Categories: 정보관리기술사

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

Table of Contents

Toggle

제134회 정보관리기술사 3교시 2번 | 서비스 메시(Service Mesh)와 Istio

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

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을 고려합니다.

zerg96