Cloud Bigtable の費用最適化の基礎
Google Cloud Japan Team
※この投稿は米国時間 2021 年 2 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud では、さまざまなワークロードに対応できる多種多様なマネージド データベースを提供しています。MongoDB、Cassandra by Datastax、Redis Labs、Neo4j などのパートナーマネージド サービスに加えて、Google Cloud は次のようなマネージド データベース オプションを提供しています。リレーショナル ユースケース用の CloudSQL や Cloud Spanner、ドキュメント データ用の Firestore や Firebase、インメモリ データ管理用の Memorystore、水平方向にスケールし、低レイテンシで毎秒数百万のリクエストをサポートできるワイドカラム型 Key-Value データベースの Cloud Bigtable などです。
Cloud Bigtable などのフルマネージド型クラウド コンピューティング データベースにより、企業は従来の自己管理型データベースのような運用上のオーバーヘッドなしで、ペタバイトのデータを保存、分析、管理できるようになります。クラウド データベースが提供するあらゆる費用効率の優位性を基盤として、これらのシステムは拡大を続け、アプリケーションをサポートするため、費用を最適化する機会がさらに増えます。
本ブログ投稿では、Cloud Bigtable の各有料コンポーネントを考察し、さまざまなリソースの変更が費用に与える影響についてご説明します。さらに、特に要求の厳しいワークロードのリソース消費を管理するのに役立つ、ハイレベルでのベスト プラクティスをいくつかご紹介します（後の投稿では、あらゆる規模の組織に適用される手法とベスト プラクティスを活用して、パフォーマンスとのトレードオフでバランスをとりながら、費用を最適化する方法についてご説明します）。
Cloud Bigtable の費用に影響するリソースについて把握する
Bigtable インスタンスの費用は、消費されるリソースの量と直接相関しています。コンピューティング リソースは、リソースのプロビジョニング時間に応じて課金されますが、ネットワーク トラフィックやストレージの場合は、消費データ量に応じて課金されます。
Cloud Bigtable を使用すると、以下に応じて課金されます。
ノード
Cloud Bigtable では、ノードがコンピューティング リソース ユニットになります。ノード数の増加につれて、インスタンスはより高負荷な読み書きリクエストに対応し、より多くのデータを提供できるようになります。ノード料金は、クラスタがデータをソリッドステート ドライブ（SSD）またはハードディスク ドライブ（HDD）に保存しているかに関係なく、インスタンスで共通しています。Bigtable は、1 時間ごとにインスタンス クラスタに存在するノードの数を追跡します。各クラスタのリージョン別料金に基づき、その時間帯の最大ノード数に応じて課金されます。ノードの料金は 1 ノードあたりの時間単位で設定され、ノード単価はクラスタのリージョンによって決定されます。
データ ストレージ
Cloud Bigtable のインスタンスを作成するとき、ストレージ タイプは SSD または HDD を選択します。この設定は後から変更できません。1 か月間の平均使用ストレージが、月額料金の計算に使用されます。データ ストレージの費用はリージョンによって異なるため、インスタンス クラスタがプロビジョニングされているリージョンごとに、個別の項目が請求書に表示されます。
Cloud Bigtable の基盤となるストレージ形式は SSTable です。この内部表現によって消費される圧縮ディスク ストレージに対してのみ請求されます。これは、データが Bigtable サービスによってディスクに保存される際に圧縮され、その圧縮済みデータに対して課金されることを意味します。さらに、Google Cloud のすべてのデータは、耐久性を向上させる目的で Colossus ファイル ストレージ システムに保持されます。データ ストレージは、バイナリ ギガバイト（GiB）/月単位で請求されます。ストレージの単価は、デプロイされたリージョンとストレージのタイプ（SSD または HDD）に応じて決定されます。
ネットワーク トラフィック
上り（内向き）トラフィック、つまり Bigtable に送信されるバイトについては無料です。下り（外向き）トラフィック、つまり Bigtable から送信されたバイトについては、宛先に応じて料金が設定されます。同じゾーンへの下り（外向き）トラフィックと同じリージョン内のゾーン間の下り（外向き）トラフィックは無料ですが、リージョン間の下り（外向き）トラフィックと大陸間の下り（外向き）トラフィックについては、請求期間中に転送されたバイト数の合計に基づいて料金が漸進的に増加します。下り（外向き）トラフィックは、送信された GiB 数単位で課金されます。
バックアップ ストレージ
Cloud Bigtable ユーザーは、プロジェクトの割り当ての範囲内で、テーブルのマネージド型バックアップを簡単に開始して、データの破損やオペレータのエラーから保護することができます。バックアップ データは、バックアップが取得されたクラスタのゾーンに保存され、アーカイブされたテーブルのサイズより大きくなることはありません。使用されたストレージと、バックアップの作成から手動または割り当てられた有効期間（TTL）による削除までのバックアップ期間に応じて請求されます。バックアップ ストレージは GiB/月単位で請求されます。ストレージの単価はデプロイされるリージョンによって異なりますが、インスタンスのストレージ タイプによる違いはありません。
Bigtable の費用を調整する方法を理解する
すでにご説明したとおり、Cloud Bigtable の有料コンポーネントの費用は、プロビジョニングされたコンピューティング ノード、および請求期間中に消費されたストレージとネットワーク リソースに直接相関しています。したがって、消費するリソースが少なくなれば、運用費用が低減することを直感的に確認できます。
一方で、リソース消費率の削減がパフォーマンスと機能に与える影響を考慮する必要があります。データベースに依存する本番稼働中のシステムにおける運用費用削減の取り組みは、それがどんな形であれ、開発または管理の面で必要となる労力、そしてパフォーマンス面でトレードオフを迫られる可能性を同時に勘案しながら行うのが最善です。
リソース消費率の変更は、一部簡単に変更できるものもありますが、アプリケーションまたはポリシーの変更が必要になるもの、またデータ移行の完了時にのみ行えるものもあります。
ノード数
アプリケーションまたはワークロードによって、インスタンスが消費するリソースのうちどれが請求額の大部分を占めることになるかはさまざまです。しかしながら、プロビジョニングされたノード数が最大の単一請求項目となる可能性は非常に高くなります。たとえば Cloud Bigtable ノードは、ワークロードにもよりますが、費用の 50～80% を占めるのが一般的です）。したがってノード数の削減により、最も効果の高い迅速な費用削減を実現できる可能性が高くなります。
当然のことではありますが、クラスタの CPU の負荷は、クラスタノードによって行われるデータベース オペレーションに直結するものです。大まかに言えば、この負荷はデータベース オペレーションの複雑さ、1 秒あたりの読み書きオペレーションの数、ワークロードに必要なデータ スループットの組み合わせによって決まります。
ワークロードのオペレーション構成は周期的で、時間の経過とともに変化する可能性があるため、ワークロードのニーズに合わせてノード数を決定できます。
Cloud Bigtable クラスタを実行する際、2 つの最大値指標に対して変更できない上限が設定されています。使用可能な最大 CPU（100% の平均 CPU 使用率）と、ノードが管理できる保存データの最大平均量です。現時点では、SSD クラスタと HDD クラスタのノードが管理できるデータは、それぞれノードあたり 2.5 TiB と 8 TiB 以下に制限されています。
ワークロードがこれらの上限を超えそうになると、クラスタのパフォーマンスが大幅に低下する可能性があります。使用可能な CPU 使用率が飽和すると、データベース オペレーションにおいて望ましくない結果が発生しやすくなります。つまり、リクエストのレイテンシと、サービスエラー率が上昇してしまうのです。ノードあたりのストレージ量がインスタンス クラスタのハードリミットを超ると、上限を超えている各クラスタにノードを追加するまで、そのインスタンスのすべてのクラスタへの書き込みが失敗します。
そのため、クラスタのノード数を選択する際は、各指標の上限を下回るよう、ある程度の余裕を持たせることをおすすめします。データベース オペレーションが増加した場合でも、データベースは最適なレイテンシでリクエストを処理し続けることができ、処理のハードリミットに達する前に負荷の急増に対応する余地ができます。
または、ワークロードのコンピューティング負荷よりもデータ負荷が高い場合は、クラスタに格納されるデータの量を削減することで必要な最小ノード数を減らせる可能性があります。
データ ストレージのボリューム
アプリケーション（またはワークロード）の中には、大量のデータを生成して保存するものがあります。ワークロードの動作がこれに当てはまる場合は、Cloud Bigtable に保存または保持するデータを減らすことで、費用を削減できる可能性があります。
ご説明したように、データ ストレージ費用は、時間の経過とともに保存されるデータの量と相関関係があります。インスタンスに保存されるデータが少なければ、発生するストレージ費用は低くなります。ストレージ ボリューム、データの構造、保持ポリシーに応じて、SSD または HDD ストレージ タイプのいずれかのインスタンスで費用削減が実現する可能性があります。
上述のように、保存されたデータの合計に基づくノード数の最小要件が存在します。そのため、保存データ量を減らすことは、データ ストレージの費用だけでなくノードの費用を削減できる機会にもなり得ます。
バックアップ ストレージのボリューム
実行される各テーブル バックアップでは、バックアップ ストレージの保持期間中に追加費用が発生します。許容可能な範囲で保持するデータのコピー数を減らし、保持期間を短縮したバックアップ戦略を策定できれば、この部分の請求を減らすことができます。
ストレージのタイプ
アプリケーション（またはワークロード）のパフォーマンス面でのニーズによっては、データベースを SSD から HDD に移行することで、ノードとデータ ストレージの両方の費用を削減できる可能性があります。
これは、HDD ノードが SSD ノードよりも多くのデータを管理できるうえ、HDD のストレージ費用が SSD ストレージよりも桁違いに低いためです。
ただし HDD はパフォーマンス面では劣ります。読み取りと書き込みのレイテンシが長くなり、1 秒あたりの読み取り数とスループットが低下します。したがって、このストレージ タイプを選択する前に、対象となるワークロードのニーズに対する HDD の適合性を評価することが不可欠です。
インスタンス トポロジ
現時点では、Cloud Bigtable インスタンスには、選択した利用可能な Google Cloud ゾーンでプロビジョニングされた最大 4 つのクラスタを含めることができます。インスタンス トポロジに複数のクラスタが含まれる場合、リソース消費費用を削減できる機会がいくつか生じます。
少し時間を取って、インスタンス内のクラスタの数とロケーションを評価してください。
クラスタを追加するたびにノードとデータ ストレージの費用が増えることはご理解いただけるかと存じますが、実はネットワークの費用にも影響が及びます。インスタンスに複数のクラスタがある場合、データはインスタンス トポロジ内のすべてのクラスタ間で自動的に複製されます。
インスタンス クラスタが異なるリージョンに配置されていると、インスタンスではリージョン間データ レプリケーションの下り（外向き）ネットワークの費用が発生します。アプリケーション ワークロードが別のリージョンのクラスタにデータベース オペレーションを加える場合、アプリケーションから発信された呼び出しと Cloud Bigtable からのレスポンスの両方で下り（外向き）ネットワークの費用が発生します。
インスタンスで複数のクラスタを作成するとき、システムの可用性要件など、業務上欠かせない理由があります。たとえば、マルチクラスタ ルーティング ポリシーが使用されていれば、単一のクラスタはスリーナイン（99.9%）の可用性を、2 つ以上のクラスタを持つレプリケートされたインスタンスはフォーナイン（99.99%）の可用性を提供します。インスタンス トポロジのニーズを評価する際は、これらのオプションを考慮に入れる必要があります。
Cloud Bigtable インスタンスで追加のクラスタのロケーションを選択する際、データの提供と永続化が分散アプリケーションの各エンドポイントに近いところから行われるよう、地理的に離れたロケーションを選択してレプリカを配置することができます。こうすることでアプリケーションにさまざまなメリットがもたらされる一方、追加ノードとクラスタ ロケーションの費用、およびインスタンスが世界中に広がることにより生じ得るデータ レプリケーションの費用も考慮に値します。
また、管理されるデータ量に基づく最小ノード数の制限がある一方で、クラスタのノード数は対称である必要がありません。そのため、各クラスタに対して予想されるアプリケーション トラフィックの予想負荷に応じて、クラスタのサイズを非対称に設定できます。
費用の最適化を実現するハイレベルでのベスト プラクティス
ここまで、Cloud Bigtable インスタンス リソースの費用配分と、請求額に影響する利用可能なリソース消費の調整について説明してきました。次に、パフォーマンス目標とのトレードオフによりバランスを取りつつ費用削減を実現するいくつかの戦略について見てみましょう。
（次回の投稿では、これらのベスト プラクティスに沿うための手法と推奨事項についてご説明します）。
ノードの費用を削減するオプション
データベースがオーバープロビジョニングされている、つまりワークロードから発生するデータベース オペレーションを処理するのに必要な数を上回るノードがデータベースにある場合、ノードの数を減らすことで費用を削減できる可能性があります。
ノード数を手動で最適化する
ワークロードによって生成される負荷が適度に均一であり、ノード数が管理対象のデータ量によって制限されていない場合は、手動プロセスによりノード数を徐々に減らして、必要最小限のノード数を見つけることができる可能性があります。
オートスケーラーのデプロイ
お使いのインフラストラクチャにおいて、アプリケーション ワークロードのデータベース需要が周期的に変動する場合、または短い期間に限って負荷が高く、残りの期間は負荷が著しく低い場合、スケジュールや指標のしきい値に従ってノード数を自動的に増減できるオートスケーラーが有用かもしれません。
データベースのパフォーマンスの改善
すでにご説明したように、Cloud Bigtable クラスタは、アプリケーション ワークロードから発生するデータベース オペレーションによる負荷に対応しつつ、負荷の急増にも対応できる十分な余裕をもたせたサイズにする必要があります。必要な最小ノード数とデータベースによって実行される作業量の間には、この直接的な相関関係があるため、クラスタのパフォーマンスを向上させて必要な最小ノード数を減らせる可能性があります。
データベース スキーマまたはアプリケーション ロジックの変更で検討可能なものとして、Rowkey の設計変更、フィルタリング ロジックの調整、列の命名基準、列の値の設計などがあります。いずれの場合も、アプリケーションからのリクエストの対応に必要な計算量を減らすことが目標になります。
シリアル化されたデータ構造に多くの列を格納する
Cloud Bigtable は、データをワイドカラム形式で整理します。この構造により、スパースデータを提供するのに必要な計算量が大幅に削減されます。一方、データが比較的密集している場合、つまりほとんどの列が大半の行に入力され、アプリケーションがリクエストごとに大部分の列を取得するのであれば、列の値を単一のデータ構造のフィールドで結合すると便利です。プロトコル バッファは、そのようなシリアル化構造の一つです。
アーキテクチャの代替案を評価する
Cloud Bigtable は、読み取りが Rowkey スペース全体に均一に分散されている場合に、最高レベルのパフォーマンスを発揮します。サービス負荷がコンピューティング リソース間で均等に共有されるため、このようなアクセス パターンは理想的です。一方アプリケーションによっては、データとのやり取りが必ずしも均等に分散されない場合があります。
たとえば、特定のワークロード パターンでは、Cloud Memorystore を利用してリードスルーまたは容量キャッシュを提供できる場合があります。インフラストラクチャを追加すると費用が増えますが、特定のシステム動作により、Bigtable ノードの費用が大幅に減少する可能性があります。
このオプションは、小さな割合のキーに対するリクエストが大きな割合を占めるZipf 分布などのべき乗則分布に従ってワークロードがデータをクエリし、かつアプリケーションが必要とする P99 レイテンシが非常に低いものである場合に役立ちます。この場合生じるトレードオフはキャッシュが結果整合にとどまることです。結果として、アプリケーションはある程度のデータ レイテンシを許容する必要があります。
このようなアーキテクチャの変更により、リクエストをより効率的に処理できるようになると同時に、クラスタ内のノード数を減らせるようになります。
データ ストレージ費用を削減するオプション
ワークロードのデータ量によっては、データ ストレージの費用が Cloud Bigtable の費用の大部分を占める場合があります。データ ストレージの費用は、Cloud Bigtable に保存するデータを少なくするか、低費用のストレージ タイプを選択することで削減できます。
長期保存するデータを Cloud Storage または BigQuery にオフロードする戦略を策定することで、包括的分析を行うユースケースを妨げることなく、アクセス頻度の低いデータを Cloud Bigtable に保持するアプローチに対する実用的な代替手段を獲得できる可能性があります。
データ保持ポリシーを評価する
保存されるデータ量を減らす簡単な方法の一つは、データ保持ポリシーを修正して、特定期間のしきい値を超えた後に、古いデータをデータベースから削除できるようにすることです。
これは、保持ポリシーに定められた期限を過ぎたデータを定期的に削除する自動プロセスを作成することで達成できますが、Cloud Bigtable には、列ファミリーに割り当てられたポリシーに従ってガベージ コレクションを列に適用できる機能が組み込まれています。セルのバージョン数を制限するポリシーを設定したり、バージョンのタイムスタンプに基づいて各セルの最大期間または有効期間（TTL）を指定したりできます。
ガベージ コレクション ポリシーを設定すると、データ保持要件が確立されているアプリケーションで Cloud Bigtable のデータ量が無制限に増加するのを防ぐためのツールが提供されます。
より大きなデータ構造をオフロードする
Cloud Bigtable は、合計サイズが最大 100 バイナリ メガバイト（MiB）の行で良好なパフォーマンスを発揮し、最大 256 MiB の行をサポートします。これにより、アプリケーションが各行に格納するデータについて、多大な柔軟性が得られます。ただし、使用可能なすべてのスペースをすべての行で使用していると、データベースのサイズが非常に大きくなる可能性があります。
一部のデータセットでは、データ構造を分割し、Cloud Bigtable と Google Cloud Storage に分けて保存できる場合があります。この際、前者には分割したデータのうち小さな部分を、後者には大きな部分を保存するのが適切です。この方法では、アプリケーションで 2 つのデータストアを管理する必要がありますが、Cloud Bigtable に保存されるデータのサイズが縮小し、ストレージ費用が低減する可能性があります。
インスタンス ストレージを SSD から HDD に移行する
特定のアプリケーションのストレージ費用を削減するための最後のオプションとして、ストレージ タイプを SSD から HDD に移行する方法が挙げられます。HDD ストレージのギガバイトあたりのストレージ費用は、SSD よりも桁違いに低コストです。したがって、大量のデータをオンラインで保持する必要がある場合は、このタイプの移行を検討するとよいかもしれません。
とはいえ、この方法は慎重に検討してから実行する必要があります。パフォーマンスとのトレードオフを包括的に評価し、データ移行を実行するための運用能力を割り当てた場合にのみ、実行可能な方法として選択できます。
バックアップ ストレージの費用を削減するオプション
現時点では、各テーブルのバックアップを最大 50 個作成し、これを最大 30 日間保持できます。確認をしないままでは、短期間に多額の費用が発生する可能性があります。
バックアップの頻度と、対象の保持ポリシーについて、慎重に評価してください。現在保持しているアーカイブの量が明確な業務要件または技術要件に基づくものでない場合は、費用削減を実現できる可能性があります。
次のステップ
Cloud Bigtable は、低レイテンシのデータベース操作と線形スケーラビリティを実現する、データ処理とデータ ストレージの両面において極めて高性能なデータベースです。インフラストラクチャ スタック内でプロビジョニングされたコンポーネントと同様に、Cloud Bigtable の運用費用は、その運用によって消費されるリソースに正比例します。リソース費用、実施可能な調整、費用最適化のいくつかのベスト プラクティスを理解することで、アプリケーションのパフォーマンス要件と毎月の支出との間でバランスを見いだすための最初のステップを踏み出すことができます。
このシリーズの次回の投稿では、費用の最適化に利用できるオプションをよりよく理解できるように、アプリケーションに対して実施できるいくつかのモニタリングについてご説明します。
その前に、以下についてもぜひご確認ください。
Cloud Bigtable の料金についての詳細
SSD ストレージか HDD ストレージかの選択時のおすすめの方法
-Cloud Professional Services Organization テクニカル アカウント マネージャー Aqsa Fulara
-Cloud ソリューション アーキテクト Drew Stevens
