Lambda運用の設計 バージョン・エイリアス・同時実行・デッドレターキューで安全に運用する

DOP-C02を目指す方向けに、本番のLambda関数を安全にデプロイし、負荷と失敗を制御して運用する設計を解説します。試験では、関数を書けることではなく、段階的なリリース・スロットリング対策・失敗時の扱いという要件から設定を選ぶ力が問われます。

覚え方：3つの観点で考える

Lambda運用は「リリース(バージョンとエイリアス)」「負荷(同時実行の制御)」「失敗(再試行と送信先)」の3観点で整理できます。

リリース：バージョンとエイリアスで段階的に切り替える

関数を発行すると不変のバージョンが作られ、エイリアス(prodなど)がそのバージョンを指します。エイリアスには重み付けルーティングがあり、新バージョンへ10パーセントだけ流すカナリアリリースが可能です。CodeDeployのLambdaデプロイ設定(Canary10Percent5Minutesなど)と組み合わせると、CloudWatchアラームで自動ロールバックまで自動化でき、SAMのDeploymentPreferenceで宣言的に書けます。呼び出し側(API GatewayやEventBridge)はエイリアスのARNを指定して、バージョン番号の変更に影響されないようにします。

負荷：同時実行の制御

アカウントのリージョンごとの同時実行数は既定1000で、これを超えるとスロットリングされます。予約済み同時実行は特定の関数に上限を確保しつつ、他の関数がそれ以上使えないようにする「上限かつ確保」の設定で、下流のDBを守るために意図的に小さくする用途もあります。プロビジョニングされた同時実行は初期化済みの実行環境を事前に用意してコールドスタートをなくす設定で、レイテンシ要件が厳しいAPIに使い、Application Auto Scalingでスケジュールや使用率に応じて増減できます。

失敗：再試行と送信先の設計

非同期呼び出し(S3・SNS・EventBridgeなど)では既定で2回再試行され、それでも失敗したイベントはデッドレターキュー(SQSまたはSNS)か、より詳細な情報を含む送信先(Destinations)の失敗時設定へ送れます。SQSをイベントソースとする場合の再試行はキューの可視性タイムアウトとmaxReceiveCountに従い、失敗分はキュー側のデッドレターキューへ移動します。ストリーム(Kinesis・DynamoDB)では、失敗したバッチがシャードをブロックしないようバッチの二分割(bisect)・最大再試行回数・レコードの最大経過時間を設定し、失敗レコードの情報を送信先へ記録します。

チェックリスト

• バージョンとエイリアスの関係と、重み付けルーティングによるカナリアを説明できる
• CodeDeployのLambdaデプロイ設定とアラームによる自動ロールバックを構成できる
• 予約済み同時実行とプロビジョニングされた同時実行の違いを言える
• 非同期・SQS・ストリームそれぞれの再試行と失敗時の扱いを説明できる
• デッドレターキューと送信先(Destinations)の違いを理解している

まとめ

Lambda運用は「リリース・負荷・失敗」の3観点で設計します。エイリアスとCodeDeployで安全に出し、同時実行で守り、DLQや送信先で失敗を取りこぼさない、という組み合わせをDOPの定番として押さえましょう。

クイズで理解度を確かめ、最新の出題範囲はAWS認定 公式ページで確認しておきましょう。