はじめに

こんにちは！NTTテクノクロスで PostgreSQL やクラウド基盤の技術支援をやっています、中村です。

突然ですが、ＤＲという言葉に聞きなじみはありますでしょうか？
ＤＲはディザスタリカバリ、「災害からの復旧」を意味します。

データベースには高可用構成という考え方があり、障害が発生しても、サービスを止めない（可用性を高くする）ためのしくみが用意されています。

ＤＲも高可用構成の延長ととらえることができます。

■最初に運用を開始するリージョンをメインサイトとした場合、
・メインサイト（リージョン）内での障害耐性を持たせるための構成として、ＡＺ（アベイラビリティゾーン）があり
・メインサイト（リージョン）内のすべてのＡＺが障害になった場合のバックアップがＤＲ（ディザスタリカバリ）サイト
といった具合です。

おそらく、ほとんどのシステムの構築の際に、ＡＺやＤＲについて検討されていると思います。

PostgreSQLのレプリケーション構成のパターン

まずはサイト内（同一リージョン内）で取りうることのできる構成を確認しましょう。

表中では、以下の略称を用います。
SR：ストリーミングレプリケーション
LR：論理レプリケーション

Azure(Flex)：Azure Database for PostgreSQL Flexible Server
AWS(RDS)：Amazon RDS for PostgreSQL
AWS(Aurora)：Amazon Aurora with PostgreSQL Compatibility

※１：クラウド環境での非同期レプリケーションは、リードレプリカを作成することで実現可能です。
※２：クラウド環境での論理レプリケーションは、個別に作成した２つのインスタンス間を想定しています。

ＤＲの構成パターン

ＤＲ構成を作成する目的は、「マスタサイトが使えない場合でも、サービスを継続したい」ということになります。

まずは、オンプレおよび各クラウド構成でどのようなＤＲ構成が可能かを確認し、そのあとで、 自社が提供しているサービスを継続するために必要な条件は何か、を当てはめていくと、適しているＤＲ構成が選択できると思います。

条件として一般的なものは、ＲＰＯとＲＴＯです。
　ＲＰＯ：データの損失をどの程度許容するか？
　ＲＴＯ：サービス再開までに必要な時間をどの程度許容するか？
これらの組み合わせも踏まえて、最適なＤＲ構成を選択するとよいでしょう。

■上記の構成でＲＰＯを低い（データの損失が少ない）順に並べると、以下となります。
　（データ損失が少ない）No.2 ＝ No.4 ＜ No.1 ＝ No.3 ＜ No.5 = No.6（データ損失が大きい）

さらに、No.1 と No.3 の中では、Aurora のグローバルデータベースが、非同期ながらもほぼデータ損失が発生しないため、
　AWS(Aurora) ＜ その他（オンプレ、Azure(Flex)、AWS（RDS) ）
の順となる点を押さえておくとよいですね。


■上記の構成でＲＴＯを短い（復旧までの時間が速い）順に並べると、以下となります。
　（復旧が速い）No.4 ＞ No.2 ＞ No.3 ＞ No.1 ＞ No.5 = No.6（復旧が遅い）

この順序は、ＤＲサイト側で同期SR構成(マルチAZ)になるまでの時間を想定していますので、もともとAZ構成となっている No.4 と No.3 の構成がやや有利になると判断しています。

※１：マスタサイトは「SR（同期(マルチAZ)）」としていますが、単体PostgreSQLでも、SR（非同期(リードレプリカ)）でも、LR（非同期）でも構成可能です。

（Geoレ）：Azure Database for PostgreSQL Flexible Server では Geoレプリケーション（読み取りレプリカ）が構成可能です。
https://learn.microsoft.com/ja-jp/azure/postgresql/read-replica/concepts-read-replicas-geo?source=recommendations
※ Geoレプリケーション構成では、ＤＲ側でマルチAZ構成にすることができません。

（クロス）：Amazon RDS for PostgreSQL ではクロスリージョンレプリカが構成可能です。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Xregion.html
※ Amazon Aurora PostgreSQL ではクロスリージョンレプリカは使用できません。

（グロ）：Amazon Aurora PostgreSQL ではグローバルデータベースが構成可能です。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

No.1 マスタサイトとＤＲサイト間を非同期レプリケーション

今回比較したすべての環境で利用可能な構成です。
ＤＲサイト側には非同期ストリーミングレプリケーションで読み取り専用のスタンバイ（リードレプリカ）を作成しておき、マスタサイトの障害発生時にリードレプリカをプライマリに昇格させます。

非同期レプリケーションのため、データの損失が発生します。ここでいうデータの損失とは、マスタサイトでアプリケーションがコミットしたはずのデータが失われるということです。 データベース側ではどうしようもできないため、データの整合性のためにアプリケーションレベルでの対応（例えば再実行するなど）が必要になります。

この構成では、昇格後にHA（高可用化）を有効にし、SR（同期）構成にします。

No.2 マスタサイトとＤＲサイト間を同期レプリケーション

マスタサイトが被災してもデータ損失なくＤＲサイトに引き継ぎたい場合に利用する構成です。 ただし、遠隔地への同期レプリケーションは通常運用時のマスタサイトのレスポンス時間に影響を与えるため、実際に実運用に耐えうるかの十分な確認が必要になります。

また、この構成はクラウド環境では利用できません。

No.3 マスタサイトとＤＲサイト間を非同期レプリケーションし、ＤＲサイト側もマルチAZ構成とする

No.1のバリエーション構成です。 最初からＤＲサイト側でもマルチAZ構成としておくことで、No.1の構成に比べて手順が一つ減り、SR（同期）構成にするまでの時間短縮が見込めます。
ＤＲサイト側がSR（同期）構成でなくてもサービスを再開できるのであれば No.1の構成でよいですし、ＤＲサイト側がSR（同期）構成になるまでサービスを再開しない業務要件なのであれば No.3の構成にする、という判断になります。

No.3の構成の場合、通常時から2台分の料金が発生するため、コストが高く点に注意が必要です。

■ Amazon RDS アーキテクチャ概要 P20 の構成が参考になります。
https://pages.awscloud.com/rs/112-TZM-766/images/01_RDS_Architecture.pdf

No.4 マスタサイトとＤＲサイト間を同期レプリケーションし、ＤＲサイト側もマルチAZ構成とする

No.2のバリエーション構成です。 最初からＤＲサイト側を非同期レプリケーション構成（カスケードレプリケーション）としておくことで、No.2の構成と比べ、SR構成にするまでの手順が一つ減り、かつSR（同期）構成にするまでの時間短縮が見込めます。

No.2同様、この構成はクラウド環境では利用できないことと、通常使用時のマスタサイトのレスポンス時間が大きく増加する可能性が高い点に留意が必要です。

No.5、No.6 マスタサイトで取得したバックアップをＤＲサイトにコピーし、PITRする

■Azure はGeoバックアップが利用可能です。
Geoバックアップでは、自動的にＤＲサイト側にバックアップがコピーされます。

Azure では、このバックアップを使用してのPITRの時間指定ができません。一番新しいバックアップを使用して、可能な限りの最新状態に復元します。

■RDS は自動バックアップレプリケーション（クロスリージョン自動バックアップ）が利用可能です。
スナップショットと更新ログを定期的にコピーします。

RDS は自動バックアップレプリケーションを用いての、PITRの時間指定が可能です。
https://docs.aws.amazon.com/jajp/AmazonRDS/latest/UserGuide/USERReplicateBackups.html

■Aurora はバックアップ（スナップショット）を別リージョンにコピーして、復元に利用することができます。
Aurora はスナップショットのフルコピーとなるとの記述から、PITRでの時間指定はできないと考えます。

以下はAuroraのバックアップに関する参考情報です。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backups.html

https://repost.aws/de/questions/QU7EYE7ejBQlyVuC5O5igIKg/auroraを-aws-backup-でバックアップを取得する際の設定項目

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_CopyDBClusterSnapshot.CrossRegion.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-pitr.html

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-copy-snapshot.html

https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html

まとめ

今回はわかりやすいように表で整理してみました。
構成は同じでも、各製品ごとにできること、できないことが異なるため、自システムに導入する目的と合致しているか特徴をつかんでおくことが重要ですね。

オンプレとすべてのクラウド環境で、マスタサイト上では PITRで時間指定の復元ができますが、 ＤＲサイト上では時間指定での PITRができない場合がある、といった違いは障害復旧の観点で大きく変わってくると思います。

それでは、本記事は以上となります。
ここまでお付き合い頂き、ありがとうございました！

PostgreSQLのことならNTTテクノクロスにおまかせください！

NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせや、移行に関する対応を受け付けています。
オンプレだけではなく、Azure、AWSなどのクラウド上でのシステムの導入、開発、維持管理のご相談もお待ちしております。

PostgreSQL の定額制チケットサービスはこちら

PostgreSQLへの移行サービスはこちら