OMS의 최적화된 마이크로서비스 아키텍처 디자인

Context

판매처 다양화에 따라 OMS가 특정 판매처에 강하게 결합되지 않으면서도 풀필먼트 이행 계획 데이터와 주문 정보를 여러 도메인에서 관리해야 했다. 컬리 풀필먼트의 거의 모든 도메인의 데이터를 동기화·재가공하여 서빙하면서 일관된 구조 없이는 개발·배포·운영이 비효율적이었다.

Technical Solution

• Shared Cache 이중 클러스터 운영: 데이터 성격·메모리 사용량·캐시 히트 수치·영향도를 복합 고려해 2개의 캐시 클러스터로 분리, 한곳의 장애가 전 판매처에 미치는 영향을 최소화
• 데이터 소유권 명시 규칙: 담당 MSA는 Shared Cache에 Write 권한, 나머지 도메인은 Read-only로만 조회 가능하도록 팀 컨벤션 설정
• MSA 분리 기준을 기능·역할·관리비용으로 설정: 상품정보 도메인은 주문 관리 내에 통합 유지(현재 관리비용 낮음), 향후 높은 비용 예상 시점에 분리 계획
• Operation API 서버를 거의 대부분 캐시만으로 응답: 내부 MSA 호출 없이 Shared Cache에서만 데이터 조회하도록 설계해 피크 시간대 23시 트래픽 처리
• 상시 배포 방식으로 전환: 작은 단위의 하위 MSA 배포 후 전체 기능 조립·테스트, 최종 기능 오픈은 최상단 MSA에서 카나리 배포 → 전체 배포로 진행
• 보수적 Auto Scale Out 규칙 설정: 캐시 장애 시 높은 트래픽이 각 MSA로 흘러가므로 평상시 최소 트래픽 대비 AS-IS 지표 기준으로 인스턴스 최소 수량 유지

Impact

마감 시간 23시의 Peak 응답에서 Operation API는 거의 대부분을 캐시로 처리하면서 권역 서비스의 메트릭 지표는 평온함. PR 리뷰 시 변경 소스코드의 절대량이 줄어들어 리뷰 스트레스 제거. 일단위 최소 1~2번, 많을 때는 10번 이상 작은 단위의 배포 버전 관리.

Key Takeaway

MSA 기반 아키텍처에서는 기능별 독립 개발 가능성뿐만 아니라 캐시·데이터 소유권·Auto Scale Out 규칙을 함께 설계해야 하나의 MSA 장애가 전체 시스템에 미치는 영향을 제한할 수 있다. 팀 규모 4~6명에서 모든 엔지니어가 모든 MSA의 동일한 컨텍스트를 유지할 때 설계·개발 단계의 효율성이 극대화된다.