Cloud Spanner 使用時にテール レイテンシが高い場合の調査方法

※この投稿は米国時間 2021 年 12 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Spanner を使用しているとき、テール レイテンシが高くなるケースに遭遇することがあります。その原因が Cloud Spanner 側にある可能性もありますが、他の理由も考えられます。このブログ投稿では、高レイテンシの理由の特定方法を説明し、Cloud Spanner レイテンシ改善のためのヒントもいくつかご紹介します。

高レイテンシと Cloud Spanner 使用の関連性を確認する

Cloud Spanner 指標（Cloud Console または Cloud Monitoring で利用可能）で高レイテンシが確認できる場合、レイテンシの原因は、「3. Cloud Spanner API Front End」または「4. Cloud Spanner Database」（Cloud Spanner エンドツーエンドのレイテンシ ガイドの図）のいずれかにあります。この場合、Cloud Spanner レベルでの詳細な調査が必要です。

一方、Cloud Spanner 指標で高レイテンシを確認できない場合、高レイテンシは、クライアントから Cloud Spanner に到達する前に発生した可能性があります。

クライアント指標で高レイテンシが確認された場合は、以下をご確認ください。

• 他のサービスへのアクセスで高レイテンシが発生していないか

• クライアント マシンにリソース不足の問題がないか

• 高レイテンシは、特定のクライアント マシンで発生していないか

クライアント側に原因がある場合の例として、次のようなものがあります。

• CPU 使用率の突然の急激な上昇（これ自体は原因ではありませんが、マシン内の他のプロセスがレイテンシを引き起こした可能性を示します）

• ディスク I/O のパフォーマンス上限に到達

• エフェメラル ポートの枯渇、および TCP 接続を確立できない

• DNS クエリによる高レイテンシ

レイテンシは、「2. Google Front End」（Cloud Spanner エンドツーエンド レイテンシ ガイド）でも計測できます。これは、GFE がリクエストを送信したときから、「4. Cloud Spanner Database」から「3. Cloud Spanner API Front End」を介して最初にレスポンスを得たときまでの時間です。この指標で高レイテンシが見られた場合、GCP 側で詳細な調査を行う必要があります。これは、サポート パッケージがある場合、サポート チケットをオープンして行うことができます。（ただし、これは非常にまれです。）

なお、この GFE 指標には、TCP / SSL handshake のレイテンシは含まれないことにご注意ください。クライアント、GFE、Cloud Spanner の指標でレイテンシの原因がまったくわからない場合は、パケットをキャプチャして、TCP / SSL handshake で高レイテンシが生じていないか確認が必要な可能性があります。（ただし、これも非常にまれです。）

Cloud Spanner 使用での高レイテンシの調査

Cloud Spanner 指標で高レイテンシが見られる場合、最も一般的な原因は Spanner ノードの不足です。CPU 使用率が高 CPU 使用率に関するアラートの推奨値内であることをご確認ください。また、CPU 使用率が低い場合、優先度が低いタスクや中程度のタスク（統計パッケージの生成、コンパクション、スキーマの変更など）は、優先度のより高いタスクに影響を与えません。一方、使用率が 100% に近い場合、優先度の低いタスクがそれより優先度の高いタスクに影響を与える可能性があることにご注意ください。

CPU 使用率が高い場合は、高 CPU 使用率の調査に従って、影響を与えているクエリを絞ることができます。

全体の CPU 使用率は高くないにもかかわらず高レイテンシが確認される場合は、ホットスポットまたはロック待機に原因があることが考えられます。

ホットスポットに関しては、アクセスが頻繁なキーを Key Visualizer で確認できます。ホットスポットは、Cloud Spanner での最適化により解消される場合もあります。ただし、キー設計やトラフィック パターンによっては、最適化では対処できないこともあります。このような場合は、スキーマ設計のベスト プラクティスをご覧ください。

ロック待機時間を調査するには、ロックの統計情報を参照してください。詳細な情報は時間の経過とともに入手できなくなるため（データの保持参照）、高レイテンシの問題が発生したらすぐに、SPANNER_SYS.LOCK_STATS_TOP_MINUTE または SPANNER_SYS.LOCK_STATS_TOP_10MINUTE を確認することが有効です。

また、クエリ、読み取りリクエスト、トランザクションに、タグを関連付けることもできます。タグ付け機能と統計情報テーブルを使用することで、高レイテンシの原因をより効率的に特定できます。

高レイテンシ回避のヒント

ほとんどの場合は、上記の方法で原因と対策が見つかります。統計情報テーブルと Key Visualizer で原因が見つからない場合に、ユースケースの高レイテンシを回避するためのヒントをいくつかご紹介しましょう。

ステイル読み取りの使用

Cloud Spanner は、読み取りオペレーションに対して、デフォルトで強整合性を保証します。しかし、たとえ短いステイルネス（例: 1 秒）であっても、ステイル読み取りにより、パフォーマンスが大幅に改善することがあります。これは、更新が頻繁でありながら更新との強整合性が不要な行を読み取る必要があるときに、特に有効です。

STORING 句を使用して列データをインデックスに組み込む

FORCE_INDEX を SELECT クエリで使用すると、SELECT 列のデータがインデックス自体に保存されている場合、ベーステーブルをスキャンしなくてもインデックスから結果が得られます。これは、STORING 句を使用して行います。

Scan Index のレイテンシと、分散ユニオンまたは分散クロス適用のレイテンシの間の乖離が大きい場合は、STORING 句を使用することで、高いパフォーマンスが得られます。

行の削除でパーティション化 DML を使用する

一部の行を定期的に削除したい場合があります。TTL による行削除ポリシーの作成が簡単な方法ですが、自身で行う場合は、パーティション化 DML を使用することで、ロック範囲のスコープを最小化できます。この理由は、並列で実行されて他のリクエストへの影響を最小限にするためです。オペレーションはべき等でなくてはならない点にご注意ください。言い換えれば、オペレーションを 1 度実行した結果と複数回実行した結果の間の相違が許容できない場合は、パーティション化 DML を使用できません。

p99 での数秒のレイテンシは発生の可能性がある

レイテンシの上昇を抑制できないことがあります。Spanner フロントエンド サーバー（「3. Cloud Spanner API Front End」（レイテンシ ガイド）が、メンテナンスのため再起動されることがあります。再起動しようとしているサーバーにリクエスト（セッション）がある場合は、他のサーバーへのセッションの引き継ぎに数秒かかります。メンテンナンスはサービス レベルの確保に不可欠であるため、このようなイベントによるテール レイテンシは避けられません。

以上となります。この記事が、これまでわからなかった高レイテンシの原因と対策を見つける一助となれば幸いです。