181. 서비스 메시 (Service Mesh)

⚠️ 이 문서는 수백 개의 마이크로서비스(MSA)가 서로 거미줄처럼 통신하는 환경에서, 개발자가 각 서비스 코드 내부에 타임아웃, 재시도, 보안(mTLS) 로직을 일일이 짜넣는 대신, 모든 서비스 옆에 찰거머리처럼 붙어 통신을 대신해 주는 **인프라 계층의 프록시 네트워크인 '서비스 메시'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 애플리케이션의 '비즈니스 로직(코드)'과 '네트워킹 로직(통신, 보안, 모니터링)'을 완벽하게 분리하여, 네트워크 제어권을 인프라 관리자(플랫폼 팀)에게 넘겨주는 아키텍처 패턴이다.
  2. 가치: 개발팀이 A 서비스(Java)와 B 서비스(Go)를 만들 때 언어별로 통신/보안 라이브러리를 세팅할 필요 없이 오직 비즈니스 구현에만 집중할 수 있게 하며, 전사적인 보안 및 라우팅 정책을 클릭 한 번으로 모든 서비스에 일괄 적용할 수 있다.
  3. 기술 체계: 각 컨테이너(Pod) 안에 서비스와 함께 배포되는 **데이터 플레인(사이드카 프록시, 예: Envoy)**과, 이 프록시들에게 중앙에서 명령을 내리는 **컨트롤 플레인(예: Istio, Linkerd)**으로 구성된다.

Ⅰ. 스마트 엔드포인트의 한계 (Fat Client)

서비스 메시가 등장하기 전, MSA 통신은 개발자의 몫이었다.

  1. 스프링 클라우드 (Spring Cloud) 방식:
    • A 서비스가 B 서비스를 호출하려면, B가 다운되었을 때를 대비한 서킷 브레이커(Circuit Breaker), 재시도(Retry), 인증(Auth) 로직을 A 서비스의 '소스 코드' 안에 라이브러리(Netflix OSS 등) 형태로 직접 집어넣어야 했다 (Fat Client).
  2. 다국어 환경의 저주 (Polyglot Hell):
    • 회사가 커져서 Python이나 Node.js로 만든 C 서비스를 추가하려면, Spring 라이브러리를 쓸 수 없으므로 Python용, Node.js용 통신/보안 라이브러리를 일일이 새로 찾아서 구현해야 했다.
  3. 코드 중복과 강한 결합:
    • 네트워킹 정책이 바뀔 때마다 모든 마이크로서비스의 소스코드를 수정하고 다시 컴파일해서 재배포해야 하는 끔찍한 오버헤드가 발생했다.

📢 섹션 요약 비유: 각 부서의 직원(서비스)이 다른 부서와 연락할 때마다 본인이 직접 상대방의 전화번호를 찾고, 전화를 안 받으면 몇 분 뒤에 다시 걸지(재시도), 암호로 말할지(보안)를 스스로 고민하고 매뉴얼(코드)에 적어두어야 하는 피곤한 상황입니다.

Ⅱ. 사이드카 프록시(Sidecar Proxy)의 마법

서비스 메시는 이 네트워크 책임감을 앱 밖으로 끄집어낸다.

  1. 데이터 플레인 (Data Plane):
    • 애플리케이션 컨테이너가 배포될 때, 쿠버네티스가 그 옆에 몰래 짝꿍 컨테이너(Sidecar Proxy, 주로 Envoy)를 하나 더 붙여준다.
    • 앱은 외부로 직접 통신하지 못하고 오직 자기 옆의 사이드카에게만 "B 서비스에게 이 데이터 좀 전해줘"라고 평문(HTTP)으로 던진다.
  2. 프록시 간의 통신:
    • A의 사이드카는 B의 사이드카와 통신한다. 이때 사이드카들끼리 알아서 데이터를 암호화(mTLS)하고, B가 응답이 없으면 3번 재시도하며, 에러가 나면 모니터링 서버에 로그를 쏘는 모든 '네트워킹 궂은일'을 전담한다.
    • ┌────────────────────────────────────────────────────────┐ │ [Pod A] (비즈니스 앱) ---> (로컬통신) ---> [사이드카 프록시 A] │ │ ↓ (암호화된 mTLS 통신) │ │ [Pod B] (비즈니스 앱) <--- (로컬통신) <--- [사이드카 프록시 B] │ └────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 각 부서 직원 옆에 '전문 개인 비서(사이드카 프록시)'를 한 명씩 고용해 둔 것입니다. 직원은 비서에게 "저쪽 부서에 이 서류 좀 줘"라고만 하면 끝이고, 비서는 서류를 암호화 가방에 넣고 오토바이를 타고 가서 상대방 비서에게 전달한 뒤 결과를 보고합니다.

Ⅲ. 컨트롤 플레인 (Control Plane)과 Istio

수백 명의 비서(사이드카)를 어떻게 한 번에 통제할 것인가?

  1. 중앙 사령부 (Istio 등):
    • 서비스 메시는 '컨트롤 플레인'이라는 중앙 관리 서버를 둔다.
    • 관리자가 컨트롤 플레인에 "오늘부터 모든 통신은 mTLS 1.3으로 암호화하고, B 서비스로 가는 트래픽의 10%만 V2 버전으로 흘려보내(카나리 배포)"라고 정책을 입력한다.
  2. 동적 정책 주입:
    • 컨트롤 플레인은 이 정책을 각 Pod에 흩어져 있는 수백 개의 사이드카 프록시들에게 실시간으로 쫙 뿌려준다(동기화).
    • 앱 소스코드를 단 한 줄도 건드리지 않고, 재배포 없이 시스템 전체의 네트워크와 보안 정책이 일순간에 변경된다.
  3. 가시성 (Observability) 확보:
    • 모든 트래픽이 프록시를 거치므로, 컨트롤 플레인은 "어느 서비스 간의 통신이 가장 느린지, 에러가 어디서 났는지"를 거미줄 모양의 시각적 대시보드(Kiali 등)로 완벽하게 그려낼 수 있다.

📢 섹션 요약 비유: 개인 비서들이 각자 제멋대로 일하는 것이 아니라, 중앙 비서실장(컨트롤 플레인)이 이어폰으로 "지금부터 비밀 통신 규격 2단계로 올려"라고 명령하면 100명의 비서가 일제히 행동 방식을 바꾸는 완벽한 중앙 통제 시스템입니다.