Istio とは？サービスメッシュが必要になる理由から学ぶ

Flaty

この記事で分かること

Istio が解決する問題
サービスメッシュとは何か
Istio の仕組み（データプレーンとコントロールプレーン）
サイドカーモードと Ambient モードの違い
Istio で何ができるか

Kubernetes を使い始めると、いずれ「Istio」という名前を目にします。しかし、公式ドキュメントを読んでも「サービスメッシュ」「サイドカー」「Envoy」など聞き慣れない用語が並び、結局何をするものなのかわかりにくいと感じる人も多いのではないでしょうか。

この記事では、Istio とは何か、なぜ必要なのかをできるだけわかりやすく整理します。

Istio が解決する問題

Istio を理解するには、まず「何を解決するのか」を知るのが近道です。

マイクロサービスが増えると辛くなること

Kubernetes でアプリケーションを運用していると、サービスの数が増えていきます。最初は数個だったものが、数十、数百になることもあります。

サービスが増えると、サービス間の通信に関する課題が出てきます。

認証・認可: サービス A からサービス B へのリクエストは許可すべきか？
暗号化: 通信内容を盗聴されないようにするには？
リトライ・タイムアウト: サービス B が一時的に応答しない場合どうするか？
トラフィック制御: 新バージョンに少しずつトラフィックを流したい
可観測性: どのサービス間の通信で遅延が発生しているか？

各サービスに実装する辛さ

これらの課題を解決するコードを、各サービスに実装することは可能です。しかし、サービスが増えるたびに同じ処理を書くのは非効率ですし、言語やフレームワークが異なれば実装も変わります。

さらに、「リトライ回数を変えたい」「タイムアウトを調整したい」となったとき、全サービスを修正してデプロイし直すのは現実的ではありません。

Istio は、こうした通信に関する処理をアプリケーションから切り離し、インフラ層で一元管理することで解決します。

サービスメッシュとは

Istio は「サービスメッシュ」を実現するためのツールです。では、サービスメッシュとは何でしょうか。

通信の責務をアプリから切り離す

サービスメッシュは、サービス間通信を管理するためのインフラ層です。

従来、通信に関する処理（リトライ、タイムアウト、暗号化など）はアプリケーション内に実装していました。サービスメッシュでは、これらの責務をアプリケーションの外に出します。

アプリケーションは「リクエストを送る」という単純な処理だけを行い、それ以外の通信制御はサービスメッシュに任せます。

サイドカーパターン

サービスメッシュの代表的な実装方式が「サイドカー」パターンです。各 Pod にプロキシを配置します。

バイクの横に取り付けるサイドカー（側車）をイメージしてください。本体（アプリケーション）の横に、常に一緒に動くもう一つのコンテナ（プロキシ）がついています。

アプリケーションからの通信は、すべてこのサイドカープロキシを経由します。プロキシが通信を仲介することで、アプリケーションを変更せずに通信制御が可能になります。

Istio の仕組み

Istio はデータプレーンとコントロールプレーンの 2 つで構成されています。

データプレーン

実際の通信を処理する部分です。モードによって構成が異なります。

サイドカーモードでは、各 Pod に配置される Envoy プロキシがこの役割を担います。Envoy はすべてのインバウンド/アウトバウンド通信を仲介します。

Ambient モードでは、各ノードの ztunnel が L4（TCP/UDP）通信を処理し、必要に応じて Waypoint proxy（Envoy）が L7（HTTP）通信を処理します。

サイドカーモードでは各 Pod にプロキシが配置されるため、Pod 数に比例してリソース消費が増加します。Ambient モードではこの課題が解消され、アプリケーション Pod へのコンテナ注入も不要です。Istio v1.24（2024 年 11 月）で GA（正式リリース）となり、新規導入では Ambient モードが推奨されつつあります。

いずれのモードでも、データプレーンは以下を実行します。

トラフィックのルーティング
負荷分散
TLS 暗号化
メトリクス収集

コントロールプレーン

データプレーンを管理する部分です。istiod という単一のコンポーネントがこの役割を担います。

istiod は以下を行います。

プロキシへの設定配布
証明書の発行・管理
サービスディスカバリ

リクエストの流れ

サービス A からサービス B へリクエストを送る場合（サイドカーモード）：

サービス A がリクエストを送信
サービス A のサイドカー（Envoy）がリクエストを受け取る
Envoy が設定に従って通信制御（mTLS 暗号化、リトライなど）を適用
サービス B のサイドカー（Envoy）がリクエストを受け取る
サービス B にリクエストが届く

Ambient モードの場合：

L7 機能（HTTP ルーティング、リトライなど）が必要な場合は、ztunnel から Waypoint proxy を経由します。

アプリケーションから見ると、いずれのモードでも普通に HTTP リクエストを送っているだけです。暗号化やリトライはプロキシが透過的に処理します。

Istio で何ができるか

Istio の主な機能は 3 つに分類できます。

トラフィック管理

サービス間のトラフィックを細かく制御できます。

カナリアリリース: 新バージョンに 10% だけトラフィックを流す
A/B テスト: 特定のヘッダーがあるリクエストだけ別バージョンに振り分け
フォールトインジェクション: 意図的に遅延やエラーを発生させて耐障害性をテスト
サーキットブレーカー: 障害が発生したサービスへのリクエストを遮断

また、メッシュの境界で外部との通信を制御する Ingress Gateway（入口）と Egress Gateway（出口）も提供します。

これらを YAML で宣言的に設定でき、アプリケーションの変更は不要です。設定には Istio 独自の VirtualService/DestinationRule に加え、Kubernetes 標準の Gateway API も利用できます（Istio 1.22 で Stable）。

セキュリティ

サービス間通信のセキュリティを強化します。

mTLS（相互 TLS）: サービス間通信を自動で暗号化
認証: リクエスト元のサービスを識別
認可:「サービス A からサービス B へのアクセスは許可、サービス C からは拒否」といったポリシーを設定

Istio を導入すると、プロキシ間の通信では Auto mTLS により自動的に mTLS が使用されます。

ただし、デフォルトは PERMISSIVE モードです。これはプロキシを経由しない平文通信も受け入れるモードで、段階的な導入を容易にするための設計です。mTLS を強制するには、PeerAuthentication リソースで STRICT モードを設定します。

証明書の発行・更新は Istio が自動で行うため、運用負荷が大幅に下がります。

可観測性

サービス間通信の状態を可視化します。

メトリクス: リクエスト数、レイテンシ、エラー率など
分散トレーシング: リクエストがどのサービスを経由したか追跡（サービスをまたいだトレースを繋げるには、アプリケーション側でトレースヘッダーの伝搬が必要）
アクセスログ: すべての通信ログを収集

これらのデータは以下のようなツールと連携して可視化できます。

Prometheus + Grafana: メトリクスの収集とダッシュボード表示
Jaeger: 分散トレーシングの可視化
Kiali: Istio に特化したサービスメッシュの可視化（依存関係やトラフィックの流れを確認）

OpenTelemetry との統合も進んでおり、既存の監視基盤と柔軟に連携できます。

Kubernetes と Istio の関係

Kubernetes と Istio は役割が異なります。

項目	Kubernetes	Istio
役割	コンテナのオーケストレーション	サービス間通信の管理
対象	Pod、Deployment、Service など	サービス間のトラフィック
主な機能	スケジューリング、スケーリング、セルフヒーリング	ルーティング、mTLS、可観測性

Kubernetes は「コンテナをどこで動かすか」を管理し、Istio は「コンテナ間の通信をどう制御するか」を管理します。

Istio は単体では動作せず、Kubernetes 上で動作することが前提です。VM 上のワークロードをメッシュに参加させることも可能ですが、Istio のコントロールプレーンは Kubernetes の API に依存しています。

まとめ

Istio は、マイクロサービス間の通信に関する課題を解決するサービスメッシュ
サイドカーモードと Ambient モードの 2 つのデータプレーンがあり、アプリケーションを変更せずに通信制御が可能
主な機能は「トラフィック管理」「セキュリティ」「可観測性」の 3 つ
Kubernetes がコンテナ管理、Istio がサービス間通信管理と役割が分かれている
新規導入では Ambient モードが推奨されつつあり、リソース効率と運用のシンプルさが特徴

参考

#Istio #サービスメッシュ

ABOUT ME