← AWSサービスの内部原理 コース
20. スケーリングの上限とレバー — アカウント上限・予約・プロビジョンド
Lambdaのスケーリングを「総量(水位)」と「速度(傾き)」の2軸で捉え、予約とプロビジョンドという2つのレバーが何を変えているのかを図で追います。
① 上限は2種類ある — 「水位」と「傾き」
総量の上限(水位)リージョン全関数で同時1,000環境
デフォルト値。全関数がこのプールを奪い合う速度の上限(傾き)関数ごとに10秒あたり1,000環境
=10秒あたり毎秒10,000リクエスト分- 総量=『同時にいくつまで走れるか』という水位の話
- 速度=『どれだけ急に増やせるか』という傾きの話
- 2つは混同されがちだが、まったく別の軸
Lambdaのスケーリング上限は、同時にいくつ走れるかという『総量』と、どれだけ急に増やせるかという『速度』の、まったく別の2軸に分かれます。
② なぜ速度に上限? — 下流を守る過負荷保護
トラフィック急増需要が上限より速く増える / 最大同時実行に到達
立ち上げ速度に上限をかける
受けられる分は処理
あふれた分は429で拒否スロットリング=入場制限(アドミッションコントロール)
殺到が届かない
下流のDB・外部API共倒れを防げる
- 全部受けて全部遅くするより、受けられない分をその場で明確に断るほうが系全体は壊れない
- 総量の上限にも10倍のリクエスト毎秒制限がセット(1,000同時なら毎秒10,000リクエスト)——同じレートリミットの発想
トラフィック急増時に環境を無制限に増やすと下流が殺到で共倒れになるため、Lambdaは意図的に立ち上げ速度を制限し、あふれた分を429で断ります。
③ 必要な総量はリトルの法則で計算できる
平均リクエスト毎秒例: 100 req/秒
× 平均処理時間(秒)例: 0.5 秒/件
リトルの法則
必要な同時実行数例: 100 × 0.5 = 50 環境
- 1環境1リクエスト。処理が終わって初めて次のリクエストに再利用される
- 処理時間が短いほど、同じ流量でも必要な環境は少なくて済む
1環境は同時に1リクエストしか処理できないので、『毎秒リクエスト × 処理時間』がそのまま同時に埋まる環境数になります。
④ 予約同時実行 — 総量プールを切り分ける
共有プール 1,000リージョンの全関数で奪い合い
予約で切り分け
重要関数の専用枠確保=他関数に食い潰されない / キャップ=これ以上は拡大できない
残りの未予約プール他の関数はこちらを共有
- 確保した枠はその関数専用。他の関数は使えなくなる
- 環境を事前に立ち上げてはくれない(枠を押さえるだけ)ので追加料金なし
- OSやDBでおなじみの、共有リソースを名前付きパーティションに区切る隔離と同じ考え方
1,000の共有プールから特定関数の専用枠を確保する操作で、その枠は『下限(確保)』と『上限(キャップ)』を同時に与えます。環境を温めるわけではなく、追加料金もありません。
⑤ プロビジョンド同時実行 — Init済みの箱を並べておく
リクエスト到着
プロビジョンド枠内なら
Init済みの暖かい環境で即処理Initフェーズを待たない
枠を超えた分は
予約なし → オンデマンド起動未予約プールを使用。コールドスタートが起こりえる
予約あり → その上限で429予約枠を超えた分はスロットリング
指定数の環境をあらかじめInit済み(暖まった状態)で用意しておくコールドスタート対策で、枠内のリクエストは初期化を待たずに即処理されます。
⑥ 2つのレバーは「変えている対象」が違う
予約(Reserved)変えるのは「総量の分け方」= どれだけ使ってよいかの枠
枠の分割のみ・無料・環境は温めないプロビジョンド(Provisioned)変えるのは「初期化のタイミング」= 暖まった箱を何個用意するか
コールドスタート対策予約は『総量の分け方』を、プロビジョンドは『初期化のタイミング』を変える——名前は似ていても操作している軸がまったく別です。