サービスメッシュ入門 - Istio/Linkerdで実現する通信制御

サービスメッシュとは

サービスメッシュは、マイクロサービス間の通信を管理するインフラストラクチャレイヤーです。サービス間通信の複雑さをアプリケーションから分離し、一貫した方法で制御します。

なぜ必要か: マイクロサービスが増えると、サービス間通信の可観測性、セキュリティ、信頼性の確保が困難になります。サービスメッシュはこれらを統一的に解決します。

サービスメッシュなしの課題

flowchart LR
    A["サービスA"] --> B["サービスB"]

各サービスで実装が必要:

• リトライロジック
• サーキットブレーカー
• タイムアウト
• TLS証明書管理
• メトリクス収集
• トレーシング

サイドカーパターン

各サービスPodにプロキシ（サイドカー）をデプロイし、すべての通信を経由させます。

flowchart LR
    subgraph Pod
        App["Application<br/>(App)"]
        Sidecar["Sidecar<br/>(Envoy)"]
        App <-->|localhost| Sidecar
    end
    Sidecar <-->|"すべての通信が経由"| External["外部"]

サービスメッシュのアーキテクチャ

flowchart TB
    subgraph ControlPlane["Control Plane"]
        Config["Config<br/>Management"]
        Telemetry["Telemetry<br/>Collection"]
        Policy["Policy<br/>Enforcement"]
    end

    subgraph DataPlane["Data Plane"]
        SA["Service A<br/>+ Sidecar"]
        SB["Service B<br/>+ Sidecar"]
        SC["Service C<br/>+ Sidecar"]
        SA <--> SB <--> SC
    end

    ControlPlane -->|"設定配布"| DataPlane

主要機能

1. トラフィック管理

# Istio VirtualService - カナリアデプロイ
apiVersion: networking.istio.io/v1beta1
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

2. サーキットブレーカー

# Istio DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

3. リトライ・タイムアウト

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
    - route:
        - destination:
            host: my-service
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: 5xx

4. mTLS（相互TLS）

サービス間通信を自動的に暗号化します。

flowchart LR
    A["サービスA<br/>🔐 証明書"] -->|mTLS| B["サービスB<br/>🔐 証明書"]
    AutoManage["自動管理"] -.-> A
    AutoManage -.-> B

# Istio PeerAuthentication
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

5. 可観測性

主要なサービスメッシュ

Istio vs Linkerd

ユースケース

カナリアリリース

A/Bテスト

# ヘッダーによるルーティング
http:
  - match:
      - headers:
          x-user-group:
            exact: beta
    route:
      - destination:
          host: my-service
          subset: v2
  - route:
      - destination:
          host: my-service
          subset: v1

フォールトインジェクション

# テスト用に意図的に遅延を注入
http:
  - fault:
      delay:
        percentage:
          value: 10
        fixedDelay: 5s
    route:
      - destination:
          host: my-service

導入の判断

適している場合

• ✓ 多数のマイクロサービス（10+）
• ✓ 複雑な通信パターン
• ✓ ゼロトラストセキュリティが必要
• ✓ 高度なトラフィック制御が必要
• ✓ Kubernetesを使用している

適していない場合

• ✗ サービス数が少ない（5未満）
• ✗ モノリシックアーキテクチャ
• ✗ シンプルな通信パターン
• ✗ 運用チームのリソースが限られている

まとめ

サービスメッシュは、マイクロサービス間通信の複雑さをアプリケーションから分離し、統一的に管理するためのインフラです。トラフィック制御、セキュリティ、可観測性を提供しますが、複雑さとリソースオーバーヘッドも伴います。サービス数と運用能力を考慮して、導入を判断しましょう。