SOA信頼性とビジネス継続性
ある企業のWebアプリケーションは、ユーザーセッションデータの格納にAmazon ElastiCache for Redis（クラスターモード無効、シングルノード、シングルAZ構成）を使用しています。過去に特定のAZで障害が発生した際、Redisノードが停止してセッションデータを取得できなくなり、アプリケーション全体が利用不能になるインシデントが発生しました。運用チームは以下の要件を満たすアーキテクチャへの移行を検討しています。
- プライマリノードまたはAZ障害時に自動フェイルオーバーが行われること
- フェイルオーバー中のセッションデータ損失を最小化すること
- 運用負荷を最小限に抑えること
最も適切な設定はどれですか？
Aレプリケーショングループを作成し、Multi-AZを有効化・自動フェイルオーバーを有効化した上で、少なくとも1つのリードレプリカを別のAZに配置する
✓ 正解
ElastiCache for Redisのレプリケーショングループ + Multi-AZ有効 + 自動フェイルオーバー有効の組み合わせにより、プライマリノードまたはAZの障害時に数秒〜1分以内でリードレプリカが自動的にプライマリへ昇格します。データはプライマリからレプリカへ非同期でレプリケートされるためセッション損失を最小化でき、DNS切り替えも自動で行われるため追加の運用作業が不要。要件をすべて最小の運用負荷で満たす唯一の構成。
Bクラスターモード（シャーディング）を有効化してデータを複数のシャードに分散し、シャードごとにレプリカを設定することで単一障害点を排除する
クラスターモード（シャーディング）はデータを複数ノードに水平分散するスケールアウトのための機能であり、AZ障害対策が主目的ではありません。また、クラスターモードへの移行にはアプリケーション側でRedisクラスタープロトコル対応クライアントへの変更が必要で、運用負荷が大幅に増します。
CElastiCache Global Datastoreを設定して、別リージョンにセカンダリクラスターを作成し、AZ障害時にセカンダリリージョンへ切り替える
Global Datastoreはクロスリージョンレプリケーション（リージョン全体のDR）のための機能であり、同一リージョン内のAZ障害対策には過剰です。コストも高く、フェイルオーバー時にはアプリケーション側でエンドポイントの切り替えが必要になるケースがあります。
DAmazon EventBridgeとAWS Lambdaを組み合わせ、プライマリノードの障害を検知したら自動的に新しいElastiCacheクラスターを起動するスクリプトを実装する
ElastiCacheには自動フェイルオーバー機能が内蔵されており、EventBridge + Lambdaで新規クラスターを起動する方式ではクラスターの起動に数分かかりRTOが大幅に延びます。また新規クラスターにはセッションデータが存在しないため、要件であるデータ損失の最小化も達成できません。
解説
ElastiCache for Redisのレプリケーショングループ + Multi-AZ有効 + 自動フェイルオーバー有効の組み合わせにより、プライマリノードまたはAZの障害時に数秒〜1分以内でリードレプリカが自動的にプライマリへ昇格します。データはプライマリからレプリカへ非同期でレプリケートされるためセッション損失を最小化でき、DNS切り替えも自動で行われるため追加の運用作業が不要。要件をすべて最小の運用負荷で満たす唯一の構成。
選択肢Bのクラスターモード（シャーディング）はデータを複数ノードに水平分散するスケールアウトのための機能であり、AZ障害対策が主目的ではありません。また、クラスターモードへの移行にはアプリケーション側でRedisクラスタープロトコル対応クライアントへの変更が必要で、運用負荷が大幅に増します。
選択肢CのGlobal Datastoreはクロスリージョンレプリケーション（リージョン全体のDR）のための機能であり、同一リージョン内のAZ障害対策には過剰です。コストも高く、フェイルオーバー時にはアプリケーション側でエンドポイントの切り替えが必要になるケースがあります。
選択肢DのElastiCacheには自動フェイルオーバー機能が内蔵されており、EventBridge + Lambdaで新規クラスターを起動する方式ではクラスターの起動に数分かかりRTOが大幅に延びます。また新規クラスターにはセッションデータが存在しないため、要件であるデータ損失の最小化も達成できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →