🏷 MSA 서비스 분리 원칙(1)
⭐️3가지 키포인트⭐️ 많은 내용이 있지만 이 3가지만 기억하면 된다.
- 단계적으로 마이그레이션 해야 한다.
- 처음에 크게 분리하고 추후에 작게 분리 하라.
- 서비스 분리 공식은 없다.
1. 작고 분리가 쉬운 서비스로 워밍업
MSA 성공적인 전환을 위해서는 다양한 사전 준비사항들이 있다.
- Cloud, Deployment Pipeline, Container, Monitoring 등
본격적인 MSA 분리 전, 작은 Pilot 프로젝트를 진행하는 것이 좋다.
Pilot 서비스를 선정하는 기준은 다음과 같다.
- 기존 Monolith에서 분리 가능한 작은 기능
- 신규 개발 되는 작은 기능
- 내부적인 의존성이 가장 적은 기능
- 장애가 발생해도 전체 시스템에 영향이 적은 기능
- 데이터의 크기, 테이블의 개수가 적은 기능
2. 핵심 기능의 분리
앞 단계에서 워밍업이 끝나면, 개발팀/운영팀 모두 MSA를 위한 기본 내공이 쌓여있을 것이다.
워밍업 후 운영/배포/프로세스/조직 등에 대한 회고를 진행한 후에 핵심 기능 분리에 대응할 준비를 해야 한다.
핵심 기능을 분리할 때 어려운 점이 있다.
- 핵심 기능은 다른 기능들과의 결합도가 높다.
- 핵심 기능일수록 장기간의 유지보수가 되어있을 가능성이 커서 도메인 경계가 명확하지 않을 가능성이 높다.
따라서 이것들을 고려하여 핵심기능을 분리하기 위해서는, 분리할 핵심 기능의 도메인을 명확하게 해야한다.
(도메인이라는 것은, 커머스로 따지면 상품 전시/결제/회원)
그러나 복잡한 Monolithic 에서 분리할 도메인을 식별하는 것 자체가 어려운 작업이다.
✔️ 분리 방법 1. 비즈니스 구조를 기반으로 분리
커머스로 따지면 기존 사업팀이 결제/회원/추천 등으로 분리 되어있는 것이다.
응집도 높은 기능별로 조직이 잘 분리되어 있을 경우 비즈니스 팀 별로 분류가 가능하다.
✔️ 분리 방법 2. 도메인 주도 설계 적용
Event Storming 수행하며 시스템의 Sub Domain 및 Bounded Context를 발견하는 것이다.
Event Storming
고객이 발생시키는 이벤트를 시작점으로 하여 Path를 발견하는 것
Event Storming은 엔지니어 뿐만 아니라 도메인 전문가도 참여하여 비즈니스의 핵심 도메인을 발견하고 용어를 통일하는데, 이는 가장 중요한 테스크 중 하나이다.
다시 돌아와서, 핵심 기능은 다른 기능들과의 결합도가 높을 가능성이 크기 때문에 의존성 분석 과정이 필요하다.
그런 분석을 위해서는 정적 분석 프로세스를 통해 상세 의존성을 분석해야 한다.
기존 모놀리틱 시스템은 규모 자체가 크고 의존성 자체가 복잡하게 결합되어 있을 가능성이 크기 때문에 사람의 눈으로 판단하기가 어렵기 때문에, 다양한 정적 분석 도구 활용이 필수적이다.
3. 데이터의 분리
MSA 전환의 가장 큰 목적 중 하나는 서비스들의 독립적인 배포인데 이는 서비스 간 결합도를 최소한으로 유지해야 달성이 가능하다.
데이터베이스의 분리 없이는 이 목적을 100% 달성하는 것은 불가능한데, 데이터베이스 공유로 인한 강한 결합이 존재하기 때문이다.
MSA 전환 초기에는 워밍업 위해 DB 분리 없이 코드만 분리 가능했다.
그러나 주의해야 할 Anti-Pattern 중 하나가 서비스 별 공유 DB를 갖는 것이다.
독립 된 저장소 및 데이터 Migration 전략 수립이 동반되어야 하는데 이 데이터 분리 패턴은 이후에 다룰 예정이다.
분리 대상 선정
- 첫번째 단계는 조직의 목표를 명확하게 수립하는 것.
- 변경의 관점에서 분리 대상을 선정해야 한다.
- 코드 커밋 히스토리를 파악해 기능별 빈도 분석
- 프로젝트 로드맵을 기반으로 향후에 크게 수정될 기능 선정
- 선정을 위해 개발팀 뿐만 아니라 제품 책임자, 도메인 전문가와 끊임없이 의사소통 해야한다.
🏷 MSA 서비스 분리 원칙(2)
4. 코드의 재사용 vs 재개발
분리 대상 서비스를 확정하고 나서는 기존 Monolithic 코드를 재사용 할건지 재개발 할건지에 대한 고민이 필요하다.
일반적으로 코드를 재사용하여 서비스를 구성하는 것이 효율적으로 보이지만, 오히려 비효율을 초래할 가능성이 높다.
✔️ 오랜 기간 유지보수 된 코드의 문제점
- 기술 부채가 많이 쌓여 있고, 기술 자체도 오래 되었을 가능성 높음
- 수 없이 변경된 요구사항을 반영한 코드들은 현재 비즈니스 도메인이 명확하게 반영되어 있지 않을 가능성 높음
- 오래된 기술의 DB, Framework, Library와 관련된 BoilerplateCode가 많을 가능성 높음
✔️ 기능의 완전한 재작성의 장점
- 요구사항을 다시 파악하여 해당 기능에 대한 비즈니스 도메인을 명확화 할 수 있음
- 비즈니스에 대한 더 높은 이해를 바탕으로 아키텍처 재설계 가능
- 기존에 쌓여 있던 기술 부채 해결
- 새로운 기술 스택을 도입하여 Polyglot Architecture를 만족할 수 있음
5. 진화적인 서비스 분리
서비스를 분리할 때 가장 큰 고민거리 중 하나가 서비스의 크기이다.
얼마나 작게 분리할 것인가에 대해 고민이 많은데, 사실 정답은 없다😂
만약 서비스의 크기가 너무 작으면,
각 서비스는 응집도 높은 비즈니스 로직 없이 CRUD만 수행하게 되고 서비스의 개수는 폭발적으로 늘어나게 될 것이다.
너무 많은 수의 서비스는 되려 운영에 대한 복잡도를 늘리게 되는 문제를 야기한다.
"Go Macro, then Micro"
➡️ 우선 크게 분리하고 필요한 경우 재설계를 통해 더 작게 분리
가장 좋은 방법은, 우선 크게 분리하고 그 이후에 설계에 대한 고민을 반복적으로 하며 추가적으로 분리하는 진화적인 사고를 가지는 것이다.
6. 반복/점진적 분리
전체 Monolith를 MSA로 전환하는 것은 길고 비용이 많이 드는 여정이다.
너무 크고 원대한 목표/계획은 실패할 가능성이 높고 중간에 쉽게 지칠 수 있다.
작고 명확한 계획의 여러 단계를 만드는 것이 유리하고, 이를 기반으로 반복적이고 점진적인 방법론을 취해야 한다.
7. 서비스 분리와 조직
MSA 자체는 혁신과 실험을 가능하게 하지만, 이제 막 도입하는 시점에서의 실험/혁신은 복잡도를 크게 증가시킬 수 있다.
MSA로 전환하고 초기에 관리하는 부분만 해도 많은 어려움이 존재한다.
이럴 땐 서비스를 분리하여 새로운 서비스를 만들 전담 팀이 필요하다.
물론 기존 Monolithic 기능도 계속 유지보수 되어야 한다.
상황에 따라 신규 인력 충원도 하면서, 첫 MSA 분리가 성공하기 까지 TFT 인력들은 다른 업무가 없어야 한다.
🏷 응집도와 결합도, SRP
Microservice의 전환/분리에 대해 이야기 할 때 많이 언급되는 용어에는 응집도, 결합도 그리고 SRP가 있다.
하나씩 알아보도록 하자.
결합도와 응집도 모두 변경의 관점에서 볼 수 있다.
결합도 - Coupling
결합도 : 특정 기능을 수정하는데 같이 수정되어야 하는 다른 기능들이 얼마나 되는가
모든 기능들은 서로 협력하여 전체 시스템을 구성한다.
그렇기 때문에 완전히 독립적인 기능은 일반적이지 않다. 의존성이 항상 존재하기 때문이다.
최대한 의존성을 줄이도록 경계를 짓는 것이 주요 포인트이다.
응집도 - Cohesion
응집도 : 유사한 기능/같이 수정되어야 하는 기능끼리 얼마나 잘 그룹화되어 있는가
같이 수정되는 기능들을 한 곳에 모아두는 것이 좋다.
이들을 그룹화하여 수정/빌드/배포/운영해야 한다.
단일 책임의 원칙 - SRP
SRP는 객체지향 프로그래밍의 원칙으로 사용된다. (=객체의 변경에 대한 이유는 단 한가지여야 한다.)
마이크로서비스 측면에서, 서비스의 변경에 대한 이유는 하나의 비즈니스 영역 때문이어야 한다라고 말할 수 있다.
