들어가며
마이크로서비스 입문 단계에서 가장 고민스러운 부분은 '거대한 하나의 시스템을 어떤 식으로 나누는 것이 좋은가?' 이다. 필자가 2년간 마이크로서비스 기반으로 시스템을 설계하면서 느낀 것은 답은 정해져 있지 않다는 것이다. 고객과 약속한 SLA(Service Level Agreement)가 존재하거나, 시스템에서 미션크리티컬한 기능, 또는 관리적인 부분, 생산성을 위한 젼략 등 중요하게 생각하는 관점이 매번 달라지기 때문이다. 개발자가 반복문을 사용함에 있어 for 문 foreach 문 while 문 중 하나를 선택하여 개발하는 것처럼 시스템에서 제공해야 할 기능을 잘 동작한다면 상관없다. 하지만 필자가 처음 설계할 때는 뭔가 정답이 있을 것만 같아서 개운치 않은 기분을 느낀 적이 많았다.
이번 포스팅에서는 필자가 사내에서 진행한 MSA 교육에서 설명한 서비스 분리 전략과, 분리된 서비스를 어떤 식으로 개발할 것인지, 개발된 서비스를 어떻게 관리할 것인지에 대해 가볍게 알아보도록 한다. 포스팅에 포함되는 내용은 여러 MSA 전문가 분들과, 서적의 내용 그리고 필자의 짧은 경험이다.
서비스를 어떻게 나눌 것인가?
비즈니스 능력에 근거한 도출방식
비즈니스 능력에 근거한 도출방식은 업무적 기능 분해를 이용하여 서비스를 나누는 방식으로, 업무 기능분해도에 명시된 분류 항목들을 기준으로 서비스를 나눌 수 있어 직관적인 서비스 도출이 가능하다. 하지만 업무 기능분해도의 타이틀 만으로 기능을 식별하게 되면 서비스 간의 관계를 파악하거나 서비스가 관리해야 할 독립된 데이터를 식별하기 힘들다. 그래서 서비스 분리가 간편하면서도 실제 구현 단계에서 분리에 실패할 확률이 높은 방식이다.
도메인 주도 설계의 전략적 설계 방식
도메인 주도 설계는 소프트웨어 디자인과 비즈니스 도메인이 요구하는 전략을 일치시켜 프로젝트를 성공적으로 완성하기 위한 사고방식이다. 도메인 주도 설계를 통한 서비스 설계를 위해 알베르토 브란톨리니가 개발한 이벤트스토밍 워크숍을 활용할 수 있다.
[MSA] 이벤트 스토밍(Event storming)
들어가며 필자가 이벤트 스토밍을 진행할 때 헷갈리는 부분은 2가지였다. 첫 번째는 다양한 포스트잇 색상의 의미였고, 두 번째는 활동의 진행 순서였다. 이번 글에서는 이 두 가지에 대한 요약
devlos.tistory.com
이벤트 스토밍을 통해 도메인 모델들이 가진 상태를 변경시키는 이벤트를 식별함으로써 도메인 모델 간의 상호관계를 명확히 파악할 수 있고, 전략적으로 경계를 나누어 서비스를 분리해 낼 수 있다. (고객과 함께 진행했을 때 만족도도 높다.. 그렇지만 퍼실리에이팅이 정말 중요하고 중요하다.)
기타 설계 방식
고객이 요청한 SLA(Service Level Agreement)가 있을 때는 이에 포커싱하여 서비스를 분리해 낼 수 있다. 고객의 SLA 가 없을 때는 요구사항 도출 단계에서 자체적으로 시스템에서 중요한 비즈니스로직을 도출해 낼 수 있는데, 이때 죽어도 괜찮은 부분과 절대로 죽어서는 안 되는 부분을 기준으로 나눈다.
재사용 관점으로 서비스를 분해할 때는 각 사업의 교집합에 속하는 서비스들을 도출해 낸다. 이 때는 주로 특수한 기능에 따라 분리할 수 있는데 메일 발송서비스, 서드파티 결제 서비스 등이 이에 해당한다. 예시의 기능은 서비스에서 추상화한 다음 구현체를 통해 구현할 수도 있다.
서비스를 어떻게 개발할 것인가?
마이크로서비스의 각 서비스들은 독립적으로 동작할 수 있어야 하지만, 상호 간의 인터페이스 외에 의존성이 없다. 그렇기 때문에폴리글랏한 형태로 구현될 수 있는데, C나, JAVA, Javascript, Python 기반의 프레임워크 형태로 분리가 될 수도 있고 더 세부적으로 Query를 중점적으로 개발하거나 비즈니스로직을 중점적으로 개발할 수도 있다.
Query를 중점적으로 구현할 경우 데이터 중심 설계가 가능한데, 이는 관계형 데이터베이스에 의존한 데이터 모델링을 수행한 다음에 이 물리 테이블 모델을 중심에 두고 애플리케이션을 구현하는 것이다. 데이터 중심 설계는 비즈니스로직이 객체 모델보다 데이터 질의 구문인 SQL 문에 들어 있다는 것이다.
비즈니스로직에 중점적으로 구현할 경우 헥사고날 아키텍처를 사용할 수 있다. 이는 비즈니스 도메인을 중점적으로 구현하는 것으로 도메인 지식을 중심으로 포트와 어댑터를 외부로 분리해 내어 개발한다. 이 아키텍처의 핵심은 도메인 계층의 소스코드를 통해 비즈니스의 플로우를 이해할 수 있도록 하는 것이다.
[MSA] 헥사고날 아키텍처(Hexagonal Architecture)
들어가며 이번 글에서는 이벤트 스토밍 결과물을 실제로 구현할 수 있도록 표현하는 헥사고날 아키텍처에 대해 알아보도록 한다. 이벤트 스토밍이 생소하다면 다음의 글을 먼저 참고하기 바란
devlos.tistory.com
서비스를 어떻게 관리할 것인가?
서비스를 관리하는 방식은 모놀리틱 한 아키텍처와 확연히 달라지는 부분은 없다. 다만 하나의 프로젝트가 여러 작은 프로젝트로 나뉘고 병렬적으로 실행되기 때문에 이를 통합하여 관리하는 것이 중요하다. 분리된 마이크로서비스의 크기는 8명 이내의 팀원이 2주 이내 개발해야 할 정도이다. 프로젝트의 크기가 클수록 다수의 마이크로서비스들이 도출될 수 있다. 관리자의 입장에서 프로젝트 진행상황을 확인하려면 각 개별 프로젝트의 일감들을 통합하여 인지하는 것이 중요하다.
조직마다 일감을 관리하는 방식이 다르기 때문에 정답은 없지만, 프로젝트 리뷰를 하듯이 서비스 별 개선 필요사항들을 수집하고 개별적으로 리뷰를 하며 지속적인 개선을 해나가는 것 역시 중요하다.
운영 시에도 로그나 모니터링을 해야 할 서비스들이 나눠서 실행되기 때문에 이러한 정보들을 통합하여 모니터링할 수 있는 환경이 필요하다. SaaS형태로 제공되는 Datadog이나 그라파나&로키 스택을 이용한 모니터링 방식을 사용할 수 있다.
마지막으로 설계 문서와 실제 프로젝트 반영 내용을 동기화하는 것이 중요하다. 폭포수 기반 프로젝트를 진행할 때는 설계 단계가 모두 수행된 다음 개발이 진행되므로 프로젝트 후반부에 설계와 실제 개발내용의 격차가 심하게 발생할 수 있다. 마이크로서비스는 시스템 단위가 작기 때문에 서비스별 업무 영역이 줄어들어 설계 변경에 상대적으로 용이하며 파악 및 업데이트 역시 편하다. 프로토타입 시점에서 설계 문서를 작성했다면, 개선 2~3 사이클 이후에는 설계문서를 살펴보며 실제 구현된 내용과 동기화시켜 줄 필요가 있다.
마치며
이번 글에서는 마이크로서비스를 분리하는 방법과 분리된 마이크로서비스를 개발하고 관리하는 방식에 대해 간략하게 살펴보았다. 2017년 이후부터 MSA가 급부상하며 많은 조직들이 도입을 검토하고 있지만 설계, 구현, 운영에 대한 전반적인 이해가 쉽지 않아서 포기하거나 실제 프로젝트 단계로 넘어가지 못하는 상황이 많아 보인다. 필자도 2년 전 동일한 고민을 했었다.. 하지만 운 좋게 여러 분들의 도움을 받고, 서비스 설계에 대한 자문을 받으면서 상대적으로 짧은 시간에 감을 잡을 수 있었다. 이 유용한 설계 기법을 이해하고 활용하는 분들이 많아졌으면 하는 바람이다.
여담
PKOS 스터디가 끝나고 한동안 블로깅이 뜸했다가 '24단계 실습으로 정복하는 쿠버네티스'의 저자이신 정훈님의 제안으로 블로그 꾸준히 쓰기 운동인 '댓또'에 참여하게 되었다. 이번 기회를 통해 써야지.. 하면서 나의 노션 안에서 헤엄치고 있는 글들을 꾸준히 풀어내어야겠다 :)
'MSA 설계 & 도메인주도 설계' 카테고리의 다른 글
| [MSA] 헥사고날 아키텍처(Hexagonal Architecture) (2) | 2022.02.21 |
|---|---|
| [MSA] 이벤트 스토밍(Event storming) (0) | 2022.02.15 |
| [DDD] 도메인 계층의 Structure (0) | 2022.02.08 |
| [DDD] 인터페이스 계층과 응용 계층의 구현 (0) | 2022.02.07 |
| [DDD] 애그리거트란? (0) | 2022.02.06 |