Google Cloud アーキテクチャ フレームワークのドキュメントでは、Google Cloud のデータベースと分析ワークロードのコストを最適化するための最適化案について説明します。
このセクションのガイダンスは、クラウド内のデータベースと分析ワークロードのプロビジョニングおよび管理を担当するアーキテクト、デベロッパー、管理者を対象としています。
このセクションでは、次のプロダクトに関するコスト最適化の最適化案について説明します。
Cloud SQL
Cloud SQL は、MySQL、PostgreSQL、SQL Server 用のフルマネージド リレーショナル データベースです。
使用量のモニタリング
モニタリング ダッシュボードで指標を確認して、デプロイメントがワークロードの要件を満たしていることを確かめます。
リソースを最適化する
Cloud SQL リソースの最適化に役立つ最適化案は次のとおりです。
- 目標復旧時間（RTO）および目標復旧時点（RPO）と整合性の取れた高可用性および障害復旧戦略を設計します。ワークロードに応じて、次のことをおすすめします。
- 短い RTO と RPO が必要なワークロードの場合は、高可用性構成とリージョン フェイルオーバー用のレプリカを使用します。
- 長い RTO と RPO に耐えられるワークロードの場合は、自動化されたオンデマンドのバックアップを使用します。これによって、障害発生後に復元するのに時間がかかることがあります。
- 必要最小限のストレージ容量でデータベースをプロビジョニングします。
- データの増加に合わせてストレージ容量を自動的にスケーリングするには、ストレージの自動増量機能を有効にします。
- ユースケースに適したストレージ タイプ（ソリッド ステート ドライブ（SSD）またはハードディスク ドライブ（HDD））を選択します。SSD は、ほとんどのユースケースで最も効率的でコスト効果の高い選択肢です。HDD は、レイテンシの影響を受けにくい大規模なデータセット（10 TB 超）や、アクセス頻度の低いデータセットに適しています。
レートを最適化する
リソースのニーズが予測可能なワークロードについては、確約利用割引の購入を検討します。1 年間の場合はオンデマンド料金の 25%、3 年間の場合は 52% の割引が適用されます。
Spanner
Spanner は、無制限のスケーリングと強整合性を備えたクラウドネイティブ データベースで、最大 99.999% の可用性を実現します。
使用量のモニタリング
以下は、Spanner リソースの使用状況を追跡するための最適化案です。
- デプロイをモニタリングし、CPU の最適化案に基づいてノード数を構成します。
- デプロイに対してアラートを設定して、ストレージ リソースを最適化します。適切な構成を決定するには、ノードあたりの上限の推奨値をご覧ください。
リソースを最適化する
Spanner リソースの最適化に役立つ最適化案は次のとおりです。
- 処理ユニット（PU）とノードの間でリソースをプロビジョニングすることで、Spanner で小規模なワークロードをはるかに低コストで実行する。1 つの Spanner ノードは 1,000 PU に相当します。
- クエリ オプティマイザーを使用して、クエリ実行のパフォーマンスを向上させる。
- 効率的な実行プランを作成するためのベスト プラクティスを使用して、SQL ステートメントを作成する。
- オートスケーラー ツールを使用して、Spanner のデプロイの使用量とパフォーマンスを管理する。このツールは、インスタンスをモニタリングし、ノードを自動的に追加または削除して、インスタンスを推奨される CPU とストレージの上限内にとどめるために役立ちます。
- ポイントインタイム リカバリ（PITR）を使用して、不注意による削除や書き込みから保護します。バージョンの保持期間が長いデータベース（特に、データが頻繁に上書きされるデータベース）では、システム リソースの使用量と必要なノード数が増えます。
- バックアップ戦略を確認し、次のいずれかのオプションを選択します。
- バックアップと復元
- エクスポートとインポート
レートを最適化する
Spanner ノードのロケーションを決定する際は、Google Cloud リージョン間の料金の違いを考慮してください。たとえば、us-central1 リージョンにデプロイされたノードは、southamerica-east1 リージョンのノードよりも 1 時間あたりのコストが大幅に削減されます。
Bigtable
Bigtable は、大規模で低レイテンシのワークロード向けのクラウドネイティブのワイドカラム型 NoSQL ストアです。
使用量のモニタリング
以下は、Bigtable リソースの使用状況を追跡するための最適化案です。
- 使用状況の指標を分析してリソース最適化の機会を特定します。
- Key Visualizer 診断ツールを使用して、Bigtable クラスタのホットスポットとホットキーを特定します。
リソースを最適化する
Bigtable リソースの最適化に役立つ最適化案は次のとおりです。
- レイテンシとストレージ容量のバランスの取れた CPU とディスクの使用量を確保するため、Bigtable クラスタのノード数とサイズを評価して調整します。
- Bigtable クラスタをプログラムによってスケーリングし、ノード数を自動的に調整することで、可能な限り低い費用でパフォーマンスを維持します。
次の点を考慮して、ユースケースで最も費用対効果の高いストレージ タイプ（HDD または SSD）を評価します。
- HDD ストレージは SSD よりも低コストですが、パフォーマンスも低くなります。
- SSD ストレージは HDD よりも費用がかかりますが、高速で予測可能なパフォーマンスが実現します。
HDD によるコスト削減は、非常に大きなデータを保存しない限り、Bigtable クラスタ内のノード費用に比べてごくわずかです。HDD ストレージは、大規模なデータセット（10 TB 超）で、レイテンシがあまり重要でない場合やアクセス頻度が低い場合に適切であることがあります。
ガベージ コレクションを使用して、期限切れのデータと古くなったデータを削除します。
ホットスポットを回避するには、行キーの設計のベスト プラクティスを適用します。
RPO に合わせて、費用対効果に優れたバックアップ プランを設計します。
クラスタの使用量を減らし、ノード数を減らすには、Memorystore を使用して、キャッシュに保存可能なクエリの容量キャッシュを追加することを検討してください。
その他の情報
BigQuery
BigQuery は、ビジネスのアジリティを高めるように設計された、スケーラビリティと費用対効果に優れたサーバーレスのマルチクラウド データ ウェアハウスです。
使用量のモニタリング
以下は、BigQuery リソースの使用状況を追跡するための最適化案です。
- BigQuery の費用をプロジェクト別、ユーザー別に分けて可視化します。最も費用のかかるクエリを特定して最適化します。
INFORMATION_SCHEMAメタデータ テーブルを使用して、プロジェクト、ジョブ、予約のスロット使用率を分析します。
リソースを最適化する
BigQuery リソースの最適化に役立つ最適化案は次のとおりです。
- コンプライアンス戦略に基づいて、データのデータセット レベル、テーブルレベル、パーティション レベルの有効期限を設定します。
- クエリあたりの課金されるバイト数を制限することで、クエリ費用を制限します。偶発的な人的ミスを防ぐには、ユーザーレベルとプロジェクト レベルでコスト管理を有効にします。
- 必要なデータのみをクエリします。クエリ全体のスキャンは避けます。データ セマンティクスを探索して理解するには、無料のデータ プレビュー オプションを使用します。
- 処理費用を削減し、パフォーマンスを向上させるため、可能であればテーブルのパーティション分割とクラスタ化を行います。
- クエリを早い段階で、できるだけ頻繁にフィルタリングします。
- 複数のソース（Bigtable、Cloud Storage、Google ドライブ、Cloud SQL など）からデータを処理する場合は、フェデレーション アクセス データモデルを使用して、ソースから直接データのクエリを実行し、データの重複を回避します。
- データを複製する代わりに、BigQuery のバックアップを使用します。データの障害復旧シナリオをご覧ください。
レートを最適化する
次の最適化案は、BigQuery リソースの課金レートの低減に役立ちます。
- データの編集方法を評価し、低コストの長期ストレージ料金を活用します。
- 定額とオンデマンドの料金の違いを確認し、要件に適したオプションを選択します。
- データ ワークフローでストリーミング挿入の代わりにバッチ読み込みを使用できるかどうかを評価します。BigQuery に読み込まれたデータがすぐに使用される場合は、ストリーミング挿入を使用します。
- パフォーマンスを向上させ、データ取得のコストを削減するには、キャッシュに保存されたクエリ結果を使用します。
その他の情報
Dataflow
Dataflow は、統合ストリームおよびバッチデータ処理用の高速で費用対効果の高いサーバーレス サービスです。
使用量のモニタリング
以下は、Dataflow リソースの使用状況を追跡するための最適化案です。
- 小規模な負荷テストを実行してジョブの最適なパフォーマンスを検出し、スループット係数を推定することによって Dataflow ジョブの費用を予測します。
- オブザーバビリティ ダッシュボードを使用して、スループットと CPU の使用状況を可視化します。
- Dataflow モニタリング インターフェースを使用して、パフォーマンス、実行、健全性に関連するパイプラインの指標を確認します。
リソースを最適化する
Dataflow リソースの最適化に役立つ最適化案は次のとおりです。
- ビッグデータを効率的に処理する場合は、Dataflow Prime を使用します。
- 自動スケーリングされるバッチ パイプラインに Flexible Resource Scheduling（FlexRS）を使用することで、バッチ処理費用を削減できます。FlexRS は、高度なスケジューリング、Dataflow シャッフル、プリエンプティブル VM と通常の VM の組み合わせを使用して、バッチ パイプラインのコストを削減します。
- Persistent Disk やワーカーノードの代わりにメモリ内シャッフル サービスを使用して、パフォーマンスを向上させます。
- レスポンスに優れた自動スケーリングのために、リソース使用量を減らすには、Streaming Engine を使用して、パイプラインの実行をワーカー VM から Dataflow サービスのバックエンドに移動します。
- パイプラインとインターネットや他の Google Cloud ネットワーク間のアクセスが不要な場合は、パブリック IP アドレスを無効にします。インターネット アクセスを無効にすると、ネットワーク コストを削減し、パイプラインのセキュリティを強化できます。
- Dataflow による効率的なパイプライン化のベスト プラクティスを適用します。
Dataproc
Dataproc は、バッチ処理、クエリ、ストリーミング、ML 用のマネージド Apache Spark / Apache Hadoop サービスです。
Dataproc リソースのコストを最適化するための最適化案を以下に示します。
- ワークロードに適したマシンタイプを選択します。
- 自動スケーリング クラスタを使用して需要に応じて自動的にスケーリングし、必要なリソースに対してのみ支払います。
- ジョブが完了したときにクラスタを削除できる場合は、マネージド クラスタ ワークフロー テンプレートを使用するエフェメラル クラスタのプロビジョニングを検討してください。
- 非アクティブなクラスタに対して料金が発生しないようにするには、スケジュール設定された削除を使用します。これにより、指定したアイドル時間の後、指定した日時、または指定した期間が経過した後にクラスタを削除できます。
- Dataproc での長時間実行クラスタの構築のベスト プラクティスを適用します。
- 常時稼働ワークロードについては、確約利用割引を購入します。
次のステップ
- コンピューティング サービス、ストレージ、ネットワーキング、運用の費用を最適化する。
- Google Cloud アーキテクチャ フレームワークの他のカテゴリを確認する