Q86 — AWS SAA-C03 第15章

第 86/100 問 | ← 第15章

Q1186. ある会社が、本番アプリケーション向けにAmazon RDS for MySQLのDBインスタンスを使用しています。今後の予定されたメンテナンス期間中に、ソリューションズアーキテクトがこのDBインスタンスに対してメジャーバージョンアップグレードを実行します。アプリケーションは極めて重要であるため、会社はメンテナンス時間を最小限に抑え、万が一問題が発生した場合にはロールバックできるようにしたいと考えています。これらの要件を満たす解決策はどれですか？

正解: C. DBインスタンスの読み取り専用レプリカを作成します。この読み取り専用レプリカのバージョンをアップグレードします。その後、読み取り専用レプリカをプライマリDBインスタンスとして昇格させ、アプリケーションが読み取り専用レプリカのエンドポイントを使用するように設定します。

解説

Amazon RDS for MySQLのDBインスタンスに対するメジャーバージョンアップグレードにおいて、メンテナンス時間を最小限に抑え、アップグレード失敗時にロールバック可能なソリューションとして最も適しているのは、選択肢Cです。すなわち、「DBインスタンスの読み取り専用レプリカを作成し、そのレプリカのバージョンをアップグレードした後、レプリカをプライマリDBインスタンスとして昇格させ、アプリケーションがそのレプリカのエンドポイントを参照するようにする」方法です。 各選択肢の検討： 選択肢A：自動アップグレードを有効化する方法。制限点：メジャーバージョンアップグレードでは通常、一定のダウンタイムが発生し、「ダウンタイムゼロ」は保証されません。また、アップグレード失敗時の組み込みロールバック機構は存在しないため、長時間のダウンタイムやデータ損失のリスクがあります。 選択肢B：新規DBインスタンスを作成し、AWS DMSでデータを移行する方法。制限点：新規インスタンス作成とDMSによるデータ移行には時間がかかり、複雑さが伴います。また、DNSレコードの変更は追加のダウンタイムや誤設定による障害リスクを招く可能性があり、失敗時のロールバックも容易ではありません。 選択肢C：読み取り専用レプリカを作成し、そのレプリカ上でバージョンアップグレードを行い、成功後に昇格させる方法。利点：プライマリDBインスタンスへの影響を一切与えず、安全かつ効率的にメジャーバージョンアップグレードを実施できます。アップグレードが成功すれば、レプリカをプライマリとして昇格させ、アプリケーションを新しいエンドポイントへ切り替えるだけです。万一失敗した場合でも、レプリカを破棄して元のプライマリDBインスタンスを継続利用すればよく、ダウンタイムを最小限に抑え、明確なロールバック手段を確保できます。 選択肢D：読み取り専用レプリカを作成し、アップグレード中の障害時にフェイルオーバーするポリシーを設定してから、プライマリDBインスタンスを直接アップグレードする方法。制限点：フェイルオーバーポリシーは、通常、プライマリDBインスタンスの障害時における高可用性対応のために使用されるものであり、バージョンアップグレードのロールバック用途には不適切です。アップグレード失敗時には、バックアップからの復元など、手動かつ複雑な回復作業が必要となり、ダウンタイムの増大や運用負荷の上昇を招きます。 結論：要件（メンテナンス時間の最小化・アップグレード失敗時のロールバック可能性・アプリケーションの最小限の中断）を最も適切に満たすのは、選択肢Cです。