PE Notes · SW
MSA와 서비스 메쉬
모노리식의 배포·확장 한계에서 MSA 전환 동인을 잡고, 스트랭글러·서비스 메쉬·모듈러 모노리식으로 언제 나누고 언제 붙일지를 정리합니다.
한 바이너리에 화면·업무·데이터가 같이 있으면 처음은 빠릅니다. 팀이 늘고 배포가 잦아지면, 작은 수정이 전체를 멈추고 검색만 키울 수 없습니다. 는 서비스를 독립 배포 단위로 나누고, 는 그 사이 통신·보안·관측을 코드 밖에 둡니다.
모노리식 구조와 한계
은 UI·로직·DB 접근이 한 프로세스, 한 배포입니다. 디버깅과 트랜잭션이 쉽고 초기는 빠릅니다. 한계는 세 가지입니다. 확장이 통째이고, 작은 변경도 전체 재배포이며, 기술 스택이 하나로 묶입니다.
전환 동인은 팀 규모, 독립 릴리즈, 기능별 스케일입니다. 은 조직 소통 구조가 시스템 구조로 굳는다는 관찰입니다. 팀 경계와 서비스 경계가 어긋나면 배포가 싸웁니다.
MSA 전환과 서비스 메쉬
한 번에 갈아엎지 않습니다. 은 옛 기능을 유지한 채 새 서비스를 옆에서 키워 점진 교체합니다. 다음은 DDD 로 경계를 긋고, 공유 DB를 서비스별 DB로 나눕니다. 분산 트랜잭션은 보상 흐름으로 넘깁니다.
서비스가 수십이 되면 재시도·타임아웃·추적·암호를 각 팀이 다시 짜지 않습니다. 각 파드 옆에 프록시를 두고 트래픽을 통과시킵니다. 컨트롤 플레인이 정책·인증서·텔레메트리를 뿌립니다. 기능은 트래픽 관리(카나리), 관측(분산 추적), 보안(mTLS), 탄력성(회로 차단)입니다. 외부 진입은 가 라우팅·인증·한도를 맡습니다.
| 비교축 | 모노리식 | MSA |
|---|---|---|
| 배포 | 통째 | 서비스 단위 |
| 확장 | 전체 | 기능별 |
| 데이터 | 공유 DB | 서비스별 DB |
| 장애 | 전파 | 격리 |
| 운영 | 단순 | 분산 복잡 |
| 적합 | 소규모·초기 | 큰 팀·높은 트래픽 |
성숙도 단계와 모듈러 모노리식
성숙은 모노리식 → → MSA입니다. 모듈러 모노리식은 배포는 하나, 내부 모듈 경계는 분명히 둡니다. MSA의 네트워크 비용을 치기 전에 경계를 학습합니다. 주문·결제·배송을 모듈로 나누고 DB는 당분간 같이 쓰는 과도기가 흔합니다.
실패는 팀이 작을 때의 조기 MSA, 도메인을 무시한 기술 중심 쪼개기입니다. 판단 기준은 대략 독립 배포가 필요해지거나 팀이 커져 병목이 보일 때입니다. ATAM으로 변경용이성 시나리오를 먼저 재고, 품질 게이트는 서비스 단위로 옮깁니다.
답안은 모노리식 한계 세 줄, 스트랭글러·DB per Service, 사이드카 네 기능, 모듈러 모노리식을 징검다리로 올립니다.