読み取りレプリカ
読み取りレプリカを使用すると、プライマリ Managed Postgres データベースのコピーを 1 つ以上作成できます。これらのレプリカは、PostgreSQL のネイティブなレプリケーション機能を使用してプライマリデータベースを継続的に追随し、変更を常に最新の状態に保ちます。
読み取りレプリカを管理するには、ウェアハウスの編集アイコンをクリックします：
これによりウェアハウスダイアログが開き、既存のサービスを表示したり、新しい読み取りレプリカを作成したりできます：
読み取りレプリカを使用する理由
スケーラビリティ
リードレプリカを利用すると、読み取り負荷の高いワークロードを複数の専用インスタンスに分散させることで、データベースを水平方向にスケールアウトできます。これは、レポーティングクエリ、分析処理、リアルタイムダッシュボードなど、本番トラフィックと同じリソースを奪い合いがちなユースケースに対して、特に有用です。
分離
分析系およびビジネスインテリジェンス系のクエリを読み取り専用のレプリカに向けることで、プライマリインスタンスは書き込み処理と重要なトランザクションワークロードに専念でき、高い応答性を維持できます。この分離によって、システム全体のパフォーマンスと予測可能性が向上します。また、分析やレポーティングツールに対して書き込み権限を付与する必要もなくなります。これらのツールは、誤ってデータを変更してしまうリスクなしに、レプリカに対して安全に動作させることができます。
ビジネス継続性
リードレプリカは、災害復旧において重要な役割を果たします。プライマリデータベースに障害が発生した場合、リードレプリカをプライマリに昇格させることで、ダウンタイムとデータ損失を最小限に抑えることができます。これにより、高可用性構成に加えて、さらなるレジリエンスの層が追加されます。
読み取りレプリカの仕組み
Managed Postgres の読み取りレプリカは、ストリーミングレプリケーションではなく、WAL シッピング方式のアーキテクチャを採用しています。この設計は、プライマリデータベースへの影響を最小限に抑えることを重視したものです。
オブジェクトストレージからの WAL シッピング
プライマリデータベースがトランザクションを処理する際、Write-Ahead Log (WAL) レコードが生成されます。これらの WAL セグメントは継続的にオブジェクトストレージ (S3) にアーカイブされます。リードレプリカは、プライマリと同期状態を維持するために、オブジェクトストレージからこれらの WAL セグメントを取得してリプレイします。
このアーキテクチャは、プライマリへの直接接続を使ったストリーミングレプリケーションを利用する 高可用性スタンバイ とは異なります。
なぜこのアプローチを選んだのか
私たちは意図的に、read replica がストリーミングスタンバイとしてプライマリに直接接続するのではなく、オブジェクトストレージ上の WAL を取得して適用するように設計しました。このアプローチにより、read replica とプライマリデータベースとの間に完全な分離が実現されます。
- プライマリへのレプリケーションオーバーヘッドがゼロ: read replica はプライマリへのストリーミング接続を維持しないため、ミッションクリティカルなワークロードに対して CPU・メモリ・ネットワークのいずれにも一切負荷を追加しません。
- 独立したスケーリング: read replica を追加または削除しても、プライマリのパフォーマンスには一切影響しません。
- ネットワーク分離: read replica は、個別の接続エンドポイントを備えた専用のネットワーク環境で動作します。
レプリケーションラグの特性
このアーキテクチャのトレードオフは、レプリケーションラグです。WAL セグメントは、プライマリから一定間隔（通常は 60 秒ごと、またはセグメントがいっぱいになった時点のいずれか早い方）でアーカイブされます。これは、通常の運用条件下では、読み取り用レプリカがプライマリから最大で数十秒程度遅延する可能性があることを意味します。
多くの読み取りスケーリング用途（レポート、分析、ダッシュボード）では、このラグは許容範囲です。アプリケーションでほぼリアルタイムな読み取りが必要な場合は、クエリをプライマリに向けられるか、あるいはこの時間幅内での結果整合性で要件を満たせるかを検討してください。
