Bigtable 自動スケーリング: 詳細とコスト削減分析

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

Cloud Bigtable は、ボタンをクリックするだけで、パフォーマンスとストレージの需要を満たすようなスケーリングを迅速に行える、フルマネージド サービスです。Bigtable を使用しているのであれば、ピーク時のスループットに対応するようにクラスタサイズを構成したり、ワークロードと一致するようにプログラムでスケーリングを行ったりしているのではないでしょうか。Bigtable は、管理性向上のために自動スケーリングをサポートするようになりました。Google が行ったテストの一つでは、一般的な 1 日周期のワークロードのコストを 40% 以上削減しました。

自動スケーリングを有効にすると、必要な分のみの支払いで済みます。Bigtable は、変化するワークロードの需要に対応して、自動で容量の追加や削除を行います。自動スケーリングを使用すると、容量のプロビジョニング管理のオーバーヘッドが削減されるため、インフラストラクチャの管理にかかる時間が減少し、ビジネスにより多くの時間をかけることができます。自動スケーリングは HDD と SSD の両方のクラスタで機能し、すべての Bigtable リージョンで使用できます。

今回は、この機能を使用するタイミングと使用方法について説明し、自動スケーリングの実際のパフォーマンス分析を行い、最後にこの機能がデータベース費用にどのような影響を与えることができるのかを確認します。

自動スケーリングを有効にする

Cloud Bigtable の自動スケーリングはクラスタレベルで構成され、Cloud Console、gcloud コマンドライン ツール、Cloud Bigtable Admin API、Bigtable クライアント ライブラリを使用して有効にします。

自動スケーリングを有効にすると、容量の使用状況の変化に応じて、Bigtable によりクラスタ内のノード数が自動的にスケーリングされます。過剰なプロビジョニング（不要なコスト）やプロビジョニング不足（ビジネス チャンスの損失）など、不正確な容量の推定に伴うビジネス クリティカルなリスクが著しく低減されます。

自動スケーリングは、既存クラスタでの有効化や新規クラスタでの構成が可能です。目標の CPU 使用率とノード数の維持範囲の 2 つの情報が必要です。複雑な計算やプログラム、メンテナンスは必要ありません。ただし、最大ノード数を最小ノード数の 10 倍以上の範囲に指定することはできないという制約に注意してください。ストレージの使用率は自動スケーリングの 1 つの要素ですが、ストレージ使用率の目標は Bigtable によって設定され、設定の変更はできません。

以下の例では、Cloud Console と gcloud を使用して自動スケーリングを有効にする方法を示しています。これらの方法を利用すると、すぐに使い始めることができます。

Cloud Console を使用する

Cloud Console でインスタンスを作成または更新する際、手動でのノード割り当てか、自動スケーリングを選択できます。自動スケーリングを選択した場合は、ノードの範囲と CPU 使用率目標を設定します。

コマンドラインを使用する

gcloud コマンドライン ツールで自動スケーリングを構成するには、以下に示すように、クラスタの作成時または更新時に自動スケーリング パラメータを変更します。

既存のクラスタを更新する:

新しいクラスタを作成する:

透明性と信頼性

Bigtable チームでは、お客様の一般的なワークロードで自動スケーリングが十分に機能することを確認するため、多数のテストを実施しました。クラスタをモニタリングして、スケーリングの理由を把握できるように、Cloud Bigtable の自動スケーリングのパフォーマンスに関する知見を得ることが重要です。Bigtable の動作を明確に理解できるように、包括的なモニタリングと監査ログを提供しています。Bigtable のアクティビティと見込まれるコストやパフォーマンスを結び付け、期待するパフォーマンスが維持されるように自動スケーリングの構成を微調整できます。以下は、指標のグラフとクラスタのログが表示されている Bigtable クラスタ モニタリングのページです。

ワークロードでの適切な自動スケーリングのタイミング

Bigtable は、動的なトラフィック プロファイルにより、さまざまなユースケースに対する柔軟性を備えています。Bigtable の自動スケーリングは、お客様のビジネスごとに適切な構成が異なるため、最適な状態に関するガイドラインを以下に示します。

自動スケーリングを使用すべき場合

• 既存の Bigtable ユーザーで、クラスタのパフォーマンスを維持しながら、コストを最適化したい場合。たとえば、オンラインでの販売に見られるような 1 日周期のトラフィック パターンに適しています。

• 新規の Bigtable ユーザーまたは新規のワークロードがある場合。ユースケースが不明である場合に、それに合わせて十分な容量をプロビジョニングすることは困難です。

• ビジネスが成長中で、将来の成長の程度が不明の場合。あらゆる機会に備えてスケーリングの準備をしておく必要があります。

自動スケーリングでの解決が難しいもの

• 一定のバッチ ワークロード。自動スケーリングは、トラフィックの急激な増加（データの「段階的な上昇」または一括アップロード）に反応します。しかし、Bigtable はその後もノードにおける短期間での増加に対してデータとトラフィックを再調整する必要があり、再調整の結果、パフォーマンスに影響が及ぶ可能性があります。

• 自動スケーリングは、Bigtable クラスタにおけるホットスポット化、つまり「過剰使用」の解決策としては適切でない恐れがあります。このようなシナリオでは、データのアクセス パターンと行キー / スキーマ設計の検討事項の確認をおすすめします。

実際の自動スケーリングの動作

Cloud Bigtable における水平方向のスケーラビリティは、その機能の中核であり、コンピューティングとストレージの分離によって実現されています。Bigtable インスタンスでのノード数の更新は、自動スケーリングの使用にかかわらず高速です。クラスタにノードが追加されると、Bigtable は追加ノード全体でデータを再調整し、クラスタ全体のパフォーマンスを改善します。クラスタがスケールダウンされると、Bigtable は削除されたノードからそれ以外のノードを対象に負荷を再調整します。

自動スケーリングを有効にすると、Bigtable はクラスタの使用率目標指標をモニタリングし、必要に応じてリアルタイムで対応し、ワークロードにあわせたスケーリングを行います。Bigtable のネイティブな自動スケーリング ソリューションの効率性を示すものとしては、クラスタのタブレット サーバーへ直接接続して指標をモニタリングしているということが挙げられます。その結果、自動スケーリングに必要なアクションが迅速に行われます。そして、設定された使用率目標に基づき、ノードの追加または削除を行います。Bigtable の自動スケーリング ロジックでは、負荷の増大に対しては迅速なスケールアップが行われますが、スケールダウンについては残りのノードに負荷がかかりすぎることを避けるため、時間をかけて行われます。

ワークロード例

自動スケーリングのパフォーマンスがさまざまなシナリオで最適になっていることを確認するために、Google が実施したテストの一つを見てみましょう。このテストのシナリオは、ピーク時間中のアクティブ ユーザーがピーク時間以外には著しく減少するような、典型的な 1 日周期のトラフィック パターンです。ノードあたり 30 GB のデータを含む Bigtable インスタンスを作成してこのシナリオのシミュレーションを行い、1 KB のポイント読み取りを実施しました。

Bigtable のモニタリング グラフを使用して、このテストから得られる情報を確認しましょう。クラスタのモニタリング グラフには、Cloud Console の Bigtable インスタンスの概要ページからクラスタ ID をクリックすることでアクセスできます。

クリックしてクラスタの概要ページへ移動すると、以下のようなクラスタのノードと CPU 使用率のモニタリング グラフが確認できます。

ノード数のグラフには、12 時間で 3 ノードから 27 ノードへ変化し、3 ノードに戻る様子が示されています。グラフには構成済みの最小ノード数と最大のノード数のほか、現在の CPU 負荷に対する推奨ノード数も表示されるため、簡単にそれらを比べながら確認できます。スループットに対応して迅速にスケールアップが行われるため、CPU 使用率の増加に沿って、CPU 目標に対する推奨ノード数（オレンジ色の線）と実際のノード数（青色の線）が近接して並んでいます。CPU 使用率が減少すると、実際のノード数は、推奨ノード数よりも遅れて減少します。この動作は、残りのノードに負荷がかかりすぎるのを避けるために、スケールダウンをより穏やかに行う Bigtable の自動スケーリング ポリシーに沿ったものです。

CPU 使用率のグラフでは、のこぎりの歯のようなパターンが確認できます。CPU 使用率がピークに達するときに両方のグラフを比較すると、CPU 使用率目標を維持するために、ノード数が調整されている様子を確認できます。Bigtable がノードを追加すると CPU 使用率は減少し、ノードが削除されると使用率は急増します。これは想定どおりの動作です。この例（典型的な 1 日周期のトラフィック パターン）では、スループットが常に増加または減少しています。異なるワークロード（たとえば、スループットが変化してその後は一定に保たれるようなワークロード）の場合、より動きの少ない CPU 使用率になります。

クラスタの概要ページでは、ログを確認し、ノード数が変化するタイミングとその理由を確認できます。

さらに詳しい情報を得るために、インスタンス モニタリング ビューに移動します。ここでは、テスト ワークロードの動きを示すさらに多くのグラフが確認できます。上述の 1 日周期のトラフィック パターンが自動スケーリングの動作と一致しています。つまり、スループットの増加にあわせてノード数が増加し、スループットの減少にあわせてノード数が減少しています。

コスト評価

今回のテスト ワークロードは 12 時間実行されました。このシナリオにおいて、自動スケーリングを使用した場合と使用しなかった場合のコストの変化について確認します。

Bigtable ノードのコスト1 を、ノードごとに 1 時間あたり $0.65 と仮定します。

自動スケーリングを使用したときと、ピーク時にあわせてスケーリングしたときのノード数とコストを比較します。

15.84 ノード（自動スケーリングの平均）÷ 27 ノード（ピーク時にあわせたスケーリング）= 0.587

このシナリオで自動スケーリングを使用した場合、必要なノード数はピーク時の 58.7% です。この例で Bigtable ネイティブの自動スケーリングを使用した場合、これは約 41.3% のコスト削減となる可能性があります。

大量のデータと秒間クエリ数を処理する場合には、非常に大きな削減が見込まれます。

まとめ

Bigtable で自動スケーリングを使用することで、スループットにあわせたノード数とコストの維持が可能なマネージド ソリューションを利用できます。

• 使用を開始する: 自動スケーリングを有効にするには、Cloud Console またはコマンドラインを使用します。

• パフォーマンスを確認する: Bigtable モニタリング ツールにより、レイテンシの監視とノード範囲の調整が行えます。

• コストを削減する: シナリオ例では、60% の CPU 使用率を維持しつつ、1 日周期のワークロードのコストを、ピーク時にあわせてスケーリングした場合の 58.7% に改善しました。

^{1. Bigtable の料金: https://cloud.google.com/bigtable/pricing}

^{2. 「ピーク時にあわせたスケーリング」は、ピーク時の負荷に確実に対応できるように、多くの DB 運用マネージャーが採用しているプロビジョニング ポリシーです。}