성장을 위해 달려오느라 거대해진 이모티콘 서비스와 그만큼 많이 쌓인 기술 부채를 두고, 천년만년 행복하게 개발하려는 구성원들이 선택한 MSA.

기존 레거시 서비스가 단일 서버로 너무 큰 코드 베이스와 기능을 가지고 있어, 이것을 분할하려는 목적과 MSA에서 추구하는 다양한 장점들을 흡수하기 위해 MSA 기반으로 다양한 기술들을 시도하고 있습니다.

아직 이 과정은 현재 진행형이지만, 왜 MSA를 선택했고, 무엇을 했으며, 어떤 미래를 그리고 있는지를 공유해 MSA 도입을 고민 중인 분들에게 도움이 되었으면 합니다.

아키텍처에 대한 설명 답게 우리가 만들 프로젝트를 우리가 살 집이라고 생각하고 현장조사, 설계, 시공, 감리의 순으로 이야기하고자 합니다.

현장조사

: 현장의 실태를 조사해서 설계의 자료로 하는 것

우선 현장조사를 시작해보겠습니다. 현장조사는 우리가 지을 집의 터가 어떤 상태인지,그리고 우리가 원하는 요구 사항대로 지으려면 어떻게 하면 좋을지 정보를 얻기 위한 단계입니다. 저희는 이 현장 조사를 통해 얻어진 정보를 바탕으로 설계를 진행하게 됩니다.

<서버개발파트의 역할>

저희 팀이 관리하고 있는 서비스의 상황을 먼저 알아보겠습니다.

저희 팀에서 개발하는 서비스는 크게, 이모티콘 서비스, 이모티콘 스튜디오 서비스와 각 서비스를 운영하는 Admin 서비스로 나누어집니다. 물론 이 외에 다른 서비스들이 있지만 이 큰 4가지가 주된 서비스들입니다.

이 중에서 이모티콘 서비스가 가장 큰 서비스로, 가장 오래된 이모티콘의 역사가 담겨있습니다.

각 대규모 서비스들은 모놀리스 형태로 각각 서비스 운영이 되고 있고, 이미 눈치채신 분들도 계시겠지만 Play 1.2.7처럼 오래된 프레임워크에서 아직 살아남아있습니다. Java 7을 사용하고 있고 admin 툴은 빠른 운영 기능 대응을 위해 선택 되었을 거라고 예측되는 Ruby on Rails를 사용하고 있습니다. 저희에게는 청산 대상입니다.

그리고 서버 상황 말고 저희 팀이 운영하는 이모티콘 서비스 상황을 살펴보면 이렇습니다.

출시 8년 만에 연 매출 1000억을 달성한 이미 성숙한 서비스입니다. 오랜 기간 앞으로 달려오다 보니, 많은 기술 부채가 적재된 상황이라 유지 보수가 팀의 주요 관심사가 되었습니다. 이러한 환경 속에 저희 팀이 느끼는 이슈들을 크게 운영적인 부분과 기술적인 부분으로 나누어 보겠습니다.

운영 이슈

첫 번째로 배포가 불편했었습니다.

이전에 저희는 webistrano나 ansible을 통해 배포를 진행하고 있었는데, 해당 배포 방식이 익숙하지 않은 저 같은 경우 처음 팀에 합류 했을 때, 배포 방법에 대한 러닝 커브가 상당하다는 것을 느꼈습니다. 각 서버마다 배포 방식도 모두 달라서 배포할 때마다 헷갈리고, 혹시나 배포 실수로 장애가 날까 봐 엄청난 부담감이 있었습니다.

두 번째로는 코드의 버전 관리 복잡도가 높다는 것입니다.

하나의 서버에 많은 기능이 모여있다 보니 여러 개발자가 같은 저장소에 여러 브랜치를 만들어 작업하게 됩니다. 이러다 보니 누가 먼저 머지 되느냐에 따라 code conflict도 나고 잘못 merge되기도 해서 원하지 않는 장애를 만나기도 합니다.

세 번째로는 하나의 서비스가 하나의 저장소를 사용하는 상태로 거대해지면서 메인 DB의 트래픽이 너무 높아지고 있었습니다. 빨리 이것을 나누어 해결해야 하는 상황이었습니다.

기술 이슈

첫 번째는 서비스가 너무 커서 설계를 변경하기가 어렵다는 것입니다.

서비스가 오랜 기간 하나의 덩어리로 계속 커지다 보니 본의 아니게 커플링도 많아져서, 한 가지를 바꾸면 같이 바꿔야 하는 것들이 많고, 담당 기능이 아닌 곳까지 수정하는 경우도 발생해 사이드 이펙트의 부담이 생깁니다. 그러다 보니 신규 기술을 적용하기 위한 의지를 가지기가 어려웠습니다.

그래서 이어지는 두 번째 이유인, 저희 구성원이 계속 운영해 가야 할 프로젝트가 과거 기술에 종속되어 앞으로 나가지 못하는 경우들이 발생합니다. 특정 라이브러리가 신규 버전에서 더 이상 호환이 안되는 경우도 발생하고, 팀의 관심 기술들과도 멀어져 개선을 위한 노력도 떨어지는 상황이 발생합니다.

그래서 저희는 배포 부담을 줄이기 위해 배포 단위를 작게 만들고 싶었고, 담당 영역을 분산하기 위해 서비스 크기를 작게 만들고 싶었습니다. 거기에다 기술 적용에 자유도를 높여서 다양한 기술을 사용하는 방향으로 서비스가 만들어졌으면 했습니다.

설계

: 목적에 따라 실제적인 계획을 세워 도면 따위로 명시하는 일

이렇게 앞의 현장조사를 통해 알게 된 상황과 요구 사항을 바탕으로 설계를 시작해야 합니다.
저희 팀이 설계를 시작하기 위해 알아본 설계 방식 중에 하나가 바로 MSA입니다.

특징만 간단하게 짚고 넘어가 보겠습니다.

MSA의 특징

쉽게 사전적인 의미를 찾기 위해 위키피디아를 찾아보면 크게 4 가지의 특징이 첫 문단에 쓰여있습니다.

서비스 간에 네트워크를 넘나드는 통신을 하게 된다.
도메인 중심으로 설계된다.
서비스별 최적화된 기술을 독립적으로 사용 가능하다.
서비스 크기는 작아지고, 독자적 개발이 가능하고, 독립 배포 가능하고, 배포 자동화도 가능하다.

딱 이 특징만 보면 저희 팀이 원하는 방향보다도 더 많은 장점을 가지고 있습니다.

MSA를 통해 기대할 수 있는 것

MSA를 선택한다면 다음과 같은 것들을 기대할 수 있을 거라고 생각했습니다.

운영 측면

배포 단위가 작아진다.
배포 영향 범위가 줄어든다.
배포 버전 관리가 독립적이 된다.
Branch 엉키는 일이 줄어든다.

트래픽 분산이 가능해져 서비스 별로 효율적인 리소스 운영을 기대할 수 있을 것 같았습니다.

기술 측면

서비스가 작아져 역할이 명확해지고, 디버깅 포인트를 고립시킬 수 있다.
설계변경에 대한 부담이 낮아진다.
각 서비스별로 기술 선택의 의존성이 낮아져서 각 서비스에 맞는 최적 기술을 선택이 가능해진다.

MSA에게 기대하는 점들은 MSA 단독으로는 빛을 보기 어렵습니다.

MSA는 따지고 보면 SOA 하위 호환 느낌으로 서비스 구조가 서버 안에서 더 바깥으로 나누어졌을 뿐, 여느 소프트웨어 기술들과 마찬가지로 설계면에서는 오래전부터 이미 있었던 개념에서 벗어나지 않습니다.

하지만 왜 근래에 MSA가 핫해졌는지를 생각해 보면, 그 이유가 클라우드 환경의 보편화 때문이란 걸 알 수 있습니다. 작은 서비스 단위를 가지는 MSA와 물리적인 이슈를 많이 해결해 준 Cloud 인프라 환경은 각각의 장점을 크로스하고 있습니다.

MSA를 통해 생겨나는 많은 서비스의 배포 때문에 걱정되는 부분들은 클라우드의 편리한 인스턴스 할당 관리를 통해 해결이 가능합니다.
자유로운 인스턴스 할당의 폐해로 나타날 수 있는, 리소스의 낭비는, MSA를 통해, 서비스별 리소스 할당이 가능한 장점으로 보완이 가능합니다.

결국 MSA는 클라우드 때문에 빛을 보게 되었고, 클라우드 역시 MSA를 통해 장점이 더 부각되어 둘은 연인 사이와 같은 궁합을 보여줍니다. 그래서 MSA 고려시 클라우드 인프라의 구축은 필수가 되었습니다. 반대로 클라우드 환경에서는 MSA 도입을 고려해보는 것이 자연스러운 일입니다.

MSA도입을 통해 예상되는 고통

하지만 이렇게 희망적인 기대와는 다르게 걱정되는 부분들도 있었습니다.

기술 측면

함수 호출이 Network I/O 호출로 바뀌게 된다. (서비스간 상태 동기화가 어려워진다.)
DB 분리 시에 Join이 어려워진다.

서비스간 네트워크 호출이 추가되어 네트워크 오류에 대한 고민들이 추가되고, DB도 분리하게 되면서 편하게 join 할 수 있었던 것들이 그러지 못하게 되어 성능이나 설계상 손해를 봐야 할 수 있는 상황이 걱정이 되기도 했습니다.

운영 측면

관리해야 할 서비스가 많아진다.

운영적인 측면으로는 팀 구성원들이 이미 각자 한 개 이상의 서비스를 담당하고 있는 와중에 더 많은 컴포넌트와 서비스를 맡게 될 것 같았습니다.

모든 서비스가 항상 이슈가 나는 것은 아니지만 물리적으로 많은 서비스를 담당하게 되면 쉽게 소홀해질 수 있어서 관리 이슈를 최대한 줄일 수 있어야 했습니다.

그리고 분리된 서비스를 따로 개발하다 보면 기술 스택의 차이 때문에 업무공유가 어렵거나 인수인계가 쉽지 않은 상황도 벌어질 수 있을 것 같았습니다.

우리가 할 수 있는 일

이렇게 저희 팀이 기대하는 것과 우려하는 것을 종합해서 고민한 결과는 다음과 같습니다.

MSA가 우리의 목표에 맞는 설계라고 결정을 하게 되었고, 그 청사진에 맞는 시공 방식과 건축 자재로는 클라우드 환경을 지원하는 쿠버네티스(kubernetes)를 선택하였습니다. 그리고 서비스 단위가 아닌 더 작은 요청 단위의 리소스 활용에 더 효과적일 거라 기대하는 Kotlin을 개발 언어로 선택하였습니다.

마지막으로 우리에게 친숙하고 비교 대상이 크게 없는 Spring을 개발 프레임워크로 선택하였습니다.

사실 시공 방식에 대한 것이나 기술의 선택이 처음부터 그냥 한 번에 딱 결정된 것은 아니고, MSA를 팀에 녹이는 과정에서 결과적으로 선택이 된 것입니다. 그리고 건축 자재는 팀 구성원들이 보편적으로 가지는 기술 관심사와 현재 상황을 고려해 결정이 되었습니다.

그래서 이후 만들어질 마이크로 서비스들은 가능한 이 기술 스택 바운더리 안에서 결정하자 정도로 합의를 하고 프로젝트들을 진행하게 되었습니다.

시공

: 도면에 따라 현장에서 공사를 실시하는 것

MSA 적용을 위해 해야 할 일

MSA를 적용하면서 지나온 과정을 크게 나누어 본다면 3가지 정도가 됩니다.

서비스 배포 환경을 통합하고 리소스 설정이 간단하게 되도록 하자
서비스 간 연결 관계와 모니터링을 쉽게 만들자
서비스를 나누자

서비스 배포 환경을 통합하고 리소스 설정이 간단하게 되도록 하자

첫 번째로 서비스 배포 환경을 통합하고 리소스 설정이 간단하게 만들기 위해 한 일들을 알아보겠습니다.

클라우드 인프라의 장점을 단순 가상 인스턴스 위에 서버를 돌리는 것으로 기대하기는 어렵습니다.

단적으로 기존의 webistrano나 ansible 같은 경우에도 모두 클라우드에서 사용 가능한 툴 들이지만 리모트에 있는 온프라미스 환경에 배포하기 위해 만들어진 툴 들이라 클라우드 네이티브 하다고 보기에는 어렵고 여러 대의 장비에 배포하는 것이 그렇게 편하지는 않았습니다.

그래서 일부 서비스에 먼저 도입하여 사용하던 쿠버네티스가 관리에 가장 적합했고, 타이밍 맞게 쿠버네티스로 개편하라는 조직 요구 사항이 겹쳐 쿠버네티스 환경 반영을 진행하게 되었습니다.

결과적으로 저희 팀의 MSA 적용에 불을 붙이게 된 것은 쿠버네티스의 도입이라고 봐도 무방합니다. 쿠버네티스의 사용은 MSA를 위해 모든 구성원들이 알아야 하는 기본 상식 이기 때문에 팀에서도 스터디를 통해 학습을 진행했고, 현재 저희 팀의 모든 서비스는 쿠버네티스에 올라가 있습니다.

하지만 쿠버네티스를 사용하기 시작하면서 좋은 점만 있었던 것은 아닙니다.
늘어난 서비스 만큼의 yaml이 만들어지고 거기에다 추가적으로 Stage 별로 따로따로, 중복된 yaml들이 많아져 yaml 복붙의 향연이었습니다.

그러다 보니 관리해야 할 yaml이 너무나 많아 이것을 보다 효과적으로 관리할 필요가 있었습니다.

그래서 처음에는 YAML 동적 생성을 위해 스크립트도 짜보고 이런저런 시도를 해 보다가 결국 만난 것이 Kustomize입니다. Kustomize는 yaml 설정을 directory를 이용해서 구조화하고 각 설정을 재사용할 수 있게 되어있어 설정의 관리가 간편해 집니다.

이렇게 Kustomize로 yaml이 간편화되어 cli로 나름 잘 사용하고 있었지만, 더 편한 방법을 찾기 위한 저희 팀원의 노력으로 ArgoCD를 도입하게 됩니다.

출처 : https://www.cncf.io/blog/2020/12/17/solving-configuration-drift-using-gitops-with-argo-cd/

ArgoCD는 쿠버네티스 api를 사용해서 ArgoUI라는 WebUI를 제공하는데 까만 화면만 보다가 신세계를 보게 되었습니다. 그리고 여기에 github 저장소를 연결해 사용하게 되면 gitops가 가능해집니다.

gitops를 도입하게 되면 git의 commit을 통한 배포 이력 관리도 가능해 다양한 형태의 이력 관리 확장도 가능합니다.

그래서 저희팀이 현재 사용하는 gitops 플로우는 그림과 같습니다.

새 이미지가 빌드 돼서 d2hub에 저장을 하고 해당 이미지 태그를 수정해 깃헙에 커밋을 하면 ArgoCD가 변경사항을 ui에 표시해 줘, ArgoUI에서 sync 버튼 클릭만으로 서비스 배포가 진행이 됩니다.

기존 Jenkins의 블루오션과 어떤 차이가 있냐라고 하실 수도 있겠지만 ArgoUI에서는 각 팟별로 배포되는 과정을 모두 한눈에 볼 수 있어 텍스트 로그와 스텝별 배포 결과만 볼 수 있는 블루오션과는 완전히 다른 경험을 하실 수 있습니다. 그래서 현재 저희 팀의 모든 서비스들은 ArgoCD를 통해 관리되고 있습니다.

여기까지 과정이 저희 팀이 MSA 환경의 배포를 위해 지나온 인프라 발자취입니다.

서비스 간 연결 관계와 모니터링을 쉽게 만들자

이제 이 서비스들의 연결 관계 관리와 모니터링을 쉽게 하기 위해 작업한 내용을 이야기해 보겠습니다.

아마 MSA에 관심을 가지신 분들에게는 너무나도 유명한 그림입니다.

출처 : http://channy.creation.net/blog/1382

저희 팀의 미래가 될 수도 있는 스타워즈의 데스스타 같은 서비스 연결 타래 그림입니다.

사실 처음 쿠버네티스에 서비스들을 올렸을 때는 인프라만 교체되는 수준이었기에 서비스 흐름이랄 게 없었습니다. 하지만 클러스터를 나누고, 스테이지를 구분 짓고, 서비스를 나누다 보니 기본 쿠버네티스 컨트롤러만으로는 커버하기 힘든 상황들이 나오기 시작했습니다.

그래서 이것을 해결하기 위한 방법으로 도입된 것이 이스티오(Istio)입니다.

이스티오는 쿠버네티스에 올려진 서비스들 간의 연결 구조를 볼 수 있는 서비스 매쉬 계층을 두고 그것을 관리할 수 있는 기능을 제공합니다.

VirtualService, ServiceEntry, Proxy 등 다양한 기능을 제공하여 연결 관리를 좀 더 유연하게 해주고, 이스티오에서 제공하는 서비스 메쉬 설정 정보들을 통해 서비스들의 상태나 연결 흐름을 kiali를 설치하시면 눈으로 확인하실 수 있습니다.

현재 저희 팀의 kiali에서 보이는 서비스 메쉬 상황입니다.

이외에도 프로메테우스나 오픈 트레이싱 툴을 연결하는 기능을 이스티오에서는 제공하기 때문에 모니터링 툴에 대한 고민을 많이 해소할 수 있습니다.

서비스를 나누자

이제 마지막 과정으로 서비스를 나누기 위해 저희 팀이 진행한 일들을 알아보겠습니다.

클라우드 환경의 도입과 MSA 설계로 인해 새로 만들어지는 기능들을 만들어 배포하는 것은 수월해졌지만, 저희에게는 처음에 이야기했던 거대한 레거시 서비스인 이모티콘 서비스에서 다운타임 없이 서비스를 하나씩 뜯어내야 하는 어려운 도전이 있었습니다.

MSA를 하겠다는 목표 중에 하나가 이 거대 서비스를 쪼개는 것이었기 때문에 방법을 찾아야 했습니다.

저희는 많이 알려진 방법인 Api gateway를 사용해 레거시를 고립시키는 방법을 선택하였습니다. 그래서 Api gateway를 어떻게, 어떤 툴로 만들지 결정을 해야 했고, 결과적으로 Spring Cloud Gateway를 선택하게 되었습니다.

Api gateway의 선택지에는 Kong도 있었지만 팀 기술 스택이 Spring 인 이상 프로덕트 라인을 통일하는 것이 수월할 것으로 생각해 선택하게 되었습니다.

이 방식은 여러 기술 사이트를 통해 많이 알려져 있는 것 처럼 Api gateway를 기존 서비스의 앞에 두어 기존 서버에서 하나둘씩 분리해 나가는 것입니다. 서비스를 분리할 때도 path 기준으로 하나씩 라우팅 전환해가면서 분리해 나갔습니다.

그림을 보면 아마도 단순 라우팅만 필요한데 ingress를 두고 굳이 또 api gateway를 두었느냐 의문을 가지시는 분들도 계실 텐데요, 그 이유는 트래픽을 고립시키려는 의도와는 별도로 인증 등의 특정 비즈 로직을 한 군데에서 처리 가능하게 하고 싶었기 때문입니다.

ingress의 라우팅을 사용한다면 인증 등의 비즈 로직을 각 서비스 별로 처리해야 하는 상황이었습니다.

그렇게 되면 동일한 코드가 각 서비스에 들어가게 되고, 만약에 인증 관련 로직 수정을 해야 한다면 인증이 들어간 모든 서비스가 변경이 되어 서비스별로 독립적인 배포를 유지하는 것에 어려움을 겪을 게 불 보듯 뻔했습니다.

ingress controller를 수정해서 넣을 수 있는 하드보일드 한 선택지도 있었지만, 우리가 지속적으로 유지 보수 가능한 기술 스택으로 해결하기 위해 Spring Cloud Gateway를 서비스들 맨 앞에 두는 것이 가장 적절해 보였습니다.

이렇게 저희 팀은 Api gateway를 넣어둔 이후에 뒤로 서비스들을 계속 분리해나가고 있습니다.

Microservice의 단위 정의 (feat. 이모티콘팀)

여기에서 서비스를 하나둘씩 분리할 때 가장 큰 고민거리 중에 하나가 바로 마이크로 서비스의 기준이 무엇인지 결정하는 것이었습니다.

사실 아직도 팀 구성원들 사이에서 완전히 합의된 마이크로 서비스에 대한 단위를 정의하지는 못했지만 최소한의 합의된 기준들은 이렇습니다.

기능 목적이 2개 이상이 되지 않도록 한다.
여러 기능에서 사용하는 단위 리소스라면 서비스로 분리하여 공동 사용한다.
사내 통제 대상인 Admin인 경우, 최소한으로 통제 Cluster에 넣도록 서비스를 분리한다.
개인 정보 대상으로 분류된 데이터를 관리하는 서비스는 해당 데이터 관리에 필요한 기능을 최소화하여 분리한다.

이건 경험상 이렇게 해두지 않으면 개인 정보 대상의 db가 아닌데도 같이 묶여, db 확인을 위해 매번 망분리 환경에 들어가야 하는 불편을 겪게 됩니다.

마지막으로 서버 렌더링을 배제하기 위해 Front서비스와 Backend 서비스는 서로 분리한다.

구성원들이 나누어질 서비스의 기준에 대한 합의 없이 서비스를 나누게 되면 중구난방의 설계가 되어 불필요한 분리가 되거나 다시 덩치 큰 서비스를 만들 수 있게 되어 서비스 단위의 기준에 대한 논의는 꼭 하시는 게 좋습니다.

이렇게 서비스를 나누는 과정까지 해서 MSA 적용을 위해 저희 팀이 한 일들을 모두 알아봤습니다.

감리

: 건축사가 설계도에 따라 해당 공사가 진행되고 있는지 확인하는 행위

아직 저희 팀도 완공 수순이 아니지만 여태까지의 진행 상황에서 나온 부분들을 되짚어 보기 위해 감리 과정으로 들어가 보겠습니다.

Microservice로 분리 후 좋아진 점

MSA를 위한 인프라가 갖춰지고 팀의 방향이 자리 잡은 이후에 좋아진 점은 이렇습니다.

업무 역할 분담이 명확해졌다

물리적으로 서비스가 각자 분리되고 코드 영역이 분리되어 본인이 확인하고 담당해야 할 영역이 명확해졌습니다. 이로 인해 본인의 영역에서 최적의 솔루션을 반영하는데 집중할 수 있게 되어 책임감 뿐만 아니라 좀 더 해당 기술에 전문성을 가질 수 있게 되었습니다.

배포의 부담이 많이 낮아졌다

새로 도입된 배포 시스템 덕분에 원하였던 대로 배포의 부담이 많이 낮아졌습니다. 배포 시 다른 서비스 로직의 코드가 섞여 들어갈 위험성도 작아지고 장애 시 롤백이나 재배포도 편해졌습니다. 통일된 인프라 덕분에 배포 방식도 간단해져 더 이상 과거와 같은 배포를 위한 러닝 커브는 없을 것 같습니다.

신규 서비스 기능 추가가 쉽다

신규 서비스 기능 추가가 편리해졌습니다. 신규 서비스의 경우에는 말할 것도 없고, 기존 코드 수정하는 것 역시 앞서 이야기한 것처럼 단위가 명확하고 작아져 수월해졌습니다. PR이 몰려서 발생하는 코드 컨플릭으로 발생하는 리베이스 빈도도 많이 줄어들었습니다.

저희 팀은 편리한 유지 보수가 설계의 중요한 포인트였기 때문에 현재의 결과에 아주 만족하고, 이 상태를 계속 발전시켜나갈 생각입니다. 특히 배포의 부담과 유지 보수에 대한 부분이 많이 해결되었기 때문에 앞으로는 성능과 리소스 측면의 개선에 포커스를 맞춰 나갈 생각입니다.

Microservice로 분리 후 힘들어진 점

설계 제약 사항과 고민들이 늘어난다

우선 설계 시 고려해야 할 사항이 늘어난다는 것입니다. 함수 호출이 아닌 IO 연결로 인해 이전에는 고민하지 않았던 서비스 간의 네트워크 에러와 이로 인해 발생하는 트랜잭션 이슈, 서비스 간 상태 동기화 등이 있고, 설계 시 DB 가 분리되는 것을 고려해서 서비스를 만들어야 한다는 점 등입니다.

개인이 담당할 서비스가 늘어난다

처음 설계 시 우려했던 것처럼 물리적으로 서비스가 늘어나기 때문에 담당 범위가 늘어납니다.서비스를 365일 24시간 운영도 해야 하지만 우리는 인간인지라 쉬기도 해야 하기 때문에 각 서비스 별로 백업 멤버도 있어야 유연한 근무환경을 유지할 수 있습니다. 너무 많은 분리는 인력 충원 없이는 한계가 올 수 있습니다.

서비스가 도메인 지식 공유가 힘들다

백업 멤버 없이 해당 서비스의 도메인 지식이 제대로 공유가 안되거나, 서비스간 기술 스택의 간극이 너무 벌어지면 담당자가 업무 고립이 되어 독박 타임을 맞이할 수 있습니다. 팀 구성원들이 번아웃에 너무 쉽게 빠지지 않게 하기 위해서는 서비스 분할 시 이 부분을 꼭 고민을 해야 할 것입니다.

완공을 위해 남은 작업들

완공을 위해 남은 작업들은 아직 다 쪼개지 못한 서비스를 쪼개는 작업, 네트워크로 분리되었기 때문에 잃어버린 성능을 보상할 수 있는 방법, 그리고 보다 더 효율적인 리소스를 활용하기 위해 비동기 방식의 도입 등입니다.

위 작업들 해결을 위해 팀에서는 Event Driven 설계의 적용과 gRPC, webflux-coroutine등의 사용을 확대하고 armeria 사용을 시도하고 있습니다.

MSA 적용이 수월했던 간접적인 이유

마지막으로 MSA 적용에 있어 저희 팀이 좀 수월하지 않았나 하고 자부하는 부분들에 대해서 공유한다면 기술적인 부분도 있었지만 팀의 분위기도 적지 않은 영향을 줬다고 생각합니다.

기존 환경에 대한 불편함을 뭉개고 앉아있는 것이 아니라, 어떻게든 개선을 하려고 하는 구성원들 덕분에 빠른 쿠버네티스로의 적응을 할 수 있었고, 다양한 기술 습득과 공유에 관심이 많아 업무에 지치지 않을 수 있었던 것 같습니다.

기술 도입에 있어 고민하는 분들은 팀의 분위기도 끌어올리는 것에도 신경을 쓰시면 좋을 것 같습니다.

그래서 MSA를 적용하는 것이 답인가?

제가 드리는 답은 결국 현장조사를 진지하게 해봐야 한다입니다.

출처 : https://www.oreilly.com/library/view/oscon-2015-video/9781491927991/video219115.html

소프트웨어 아키텍처 이야기할 때 단골 손님인 마틴 파울러 선생님의 이야기를 빌려 이야기하면, 소프트웨어 아키텍처에서 중요한 것은 탁상공론의 위험성을 줄이고 현실이 반영되어야 한다는 것입니다.

결국 우리가 해결해야 하는 문제의 정의가 정확하게 되어야, 그에 맞는 설계를 할 수 있어 현장조사가 제일 중요합니다.

그래서 MSA를 고민하는 분들이라면

조금 더 간편한 선택지를 원하시는 분들도 계실 것 같아 제가 감히 제안한다면 이렇습니다.

우선 팀의 현장조사를 통해 문제를 확인한 다음, 팀의 서비스 하나에 너무 많은 사람이 같이 붙어있어 관리가 어려워 나누고 싶거나, 기술 부채가 누적되어 일부를 조금씩이라도 뜯어서 고치고 싶거나, 서비스 모듈 간 기술 스택 자유도를 부여하고 싶다면 MSA 도입을 추천드립니다.

아니면 다른 것은 다 괜찮은데 배포 부담 만이라도 어떻게든 좀 줄이고 싶다 하신다면 위에서 소개 드린 배포 환경의 우선 도입을 추천드립니다.

긴 글 읽어주셔서 감사합니다.

이모티콘 서비스는 왜 MSA를 선택했나?