このドキュメントでは、オンライン トランザクション処理（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 ベンチマーク ガイドを使用します。このガイドでは、さまざまな AlloyDB for PostgreSQL 構成のパフォーマンス データを提供します。これにより、TPS 要件を満たす構成を見つけることができます。
- 適切な AlloyDB for PostgreSQL のサイズを選択します。現在のデータサイズと将来の増加の見込みを考慮します。
マシンサイズのガイドライン
次の表の例は、読み取りと書き込みの比率が約 65%（読み取り）対 35%（書き込み）である TPC-C ベンチマークのデータに関する推奨事項を示しています。AlloyDB for PostgreSQL インスタンスのサイズを設定する場合は、オペレーティング システムのスケジューリングのオーバーヘッドを回避するために、安定状態の CPU 使用率を 60～70% にする必要があります。これにより、クライアント アプリケーションによるリソース使用量の急増に対応できる余裕が生まれます。
| vCPU / メモリ | 推奨されるトランザクション/秒 範囲（30% キャッシュに保存） |
推奨されるワーキング データサイズ （合計サイズは最大 128 TB） |
推奨される max_connections |
|---|---|---|---|
| 2 / 16 GB | 最大 1,000 | 最大 100 GB | 1000 |
| 4 / 32 GB | 最大 2,500 | 最大 250 GB | 2000 |
| 8 / 64 GB | 最大 4,000 | 最大 500 GB | 4000 |
| 16 / 128 GB | 最大 8,000 | 最大 1 TB | 5000 |
| 32 / 256 GB | 最大 14,000 | 最大 3 TB | 5000 |
| 64 / 512 GB | 最大 20,000 | 最大 8 TB | 5000 |
| 96 / 768 GB | 最大 25,000 | 最大 16 TB | 5000 |
| 128 / 864 GB | 20,000 超 | 最大 32 TB | 5000 |
デプロイタイプ
ワークロードに応じて、AlloyDB for PostgreSQL をプライマリ インスタンスのみとして、またはプライマリと読み取りプール インスタンスとしてデプロイできます。
プライマリのみ
次のワークロードには、プライマリのみのデプロイを選択します。
- 書き込みが中心で読み取りが少ない
- 読み取りが多いクエリで書き込みが少ない
- 一般的な OLTP 読み取り / 書き込み（読み取り 60～70%、書き込み 30～40%）。
マシンタイプの詳細については、一般的なマシンサイズのガイドラインをご覧ください。
読み取りプール インスタンスを使用するプライマリ
読み取りプール インスタンスを含むプライマリをデプロイする場合は、次の点を考慮してください。
- レイテンシに敏感な読み取りがある場合は、読み取りクエリを読み取りプール インスタンスにオフロードすることを検討してください。このインスタンスでは、標準 PostgreSQL と比較してレプリカラグが 25 分の 1 に抑えられます。すべての読み取りプール インスタンスに最大 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 ベンチマーク ガイド。