Service Mesh 2025 - マイクロサービス通信の標準インフラ

Service Meshとは

Service Meshは、マイクロサービスアーキテクチャにおけるサービス間通信を管理するための専用インフラストラクチャレイヤーです。アプリケーションコードを変更することなく、認証・認可、トラフィック制御、オブザーバビリティを透過的に実現します。

2025年、CNCFの調査によるとKubernetes本番環境の70%以上がService Meshを採用しており、マイクロサービス運用の標準インフラとして確立されました。

なぜService Meshが必要なのか

マイクロサービスの課題

従来のモノリシックアプリケーションでは、関数呼び出しで済んでいた処理が、マイクロサービスではネットワーク通信になります。

# マイクロサービス間通信の課題
challenges:
  reliability:
    - ネットワーク障害への対応
    - タイムアウト処理
    - リトライロジック
    - サーキットブレーカー

  security:
    - サービス間認証
    - 通信の暗号化
    - アクセス制御
    - 証明書管理

  observability:
    - 分散トレーシング
    - メトリクス収集
    - ログの相関付け
    - サービスマップ

これらをアプリケーションコードで実装すると、ビジネスロジックと運用コードが混在し、保守性が低下します。Service Meshはこれらの横断的関心事をインフラレイヤーに委譲します。

主要Service Mesh比較（2025年版）

Istio

Google、IBM、Lyftが開発した最も機能豊富なService Mesh。エンタープライズでの採用率No.1です。

# Istio のアーキテクチャ
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-control-plane
spec:
  profile: default
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100.0
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
  components:
    pilot:
      k8s:
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer

Istioの特徴:

Linkerd

Buoyant社が開発した軽量Service Mesh。シンプルさとパフォーマンスを重視しています。

# Linkerd のインストール設定
apiVersion: linkerd.io/v1alpha2
kind: LinkerdConfig
metadata:
  name: linkerd-config
spec:
  proxy:
    resources:
      cpu:
        request: 100m
        limit: 1000m
      memory:
        request: 20Mi
        limit: 250Mi
    logLevel: warn,linkerd=info
  identity:
    issuer:
      scheme: kubernetes.io/tls
      clockSkewAllowance: 20s
      issuanceLifetime: 24h0m0s
  # 自動mTLS有効化
  autoInjectContext: enabled

Linkerdの特徴:

• Rust製プロキシ（linkerd2-proxy）: Envoyより軽量で高速
• ゼロコンフィグmTLS: インストール直後から暗号化
• 低リソース消費: Pod あたり 10-20MB
• シンプルなCLI: linkerd check で問題診断

# Linkerd インストールと検証
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check

# アプリケーションへの注入
kubectl get deploy -o yaml | linkerd inject - | kubectl apply -f -

# ダッシュボード起動
linkerd viz install | kubectl apply -f -
linkerd viz dashboard &

Cilium Service Mesh

eBPFベースの次世代Service Mesh。カーネルレベルで動作し、サイドカーレスを実現します。

# Cilium Service Mesh 設定
apiVersion: cilium.io/v2alpha1
kind: CiliumEnvoyConfig
metadata:
  name: l7-traffic-policy
spec:
  services:
    - name: payment-service
      namespace: production
  backendServices:
    - name: payment-v1
      namespace: production
    - name: payment-v2
      namespace: production
  resources:
    - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
      name: l7-listener
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: l7-traffic
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: payment-service
                      domains: ["*"]
                      routes:
                        - match:
                            prefix: "/"
                          route:
                            weighted_clusters:
                              clusters:
                                - name: production/payment-v1
                                  weight: 90
                                - name: production/payment-v2
                                  weight: 10

Ciliumの特徴:

# Cilium ネットワークポリシー
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-gateway-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/.*"
              - method: "POST"
                path: "/api/v1/orders"
                headers:
                  - header: "Content-Type"
                    value: "application/json"

比較表：Istio vs Linkerd vs Cilium

# Service Mesh 比較 2025
comparison:
  istio:
    maturity: "非常に高い"
    resource_overhead: "高"
    features: "最も豊富"
    learning_curve: "急勾配"
    use_case: "エンタープライズ、複雑な要件"
    proxy: "Envoy"
    mTLS: "設定必要"

  linkerd:
    maturity: "高い"
    resource_overhead: "低"
    features: "必要十分"
    learning_curve: "緩やか"
    use_case: "スタートアップ、シンプルな運用"
    proxy: "linkerd2-proxy (Rust)"
    mTLS: "デフォルト有効"

  cilium:
    maturity: "成長中"
    resource_overhead: "最低"
    features: "L3/L4に強い"
    learning_curve: "中程度"
    use_case: "パフォーマンス重視、大規模環境"
    proxy: "eBPF + Envoy"
    mTLS: "SPIFFE/SPIRE連携"

Ambient Mesh（サイドカーレス）

2025年の最大トレンドはAmbient Meshです。Istioが導入したこのアーキテクチャは、サイドカーを排除し、ノードレベルのプロキシで通信を制御します。

従来のサイドカーモデルの課題

# サイドカーモデルの問題点
sidecar_challenges:
  resource_overhead:
    description: "各Podにプロキシコンテナが必要"
    impact: "メモリ・CPUコストの増大"
    example: "1000 Pod × 100MB = 100GB追加メモリ"

  latency:
    description: "すべてのリクエストがプロキシを経由"
    impact: "レイテンシ増加（1-3ms）"

  complexity:
    description: "サイドカー注入の管理"
    impact: "デプロイメント複雑化"

  upgrade:
    description: "プロキシ更新にPod再起動が必要"
    impact: "ローリングアップデートの負担"

Ambient Meshアーキテクチャ

# Istio Ambient Mesh 設定
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-ambient
spec:
  profile: ambient
  components:
    ztunnel:
      enabled: true
    cni:
      enabled: true
  values:
    cni:
      ambient:
        enabled: true
---
# 名前空間をAmbientモードに設定
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    istio.io/dataplane-mode: ambient

Ambient Meshの構成要素:

1. ztunnel（Zero Trust Tunnel）: L4プロキシ、ノードごとに1つ
2. waypoint proxy: L7処理が必要な場合のみデプロイ
3. Istio CNI: トラフィックリダイレクト

# Waypoint Proxy（L7処理が必要な場合）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: payment-waypoint
  namespace: production
  labels:
    istio.io/waypoint-for: service
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE
---
# L7ルーティングルール
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payment-route
  namespace: production
spec:
  parentRefs:
    - name: payment-waypoint
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v2
      backendRefs:
        - name: payment-v2
          port: 8080
          weight: 100

トラフィック管理

カナリアリリース

# Istio VirtualService でのカナリアリリース
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
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
---
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
        http2MaxRequests: 1000
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

サーキットブレーカー

# サーキットブレーカー設定
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payment-circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 50
        connectTimeout: 5s
      http:
        http1MaxPendingRequests: 100
        http2MaxRequests: 500
        maxRequestsPerConnection: 10
        maxRetries: 3
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
      minHealthPercent: 30

リトライとタイムアウト

# リトライポリシー
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
      timeout: 10s
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: gateway-error,connect-failure,retriable-4xx
        retryRemoteLocalities: true

セキュリティ機能

mTLS（相互TLS認証）

# Istio PeerAuthentication
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # PERMISSIVE, STRICT, DISABLE
---
# 特定サービスへの例外設定
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: legacy-service-exception
  namespace: production
spec:
  selector:
    matchLabels:
      app: legacy-service
  mtls:
    mode: PERMISSIVE
  portLevelMtls:
    8080:
      mode: DISABLE

認可ポリシー

# AuthorizationPolicy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/production/sa/order-service
              - cluster.local/ns/production/sa/checkout-service
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/payments", "/api/v1/refunds"]
      when:
        - key: request.headers[x-request-id]
          notValues: [""]
---
# デフォルト拒否ポリシー
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  {}  # 空のspecはすべて拒否

JWT検証

# RequestAuthentication（JWT検証）
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-gateway
  jwtRules:
    - issuer: "https://auth.example.com"
      jwksUri: "https://auth.example.com/.well-known/jwks.json"
      audiences:
        - "api.example.com"
      forwardOriginalToken: true
      outputPayloadToHeader: x-jwt-payload
---
# JWTクレームに基づく認可
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-gateway
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals: ["https://auth.example.com/*"]
      when:
        - key: request.auth.claims[role]
          values: ["admin", "user"]

オブザーバビリティ

メトリクス収集

# Istio メトリクス設定
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: mesh-metrics
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus
      overrides:
        - match:
            metric: REQUEST_COUNT
            mode: CLIENT_AND_SERVER
          tagOverrides:
            response_code:
              operation: UPSERT
            request_protocol:
              operation: REMOVE
---
# Prometheus ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istio-component-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: istiod
  endpoints:
    - port: http-monitoring
      interval: 15s
      path: /metrics

分散トレーシング

# Jaeger 連携設定
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 10.0  # 10%サンプリング
        zipkin:
          address: jaeger-collector.observability:9411
    extensionProviders:
      - name: jaeger
        zipkin:
          service: jaeger-collector.observability.svc.cluster.local
          port: 9411
---
# トレーシングプロバイダー指定
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: tracing-config
  namespace: production
spec:
  tracing:
    - providers:
        - name: jaeger
      randomSamplingPercentage: 10.0
      customTags:
        environment:
          literal:
            value: production

2025年の動向

eBPFの台頭

# 2025年のService Meshトレンド
trends_2025:
  ebpf_adoption:
    description: "カーネルレベルのネットワーク処理"
    benefits:
      - "サイドカー不要"
      - "低レイテンシ"
      - "リソース効率"
    players:
      - "Cilium Service Mesh"
      - "Istio Ambient Mode（ztunnel）"

  sidecarless:
    description: "サイドカーレスアーキテクチャの主流化"
    adoption_rate: "新規導入の40%"

  gateway_api:
    description: "Kubernetes Gateway APIの標準化"
    status: "GA（1.0）"
    benefits:
      - "ベンダー中立"
      - "表現力の向上"
      - "ロールベースの設定"

Gateway API統合

# Kubernetes Gateway API（標準化）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: production
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-cert
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-routes
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: x-api-version
                value: "v1"
      backendRefs:
        - name: api-v1
          port: 8080

マルチクラスター対応

# Istio マルチクラスター設定
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-multicluster
spec:
  profile: default
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: cluster1
      network: network1
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
---
# リモートクラスターへのシークレット
apiVersion: v1
kind: Secret
metadata:
  name: istio-remote-secret-cluster2
  namespace: istio-system
  labels:
    istio/multiCluster: "true"
type: Opaque
data:
  cluster2: <base64-encoded-kubeconfig>

導入ガイドライン

選択基準

# Service Mesh選択フローチャート
selection_guide:
  small_team:
    condition: "チーム10人以下、シンプルなマイクロサービス"
    recommendation: "Linkerd"
    reason: "低学習コスト、即座にmTLS"

  enterprise:
    condition: "大規模組織、複雑なポリシー要件"
    recommendation: "Istio"
    reason: "豊富な機能、エコシステム"

  performance_critical:
    condition: "低レイテンシ必須、大規模トラフィック"
    recommendation: "Cilium Service Mesh"
    reason: "eBPFによる最高性能"

  greenfield:
    condition: "新規プロジェクト、2025年以降"
    recommendation: "Istio Ambient Mode"
    reason: "サイドカーレスの利点、将来性"

段階的導入

# 段階的導入ステップ
adoption_phases:
  phase1:
    name: "観測性から開始"
    duration: "2-4週間"
    goals:
      - "メトリクス収集"
      - "トレーシング導入"
      - "サービスマップ可視化"

  phase2:
    name: "mTLS有効化"
    duration: "2-4週間"
    goals:
      - "PERMISSIVEモードで開始"
      - "互換性検証"
      - "STRICTモードへ移行"

  phase3:
    name: "トラフィック管理"
    duration: "4-6週間"
    goals:
      - "カナリアリリース"
      - "フォールトインジェクション"
      - "サーキットブレーカー"

  phase4:
    name: "認可ポリシー"
    duration: "4-8週間"
    goals:
      - "ゼロトラスト実現"
      - "最小権限の原則"
      - "監査ログ"

まとめ

2025年のService Meshは、Ambient MeshとeBPFの台頭により、サイドカーモデルからの脱却が進んでいます。

• Istio: 最も機能豊富、Ambient Modeで進化中
• Linkerd: シンプルさと軽量性を維持、Rustプロキシの優位性
• Cilium: eBPFベースで最高性能、大規模環境に最適

選択のポイントは、チームのスキルセット、パフォーマンス要件、運用の複雑さのバランスです。新規プロジェクトでは、IstioのAmbient Modeを検討し、パフォーマンスが最優先ならCiliumを選択することをお勧めします。

参考: CNCF Service Mesh Landscape, Istio Documentation, Linkerd Documentation