Q16 — AWS SAA-C03 第2章

第 16/65 問 | ← 第2章

Q81. ある企業が、MySQLデータベースで動作するオンプレミスアプリケーションを運用しています。このアプリケーションをAWSに移行し、アプリケーションの弾力性（elasticity）と可用性（availability）を高めようとしています。現在のアーキテクチャでは、通常の稼働時にデータベースに対して読み取り負荷が非常に高くなっています。また、開発チームは4時間ごとに本番データベースの完全なエクスポートを実行し、そのデータでステージング環境のデータベースを更新しています。このエクスポート期間中、ユーザーは許容できないレベルのアプリケーション遅延を経験しており、手順が完了するまでステージング環境を活用できません。ソリューションアーキテクトは、このアプリケーション遅延問題を解消する代替アーキテクチャを提案する必要があります。さらに、この代替アーキテクチャは、開発チームが遅延なく引き続きステージング環境を利用できるようにする必要があります。これらの要件を満たすソリューションはどれですか？

正解: B. 本番環境にはAmazon Aurora MySQLとMulti-AZ Aurora Replicasを使用します。必要に応じてステージングデータベースを作成するために、データベースのクローン作成（database cloning）機能を活用します。

解説

正解はBです。Amazon Auroraのデータベースクローン機能は、既存のクラスターから新しい独立したクラスターを数分で作成でき、本番データベースへの負荷をほとんど与えず、一貫性のあるスナップショットに基づいてステージング環境を迅速に提供できます。これにより、4時間ごとのmysqldumpによるフルエクスポートによる長時間の遅延や本番負荷増加を回避でき、開発チームは即座にステージング環境を利用可能です。一方、AおよびDはmysqldumpによるエクスポート・リストアを前提としており、依然として本番DBへの負荷と長時間の処理時間が発生します。Cは、Multi-AZのスタンバイインスタンスをステージング用途に再利用することは技術的に不可能であり（スタンバイは自動フェイルオーバー専用で、ユーザーが直接アクセス・操作できません）、また読み取り専用レプリカも本番トラフィックに使用されるため、ステージング用途に転用すると本番パフォーマンスに悪影響を及ぼします。