DVAトラブルシューティングと最適化
Lambda関数からAmazon ElastiCache（Redis）に接続してセッションデータをキャッシュするアプリケーションがあります。トラフィック増加後、Redisの同時接続数が上限に達してConnectionTimeoutエラーが頻発するようになりました。CloudWatch Logsを調査すると、Lambda関数の各呼び出しで毎回新しいRedis接続を作成・切断していることが確認されました。追加インフラコストを増やさずにこの問題を根本的に解決する方法はどれですか？
AElastiCacheノードタイプをより大きなサイズにアップグレードしてmaxclients値を引き上げ、許容される同時接続数の上限を増やしてエラーを解消する
ElastiCacheのアップグレードでmaxclients値は増えるが、Lambda呼び出しごとに新たな接続を作成し続ける根本的な問題は解決しない。追加コストが発生し、トラフィック増加に合わせて再び同じ問題が発生するためスケーラブルではない。
BLambda関数の予約済み同時実行数（Reserved Concurrency）を低い値に設定して同時実行を制限し、ElastiCacheへの同時接続数がmaxclients上限を超えないようにする
Reserved Concurrencyで同時実行数を制限するとLambdaのスケーラビリティが低下してスロットリングが発生し、ユーザー体験が悪化する。接続再利用の問題の根本解決にはならず、この選択は逆効果。
CRedisクライアントの初期化コードをハンドラー関数の外側のグローバルスコープに移動し、実行コンテキストが再利用される際にRedis接続も再利用されるよう変更する
✓ 正解
Lambdaの実行コンテキスト再利用の仕組みを活用し、グローバルスコープで初期化したRedisクライアントはウォームな呼び出し間で共有される。コード変更のみで接続の無駄な作成・切断を排除でき、追加コストなしで問題を根本的に解決できる正しいアプローチ。
DElastiCacheをシングルノードからクラスターモード（複数シャード）に変更して接続要求を複数ノードに分散させ、各ノードへの接続数を削減する
ElastiCacheクラスターモードは書き込みスケーラビリティと可用性向上に有効だが、各Lambda呼び出しが接続を作成・切断し続けるコード上の問題は解決しない。各シャードへの接続数がトラフィックと共に増加し続ける。
解説
Lambdaの実行コンテキスト（Execution Context）はウォーム状態で同一コンテナ内の後続呼び出しに再利用される。ハンドラー外のグローバルスコープで初期化したオブジェクト（DBコネクション・SDKクライアント等）は、同じコンテキストを再利用する次の呼び出しでそのまま使われる。Redisクライアントをグローバルスコープに移動することで、呼び出しごとに接続を作成・切断する無駄がなくなり累積接続数を大幅に削減できる。コード変更のみで対応可能で追加インフラコストは不要。
選択肢AのノードタイプアップグレードはRedisの接続数上限を増やせるが、Lambda呼び出しのたびに接続を作成する根本的な問題は解決しない。トラフィックが増えれば再び同じ問題が発生し、追加インフラコストも増加する。
選択肢BのReserved Concurrency制限はアプリケーションのスケーラビリティを低下させる。接続を再利用しない根本的な問題は解消されず、ユーザー体験に悪影響を与える。
選択肢DのElastiCacheクラスターモードへの変更は水平スケーリングには有効だが、Lambda各呼び出しで接続作成・切断する問題は解決しない。ノードが増えても接続数の総増加は続く。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →