Istioを使ったサービスメッシュ構築 - 概要

マイクロサービスアーキテクチャを採用している場合、複数のサービスの集合としてシステムが構築され、マイクロサービスの依存関係やAPIコールスタックが複雑になりやすくなります。

このマイクロサービスがメッシュ（網目）状に複雑に絡み合った状態は、「サービスメッシュ」と呼ばれます。サービスメッシュにおいて、マイクロサービス個別の設定・管理を行うのは困難なため、マイクロサービス間を横串で捉えた管理が課題となります。この課題を解決するのが「Istio」です。Google/IBM/Lyftにより共同開発され、2017年5月24日にOSSとして発表されました。

Istioでは、「Control Plane」と「Data Plane」が協調動作することで、サービスメッシュを構成するサービス間の通信を統一的に制御します。

• Control Plane：Istio本体。サービスディスカバリや証明書の管理などを行う
• Data Plane：アプリケーションロジックと直接関係のない処理を独立させるため、プロキシ（Envoy）をサイドカーパターンコンテナとして導入する。これにより、サービス間のルーティング制御を行ったり、過負荷時のサーキットブレーカーとして動作したりする

Istioの類似プロダクトとして、「Linkerd」「Kuma」などがあります。Linkerdは2021年7月28日、CNCF（Cloud Native Computing Foundation）のGraduatedプロジェクトになったことがアナウンスされました。

サービスメッシュに関しては、2020年8月7日、マイクロソフトが「Open Service Mesh」をOSS実装として発表しました。また、2021年2月22日に、マイクロソフトがオープンソースの分散アプリケーションランタイム「Dapr」のv1.0をリリースしました。

Istio「3つの特徴」

Istioには、大きく分けて3つの特徴があり、ルーティング制御などさまざまな処理方式をマイクロサービスのアプリケーションから独立させて設定・実現できます。これにより、アプリケーションの独立性が高まり、保守性・変更容易性が向上します。個別の機能の説明や使い方については次回以降に説明するので、今回はざっくり理解していただければ大丈夫です。

• Traffic Management：ルーティング制御、ゲートウェイ、サーキットブレーカー、カオスエンジニアリング
• Observability：メトリクス、分散トレーシング、アクセスログ管理
• Secure：鍵や証明書の管理、認証（Authentication）、認可（Authorization）

Istioのコンポーネントの構成要素と歴史

IstioのControl Planeは「istiod」により動作します。2020年5月19日に「Introducing istiod: simplifying the control plane」が発表され、以下のコンポーネントはistiodに集約されました。

• Pilot：サービスディスカバリ
• Citadel：証明書管理
• Galley：EnvoyプロキシのConfiguration管理

Istioの初学者の方は、機能を細かく理解しておく必要はありません。「Control Planeを構成するIstiodが持つ機能にはこんなものがあるんだな」という程度に理解しておいてください。

2020年5月5日に、「Redefining extensibility in proxies - introducing WebAssembly to Envoy and Istio」が発表され、Proxy-WASM(WebAssembly)によるEnvoyプロキシの拡張機能が紹介されました。

同様の機能を担っていたMixerコンポーネントは、将来リリースでコミュニティプロジェクトに移管され、レガシーユースケースにのみ利用可能とされることとなりました。

日付の古いブログサイトなどでは、Mixerの記述が残っているケースもあると思いますので、意識しておくと良いでしょう。

*　*　*

今回はサービスメッシュについてIstioを中心に解説しました。IstioはTraffic Management/Observability/Securityの3つの特徴を持ち、マイクロサービスを構築する手助けをします。 マイクロサービスの流行・進展は、これからも続いていくと考えられます。サービスメッシュについて深く理解しておくためにも、まずはIstioに触れてみてはいかがでしょうか。次回は、実際にIstioのインストールからサービスメッシュの構築までの手順を紹介します。