ある企業が、Lambdaを使ったサーバーレスアーキテクチャでVPC内のElastiCache（Redis）クラスターにアクセスしている。Lambda関数はプライベートサブネットに配置されており、Redis接続の確立はコールドスタート時にのみ行うようにしてコネクションを使い回している。しかし本番環境で「Lambda関数が増加するとRedisのコネクション数が上限に達し、新規コネクションが拒否されるエラーが発生する」という問題が起きている。コードを大幅に変更せずにコネクション数の爆発を抑える方法として最も適切なものはどれか。

正解: A

Lambdaの同時実行インスタンス数が増えるとそれぞれがコネクションを保持するため、Redisのコネクション数がスケールとともに爆発的に増加する問題（Connectionstorm）はサーバーレス×コネクション型ストアの典型的な課題である。Amazon ElastiCache Serverlessはコネクションプールを内蔵しており、多数のLambdaインスタンスからの接続をプールで集約してRedis側への実際のコネクション数を抑制できる。既存のコードでRedis接続先のエンドポイントを変更するだけで対応できるため、「コードを大幅に変更せず」という要件を満たす。選択肢Dのリクエストごとのコネクション新規作成は、コネクション数の上限到達を回避できるが、接続オーバーヘッドによりレイテンシが大幅に増加し、実用的でない。選択肢Cの予約済み同時実行数による制限はコネクション数を管理できるが、スパイク時にLambdaがスケールできなくなりAPIの可用性が損なわれる。また、これは本質的な解決ではなくトレードオフにすぎない。選択肢BのMemcachedへの移行はRedis固有の機能（永続化・Sorted Set等）を失う可能性があり、アーキテクチャの大幅な変更を要する。