PaaS デプロイに対する高可用性とディザスター リカバリーのオプションについて説明する
可用性に関して言えば、PaaS は事情が異なります。構成できるのは、Azure に用意されているオプションだけです。
Azure SQL Database と Azure SQL Database Managed Instance という SQL Server ベースのオプションについては、アクティブ geo レプリケーション (Azure SQL Database のみ) と自動フェールオーバー グループ (Azure SQL Database または Azure SQL Database Managed Instance) から選ぶことができます。
Azure Database for MySQL はサービス レベル アグリーメントで 99.99 の可用性が保証されています。つまり、ダウンタイムが発生する可能性はほぼゼロです。 Azure Database for MySQL で、ハードウェア障害など、ノードレベルの問題が発生した場合は、組み込みのフェールオーバー メカニズムが作動します。 MySQL データベースに対するトランザクショナルな変更はすべて、コミットされた時点で同期的にストレージに書き込まれます。 ノードレベルの中断が発生した場合、データベース サーバーは新しいノードを自動的に作成してデータ ストレージをアタッチします。
アプリケーションの観点では、必要な再試行ロジックをコーディングすることが求められます。新しいノードを立ち上げる過程ですべての接続が切断され、実行中のトランザクションがあればすべて失われるためです。 クラウド アプリケーションは一時的な障害に対応した設計が求められることから、このプロセスは、あらゆるクラウド アプリケーションのベスト プラクティスと考えられます。
Azure Database for PostgreSQL の標準的なデプロイ モデルには、MySQL と同様のモデルが使用されます。ただし、Azure PostgreSQL には、Citus と呼ばれるスケールアウト ハイパースケール ソリューションも用意されています。 Citus では、スケールアウトと追加的な高可用性の両方がサーバー グループに提供されます。 有効にした場合、サーバー グループのすべてのノードに対してスタンバイ レプリカが構成され、グループ内のサーバー数が倍増することからコストも大きくなります。 応答しない、完全に機能不全になるなど、元のノードに問題が発生した場合、スタンバイ ノードが処理を引き継ぎます。 データは、PostgreSQL の同期ストリーミング レプリケーションによって同期状態が保たれます。
Azure Database for MySQL の場合と同様、接続は切断されて実行中のトランザクションは失われるため、Azure Database for PostgreSQL を使用するソリューションも、アプリケーションに再試行ロジックを組み込む必要があります。
Azure Database for MySQL と Azure Database for PostgreSQL は、どちらも読み取りレプリカのオプションをサポートします。 つまり、レポートなどのアクティビティにはレプリカを使用することで、プライマリ データベースの処理負荷をオフロードできるということです。 また、読み取りレプリカは別のリージョンに存在するため、可用性も向上します。