「サービスメッシュ」「Istio」って何？ どう使える？ どう役立つ？：寺田佳央氏が分かりやすく説明

マイクロサービスに関わる人々の間で、「サービスメッシュ」「Istio」への注目が高まっている。これについて、Javaコミュニティーで広く知られる日本マイクロソフトのテクニカルエバンジェリスト、寺田佳央氏がデモを交え、分かりやすく説明した。寺田氏の説明を要約してお届けする。

[三木泉，＠IT]

　マイクロサービスに関わる人々の間で、Istioへの注目が高まっている。これはGoogle、IBM、Lyftが開発し、2017年5月にオープンソース化したソフトウェア。「サービスメッシュ」と呼ばれる機能を果たす。サービスメッシュでは、マイクロサービス間の通信を統一的な仕組みで制御。これにより、きめ細かなセキュリティの確保、流量制御、フェイルオーバー、ブルー／グリーンデプロイメント、カナリアデプロイメントなどを容易にする。

参照記事：新OSSプロジェクト「Istio」は、マイクロサービスのためのサービスメッシュを開発

　Istioでは、Lyftが開発してオープンソース化したプロキシソフトウェアEnvoyを用い、これを各マイクロサービスに配置、これらを統合的に設定する。現時点ではKubernetes上でのみ動いているが、今後Cloud FoundryやMesos上でも使えるようになる。

　このIstioについて、Javaコミュニティーで広く知られる日本マイクロソフトのテクニカルエバンジェリスト、寺田佳央氏がデモを交え、分かりやすく説明した。以下に、寺田氏の説明を要約してお届けする。なお、このプレゼンテーションは、2018年1月30日に開催された、Payara、Hazelcast日本法人設立イベントで行われた。

開発言語に非依存のマイクロサービス間通信制御を実現

日本マイクロソフトのテクニカルエバンジェリスト、寺田佳央氏

　マイクロサービスアーキテクチャのアプリケーションでは、やるべきことや、ベストプラクティスのデザインパターンがいろいろある。例えば同一アプリケーションを構成する他のマイクロサービスの存在を自動的に検知（サービスディスカバリ）できるかどうかで、アプリケーションの運用効率が大きく変わる。ネットワーク制御、デプロイメント方法（ブルー／グリーン、カナリアなど）についても考える必要がある。リトライ／タイムアウト、負荷分散、サーキットブレーカー／バルクヘッド、流量制御、障害検知、監視、ログ出力などを実現する機能が求められる。

　これらをアプリケーションに組み込むことが大きな負担になっている。現在のところ、多くの開発者は各種のライブラリから、必要な機能を果たすものを選択してアプリケーションに実装している。Javaにおける例としてはSpring Cloud Config、Spring Cloud Security、Netflix OSSに含まれるHystrix、Eureka、Ribbon、Zuul、AkkaのCircuit Breakerなどがある。

　しかし、マイクロサービスアーキテクチャのアプリケーションは、異なる開発言語で開発されたマイクロサービスで構成されるケースが増えてくる。すると開発者は、開発言語ごとに適切なライブラリを調べ、使い方を習得して各マイクロサービスに組み込まなければならない。これは大きな負担だ。

　そこで登場するのがIstioの採用する「サイドカーパターン」。この言葉は耳慣れないかもしれないが、Java開発者にとっては「CDI（Contexts and Dependency Injection）」と同様の構成を意味するので分かりやすい。CDIでは実装クラスを直接触るのではなく、プロキシオブジェクトを触る。CDIはJavaのクラスレベルの話だが、これをサービスレベルにしたのがIstioのサイドカーパターン。すなわち、ネットワーク制御、流量制御、監視などの機能を、アプリケーションに埋め込むのではなく、プロキシプロセスとして動かす。

Istioでは、各マイクロサービスでプロキシを動かす

　具体的には、IstioではKubernetesのデプロイメント単位でプロキシサーバが動作し、これらが相互に通信する構成になる。Istioでは、プロキシサーバとしてLyftが開発したEnvoyを使っている。

さまざまなデプロイメントパターンを支援

　Istioでは、監視については設定なしに、制御についてはシンプルな設定ファイルを書けば、コマンド1つで各プロキシに適用できる。

　例えば、IstioにモニタリングツールのPrometheus、可視化ツールのGrafanaを組み合わせれば、ログを個々に見ていく代わりに、何が起こっているかをリアルタイムでモニターできる。また、Jaegerなどの分散トレーシングツールを併用し、マイクロサービス間の依存関係を可視化し、レイテンシなどの指標を監視できる。

マイクロサービス間の依存関係を可視化

　ネットワーク制御については、RouteRuleとしてyamlファイルに簡単な設定をするだけで、適用できる。これによって、デプロイメントに関連した多様なシナリオに対応できる。

　例えば、ある本番稼働中のアプリケーションで、新たなバージョンを開発したとする。本番稼働のバージョンを「バージョン1」とし、新たに開発したバージョンを「バージョン2」とする。

　この場合、まず、フロントエンドからの呼び出しを、本番稼働するバージョン1に100％向けるルールを適用できる。一方、開発者など、「リクエストに特定ヘッダが付加された人のみ、バージョン2にアクセスできる」というルールを書き、適用することもできる。

ヘッダを用い、特定ユーザーに対して新バージョンを提供する

ヘッダに基づいてアクセスを振り向けるルールを適用

　さらに、カナリアリリースのために、例えば「リクエストの80％はバージョン1、20％はバージョン2を呼び出す」というルールを記述し、実行することも可能だ。

　こうして、マイクロサービスアーキテクチャを採用する最大の目的ともいえる、モジュール単位の頻繁なアップデートを、プロセスとして容易に管理できるようになる。