🔧
DevOps
Istio
Istio
서비스 메시 플랫폼. 트래픽 관리, 보안, 관찰성 제공.
상세 설명
Istio는 마이크로서비스 아키텍처에서 서비스 간 통신을 관리하는 서비스 메시 플랫폼입니다. Envoy 프록시를 사이드카로 주입하여 애플리케이션 코드 변경 없이 트래픽 제어, 보안, 관찰성 기능을 제공합니다. Google, IBM, Lyft가 공동 개발했으며, 현재 CNCF 졸업 프로젝트입니다.
Istio의 핵심 기능은 트래픽 관리입니다. VirtualService와 DestinationRule을 통해 A/B 테스팅, 카나리 배포, 트래픽 미러링, 서킷 브레이커 패턴을 선언적으로 구성할 수 있습니다. 복잡한 라우팅 규칙도 YAML 설정만으로 적용됩니다.
보안 측면에서 Istio는 mTLS(상호 TLS)를 자동으로 적용하여 서비스 간 통신을 암호화합니다. RBAC 정책으로 세밀한 접근 제어가 가능하며, JWT 검증 등 인증/인가 기능도 제공합니다. 보안 정책이 인프라 레벨에서 적용되므로 개발자는 비즈니스 로직에 집중할 수 있습니다.
관찰성 기능으로는 Prometheus 메트릭 자동 수집, Jaeger/Zipkin 분산 트레이싱 연동, Kiali 서비스 그래프 시각화를 지원합니다. 운영 환경에서 Istio는 복잡성을 추가하지만, 50개 이상의 마이크로서비스를 운영할 때 그 가치가 빛납니다.
코드 예제
# VirtualService - 카나리 배포 설정
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: product-service
namespace: production
spec:
hosts:
- product-service
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: product-service
subset: v2
- route:
- destination:
host: product-service
subset: v1
weight: 90
- destination:
host: product-service
subset: v2
weight: 10
---
# DestinationRule - 서킷 브레이커 설정
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: product-service
spec:
host: product-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: UPGRADE
http1MaxPendingRequests: 100
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 60s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2실무에서 이렇게 말해요
팀장: "이번 결제 서비스 신버전 배포, Istio로 카나리 어떻게 진행할까요?"
개발자: "먼저 5%만 v2로 라우팅하고, Kiali에서 에러율 모니터링하면서 점진적으로 올리려고 합니다."
팀장: "좋아요. 그리고 서킷 브레이커 설정 확인하셨죠? 지난번에 연쇄 장애 났던 거 기억하시잖아요."
개발자: "네, outlierDetection에 5xx 에러 5회 연속 발생 시 60초 차단으로 설정했습니다."
면접관: "Istio 없이도 로드밸런싱은 가능한데, 굳이 서비스 메시를 도입하는 이유가 뭘까요?"
지원자: "애플리케이션 코드 변경 없이 트래픽 제어가 가능하고, mTLS 같은 보안 정책을 인프라 레벨에서 일관되게 적용할 수 있습니다. 특히 분산 트레이싱이 자동으로 연동되어 마이크로서비스 디버깅이 훨씬 수월해집니다."
리뷰어: "VirtualService에 timeout 설정이 없네요. downstream 서비스 지연 시 연쇄적으로 영향받을 수 있어요."
개발자: "아, 맞습니다. http route에 timeout: 3s 추가하고, retry도 attempts: 3으로 설정하겠습니다."
주의사항
- 사이드카 프록시로 인한 레이턴시 오버헤드(1-5ms)와 메모리 사용량(약 50MB/pod) 증가를 고려해야 합니다
- istiod 컨트롤 플레인 장애 시 새로운 설정 적용이 불가능합니다. HA 구성(최소 2개 replica)이 필수입니다
- 작은 규모(10개 미만 서비스)에서는 Istio 복잡성이 오히려 부담이 됩니다. Linkerd나 단순 Ingress부터 시작하세요