Contents
Istio のトラフィック管理基礎と主要 CRD（VirtualService・DestinationRule）
Istio が提供する VirtualService と DestinationRule は、マイクロサービス間のルーティングやリトライ、タイムアウトといった制御を宣言的に記述できる中心的なカスタムリソースです。
この 2 つだけでほとんどのトラフィック管理シナリオが実装可能になるため、まずは概念と構成要素を整理してから具体例へ進みます。
VirtualService と DestinationRule の役割
VirtualService は「リクエストをどこに送るか」という ルーティングロジック を定義し、HTTP/HTTPS/TCP のマッチ条件や重み付け、ミラーリングなどを記述します。一方、DestinationRule は「選択された宛先の詳細設定」――サブセット（バージョン）やポリシー（mTLS、ロードバランシング方式、アウトライヤーディテクション等）を管理します。
ポイント
- VirtualService → 「何をしたいか」（例：10% を Canary に流す）
- DestinationRule → 「どのように実行するか」（例：subset v2 の Pod だけ対象）
Bookinfo アプリでの最小構成
以下は Istio 公式チュートリアルでも紹介されている bookinfo サンプルの reviews サービスに対して、v1 と v2 を 80/20 の比率で振り分ける例です。
|
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 |
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: reviews spec: hosts: - reviews.prod.svc.cluster.local http: - route: - destination: host: reviews.prod.svc.cluster.local subset: v2 weight: 80 - destination: host: reviews.prod.svc.cluster.local subset: v1 weight: 20 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews.prod.svc.cluster.local subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 |
subsetは DestinationRule に定義されたラベルと一致させるだけで利用可能です。weightの変更は VirtualService を再適用すれば即座に反映され、ダウンタイムなしでトラフィックシフトが行えます。
参考: Istio Traffic Management – VirtualService & DestinationRule
AWS EKS と GKE における Istio のインストール手順
クラウド環境ごとに IAM／Workload Identity の設定が異なるため、まずは 共通のインストールフロー（istioctl または Helm）を示し、その後で各プラットフォーム固有のポイントを解説します。
共通手順：istioctl によるインストール
istioctlバイナリを取得し、PATH に追加する。- プロファイル（例:
default) を指定して CRD とコアコンポーネントをデプロイする。 - 任意の名前空間に自動サイドカー注入ラベルを付与する。
|
1 2 3 4 5 6 7 8 9 10 |
# 1. ダウンロード (v1.20 系を例示) curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.0 sh - export PATH=$PWD/istio-1.20.0/bin:$PATH # 2. デフォルトプロファイルでインストール istioctl install --set profile=default -y # 3. サイドカー自動注入を有効化（例: prod 名前空間） kubectl label namespace prod istio-injection=enabled |
この手順は EKS、GKE 共通で機能しますが、認証情報の付与方法が異なる点だけ注意が必要です。
AWS EKS：IAM ロールと ServiceAccount の連携
| 項目 | 推奨設定例 |
|---|---|
| IAM ロール | eksctl create iamserviceaccount --name istiod-sa --namespace istio-system --cluster <CLUSTER> --attach-policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy |
| ServiceAccount アノテーション | kubectl annotate serviceaccount -n istio-system istiod-sa eks.amazonaws.com/role-arn=<ROLE_ARN> |
- 理由：Istio のコントロールプレーン（istiod）は CRD 作成や Secret 管理に対して IAM 権限が必要です。上記のアノテーションで Pod が自動的にロールを取得でき、最小権限の原則を保てます。
- 参考: Amazon EKS – IAM for Service Accounts (IRSA)
Google GKE：Workload Identity の活用
- GCP コンソールで サービスアカウント を作成し、
roles/istio.reader等のロールを付与。 - 同名（または別名）の Kubernetes ServiceAccount に
iam.gke.io/gcp-service-accountアノテーションを設定する。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 1. GCP SA 作成例 gcloud iam service-accounts create istio-sa --display-name "Istio control plane" # 2. ロール付与例 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:istio-sa@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/istio.reader" # 3. Kubernetes SA とアノテーション設定 kubectl create serviceaccount istiod-sa -n istio-system kubectl annotate serviceaccount istiod-sa -n istio-system \ iam.gke.io/gcp-service-account=istio-sa@$PROJECT_ID.iam.gserviceaccount.com |
- 理由：Workload Identity により GCP の IAM と Kubernetes の ServiceAccount がシームレスに紐付くため、追加の認証プラグインを導入せずに済みます。
- 参考: GKE – Workload Identity
Canary デプロイと A/B テストによる段階的ロールアウト
本番環境への新バージョン導入はリスクが伴います。Istio の Weighted Routing と Header/Query マッチング を組み合わせれば、コード変更なしでトラフィックの分割・評価・ロールバックが可能です。
Canary 用 VirtualService（重み付け）
以下は checkout サービスのリクエスト 10% を v2 に流す例です。weight の数値を kubectl apply -f で上書きするだけで、リアルタイムにシフトできます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: checkout spec: hosts: - checkout.prod.svc.cluster.local http: - route: - destination: host: checkout.prod.svc.cluster.local subset: v2 weight: 10 - destination: host: checkout.prod.svc.cluster.local subset: v1 weight: 90 |
運用ベストプラクティス
| 項目 | 推奨設定 |
|---|---|
| ヘルスチェック | DestinationRule の outlierDetection を有効化し、エラー率が一定以上になったら自動でトラフィックを 0 にリセット |
| モニタリング指標 | Prometheus で istio_requests_total, istio_request_duration_seconds を取得し、Canary 判定基準に組み込む |
| ロールバック手順 | weight: 0（v2） と weight: 100（v1） に変更すれば即座に元バージョンへ復帰 |
注意：本稿中のエラーレート削減率や MTTR の数値は社内報告書に基づく概算であり、外部公開された根拠はありません（※出典不明）。
A/B テストシナリオ（属性ベースのマッチング）
ヘッダー x-user-group: beta が付与されたユーザーだけを v2 に振り分ける構成です。A/B テストでは マッチ条件 と 重み付け を組み合わせ、実験対象とコントロールグループを明確に分離します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: recommendation spec: hosts: - rec.prod.svc.cluster.local http: - match: - headers: x-user-group: exact: beta route: - destination: host: rec.prod.svc.cluster.local subset: v2 - route: - destination: host: rec.prod.svc.cluster.local subset: v1 |
- 効果測定：A/B テストの成功指標は「コンバージョン率」「レイテンシ」などビジネス KPI に紐付け、Prometheus と Grafana のダッシュボードで可視化します。
- ロールアウト手順：テスト期間が終了したら
match条件を削除し、重み付けだけに戻すか、完全に新バージョンへ切り替えます。
大規模同時接続環境で活用すべき 5 つの Istio 機能
STCLab の実装例を参考に、数百万単位の同時接続が想定されるサービスで特に有効な機能をまとめます。以下は 「ミラー → レートリミット → サーキットブレーカー → タイムアウト → mTLS」 の順序で構成した例です。
1. トラフィックミラーリング
本番トラフィックの一部をステージング環境にコピーし、実際の負荷下で新バージョンの動作検証が可能です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: api-mirror spec: hosts: - api.prod.svc.cluster.local http: - route: - destination: host: api.prod.svc.cluster.local subset: v1 mirror: host: api.prod.svc.cluster.local subset: v2 mirrorPercentage: value: 10 # 本番リクエストの 10% をミラーに送信 |
ポイント：ミラー先は同一クラスタ内に置くとレイテンシ測定が正確です。
2. レートリミット（EnvoyFilter）
全サービス共通で秒間リクエスト数を制限し、過負荷時のバックプレッシャーを防ぎます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: networking.istio.io/v1beta1 kind: EnvoyFilter metadata: name: global-rate-limit spec: configPatches: - applyTo: HTTP_ROUTE match: context: SIDECAR_INBOUND patch: operation: MERGE value: requestHeadersToAdd: - header: key: x-envoy-ratelimited value: "true" |
- 実装上の注意：
ratelimitサービスを別途デプロイし、EnvoyFilter から呼び出す構成が一般的です（詳細は公式ドキュメント参照）。
3. サーキットブレーカー（OutlierDetection）
連続エラー検知時に対象インスタンスを自動で除外し、障害拡大を防止します。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: payment-cb spec: host: payment.prod.svc.cluster.local trafficPolicy: outlierDetection: consecutive5xxErrors: 3 interval: 5s baseEjectionTime: 30s |
4. タイムアウト設定
リクエストが一定時間以内に完了しなければエラーとして返すことで、バックエンドへの過剰負荷を抑えます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: order-timeout spec: hosts: - order.prod.svc.cluster.local http: - route: - destination: host: order.prod.svc.cluster.local timeout: 2s # 2 秒でタイムアウト |
5. mTLS（相互認証）
内部通信をすべて TLS 化し、盗聴・改ざんリスクを排除します。
|
1 2 3 4 5 6 7 8 |
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default-mtls spec: mtls: mode: STRICT # 全サービスで必須の相互認証 |
効果：上記設定を適用した環境では、内部トラフィックが暗号化されるだけでなく、認証失敗時に自動的にリクエストが遮断されます。
実装フローまとめ
- ミラー で新機能の実運用テスト →
- レートリミット による全体トラフィック抑制 →
- サーキットブレーカー が異常を検知したらインスタンス除外 →
- タイムアウト で遅延リクエストを早期に切断 →
- mTLS で通信全体を保護
この順序は「可視化 → 保護 → 回復」の流れになっており、他プロジェクトでもほぼそのまま流用可能です。
セキュリティ・耐障害性機能と導入後の定量的成果
mTLS と AuthorizationPolicy の組み合わせ
全ネームスペースで mTLS を強制し、重要サービス（例: payment）へのアクセスは特定 ServiceAccount のみ許可する構成です。
|
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 |
# 全体に mTLS 強制 (STRICT) apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: global-mtls spec: selector: {} # 空で全ネームスペース対象 mtls: mode: STRICT # payment サービスへのアクセス制御 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-payment-from-frontend namespace: prod spec: selector: matchLabels: app: payment action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/prod/sa/frontend"] |
- 運用上の注意
- 証明書は
istiodが自動ローテーションしますが、外部システムとの連携時は手動更新が必要です。 - ポリシー衝突を防ぐために CI パイプラインで
kubectl apply --dry-run=clientを実行し、Lint ツール（例:kube-linter）で検証します。
サーキットブレーカーとタイムアウトの実装例
以下は在庫管理サービス (inventory) に対して 5xx エラーが連続したら 60 秒間隔で除外、同時に リクエストタイムアウトを 1.5 秒 に設定する例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: inventory-cb-timeout spec: host: inventory.prod.svc.cluster.local trafficPolicy: outlierDetection: consecutive5xxErrors: 2 interval: 10s baseEjectionTime: 60s connectionPool: tcp: maxConnections: 1000 timeout: 1.5s |
導入効果（社内報告ベース）
| 指標 | 導入前 | 導入後 | 変化率 |
|---|---|---|---|
| エラーレート (5xx) | 約 2.8% | 約 1.9% | -30% |
| MTTR（平均復旧時間） | 120 秒 | 45 秒 | -62% |
| インシデント件数（月） | 8 件 | 3 件 | -63% |
備考：上記数値は STCLab 社内の実運用データに基づく概算であり、外部公開された検証結果ではありません（※出典不明）。
運用のベストプラクティス
- 可視化 – Prometheus と Grafana で
istio_requests_total,istio_request_duration_seconds,istio_tcp_connections_opened_totalをモニタリング。 - 自動化 – GitOps（Argo CD）で CRD のデプロイを管理し、変更があれば自動的にテスト・適用。
- 定期レビュー – 3か月ごとに
outlierDetectionパラメータやtimeout設定の妥当性を評価し、トラフィック増加に合わせて調整。
まとめ
- VirtualService と DestinationRule が Istio におけるトラフィック管理の核であり、ルーティングロジックとエンドポイント設定を分離して宣言的に記述できる。
- AWS EKS / GKE のインストールは
istioctl（共通）＋各クラウドの認証連携（IAM/IRSA、Workload Identity）が要点。 - Canary デプロイ は重み付け、A/B テスト はヘッダーやクエリマッチで実現し、いずれもコード変更不要で安全にロールアウトできる。
- 大規模環境では ミラー → レートリミット → サーキットブレーカー → タイムアウト → mTLS の 5 機能を組み合わせると、可視化・保護・回復のフローが完成する。
- mTLS と AuthorizationPolicy による内部通信の暗号化・認可はセキュリティ基盤として必須であり、サーキットブレーカーやタイムアウトと併用すると障害復旧時間（MTTR）を大幅に短縮できる。
これらの知見を踏まえて、自組織のマイクロサービスアーキテクチャに Istio を導入すれば、トラフィック制御とセキュリティが一元管理でき、運用コスト削減と信頼性向上を同時に実現できます。