はじめに
マイクロサービスの数が増えると、mTLS、再試行、サーキット ブレーカー、トレース、トラフィック分割など、サービス間通信の管理が複雑になります。サービス メッシュは、すべてのネットワーク ロジックをアプリケーション コードからインフラストラクチャ レイヤーに取り出すことで解決します。
1. サービス メッシュ アーキテクチャ
1.1 コンセプト
Service Mesh は、各ポッドに挿入されたネットワーク プロキシ (サイドカー) を介してサービス間通信を処理する 専用のインフラストラクチャ レイヤー です。
Không có Service Mesh:
┌──────────┐ ┌──────────┐
│ Service A│ │ Service B│
│ │ │ │
│ ┌──────┐ │ HTTP/gRPC │ ┌──────┐ │
│ │ App │─┼───────────────────┼▶│ App │ │
│ │ Code │ │ │ │ Code │ │
│ │ │ │ Circuit breaker, │ │ │ │
│ │ +retry│ │ mTLS, tracing... │ │ │ │
│ │ +auth │ │ ← TRONG app code │ │ │ │
│ └──────┘ │ │ └──────┘ │
└──────────┘ └──────────┘
Có Service Mesh:
┌──────────────┐ ┌──────────────┐
│ Pod A │ │ Pod B │
│ │ │ │
│ ┌──────────┐ │ │ ┌──────────┐ │
│ │ App Code │ │ │ │ App Code │ │
│ │ (simple) │ │ │ │ (simple) │ │
│ └────┬─────┘ │ │ └────▲─────┘ │
│ │ │ │ │ │
│ ┌────▼─────┐ │ mTLS, retry │ ┌────┴─────┐ │
│ │ Sidecar │─┼───circuit brk──┼▶│ Sidecar │ │
│ │ Proxy │ │ tracing │ │ Proxy │ │
│ │ (Envoy) │ │ │ │ (Envoy) │ │
│ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘
1.2 データ プレーンとコントロール プレーン
┌─────────────────────────────────────────────────┐
│ Control Plane │
│ (Istiod / Linkerd Control Plane) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Config │ │ Cert │ │ Service │ │
│ │ Mgmt │ │ Authority│ │ Discovery │ │
│ │ │ │ (CA) │ │ │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ │ │
│ xDS API (push config) │
└──────────────────────┼───────────────────────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌───────▼──────┐┌──────▼──────┐┌──────▼──────┐
│ Envoy/Linkerd││ Envoy/Linkerd││ Envoy/Linkerd│ ← Data Plane
│ Proxy ││ Proxy ││ Proxy │
│┌────────────┐││┌────────────┐││┌────────────┐│
││ Service A ││││ Service B ││││ Service C ││
│└────────────┘││└────────────┘││└────────────┘│
└──────────────┘└──────────────┘└──────────────┘
データ プレーン: サイドカー プロキシが実際のトラフィック (ルーティング、mTLS、メトリクス) を処理します。 コントロール プレーン: データ プレーン プロキシ (プッシュ ポリシー、証明書) を構成および管理します。
2. Istio
2.1 アーキテクチャ
┌─────────────────────────────────────────┐
│ Istiod (Control Plane) │
│ │
│ ┌─────────┐ ┌────────┐ ┌───────────┐ │
│ │ Pilot │ │Citadel │ │ Galley │ │
│ │ │ │ │ │ │ │
│ │ Service │ │ Cert │ │ Config │ │
│ │ Disc. │ │ Mgmt │ │ Validate │ │
│ │ Config │ │ mTLS │ │ Transform│ │
│ │ Push │ │ SPIFFE │ │ │ │
│ └─────────┘ └────────┘ └───────────┘ │
└────────────────────┬────────────────────┘
│ xDS/gRPC
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Envoy │ │ Envoy │ │ Envoy │
│ Sidecar │ │ Sidecar │ │ Sidecar │
└─────────┘ └─────────┘ └─────────┘
2.2 インストール
# Install Istio CLI
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
# Install Istio on cluster (demo profile for learning)
istioctl install --set profile=demo -y
# Production profile
istioctl install --set profile=default \
--set meshConfig.enableTracing=true \
--set meshConfig.defaultConfig.tracing.zipkin.address=jaeger:9411
# Enable sidecar injection for namespace
kubectl label namespace default istio-injection=enabled
# Verify
kubectl get pods -n istio-system
2.3 トラフィック管理
VirtualService — リクエスト ルーティング:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
# Canary: 90% v1, 10% v2
- route:
- destination:
host: order-service
subset: v1
weight: 90
- destination:
host: order-service
subset: v2
weight: 10
timeout: 5s
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset,connect-failure
DestinationRule — ロード バランシングとサーキット ブレーカー:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order-service
spec:
host: order-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 100
http2MaxRequests: 1000
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
loadBalancer:
simple: LEAST_REQUEST
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
ヘッダーベースのルーティング (A/B テスト):
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
# Beta users → v2
- match:
- headers:
x-user-group:
exact: beta
route:
- destination:
host: order-service
subset: v2
# All others → v1
- route:
- destination:
host: order-service
subset: v1
2.4 フォールトインジェクション (カオステスト)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: payment-service
spec:
hosts:
- payment-service
http:
- fault:
# 10% requests bị delay 5s
delay:
percentage:
value: 10
fixedDelay: 5s
# 5% requests bị abort với 503
abort:
percentage:
value: 5
httpStatus: 503
route:
- destination:
host: payment-service
3. リンカード
3.1 アーキテクチャ
Linkerd は Envoy の代わりに linkerd2-proxy (Rust で書かれた) を使用します。
┌─────────────────────────────────┐
│ Linkerd Control Plane │
│ │
│ ┌────────────┐ ┌───────────┐ │
│ │ Destination│ │ Identity │ │
│ │ (discovery │ │ (mTLS │ │
│ │ + config) │ │ certs) │ │
│ └────────────┘ └───────────┘ │
│ ┌────────────┐ │
│ │ Proxy │ │
│ │ Injector │ │
│ └────────────┘ │
└─────────────────────────────────┘
│
┌──────┼──────┐
▼ ▼ ▼
┌──────┐┌──────┐┌──────┐
│linkerd││linkerd││linkerd│ ← linkerd2-proxy (Rust)
│proxy ││proxy ││proxy │
└──────┘└──────┘└──────┘
3.2 インストールと使用法
# Install CLI
curl -sL https://run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH
# Check cluster readiness
linkerd check --pre
# Install control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
# Verify
linkerd check
# Inject sidecar into existing deployment
kubectl get deploy order-service -o yaml \
| linkerd inject - \
| kubectl apply -f -
# Or annotate namespace for auto-injection
kubectl annotate namespace default linkerd.io/inject=enabled
# Linkerd dashboard
linkerd viz install | kubectl apply -f -
linkerd viz dashboard
3.3 トラフィック分割 (SMI)
# Service Mesh Interface (SMI) — standard API
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: order-service-split
spec:
service: order-service
backends:
- service: order-service-v1
weight: 900 # 90%
- service: order-service-v2
weight: 100 # 10%
4. Istio 対リンカード
| 基準 | イスティオ | リンカード |
|---|---|---|
| プロキシ | エンボイ (C++) | linkerd2-proxy (Rust) |
| リソース使用量 | 高 (~100MB/サイドカー) | 低 (~20MB/サイドカー) |
| レイテンシのオーバーヘッド | ~3-5ms p99 | ~1-2ms p99 |
| 機能セット | とても豊かです | コア機能、シンプル |
| 学習曲線 | ドクター | 平均 |
| 交通管理 | 非常に強力 (VirtualService) | 基本 (SMI トラフィックスプリット) |
| マルチクラスター | 良い | 良い |
| コミュニティ | ビッグ (Google、IBM) | 良い (元気、CNCF卒業) |
| 推奨 | 複雑な使用例、エンタープライズ | シンプル、パフォーマンス重視 |
いつ何を選択するか?
Cần traffic management phức tạp (A/B, canary, fault injection)?
→ Istio
Cần performance tối đa, resource constrained?
→ Linkerd
Team nhỏ, muốn adopt nhanh?
→ Linkerd
Enterprise, nhiều cluster, complex policies?
→ Istio
Chưa chắc cần service mesh?
→ Bắt đầu KHÔNG có mesh
→ Khi pain points rõ ràng → evaluate
5. サービスメッシュからの可観測性
サービス メッシュは、アプリケーション コードを変更することなく、ゴールデン シグナルを自動的に提供します。
Automatic Metrics (mỗi request):
├── Request rate (requests/sec)
├── Success rate (% non-5xx)
├── Latency distribution (p50, p95, p99)
├── Bytes in/out
└── Active connections
Automatic Distributed Tracing:
├── Span creation cho mỗi hop
├── Context propagation (B3/W3C headers)
├── Service dependency graph
└── Request flow visualization
Automatic mTLS Metrics:
├── Certificate expiry
├── Handshake success/failure
└── Protocol versions
# Linkerd: xem metrics real-time
linkerd viz stat deploy
linkerd viz top deploy/order-service
linkerd viz routes deploy/order-service
# Istio: Kiali dashboard
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml
istioctl dashboard kiali
概要
- サービス メッシュ は、ネットワーク ロジックをアプリケーション コードからサイドカー プロキシに分離します。
- データ プレーン (プロキシ) がトラフィックを処理します。 コントロール プレーン が構成を管理します
- Istio: 機能が豊富な Envoy ベースで、企業の複雑なユースケースに適しています
- Linkerd: 軽量、Rust ベース、高性能、導入が簡単
- Service Mesh は mTLS、可観測性、トラフィック管理を自動的に提供します
- サービス メッシュは常に必要なわけではありません - 複雑さに基づいて評価します