Service Mesh

Service Mesh(서비스 메시)는 마이크로서비스 간의 네트워크 통신을 관리하는 인프라 계층입니다. 애플리케이션 코드 수정 없이 서비스 간 트래픽 관리, 보안, 관측성을 제공하여 마이크로서비스 아키텍처의 복잡성을 해결합니다.

Service Mesh는 주로 사이드카 패턴을 사용하여 각 서비스 Pod에 프록시(예: Envoy)를 배치합니다. 이 프록시가 모든 인바운드/아웃바운드 트래픽을 가로채서 라우팅, 로드밸런싱, mTLS 암호화, 서킷 브레이커, 재시도 로직 등을 처리합니다. 대표적인 구현체로 Istio, Linkerd, Consul Connect가 있으며, 각각 기능성, 단순성, 멀티 클라우드 지원에 강점이 있습니다.

Istio VirtualService - 트래픽 라우팅

# virtualservice.yaml - 카나리 배포 트래픽 분할
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
    retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 10s
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: product-service
  namespace: production
spec:
  host: product-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Istio mTLS 설정

# peer-authentication.yaml - 서비스 간 mTLS 강제
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
# authorization-policy.yaml - 세밀한 접근 제어
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: product-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: product-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - "cluster.local/ns/production/sa/order-service"
        - "cluster.local/ns/production/sa/cart-service"
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/products/*"]

• 복잡성 증가: Service Mesh는 강력하지만 복잡합니다. 소규모 팀이나 간단한 아키텍처에서는 오버엔지니어링일 수 있습니다.
• 리소스 오버헤드: 각 Pod에 사이드카가 추가되므로 클러스터 리소스 사용량이 증가합니다. Pod당 CPU 100m, 메모리 128MB 정도를 계획하세요.
• 디버깅 복잡도: 문제 발생 시 애플리케이션, 사이드카, 컨트롤 플레인 모두를 확인해야 합니다. 충분한 관측성 도구가 필요합니다.
• 버전 호환성: Istio와 Kubernetes 버전 간 호환성을 확인하세요. 업그레이드 시 주의가 필요합니다.
• 점진적 도입: 처음부터 모든 기능을 활성화하지 말고, mTLS부터 시작해서 점진적으로 기능을 추가하세요.

• Istio - 가장 널리 사용되는 Service Mesh 구현체
• Linkerd - 경량화된 Service Mesh
• Envoy - Service Mesh의 데이터 플레인 프록시
• Kubernetes - Service Mesh의 기반 플랫폼
• Observability - Service Mesh가 제공하는 핵심 기능

• Istio Documentation - 공식 문서
• Linkerd Documentation - 경량 Service Mesh 가이드
• Envoy Proxy - 데이터 플레인 프록시 문서