マルチデータセンター（またはマルチDC）セットアップの主な目標は、データベースエコシステムがSQL（PostgreSQL、MySQL）であるか、NoSQL（MongoDB、Cassandra）であるかに関係なく、エンドユーザーの低レイテンシです。高可用性とディザスタリカバリ。このような環境の中心には、耐久性を保証する方法でデータを複製する機能があります（補足として、Cassandraの耐久性構成パラメーターはPostgreSQLで使用されるものと同様です）。さまざまなレプリケーション要件については以下で説明しますが、極端なケースについては、さらに調査する必要があります。
非同期ログ配布を使用したレプリケーションはPostgreSQLで長い間利用可能であり、バージョン9.1で導入された同期レプリケーションは、PostgreSQL管理ツールの開発者にまったく新しいオプションのセットを開きました。
考慮事項
PostgreSQLマルチDC実装の複雑さを理解する1つの方法は、PostgreSQLがACIDに準拠することを主張していることを念頭に置きながら、他のデータベースシステムに実装されているソリューションから学ぶことです。
マルチDCセットアップには、ほとんどの場合、クラウド内に少なくとも1つのデータセンターが含まれます。クラウドプロバイダーは、クライアントに代わってデータベースレプリケーションを管理する責任を負いますが、通常、専用の管理ツールで利用できる機能とは一致しません。たとえば、ハイブリッドクラウドやマルチクラウドソリューションを採用している多くの企業では、既存のオンプレミスインフラストラクチャに加えて、マルチDCツールでこのような混合環境を処理できる必要があります。
さらに、フェイルオーバー中のダウンタイムを最小限に抑えるために、PostgreSQL管理システムは（API呼び出しを介して）DNS更新を要求できる必要があります。これにより、データベース要求は新しいマスタークラスターにルーティングされます。
地理的に広いエリアにまたがるネットワークは待ち時間の長い接続であり、すべてのソリューションが妥協する必要があります。同期レプリケーションを忘れて、1つのプライマリと多くのリードレプリカを使用します。レプリケーションに対するネットワーク効果の詳細な分析については、AWSMongoDBおよびSeverenines/GaleraClusterの調査を参照してください。関連するメモとして、ロケーション間の遅延をテストするための優れたツールは、Wonder NetworkPingStatisticsです。
WANの高遅延の性質を変更することはできませんが、ユーザーの場所に近いリードレプリカから読み取りを確実に提供することで、ユーザーエクスペリエンスを劇的に向上させることができますが、いくつかの注意点があります。レプリカをプライマリから移動することにより、書き込みが遅延するため、同期レプリケーションを廃止する必要があります。このソリューションは、書き込み後の読み取りの整合性や接続損失による古いセカンダリ読み取りなどの他の問題も回避できる必要があります。
RTOを最小限に抑えるには、高い読み取りスループットも提供できる耐久性のあるストレージにデータを複製する必要があります。CitusDataによると、これらの要件を満たす1つのオプションはAWSS3です。
複数のデータセンターという概念は、データベース管理システムがDBAにすべてのデータセンターとその中のさまざまなPostgreSQLクラスターのグローバルビューを提示し、複数のバージョンのPostgreSQLを管理し、それらの間のレプリケーションを構成できる必要があることを意味します。
地域のデータセンターへの書き込みを複製する場合は、伝播遅延を監視する必要があります。遅延がしきい値を超えると、レプリカに古いデータが含まれていることを示すアラームがトリガーされます。同じ原則が非同期マルチマスターレプリケーションにも当てはまります。
同期セットアップでは、待ち時間が長くなるか、ネットワークが中断すると、コミットが完了するのを待っている間にクライアントリクエストの処理が遅れる可能性がありますが、非同期構成では、スプリットブレインや長期間にわたるパフォーマンスの低下のリスクがあります。記事「Galeraを使用した地理分散データベースクラスター」で説明されているように、十分に確立されたレプリケーションソリューションを使用しても、スプリットブレインと同期コミットの遅延は避けられません。
もう1つの考慮事項は、ベンダーのサポートです。この記事の執筆時点では、AWSはPostgreSQLのクロスリージョンレプリカをサポートしていません。
インテリジェントな管理システムは、データセンター間のネットワーク遅延を監視し、変更を推奨または調整する必要があります。同期レプリケーションは、データセンターがファイバーネットワークを使用して接続されているAWSアベイラビリティーゾーン間で完全に正常です。このようにして、ソリューションはデータ損失をゼロにすることができ、負荷分散とともにマスターマスターレプリケーションを実装することもできます。 AWS Aurora PostgreSQLは現在、マスターマスターレプリケーションオプションを提供していないことに注意してください。
レプリケーションのレベルを決定します：クラスター、データベース、テーブル。決定基準には、帯域幅のコストを含める必要があります。
地理的な距離が原因でレプリカがマスターから更新を受信できないようにするネットワークの中断を回避するために、カスケードレプリケーションを実装します。
ソリューション
すべての要件を考慮して、仕事に最適な製品を特定します。ただし、注意が必要です。各ソリューションには独自の警告があり、製品ドキュメントの推奨事項に従って対処する必要があります。たとえば、BDR監視要件を参照してください。
PostgreSQLの公式ドキュメントには、非商用のオープンソースアプリケーションのリストが含まれています。商用のクローズドソースソリューションを含む拡張リストは、レプリケーション、クラスタリング、および接続プールのwikiページにあります。これらのツールのいくつかは、PostgreSQL用のトップPGクラスタリングHAソリューションの記事で詳細に確認されています。
ターンキーソリューションはありませんが、一部の製品は、特にベンダーと協力している場合に、ほとんどの機能を提供できます。
網羅的ではないリストは次のとおりです：
- Citus Dataは、独自のPostgreSQLビルドを提供し、印象的なエンタープライズ機能とAWSとの緊密な統合で強化されています。
- EnterpriseDBは、ほとんどの要件を満たすために組み合わせることができるサービスの大規模なスイートを提供します。ほとんどの情報は製品ドキュメントにあります。
- Postgres-BDRは、地理的に分散したクラスター向けに特別に設計された強力なレプリケーションツールですが、クラウドプロバイダーとは統合されていません。
- ClusterControlには、PostgreSQLを管理するための優れた機能セットが付属しています。また、クラウド統合も制限されています。
- ElephantSQLは多くのクラウドプロバイダーで機能します。ただし、オンプレミス設定のオプションはありません。
- Crunchy PostgreSQL for Kubernetesは、アップストリームPostgreSQL上に構築されたクラウドに依存しない製品です。
結論
これまで見てきたように、PostgreSQLマルチデータセンターソリューションの選択に関しては、万能のソリューションはありません。多くの場合、妥協は必須です。ただし、要件と影響を十分に理解することは、十分な情報に基づいた意思決定を行う上で大いに役立ちます。
静的（読み取り専用）データと比較して、データベースのソリューションでは、更新（書き込み）のレプリケーションを考慮する必要があります。 SQLとNoSQLの両方のレプリケーションソリューションを説明している文献では、スプリットブレインや書き込み後の読み取りの一貫性などの問題を回避するために、多くのレプリカを使用した書き込みに信頼できる唯一の情報源を使用することを主張しています。
最後に、相互運用性は、マルチDCセットアップがオンプレミスにあるデータセンターやさまざまなクラウドプロバイダーにまたがる可能性があることを考慮すると、重要な要件です。