Service Mesh

Service Mesh가 뭔데

마이크로서비스 환경에서 서비스가 수십 개가 되면 서비스 간 통신이 복잡해진다. 각 서비스가 직접 다른 서비스를 호출하는데, 이때 문제가 생긴다.

• 어떤 서비스가 어디로 트래픽을 보내는지 보이지 않는다

• 서킷 브레이커, 재시도 로직을 서비스마다 따로 구현해야 한다

• 서비스 간 통신 암호화를 각자 처리해야 한다

  Service Mesh는 서비스 간 통신을 인프라 레벨에서 관리하는 것이다. 애플리케이션 코드를 건드리지 않고 트래픽 제어, 보안, 관찰을 한 곳에서 처리한다.

  ---

  Sidecar 패턴

  Service Mesh의 핵심 구조다. 각 서비스 옆에 Proxy(사이드카)를 붙여서 모든 네트워크 트래픽이 Proxy를 통하게 만든다.

  [서비스 A] → [Proxy A] → [Proxy B] → [서비스 B]

  서비스는 직접 통신하지 않는다. Proxy끼리 통신한다. 트래픽 제어, 로깅, 암호화가 전부 Proxy에서 처리된다.

  ---

  Control Plane / Data Plane

  구분	역할	도구
  Control Plane	정책을 전달하고 Proxy를 관리	Istio
  Data Plane	실제 트래픽을 처리하는 Proxy	Envoy

  Istio(Control Plane)가 Envoy(Data Plane)에게 지시하고, Envoy가 실제 트래픽을 처리한다. 지휘관과 병사 관계로 기억하면 편하다.

  ---

  Service Mesh가 제공하는 것

  트래픽 제어

• Canary 배포를 코드 없이 설정으로 처리한다

• 특정 헤더가 있는 요청만 새 버전으로 보낼 수 있다

• 요청 비율 기반으로 A/B 테스트가 가능하다

  Observability

• 서비스 간 모든 트래픽의 메트릭이 자동으로 수집된다

• 분산 트레이싱이 자동으로 적용된다

• 서비스 맵을 시각화한다

  보안 (mTLS)

• 서비스 간 통신을 자동으로 암호화한다

• 서비스 인증을 자동으로 처리한다

• 특정 서비스만 특정 서비스를 호출하도록 정책을 설정한다

  Resilience

• 서킷 브레이커를 코드 없이 설정으로 적용한다

• 재시도, Timeout을 인프라 레벨에서 처리한다

  ---

  대표 도구

  도구	설명
  Istio	가장 널리 쓰이는 Service Mesh, Control Plane
  Envoy	Istio의 Data Plane으로 쓰이는 고성능 Proxy
  Linkerd	경량 Service Mesh, 설정이 간단하다
  Consul Connect	HashiCorp의 Service Mesh

  ---

  SRE 관점에서 Service Mesh

  12주차에서 배운 Reliability Patterns (Circuit Breaker, Retry, Timeout)을 애플리케이션 코드 없이 인프라 레벨에서 적용할 수 있다. 각 서비스 개발자가 직접 구현하던 것을 플랫폼이
  처리해준다.

  결국 Service Mesh는 Platform Engineering과 연결된다. 개발자가 Reliability 코드를 직접 짜지 않아도 신뢰성 있는 서비스를 만들 수 있는 환경을 만드는 것이다.