Lambda の 15 分制限はなぜ 15 分なのか - サーバーレスの設計制約に隠された合理性
Lambda の最大実行時間 15 分、メモリ上限 10GB、ペイロード 6MB など、サーバーレスの各種制限がなぜその値に設定されているのかを、Firecracker の設計思想とマルチテナント運用の観点から解説します。
制限は制約ではなく設計判断である
Lambda を使い始めた開発者が最初に直面するのが、各種の制限 (Limits) です。最大実行時間 15 分、メモリ 128MB〜10,240MB、同期呼び出しのペイロード 6MB、デプロイパッケージ 250MB (展開後)。これらの数字は恣意的に決められたものではなく、マルチテナント環境でのリソース公平性、運用の安全性、コスト効率のバランスを取った結果です。Lambda は数百万の顧客の関数を同一の物理インフラ上で実行するマルチテナントサービスです。1 つの関数が無制限にリソースを消費すると、他の顧客の関数に影響を与えます。制限は「ノイジーネイバー問題」を防ぐためのガードレールであり、同時にサーバーレスの設計パラダイムを形作る意図的な制約でもあります。制限があるからこそ、開発者は処理を小さな単位に分割し、イベント駆動で疎結合なアーキテクチャを設計するようになります。
15 分制限の歴史と背景
Lambda が 2014 年にローンチされた当初、最大実行時間はわずか 60 秒でした。2016 年に 5 分に延長され、2018 年に現在の 15 分に引き上げられました。この段階的な延長は、顧客のユースケースの拡大と、AWS 側のインフラ最適化の進展を反映しています。15 分という値には、いくつかの技術的・運用的な根拠があります。第 1 に、Firecracker MicroVM のライフサイクル管理です。Lambda は Firecracker 上で関数を実行しますが、MicroVM を長時間維持するとメモリリークやリソースの断片化が蓄積するリスクがあります。15 分は、実用的なバッチ処理を完了できる十分な時間でありながら、MicroVM の健全性を維持できる範囲です。第 2 に、障害検知と復旧の観点です。関数が無限に実行され続けると、デッドロックや無限ループの検知が困難になります。15 分のタイムアウトは、異常な実行を自動的に終了させるセーフティネットとして機能します。第 3 に、コスト予測可能性です。Lambda は実行時間に対して課金されるため、実行時間に上限がないと、バグによる無限ループが予期しない高額請求につながります。15 分の上限は、最悪のケースでも 1 回の実行コストが予測可能な範囲に収まることを保証します。
メモリ 10GB とペイロード 6MB の理由
Lambda のメモリ上限は、2020 年に 3,008MB から 10,240MB (10GB) に引き上げられました。この上限は、Firecracker MicroVM が動作する物理ホストのメモリ容量と、1 台のホストで同時に実行される MicroVM の数から逆算されています。物理ホストのメモリを数百の MicroVM で共有するため、1 つの MicroVM に割り当てられるメモリには上限があります。10GB は、機械学習の推論、大規模なデータ変換、メモリ集約型の計算処理をカバーできる実用的な上限です。同期呼び出しのペイロード上限 6MB は、API Gateway との統合を前提とした設計です。API Gateway のリクエスト/レスポンスのペイロード上限が 10MB であり、Lambda 側はそれより小さい 6MB に設定されています。この差は、Base64 エンコーディングのオーバーヘッド (約 33% 増) を考慮したものです。6MB のバイナリデータを Base64 エンコードすると約 8MB になり、API Gateway の 10MB 上限に収まります。大きなデータを扱う場合は、S3 にデータを保存し、Lambda にはオブジェクトキーだけを渡す「クレームチェックパターン」が推奨されます。非同期呼び出しのペイロード上限が 256KB とさらに小さいのは、非同期呼び出しのペイロードが SQS キューに一時保存されるためです。
同時実行数 1,000 のデフォルト制限
Lambda のアカウントあたりのデフォルト同時実行数は 1,000 です。この制限は、新規アカウントが意図せず大量の Lambda 関数を同時実行し、高額な請求が発生することを防ぐためのセーフガードです。上限緩和リクエストにより、数万〜数十万の同時実行数まで引き上げることが可能です。同時実行数の制限は、Lambda だけでなく、Lambda が接続する下流のサービスを保護する役割も果たしています。たとえば、Lambda が RDS データベースに接続する場合、同時実行数が無制限だとデータベースの最大接続数を超えてしまいます。RDS Proxy を使用すれば接続プーリングで緩和できますが、同時実行数の制限自体が最初の防御線として機能しています。関数レベルの予約済み同時実行数 (Reserved Concurrency) を設定すれば、特定の関数が他の関数の同時実行枠を食い潰すことを防げます。たとえば、重要な API バックエンドの関数に 500 の予約済み同時実行数を設定し、バッチ処理の関数には 100 を設定すれば、バッチ処理の急増が API のパフォーマンスに影響しません。
制限を味方にするアーキテクチャ設計
Lambda の制限を「不便な制約」と捉えるか「設計のガイドライン」と捉えるかで、アーキテクチャの品質は大きく変わります。15 分制限は、処理を小さな単位に分割し、Step Functions でオーケストレーションする設計を促します。Step Functions の Express Workflow は最大 5 分、Standard Workflow は最大 1 年の実行が可能で、Lambda の 15 分制限を事実上無制限に拡張できます。6MB のペイロード制限は、関数間のデータ受け渡しに S3 を使うクレームチェックパターンを促し、結果として関数間の疎結合性が高まります。メモリ制限は、処理をストリーミング化する設計を促します。10GB のファイルを一括でメモリに読み込むのではなく、S3 Select や Kinesis Data Streams でストリーミング処理すれば、少ないメモリで大量のデータを処理できます。これらの制限は、結果的にスケーラブルで耐障害性の高いアーキテクチャへと開発者を導きます。制限がなければ、モノリシックな巨大関数を書いてしまう誘惑に負けるでしょう。サーバーレスの設計パターンを深く理解するには、専門書籍 (Amazon)が参考になります。