レイテンシのトラブルシューティング

他のデータベース システムと同様に、Bigtable でもレイテンシの問題が発生する可能性があります。このドキュメントでは、Bigtable でレイテンシの問題が発生する一般的な原因と、そのトラブルシューティング方法について説明します。

次のセクションのトラブルシューティングの手順を使用して、Bigtable のレイテンシの問題を診断して解決します。

高レイテンシの原因を理解する

Bigtable のレイテンシの問題には、次の要因が影響します。

  • サーバーのレイテンシ。サーバー レイテンシの測定は、Bigtable がリクエストを受信すると開始され、Bigtable がデータの最後のバイトをクライアントに送信すると終了します。大量のデータのリクエストの場合、クライアントがレスポンスを使用できるかどうかによってサーバー レイテンシが影響を受ける可能性があります。
  • オペレーションのレイテンシは、すべての再試行を含む Bigtable オペレーションのエンドツーエンドの合計時間を測定します。この指標は、クライアントから Bigtable へのラウンドトリップを追跡します。アプリケーションのレイテンシ、ネットワーク接続、Bigtable クライアント ライブラリのレイテンシ、サーバー レイテンシはすべて、オペレーション レイテンシに影響します。
  • ワークロードとリクエスト パターンは、インフラストラクチャの問題だけでなく、アプリケーションがリクエストするワーク パターンの変更によってもレイテンシを増加させる可能性があります。たとえば、以前は 100 行をスキャンしていた動的に生成されたスキャンクエリが、最近のデータ インポートまたはアプリケーション ロジックの変更により、100 万行をスキャンするようになったとします。システムは効率的に動作している可能性がありますが、1 回のオペレーションの作業量が大幅に増加すると、実行時間が長くなり、Bigtable はレイテンシが高いと認識します。

始める前に

レイテンシが高い問題のトラブルシューティングを行うには、次の操作を行います。

  • クライアント ライブラリのクライアントサイドの指標を有効にして、パフォーマンスを最適化し、問題を解決します。
  • ネットワーク レイテンシを最小限に抑えるには、アプリケーションが Bigtable クラスタと同じゾーンにあることを確認します。これにより、アプリケーションとクラスタ間のネットワーク距離が短縮され、リクエストの応答時間が改善されます。
  • Bigtable 環境について次の情報を収集します。
  • クライアント側の環境に関する次の情報を収集します。
  • 問題に関する次の情報を収集します。

レイテンシの問題をトラブルシューティングする

Bigtable でレイテンシの問題が発生した場合は、次の手順で問題のトラブルシューティングを行います。

  1. サーバーのレイテンシを確認する:Google Cloud コンソールの [モニタリング] ページを使用して、サーバーのレイテンシを表示します。詳細については、Cloud Monitoring でモニタリングするをご覧ください。インスタンスのレイテンシを確認します。インスタンスに複数のクラスタが含まれている場合は、クラスタごとに指標をスライスします。読み取りレイテンシまたは書き込みレイテンシのグラフ、またはクライアント側の指標でレイテンシの増加が見られる場合は、このドキュメントのサーバー レイテンシのトラブルシューティング セクションにあるサーバー レイテンシのトラブルシューティングの手順に沿って操作します。
  2. クライアント レイテンシを確認する: クライアントサイドの指標を有効にした後、Cloud Monitoring の Metrics Explorer で bigtable.googleapis.com/client を検索します。利用可能なクライアントサイドの指標を確認します。クライアント側の指標でレイテンシが増加しているが、サーバーでは増加していない場合は、アプリケーションとネットワーク接続を調べます。詳細については、このドキュメントのクライアントのレイテンシのトラブルシューティングをご覧ください。

次の図は、Bigtable でレイテンシが増加した場合のトラブルシューティング プロセスを示しています。

Bigtable のレイテンシのトラブルシューティングのフローチャート。
図 1. Bigtable のレイテンシの問題のトラブルシューティング プロセス（クリックして拡大）。

クライアント レイテンシのトラブルシューティング

クライアント側のレイテンシの問題をトラブルシューティングする手順は次のとおりです。

始める前に

クライアントサイドのレイテンシのトラブルシューティングを開始する前に、次のタスクを完了します。

  • Bigtable でクライアントサイドの指標を有効にします。
  • Java クライアント バージョン 2.17.1 以前を使用している場合は、チャネル プライミングを有効にします。バージョン 2.18.0 以降では、チャネルの更新がデフォルトで有効になっています。
  • ワークロードに最適な接続プールサイズを決定するために、反復処理を行います。チャネルが不足している場合や過剰な場合、試行レイテンシが高くなる可能性があります。

アプリケーション ブロックのレイテンシを確認する

Google Cloud コンソールで Application Blocking Latencies 指標を確認し、次のいずれかの操作を行います。

  • アプリケーション ブロックのレイテンシが高く、報告されたレイテンシの増加に対応している場合は、クライアント側の問題のトラブルシューティングに重点を置きます。
  • アプリケーションのブロック レイテンシが高く、クライアントが GKE や Compute Engine などのGoogle Cloud インフラストラクチャでホストされている場合は、適切な Google Cloud サポートチームにエスカレーションします。
  • アプリケーション ブロッキング レイテンシが低く、Bigtable サービング レイテンシも低い場合、レイテンシのボトルネックは、ネットワークや Google フロントエンドなど、ネットワーキングまたはトラフィック パスの中間コンポーネントにある可能性があります。レイテンシのボトルネックを特定するために、完全なパケット キャプチャを支援するよう Google Cloudネットワーキング チームにエスカレーションすることを検討してください。

オペレーション レイテンシが高い場合に対処する

  1. connectivity_error_count が高い場合、アプリケーションは Google フロントエンドに到達できません。RPC タイムアウトを短く設定して、リクエストを別のチャネルで再試行できるようにします。
    • RPC タイムアウトが小さすぎると、オペレーション レイテンシが高くなる可能性があります。通常のオペレーション中の一般的な P99 RPC タイムアウトを特定します。RPC タイムアウト値をこのベンチマークに近い値に設定すると、パフォーマンスを最適化できます。
  2. retry_count が高い場合は、attempt_latencies ステータス タグを確認します。試行が DEADLINE_EXCEEDED エラーで失敗する場合、リクエストの期限は平均 attempt_latencies と比較して短すぎます。

gRPC スレッドでキューに登録されたリクエストに対応

どの指標も基準値を超えていない場合、リクエストが gRPC スレッドでキューに登録されることがあります。この問題は、次の理由で発生することがあります。

  • チャネル プールのサイズが小さすぎて、リクエストが gRPC チャネルでキューに登録されます。詳細については、バッファリングされたリクエストをご覧ください。
  • クライアント VM の CPU 使用率が高い。CPU 使用率が高いと、クライアントでリクエストのキューイングも発生します。

サーバーのレイテンシのトラブルシューティング

サーバーサイドのレイテンシの問題をトラブルシューティングする手順は次のとおりです。

クラスタが過負荷状態かどうかを判断する

  1. Read requests グラフと Write requests グラフで QPS の変化を確認します。
  2. Node count グラフでノード数の変化を確認します。
  3. Read throughput グラフと Write throughput グラフで帯域幅の増加を確認します。詳細については、パフォーマンスについてをご覧ください。
  4. アプリ プロファイル、メソッド、テーブルで CPU がどのように使用されているかを特定してパフォーマンスの問題をトラブルシューティングするには、Cloud Bigtable クラスタの CPU 使用についてのブログ投稿をご覧ください。
  5. 影響を受けるクラスタのノード数を増やします。詳細については、ノードを手動で追加または削除すると自動スケーリングをご覧ください。平均 CPU 使用率が推奨しきい値を下回っていることを確認します。

ホットスポットの確認

ホット タブレットは、同じノードに関連付けられている他のタブレットと比べて、ノードの CPU を過剰に使っています。このような使用量の偏りは、行範囲へのリクエスト量が当初の予想以上に多い場合や、スキーマ設計の欠陥が原因で発生します。このノード使用量の偏りによって、レイテンシの増加やレプリケーションの遅延が発生する可能性があります。これをホットスポットと呼びます。

  1. CPU utilization (hottest node) high granularity グラフでホットスポットを確認します。
  2. ホット タブレットを特定するには、ホット タブレットまたは Key Visualizer ツールを使用します。
  3. クラスタレベルの CPU の過剰使用は、ノードを追加する（水平スケーリング）ことで軽減できることが多いですが、ホットスポットには他の軽減策が必要になることがあります。これらの手法には、行キーの構築方法の変更やスキーマの変更などがあります。詳細については、Cloud Bigtable のホットスポットを取り除くのブログ投稿をご覧ください。

QPS が低い場合のレイテンシに対処する

Bigtable は、頻繁にアクセスされる大きなテーブルで優れたパフォーマンスを発揮します。一定期間使用されていない状態でリクエストを送信すると、Bigtable が接続を再確立するまでにレイテンシが高くなる可能性があります。

  1. Read requests グラフと Write requests グラフに低い QPS が表示されている場合は、レスポンス時間が長くなることが予想されます。
  2. コールド スタートと低 QPS のベスト プラクティスに従って、コールド スタートの問題を軽減します。

リクエストの効率性を評価する

クエリ統計情報を使用してリクエストの効率を評価します。クエリの統計情報には、クエリ対象の行数と返された行数の比率、クエリ対象のセル数と返されたセル数の比率が表示されます。これは、クエリの効率を示しています。クエリ パターンやスキーマ設計を見直して、リクエストの効率を向上させます。詳細については、クエリ統計情報を取得するをご覧ください。

構成またはアプリ プロファイルの変更を確認する

ノード数とスループットが変化していないのに、CPU 使用率の平均値が上昇している場合は、レプリケーションまたはガベージ コレクションの戦略が変更されたことが原因である可能性があります。詳細については、レプリケーションとパフォーマンスをご覧ください。レプリケーションまたはガベージ コレクションの構成変更を元に戻します。

Bigtable サポートにエスカレーションする

上記の手順で問題が解決しない場合は、Bigtable サポートにエスカレーションします。

次のステップ