このページでは、Spanner コンポーネントのレイテンシの問題を特定してトラブルシューティングする方法について説明します。Spanner リクエストで発生する可能性のあるレイテンシ ポイントの詳細については、Spanner リクエストのレイテンシ ポイントをご覧ください。
さまざまなコンポーネントとデータベース間のリクエストのレイテンシを測定し、比較することで、レイテンシの原因となっているコンポーネントを特定できます。これらのレイテンシには、エンドツーエンドのレイテンシ、Google Front End(GFE)のレイテンシ、Spanner API リクエストのレイテンシ、クエリのレイテンシが含まれます。
サービスを使用するクライアント アプリケーションで、エンドツーエンド レイテンシからレイテンシが増加していることを確認します。クライアントサイド指標で次のディメンションを確認します。詳細については、クライアントサイドの指標の説明をご覧ください。
client_name: クライアント ライブラリの名前とバージョン。location: クライアントサイドの指標が公開される Google Cloud リージョン。アプリケーションがGoogle Cloudの外部にデプロイされている場合、指標はglobalリージョンにパブリッシュされます。method: RPC メソッド名(例:spanner.commit)。status: RPC ステータス(例:OK、INTERNAL)。
これらのディメンションごとにグループ化して、問題が特定のクライアント、ステータス、方法に限定されたものであるかを確認します。デュアルリージョン ワークロードまたはマルチリージョン ワークロードの場合は、問題が特定のクライアントまたは Spanner リージョンに限定されたものであるかを確認します。
クライアント アプリケーションの正常性、特にクライアント側のコンピューティング インフラストラクチャ(たとえば、VM、CPU、メモリ使用率、接続、ファイル記述子など)を確認します。
クライアントサイドの指標を表示して、Spanner コンポーネントのレイテンシを確認します。
a.
spanner.googleapis.com/client/operation_latencies指標を使用して、エンドツーエンドのレイテンシを確認します。b.
spanner.googleapis.com/client/gfe_latencies指標を使用して、Google Front End(GFE)のレイテンシを確認します。Spanner 指標の次のディメンションを確認します。
database: Spanner データベース名。method: RPC メソッド名(例:spanner.commit)。status: RPC ステータス(例:OK、INTERNAL)。
これらのディメンションごとにグループ化して、問題が特定のデータベース、ステータス、方法に限定されたものであるかを確認します。デュアルリージョンまたはマルチリージョンのワークロードの場合は、問題が特定のリージョンに限定されたものであるかを確認します。
spanner.googleapis.com/api/request_latencies指標を使用して、Spanner API リクエストのレイテンシを確認します。詳細については、Spanner の指標をご覧ください。エンドツーエンドのレイテンシが高い一方で、GFE のレイテンシと Spanner API リクエストのレイテンシが低い場合、アプリケーション コードに問題がある可能性があります。クライアントとリージョン GFE 間のネットワークに問題がある可能性も考えられます。アプリケーションのパフォーマンスに問題があり、一部のコードパスが遅くなる場合、各 API リクエストに対するエンドツーエンドのレイテンシが増加する可能性があります。前のステップでは検出されなかった、クライアント側のコンピューティング インフラストラクチャに問題がある可能性もあります。
GFE のレイテンシが高い一方で、Spanner API リクエストのレイテンシが低い場合は、次のいずれかが原因である可能性があります。
別のリージョンからデータベースにアクセスしている。これによって GFE のレイテンシが高くなり、Spanner API リクエストのレイテンシが低くなっている可能性が考えられます。たとえば、
us-central1リージョンにインスタンスを持つus-east1リージョンのクライアントからのトラフィックは、GFE のレイテンシは高くなりますが、Spanner API リクエストのレイテンシは低い場合があります。GFE レイヤに問題がある。Google Cloud ステータス ダッシュボードを参照し、リージョンでネットワークの問題が発生していないかどうかを確認します。問題が発生中でない場合、サポート エンジニアが GFE のトラブルシューティングに対応する際の参考になるよう、サポートケースを開いてその情報を入力します。
インスタンスの CPU 使用率を確認します。インスタンスの CPU 使用率が推奨レベルを超えている場合は、ノードを手動で追加するか、自動スケーリングを設定する必要があります。詳細については、自動スケーリングの概要をご覧ください。
Key Visualizer を使用して、潜在的なホットスポットや不均衡なアクセス パターンをモニタリングしてトラブルシューティングを行い、問題の発生時期と関連性が強いアプリケーション コードの変更をロールバックしてみてください。
トラフィック パターンの変化を確認します。
クエリ分析情報とトランザクション分析情報を参照し、クエリまたはトランザクションのパフォーマンスにおけるボトルネックがあるかどうかを確認します。
最も古いアクティブなクエリのプロシージャを使用して、パフォーマンスのボトルネックを引き起こす可能性のある時間のかかるクエリを確認し、必要に応じてクエリをキャンセルします。
次のトピックのトラブルシューティング セクションの手順に沿って、Spanner イントロスペクション ツールを使って問題のトラブルシューティングを行います。
次のステップ
- これで、レイテンシが発生するコンポーネントを特定できたので、組み込みのクライアント サイドの指標を使用して問題をさらに調査します。
- 指標を使用してレイテンシを診断する方法を学習する。
- Spanner の期限超過エラーのトラブルシューティング方法を学習する。