Cloud Bigtable クラスタの CPU 使用について

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

CPU 使用率は、Cloud Bigtable の重要業績評価指標です。Bigtable のパフォーマンスとコストを最適化するためには、CPU 使用量の把握が不可欠です。Bigtable クラスタの CPU 使用率をより詳細に可視化できるようになり、Bigtable のオブザーバビリティが大幅に向上しました。アプリ プロファイル、メソッド、テーブルなど、さまざまな項目から使用率を分類することが可能になりました。このようなきめ細かなレポートは、より多くの情報に基づいたアプリケーション設計の選択や、パフォーマンス関連のインシデントの診断に役立ちます。

この投稿では、ペルソナベースのユーザー ジャーニーの例を通して、この可視性が現実の世界でどのように利用できるかをご紹介します。

ユーザー ジャーニー: 高レイテンシのインシデントを調査する

対象となるペルソナ: サイト信頼性エンジニア（SRE）

ABC 社では、マルチテナント環境で Cloud Bigtable を実行しています。ABC 社の複数のチームが同じ Bigtable インスタンスを使用しています。

アリスは ABC 社の SRE です。クラスタのテール レイテンシがパフォーマンスの許容しきい値を超えたため、アリスは通知を受け取りました。アリスはクラスタレベルの CPU 使用率のグラフを見て、インシデントの発生期間中に CPU 使用率が急上昇したことを確認します。

アリスは、このスパイクの詳細を把握するために、さらに掘り下げたいと考えています。彼女が最初に知りたいのは、「どのチームに連絡すればいいのか」です。

幸いなことに、ABC 社のチームでは、各チームの使用率をアプリ プロファイルに次のような形式でタグ付けするというベスト プラクティスを採用しています。<teamname>-<workload-type>

Bigtable インスタンスには、次のアプリ プロファイルがあります。

• revenue-updater

• info-updater

• personalization-reader

• personalization-batch-updater

インスタンスのデータは、次のテーブルに保存されています。

• revenue

• client-info

• personalization

彼女は、アプリ プロファイルごとの CPU チャートを使用して、personalization-batch-updater アプリ プロファイルがインシデントの発生時に最も多くの CPU を使用していたことと、personalization-reader アプリ プロファイルのサービス提供パス トラフィックに、レイテンシ急増に対応するスパイクが見られたことを確認しました。

この時点でアリスは、personalization-batch-updater トラフィックが personalization-reader トラフィックに悪影響を与えていることを把握します。彼女はさらに、Metrics Explorer のダッシュボードを詳しく調べて、問題のあるメソッドとテーブルを特定します。

アリスは、personalization-batch-updater アプリ プロファイル、personalization テーブル、MutateRows メソッドを、サービス提供パス トラフィックのテール レイテンシを引き上げている CPU 使用率の増加の原因と特定しました。

この情報を使用して、彼女はパーソナライズ チームに連絡し、バッチジョブを開始する前にクラスタを正しくプロビジョニングして、他のテナントのパフォーマンスに影響を与えないようにしました。

このシナリオでは、次のようなオプションが検討できます。

1. 複数のクラスタを持つレプリケートされたインスタンスでバッチジョブを実行します。バッチジョブ専用のクラスタをプロビジョニングし、単一クラスタ ルーティングを使用して、サービス提供パスのトラフィックをバッチ アップデートから完全に分離します。

2. バッチジョブの開始前およびバッチジョブの継続期間中に、クラスタにプロビジョニングするノード数を増やします。このオプションは、サービス提供パスのトラフィックに影響を与える可能性があるため、オプション 1 の方が推奨されます。ただし、オプション 1 の方が費用効果は高くなります。

ユーザー ジャーニー: スキーマとコストを最適化する

対象となるペルソナ: デベロッパー

ボブは、Bigtable に新しいワークロードをオンボードしている開発者です。彼は機能の開発を完了し、本番環境にリリースする前にパフォーマンス ベンチマーク フェーズに進みます。彼は、クエリのスループットとレイテンシの両方が予想よりも低いことに気づき、問題のデバッグを開始しました。

最初のステップとして、クラスタの CPU 使用率を見てみると予想以上に高く、推奨される最大値付近で推移していました。

さらにデバッグするために、彼はアプリ プロファイルごとの CPU 使用率と、テーブル チャートごとの CPU 使用率を調べます。彼は、CPU の大部分が product-reader アプリ プロファイルと product_info テーブルによって消費されていると判断しました。

彼はアプリケーション コードを調査し、クエリに値範囲フィルタが含まれていることに気づきました。値フィルタが高コストになっていることがわかったため、フィルタをアプリケーションに移動しました。これにより、Bigtable クラスタの CPU 使用率が大幅に減少しました。結果として、パフォーマンスが向上するだけでなく、Bigtable クラスタのコストも削減できました。

新しいオブザーバビリティ指標である「アプリ プロファイル、メソッド、テーブルごとの CPU」を使用するメリットや利用場面を理解するために、このブログ投稿をご利用ください。

指標へのアクセス

これらの指標には、Bigtable Monitoring UI の [テーブル] タブと [アプリケーション プロファイル] タブからアクセスできます。メソッドの内訳を確認するには、Metrics Explorer で指標を表示します。Metrics Explorer には Cloud Monitoring UI からも移動できます。

- Cloud Bigtable、エンジニアリング マネージャー、Vikram Khemka