단일 어플리케이션 분할 시점: 수술적 분리의 예술

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

소프트웨어 개발자 및 DevOps 엔지니어

• *난이도**: 중급(모놀리즘 아키텍처 이해 필요)

핵심 요약

• 모놀리즘 분할 시점 : 테스트 시간이 45분 이상, 배포 시 전역 영향 발생, 팀 간 협업 장애 발생 시 분할 고려
• DDD 기반 분리 패턴 : User 모델을 Identity Service, Billing Service, User Profiles Service로 분리
• 도구 활용 : nginx (라우팅), delegate (레이지 분리), Rails Event Store (이벤트 기반 분리)
• 핵심 원칙 : "분할의 고통 < 유지의 고통" 시 분할 실행

섹션별 세부 요약

1. 모놀리즘 분할의 필수 조건

• 문제 사례
• 테스트 스위트 실행 시간 45분 이상
• 배포 시 전역 영향 발생 (예: Jenga 게임 유사)
• 팀 간 마이그레이션 충돌 (예: 인벤토리 테이블 변경 시 주문 팀 영향)
• 분리 기준
• 단일 테이블이 CPU 사용량의 80% 차지
• 외부 API (Stripe, Twilio 등) 직접 호출로 인한 전역 업데이트 필요

2. 서비스 분리 전략

• DDD 기반 분리
• User 모델을 Identity Service, Billing Service, User Profiles Service로 분리 (예: Authentication, Subscriptions, Avatars)
• 팀 경계 기반 분리 (Conway’s Law)
• 팀 A의 "Orders"와 팀 B의 "Inventory" 변경으로 인한 충돌 시 분리
• 외부 파트너 API 통합
• Stripe, Twilio 등 외부 API 호출을 Partner Gateway Service로 통합

3. 분리 실행 단계

• 단계 1: 프록시 라우팅
• /api/v2/orders 라우팅을 새 Orders Service로 전달 (예: nginx 사용)
• 단계 2: 데이터 동기화
• 이벤트 스트리밍 (Kafka) 또는 DB 트리거로 데이터 동기화
• 단계 3: 오래된 경로 폐기
• /api/v1/orders 경로가 v2 정상 작동 시 폐기

4. 분리 시 도구 활용

• 내부 서비스 개발
• delegate gem으로 레이지 분리 구현 (예: PaymentService.new.process(order: self))
• 이벤트 기반 분리
• Rails Event Store로 이벤트 기반 분리 (예: OrderCreatedHandler 클래스 생성)

5. 분리 시 주의 사항

• 미세 서비스 트렌드에 휘둘리지 않기
• DevOps 인프라 (컨테이너 오케스트레이션) 미비 시 분할 자제
• 단순 도메인 (예: 10개 모델 SaaS)은 분할 필요 없음
• 분리 전 체크리스트
• Observability: OpenTelemetry로 서비스 간 호출 추적
• 테스트: Pact (계약 테스트), Gremlin (장애 시뮬레이션)

결론

• 하나의 서비스 분리로도 성과 가능 : 결제 서비스 분리로 팀 배포 속도 향상, 장애 고립, 기술 유연성 확보
• 관찰 → 분리 → 테스트 순서 : OpenTelemetry, Pact, Gremlin 도구 활용하여 안정적 분리 구현
• 핵심 원칙 : "분할의 고통 < 유지의 고통" 시 분할 실행 (예: Identity Service 분리 후 테스트 시간 단축)