パフォーマンス ダッシュボードの指標とビュー

このページでは、Google Cloud プロジェクトのリソースのパフォーマンスと Google Cloud 全体のパフォーマンスを判定するために使用される指標について説明します。また、さまざまなビューの詳細を確認し、これらのパフォーマンス指標の詳細を確認することもできます。

指標

パフォーマンス ダッシュボードには、パケットロスとレイテンシ（ラウンド トリップ時間（RTT））の 2 種類の指標があります。Google Cloud プロジェクトのパケットロス指標を取得するには、プロジェクトに十分な数の VM が必要です。レイテンシ指標を取得するには、十分な量のトラフィックが必要です。また、パフォーマンス ダッシュボードは設定不要です。

以降のセクションで、両方の指標について詳しく説明します。

パケットロス

パケットロス指標には、次の間でのアクティブ プローブの結果が表示されます。

  • 1 つの VPC ネットワーク内の VM。

  • ピアリングされた VPC ネットワーク内の VM で、1 つまたは両方のネットワークがプロジェクト内にある場合。ピアリングされたネットワークが異なるプロジェクトにある場合、パケットロスは宛先プロジェクトに表示されます。

  • プロジェクトで使用されている共有 VPC ネットワーク内の VM。共有 VPC ネットワークを使用する 2 つのプロジェクト間のパケットロスは、宛先のサービス プロジェクトに表示されます。

たとえば、プロジェクト A に、ゾーン A にのみ VM が配置されたネットワーク A と、ゾーン M にのみ VM が配置されたネットワーク M という 2 つの VPC ネットワークがあるとします。これら 2 つのネットワークがピアリングされている場合、プロジェクト A のパフォーマンス ダッシュボードには A と M のゾーンペアのパケットロス データが表示されます。ネットワークがピアリングされていない場合、パフォーマンス ダッシュボードにはそのゾーンペアのパケットロス指標は表示されません。

この 2 つのネットワークが同じプロジェクトにない場合、各ネットワークのパフォーマンス ダッシュボードにいつ指標が表示されるのかに注意してください。つまり、ネットワーク A がプロジェクト A の一部であり、ネットワーク M がプロジェクト M の一部であるとします。ネットワークがピアリングされていると、プロジェクト M のパフォーマンス ダッシュボードに、ゾーン M が宛先ゾーンである場合にパケットロスのデータが表示されます逆に、ゾーン A が宛先ゾーンの場合、パケットロス データはプロジェクト A にのみ表示されます。ネットワークがピアリングされていない場合、プロジェクトのパフォーマンス ダッシュボードにはゾーンペアのパケットロスのデータは表示されません。

すべてのプローブで収集されたデータは、パフォーマンス ダッシュボードで集約されます。つまり、パフォーマンス ダッシュボードでは、プロジェクト内パケットロスと他のタイプ（他のプロジェクトのピアリングされた VPC ネットワークに関連するパケットロスなど）のデータを分離することはできません。ただし、Monitoring を使用して、より詳細な結果を確認できます。詳細については、パフォーマンス ダッシュボードの指標のリファレンスをご覧ください。

パフォーマンス ダッシュボードは、Cloud VPN 接続経由でプローブを送信しません。

手法

パフォーマンス ダッシュボードは、VM を格納する物理ホスト上でワーカーを実行します。このワーカーは、トラフィックと同じネットワーク上で実行されるプローブ パケットを挿入して受信します。ワーカーは VM ではなく物理ホストで実行されるため、このようなワーカーは VM リソースを消費せず、トラフィックが VM に表示されません。

プローブは、互いに通信できる VM のメッシュ全体をカバーします。これは、必ずしもトラフィック パターンと同じではありません。したがって、パフォーマンス ダッシュボードにパケットロスの兆候が表示されることがありますが、アプリケーションでパケットロスが測定されたという証拠は示されません。

プローブされたすべての VM に対して、Google Cloud は内部 IP アドレスと外部 IP アドレス（存在する場合）の両方を使用して VM にアクセスを試みます。プローブは Google Cloud を離れるわけではありませんが、外部 IP アドレスを使用すると、インターネットからのトラフィックなど、外部トラフィックで使用されるパスの一部をパフォーマンス ダッシュボードに表示できます。

内部 IP アドレスのパケットロスは UDP パケットを使用して測定され、外部 IP アドレスのパケットロスは TCP パケットを使用して測定されます。

指標の可用性と信頼レベル

パフォーマンス ダッシュボードは、ネットワーク内のすべての VM 間のペアのサブセットをプローブします。収集されたデータは、発生する可能性のあるパケットロスを推測するために使用されます。データにおける Google の信頼度はプローブ率に依存し、プローブ率は各ゾーンにある VM の数と VM がデプロイされているゾーンの数によって異なります。たとえば、10 個の VM を 2 つのゾーンに配置すると、10 個の VM を 10 個のゾーンに配置する場合よりも信頼度が高くなります。

Google Kubernetes Engine（GKE）によって作成されたものも含めて、すべての VM は、VM の総数に含まれます。

次の表に、さまざまなレベルの信頼度を示します。ヒートマップでは、より低いレベルの信頼度がアスタリスク（*）や N/A でフラグ設定されます。

レベル 各ゾーンに必要な VM の数 パフォーマンス ダッシュボードのヒートマップに表示される内容
95% の信頼度 プロジェクト内のゾーン数の 10 倍の数の VM。たとえば、プロジェクト内に 12 個のゾーンがある場合、各ゾーンに 120 個の VM が必要です。 追加表記のない測定結果
90% の信頼度 プロジェクト内のゾーン数の 2.5 倍の数の VM。たとえば、プロジェクト内に 12 個のゾーンがある場合、各ゾーンに 30 個の VM が必要です。 追加表記のない測定結果
信頼度が低い アスタリスクの付いた測定結果
プローブ数が少ないため、意味のあるデータを導出できない N/A

Google Cloud のパケットロス指標は常に利用できます。アスタリスク（*）は、1 分あたり 400 件未満のプローブが存在する場合に表示されます。

プロジェクト固有のレイテンシ

レイテンシ指標は、次の対象間におけるユーザー トラフィックを使用して測定されます。

  • 1 つの VPC ネットワーク内の VM。
  • ピアリングされる VPC ネットワーク間の VM（ネットワークが同じプロジェクト内にある場合）。
  • VM とインターネット エンドポイント。

また、共有 VPC ネットワーク内のサービス プロジェクトのパフォーマンス ダッシュボードには、サービス プロジェクト内のゾーンのみのデータが表示されます。たとえば、ゾーン A の VM とサービス プロジェクト A がホスト プロジェクトを使用して、ゾーン B とサービス プロジェクト B の VM と通信するとします。トラフィックに関する測定は、サービス プロジェクトにもホスト プロジェクトにも使用できません。

Google Cloud レイテンシ

レイテンシ指標は、次の対象間における実際のユーザー トラフィックを使用して測定されます。

  • 1 つの VPC ネットワーク内の VM。
  • ピアリングされた VPC ネットワーク間の VM。
  • VM とインターネット エンドポイント。

プロジェクトと Google Cloud のレイテンシの測定方法

レイテンシは、TCP パケットを使用して測定されます。

実際のトラフィックのサンプルに基づいて、TCP シーケンス番号（SEQ）を送信してから、対応する ACK を受信するまでの経過時間でレイテンシが測定され、これにはネットワーク RTT と TCP スタック関連の遅延が含まれます。ダッシュボードでは、関連するすべての測定結果の中央値でレイテンシが表示されます。

レイテンシ指標は、VPC フローログと同じデータソースとサンプリング手法に基づいています。

プロジェクト固有のレイテンシは、プロジェクトのサンプルに基づいています。Google Cloud のレイテンシは、Google Cloud 全体からのサンプルに基づいています。

グローバル レイテンシ指標は、Google Cloud からインターネット エンドポイントへのアクティブなプローブではなく、TCP トラフィック ヘッダーのパッシブ サンプリングから導き出されます。

レイテンシ指標の異常

次のレイテンシ指標の異常に注意してください。

  • 低レート環境の場合、Network Intelligence Center は 60 秒のプローブを使用してレイテンシ指標を測定します。そのため、TCP ベースのサービスから返されるアプリケーション レベルのレスポンスに遅延が発生している場合、パケット サンプリングに基づく RTT 指標は、誤って高いレイテンシ レベルを示すことがあります。通常、不正確な RTT レベルは、アプリケーション レベルの遅延と関連しているかどうかを確認することで判断できます。

    TCP ベースのサービスが ACK で迅速に応答した場合でも、サンプリングにおいて ACK が見逃され、後続のデータ レスポンスがかなり前の SEND に対する終了 ACK として判定されると、RTT の測定全体に歪みが生じます。この場合、RTT 指標は無視してかまいません。

  • プロジェクト固有のレイテンシ データが、グローバル レイテンシ データと一致していないことがあります。この不整合は、グローバル データセットに他のネットワーク パスも組み込まれており、そのレイテンシが特定のプロジェクトによって使用されるネットワーク パスからのレイテンシと比べて大幅に異なっている場合に発生することがあります。

指標の可用性

Google Cloud のレイテンシ指標は、常に利用できます。プロジェクトごとのレイテンシ指標は、TCP トラフィックが 1 分あたり約 1,000 パケット以上の場合にのみ利用できます。

指標の集計表

次の表は、パケットロスとレイテンシの指標を報告するために使用されるプローブ手法とプロトコルをまとめたものです。

パケットロス レイテンシ
プロービング方法 アクティブ プロービング（合成した VM トラフィック） パッシブ プロービング（実際の VM トラフィック）
プロトコル UDP（内部 IP アドレス）、TCP（外部 IP アドレス） TCP（内部 / 外部 IP アドレス）

レイテンシ ビュー

レイテンシの詳細: インターネットから Google Cloud へのトラフィック タイプには 3 つのビューがあります。テーブルビュー、地図ビュー、タイムライン ビューです。

テーブルビュー

[テーブル] ビューには、選択した地理的エリアと、プロジェクト内の VM インスタンスを含むリージョン間の RTT の中央値が表示されます。テーブルには次の情報が含まれます。

  • 国: 国の名前。
  • 都市: 都市の数。特定の都市のレイテンシの詳細は、国の詳細グラフで確認できます。
  • 宛先リージョン: 特定の国のユーザーについてトラフィックがある宛先リージョンの数。
  • 中央値のレイテンシ: 国とリージョン間の RTT 中央値（ミリ秒）。

地図表示

地図表示には、地理的位置（大都市圏や都市）と Google Cloud リージョンが表示されます。

  • 特定のロケーションと Google Cloud リージョンのレイテンシの中央値を確認します。
  • Google Cloud リージョンを選択して、選択したリージョンへのトラフィックがあるロケーションを表示します。
  • サイドバーのレイテンシ グラフで、ロケーション固有の詳細を表示します。
  • 地図上の検索ボックスを使用してロケーションを検索します。

各地点は、地図上でレイテンシの中央値の範囲を示すため、異なる濃い青色で色分けされています。次の画像では、世界地図上の特定の都市を示す円の色は青系統の色合いになります。青色が濃いほど、その都市の特定の Google Cloud リージョンからのレイテンシが高くなります。

地図上のレイテンシの中央値の範囲。
地図上のレイテンシの中央値の範囲（クリックして拡大）

タイムライン ビュー

[タイムライン] ビューには、選択した地理的領域と Google Cloud リージョン間の RTT の中央値が表示されます。現在のレイテンシの指標と 6 週間分の履歴データが表示されます。フィルタを使用して、トラフィックを都市、地域、国レベルでさらに集計できます。特定の地理的場所の位置情報ペアに対応するレイテンシの指標は、そのペアに十分な Google Cloud トラフィックがある場合にのみ表示できます。