Istioの全貌

Istioのアーキテクチャー

図7：Istioのアーキテクチャー

図7は、Kubernetes環境に展開されたIstioの主要なコンポーネントを表しています。Istioによるサービス・メッシュ・ファブリックは、Envoyで構成されるデータ・プレーンと、Pilot、Mixer、Citadelという3つのコンポーネントを含むコントロール・プレーンから成ります。Envoyとは、多機能なプロキシーです。このEnvoyにサービス間通信を仲介させることで、アプリケーションの実装を変更することなく、トラフィック管理やセキュリティ、テレメトリーを実現します。コントロール・プレーンは不特定多数のEnvoyを管理するもので、運用管理者はコマンドラインインターフェース（Command-line Interface、CLI)を介して、Istioを制御します。

Envoy

Envoyは、C++で実装された軽量かつ高速なルーターです。プロトコルとしてHTTP、gRPC、TCPをサポート、そしてレイヤー4/7をカバーし、TLS終端処理、動的なサービス・ディスカバリー、ヘルス・チェック、ロード・バランシング、WBR、CBR、サーキット・ブレーカー、フォールト・インジェクション、メトリクス収集等様々な機能を提供します。元々はLyft, Inc.が開発していましたが、現在はCNCF所管のOSSプロジェクトとして公開されています。

Istioは、コンテナとして提供されているEnvoyを、各サービスがデプロイされているPodにデプロイします。つまり各Podの中で、サービスと対になるEnvoyが存在する形態となります。主要な機能を提供するコンポーネント（この場合はサービス）に対して、補完機能を提供する別個のコンポーネント（この場合はEnvoy）をデプロイするデザイン・パターンを「サイドカー・パターン」と呼び、補完機能を提供するコンポーネントは「サイドカー」と呼ばれます。サイドカーであるEnvoyは、プロキシーとしてサービスの通信の全てを仲介します。通信仲介の過程でEnvoyの豊富な機能を駆使することによって、サービス・メッシュ上で、カナリア・リリースやカオス・エンジニアリングの実践といった様々なタスクを実行できるのです。

Envoyそのものを単独で利用することもできますが、膨大な数のサービスと同数のEnvoyを個別に手作業で管理するのは、非常に手間がかかります。そこで、分散配置されたEnvoyを管理するための管理機能としてコントロール・プレーンが提供されています。例えば、Envoyは自身のヘルス・チェックで得られた情報と、Pilotから入手した情報を踏まえ、ロード・バランシングの宛先情報を保守します。また、サービス呼出し後、テレメトリー情報をMixerに送付します。

Pilot

Pilotは、コントロール・プレーンを形成するコンポーネントの一つで、Envoyの構成管理を司ります。主に、サービス・ディスカバリーやトラフィック管理の観点から、Envoyに構成情報を連携し、サービス間の動作を制御するのがPilotの役割です。

図8：PilotとEnvoyによるサービス・ディスカバリー

PilotとEnvoyは次のような流れでサービス間通信を実現します。まず始めに呼び出し元サービスは、呼び出し先サービスのアドレス（ドメイン名）を特定しなければなりません。この時、ネーミング・サービスに対するサービスの登録とサービスの発見、すなわちサービス・ディスカバリーの仕組みが必要になります。サービス・ディスカバリーは、KubernetesをはじめIstioの基盤として稼動するオーケストレーション・フレームワークによって実装されています。よって、IstioはIstio独自のサービス・ディスカバリー機能を提供するのではなく、オーケストレーション・フレームワークが提供するサービス・ディスカバリーを利用します。すなわち各サービスは、オーケストレーション・フレームワークの機能を使ってサービスを登録します（図8の1）。その一方で、Pilotはオーケストレーション・フレームワークのサービス・ディスカバリー機能を利用して、サービスを発見（サービス・ディスカバリー）するAPIを提供します。Envoyは、Pilotの提供するAPIを利用して、呼び出し先サービスの宛先情報を入手します（図8の2）。

次に、呼び出し元サービスから呼び出し先サービスにリクエストが送信されますが、この時、呼び出し元サービス側のEnvoyはリクエスト送信のロード・バランシングを実行します（図8の3）。Envoyそのものは多くのロード・バランシングのアルゴリズムをサポートしますが、Istioがサポートするのは、ラウンド・ロビン、ランダム、重み付け最小リクエスト（Weighted Least Request）の3種類です。Envoyは、ロード・バランシング先のインスタンスに対して定期的なヘルス・チェックを実行し、問題のあるインスタンスはロード・バランシング対象から外します。ちなみにこのヘルス・チェックにおいて、前述のサーキット・ブレーカー・パターンを活用しています。

さて、サービス・ディスカバリーの動作シナリオに見られるように、Istioは自身で全ての機能を実装するのではなく、必要に応じてIstioの基盤となるオーケストレーション・フレームワークの機能を利用します。Istioはマルチ・プラットフォーム・サポートを標榜していますので、複数のオーケストレーション・フレームワークにも対応できるような仕掛けを用意しています。Pilotの場合、プラットフォーム・アダプター、抽象モデル、Envoy APIという3つのコンポーネントを使って、マルチ・プラットフォーム・サポートを実現しています（図9）。

図9：Pilotのアーキテクチャー

プラットフォーム・アダプターとは、Istioの基盤となるオーケストレーション・フレームワークとのインターフェースを提供するコンポーネントです。プラットフォーム・アダプターを介してPilotは実装の異なる各オーケストレーション・フレームワークと協業します。プラットフォーム・アダプターはオーケストレーション・フレームワークの実装に依存ことになるのですが、特定の実装への依存を断ち切るために抽象モデルのレイヤーが、そしてEnvoyとのインターフェースとなるEnvoy APIが配置されます。このようなアーキテクチャーを取ることで、PilotとEnvoyが連携しながら、特定のオーケストレーション・フレームワークに依存することなく、サービス・ディスカバリーとトラフィック管理サービスを提供できるのです。

Mixer

ICTシステムには「基盤バックエンド」と呼ばれる、いわば裏方の仕組みが必ず必要になります。基盤バックエンドの例としては、アクセス制御、あるいはログやトレース、メトリクスの収集（テレメトリー）、そしてCPU等のシステム・リソースの割当管理などが挙げられます。多くの場合、製品が基盤バックエンドの基本機能を提供しますが、それを使いこなすには、アプリケーションの中に基盤バックエンド機能を呼び出すロジックを組み込まねばなりませんでした。このような非機能要件にまつわる実装をアプリケーションに組み込む作業は、アプリケーション開発者にとって大きな負担となっています。

もちろん基盤バックエンドは、クラウド・ネイティブ・アプリケーションでも必要となります。従来以上に複雑な分散コンピューティング環境であるサービス・メッシュにおいて、基盤バックエンドの構築と運用をよりシンプルな作業とし、アプリケーション開発者の負担を軽減することが、Istioの目標の一つであり、Mixerはそのためのキーとなるコンポーネントです。

Mixerは、サービス・メッシュ上でポリシー管理とテレメトリーを制御する管理コンポーネントです。Envoyと連携して、アクセス制御や、ログ、トレース、メトリクスの収集を実行します。図10を用いて、Mixerの概要と動作シナリオを説明しましょう。

図10：Mixerのアーキテクチャー

Mixerは、Pilotと同じように、アダプターという仕組みを備え、これを介して様々な基盤バックエンド機能をプラグインできる、モジュラー構造を有しています。アダプターによって、アクセス制御やテレメトリーに限らず、様々な機能を容易に追加できる柔軟性を持っているのがMixerの特徴の一つです。

一方Envoyは、他のサービスへのリクエスト送信前後にMixerを呼び出します。リクエスト送信前にはアクセス制御等の事前チェックを行い、リクエスト送信後はMixerにメトリクスを送信するのです。このように、ポリシー管理とテレメトリーは、EnvoyとMixerの連携によって処理されます。アプリケーションであるサービスの中に、ポリシー管理やテレメトリーのための実装を追加する必要はありません。つまりMixerは、従来基盤バックエンドを使いこなすために求められてきたアプリケーション開発者の負担を軽減するのです。

またIstioは、Envoyには1次キャッシュ、Mixerには2次キャッシュを組み込んでいます。この2レベルのキャッシュによって、EnvoyとMixer間、そしてMixerと基盤バックエンド間の通信頻度を抑え、より良いパフォーマンスと高い可用性を両立します。

セキュリティ・アーキテクチャーとCitadel

ICTシステムを安全に保つために求められる認証、認可、改竄の防止、監査等のセキュリティ対策は、サービス・メッシュであってももちろん必要です。サービス・メッシュのセキュリティ対策では、動的に構成変更が発生しうる、不特定多数のサービス間通信が保護対象となりますので、より複雑で手間のかかる作業となることが想定されます。セキュリティ対策の負担を軽減して安全なアプリケーション稼動基盤を実現するために、Istioは強固なアイデンティティとポリシーの管理、相互TLSによる認証・認可と暗号化、そして監査といった諸機能を提供し、サービス間通信の安全性を担保します。

図11：Istioのセキュリティ・アーキテクチャー

図11はIstioにおけるセキュリティ対策の全体像を示したものです。Pilotはトラフィック管理の構成情報に加えて、認証のポリシー情報をEnvoyの各インスタンスに配布します。認証のポリシーとは、認証対象のサービスや、サービスの範囲を規定するメタ情報です。認証処理そのものは、Pilotから送付されたポリシー情報を基にEnvoyが実行します。

認証で取られる手法が、相互TLS認証というものです。相互TLSとは相手サービスを呼び出すクライアント側と、呼び出されるサーバー側の双方が、通信相手を認証するものです。まずサービスの呼び出し元であるクライアント側のEnvoyが、呼び出し先のEnvoyを介してサーバー側のアイデンティティをチェックし、呼び出し先サービスが適切か確認します。次に呼び出し先のEnvoyが、呼び出し元の認可や監査を行います。このようなプロセスを経て、呼び出し元Envoyと呼び出し先Envoyの間でTLSコネクションが確立され、サービス間通信が実行されます。これがIstioで採用している相互TLSによる認証の流れです。

このようなスキームの中で、CAとして鍵の管理や証明書の発行を担うのがCitadelです。Citadelは、PilotやMixerと同様に、コントロール・プレーンを構成する管理コンポーネントで、以前は「Istio-Auth」あるいは「Istio-CA」と呼ばれていました。また基盤バックエンドと連携して認可の実装を提供するのが、前述のMixerとなります。