正解：D
1. 「ホットスタンバイ」による継続的レプリケーション
-
何をするか: オンプレミスの現行データベース（マスター）と、Compute Engine (GCE) 上に構築したPostgreSQLインスタンス（スタンバイ/レプリカ）の間で、ストリーミングレプリケーションを設定します。
-
効果: GCE上のスタンバイインスタンスは、オンプレミスのマスターに加えられたすべての変更（トランザクション）をほぼリアルタイムで受け取り、適用します。これにより、両データベースのデータ同期が継続的に行われます。
-
ダウンタイムの最小化: 移行（カットオーバー）の瞬間までデータの同期が保たれるため、移行ウィンドウで必要な作業は、レプリカをマスターに昇格させることと、アプリケーションの接続先を切り替えることの2つだけになり、ダウンタイムが数秒〜数分に抑えられます。
2. 「PgBouncer」による接続の素早い切り替え
-
PgBouncerの役割: PgBouncerはPostgreSQLの接続プーラーです。アプリケーションとデータベースの間に位置し、アプリケーションの接続要求をデータベースへの実際の接続に仲介します。
-
ダウンタイムの最小化: 移行のカットオーバー時、以下の手順でアプリケーションのダウンタイムを最小化します。
-
PgBouncerを通じて行われている**既存の接続を一時的にドレイン（切断）**させます。
-
GCE上のホットスタンバイを新しいマスターに昇格させます。
-
PgBouncerの設定を、新しいGCEマスターを指すように変更します。
-
アプリケーションは、PgBouncerを介して新しいGCEマスターへの接続を再確立します。
-
-
利点: PgBouncerを使用することで、アプリケーション側の設定（IPアドレスやポートなど）を変更することなく、新しいデータベースインスタンスにトラフィックを迅速に切り替えることができます。これにより、アプリケーションの再デプロイや設定変更に伴う複雑さや時間的コストが削減されます。
まとめ
このDのソリューションは、以下の理由から「最小限のダウンタイム」を実現するための最も適切な技術的アプローチです。
| 要素 | 実現されること | 最小ダウンタイムへの貢献 |
| ホットスタンバイ | 移行直前までデータの継続的同期を保証。 | 移行ウィンドウで大量のデータを転送・適用する時間を不要にする。 |
| PgBouncer | アプリケーションとデータベースの接続層を抽象化。 | 接続の切り替えを迅速かつ中断を最小限にして実行できる。 |
この手法は、マネージドサービス（CのDMSなど）が特定のターゲット（この場合はCompute Engine）をサポートしていない場合に、高可用性やゼロダウンタイム移行を実現するための最も信頼性の高い手動設定のアプローチとなります。
コメント