[요약] Part 3. 실전 마이크로서비스 도입과 운영 원칙

마이크로서비스 전환을 결정짓는 진짜 기준

단순한 기술적 호기심이나 무조건적인 트래픽 증가만으로는 서비스를 분리할 이유가 부족합니다. 아키텍처 전환은 조직의 한계와 시스템의 생존을 위한 필수적인 선택일 때 이루어져야 합니다.

• 자원 격리의 필요성
• 특정 기능(예: 이미지 처리, 대규모 데이터 집계)이 CPU나 메모리를 독식하여 시스템 전체를 느리게 만들 때
• 하나의 기능 장애가 스레드를 고갈시켜 전혀 관계없는 기능까지 함께 다운되는 현상이 빈번할 때
• 독립적인 배포와 조직 규모
• 개발팀이 쪼개지면서 서로의 코드 병합과 배포 일정이 충돌하여 병목 현상이 발생할 때
• 특정 서비스만 하루에 수십 번씩 독립적으로 빠르고 안전하게 배포해야 할 때
• 이질적인 기술 스택의 통합
• 기존 레거시 시스템의 언어(예: Java)와 완전히 다른 생태계(예: Python AI 모델)를 효율적으로 통합해야 할 때

분산 환경의 생존 기술: 서킷 브레이커

네트워크는 절대 신뢰할 수 없습니다. 서비스 간 통신 장애는 언제든 발생할 수 있으며, 이를 방어하지 못하면 도미노처럼 전체 시스템이 붕괴됩니다.

• 연쇄 장애(Cascading Failure) 방어
• 타겟 서비스가 죽었을 때 무한정 기다리지 않고 즉시 연결을 끊어버리는 '두꺼비집' 역할
• 우리 서비스의 스레드 고갈을 막아 최소한의 핵심 기능은 살아있게 유지함
• 상태 전이 메커니즘
• Closed (정상): 평소처럼 통신을 허용
• Open (차단): 임계치 이상의 에러 발생 시 즉시 통신을 차단하고 빠른 실패(Fail-Fast) 반환
• Half-Open (반열림): 일정 시간 후 일부 트래픽만 흘려보내 복구 여부를 테스트
• 우아한 실패 처리 (Fallback)
• 에러 화면을 노출하는 대신, 캐시된 과거 데이터를 보여주거나 작업을 세션에 저장하는 등 플랜 B를 실행

미로 속의 디버깅: 분산 로그 추적

수많은 서비스로 쪼개진 환경에서는 에러의 근원지를 찾는 것이 가장 고통스러운 작업입니다.

• Trace ID를 통한 요청의 연결
• 사용자의 첫 진입점(Gateway)에서 고유한 꼬리표(Trace ID)를 발급
• 서비스들이 서로 API를 호출할 때 HTTP 헤더 등에 이 ID를 담아 전파(Propagation)
• 모든 로그에 Trace ID를 남겨, 나중에 엘라스틱서치나 Datadog 등에서 한 번에 묶어 검색
• Span ID를 통한 병목 구간 파악
• 각 서비스 내부의 작업 단위마다 Span ID를 부여하여 폭포수 차트로 시각화
• 어떤 서비스의 어느 로직(예: DB 쿼리)에서 시간이 지연되었는지 정확히 타겟팅 가능

파편화된 환경의 안전한 배포 전략

여러 팀이 수십 개의 서비스를 독립적으로 배포하는 환경에서는 배포 자체가 큰 리스크가 될 수 있습니다.

• 하위 호환성(Backward Compatibility) 절대 준수
• 내가 만든 API의 응답 구조나 파라미터를 변경하여 호출하는 다른 서비스를 망가뜨리지 말 것
• 스키마 변경 시 필드 삭제나 타입 변경은 지양하고, 버전업을 명시적으로 진행할 것
• 점진적이고 안전한 배포 방식
• 블루-그린 (Blue-Green): 신버전(Green)을 대기시켜 놓고 트래픽을 한 번에 전환하여 롤백을 1초 만에 가능하게 함
• 카나리 배포 (Canary Release): 1%, 5% 등 소수의 트래픽만 먼저 흘려보내 안전성을 검증한 후 트래픽을 늘림
• 컨테이너(Docker)를 통한 환경 통일
• 코드와 실행 환경(OS, 라이브러리)을 하나의 상자(Image)로 묶어 어디서나 동일하게 동작하도록 보장