RDS for PostgreSQLで時間をかけてmax_wal_sizeやチェックポイント周りを詰めた設定を、そのままAurora PostgreSQLへ持ち込んでも期待した効果が出ません。レプリカ遅延の監視も同じで、ReplicaLagのしきい値をAuroraに流用するとアラートが機能しなくなります。SQLの書き方もMVCCもEXPLAINの読み方も変わらないのに、チューニングと監視だけが通用しない。この食い違いは、両者がページとWALをどこに置いてどう複製するかというレイヤーで別物だという点から説明できます。
この記事は「Aurora/RDS PostgreSQLの違いと性能差の原因」の一部を、話題を絞って書き直したものです。移行後に遅いときの症状別の切り分け手順や、I/O課金・バックアップ・拡張機能といったコスト面の違いは、ブログの完全版にまとめています: Aurora/RDS PostgreSQLの違いと性能差の原因
共通する部分と、違う部分の境界
SQL方言、MVCCとVACUUMの仕組み、オプティマイザ、ロックの種類、拡張機能の多くはAuroraとRDSで共通です。pg_stat_statementsやEXPLAINも同じ知識で読めます。差が出るのはストレージ層とレプリケーション方式に限られます。この境界を意識すると、移行後のトラブルがどちら側の問題かを判断しやすくなります。
ストレージとWALの扱い
RDS for PostgreSQLは、EBSボリューム（gp3 / io1 / io2など）を1インスタンスに紐付けた構成です。コミット時はWALをローカルのWAL領域にfsyncし、ダーティページはチェックポイントとバックグラウンドライタがデータファイルへ書き出します。Multi-AZの単一スタンバイ構成ではストレージをブロックレベルで同期ミラーするため、コミットのレイテンシにAZ間の往復が加算されます。ページ破損対策としてfull_page_writesが有効なので、チェックポイント直後はWAL量が増えます。
Aurora PostgreSQLのインスタンスはデータファイルを直接書きません。コミット時にredoレコードを3つのAZに分散した共有ストレージへ送り、書き込みクォーラムが成立した時点でコミットが完了します。ページは各ストレージノードがredoを適用して作ります。この構造から、チェックポイントによるダーティバッファの一括フラッシュが性能に与える影響は小さくなります。ページ全体の二重書きも構造的に不要になり、ネットワークへ流す量が減ります。結果としてmax_wal_sizeやcheckpoint_completion_target系のチューニングは、RDSと同じ意味を持ちません。移行前のWAL調整が効果を発揮しない理由はここにあります。該当パラメータを変更できるかどうかは、自分のDBクラスターパラメータグループでIsModifiableを確認してください。
レプリカ遅延は単位も意味も違う
RDSのリードレプリカは、プライマリからWALを受け取って自分のストレージに適用する物理ストリーミングレプリケーションです。遅延はReplicaLag（秒）で確認できます。主因はrecoveryプロセスによる単一スレッドのWAL適用と、レプリカ側のI/Oです。更新の重いバッチ中に数十秒から分単位まで遅れることは、この構造では珍しくありません。
Auroraのリーダーはライターと同じストレージボリュームを読みます。WALをストレージに書く作業がないため、ライターから届いたredo情報で自分のバッファキャッシュを更新・無効化するだけで済み、遅延は通常ミリ秒オーダーです。メトリクスはAuroraReplicaLag（ミリ秒）で、単位も意味もRDSと異なります。それでもゼロではありません。ライターの更新スループットが高いとき、リーダーのCPUが飽和しているとき、リーダー側で長時間クエリが走っているときに伸びます。
外部スタンバイとフェイルオーバーの前提
Auroraでは外部に自前の物理スタンバイを立てられません。pg_basebackupと物理スロットを組み合わせた構成は取れないため、クラスター外へデータを流すなら論理レプリケーションかDMSを使います。論理スロットは両者で使えますが、スロットを放置するとWALが溜まってストレージを圧迫する点は共通の注意事項です。
フェイルオーバーについては、Auroraがストレージを共有しているためリーダーの昇格が主な作業になり、一般にRDS Multi-AZより短時間で完了します。ただし体感時間は、接続がどのエンドポイントを掴んでいるか、アプリ側のDNSキャッシュTTL、コネクションプールの再接続設計で変わります。切り替え時間は自分のアプリ構成で検証してください。
元記事で扱っている内容
- 挙動差の原因をストレージ層・レプリケーション方式・パラメータ既定値の3点に整理した結論部分
- 移行後に「遅い・おかしい」と言われたときの、症状から原因へたどる切り分け手順
- I/O課金、バックアップ、拡張機能など、コストと運用で見落としやすい違い
- Aurora移行の選定時に確認するチェックポイントと、学習を続けるための指針
- Aurora・RDS間の違いについて実務で質問が集まる論点のよくある質問