Istio
Amazon EKS で Istio Service Mesh を活用するための実践ガイドです。
目次
- Service Mesh は本当に必要ですか？
- インストールと初期設定
- 基本概念
- アーキテクチャ
- AWS 統合
- 用語集
- トラフィック管理
- セキュリティ
- 可観測性
- レジリエンス
- 高度な機能
- トラブルシューティング
- ベストプラクティス
- 代替案の比較
Istio とは？
Istio は、マイクロサービスを接続、保護、制御、監視するためのオープンソースの Service Mesh プラットフォームです。複雑なマイクロサービスアーキテクチャにおけるサービス間通信を管理し、トラフィック制御、セキュリティ、可観測性を提供します。
Service Mesh の概念
Service Mesh は、マイクロサービス間の通信を管理するインフラストラクチャレイヤーです。Istio は各サービスとともに Sidecar Proxy（Envoy）をデプロイし、すべてのネットワークトラフィックをインターセプトして制御します。これにより、アプリケーションコードを変更せずに次の機能を提供します。
- トラフィックルーティング: インテリジェントルーティング、ロードバランシング、Canary デプロイメント
- セキュリティ: 自動 mTLS、認証、認可
- 可観測性: メトリクス、ログ、分散トレーシング
- レジリエンス: Circuit Breaking、Retry、Timeout
実践的な利用例
Istio を使用しないアプリケーション
Istio を使用するアプリケーション - 各サービスに Sidecar としてデプロイされた Envoy Proxy
Istio を適用すると、各マイクロサービスに sidecar コンテナとして Envoy Proxy が自動的にデプロイされ、すべてのネットワークトラフィックを透過的にインターセプトして制御します。
Service Mesh は本当に必要ですか？
Service Mesh は強力なツールですが、すべての状況に適しているわけではありません。導入前に慎重な検討が必要です。
判断フロー
Service Mesh が必要な場合 ✅
1. 複雑なマイクロサービス環境
推奨基準:
- ✅ マイクロサービスが 10 個以上
- ✅ サービス間通信（East-West トラフィック）が頻繁に発生する
- ✅ 複数のプログラミング言語（Polyglot）を使用している
- ✅ 複数のチームがサービスを独立して開発している
2. Zero Trust セキュリティ要件
Service Mesh が提供する機能:
- サービス間の自動 mTLS 暗号化
- SPIFFE ベースの Identity 管理
- きめ細かな認証／認可ポリシー
- 暗号化通信の保証
代替手段では実現が難しいこと:
- 各サービスにおけるセキュリティロジック実装の重複
- 手動での証明書管理の複雑さ
- 一貫性のないセキュリティポリシー
3. 高度なトラフィック管理
# Canary Deployment (Traffic Distribution)
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10 # Only 10% to new version必要となる場合:
- Canary デプロイメント、A/B テスト
- Header/path ベースのルーティング
- Traffic Mirroring（Shadow Testing）
- Fault Injection（Chaos Engineering）
- Circuit Breaking、Retry、Timeout
4. 統合された可観測性
Service Mesh の利点:
- アプリケーションコードを変更せずにメトリクスを自動収集
- Distributed Tracing の自動実装
- 統一されたログ形式
- サービストポロジーの可視化（Kiali）
Service Mesh が不要な場合 ❌
1. シンプルなアーキテクチャ
代わりに使用するもの:
- Kubernetes Ingress Controller（NGINX、Traefik）
- シンプルなロードバランサー
- アプリケーションレベルの実装
2. 少数のマイクロサービス（10 未満）
オーバーヘッドの方が大きい場合:
- Service Mesh の運用の複雑さ > 得られるメリット
- 5～10 個のサービスは手動で管理可能
- NetworkPolicy で十分なセキュリティを提供できる
代替案:
# Kubernetes NetworkPolicy is sufficient
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
app: frontend3. 運用リソースの不足
Service Mesh の運用要件:
- Istio/Envoy の専門知識
- Control Plane の監視と管理
- アップグレードおよびパッチ管理
- トラブルシューティング能力（デバッグの複雑さが増加）
チームに必要な準備:
- 少なくとも 1～2 名の Service Mesh エキスパート
- 継続的な学習とアップデートの追跡
- 十分なテスト環境
4. パフォーマンスが極めて重要な場合
Service Mesh のオーバーヘッド:
- レイテンシー: +1～3ms（P50）、+5～10ms（P99）
- CPU: Pod あたり +10～20%
- メモリ: Pod あたり +50～100MB（Sidecar モード）
代替案を検討:
- Ambient Mode（リソース使用量を 90% 削減）
- CNI ベースのソリューション（Cilium）
- アプリケーションレベルの最適化
代替ソリューションの比較
| 機能 | Service Mesh | CNI（Cilium） | Ingress Controller | アプリケーションレベル |
|---|---|---|---|---|
| L7 トラフィック管理 | ✅ 完全対応 | ⚠️ 制限あり | ⚠️ Ingress のみ | ✅ 可能 |
| mTLS 自動化 | ✅ 完全対応 | ✅ 可能 | ❌ 非対応 | ❌ 手動実装 |
| Distributed Tracing | ✅ 自動 | ❌ 非対応 | ❌ 非対応 | ⚠️ 手動実装 |
| L3/L4 ポリシー | ✅ 対応 | ✅ 完全対応 | ❌ 非対応 | ❌ 非対応 |
| 運用の複雑さ | 🔴 高 | 🟡 中 | 🟢 低 | 🟡 中 |
| リソースオーバーヘッド | 🔴 高（Sidecar） | 🟢 低 | 🟢 低 | 🟢 なし |
| 適した規模 | 10 以上のサービス | すべての規模 | 小規模 | 小規模 |
CNI ベースのソリューション（Cilium）
Cilium は eBPF をベースに、ネットワークレベルで多くの機能を提供します。
Cilium がより適している場合:
- L3/L4 ネットワークポリシーが主な目的である
- 高パフォーマンスが中核要件である
- Service Mesh の運用負荷を避けたい
- シンプルな mTLS と可観測性のみが必要である
参照: Cilium ドキュメント
判断チェックリスト
導入前に次の質問に回答してください。
アーキテクチャ:
- [ ] マイクロサービスが 10 個以上ありますか？
- [ ] サービス間通信は複雑ですか？
- [ ] 複数のプログラミング言語を使用していますか？
セキュリティ:
- [ ] Zero Trust セキュリティモデルが必要ですか？
- [ ] サービス間の mTLS 暗号化は必須ですか？
- [ ] きめ細かなアクセス制御が必要ですか？
トラフィック管理:
- [ ] Canary デプロイメント、A/B テストが必要ですか？
- [ ] 高度なルーティングルールが必要ですか？
- [ ] 多くのサービスに Circuit Breaking、Retry が必要ですか？
可観測性:
- [ ] 分散トレーシングは必須ですか？
- [ ] 統合されたメトリクス収集が必要ですか？
- [ ] サービストポロジーの可視化が必要ですか？
運用:
- [ ] Service Mesh のエキスパートがいますか？
- [ ] 運用の複雑さに対応できますか？
- [ ] リソースオーバーヘッドを許容できますか？
結果:
- ✅ 10 個以上にチェック: Service Mesh を強く推奨
- 🟡 5～9 個にチェック: 慎重な評価が必要。小規模から始める（Ambient Mode を推奨）
- ❌ 4 個以下にチェック: 代替ソリューション（CNI、Ingress、アプリケーションレベル）を検討
段階的な導入戦略
Service Mesh が必要と判断した場合は、段階的に導入してください。
推奨順序:
- パイロットプロジェクト（1～2 個の namespace）
- 可観測性を優先（メトリクス、ログ、トレース）
- セキュリティを適用（mTLS PERMISSIVE → STRICT）
- トラフィック管理（VirtualService、DestinationRule）
- 全社展開
主な機能
トラフィック管理
- インテリジェントルーティングとロードバランシング
- A/B テスト、Canary デプロイメント、Blue/Green デプロイメント
- Circuit Breaking、Retry、Timeout の制御
- Traffic Mirroring と Fault Injection
セキュリティ
- サービス間の自動 mTLS 暗号化
- 強力な認証と認可
- きめ細かなアクセス制御ポリシー
- ネットワーク分離とセキュリティポリシー
可観測性
- メトリクス、ログ、トレースの自動生成
- Prometheus、Grafana、Jaeger、Kiali との統合
- サービストポロジーの可視化
- リアルタイムトラフィック監視
レジリエンス
- Circuit Breaker パターン
- Rate Limiting
- Outlier Detection
- Zone Aware Routing
Istio アーキテクチャ
Istio は Control Plane と Data Plane で構成されます。
Control Plane（istiod）:
- Pilot: Service discovery、トラフィックルーティングルールの管理
- Citadel: 証明書の生成と管理、mTLS の有効化
- Galley: 設定の検証とデプロイ
Data Plane:
- Envoy Proxy: 各 Pod に sidecar としてデプロイされ、すべてのネットワークトラフィックをインターセプトして制御する
Amazon EKS で Istio を使用する利点
- マイクロサービス管理の容易さ
- アプリケーションコードを変更せずにトラフィックを管理
- 宣言的設定による一貫したポリシー適用
- Kubernetes Native API を使用
- セキュリティの強化
- サービス間の自動暗号化
- AWS IAM と統合された認証
- きめ細かな権限制御
- 可観測性の向上
- Amazon CloudWatch との統合
- AWS X-Ray による分散トレーシング
- 詳細なメトリクスとログ
- AWS サービスとの統合
- Application Load Balancer（ALB）との統合
- AWS Certificate Manager（ACM）との統合
- Amazon EBS CSI Driver と互換
はじめに
Istio を初めて使用する場合は、次の順序でドキュメントをお読みください。
- インストールと初期設定: EKS クラスターに Istio をインストールする
- 基本概念: Istio の中核概念を理解する
- トラフィック管理: Gateway、VirtualService、DestinationRule を学ぶ
- セキュリティ: mTLS、認証、認可を設定する
- 可観測性: メトリクス、ログ、トレースを収集する
- ベストプラクティス: 本番環境向けの推奨事項
ハンズオン例
各セクションには、動作する YAML 例が含まれています。すべての例は、クリックしてコピーできるように構成されています。
# Example VirtualService
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1参考資料
クイズ
この章で学んだ内容を確認するために、以下のクイズに挑戦してください。