AnalyticDB for PostgreSQL パフォーマンス専有型エディションは、シングルレプリカアーキテクチャを採用しており、ストレージコストを削減するとともに、高可用性エディション（High-availability Edition）よりも高い書き込み I/O パフォーマンスを実現します。このエディションは、最大稼働時間（uptime）よりもコスト効率および書き込みスループットが重視される分析ワークロードに適しています。
パフォーマンス専有型エディションは、ほとんどのビジネス分析シナリオに適しています。一方、最高レベルの可用性が必須となるコア業務要件には、高可用性エディションをご利用ください。
パフォーマンス専有型エディションの適用タイミング
| 評価基準 | ハイパフォーマンスエディション | 高可用性エディション |
|---|---|---|
| アーキテクチャ | シングルレプリカ | デュアルレプリカ（プライマリ＋スタンバイ） |
| ストレージコスト | 低コスト（同一仕様比で 50% 削減） | 上位 |
| 書き込み I/O パフォーマンス | 高性能（レプリケーションオーバーヘッドなし） | 下位 |
| SQL クラッシュからの復旧 | 約 10 秒 | 5～10 分 |
| コンピュートノード障害からの復旧 | 再起動が必要。自動フェイルオーバーなし | 自動フェイルオーバーあり。サービス中断なし |
| ホスト障害からの復旧 | ホスト移行後の再起動が必要。約 15 分 | 自動フェイルオーバーあり。移行処理はバックグラウンドで実行 |
| 推奨ユースケース | 分析処理、バッチ処理、コストに敏感なワークロード | ミッションクリティカルな本番 OLAP |
ハードウェア障害発生時に数分～数時間の復旧ウィンドウを許容できるワークロードには、パフォーマンス専有型エディションを選択してください。一方、ハードウェア障害時にも継続的な可用性が求められるワークロードには、高可用性エディションをご利用ください。
アーキテクチャ
パフォーマンス専有型エディションでは、コーディネーターノードおよびコンピュートノードの両方をシングルレプリカアーキテクチャでデプロイします（以下参照）。
図 1. パフォーマンス専有型エディションのアーキテクチャ
高可用性エディションでは、スタンバイコーディネーターノードおよびセカンダリコンピュートノードが含まれます。
図 2. 高可用性エディションのアーキテクチャ
スタンバイコーディネーターノードおよびセカンダリコンピュートノードを省略することにより、以下の 3 つの直接的な効果があります：
スタンバイコーディネーターノード向けのストレージ領域が割り当てられません。
コンピュートノードのストレージ容量が 50% 削減されます。
プライマリおよびセカンダリコンピュートノード間のデータ同期が不要となり、書き込み I/O パフォーマンスが向上します。
コスト削減
同一仕様のインスタンスにおいて、パフォーマンス専有型エディションはレプリカ数が 1 つであるため、高可用性エディションより低コストです。
下表は、一般的な 2 つの仕様レベルにおける両エディションの月額料金（米ドル）を示しています。
| 仕様 | HPE ストレージ（USD/月） | HAE ストレージ（USD/月） | ストレージの削減 | HPE コンピュート（USD/月） | HAE コンピュート（USD/月） | コンピュート削減率 | HPE 合計（USD/月） | HAE 合計（USD/月） | 合計削減量 |
|---|---|---|---|---|---|---|---|---|---|
| エントリーレベル | 22.4 | 100 | 77.6% | 175.55 | 352.05 | 50.13% | 197.95 | 452.05 | 56.21% |
| 一般 | 89.6 | 200 | 55.2% | 668.65 | 700.28 | 4.52% | 758.25 | 900.28 | 15.78% |
エントリーレベル仕様： パフォーマンス専有型エディション（HPE）は、2 CPU コア、50 GB ストレージ、2 コンピュートノードを採用します。高可用性エディション（HAE）は、2 CPU コア、50 GB ストレージ、4 コンピュートノードを採用します。この仕様では、HPE のコストは HAE より 56% 安価です。
共通の仕様：両方のエディションで、4 CPU コア、100 GB ストレージ、および4つのコンピュートノードを使用します。これらの仕様では、HPE の方が 15% 安価です。
最新の料金情報については、「AnalyticDB for PostgreSQL の料金」をご参照ください。
パフォーマンス
パフォーマンス専有型エディションは、プライマリおよびセカンダリコンピュートノード間のデータ同期およびストリーミングレプリケーションを排除することで、より高い I/O パフォーマンスを実現します。2 CPU コアのインスタンスでは、I/O パフォーマンスが同等の高可用性エディションインスタンスの最大 250% に達します。書き込み負荷の高いワークロードでは、約 100% のパフォーマンス向上が確認されています。
以下のベンチマークは、2 CPU コア、400 GB ストレージ、4 コンピュートノードという同一構成で両エディションを比較した結果です。
ローカルレプリケーション
約 90 GB のデータを含む行指向テーブルのレプリケーション：
CREATE TABLE lineitem2 AS (SELECT * FROM lineitem);| エディション | 実行時間 |
|---|---|
| 高性能エディション | 249 秒 |
| 高可用性エディション | 1,307 秒 |
パフォーマンス専有型エディションは、この操作を約 5 倍の高速度で完了しました。INSERT INTO SELECT 操作でも同程度の改善が見られます。
TPC-H ベンチマーク
本テストは TPC-H ベンチマーク手法に基づいて実施されていますが、すべての TPC-H 要件を満たすものではありません。公開済みの TPC-H 結果との比較はできません。
100 GB の TPC-H データセットに対して 22 の SQL クエリを実行しました。結果を以下に示します。
パフォーマンス専有型エディションは、全クエリセットの実行を高可用性エディションより 40% 速く完了しました。これは、レプリケーションオーバーヘッドを排除したことによる I/O 利点を反映しています。
可用性
データ信頼性
AnalyticDB for PostgreSQL は、強化型 SSD（ESSD）上にデータを保存します。ESSD はストレージレイヤーで複数の内部レプリカを活用するため、シングルレプリカモードであっても高いデータ信頼性および整合性を確保します。コンピュートノード障害発生時にもデータ損失は発生しません。
障害シナリオと復旧動作
パフォーマンス専有型エディションは、スタンバイノードが存在しないため、高可用性エディションより可用性が低くなります。下表は、代表的な障害シナリオにおける復旧動作をまとめたものです。
| 障害シナリオ | 高性能エディション | 高可用性エディション |
|---|---|---|
| SQL クラッシュ（コアダンプ、メモリ不足（OOM）） | 約 10 秒（最適化されたチェックポイント） | 5～10 分 |
| コンピュートノード障害 | 再起動が必要。再起動完了までサービス不可 | 自動フェイルオーバーあり。セカンダリノードが即座に引き継ぎ、サービス中断なし |
| ホスト障害 | ホスト移行後の再起動が必要。約 15 分 | 自動フェイルオーバーあり。ホスト移行はバックグラウンドで実行 |
物理マシン障害の場合、極端なケースでは最大 8 時間の復旧時間がかかることがあります。
復旧モードの動作原理
AnalyticDB for PostgreSQL におけるほとんどの障害（コアダンプや OOM エラーなどによる SQL クラッシュを含む）は、完全なノード障害ではなく「復旧モード」をトリガーします。復旧モード中、インスタンスは以下の処理を行います：
残存するロックおよびメモリを解放します。
コミット済みだがディスクに書き込まれていないトランザクションを復元するために、Write-Ahead Log（WAL）ファイルを再生します。
サービスを再開します。
パフォーマンス専有型エディションでは、WAL データの再生量を削減する最適化されたチェックポイント機構を採用しているため、これらの一般的な障害シナリオからの復旧時間は約 10 秒となります。これに対し、高可用性エディションでは 5～10 分かかります。
WAL およびチェックポイント
Write-Ahead Log（WAL）： トランザクションコミット前に、各トランザクションによるすべてのデータ変更を記録します。WAL を活用することで、コミット済みだがまだディスクにフラッシュされていない変更を再生できます。
チェックポイント： すべてのデータ変更がディスク上に確実に反映された時点を指します。データベースは、最も直近のチェックポイントから復旧を開始します。AnalyticDB for PostgreSQL では、定期的なスケジュールに加え、WAL ファイルサイズがしきい値に達した際にもチェックポイントが自動的に実行されます。
コンピュートノード障害
高可用性エディションでは、コンピュートノード障害発生時にセカンダリコンピュートノードが自動的に引き継ぎ、障害ノードはバックグラウンドで再起動され、サービス中断は発生しません。
パフォーマンス専有型エディションでは、引き継ぎ可能なセカンダリノードが存在しないため、インスタンスは一時的に利用不可となり、復旧には手動での再起動が必要です。
ホスト障害
ホスト障害は、両エディションともに自動ホスト移行をトリガーします。高可用性エディションでは、スタンバイノードがサービス継続性を維持しながら、ホスト移行がバックグラウンドで実行されます。パフォーマンス専有型エディションでは、ホスト移行完了後にインスタンスを再起動する必要があります。このプロセスには約 15 分かかります。
よくある質問
パフォーマンス専有型エディションから高可用性エディションへアップグレードできますか？
直接のインプレースアップグレードはサポートされていません。両エディションはレプリカ数およびストレージ構成が異なるため、自動移行パスは提供されていません。エディションを切り替えるには、まずパフォーマンス専有型エディションのインスタンスからデータをバックアップし、次に高可用性エディションのインスタンスを購入して、そのインスタンスにデータを復元してください。移行手順については、「AnalyticDB for PostgreSQL インスタンス間でのデータ移行」をご参照ください。