제134회 정보관리기술사 3교시 2번 — 서비스 메시(Service Mesh)와 Istio 사이드카 패턴

by

마이크로서비스 아키텍처에서 서비스 간 통신 복잡성(관찰가능성·보안·트래픽 제어)을 애플리케이션 코드 변경 없이 인프라 수준에서 처리하는 서비스 메시가 표준 패턴으로 자리 잡고 있습니다.

1. 서비스 메시 개념 및 필요성

1-1. 마이크로서비스 통신 문제

  • 분산 추적 어려움: 수십~수백 서비스 간 요청 흐름 파악 불가
  • 서비스 간 mTLS: 상호 인증 암호화를 각 서비스가 직접 구현해야 함
  • 부하 분산·재시도: 서킷 브레이커·타임아웃을 애플리케이션마다 중복 구현
  • 카나리/블루-그린 배포: 트래픽 가중치 조절 로직을 코드에 포함

2. 서비스 메시 핵심 아키텍처

2-1. 사이드카 패턴(Sidecar Pattern)

각 Pod에 Envoy Proxy 컨테이너를 사이드카로 자동 주입(Auto-Injection)합니다.
모든 인바운드·아웃바운드 트래픽은 Envoy를 통과하므로 애플리케이션 코드는 변경 없이
통신 제어·관찰·보안 기능이 투명하게 적용됩니다.

2-2. Istio 핵심 컴포넌트

컴포넌트 역할 비고
istiod 컨트롤 플레인 통합 — Pilot+Citadel+Galley Istio 1.5+에서 단일 프로세스로 통합
Pilot Envoy에 라우팅·부하분산 정책 배포(xDS 프로토콜) 서비스 디스커버리 연동
Citadel mTLS 인증서 발급·관리(SPIFFE/SVID) 서비스 간 Zero Trust 인증
Envoy Proxy 데이터 플레인 — 실제 트래픽 처리 L4/L7 프록시, 사이드카로 주입
Ingress/Egress GW 클러스터 경계 트래픽 제어 외부 트래픽 진입·이탈 관리

3. 주요 기능

3-1. 트래픽 관리

기능 Istio 리소스 설명
라우팅 규칙 VirtualService URL 경로·헤더 기반 라우팅, 가중치 분할
대상 정책 DestinationRule 부하 분산 알고리즘, 서킷 브레이커, TLS 설정
게이트웨이 Gateway 클러스터 경계 포트·프로토콜 정의
서비스 항목 ServiceEntry 외부 서비스(Egress) 등록·제어

3-2. 관찰가능성(Observability)

  • 메트릭: Envoy가 Prometheus 형식 메트릭 자동 노출 → Grafana 시각화
  • 분산 추적: Jaeger/Zipkin 연동으로 서비스 간 요청 추적(Trace ID·Span)
  • 접근 로그: Envoy 액세스 로그 → ELK 스택 수집

3-3. 보안(mTLS)

SPIFFE(Secure Production Identity Framework): 서비스 간 암호화 신원 부여
PeerAuthentication: mTLS 모드 설정 (STRICT/PERMISSIVE/DISABLE)
AuthorizationPolicy: L7 RBAC — 특정 서비스만 특정 경로에 접근 허용

4. 서비스 메시 비교

구분 Istio Linkerd Consul Connect
데이터 플레인 Envoy(C++) Linkerd-proxy(Rust) Envoy
성능 오버헤드 중간 낮음 중간
기능 풍부도 최고 중간 높음
운영 복잡도 높음 낮음 중간
멀티클러스터 지원 지원 강력 지원

5. 결론

서비스 메시는 마이크로서비스의 ‘운영 복잡성’을 인프라 계층으로 이동시켜 개발자 부담을 줄이는 플랫폼 엔지니어링의 핵심 구성 요소입니다. Istio는 기능이 가장 풍부하지만 운영 복잡도가 높으므로, 단순 환경에서는 Linkerd를, 다중 클러스터·멀티클라우드에서는 Consul을 고려합니다.

Leave a Comment