← AWSサービスの内部原理 コース
23. メモリという名のCPUダイヤル — リソース比例配分の設計
Lambdaの性能設定が「メモリ1本」に見える理由を、比例配分の仕組み(cgroups)とコストの逆説まで図で追っていきます。
① 設定レバーは「メモリ」1本だけ
メモリ設定128MB〜10,240MB(1MB刻み)
CPUコア数スライダー存在しない
メモリに比例して自動決定
CPUパワーメモリと連動して増減
- コンソールで触れる性能レバーは「メモリ」だけ
- 「Lambdaはメモリの設定量に比例してCPUのパワーを割り当てる」(公式ドキュメント)
Lambdaの性能設定はメモリのみ。公式ドキュメントの通り、CPUパワーはメモリ設定量に比例して自動で割り当てられる。
② 比例の基準点 — 1,769MB = 1vCPU
128MB約1/14 vCPU
1,769MB= 1vCPU(基準点)
10,240MB約5.8vCPU
- 厳密には「毎秒1vCPU秒分のクレジット」という表現
- メモリを増やす行為 = 同時にCPUを買う行為
1,769MBでちょうど1vCPU相当(毎秒1vCPU秒分のクレジット)。ダイヤルを回すとCPUの取り分が比例して動く。
③ 正体はcgroups — OSの比例配分そのまま
メモリ設定値あなたが回すダイヤル
AWSが連動させる
cgroupsCPUシェア/クォータの割り当て
Linuxカーネルの機能「この比率で回す」と指示
CPUスケジューラ関数ごとにCPU時間を厳密に配分
- 1台の物理サーバーに複数の関数が同居しても取り分は厳密に区切られる
- メモリ2倍 → CPUの取り分も約2倍。魔法ではなくOSのリソース割り当て
各関数はマイクロVM内で動き、CPUの取り分はLinuxのcgroupsで区切られる。AWSはメモリ設定値をこのCPUシェア/クォータに連動させているだけ。
④ CPUバウンドの逆説 — 増額したのに安くなる
CPUバウンドな関数画像変換・暗号処理・大きな集計
メモリ2倍(単価は上がる)
CPUも約2倍計算そのものが速くなる
実行時間が半分以下に縮めば
総コスト低下時間 × メモリ が減る
- 課金 = 実行時間 × 割り当てメモリ
- 公式も「CPU・ネットワーク・メモリのいずれかがボトルネックなら、メモリ増で性能が劇的に改善しうる」と明記
課金は「実行時間 × 割り当てメモリ」。CPUバウンドな関数はメモリ増でCPUも増えて劇的に速くなり、時間×メモリの総コストがむしろ下がることがある。
⑤ IOバウンドでは効かない — 待ち時間は縮まない
IOバウンドな関数外部API応答待ち・DynamoDB読み取り待ち
メモリ2倍(単価は上がる)
待ち時間そのままCPUは遊んでいる
実行時間ほぼ変わらず
総コスト増加単価アップ分だけ損
- CPUバウンド(④)とは効き方が正反対 — 一律の勘でチューニングしない
外部APIやDynamoDBの応答を「待つ」時間が支配的な関数では、CPUを増やしても待ち時間は縮まず、単価だけ上がって総コストは増える方向に働く。
⑥ 見極めてからダイヤルを回す
CloudWatchで観測実行時間(Duration)とメモリ使用量
CPUバウンド? IOバウンド?
性質を見極める
自動で複数のメモリ設定を試行
AWS Lambda Power Tuning最適点を探すツール(公式紹介)
- 1本のダイヤルの背後にあるのは、cgroupsの比例配分とCPU/IOという計算の性質
その関数がCPUバウンドかIOバウンドかを観測で見極めてから設定する。これが根拠を持ったチューニングの定石。
サンプルコード(フレームワーク環境が必要なため表示のみ)
# メモリ(=CPU)を1024MBに設定する。CPUはこの値に比例して割り当てられる
aws lambda update-function-configuration \
--function-name my-function \
--memory-size 1024