本ブログは Mirantis社のblog記事「Return of the Smesh (Spinnaker Shpinnaker and Istio Shmistio to make a Smesh! Part 2)」の翻訳記事です。

オープンソースの世界を旅していて最初に学んだことは、与えられたアーキテクチャ内のコンポーネント設計には、より良いマウストラップを構築するための新しい異なるアプローチが常に存在すること。そして、一つのプロジェクトには、通常、新しいアプリケーションアーキテクチャを開発する際に作成された質問に対するすべての答えが含まれているわけではないということでした。

Kubernetes は、多くのアプリケーションのニーズを満たしています。
しかし、ニーズがコンポーネント間のデータのフローに依存するようになり、さらに提供するリソース間の距離が大きくなるとどうなるでしょうか？
このような場合、サービス品質 ( QoS ) などの問題が非常に重要になります。
また、個々のサービスに対するアクセスのセキュリティ要求が高まった場合はどうでしょうか？

これらの問題は、Kubernetes フレームワーク自体では対応できないニーズです。
そこで、これらのニーズを満たすための Smesh ( Service Mesh )という概念が登場します。

Smesh の核心に迫る前に、マイクロサービスのアーキテクチャと、要求されているニーズを詳しく見てみましょう。

マイクロサービスアーキテクチャ

イギリスの有名な作家でありソフトウェア開発者でもある Martin Fowler 氏は、マイクロサービスアーキテクチャのスタイルを、

「小さなサービスの集合体として単一のアプリケーションを開発するアプローチであり、それぞれが独自のプロセスで動作し、軽量なメカニズムで通信する。」

と説明していますが、多くの場合、HTTP リソースや API を介して通信しています。
Kubernetes のようなネイティブのマイクロサービス対応プラットフォームを提供することは、マイクロサービスアーキテクチャを適切にサポートするためには不可欠です。
以下は、マイクロサービスアーキテクチャがどのようにレイアウトされているかの例と、サービスがどのように相互動作するかの初歩的な図です。

Istio は、K8s フレームワークの上にレイヤリングされたサービスメッシュで、権限の定義をサポートし、帯域幅のパフォーマンスを向上させ、マイクロサービス間のデータのフローを制御します。

Smesh（サービスメッシュ）とは？ Istio やその他ツールについては…

サービスメッシュは、マイクロサービスアプリケーションのための構成可能なインフラストラクチャ層です。これにより、サービスインスタンス間の通信を柔軟性、信頼性、高速化します。メッシュは、Service discovery、Load balancing、Encryption、認証（ Authentication ） と 認可（ authorization ）、サーキットブレーカーパターンのサポート、その他の機能を提供します。

ウィリアム・モーガン氏は、サービスメッシュを「サービス間通信を処理するための専用インフラ層」と表現しています。これは、最新のクラウドネイティブアプリケーションを構成するサービスの複雑なトポロジーを介して、リクエストを確実に配信する責任があります。

サービス・メッシュ・テクノロジーには、理解するための新しい用語が独自の辞書として用意されています。
以下に、より重要な用語や概念をいくつか挙げておきますので、参考にしてください。

コンテナオーケストレーションフレームワーク：

Kubernetes はニーズを満たす最も一般的なフレームワークです。でも他にもありますよ。

Services vs. service instances：

Services という用語と service instances という用語には違いがあります。この違いは、Services がインスタンスそのものではなく定義を表しているということです。

Sidecar proxy：

Sidecar proxy は特定の service instances にアタッチします。これはオーケストレーションフレームワークによって管理され、他のすべてのプロキシ間の相互通信を処理し、 インスタンス自体へのトラフィックを減らします。

Service discovery：

この機能は、必要に応じて異なるサービスがお互いを「発見」することを可能にします。Kubernetes フレームワークは、問題なくリクエストを受け取る準備ができているインスタンスのリストを保持します。

Load balancing：

サービスメッシュでは、Load balancing 機能はスタックの最上位に最も負荷の低いインスタンスを配置し、より負荷の高いインスタンスが最も負荷の低いインスタンスの処理を奪わないようにして最大のサービス量を得ることができるようにします。

Encryption：

各サービスが独自の暗号化/復号化を提供する代わりに、サービスメッシュはリクエストとレスポンスを暗号化/復号化できます。

認証（ Authentication ） と 認可（ authorization ）：

サービスメッシュは、サービスインスタンスに送信される前にリクエストを検証できます。

サーキットブレーカーパターンのサポート：

サービスメッシュはサーキットブレーカーパターンをサポートしており、リクエストが不健全なインスタンスに送られるのを防ぐことができます。この機能については後ほど説明します。

これらの機能を組み合わせて使用することで、トラフィックシェーピングまたは QoS のための手段を提供します。パケットシェーピングとも呼ばれるトラフィックシェーピングは、ネットワーク帯域幅管理の一種で、ネットワークトラフィックの操作と優先順位付けのためのもので、他のユーザーに影響を与えるヘビーユースケースの影響を軽減します。QoS は、トラフィックシェーピングのもう一つの手段で、ネットワーク上を移動するトラフィックの様々なタイプを認識し、それに応じて優先順位を付けます。例えば、Istio は、マイクロサービスの接続、安全性の確保、管理、監視のための統一された方法を提供し、ネットワークトラフィックの優先順位付けのためにトラフィックフローのテレメトリをキャプチャしながら、マイクロサービス間のトラフィックシェーピングを提供します。

Istio には、アプリケーション開発プロセスにサーキット・ブレーキングの機能も含まれています。サーキットブレーキングは、サービス・インスタンスの健全性と実行可能性のステータスを維持することで、部分的または全体的なカスケード・ネットワーク通信障害を防ぐのに役立ちます。サーキットブレーカー機能は、トラフィックが特定のサービスインスタンスにルーティングされ続けるべきかどうかを決定します。アプリケーション開発者は、サービスインスタンスがリクエストを受け付けないとマークされたときに、設計上の考慮事項として何をすべきかを決定しなければなりません。

Istio のバックエンドプロキシとして統合されている Envoy は、サーキット・ブレーキングの機能をロードバランシングとヘルスチェックのサブセットとして扱います。Envoy は、実際のバックエンド・クラスタへの通信からルーティング方法を分離し、不健全なサービス・インスタンスやリクエストを受け付けないサービス・インスタンスへのルートを排除しています。この方法により、トラフィックを適切な健全でリクエストを受け付けるバックエンドへマッピングするために、多くの異なる可能性のあるルートを作成することができます。

以下は参考までに Istio アーキテクチャの図です。

Istioのコンポーネントとその機能は以下の通りです。

Control plane：

• Istio-Manager : Envoy プロキシにルーティングルールとサービスディスカバリ情報を提供します。
• Mixer : 各 Envoy プロキシからテレメトリを収集し、アクセス制御ポリシーを適用します。
• Istio-Auth : 「サービスからサービスへ」および「ユーザーからサービスへ」の認証を提供します。このコンポーネントはまた、必要に応じて、サービス間で暗号化されていないトラフィックを TLS ベースのトラフィックに変換します。

Data plane：

• Envoy : Control plane コンポーネントによって管理される機能豊富なプロキシ。Envoy はサービスとの間のトラフィックを遮断し、Control plane で設定されたルールに従ってルーティングとアクセスポリシーを適用します。

というわけで、基本的なことは以上です。

次回は Istio といくつかのサンプルアプリをインストールして試します。