Istioの雰囲気

6 min readMar 24, 2019

Istioとは何か

Istioはマイクロサービスがもたらした課題の１つである「複雑なサービス間通信」を解決しようとするものです。
マイクロサービス化により、多くの恩恵を受けることができました。しかし、マイクロサービスを開発・運用していると「デバッグするのが難しい」、「どこで遅延が起こっているかが分かりにくい」などの問題を感じたことがあると思います。そういった問題をアプリケーションと隔離されたレイヤで解決するのが、サービスメッシュです。サービスメッシュはアプリケーション開発者をビジネスロジックを書くことに集中させ、それ以外のマイクロサービス固有の問題から開放する救世主かもしれません。2019年の時点でおそらく最も注目を集めているサービスメッシュがIstioです。他にはLinkerd やAWS App Meshなどがあります。

Istioの特徴を以下に挙げていきます。

Google,IBM,Lyftの共同開発により、OSS化されたサービスメッシュのフレームワーク
KubernetesのPod内にSidecarとしてEnvoyをデプロイし、コードの変更なく、サービスメッシュの機能を追加できる
IstioのマニフェストはKubernetesのマニフェストのフォーマットをそのまま使用できる
Kubernetesに依存している訳ではなく、Nomadにも対応している

なぜIstioか

コードを修正することなく、マイクロサービスがもたらした多くの問題を解決できるからです。Istioは以下の課題を解決します。

トラフィックコントロール
Fault Isolation
Observability
サービス間の認証・認可

これらをすべてをアプリケーションで実装できますが、すべてのマイクロサービスに実装するのは現実的でしょうか。※1
Istioはアプリケーションのレイヤに手を入れることなく、Sidecarと呼ばれるネットワークプロキシのレイヤで上の課題を解決できます。Blue-Green Deployment、Canary Release、Circuit breaking、Fault Injectionなどを容易に行えることも魅力的でしょう。

Istioのアーキテクチャ

下の図は公式のページにあるアーキテクチャの概要です。

Data PlaneとControl Planeの２つに大別できます。図のProxyと書いているところがData Plane、帆のマークが付いているところがControl Planeです。Istioの構成要素について、それぞれ説明していきます。

Pilot

サービスディスカバリーやトラフィックコントロールの構成情報を管理しています。Envoyと連携し、サービス間の通信を制御します。

Mixer

Envoyと連携してリクエスト前のポリシー確認を行います。また、リクエスト送信後にアクセス制御やログ、トレース、メトリクスの収集を行い、PrometheusやInfluxDB、Stackdriverなどのテレメトリーサービスに連携します。

Citadel

CAとして相互TLSで使われる鍵の管理や証明書の発行を行います。

Galley

基盤となるプラットフォーム(Kubernetesなど)から取得したユーザーの詳細設定を検証し、他のIstioコンポーネントから隔離します。

Enovy

PodにSidecarとしてデプロイされたネットワークプロキシです。※2
サービスの情報、ルーティングなどをPilotから取得し、リクエストを適切なサービスのインスタンスに転送します。また、リクエストを受ける側のEnvoyはリクエストが許可されたものかをMixerに問い合わせます。処理が終われば、リクエストした側のEnvoyもリクエスト受けた側のEnvoyもMixerにテレメトリーを報告します。

現状の問題点

学習コストが高い
導入事例が少ない

Istioの導入は私のようなアプリケーションのコードを書くことがメインの開発者にとっては学習コストが高いと思います。ハマった際に原因がわからず、通信の流れを粘り強くデバッグする必要がありました。「学習コストが高い」と感じた場合はIstioのすべての機能を使いこなそうとせず、一部の機能(例えば、トラフィックコントロールの部分)のみを使って、Istioに徐々に慣れていくという戦略が現実的かと思います。
また、2019年3月時点では日本でのIstio導入事例が少ないように思います。しかし、次に書くIstio導入の敷居を下げるサービスによって導入事例が増えていく可能性があります。

サービスメッシュこそ未来

Istioに限った話ではありませんが、サービスメッシュには勢いがあります。例えば、以下のようなマネージドなサービスメッシュが台頭しています。

また、サービスメッシュのスタートアップのTetrateが1250万ドルの資金調達を行ったりと、サービスメッシュの注目が高まっていると言えるでしょう。今後、サービスメッシュを扱いやすくするプロダクトが洗練されていくと、学習コストの高さは緩和され、導入の敷居は下がってくいのではないでしょうか。

最後に

モノリシックなサービスを分割し、Kubernetes上のコンテナ環境へ移行させるだけでは、課題がいくつも残りました。そして、それらの課題の大部分はプロダクトを成長させていく上で、目を背けることができないものです。サービスメッシュにはそれらの課題を解決できるポテンシャルがあります。私はサービスメッシュやっていくぞ、という気持ちです。

参考

※1 マイクロサービスの実装言語がすべて統一されていたら、それぞれの機能をライブラリとして切り出すことは可能だと思います
※2 Envoy自体はSidecarに特化したプロキシという訳ではなく、フロントのプロキシとして使用するもできます