Service Mesh

서비스 메시 (Service Mesh)

서비스 메시 (Service Mesh) 는 마이크로서비스 간 통신을 자동화되고 일관되게 처리하는 인프라레이어이다. 각 서비스에 사이드카 프록시를 연결해 트래픽 라우팅, 로드 밸런싱, mTLS 기반 보안, 리트라이·서킷 브레이커, 분산추적·메트릭 수집 등의 기능을 비즈니스 코드에서 분리해 제공한다. 제어 평면 (Control Plane) 은 정책을 중앙에서 설정하며, 데이터 평면 (Data Plane) 은 사이드카를 통해 실제 플로우를 처리한다. Istio, Linkerd, Consul, Cilium 등이 대표 솔루션이다.

등장 배경 및 발전 과정

클라우드 네이티브 환경에서 마이크로서비스가 확산되면서, 서비스 간 통신 관리의 복잡성, 보안, 관찰성이 문제가 되었다.

초기에는 애플리케이션 코드에 통신 로직 (재시도, TLS, 라우팅 등) 을 직접 구현하거나, 라이브러리 (API Gateway 나 SDK) 로 해결했지만, 이는 언어·프레임워크 종속, 운영 복잡성 증가 등의 한계가 있었다.

마이크로서비스는 수백~수천 개의 독립 컴포넌트로 구성되고, 새로운 네트워크 요구사항이 지속적으로 등장함에 따라 이러한 문제를 해결하기 위한 인프라 기반의 네트워크 계층이 필요해졌다.

• 서비스 간 통신 복잡성 증가: 수십, 수백 개의 서비스가 네트워크를 통해 통신
• 운영 복잡성: 각 서비스별로 로깅, 모니터링, 보안 구현 필요
• 네트워크 신뢰성 문제: 분산 환경에서의 장애 전파 및 복구 어려움
• 보안 관리 어려움: 서비스별 개별 보안 구현의 일관성 부족

이러한 문제들로 2010 년대 후반 Netflix, Google, Lyft 등이 대규모 마이크로서비스 환경에서 겪은 통신 복잡성 문제를 해결하기 위해 개발되었다.

발전 단계:

1. 1 세대 (2016-2017): Linkerd 1.x, Envoy Proxy 등장
2. 2 세대 (2017-2019): Istio, Linkerd 2.x 출시, CNCF 프로젝트화
3. 3 세대 (2019- 현재): 성능 최적화, 간소화, 멀티 클러스터 지원

목적 및 필요성

목적 (Purpose)

필요성 (Need)

핵심 개념

서비스 메시는 마이크로서비스 아키텍처에서 서비스 간 통신을 처리하는 전용 인프라 레이어이다. 애플리케이션 계층과 분리되어 네트워크 통신의 복잡성을 추상화한다.

기본 개념

실무 구현 연관성

기술적으로 검토된 적합성

주요 기능 및 역할

핵심 기능 (Key Functional Capabilities)

핵심 역할 (Operational Roles)

요약 정리

특징

기술적 검토 요약

통합 요약

핵심 원칙

기술적 검토 및 타당성 분석

요약 정리

주요 원리

• 프록시 기반 통신: 각 서비스에 사이드카 프록시 배치, 모든 트래픽을 프록시가 처리.
• 정책 기반 관리: 컨트롤 플레인에서 정책을 정의, 데이터 플레인에 적용.
• 분산 추적 및 모니터링: 모든 트래픽을 관찰 가능하게 함.

flowchart TB
    subgraph "Service A Pod"
        SA[Service A]
        PA[Sidecar Proxy A]
    end

    subgraph "Service B Pod"
        SB[Service B]
        PB[Sidecar Proxy B]
    end

    subgraph "Control Plane"
        CP["Control Plane (Istiod)"]
        CFG["Config API (CRDs)"]
    end

    subgraph "Observability Systems"
        MET[Prometheus / Grafana]
        TRACE[Jaeger / Zipkin]
    end

    SA --> PA
    PA --> PB
    PB --> SB

    CFG --> CP
    CP --> PA
    CP --> PB

    PA --> MET
    PB --> MET
    PA --> TRACE
    PB --> TRACE

• ControlPlane 은 정책/설정을 프록시에 전달
• App1 에서 App2 로의 모든 네트워크 요청은 각각의 사이드카를 통해 제어/관찰/정책 적용됨

작동 흐름

sequenceDiagram
    participant Client as 클라이언트
    participant ProxyA as Service A Proxy
    participant ServiceA as Service A
    participant ProxyB as Service B Proxy
    participant ServiceB as Service B
    participant Control as 컨트롤 플레인

    Control->>ProxyA: 정책 및 라우팅 규칙 배포
    Control->>ProxyB: 정책 및 라우팅 규칙 배포
    
    Client->>ProxyA: 요청
    ProxyA->>ProxyA: 인증, 권한 확인
    ProxyA->>ServiceA: 요청 전달
    ServiceA->>ProxyA: 응답
    ProxyA->>ProxyB: Service B 호출
    ProxyB->>ProxyB: 보안 정책 적용
    ProxyB->>ServiceB: 요청 전달
    ServiceB->>ProxyB: 응답
    ProxyB->>ProxyA: 응답
    ProxyA->>Client: 최종 응답
    
    ProxyA->>Control: 텔레메트리 데이터
    ProxyB->>Control: 텔레메트리 데이터

• 각 서비스에 사이드카 (프록시) 가 삽입되고, 모든 통신은 사이드카를 통해 흐름 제어됨
• 제어 플레인 (Control Plane) 이 정책 및 설정을 사이드카에 전달

구조 및 아키텍처

flowchart TB
    subgraph "User"
        U[External Client]
    end

    subgraph "Kubernetes Cluster"
        subgraph "Ingress"
            GW["Ingress Gateway<br/>(Deployment + Service)"]
        end

        subgraph "Application Pods"
            APP1["Order Service Pod<br/>(App + Envoy Sidecar)"]
            APP2["Payment Service Pod<br/>(App + Envoy Sidecar)"]
        end

        subgraph "Control Plane (istio-system)"
            CP1["Pilot (xDS)"]
            CP2["Citadel (mTLS)"]
            CP3["Telemetry (Prometheus Hook)"]
        end

        subgraph "Management Plane (Optional)"
            MGMT["Gloo / Tetrate / Mesh Hub"]
        end
    end

    U --> GW
    GW --> APP1
    GW --> APP2

    CP1 -.-> APP1
    CP1 -.-> APP2
    CP2 -.-> APP1
    CP2 -.-> APP2
    CP3 -.-> APP1
    CP3 -.-> APP2

    MGMT -.-> CP1
    MGMT -.-> CP2
    MGMT -.-> CP3

• APP1, APP2: 각각의 서비스에 사이드카 프록시가 주입된 Pod
• Ingress Gateway: 외부 요청 진입점 (Istio 에서 일반적으로 istio-ingressgateway)
• Control Plane: Istio 의 핵심 컴포넌트들 (Pilot, Citadel, Telemetry, Injector 등)
• Management Plane: Istio 에는 기본적으로 없지만, Tetrate, Gloo Mesh 등 외부 솔루션에서 제공됨

구성 요소

• 데이터 플레인과 컨트롤 플레인은 모든 Service Mesh 에서 반드시 필요.
• 관리 플레인은 멀티 클러스터 운영이나 엔터프라이즈급 통합 관리에 필요하며, 운영 도구 (예: Tetrate, Gloo Mesh) 가 이를 담당.
• 게이트웨이는 외부 연동 시점에서 Ingress/Egress 트래픽을 통제하며, 인증서 관리와 고급 라우팅 기능까지 포함됨.

Service Mesh 구성요소 ↔ Kubernetes 리소스 매핑표

구현 기법

요약 정리

사이드카 기반 구성 (Sidecar-Based Service Mesh)

flowchart TD
    Client[Client]
    subgraph Pod A
        AppA[App A]
        ProxyA[Envoy Proxy A]
    end
    subgraph Pod B
        AppB[App B]
        ProxyB[Envoy Proxy B]
    end

    Client -->|Request| ProxyA --> AppA
    AppA --> ProxyA -->|Call Service B| ProxyB --> AppB
    AppB --> ProxyB -->|Response| ProxyA --> AppA --> ProxyA -->|Response| Client

YAML 예시 (Istio 기반)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

# 1. 서비스 A
apiVersion: v1
kind: Service
metadata:
  name: service-a
spec:
  selector:
    app: service-a
  ports:
    - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-a
  template:
    metadata:
      labels:
        app: service-a
        istio-injection: enabled
    spec:
      containers:
        - name: app-a
          image: your-org/service-a
          ports:
            - containerPort: 8080

# 2. 서비스 B
---
apiVersion: v1
kind: Service
metadata:
  name: service-b
spec:
  selector:
    app: service-b
  ports:
    - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-b
  template:
    metadata:
      labels:
        app: service-b
        istio-injection: enabled
    spec:
      containers:
        - name: app-b
          image: your-org/service-b
          ports:
            - containerPort: 8080

노드 기반 구성 (Ambient Mesh / 사이드카리스)

flowchart TD
    Client[Client]
    subgraph Node
        ProxyN["Ztunnel (Node Proxy)"]
        AppA[App A Pod]
        AppB[App B Pod]
    end

    Client -->|Request| ProxyN --> AppA
    AppA --> ProxyN --> AppB
    AppB --> ProxyN --> AppA --> ProxyN -->|Response| Client

YAML 예시 (Istio Ambient Mesh 기반 예시)

• Ambient Mesh 는 Istio 1.18+ 에서 사용 가능하며, ztunnel 데몬셋으로 노드 프록시 구성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# Ambient Mode 활성화용 네임스페이스 라벨
kubectl label namespace default istio.io/dataplane-mode=ambient

# 서비스 A/B는 일반 Pod로 배포 (사이드카 없이)
apiVersion: v1
kind: Service
metadata:
  name: service-a
spec:
  selector:
    app: service-a
  ports:
    - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-a
  template:
    metadata:
      labels:
        app: service-a
    spec:
      containers:
        - name: app-a
          image: your-org/service-a
          ports:
            - containerPort: 8080

• ztunnel 및 waypoint-proxy 는 Istio 설치 시 자동 구성됨

프록시리스 구성 (Proxy-less / gRPC xDS 방식)

flowchart TD
    Client[Client gRPC Stub]
    AppA["App A (gRPC xDS Client)"]
    AppB["App B (gRPC Server)"]

    Client -->|gRPC Call| AppA -->|Direct gRPC| AppB -->|Response| AppA --> Client

YAML 예시 (프록시 없는 앱 직접 xDS 처리)

• gRPC xDS 라이브러리를 내장한 앱으로 구성하며, 별도의 Envoy 가 없음

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grpc-xds-app-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grpc-xds-a
  template:
    metadata:
      labels:
        app: grpc-xds-a
    spec:
      containers:
        - name: grpc-app
          image: your-org/grpc-xds-client
          ports:
            - containerPort: 50051
---
apiVersion: v1
kind: Service
metadata:
  name: grpc-xds-app-a
spec:
  selector:
    app: grpc-xds-a
  ports:
    - port: 80
      targetPort: 50051

• 앱 내부에서 grpc-xds 라이브러리를 통해 Control Plane 과 xDS 직접 통신

확장/표준화 인터페이스 구성 (SMI 기반)

flowchart TD
    Client[Client]
    AppA[Service A]
    AppB[Service B]
    TrafficPolicy[TrafficTarget + HTTPRoute]

    Client --> AppA -->|→ SMI 정책 참조| TrafficPolicy -.-> AppB
    AppB --> AppA --> Client

YAML 예시 (SMI 표준 적용)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# HTTPRouteGroup 정의
apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: http-route
spec:
  matches:
    - name: all
      pathRegex: ".*"
      methods: ["*"]

# TrafficTarget 정의 (A → B 허용)
---
apiVersion: access.smi-spec.io/v1alpha3
kind: TrafficTarget
metadata:
  name: a-to-b
spec:
  destination:
    kind: ServiceAccount
    name: service-b
    namespace: default
  sources:
    - kind: ServiceAccount
      name: service-a
      namespace: default
  rules:
    - kind: HTTPRouteGroup
      name: http-route
      matches:
        - all

• Consul, Linkerd 등에서 사용 가능하며, SMI 는 CRD 로 구성되어 확장성이 뛰어남.

장점

요약 정리

단점과 문제점 그리고 해결방안

단점

• 운영 복잡성과 성능 이슈가 주요 핵심 단점.
• 사이드카 구조 자체의 한계 (리소스 소비, 디버깅 어려움 등) 가 중심.
• eBPF, ambient mesh, 자동화 도구 등으로 완화 가능.

문제점

• 프록시 장애, 정책 오류, 제어 플레인 불안정이 주요 원인.
• 특히 mTLS 인증서 만료, 트래픽 병목, 장애 전파는 실무에서 자주 발생.
• CI 기반 자동 검증, Canary 배포, 서킷브레이커 등 실질적인 대응 전략 중요.

도전 과제

요약 정리

도전 과제별 실제 사례 아키텍처

Pinterest - 사이드카 오버헤드 → Ambient Mesh 전환

사례:

• Pinterest 는 Istio 사이드카 프록시로 인해 서비스 호출 지연이 평균 12% 증가함.
• 대규모 트래픽 발생 시 CPU/메모리 급상승 문제 발생

대응 전략/해결 방법:

• Ambient Mesh PoC 도입하여 TCP-only 서비스에 사이드카 제거.
• 프록시 리소스 20~30% 절감

flowchart TD
  subgraph Legacy_Sidecar
    A1[App A] --> A2[Envoy Proxy]
    B1[App B] --> B2[Envoy Proxy]
    A2 -->|mTLS| MeshNet
    B2 -->|mTLS| MeshNet
  end

  subgraph Ambient_Mesh
    A3[App A] --> MeshTunnel
    B3[App B] --> MeshTunnel
    MeshTunnel --> MeshNet
  end

  style Legacy_Sidecar fill:#fff5f5,stroke:#f66
  style Ambient_Mesh fill:#f5fff5,stroke:#6f6

전환 효과: 사이드카 제거 → CPU 사용량 30% 감소, 네트워크 RTT 10% 단축

T-Mobile - Multi-cluster 메시 연합 구성

사례:

• T-Mobile 은 4 개 이상의 K8s 클러스터를 연합 구성하여 운영 중, Istio 에서 클러스터 간 정책 불일치로 인한 트래픽 누락 현상 발생

대응 전략/해결 방법:

• Istio 의 Multi-primary 구성 + Gateway-based cross-cluster 설정을 통해 네임스페이스 격리 정책 통일

flowchart TD
  subgraph Cluster-A
    A1[Service A] --> A2[Ingress Gateway]
  end

  subgraph Cluster-B
    B1[Service B] --> B2[Ingress Gateway]
  end

  A2 <--> B2
  A2 --> CP1["Istiod (Primary)"]
  B2 --> CP2["Istiod (Remote)"]

  CP1 ---|Global Policies| CP2

Global Control Plane 연동을 통해 다중 클러스터 정책 동기화 달성

AutoTrader UK - 트레이싱 강화 (Kiali + OTEL)

사례:

• AutoTrader UK 는 서비스 간 예외 상황 발생 시 트래픽 경로가 사이드카 경유로 인해 trace 불완전, root cause 분석에 2 배 이상 시간 소요

대응 전략/해결 방법:

• Kiali + OpenTelemetry + Jaeger 를 통합하여 trace 흐름 시각화, alert 기반 전파 경로 추적 기능 도입

flowchart LR
  User --> Proxy1[Envoy A]
  Proxy1 --> App1[Service A]
  App1 --> Proxy2[Envoy B]
  Proxy2 --> App2[Service B]
  Proxy1 & Proxy2 --> OTEL[OpenTelemetry Collector]
  OTEL --> Jaeger["Jaeger (Tracing UI)"]
  OTEL --> Prom[Prometheus]
  Prom --> Grafana

  subgraph Visualization
    Jaeger --> Kiali
  end

장애 원인 트레이싱 소요 시간 60% 단축

Skyscanner - AWS App Mesh → SMI 기반 메시 전환

사례:

• Skyscanner 는 App Mesh 에서 AWS 종속 API 사용으로 인해 멀티 클라우드 이전 시 완전한 재설계 필요 상태 발생

대응 전략/해결 방법:

• SMI-compatible 메시 (Linkerd) 로 전환, Terraform 기반 클라우드 중립 구성을 병행

flowchart TD
  subgraph Vendor_Locked
    C1[Service A] --> C2[AWS App Mesh Proxy]
    C2 -->|AWS SDK/API 종속| AppMeshCP
  end

  subgraph SMI_Based
    D1[Service A] --> D2[Linkerd Proxy]
    D2 --> LinkerdCP[Linkerd Controller]
    LinkerdCP -->|SMI Policy| Kubernetes
  end

  style Vendor_Locked fill:#f9f0ff,stroke:#985eff
  style SMI_Based fill:#f0fff9,stroke:#58b68b

멀티클라우드 이전 시 설정 재사용률 80% 달성

도입 전략별 실패 사례 vs. 성공 사례 비교

Ambient Mode vs. Sidecar Mode 비교

• Ambient Mode는 운영 효율성과 리소스 절감에 강점을 가지며, 사이드카의 오버헤드를 제거함으로써 배포 복잡성과 비용을 줄일 수 있는 차세대 방식이다. 특히 대규모 클러스터나 점진적 메시 도입에 적합하다.
• Sidecar Mode는 정밀한 트래픽 제어와 보안 정책 적용에 강점을 가지며, 각 서비스 단위로 세밀한 설정과 확장 기능을 요구하는 환경에서 여전히 유효하다.

Service Mesh 기능 비교

선택 가이드 (Deployment Decision Guide)

적합 아키텍처 추천 (Architecture Use Cases)

분류 기준에 따른 종류 및 유형

요약 정리

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

요약 정리

최적화하기 위한 고려사항 및 주의할 점

요약 정리

실무 적용 예시

요약 정리

활용 사례

사례 1: Kubernetes 기반 대형 전자상거래 서비스에 Istio 도입

시나리오:

Kubernetes 기반 대형 전자상거래 서비스에 Istio 도입,

• 외부 (고객) 트래픽은 API Gateway 로,
• 내부 서비스간 트래픽은 Istio Service Mesh 가 mTLS 로 암호화, 장애 시 자동 재시도/우회,
• 관리자는 대시보드로 서비스 간 지연, 장애, 인증 상태를 시각적 모니터링

시스템 구성

flowchart LR
    User --> APIGW("API Gateway")
    APIGW --> S1["(Pod) Order Service\n+ Sidecar"]
    APIGW --> S2["(Pod) Product Service\n+ Sidecar"]
    APIGW --> S3["(Pod) Payment Service\n+ Sidecar"]
    
    S1 <--> S2
    S1 <--> S3
    
    ControlPlane("Istio Control Plane") -.-> S1
    ControlPlane -.-> S2
    ControlPlane -.-> S3

유무 비교:
Service Mesh 미사용 시: 각 서비스마다 인증/보안/장애처리 코드 내장 필요, 가시성/관리가 어려움
Service Mesh 도입 후: 인프라 계층 일원화 관리, 장애 복원, 실시간 시각화, 인증 자동화

구현 예시:

• YAML 선언식 구현 예시 (트래픽 라우팅 정책, Istio VirtualService)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# istio-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
  - product-service
  http:
  - route:
    - destination:
        host: product-service
        subset: v2
      weight: 80
    - destination:
        host: product-service
        subset: v1
      weight: 20

80% 는 새로운 v2, 20% 는 기존 v1 로 분할 배포 (카나리 배포 예시), 정책 선언만으로 운영 수준 트래픽 제어

사례 2: 멀티 클러스터 전자상거래 서비스

아키텍처 & Workflow:

graph LR
  subgraph Cluster-A
    SvcA1 --- SidecarA1
    SvcA2 --- SidecarA2
  end
  subgraph Cluster-B
    SvcB1 --- SidecarB1
  end
  SidecarA1 <--> SidecarB1
  ControlPlaneA & ControlPlaneB <--> SharedControlPlane

• Cluster A ↔ Cluster B 사이의 mTLS 통신
• Control Plane 은 공유 혹은 페더레이션 구조
• **서비스 간의 클러스터 간 호출이 정책적으로 허용됨

사용 목적: 데이터 지역성 유지 + 글로벌 트래픽 관리

장점: 클러스터 경계를 넘는 mTLS 보안 유지, 글로벌 정책 일관성

차이점: 메시 없이 서비스 간 직접 호출 시 보안·관찰성 미흡 → 메시 도입으로 정책 수준 통제 가능

구현 예시:

• Istio 멀티 클러스터 구성 주요 목표

• Istio 멀티 클러스터 설정 예시

  • ServiceEntry (Cluster A → Cluster B 서비스 호출 허용)

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

    apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: svc-b1-entry spec: hosts: - svc-b1.ecom-b.svc.cluster.local location: MESH_EXTERNAL ports: - number: 8080 name: http protocol: HTTP resolution: DNS addresses: - 240.0.0.1

    • 목적: Cluster-A 에서 Cluster-B 의 svc-b1 호출 가능하도록 설정.

  • DestinationRule (mTLS 설정 포함)

    1 2 3 4 5 6 7 8 9

    apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: svc-b1-dr spec: host: svc-b1.ecom-b.svc.cluster.local trafficPolicy: tls: mode: ISTIO_MUTUAL

    • 목적: Cluster A 의 Envoy 프록시가 Cluster B 로 mTLS로 통신하도록 지정.

  • VirtualService (Cluster A 에서 요청 라우팅)

    1 2 3 4 5 6 7 8 9 10 11 12 13

    apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: route-to-svc-b1 spec: hosts: - svc-b1.ecom-b.svc.cluster.local http: - route: - destination: host: svc-b1.ecom-b.svc.cluster.local port: number: 8080

    • 목적: Cluster A 의 요청을 Cluster B 의 서비스로 직접 라우팅.

  • PeerAuthentication (글로벌 mTLS 설정)

    1 2 3 4 5 6 7 8

    apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT

    • 목적: 모든 트래픽에 대해 mTLS 적용 강제화 (클러스터 간 포함)

  • Gateway 구성 (옵션: 멀티 클러스터 간 Ingress 연결 시)

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

    apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: cluster-b-gateway spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - svc-b1.ecom-b.svc.cluster.local tls: mode: ISTIO_MUTUAL credentialName: tls-secret

사례 3: 전자상거래 플랫폼의 서비스 메시 적용

전자상거래 플랫폼의 서비스 메시 적용

대규모 전자상거래 플랫폼에서 주문, 결제, 재고, 배송 등 다양한 마이크로서비스 간 통신을 관리하기 위해 Istio 서비스 메시를 도입한 사례입니다.

시스템 구성:

graph TB
    subgraph "External"
        USER[Users]
        API_GW[API Gateway]
    end
    
    subgraph "Service Mesh"
        subgraph "Frontend Services"
            WEB[Web Service]
            MOBILE[Mobile API]
        end
        
        subgraph "Business Services"
            ORDER[Order Service]
            PAYMENT[Payment Service]
            INVENTORY[Inventory Service]
            SHIPPING[Shipping Service]
        end
        
        subgraph "Data Services"
            USER_DB[(User DB)]
            ORDER_DB[(Order DB)]
            INVENTORY_DB[(Inventory DB)]
        end
    end
    
    subgraph "Istio Control Plane"
        PILOT[Pilot]
        CITADEL[Citadel]
        GALLEY[Galley]
    end
    
    USER --> API_GW
    API_GW --> WEB
    API_GW --> MOBILE
    
    WEB --> ORDER
    MOBILE --> ORDER
    ORDER --> PAYMENT
    ORDER --> INVENTORY
    ORDER --> SHIPPING
    
    ORDER --> ORDER_DB
    INVENTORY --> INVENTORY_DB

Workflow:

1. 사용자 요청이 API Gateway 를 통해 진입
2. Istio Envoy Proxy 가 모든 서비스 간 통신 가로채기
3. 트래픽 정책에 따라 라우팅 및 로드 밸런싱 수행
4. 상호 TLS 로 서비스 간 보안 통신 보장
5. 메트릭 및 추적 정보를 Prometheus, Jaeger 로 전송

서비스 메시의 역할:

• 결제 서비스의 카나리 배포를 통한 안전한 업데이트
• 재고 서비스 장애 시 자동 서킷 브레이커 동작
• 모든 서비스 간 통신에 대한 실시간 모니터링

서비스 메시 유무에 따른 차이점:

구현 예시:

• 카나리 배포: VirtualService + DestinationRule
  -> 결제 서비스 (Payment Service) 에 v1, v2 를 순차적으로 배포

  • 배포가 안정되면 v2 의 비중을 점차 늘려 전체 전환 가능.
  • DestinationRule

  1 2 3 4 5 6 7 8 9 10 11 12 13

  apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: payment-destination spec: host: payment subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

  • VirtualService

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: payment-route spec: hosts: - payment http: - route: - destination: host: payment subset: v1 weight: 90 - destination: host: payment subset: v2 weight: 10

• 서킷 브레이커: DestinationRule
  -> 재고 서비스 (INVENTORY) 가 장애 발생 시, 일정 시간 차단 및 자동 복구

  • 특정 횟수 이상 오류 발생 시 요청 차단 → 일정 시간 후 자동 복구

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

  apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: inventory-circuit-breaker spec: host: inventory trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 100

• mTLS 자동 적용: PeerAuthentication

  • 전체 네임스페이스에 대해 서비스 간 통신은 반드시 mTLS 로 수행하도록 강제.

  1 2 3 4 5 6 7 8

  apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT

• 트래픽 관찰성: Prometheus, Jaeger 연동

  • Istio 설치 시 기본적으로 아래 요소가 포함되며, 설정만 추가하면 됨:

    • Prometheus - 메트릭 수집 (istio-proxy 에서 지표 수집)
    • Grafana - 메트릭 시각화
    • Jaeger/Zipkin - 분산 추적 시각화
    • Kiali - 서비스 메시 구조 + 트래픽 흐름 시각화

  • 예시: Telemetry 설정

    1 2 3 4 5 6 7 8 9 10 11 12

    apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: default spec: metrics: overrides: - match: metric: request_duration_milliseconds enabled: true tracing: randomSamplingPercentage: 100.0

사례 4: Istio 기반 마이크로서비스 환경에서의 트래픽 관리 및 분산 트레이싱

시스템 구성: Kubernetes 클러스터 + Istio(서비스 메시) + Envoy(프록시) + Jaeger(분산 트레이싱)

워크플로우:

1. 클라이언트 → API Gateway → 서비스 A (사이드카 프록시)
2. 서비스 A → 서비스 B (프록시 간 통신)
3. 모든 트래픽은 Jaeger 에서 추적

역할: 트래픽 라우팅, 로드 밸런싱, 보안, 모니터링, 분산 트레이싱

차이점: 기존 라이브러리 기반 (Spring Cloud) 은 언어 종속적, 서비스 메시는 언어 독립적

구현 예시:

• 서비스 메시 자체는 인프라 계층이므로 코드 구현보다는 설정 예시를 제공합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Istio VirtualService 예시 (Kubernetes YAML)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
        subset: v1
      weight: 90
    - destination:
        host: my-service
        subset: v2
      weight: 10

사례 5: e‑commerce 플랫폼 안정성

목적: 블랙프라이데이 같이 트래픽 급증 시 서비스 안정성 확보

기술 스택: Kubernetes, Istio, Envoy

시스템 구성:

graph TD
  User --> IngressGW[Envoy Ingress Gateway]
  IngressGW --> svc-v1
  IngressGW --> svc-v2
  svc-v1[Checkout v1 + Envoy] --> svc-db
  svc-v2[Checkout v2 + Envoy] --> svc-db
  subgraph Control Plane
    Pilot
    Citadel
  end

Workflow:

1. Ingress Gateway 통해 외부 요청 수신
2. VirtualService 로 v2 버전 트래픽을 20% 할당
3. Pilot 이 VirtualService 설정을 각 Envoy 에 배포 (xDS)
4. 사이드카 Envoy 에서 Retry/Timeout/Circuit-Breaker 자동 적용
5. Citadel 이 mTLS 인증서 자동 할당 및 갱신
6. 정상 여부 모니터링, 성능 충족 시 점진적 v2 트래픽 증가

효과:

• 코드 변경 없이 레이어에서 안정성/보안 확보
• 실패 시 장애 스트래티징을 통한 롤백 우회
• 실무 대비 트래픽 제어 및 CNCF 준수 환경 제공

구현 예시:

• Python + Istio VirtualService (Canary 배포)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# virtualservice-canary.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: checkout-canary
spec:
  hosts:
    - checkout.example.com
  http:
    - route:
        - destination:
            host: checkout
            subset: v2
          weight: 20
        - destination:
            host: checkout
            subset: v1
          weight: 80
      retries:
        attempts: 3
        perTryTimeout: 2s
      fault:
        delay:
          percentage:
            value: 10
          fixedDelay: 1s

1
2
3
4
5
6
7
8
9

# deploy_canary.py
import subprocess

def apply(file):
    subprocess.run(["kubectl", "apply", "-f", file], check=True)

if __name__ == "__main__":
    apply("virtualservice-canary.yaml")
    print("Canary VirtualService deployed.")

• 이 코드와 YAML 은 20% v2, 80% v1 배포 리스크 완화
• Envoy 사이드카가 자동으로 retries, timeout, fault injection 정책 집행

주목할 내용

• 아키텍처 진화: 기존 사이드카 기반 구조에서 앰비언트 메시, eBPF 기반 Proxy-less 메시로 확장되고 있음.
• 운영 자동화: 선언형 정책, GitOps 기반 배포, 서킷 브레이커 기반 장애 회복 전략이 핵심 운영 방식으로 자리 잡음.
• 보안의 표준화: mTLS 와 제로 트러스트는 모든 서비스 메시 설계의 기본 보안 모델이며, SPIFFE 기반 ID 인증도 필수 요소.
• 관찰성 통합: OpenTelemetry, Jaeger, Kiali 를 통한 시각화 및 추적이 운영과 디버깅의 중심이 되고 있음.
• 벤더 중립성: SMI 는 다양한 서비스 메시 구현체 간 호환성과 이식성 확보를 위한 핵심 표준으로 주목됨.

반드시 학습해야할 내용

요약 정리

용어 정리

• Sidecar, Control Plane, Data Plane은 대부분의 서비스 메시 구조에서 공통적으로 사용되는 핵심 용어.
• Ambient Mesh와 Proxy-less Mesh는 최근 등장한 개념으로, 기존 Sidecar 기반 모델의 성능·운영 복잡성 문제를 개선하고자 하는 아키텍처 진화 방향.
• mTLS, Zero Trust, RBAC 등은 서비스 메시 보안 정책 설계의 핵심으로 간주.
• OpenTelemetry는 관찰성 구현에서 de facto 표준이며, Istio, Linkerd, AWS App Mesh 등 다양한 메시에서 지원된다.

참고 및 출처

• Red Hat - What is a service mesh?
• Microsoft Cloud Native Architecture - Service Meshes
• Istio 공식 문서 – What is Istio?
• Linkerd 공식 문서 – What Is a Service Mesh?
• Cilium 공식 사이트 – Service Mesh
• Kong – What is a Service Mesh?
• AWS – What is Service Mesh?
• Tigera – Service Mesh Architecture
• Solo.io – Service Mesh Architecture
• Netflix Tech Blog – Zero‑Configuration Service Mesh
• InfoQ – Envoy Service Mesh 사례
• Google Cloud – Service Mesh 보안 모범 사례
• CNCF – Demystifying Service Mesh
• Red Hat OpenShift Service Mesh (Istio 기반)