아키텍처
OMS의 최적화된 마이크로서비스 아키텍처 디자인
두줄요약
OMS를 판매처와 풀필먼트를 잇는 인터프리터로 보고, 최소 동기화와 재가공 서빙을 중심으로 마이크로서비스와 shared cache 구조를 설계했습니다. 이를 통해 작은 단위 개발과 상시 배포, 피크 트래픽 흡수를 가능하게 했지만, 팀 전체의 높은 컨텍스트 공유가 필요했습니다.
구조와 흐름
- OMS를 판매처와 풀필먼트를 잇는 주문 인터프리터이자 주문·배송 이행 정보 서빙 계층으로 정의
- 최소 동기화와 재가공 서빙을 통해 다양한 도메인 데이터를 OMS 내부에 흡수하고, 이를 마이크로서비스로 분리해 관리
- shared cache 중심으로 트래픽을 흡수하고, 판매처 특성과 운영 요구에 따라 별도 캐시 클러스터와 외부 연동 구성을 적용
선택 이유
- 특정 판매처 데이터에 강하게 결합되지 않도록 설계해 향후 판매처 확장에 유리한 구조 확보
- 기능과 역할, 관리비용 기준으로 도메인을 나눠 불필요한 분리를 피하고, 필요한 시점에만 msa 분리
- 외부몰·파트너사 연동은 OMS 밖에서 동작하도록 두어 다른 팀으로 넘길 수 있는 확장성 확보
장단점
- 장점: 작은 단위 개발, 동시 작업, PR 리뷰 간소화, 상시 배포, 카나리 오픈, 라이브러리 버전업 테스트 용이
- 장점: shared cache로 내부 msa 호출과 네트워크 비용을 줄이고 피크 트래픽을 완충
- 단점: 모든 엔지니어가 모든 msa를 팔로업해야 해 컨텍스트 유지 부담이 큼
트레이드오프
- 캐시에 크게 의존할수록 평상시 효율은 높지만 장애 시 트래픽이 각 msa로 몰릴 위험 증가
- 캐시 클러스터를 분리해 리스크를 낮추되 운영 복잡도와 관리 포인트는 늘어남
- 팀 규모가 커질수록 분업 효율보다 공통 컨텍스트 유지 비용이 커질 수 있음