高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜

JAWS-UG KYUSHU QUEST 2026 in Fukuoka
https://jawsug-fukuoka.connpass.com/event/403616/

Transcript

1. 高負荷プロダクション環境におけるAWS Lambdaのリアル 〜スケールとコストを左右する実行ライフサイクルの技術仕様〜 JAWS-UG KYUSHU QUEST 2026 in Fukuoka 2026.09.26 Mai Miyazaki @maimyyym ©Fusic Co., Ltd. 0
2. Introduction Click!! 宮 崎 真 衣 M A I M I YA Z A K I HN: mai (@maimyyym ) 株式会社Fusic 2023年10月入社 事業本部 クラウドエンジニアリング部門 チームリーダー / エンジニア ◉ Work - AWSを基盤とするシステムの開発・運用、技術提案 AWSパートナープログラム関連業務 ◉ Skill - AWS / Python / TypeScript / PHP(Laravel) Interested in: Security, Identity & Compliance ◉ Hobby - 野球観戦、舞台観劇 ◉ Comment - re:Invent 2026 参加します！ ©Fusic Co., Ltd. 1
3. 1. はじめに 2. スケールしないAWS Lambda 3. AWS Lambdaの実行環境と同時実行コントロール 4. AWS Lambdaのコスト最適化 5. 開発・運用現場におけるAWS Lambdaのチューニング ©Fusic Co., Ltd. 2
4. 01 はじめに ©Fusic Co., Ltd. 3
5. はじめに はじめに サーバーレスといえば、どのようなことが思い浮かびますか？ ©Fusic Co., Ltd. 4
6. はじめに はじめに サーバーレスといえば、どのようなことが思い浮かびますか？ わたしは、高性能要件×高負荷な環境で AWS Lambdaを用いたシステムの開発・運用を重ねていく中で多くの困難に直面しました。 必ずしも安いとは限らない。 必ずしもスケールできるとは限らない。 ©Fusic Co., Ltd. 5
7. はじめに はじめに サーバーレスといえば、どのようなことが思い浮かびますか？ わたしは、高性能要件×高負荷な環境で AWS Lambdaを用いたシステムの開発・運用を重ねていく中で多くの困難に直面しました。 必ずしも安いとは限らない。 必ずしもスケールできるとは限らない。 これから本番環境を設計する皆さまの技術判断の軸になる、 AWS Lambdaと正面から向き合った知見をお届けします。 ©Fusic Co., Ltd. 6
8. はじめに はじめに ECSにすればよかったのにというツッコミはなしでお願いします！ （諸事情によりAWS Lambdaで構築を進めるしかなかったので・・・） そういうこともある… ©Fusic Co., Ltd. 7
9. 02 スケールしないAWS Lambda ©Fusic Co., Ltd. 8
10. スケールしないAWS Lambda スケールしないAWS Lambda AWS Lambdaといえば・・・（サーバーレスといえば） アクセス変動に応じてスケールする ※ 多くのメリットのうちの一例です。 サーバーの管理が不要であることが第一のメリットだと考えています。 ©Fusic Co., Ltd. 9
11. スケールしないAWS Lambda スケールしないAWS Lambda ところが・・・ ©Fusic Co., Ltd. 10
12. スケールしないAWS Lambda スケールしないAWS Lambda あまりに急激なスパイクには対応できないこともある。 ©Fusic Co., Ltd. 11
13. スケールしないAWS Lambda スケールしないAWS Lambda あまりに急激なスパイクには対応できないこともある。 ©Fusic Co., Ltd. 12
14. スケールしないAWS Lambda 同時実行スケーリングレート 原因は、同時実行スケーリングレート 各 AWS リージョン および各関数において、同時実行のスケーリングレートは 10 秒ごとに 1,000 の実行環境インスタンス (または 10 秒ごとに 1 秒あたり 10,000 リクエスト) です。 つまり、Lambda は 10 秒ごとに最大 1,000 の追加実行環境インスタンスを各関数に割り当 てるか、または 1 秒あたり 10,000 件の追加リクエストに対応できます。 https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/scaling-behavior.html 10,000rpsを超えるスパイクには対応できない！ ©Fusic Co., Ltd. 13
15. スケールしないAWS Lambda 同時実行スケーリングレート 公式ドキュメントには・・・ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/scaling-behavior.html ©Fusic Co., Ltd. 14
16. スケールしないAWS Lambda 同時実行スケーリングレート 公式ドキュメントには・・・ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/scaling-behavior.html （本当にあった話）この制限について心配ごとが起きるケース 大規模アクセス × 予測できない急激なスパイクの可能性 ©Fusic Co., Ltd. 15
17. スケールしないAWS Lambda Tips: クォータについて 同時実行数 同時実行スケーリングレート 定義 同時に処理できる未完了のリクエストの数 （ある時点においてリクエストを処理して いる実行環境インスタンスの数） リクエスト増加に応じてスケールできる最 大速度（Lambda が新しい実行環境をどれ だけ速く作成できるか） イメージ 同時に何個の実行環境を持てるか。 「どれだけ持てるか」の量。 10 秒ごとに何個まで増やせるか。 「どれだけ速く増やせるか」の速度。 デフォルトのクォータ 1,000 10 秒ごとに 1,000 の実行環境インスタンス （または 10 秒ごとに 1 秒あたり 10,000 リ クエスト） 引き上げ 数万まで可能 不可 ©Fusic Co., Ltd. 16
18. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency AWS Lambdaで利用できる同時実行コントロール 予約済み同時実行 プロビジョニングされた同時実行 Reserved Concurrency Provisioned Concurrency 関数のために確保される、その関数だけが使え 初期化済みで、リクエストに即座に応答できる る同時実行の最大数。 状態に保たれた実行環境の数。 その関数のために確保される量であり、その関 コールドスタートと可変的な起動レイテンシを 数が使える同時実行の上限でもある。 回避するための仕組み。 ©Fusic Co., Ltd. 17
19. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency プロビジョニングされた同時実行（Provisioned Concurrency） スケーリングレートは「新しく実行環境を増やせる速度」の制限。 Provisioned Concurrency は実行環境をあらかじめ確保するものなので、この制限の土俵に乗らない。 ©Fusic Co., Ltd. 18
20. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency 実行環境（インスタンス）を確保するからこそ、その分の追加料金が発生 確保している量 例: メモリ 1,024MB × 設定数 100 この面積 ＝ 料金 リクエストが来なくても課金される 1マス ＝ 1 GB-秒 この単位で料金が決まる 期間（確保している時間） https://aws.amazon.com/jp/lambda/pricing/ ©Fusic Co., Ltd. 19
21. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency 実行環境（インスタンス）を確保するからこそ、その分の追加料金が発生 確保している量 例: メモリ 1,024MB × 設定数 100 この面積 ＝ 料金 リクエストが来なくても課金される 1マス ＝ 1 GB-秒 まさに、この体積がコストに直結 この単位で料金が決まる 期間（確保している時間） https://aws.amazon.com/jp/lambda/pricing/ ©Fusic Co., Ltd. 20
22. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency コスト最適化のために・・・ Application Auto Scaling を使用して、Provisioned Concurrency の設定値を自動で管理 スケジュールに基づくスケーリング ターゲット追跡スケーリング 予測可能な場合 予測不可能な場合 ©Fusic Co., Ltd. 21
23. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency コスト最適化のために・・・ Application Auto Scaling を使用して、Provisioned Concurrency の設定値を自動で管理 スケジュールに基づくスケーリング ターゲット追跡スケーリング 予測可能な場合 予測不可能な場合 ©Fusic Co., Ltd. 22
24. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency 予測不可能なスパイクに対応するための、ターゲット追跡スケーリングポリシー 【仕組み】 ProvisionedConcurrencyUtilization （＝確保量に対する実際の使用率）の目標値（例: 0.7）超えを検知 →ProvisionedConcurrencyを新たに追加して実行環境を割り当てることで目標値を維持する メトリクス発行 アラーム発火 PC 数変更 環境の割り当て 〜1分 3分(※) 即時 1〜2分＋割当時間 利用可能 合計 5〜7分程 ※ バーストロードを少なくとも 3 分間維持 & ターゲット平均に達している 3 つのデータポイント が必要 ©Fusic Co., Ltd. 23
25. スケールしないAWS Lambda スパイク対策としてのProvisioned Concurrency 予測不可能なスパイクに対応するための、ターゲット追跡スケーリングポリシー 【仕組み】 ProvisionedConcurrencyUtilization （＝確保量に対する実際の使用率）の目標値（例: 0.7）超えを検知 →ProvisionedConcurrencyを新たに追加して実行環境を割り当てることで目標値を維持する メトリクス発行 アラーム発火 PC 数変更 環境の割り当て 急激なスパイクには間に合わない… 利用可能 〜1分 3分(※) 即時 1〜2分＋割当時間 ゆるやかなスパイク かつ コールドスタートを抑えたいケースでは効果的 合計 5〜7分程 ※ バーストロードを少なくとも 3 分間維持 & ターゲット平均に達している 3 つのデータポイント が必要 ©Fusic Co., Ltd. 24
26. 03 AWS Lambdaの実行環境と同時実行コントロール ©Fusic Co., Ltd. 25
27. AWS Lambdaの実行環境と同時実行コントロール 同時実行数のコントロール ここまでのまとめ 同時に起動できる実行環境には限りがある ©Fusic Co., Ltd. 26
28. AWS Lambdaの実行環境と同時実行コントロール 同時実行数のコントロール ここまでのまとめ 同時に起動できる実行環境には限りがある なるべく多くのリクエストを処理するために・・・ 「実行時間」を短縮 ©Fusic Co., Ltd. 27
29. AWS Lambdaの実行環境と同時実行コントロール 同時実行数のコントロール 同時に必要な実行環境の数は 平均RPS × 平均実行時間 で決まる。 1 つの実行環境は同時に 1 リクエストしか処理しないので、 実行時間を半分にすれば 1 環境あたりのスループットが倍になり、必要な環境数が半分に。 ©Fusic Co., Ltd. 28
30. AWS Lambdaの実行環境と同時実行コントロール AWS Lambda実行環境ライフサイクル 実行環境はINITで1回だけ作られ、INVOKEとフリーズを繰り返したあとSHUTDOWNで破棄される 初回のみ リクエストごとに繰り返し 最後に1回 INIT INVOKE フリーズ INVOKE SHUTDOWN 環境の作成 初期化処理 ハンドラを 実行 次の呼び出し まで一時停止 初期化なしで すぐ実行 一定時間 未使用で破棄 再利用（解凍） 【INITフェーズの内訳】 ①すべての拡張機能を起動 (Extension init) ②ランタイムをブートストラップ (Runtime init) ③関数の静的コード (Function init) を実行 【INVOKEフェーズの内訳】 ①関数の実行 ②拡張機能の実行 ©Fusic Co., Ltd. 29
31. AWS Lambdaの実行環境と同時実行コントロール レスポンス速度≠実行時間 INVOKEフェーズの終了条件はランタイム（関数の実行）とすべての拡張が終了すること INVOKE Function Extension レスポンス速度(※最短） 実行時間 ©Fusic Co., Ltd. 30
32. AWS Lambdaの実行環境と同時実行コントロール レスポンス速度≠実行時間 INVOKEフェーズの終了条件はランタイム（関数の実行）とすべての拡張が終了すること INVOKE Function Extension レスポンス速度(※最短） 実行時間 Extensionの例: ログ、メトリクス、トレースなどテレメトリーデータを処理・転送するOpenTelemetry Collector Lambdaレイヤーとして追加 ★Tips: レスポンス速度の改善 - Otel decouple processorを活用し、Extensionの処理完了前にレスポンスを返す - CloudWatchでサポートしているメトリクスを送信するだけならCloud Watch Metric Streamsに置き換えることで、 外部拡張機能として要していた「実行時間」がゼロになる ©Fusic Co., Ltd. 31
33. AWS Lambdaの実行環境と同時実行コントロール 実行時間の改善 ①まずは計測 INIT INVOKE 【INIT（コールドスタート）の時間】 - CloudWatch Logsに出力 - X-Rayで可視化 【INVOKEフェーズの時間】 - CloudWatchメトリクス - Duration - PostRuntimeExtensionsDuration ②フェーズごとに改善 【ハンドラ内の内訳詳細（外部との接続等）】 - X-RayやADOTを活用 ©Fusic Co., Ltd. 32
34. 04 AWS Lambdaのコスト最適化 ©Fusic Co., Ltd. 33
35. AWS Lambdaのコスト最適化 AWS Lambdaのコスト変動要素 コストを決める4つの要素 Provisioned Concurrency メモリ 実行時間 リクエスト量 （数×有効時間） ©Fusic Co., Ltd. 34
36. AWS Lambdaのコスト最適化 コスト最適化 多量のリクエストを処理するAWS Lambdaのコスト最適化の考え方 実行時間の最適化 同時実行数の削減 コスト最適化 コスト変動 コスト変動 ©Fusic Co., Ltd. 35
37. AWS Lambdaのコスト最適化 コスト最適化のためのメモリ最適化 メモリを増やすほど処理時間は速くなる 処理時間が短くなると 全体的なコスト削減が可能に。 処理内容によっては、効果的 効く：CPU バウンドな処理 効かない：I/O 待ちが支配的な処理 例： 関数のコード自体の計算処理 （画像変換、暗号化、圧縮、パース等） 例：外部からの応答を待っている処理 （DB、API、S3等） ©Fusic Co., Ltd. 36
38. AWS Lambdaのコスト最適化 Tips: メモリ最適値を可視化するツール AWS Lambda Power Tuning メモリを増やせば速くなるが、どこかで頭打ちになる メモリ設定を総当たりで実測して、最適値を可視化してくれる AWS 公式のツール AWS Lambda Power Tuning https://github.com/alexcasalboni/aws-lambda-power-tuning Step Functionsのステートマシンとして 動き、各メモリ設定を並列に実行 ©Fusic Co., Ltd. 37
39. 05 開発・運用現場におけるAWS Lambdaのチューニング ©Fusic Co., Ltd. 38
40. 開発・運用現場におけるAWS Lambdaのチューニング 開発・運用現場におけるAWS Lambdaのチューニング 技術仕様を踏まえて、開発・運用現場でどう考えるか ©Fusic Co., Ltd. 39
41. 開発・運用現場におけるAWS Lambdaのチューニング フェーズごとに考える 設計・開発フェーズ 運用フェーズ そもそも Lambda が正しいか 止めずにどう変え続けるか 実行基盤の選択 負荷テストで裏付け・調整 設定変更とリファクタリングによる 継続的な改善 ©Fusic Co., Ltd. 40
42. 開発・運用現場におけるAWS Lambdaのチューニング 設計・開発フェーズ 〈 後戻りできない判断 〉 実行基盤の選択 • スパイク • 予測できるか • スケーリングレートを超えるほど急激か • ベースライン • 常時どの程度一定か、ゼロに落ちるか Lambda / Managed Instances / ECS / EKS … 負荷テストで裏付け・調整 • 多量のリクエストやスパイクが発生した際に、 実際にコードを動かして何が起こるか実測 • 実測し、必要同時実行数の見極め・速度改善 メモリ / ProvisionedConcurrency /実行基盤 … ©Fusic Co., Ltd. 41
43. 開発・運用現場におけるAWS Lambdaのチューニング 運用フェーズ 〈 止められない中での改善 〉 無停止で適用できる改善策 • メモリ設定 — デプロイ不要・即時反映。最もコスパが良い • リファクタリング — 実行時間そのものを削る ©Fusic Co., Ltd. 42
44. タイトル まとめ Point 01 AWS Lambdaが、同時に起動できる・増やすことができる実行環境には限りがある Point 02 「実行時間」を短縮することで、「同時実行のコントロール」を行う Point 03 「実行時間」を短縮することが、結果的に「コスト最適化」につながる Point 04 設計・開発・運用…フェーズごとに技術判断をしっかり行なっていく ©Fusic Co., Ltd. 43
45. カジュアル面談もお気軽に！ Let’s Talk! OSEKKAI × TECHNOLOGY ココロと技術で、ぴったりも、びっくりも。 Thank You ご清聴いただきありがとうございました ©Fusic Co., Ltd. 44