ある企業が、EC2 インスタンス上で動作するステートフルな Web アプリケーションを Auto Scaling 対応に改修しようとしている。現在はユーザーのセッションデータがサーバーのローカルメモリに保存されており、スケールイン時にセッションが失われてしまう。アプリケーションコードの変更を最小限にしてセッションを保持する最も適切なソリューションはどれか。
- A. EC2 インスタンスのローカルストレージを Instance Store に変更し、高速な読み書きでセッション処理を高速化する。
- B. Auto Scaling グループのスケールインプロセスを無効化して、インスタンスが削除されないようにする。
- C. ALB のスティッキーセッション(Session Stickiness)を有効化して、同一ユーザーのリクエストが常に同一インスタンスに届くようにする。
- D. セッションデータを Amazon ElastiCache for Redis に外部化し、アプリケーションのセッションストアを ElastiCache に向ける。
解答と解説を見る
正解: D
セッションデータを Amazon ElastiCache for Redis などの外部共有ストアに保存することで、どのインスタンスがリクエストを処理してもセッション情報を取得できる。これがステートフルアプリケーションの Auto Scaling 対応の標準パターンである。セッションストアのライブラリを ElastiCache エンドポイントに向ける変更が必要だが、比較的少ないコード変更で対応できる。選択肢CのALB スティッキーセッションはセッション維持には有効だが、そのインスタンスがスケールインで終了するとセッションが失われる。根本的な解決策にはならない。選択肢BのAuto Scaling スケールイン無効化はスケーラビリティを失い、コスト効率も悪化する。Auto Scaling の意味をなさない設定変更である。選択肢AのInstance Store は揮発性ストレージで、インスタンス終了時にすべてのデータが失われる。セッション保持の要件を満たさない。
📚 関連サービスの解説: Amazon ElastiCache