Bigtable のモニタリング: クライアントサイドの指標

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

Cloud Bigtable は、ミリ秒単位 1 桁のレイテンシでの読み取りと書き込みを可能にする NoSQL データベース サービスです。しかし、複雑なインフラストラクチャで、グローバルなお客様向けの何百万ものインタラクションを伴うアプリケーションを開発する場合には、予期しないレイテンシが発生する可能性があります。大規模なシステムでレイテンシが発生すると、ビジネスの機会が失われたり、ユーザー エクスペリエンスが低下したり、データ パイプラインが中断したりする可能性があります。

Bigtable はマネージド サービスであるため、いくつかのリアルタイム ダッシュボードとツールを使用してリソースをモニタリングできます。スループット、リソース使用状況、エラー率などが表示されるため、デプロイ、デバッグ、問題の識別をすばやく行えます。このたび、モニタリング エクスペリエンスを向上させるため、いくつかの新しいクライアントサイド指標を Java 用 Bigtable クライアント ライブラリの一部として追加しました。サポートに寄せられるよくある質問に基づき、リモート プロシージャ コール（RPC）全体の透明性を高める指標を特定しました。今後お客様は、レイテンシの原因が開発側の問題（新しい機能やコード内のアンチパターンなど）なのか、それともサービス ダウンタイムが問題を引き起こしていてエスカレーションが必要なのかを、より迅速に判断できます。

このブログ投稿では、新しい Bigtable クライアントサイド指標を使用してアプリケーションに関する詳しい分析情報を得る方法をご紹介します。その次に、いくつかのシナリオを検証しながら、指標を使用して問題を解決する方法を学びます。

新しい指標を理解する

Java 用 Bigtable クライアント ライブラリ、または HBase から移行するお客様向けの HBase クライアントを使用するときに、新しい 8 つの指標が利用可能になりました。これらの指標のほとんどは、システムへの有益な透明性を提供してくれるデータポイントです。

これまでお客様は、リクエストに関する全体的なレイテンシを表示できたかもしれませんが、その中の個々のレイヤを調査することはできず、そのためシナリオによっては問題の解決が困難でした。今後は、さまざまな問題を自分ですばやく識別できるようになり、サポートへの問い合わせが必要な場合にも、より多くの情報に基づく質問をすることができます。

下の図は、リクエスト ライフサイクルを簡略化して示したものです。それぞれの新しい指標にはラベルが付いているため、リクエストのどのレイヤを測定する指標かがわかります。ライフサイクルの始めにクライアント アプリケーションから Google フロントエンドに向けてリクエストが発行され、それが Cloud Bigtable サーバーにルーティングされます。リクエスト元が再試行可能エラーを受け取った場合、クライアントは再試行をスケジュールし、リクエストを再送信します。

レイテンシの原因がどこにあるか識別できれば、トラブルシューティングを始める手順が明確にわかります。それぞれの指標の詳しい説明が Cloud Bigtable ドキュメントにあります。最初にこのクイック リファレンスをご覧ください。

クライアントサイド指標のセットアップ

15 分後、Cloud Monitoring UI と Cloud Monitoring API を介して新しい指標を利用できるようになります。Cloud コンソールを介して、Metrics Explorer の中の指標を見てみましょう。

指標セレクタを使って bigtable.googleapis.com/client を検索し、クライアントサイド指標を見つけます。

グラフの下部にある [別の指標を追加] をクリックすると、グラフ内に他の指標を表示できます。また、[Save Chart] をクリックしてダッシュボードにグラフを追加することで、それぞれの指標を含むダッシュボードを作成できます。サンプルのダッシュボード（JSON ファイル）、およびこれを Metrics Explorer にアップロードしてインストールする手順をご覧ください。この例では、カスタム可能なダッシュボードにすべての新しい指標が示されています。

よくある問題を解決する

すでに述べたとおり、さまざまな理由で、想定とは異なるレイテンシが発生する可能性があります。以下に 3 つの例を取り上げて、クライアントサイド指標で明らかになる高レイテンシ、その原因、修正方法を見ていきます。

高い試行レイテンシ: チャネルプールのサイズが不適切

最初の例のアプリケーションでは、Bigtable から読み取る秒間クエリ数（QPS）が非常に低く、1 秒につき約 1 リクエストです。おそらくこれは各リクエストで大量のデータを読み取るダッシュボードですが、スループットのトラフィックを頻繁には受信していません。

レイテンシ グラフは次のようになります。

オペレーション レイテンシは 3 秒つまり 3,000 ms を超えていますが、Bigtable サーバー レイテンシはすべて 25 ms 未満です。したがって、このクエリが問題を引き起こしているのではなく、何か別の問題の可能性があることがわかります。カスタム Bigtable クライアントサイド指標ダッシュボードを見ると、再試行カウントと接続エラーが含まれていて、コンテキストが良くわかります。

再試行カウント指標を見ると、リクエストが何度も再試行されていることがわかります。さらに、1 分あたり数千件の接続エラーがあり、接続に何らかの問題があることを示しています。

高いアプリケーション ブロッキング レイテンシ: 行読み取りライブ ストリームの処理

別のアプリケーションでは、いくつかの行に対して接頭辞スキャンを行い、それぞれを処理しているようです。コードのスニペットは次のようになっています。

Bigtable サーバー レイテンシの 50 パーセンタイル（P50）は約 4 ms と低いですが、試行レイテンシの P50 は約 275 ms です。このレイテンシの原因は応答の処理時間であることがわかります。指標を見ると、このレイテンシの原因のほとんどは、同じく約 275 ms のアプリケーション ブロッキング レイテンシであることがわかります。

全体的なレイテンシ、つまりこのシナリオでは試行レイテンシを削減するには、次のように行をキャッシュに保存してから処理します。

この例では、各行の処理に依然として 5 ms かかるので全体的なアプリケーション パフォーマンスに大きな違いは見られません。しかしこれは、より大きなレイテンシが見込まれることを検証したり、一つの要因として完全に取り除いたりするのに良い方法です。下のグラフは元のレイテンシと、コード更新後のレイテンシ低減を示しています。

高いサーバー レイテンシ: リージョン間アプリケーション サーバーと Bigtable

この最後の例では、さきほどのレイテンシの問題をすべて解決した後、グローバルに拡張するために別のリージョンに Bigtable クラスタをもう 1 つ追加する必要があります。レイテンシを検査すると、試行レイテンシが 200 ms 前後である一方、Bigtable サーバー レイテンシは約 2.2 ms と低いままです。

しかしサーバー レイテンシは約 147 ms であり、これは高い試行レイテンシの原因がアプリケーションと Bigtable サーバーとの通信であることを示しています。リージョンを超えた往復呼び出しが発生していますから、そうなるのも当然です。ここで新しい Bigtable クラスタのリージョン内のアプリケーション サーバーに 1 つのマシンを追加すると、この往復コストがなくなるはずです。

次のステップ

この記事では、Cloud Bigtable の新しいクライアントサイド指標を使ってシステムのオブザーバビリティと透明性を改善させる方法、それらの指標を有効にする方法、そしてシステム レイテンシ全般に影響が出ている場合によく見られるシナリオをいくつかご紹介しました。

• 新しいクライアントサイド指標を深く理解して、Bigtable システムをさらに最適化しましょう。

• モニタリング ダッシュボードをいくつかセットアップしましょう。

• Bigtable パフォーマンス全般について学習し、、データベース設計が原因で高い Bigtable サーバー レイテンシが生じていないこと、およびツールを最大限に活用していることを確認しましょう。

• 新しくモニタリングされる指標のアラートを追加して、レイテンシが変化したときにすばやく対応できるようしましょう。