このドキュメントでは、オンライン トランザクション処理（OLTP）とオンライン分析処理（OLAP）の両方のワークロードで AlloyDB for PostgreSQL インスタンスのサイズを決定するためのワークロードとデプロイに関する推奨事項について説明します。
概要
データベースのパフォーマンスを向上させるため、AlloyDB for PostgreSQL には次の組み込み機能が用意されています。
- 自動的なメモリ管理
- 適応型自動バキューム
- 最適化された組み込みのパフォーマンス設定
- レプリケーション ラグの低減
- スケール オペレーション中のプライマリでのダウンタイムが 1 秒未満、読み取りプール ノードでのダウンタイムがゼロの中断のないメンテナンス
パフォーマンスを重視して AlloyDB for PostgreSQL インスタンスをチューニングするには、次のことを管理する必要があります。
- プライマリ インスタンスと読み取りプール インスタンスのサイズを正しく設定する
- パフォーマンスに影響するフラグの更新
サイズに関する考慮事項
AlloyDB for PostgreSQL インスタンスのサイズを決定する前に、次の点を決定します。
- ワークロードの種類: OLTP、OLAP、HTAP
- パフォーマンスの要件: レイテンシとスループットの要件
- 予想されるデータサイズ: AlloyDB for PostgreSQL に保存するデータのサイズと、アクティブなデータセットのサイズ
- ワークロードの規模: 時間の経過とともにデータサイズが増加する
OLTP ワークロード
AlloyDB for PostgreSQL データベースは、ゾーン インスタンス（単一ノード）または高可用性インスタンス（各ゾーンに 2 つのノード）としてデプロイできます。必要に応じて、地理的に分散されたワークロードや障害復旧（DR）用に、別のリージョンに読み取りプール インスタンスとセカンダリ クラスタを追加することもできます。
AlloyDB for PostgreSQL は、コンピューティングとストレージが分離されたクラウドスケールの分散アーキテクチャを使用してデプロイされます。書き込みは、書き込み先ログ（WAL）ファイルがリージョン ストレージに永続化されるとすぐに確認されます。ブロックの実現化はストレージにオフロードされます。
同様に、マルチティア キャッシュ アーキテクチャでは、データはバッファ キャッシュ、超高速キャッシュ、インテリジェント ストレージ エンジンの間に自動的に配置されます。AlloyDB for PostgreSQL で使用されるこのマルチティア キャッシュ アーキテクチャにより、AlloyDB for PostgreSQL のコンテキストでは、他のデータベース システムと比較する際の 1 秒あたりの入出力オペレーション（IOP）は関連しません。
ただし、1 秒あたりのトランザクション数（TPS）または 1 分あたりのトランザクション数（TPM）を使用すると、AlloyDB for PostgreSQL で処理できるデータ量を理解するための有意な比較を行うことができます。
主なサイズ設定指標は TPS です。必要な AlloyDB for PostgreSQL のサイズを推定する手順は次のとおりです。
- 既存のワークロードを特定します。セルフマネージド PostgreSQL または他の商用データベースから移行する場合は、既存のワークロードの TPS 値がすでにある場合があります。
- クエリを分析する。ワークロードで最も重要なクエリを特定し、そのパフォーマンス要件を決定します。
HammerDBやpgbenchなどのツールを使用します。これらのツールは、AlloyDB for PostgreSQL のベンチマークを実施し、マシンサイズが TPS 要件を満たしているかどうかを判断するのに役立ちます。- AlloyDB for PostgreSQL OLTP ベンチマーク ガイドを使用します。このガイドでは、TPS 要件を満たす構成を見つけるために、さまざまな AlloyDB for PostgreSQL 構成のパフォーマンス データを提供します。
- 適切な AlloyDB for PostgreSQL のサイズを選択します。現在のデータサイズと将来の増加の見込みを考慮します。
マシンサイズのガイドライン
次の表の例は、読み取りと書き込みの比率が約 65% 読み取りと 35% 書き込みの TPC-C ベンチマークを使用するデータの推奨事項を示しています。AlloyDB for PostgreSQL インスタンスのサイズを設定するときは、オペレーティング システムのスケジューリングのオーバーヘッドを回避するために、安定状態の CPU 使用率を 60 ～ 70% にする必要があります。これにより、クライアント アプリケーションによるリソース使用量の急増に対応できる余裕が生まれます。
| vCPU/メモリ | 推奨されるトランザクション/秒 範囲（30% キャッシュに保存） |
推奨されるワーキング データサイズ （合計サイズは最大 128 TB） |
推奨される max_connections |
|---|---|---|---|
| 2 / 16GB | 最大 1,000 | 最大 100 GB | 1000 |
| 4 / 32GB | 最大 2,500 | 最大 250 GB | 2000 |
| 8/ 64GB | 最大 4,000 | 最大 500 GB | 4000 |
| 16 / 128GB | 最大 8,000 | 最大 1 TB | 5000 |
| 32 / 256GB | 最大 14,000 | 最大 3 TB | 5000 |
| 64 / 512GB | 最大 20,000 | 最大 8 TB | 5000 |
| 96 / 768GB | 最大 25,000 | 最大 16 TB | 5000 |
| 128 / 864GB | 20,000 より大きい | 最大 32 TB | 5000 |
デプロイタイプ
ワークロードに応じて、AlloyDB for PostgreSQL をプライマリ インスタンスのみとしてデプロイすることも、読み取りプール インスタンスを含むプライマリとしてデプロイすることもできます。
プライマリのみ
次のワークロードには、プライマリ専用のデプロイを選択します。
- 書き込みが中心で読み取りが低～中程度
- 読み取りが多いクエリで書き込みが少ない
- 一般的な OLTP 読み取り / 書き込み（読み取り 60 ～ 70%、書き込み 30 ～ 40%）。
マシンタイプの詳細については、一般的なマシンサイズのガイドラインをご覧ください。
読み取りプール インスタンスを使用するプライマリ
読み取りプール インスタンスを使用してプライマリをデプロイする場合は、次の点を考慮してください。
- レイテンシに敏感な読み取りがある場合は、読み取りクエリを読み取りプール インスタンスにオフロードすることを検討してください。読み取りプール インスタンスでは、標準の PostgreSQL と比較してレプリカのレイテンシが 25 倍低くなります。すべてのリードプール インスタンスに最大 20 個のノードを構成できます。
- 複数のデータベース（同じインスタンス内の CRM や財務など）がある場合は、複数の読み取りプール インスタンスを構成します。この戦略を使用すると、効果的なキャッシュとクエリのパフォーマンスが向上します。
- プライマリ プール インスタンスと読み取りプール インスタンスのサイズは、要件に応じて異なります。読み取りプール インスタンスのベスト プラクティスについては、AlloyDB のパフォーマンスと可用性を向上させるためのベスト プラクティスをご覧ください。
- 高可用性を確保するため、読み取りプール インスタンスごとに複数のノードを追加します。
- 読み取りクエリのパフォーマンスを向上させるため、特定の読み取りプール インスタンスでカラム型エンジンを選択的に有効にします。これを行うには、プライマリ インスタンスで列エンジンを有効にする必要はありません。
インデックス アドバイザーなどの組み込み機能を使用して、クエリのパフォーマンスを向上させるインデックスを追加することを検討してください。
OLAP ワークロード
OLAP ワークロードの場合、主なサイジング指標はクエリのパフォーマンスです。特に、テーブル全体のスキャンや集計が必要なクエリが対象です。AlloyDB for PostgreSQL には、分析クエリの高速化に役立つ組み込みのカラム型エンジンが含まれています。デフォルトでカラム型エンジンを有効にすると、メモリの 30% が消費され、超高速キャッシュデータが自動的に使用されます。
TPC-H ワークロードを使用して AlloyDB for PostgreSQL で OLAP パフォーマンスを測定する方法については、AlloyDB for PostgreSQL の PostgreSQL OLAP ベンチマーク ガイドをご覧ください。
デプロイタイプ
ワークロードに応じて、AlloyDB for PostgreSQL をプライマリ インスタンスのみとしてデプロイすることも、読み取りプール インスタンスを含むプライマリとしてデプロイすることもできます。
プライマリのみ
プライマリ専用インスタンスをデプロイする場合は、次の点を考慮してください。
- このデプロイは、分析クエリ（HTAP）を使用するトランザクションの両方に使用します。
- カラム型エンジンを有効にして OLAP クエリをサポートします。
- 列データを保存するためのメモリがより多く提供される 16 vCPU 以上のマシンにデプロイすることを検討してください。
読み取りプールありのプライマリ
読み取りプール インスタンスを使用してプライマリをデプロイする場合は、次の点を考慮してください。
- 書き込みが多い場合や、レイテンシに敏感な分析読み取りで低レイテンシが求められる場合は、HA を有効にして読み取りプール インスタンスとともにプライマリ インスタンスをデプロイします。
- 分析クエリを実行する読み取りプール インスタンスでカラム型エンジンを有効にします。
- 複数のデータベース（同じインスタンス内の CRM や財務など）がある場合は、複数の読み取りプール インスタンスを構成します。この戦略を使用すると、効果的なキャッシュとクエリのパフォーマンスが向上します。
- プライマリ プール インスタンスと読み取りプール インスタンスのサイズは、要件に応じて異なります。読み取りプール インスタンスのベスト プラクティスについては、AlloyDB のパフォーマンスと可用性を向上させるためのベスト プラクティスをご覧ください。
- 高可用性を確保するため、読み取りプール インスタンスごとに複数のノードを追加します。
- 読み取りクエリのパフォーマンスを向上させるため、特定の読み取りプール インスタンスでカラム型エンジンを選択的に有効にします。これにより、プライマリ インスタンスで列エンジンを有効にする必要がなくなります。
次のステップ
- パフォーマンスと可用性を向上させるためのベスト プラクティスについて学習する。
- AlloyDB for PostgreSQL の PostgreSQL OLTP ベンチマーク ガイド。
- AlloyDB for PostgreSQL の PostgreSQL OLAP ベンチマーク ガイド。