// シス担のミカタ
サーバーレス

同時実行数と制限 どうじじっこうすうとせいげん

同時実行数コンカレンシーLambdaスロットリングスケーリングサーバーレス
同時実行数と制限について教えて

簡単に言うとこんな感じ！

サーバーレス関数って「何人でも同時に使えるすごいやつ」なんだけど、実は「何人まで同時に処理できるか」に上限があるんだ！その上限を超えると新しいリクエストは「ちょっと待って！」って弾かれちゃう。これが「同時実行数と制限」だよ！

同時実行数と制限とは

同時実行数（コンカレンシー、Concurrency） とは、サーバーレス関数（AWS Lambda などの FaaS）が「同じ瞬間に並行して処理できるリクエストの最大数」のことです。たとえば同時実行数が 100 であれば、100 件のリクエストまでは同時に処理できますが、101 件目は待機または拒否されます。

サーバーレスは「リクエストが来たら自動でスケール（台数を増やす）する」という特性を持ちますが、それは無限ではありません。クラウドプロバイダーはリージョンごと・アカウントごとに上限を設けており、これを超えると スロットリング（Throttling） と呼ばれるエラーが発生します。ビジネスの発注・選定・設計フェーズで見落としやすいポイントの一つです。

実務上、突発的なアクセス集中やバッチ処理との競合などで同時実行数の上限に達してしまい、ユーザーにエラーが返るトラブルは珍しくありません。上限を正しく把握し、必要に応じてリザーブドコンカレンシーやプロビジョンドコンカレンシーを設定しておくことが、安定したサービス運用の鍵です。

同時実行数の仕組み

サーバーレスでは、リクエストが届くたびに関数の「実行環境（インスタンス）」が起動します。同時実行数とは、その実行環境が同時に何本立ち上がれるか、と考えると直感的です。

用語意味
同時実行数（コンカレンシー）ある瞬間に並行処理できるリクエスト数
スロットリング上限超過時に新規リクエストを拒否すること（HTTP 429）
リザーブドコンカレンシー特定の関数に同時実行枠を専用確保する設定
プロビジョンドコンカレンシーコールドスタートを防ぐため、実行環境をあらかじめ温めておく設定
アカウントレベル上限AWS の場合デフォルト 1,000（リージョンごと。申請で引き上げ可）

同時実行数の計算式

関数の同時実行数は、次の式でざっくり見積もれます。

同時実行数 ≈ リクエスト数（件/秒）× 関数の平均実行時間（秒）

例）100 req/秒 × 0.5秒 = 50 の同時実行数が必要

覚え方

「同時は同士（どうし）を助ける」→ 同時実行数を超えたら助けられずスロットリング！
リクエストが増えたら「仲間（インスタンス）」を増やすけど、チームの人数制限（上限） があるイメージで。

歴史と背景

  • 2014年 — AWS Lambda が登場。「サーバー管理不要で関数を実行」という概念が登場し、自動スケーリングが注目を集める
  • 2015年頃 — 利用が拡大するにつれ、同時実行数の上限（当初は低め）でスロットリングが頻発し、問題として認知されるようになる
  • 2018年 — AWS がリザーブドコンカレンシーを正式サポート。関数ごとに枠を確保できるようになり、重要な関数が枠を食い尽くされる問題を緩和
  • 2019年 — プロビジョンドコンカレンシーが追加。コールドスタート（起動遅延）対策として注目される
  • 現在 — Google Cloud Functions・Azure Functions などでも同様の概念が整備され、サーバーレス設計の必須知識として定着

コンカレンシーの種類と比較

3種類のコンカレンシー設定

アカウント全体の同時実行上限（例: 1,000） リザーブド コンカレンシー 特定の関数に 専用枠を確保 例: 重要APIに 200枠を予約 🔒 他の関数が奪えない プロビジョンド コンカレンシー 実行環境を 事前に起動して待機 コールドスタートを ゼロに ⚡ 追加コストがかかる 未設定 （デフォルト） 残り枠をすべての 関数で共有 上限まで自動 スケール 🌊 枠を使い切られる可能性 リザーブド + プロビジョンド + 未設定の合計 ≤ アカウント上限

スロットリングが起きたときの流れ

リクエスト到着
     │
     ▼
同時実行数に空きがある？
     │
   YES ──────────────────→ 関数を実行（正常）
     │
    NO
     │
     ▼
リトライ設定あり？
     │
   YES ──→ キューで待機 → 空き次第実行
     │
    NO
     │
     ▼
HTTP 429 / TooManyRequestsException を返す（スロットリング）

主要クラウドの上限比較

プロバイダーデフォルト上限引き上げ
AWS Lambda1,000（リージョンあたり）サポートへ申請で可能
Google Cloud Functions3,000（プロジェクトあたり）申請で可能
Azure Functions（消費プラン）200（サブスクリプションあたり）申請で可能

関連する規格・RFC

規格・仕様内容
HTTP 429 Too Many Requestsスロットリング時に返す標準HTTPステータスコード（RFC 6585）
CloudEvents v1.0サーバーレスイベントの標準仕様。コンカレンシー設計に影響する
AWS Service QuotasAWSサービスの上限を一元管理・申請する仕組み

関連用語