SOA信頼性とビジネス継続性
あるソーシャルゲーム企業はEC2ゲームサーバーからElastiCache Redis（シングルノード構成）をセッションストアとして使用しています。
先日Redisノードがハードウェア障害で停止し、全プレイヤーのセッションが失われ大量の再ログインが発生しました。
「プライマリノード停止時に最短時間で復旧しデータロスを最小化する」という要件に対して、最も適切な対応はどれですか？
AElastiCacheのスナップショット（バックアップ）を30分ごとに設定し、障害発生時はスナップショットから新規クラスターを手動復元する
スナップショットは最大30分のデータロスが発生し、スナップショットから新規クラスターを復元する作業にも数分〜数十分かかります。「最短時間で復旧しデータロスを最小化」という要件を満たしません。
BRedisレプリケーショングループを作成し、別AZにリードレプリカを1台以上配置してMulti-AZおよび自動フェイルオーバーを有効化する
✓ 正解
レプリケーショングループのMulti-AZ自動フェイルオーバーにより、プライマリ障害時にリードレプリカが数十秒以内でプライマリに昇格します。ほぼリアルタイムのレプリケーションでデータロスを最小化でき、アプリケーション側のエンドポイント変更も不要です。
Cシングルノード構成を維持しつつEC2のユーザーデータにRedis起動スクリプトを組み込み、Auto Scalingで障害時に新ノードを自動起動する
Auto Scalingで起動した新ノードは空の状態であるため、障害直前のセッションデータは完全に失われます。また起動・初期化に数分かかるため最短復旧にはならず、データロス最小化の要件も満たしません。
DAmazon DynamoDBをセッションストアとして採用し、セッションデータをKVS形式で格納することでElastiCacheへの依存を解消する
DynamoDBへの切り替えはセッション永続化の観点では有効ですが、アプリケーションの全面的な変更が必要で工数が大きく、インメモリのElastiCacheと比べてレイテンシが増加しゲームの応答性に影響します。構成変更だけで解決できる問題に対して過剰な対応です。
解説
ElastiCache Redisのレプリケーショングループは、プライマリノードとリードレプリカで構成されます。Multi-AZを有効化するとプライマリとレプリカが異なるAZに配置され、プライマリ障害時には自動フェイルオーバーにより数十秒以内にリードレプリカがプライマリへ昇格します。レプリケーションはほぼリアルタイムで行われるため、フェイルオーバー直前のセッションデータがほぼ保持されます。アプリケーションの接続先はレプリケーショングループのプライマリエンドポイントで固定されるため、昇格後も同じエンドポイントで接続が継続されます。
選択肢AのElastiCacheスナップショット復元は、最大30分のデータロスに加えスナップショットからの新規クラスター作成・起動に数分〜数十分かかり、最短復旧の要件を満たしません。
選択肢CのAuto Scalingによる新ノード起動は、起動した新ノードにはレプリケーションデータがなくセッションデータが完全に失われます。また起動・初期化にも数分かかります。
選択肢DのDynamoDBへの切り替えはセッション永続化に有効ですが、アプリケーションの大規模な変更が必要であり、インメモリキャッシュのレイテンシ優位性も失われます。ElastiCacheの構成変更だけで要件は達成できます。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →