Lambdaの適用判断

このレッスンでできるようになること

要件の文から実行時間と同時実行の制約を拾い、「これは Lambda で組む」「これは Lambda にしない」を根拠つきで言い切れるようになります。SAA では、サーバーレスが常に正解ではない問題が必ず出ます。

まず要件を読む

ある動画配信の会社が、2つの処理を AWS へ移そうとしています。

1つ目は、ユーザーが画像をアップロードしたときにサムネイルを作る処理です。1件あたり数秒で終わり、アップロードは日中に不規則に発生します。

2つ目は、投稿された動画を複数の解像度へ変換する処理です。長い動画だと 1 件に 3 時間ほどかかります。

社内では「どちらもイベント駆動なので Lambda で作ろう」という案が出ています。この案の片方は正しく、もう片方は動きません。どこで線を引くかがこのレッスンです。

Lambda にしない判断をする境界

本記事執筆時点で、試験に出る境界は次のとおりです。数字そのものより、何を超えると別のサービスになるかを覚えます。

冒頭のサムネイル生成は数秒なので Lambda が素直です。動画変換は 3 時間かかるので、15 分の壁に当たって完走しません。ここは Fargate のタスクや AWS Batch に出します。「イベント駆動だから Lambda」ではなく、1 回の処理が 15 分で終わるかで切ります。

同時実行の制約が問題になる場面

Lambda は呼ばれた数だけ並列に立ち上がります。これは強みですが、後ろに RDS のようなコネクション数に限りがあるものがいると、そのまま接続を食い潰します。要件文に「データベースの接続が枯渇した」「下流のシステムが過負荷になった」とあれば、次の道具を選びます。

• 予約済み同時実行 — その関数が使える上限を決める。下流を守り、同時に他の関数の枠を奪わないようにする
• SQS を挟む — 押し寄せたイベントをいったん貯めて、決めた速さで処理する
• RDS Proxy — 接続をプールして使い回し、DB 側の接続数を抑える

逆に「最初の呼び出しだけ応答が遅い」「レイテンシを一定にしたい」という要件はコールドスタートの話で、答えはプロビジョニングされた同時実行です。予約済み同時実行と名前が似ていますが、上限を決めるものと、あらかじめ温めておくもので役割が違います。ここは試験で入れ替えて出されます。

要件語から構成への対応

よくある引っ掛け

その1 「Lambda のタイムアウトを延ばす」選択肢。 設定値は上限の範囲でしか延ばせないので、3 時間の処理はどう設定しても終わりません。実行時間が上限を超える問題は、設定ではなくサービスの選び直しで解きます。

その2 「メモリを増やせば同時実行の問題が解決する」選択肢。 メモリを増やすと 1 回の処理は速くなりますが、下流の接続数が枯渇している問題には効きません。むしろ処理が速く回る分だけ流量が増えることもあります。

まとめ

• 1 回の実行が本記事執筆時点で 15 分を超えるなら Lambda にしない
• 長時間の処理は Batch や Fargate へ、分割できるなら Step Functions へ
• 下流を守るのは予約済み同時実行、SQS、RDS Proxy
• コールドスタート対策はプロビジョニングされた同時実行。役割を取り違えない
• 断続的な負荷ほどサーバーレスが効き、常時高負荷ではコンテナのほうが安くなりうる