イラスト:Shutterstockのevv
Istio Ambient Meshは2022年9月に発表されましたが、当時の私はあまり注目していませんでした。しかし、すでにIstioをサービスメッシュとして利用している方、あるいは導入を検討している方にとって、これは従来のサイドカーモデルが抱えるいくつかの課題を解消するための重要な進化です。本記事ではその詳細を順を追って見ていきます。
注:Istio Ambient Meshはまだalpha段階であり、General Availability(GA)に到達するまでは本番環境での利用は避けるべきです。
本題に入る前に、いくつかの基礎概念を押さえておきましょう。これらを知らないと、この先の内容は象形文字のように見えてしまうかもしれません。
サービスメッシュとは
現代の多くのアプリケーションは、分散型のマイクロサービスを基盤として構築されています。各マイクロサービスは特定の機能を担い、互いに通信し合うのが一般的です。たとえるなら、石を削り出して作る一枚岩の彫像ではなく、モジュール化されたレゴブロックを組み合わせて作る彫像のようなものです。
サービスメッシュとは、こうしたアプリケーション(マイクロサービス)の上に重ねるレイヤーのことで、アプリケーション本体に手を加えることなく、トラフィック管理、可観測性、セキュリティといった機能を提供します。
Istioサービスメッシュの機能
Istioは、既存の分散アプリケーションに透過的に重ねて使えるオープンソースのサービスメッシュです。クラスタ内のサービス間通信は既定では平文であり、セキュリティ面では好ましくありません。Istioサービスメッシュは、これらの通信をmTLS(相互TLS)で暗号化し、トラフィックを保護します。さらに、以下のような機能も備えています(これらに限りません)。
- HTTP、gRPC、WebSocket、TCPのロードバランシング
- きめ細かなトラフィック制御
- アクセス制御、レート制限、クォータ
- サービスディスカバリ
- 網羅的な可観測性(クラスタ内すべてのトラフィックに対するメトリクス・テレメトリ、ログ、トレース)
サービスメッシュの概要とそのメリットを押さえたところで、従来のIstioサイドカーモデルと新しいAmbient Meshモデルを比較してみましょう。
Ambient Mesh非採用時のIstioアーキテクチャ
Istioには、コントロールプレーンとデータプレーンという2つの基本コンポーネントがあります。
データプレーンは、メッシュ内のサービス間通信を担う部分です。サービスメッシュは、メッシュ内の各サービスにサイドカーとしてデプロイされたEnvoyプロキシを利用し、メッシュ内のすべての受信・送信トラフィックがこのEnvoyプロキシを経由します。
コントロールプレーンは、これらのプロキシからデータを収集し、現在の環境の状態を望ましい状態と突き合わせながら、プロキシの構成を判断・制御します。
出典:https://istio.io/latest/docs/ops/deployment/architecture/
このモデルの課題
- 運用上の影響:コントロールプレーン経由でプロキシをアップグレードするといった変更を行う際、各サイドカーコンテナを再起動する必要があり、サービスに影響が及ぶ場合があります。
- リソース消費の大きさ:サイドカーには最悪ケースを想定したリソースを確保しておく必要があり、非効率でコスト管理者を悩ませます。
- トラフィックの不具合:HTTP実装が標準に準拠していないアプリケーションを扱う場面で発生しがちです。
サイドカーはレイヤー4とレイヤー7の双方のトラフィック処理を担います。ここで顕著な問題は、L7処理は計算負荷が非常に高いにもかかわらず、シンプルなトランスポートセキュリティしか必要としないサービスにまで一律に適用されてしまう点です。さらに、Envoyプロキシで報告される重大な共通脆弱性識別子(CVE)の多くはL7レイヤーで発生しており、L7フィルタリングを必要としないサービスにまでこれを適用することで、攻撃対象領域(アタックサーフェス)が不必要に広がってしまいます。
Ambient Mesh採用時のIstioアーキテクチャ
Istio Ambient Meshは、データプレーンのアーキテクチャに大胆な変更をもたらします。サイドカー方式では「全部入りか、何もないか」だったL4とL7の機能を、このモデルでは分離します。
出典:https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
サイドカーに代わって登場するのが、ztunnel(ゼロトラストトンネル)によるセキュアなオーバーレイです。ztunnelは共有エージェントとしてDaemonSetでデプロイされ、Kubernetesクラスタの各ノードに1つずつ配置されます。
ztunnelは、istio-cniコンポーネントに組み込まれたeBPFプログラムを用いてトラフィックをルーティングします。これにより、iptablesによるルーティングと比べてパフォーマンスと柔軟性の両面で利点があります。
各ztunnelは、自ノード内のworkloadsに対するL4トラフィックの保護を担当します。
L7機能については、ambient meshではEnvoyベースのwaypointプロキシをネームスペース単位でデプロイできます。これにより、そのネームスペース内のworkloadsはIstioのフル機能を利用できます。
出典:https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
これらのwaypointプロキシは、対象ネームスペース内のworkloadsの実際の需要に応じてスケールします。最悪ケース使用量を見越してサイドカーにリソースを確保しておく方式と比べ、はるかに効率的かつ経済的です。
L7プロキシが必要な箇所にのみ適用され、リソース効率が高く、動的かつ独立してスケールできることから、このアーキテクチャは本質的に扱いやすく、コスト効率にも優れたIstioサービスメッシュ運用を可能にします。
また、従来のサイドカーモデルとの相互運用も可能で、構成の選択肢に柔軟性が生まれます。
この新しいデータプレーンモデルには、本記事では深く扱わない2つの懸念点があります。
- パフォーマンス(ホップ数が増えることに起因)
Istioは、サイドカーモデルにおける冗長な双方向L7フィルタリングがなくなることで、ambient meshでホップが増えることによる性能低下は十分に補って余りあると説明しています。この点については、この取り組みを共同で進めているSolo.ioおよびGoogleと連携した、専用のパフォーマンス検証記事も別途公開予定とのことです。 2. セキュリティ(共有エージェントモデルに起因)
サイドカーレスのデータプレーンにおけるセキュリティ面が気になる方は、Ambient Mesh Security Deep Diveのブログ記事を一読することをお勧めします。
Ambient Meshが本番環境で動く姿を見るのが今からとても楽しみです。活用するユーザーには、大幅なコスト削減と効率化をもたらしてくれるはずです。
とはいえ、結局のところ「部屋の中の象」—すなわちEnvoyプロキシ—の存在は依然として残り、見て見ぬふりをされたままです。
サイドカーがすぐに消えてなくなるとは思いません。しかしいつの日か、軽量かつセキュアで、それでいて強力なL7処理ソフトウェアが登場し、サービスメッシュ利用者が抱える悩みを一掃してくれる日が来るかもしれません。それまでは、その方向に進む一歩一歩を歓迎したいと思いますし、皆さんもきっとそう感じるはずです。