ユースケース: ネットワーク パフォーマンスの監査
負荷分散された複数のアプリケーションを含むネットワークをサポートしている、ネットワーク管理者になった場合を考えます。このようなアプリケーションをサポートするネットワーク構成を監査して、構成がネットワークの予測される状態と一致することを確認するように求められました。この監査を行うことで、アプリケーションのレイテンシが可能な限り低く抑えられているかを確認できます。
次のユースケースでは、ネットワーク トポロジが既存の構成の確認にどのように役立つかを示します。たとえば、すべてのクライアント リクエストが、クライアントに最も近い Google Cloud リージョンにあるアプリケーション インスタンスによって処理されていることを確認できます。また、トラフィックがグローバルにデータを複製するデータベースから来ているために、リージョン間トラフィックが低く抑えられていることも確認できます。
トポロジの概要
このデプロイメントは 3 つの Google Cloud リージョン（us-central1、europe-west1、asia-east1）にまたがっています。すべての外部クライアント リクエストは、3 つの各リージョンに複数のバックエンドを持つ単一の外部アプリケーション ロードバランサによって処理されます。3 つのビジネス リージョン（Americas、EMEA、APAC）のいずれかからのクライアント リクエストは、最も近い Google Cloud リージョンのアプリケーション インスタンスによって処理されます。
次のグラフは、デプロイメントの最上位階層を示しています。
リソースおよびトラフィック パス
この例では、プロジェクトに以下の Google Cloud リソースが含まれています。
1 個の HTTPS ロードバランサ
4 個のバックエンド サービス（
browse、shopping_cart、checkout、feeds）12 個のインスタンス グループ（ロードバランサのバックエンド）
3 つのリージョンのそれぞれのバックエンド サービスごとに 1 個のインスタンス グループがあります。
3 個のデータベース インスタンス（各リージョンに 1 つずつ）。
特定の国からのトラフィックは、次のロケーションに到達すると想定されます。
Americasビジネス リージョンの国からのトラフィックは、us-central1リージョンのバックエンドに送られます。たとえば、カナダの外部クライアントからのトラフィックは、ロードバランサを経由してus-central1リージョンのcheckoutバックエンドに送られます。EMEAビジネス リージョンの国からのトラフィックは、europe-west1リージョンのバックエンドに送られます。たとえば、ポーランドの外部クライアントからのトラフィックは、ロードバランサを経由してeurope-west1リージョンのcheckoutバックエンドに送られます。APACビジネス リージョンの国からのトラフィックは、asia-east1リージョンのバックエンドに送られます。たとえば、日本の外部クライアントからのトラフィックは、ロードバランサを経由してasia-east1リージョンのcheckoutバックエンドに送られます。- データベース インスタンスへのトラフィックは、同じリージョンのバックエンドから送信されます。たとえば、
asia-east1のバックエンドは、asia-east1のデータベース インスタンスにのみデータを送信します。 - リージョン間トラフィックはデータベース レプリケーションに制限されます。たとえば、
us-central1とeurope-west1の間のトラフィックは、それらのリージョンのデータベース インスタンス間のみを移動します。
予期しないトラフィック フロー
このシナリオでは、EMEA ビジネス リージョンからのトラフィックが、2 つの異なる Google Cloud リージョン（us-central1 と europe-west1）に送信されていることがわかります。ネットワーク トポロジを使用すると、バックエンドの 1 つが過剰に使用されていることがわかります。
ロードバランサを通過する外部トラフィックが最終的に正しい Google Cloud リージョンに送信されることを確認するとします。グラフをフィルタリングして、外部ロードバランサ
shopping-site-lbのトラフィックのみを表示します。フィルタを適用すると、次の例に示すように、ネットワーク トポロジがロードバランサに関連する接続のみを表示します。
それぞれのビジネス リージョンにポインタを合わせて、それぞれのリージョンへの通信を強調表示します。
ポインタを Americas と APAC の上に置くと、最も近い Google Cloud リージョン（それぞれ
us-central1とasia- east1）に向かうトラフィックが表示されます。一方、ポインタを EMEA に合わせると、us-central1とeurope-west1へのトラフィックが表示されます。理想的には、レイテンシを減らすために EMEA からのすべてのトラフィックをeurope-west1に送信する必要があります。次に、[EMEA] をクリックして、EMEA と Google Cloud リージョン間のスループットを調べます。ネットワーク トポロジが、各接続の帯域幅の値をオーバーレイします。1 秒あたり約 0.58 バイトが
us-central1に、29.9 キロバイト/秒がeurope-west1に送信されます。ほとんどのトラフィックは予想どおりに転送されていますが、一部のトラフィックはus-central1に流れています。1この図は参考用です。この図のデータはユースケースを反映していません。
さらに調べるために、
us-central1を展開してトラフィックの行き先を表示します。このリージョンには単一のサブネットを持つネットワークが 1 つしかないため、ネットワーク トポロジは階層におけるこのレベルを表示せず、インスタンス グループまでスキップします。トラフィックは、ロードバランサのバックエンド サービスに関連付けられているインスタンス グループに送信されていることがわかります。
europe-west1へ送信されるトラフィックは比較的少量であるため、europe-west1のリソースが過剰に使用されてトラフィックがus-central1にオーバーフローする可能性があります。1この図は参考用です。この図のデータはユースケースを反映していません。
同じロードバランサのバックエンド サービスに関連付けられているインスタンスに到達するまで
europe-west1リージョンを展開して、結果を確認します。 ネットワーク トポロジが、インスタンスの詳細ペインに時系列グラフを表示します。グラフから、インスタンスの CPU 使用率が 81% であることがわかります。この例のしきい値は 80% であり、インスタンスのオーバーサブスクリプションが発生していることがわかります。この問題を解決するには、インスタンス グループをスケールアップして、トラフィックが理想的なフローに戻るようにします。
1この図は参考用です。この図のデータはユースケースを反映していません。
リージョン間のトラフィック
次のセクションでは、リージョン間の内部トラフィックがデータベース インスタンスのトラフィックのみに制限されていることを確認します。
内部トラフィックに焦点を当てるには、[トポロジ構成] リストで [インスタンス] と [Cloud NAT ゲートウェイ] のチェックボックスのみをオンにします。アプリケーション内のトラフィックのみを表示するため、外部クライアントや外部ロードバランサのトラフィックを表示する必要はありません。
asia-east1リージョンを展開すると、5 つのインスタンス グループが表示されます。これらのグループはすべて同じネットワーク、サブネットなどに存在するため、ネットワーク、サブネット、またはゾーンごとに集計されません。1 つのインスタンス グループ（
db-group-asia）のみにリージョン間トラフィックのパスが含まれていることに注目してください。他のすべてのインスタンス グループは、リージョン内で通信しています。基本エンティティに到達するまで、
db-group-asiaグループを展開します。このシナリオのベース エンティティは、データベース サーバーとして機能する仮想マシン（VM）インスタンス（db-instance-asia）です。このインスタンスは他のリージョンと通信してデータを複製しています。これは予想どおりであり、これ以上調べる必要はありません。1この図は参考用です。この図のデータはユースケースを反映していません。
![[エンティティ] ペインから選択解除された外部クライアントとロードバランサを示すスクリーンショット。](https://cloud-dot-devsite-v2-prod.appspot.com/static/network-intelligence-center/docs/network-topology/images/use-cases/auditing-internalonly.png?hl=ja)
