Anthos Service Mesh: 外部サービスとの連携 - 指標とトレース
Google Cloud Japan Team
※この投稿は米国時間 2023 年 3 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。
最近私は、Anthos Service Mesh（ASM）を使用して、メッシュ内部のサービスと外部のサービスとの接続と統合を管理するための方法をお客様にアドバイスする機会がありました。
そのときの目標は次の通りでした:
メッシュから外部サービスに流れるトラフィックのトレースと指標を取得する
クラウド GKE クラスタでレガシー サービスの再デプロイを実行する
トラフィックを GKE サービスに段階的に移行する
この記事では、メッシュから外部サービスに流れるトラフィックの指標とトレースを取得する方法について説明します。このチュートリアルでは、クラスタ内部のサービスと外部サービスを模したサービスにサンプル サービスを使用しますが、実際のアプリケーション環境でも同じ考え方と構成を適用できます。
要件
この記事で説明されるアクティビティを実行するには、GCP プロジェクトにアクセスできる必要があります。また、ASM を有効にした状態で GKE クラスタ作成する権限が必要です。
説明される構成の多くが Istio API をベースとしているため、今回の手順をそのまま、あるいは少ない変更を加えて適用できます。また、Istio オープンソース インストールやその他の商用実装にも適用できます。トラフィック指標とトレースのモニタリングに関する箇所については、GCP の Cloud Monitoring と Cloud Trace で構築しています。
GCP で GKE クラスタを作成して Anthos Service Mesh を有効にする
ASM を有効にした状態で GKE クラスタを作成します。これを行うための簡単な説明は、ASM のドキュメントの GKE UI のクイックスタートのページにあります。クラスタを作成したら、このドキュメント ページの説明に従い、kubectl を使用してそのクラスタに接続するための認証情報を取得します。
ASM を有効にした状態でクラスタを作成したら、Cloud Trace の統合を有効にします（ASM ではデフォルトで有効化されません）。
Cloud Trace を有効にするには、メッシュ構成を変更する必要があります。上述の GKE UI のクイックスタートに従いクラスタを作成した場合、次のコマンドでこれを行えます:
サンプル アプリケーションをデプロイする
次に、sleep というサンプル アプリケーションをデプロイします。これは、Istio リリースに含まれるサンプルの一部となり、これを外部サービスへのトラフィックのソースとして使用します。
アプリケーションをデプロイする名前空間を作成します。これを meshed という名前にします:
名前空間での Pod の作成時にサイドカー プロキシが自動的に挿入されるようにするために、ラベル istio.io/rev のリリース チャネル値でラベルを付ける必要があります。今回の場合、リリースは asm-managed です:
出力の「istio-injection not found」のメッセージは無視できます。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。ASM の新規インストールや新規デプロイでは、こうなって当然です。
使用するサンプル アプリケーションを含む Istio リリースをダウンロードして抽出します:
次のようなメッセージが表示されます:
Istio ダウンロードで作成されたフォルダ内に移動します。以下はその例です:
サンプル sleep アプリケーションを名前空間にデプロイします:
Pod が作成されていること、Pod に 2 つのコンテナ（アプリケーション コンテナと ASM Envoy プロキシ）があることを確認します:
クラスタが新しく作成された Autopilot クラスタである場合、Pod の起動までに数分ほどかかる可能性があります。Pod の起動が完了すると、以下のような出力が表示されます:
外部サービスへのアクセスを管理する
ASM（および Istio）では、外部サービスへのアクセスを ServiceEntry リソースを使用して管理できます。このリソースを使用することで、外部サービスのエントリを Istio の内部サービス レジストリに追加できるため、外部サービスに向かうトラフィックをメッシュ内部のものであるように扱って誘導とモニタリングを行えます。
パブリック エンドポイント httpbin.org 用の ServiceEntry を作成します。これを外部サービスのサンプルとして使用します:
外部サービスのトラフィック指標を取得する
メッシュの外部へと流れるトラフィックのサンプルの指標とトレースを確認するには、最初に SOURCE_POD 環境変数をソース Pod の名前に設定します:
次に、sleep Pod コンソールに接続します:
次に、サンプル sleep アプリケーションから httpbin.org へのある程度の量のトラフィックを生成します。
httpbin.org/ip ページが、リクエストに含まれているソース IP で反応していることを確認できます。これは、GKE クラスタノードのパブリック IP のいずれかであるはずです。
数分待ってから、指標が取得されているかを確認します:
GCP Console で [Monitoring] に移動し、左側のメニューで [Metrics Explorer] を選択します。
Metrics Explorer で、[Resource & Metrics] にある [SELECT A METRIC] をクリックして、検索ボックスに「istio」と入力します
結果の中から、次のように [Istio Canonical Service] > [Service] > [Client Request Count] を選択して、[Apply] をクリックします。
[ADD FILTER] をクリックして、以下のように source_workload_name = sleep でフィルタを作成します。
再度 [ADD FILTER] をクリックして、以下のように destination_service_name = httpbin.org でフィルタを作成します。
[How do you want to view data?] セクションの [Group by] メニューで、データのグループ化で使用するラベルを選択できます。本番環境の場合で、サービスが複数の外部サービスと接続されている場合に destination_service_name のラベルを選択してグループ化する、response_code のラベルを選択してエラー率を測定するなどの使用法があります。今回は、sleep から httpbin.org までの接続しかないため、デフォルトの構成のままにします。
これで、httpbin.org への 1 秒あたりのリクエスト数を表示するグラフが作成されました。専用の ServiceEntry リソースをすでに作成しているため、httpbin.org を宛先サービスとして選択できたはずです。
右上にある [Save Chart] をクリックします。グラフの名前を「req/s to httpbin.org」にして、「ASM External Services」という名前の新しいダッシュボードに保存します。
次に、同じことを行ってレイテンシの指標用のグラフを作成します:
[Resource & Metrics] で、名前が ISTIO CANONICAL SERVICE - CLIENT REQUEST COUNT になっているボタンをクリックします。
ここでは以下のように [Istio Canonical Service] > [Service] > [Client Roundtrip Latencies] を選択して、[Apply] をクリックします。
前のグラフで作成したものと同じフィルタを、source_workload_name = sleep と destination_service_name = httpbin.org で 2 つ作成します。
これで、httpbin.org へのリクエストの往復レイテンシを表示するグラフが作成されます。
このグラフは、50 パーセンタイルをデフォルトのアグリゲータとして使用します。[How do you want to view data?] セクションでこの値を変更することも、別の指標を異なるパーセンタイルで追加することもできます。
右上にある [Save Chart] をクリックします。グラフの名前を「Latency to httpbin.org」にして、「ASM External Services」ダッシュボードに保存します。
作成したグラフが含まれるダッシュボードを表示するには、表示されるポップアップ ボックスの [VIEW DASHBOARD] をクリックするか、左側のメニューの [Dashboards] に移動して、ダッシュボード リストの [ASM External Services] を選択します。このようにすることで、httpbin.org に向かう 1 秒あたりのリクエスト数と 50 パーセンタイル レイテンシを表示するダッシュボードが以下のように表示されるはずです:
グラフの自動更新の有効化や時間間隔の変更は右上から行えます。
外部サービス アクセスのトレースを取得する
次に、httpbin.org へのリクエストのトレースを確認してみます:
GCP Console で、[Trace] > [Trace List] に移動します
フィルタ スペースに、istio.canonical_service: sleep と入力します
httpbin.org:80/* へのリクエストのトレースの一覧が表示されます
最も最近のトレースを選択すると、往復レイテンシなどのそのリクエストに関する情報が表示されます。
これは、sleep サービスを起点として httpbin.org に直接向かうきわめてシンプルなリクエストです。Cloud Trace では、外部のエンドユーザーを起点としてメッシュに入り、メッシュ内の複数のマイクロサービスと関与し、最終的に外部のバックエンド サービスに到達するより複雑なリクエストでも追跡できます。
外部サービスへの HTTPS 接続の指標とトレースを取得する
上記の構成は HTTP 接続で機能します。外部サービスへの HTTPS 接続を実行する場合、トレースは表示されず、宛先のサービスは Cloud Monitoring の指標に表示されません。これは、そのリクエストがソース アプリケーションから外部サービスまでの間で暗号化されていて、ASM プロキシが HTTP ペイロードにアクセスできないためです。
この問題を解決するための方法は、ソースサービスではなくプロキシを TLS の起点とすることです。この手法であれば、もとのトラフィックを HTTP のままにしつつ、外部サービスに向かう接続が HTTPS になるため、プロキシがリクエストに含まれるデータにアクセスできるようになります。
これを行うには、以下を行う必要があります:
1. 前のセクションの ServiceEntry を調整して、HTTP リクエストをポート 443 にリダイレクトするようにする
2. ポート 80 で HTTP リクエストの TLS 発信を実行する DestinationRule を作成する:
発信元の Pod からの接続は引き続き HTTP です。そのため、引き続きトレースと指標を確認できます:
ただし、上述の ServiceEntry と DestinationRule があるため、ASM プロキシは HTTPS を使用して httpbin.org に接続します。
まとめ
この記事では、以下を行うための方法について説明しました:
ASM で Cloud Trace を有効にする。
Istio ServiceEntry リソースを使用して、外部サービスを ASM 内部レジストリに登録する。
Cloud Monitoring でグラフを作成して、メッシュから外部サービスまでの通信のトラフィックとレイテンシの指標を確認する。
Cloud Trace を使用してメッシュから外部サービスへのリクエストを追跡する。
ASM からの外向きの TLS 発信を構成する
以下のチュートリアルでも、Anthos Service Mesh の詳細について学習できます:
今後の記事にもご期待ください。メッシュ内部で実行されるサービスと外部で実行されるサービス間のトラフィックを分割して、本番環境トラフィックを ASM に段階的に移行する方法について説明します。
- カスタマー エンジニア Giovanni Galloro
