サービス メッシュについて
サービス メッシュは、サービス間の通信を支援する、アプリケーションのインフラストラクチャ レイヤーです。 サービス メッシュは、ワークロードに対するトラフィック管理、回復性、ポリシー、セキュリティ、強力な ID、監視などの機能を提供します。 アプリケーションはこれら運用上の機能から切り離され、サービス メッシュによりアプリケーション レイヤーからインフラストラクチャ レイヤーに移されます。
シナリオ
サービス メッシュを使用する場合は、次のようなシナリオを実現できます。
クラスター内のすべてのトラフィックの暗号化: クラスター内の指定されたサービス間で相互 TLS を有効にします。 これは、ネットワーク境界のイングレスとエグレスに拡張でき、アプリケーションのコードとインフラストラクチャを変更せずに、既定で安全なオプションを提供します。
カナリアおよびフェーズ ロールアウト: クラスター内の一連の新しいサービスにルーティングされるトラフィックのサブセットの条件を指定します。 カナリア リリースのテストが成功したら、条件付きルーティングを削除し、新しいサービスへのすべてのトラフィックの割合を徐々に増やします。 最終的には、すべてのトラフィックが新しいサービスに送信されます。
トラフィック管理と操作: 特定の配信元からサービス バージョンへのすべてのトラフィックをレート制限するサービス ポリシー、または指定されたサービス間の障害クラスに再試行戦略を適用するポリシーを作成します。 移行中または問題をデバッグするために、新しいバージョンのサービスにライブ トラフィックをミラーリングします。 テスト環境のサービス間にフォールトを挿入して、回復性をテストします。
監視: サービスがどのように接続されているか、およびサービス間を流れるトラフィックの分析情報を取得します。 イングレス/エグレスを含め、クラスター内のすべてのトラフィックのメトリック、ログ、トレースを取得します。 アプリケーションに分散トレース機能を追加します。
選択条件
サービス メッシュを選ぶ前に、要件と、サービス メッシュをインストールする理由を理解していることを確認してください。 以下の点を確認してください。
イングレス コントローラーはニーズに対して十分か?: 必要なシナリオへ対応するには、A/B テストや、イングレスでのトラフィック分割などの機能で十分な場合があります。 環境に利点のない複雑さを加えないでください。
ワークロードと環境は追加のオーバーヘッドを許容できるか?: サービス メッシュのサポートに必要なすべてのコンポーネントには、CPU やメモリなどのリソースが必要です。 すべてのプロキシと、関連付けられているポリシー チェックにより、トラフィックに待機時間が追加されます。 待機時間の影響をとても受けやすいワークロードがある場合や、サービス メッシュ コンポーネントをカバーする追加のリソースを提供できない場合は、サービス メッシュの使用を再検討する必要があります。
必要以上に複雑になっていないか?: ビジネス チームや運用チームにとって重要ではない機能を使うためにサービス メッシュをインストールする場合、インストール、メンテナンス、構成をさらに複雑にする価値があるかどうかを検討してください。
インクリメンタル アプローチを採用できるか?: 多くの機能を提供するサービス メッシュの中には、よりインクリメンタルなアプローチを採用できるものがあります。 確実に成功するためには、必要なコンポーネントだけをインストールしてください。 後からさらに多くの機能が必要だと判明した場合は、後でそれらを検討します。 最初からすべてのものをインストールするという衝動は抑えてください。
次のステップ
Azure Kubernetes Service (AKS) には、Istio および Open Service Mesh 用の公式にサポートされているアドオンが用意されています。
また、オープンソース プロジェクトやサード パーティによって提供され、AKS で一般的に使用されているサービス メッシュもあります。 これらのサービス メッシュは、AKS のサポート ポリシーの対象外です。
サービス メッシュを取り巻く状況について詳しくは、レイヤー 5 のサービス メッシュの状況に関するページを参照してください。
サービス メッシュ標準化の取り組みについて、詳しくは以下をご覧ください。