MSA 4) MSA 분리 전략 : 분리 원칙

분리 원칙

---

작고 분리가 쉬운 서비스로 워밍업

• MSA 성공적 전환 위해서는 다양한 사전 준비사항이 존재함

       - Cloud, Deployment Pipeline, Container, Monitoring 등

• 본격적 MSA 분리 전 간단한 서비스 분리하여 역량 내재화
• 한 두개 정도 간단한 서비스 분리하여 필요한 인프라, 프로세스 구축
• 작은 Pilot 서비스 선택
• 신규 서비스 -> 기존 Monolith 로의 의존성이 없거나 적은 서비스
• 신규 서비스 -> 기존 Monolith 의존성이 존재하면 Monolith 변경에 영향을 받음

핵심 기능의 분리

• 핵심 기능은 다른 기능들과 결합도가 높음
• 도메인 경계가 명확하지 않을 가능성 높음
• 분리할 핵심 기능의 도메인을 명확하게 해야 함
• 비즈니스 팀 구조를 기반으로 분리
• 도메인 주도 설계 적용

데이터의 분리

• 워밍업을 위해 DB 분리 없이 코드만 분리 가능
• Anti-Pattern 중 하나가 서비스 별 공유 DB를 갖는 것
• 독립 된 저장소 및 데이터 Migration 전략 수립이 동반 되어야 함

분리 대상 선정

• First Step은 조직의 목표를 명확히 해야 함
• 히스토리를 파악하여 기능 별 빈도 분석
• 프로젝트 로드맵을 기반으로 향후에 크게 수정 될 것 선정

코드의 재사용 vs 재개발

• 기술 부채 및 노후된 기술
• 오랜 기간 유지보수 된 코드의 문제점
• 요구사항 파악하여 비즈니스 도메인 명확화

진화적인 서비스 분리

• 서비스의 크기를 고려해야 함
• 원칙 - Go Macro, then Micro
• 우선 크게 분리하고 필요한 경우 재설계를 통해 더 작게 분리

반복/점진적 분리

• Monolith -> MSA 전환은 여정이 험난함
• 한번에 하나씩 단계적 분리
• 하나의 작은 기능을 신규 서비스로 분리
• 클라이언트로 부터의 Request를 신규 서비스로 전환 - Proxy 필요

Strangler PAttern Progression (akf 참조)

• Monolith에서 Method 호출하던 의존성 모두 신규 서비스로 전환
• Monolith 내부의 기존 코드는 잠시 유지 후 반드시 제거

 

결론

완벽한 정답은 없겠지만

참고 시, 언젠가 반드시 도움이 될 가능성이 높다.