組織がマイクロサービスに移行する場合、数十から数百の固有のアプリケーションをサポートする必要があります。 これらのエンドポイントを別々に管理するということは、要求を含め、大量の仮想マシン（VM）をサポートするということです。 Kubernetesのようなクラスター・ソフトウェアは、ポッドを作成してスケーリングすることができますが、Kubernetesはルーティング、トラフィック・ルール、強力なモニタリング・ツールやデバッグ・ツールは提供しません。

そこでサービス・メッシュの登場です。

サービスの数が増えるにつれて、潜在的に可能な通信パスは指数関数的に増加します。 2つのサービスには2つの通信パスしかありません。 3つのサービスには6つの通信パス、10のサービスには90の通信パスがあります。 サービス・メッシュは、通信のポリシーを作成することによって、それらの通信パス を構成する統一的な方法を提供します。

サービス・メッシュはサービスを計測し、事前定義された構成に従って通信トラフィックを誘導します。 つまり、管理者は、実行中のコンテナを構成する（そのようにコードを書く）のではなく、サービス・メッシュを構成しておくと、サービス・メッシュにその作業を完了させることができるということです。 以前、Webサーバーとサービス間通信では、常にこれが行われていました。

クラスターでこれを行う最も一般的な方法は、サイドカー・パターンを使用することです。 サイドカーとは、ポッド内部の新しいコンテナで、サービスとコンテナの間の通信トラフィックを経路指定して監視するものです。

前述のように、IstioはKubernetesの上にレイヤーを作り、基本的にプログラマーや管理者には見えないコンテナを追加します。 「サイドカー」コンテナと呼ばれるこれらのコンテナは、「中間者」として機能し、トラフィックを誘導してコンポーネント間の対話をモニタリングします。 この2つが組み合わされ、構成、モニタリング、管理の3つの機能を果たします。

構成

Kubernetesを使用して構成を設定するための主な手法は、kubectlコマンドです。このコマンドは通常、「kubectl -f」です（ここで、ファイルはYAMLファイルです）。 Istioユーザーは、kubectlで別の新しい種類のYAMLファイルを実行するか、あるいは新しいオプションのioctlコマンドを使用することができます。

モニタリング

Istioを使用すると、Kubernetesで実行しているアプリケーションの正常性を容易にモニターできます。 Istioの計測では、アプリケーションの正常性を管理して視覚化することができ、Kubernetesが提供するクラスターやノードの一般的なモニタリングよりも、多くの洞察が得られます。

管理

IstioのインターフェースはKubernetesと本質的に同じものなので、それを管理することに追加の作業はほぼ必要ありません。 Istioでは、ユーザーはKubernetesクラスター全体に影響を及ぼし管理するポリシーを作成することができます。それにより、カスタム管理コードが不要になり、各クラスターを管理する時間を短縮できます。

サービス・メッシュの主なメリットは、強化されたデバッグ、モニタリング、ルーティング、およびセキュリティーの機能を利用できることです。 つまりIstioでは、より少ない労力でより幅広いサービス・グループを管理できるようになります。

デバッグの向上

例えば、サービスに複数の依存関係があるとします。 ある保険会社のpay_claimサービスは、deductible_amtサービスを呼び出し、このサービスはis_member_coveredサービスを呼び出すといったように続くとします。 複雑な依存関係の連鎖になると、10から12のサービス呼び出しが含まれることがあります。 これら12のサービスのいずれかに障害が発生すると、連鎖的に障害が発生し、その結果500番台エラーや400番台エラーが発生したり、場合によっては応答がまったくなかったりすることがあります。

その一連の呼び出しをデバッグするため、スタック・トレースに似た仕組みを使用できます。 フロントエンドでは、クライアント・サイドの開発者がWebサーバーからどのようなエレメントがどのような順序で取り出されているかを確認し、それらを調べることができます。 フロントエンドのプログラマーは、ウォーターフォール・ダイアグラムを取得してデバッグを補助することができます。

この例では、データセンターで何が起きているか、つまりcallback=parselLotamaAudiencesが他の4つのWebサービスをどのように呼び出しているか、応答が特に遅いのはどれかについては示されていません。 後ほど、Istioが関数呼び出しをトレースするためのツールをどのように提供するかについて、この例に似た図を使用して説明します。

モニタリングおよびプログラム識別情報

DevOpsチームおよびIT管理者は、トラフィックを監視して、待ち時間、サービス時間、トラフィックにおけるエラーの割合などを確認したい場合があります。 そのような場合は、ダッシュボードで見たいと考えるでしょう。 ダッシュボードは、時間の経過に伴う合計、平均、あるいはそれらのメトリックを視覚化したものを提供し、通常、特定のノード、サービス、ポッドに「ドリルダウン」する機能が備えられています。 Kubernetesはこの機能をネイティブに提供しません。

ポリシー

Kubernetesではデフォルトで、すべてのポッドが他のすべてのポッドにトラフィックを送信できます。 Istioでは、管理者がポリシーを作成して、相互に連携できるサービスを制限することができます。 例えば、サービスが真の依存関係にある他のサービスのみを呼び出せるようにすることができます。 サービスを機能させ続けるためのもう1つのポリシーは、レート制限です。これによって、多すぎるトラフィックがサービスを妨害するのを阻止し、サービス妨害（DoS）攻撃を防ぎます。

ルーティングとロード・バランシング

Kubernetesにはデフォルトでラウンドロビン・ロード・バランシング機能が備わっています。 1つのマイクロサービスを提供する6つのポッドがある場合、Kubernetesは、要求を各ポッドに昇順に送信した後、また最初に戻って送信するロード・バランサー（「サービス」）を提供します。 しかし企業は、同じサービスの異なるバージョンを実動環境にデプロイすることがあります。

この最も簡単な例が、Blue/Greenデプロイです。 このケースでは、ソフトウェアはまったく新しいバージョンのアプリケーションを実動にビルドすることがありますが、それには実動ユーザーの要求は送信されません。 新しいバージョンをプロモートした後、企業は古いサーバーを保持して、障害が発生した場合に迅速にスイッチバックすることができます。

Istioでは、これは構成ファイルでのタグ付けの使用と同じくらい簡単です。 また、管理者はラベルを使用して接続先のサービスの種類を示したり、ヘッダーに基づいてルールを構築したりすることもできます。 例えば、ベータ・ユーザーは最新かつ最大のビルドを含む「カナリア」ポッドに、そして通常のユーザーは安定した実動ビルドにルーティングされます。

回路遮断

サービスが過負荷またはダウン状態になると、それが続いている間はそれ以上の要求は失敗します。 Istioはエラーと遅延をトラッキングしているため、ポリシーによって設定された特定数の要求の後、強制的に一時停止してサービスを復旧させることができます。 小さなテキスト・ファイルを作成し、それを新しいポリシーとして使用するようIstioに指示することによって、クラスター全体にわたってこのポリシーを適用することができます。

高い安全性

Istioは、認証、許可、および監査（AAA）とともに、ID、ポリシー、暗号化をデフォルトで提供します。 他のポッドと通信する管理下のポッドはすべて暗号化トラフィックを使用するため、監視できません。 IDサービスは、暗号化と組み合わされ、無許可ユーザーがサービス呼び出しを偽造（「スプーフ」）できないようにします。 AAAは、少ないオーバーヘッドでモニターするために必要なツールをセキュリティーおよび運用の担当者に提供します。

管理の簡素化

従来のアプリケーションでは、Istioが提供するID、ポリシー、およびセキュリティーの各機能が依然として必要です。 そのためプログラマーと管理者は、不適切な抽象化レベルで作業し、すべてのサービスに対して同じセキュリティー・ルールを何度も再実施しなければなりません。 Istioでは、プログラマーと管理者は、単一のコントロール・パネルを使用して、クラスターのポリシーを設定し、適切なレベルで作業を行うことができます。