どうも、拓田です。
AWS Lambdaはサーバレスだと聞いて「どうせコンテナで動いているんでしょ」と思っていたら全然違っていたので調べてみてみました。
色々調べてみたらLambdaの実体はコンテナではなくFirecrackerという技術で動くマイクロVMだということがわかった。
またFirecrackerの機能はLambdaの一部でしかなく、Lambdaはどういう役割やアーキテクチャをしているのかわからなかったので、そこら辺を整理してみました。
✅Lambdaはサーバレスで構築できるってことくらいしか知らない
✅Firecrackerとか何なのか知らない
✅そもそもコンテナとマイクロVMの違いすら分からない
こんな方は本記事を読めばLambdaやマイクロVMの事を理解できると思いますので、読んでみてください。
コンテナとマイクロVMの違い
まず前提として、仮想マシン（VM）とコンテナ、またマイクロVMの違いを整理する。
通常の仮想マシン（VM）とは
VMはハードウェアをエミュレーションして独立したOSを動かす。
ホストOS
├── VM-A（独自カーネル・仮想GPU・仮想USB・仮想サウンド…）
├── VM-B（独自カーネル・仮想GPU・仮想USB・仮想サウンド…）
└── VM-C（独自カーネル・仮想GPU・仮想USB・仮想サウンド…）
完全に隔離されているためセキュリティは高いが、起動に数十秒〜数分かかり容量も数GB単位になる。
コンテナとは
コンテナはホストOSのカーネルを共有して動く軽量な実行環境だ。
ホストOS
└── カーネル（共有）
├── コンテナA（アプリAのプロセス）
├── コンテナB（アプリBのプロセス）
└── コンテナC（アプリCのプロセス）
カーネルを共有するため起動が速く軽量だが、後述するセキュリティ上の問題がある。
マイクロVMとは
マイクロVMはVMとコンテナの中間に位置する。
ホストOS
├── マイクロVM-A（削ぎ落としLinuxカーネル＋最小限のデバイス）
├── マイクロVM-B（削ぎ落としLinuxカーネル＋最小限のデバイス）
└── マイクロVM-C（削ぎ落としLinuxカーネル＋最小限のデバイス）
それぞれが独自のカーネルを持ちつつ、不要な機能を徹底的に削ぎ落とすことで軽量化している。
3つの比較
| コンテナ | マイクロVM | 通常のVM | |
|---|---|---|---|
| カーネル | ホストと共有 | 独自（削ぎ落とし済み） | 独自（フル） |
| 起動時間 | 数百ms〜数秒 | 125ms以下 | 数十秒〜数分 |
| 容量 | 軽量 | 数MB | 数GB |
| セキュリティ | カーネル共有のリスクあり | 強い隔離性 | 強い隔離性 |
| 管理 | 自分で管理 | AWSが管理 | 自分で管理 |
Firecracker(マイクロVM)が生まれた経緯：コンテナエスケープ問題
コンテナエスケープとは
Lambdaはサーバレスなので、コンテナでも実現可能だった。
しかしコンテナはカーネルを共有するため、コンテナエスケープというセキュリティ上の脅威が存在したため、マイクロVMが必要になった。
【攻撃の流れ】
コンテナ内でroot権限を獲得
↓
カーネルの脆弱性を突く
↓
ホストOSに脱出（※コンテナエスケープ）
↓
同じカーネルで動く他のコンテナや
ホストマシン自体のroot権限を取得
カーネルを共有しているため、カーネル自体に脆弱性があるとホストサーバ、また全コンテナが影響を受ける。
これはマルチテナント環境（複数のユーザーが同じサーバーを共有する環境）では致命的な問題となる。
Firecrackerによる解決
AWSはこの問題を解決するためにFirecrackerを開発した。
【Firecrackerの場合】
ユーザーAのマイクロVM（独自カーネル）
ユーザーBのマイクロVM（独自カーネル）
ユーザーCのマイクロVM（独自カーネル）
それぞれが独立したカーネルを持つため、仮にエスケープしても他のマイクロVMには影響しない。
カーネルを共有していないため、コンテナエスケープという概念自体が成立しない。
コンテナと比べてもroot権限管理は依然重要
なおFirecrackerでカーネルを分離しても、コンテナ内のroot権限管理は現在も重要なベストプラクティスだ。
・コンテナ内は非rootユーザーで動かす
・必要最小限の権限だけ付与する（最小権限の原則）
・root権限が必要な処理はコンテナ外で行う
Firecrackerはあくまでカーネルレベルの隔離を提供するものであり、アプリケーション層のセキュリティ対策と組み合わせて使うのが現場の実態だ。
Firecrackerのカーネルはどうやって軽量化しているのか
Linuxカーネルは機能を選択してビルドできる仕組みを持っている。
Firecrackerはこれを活用して、Lambda関数の実行に不要な機能を徹底的に削除している。
【削除しているもの（例）】
・USBドライバ
・サウンドドライバ
・GPUドライバ
・Bluetoothスタック
・不要なファイルシステム
【残しているもの】
・ネットワーク機能
・最小限のストレージ
・プロセス管理
・メモリ管理
結果として数MB単位のカーネルで動き、起動時間は125ms以下のコンテナ並みの軽量さを実現している。
Lambdaの実体とアーキテクチャ
コントロールプレーンとデータプレーン
Lambdaは内部的にコントロールプレーンとデータプレーンに分かれている。
【コントロールプレーン】
・関数の作成・更新・削除などの管理API
・AWSの他サービスとの連携（API Gateway等）
・AWSが管理するマイクロサービス群が実体
【データプレーン】
・Lambda関数の実行管理
・マイクロVMの割り当て
・ウォームスタンバイの管理
Lambda Worker
データプレーンの下にはLambda Workerと呼ばれる層がある。
Lambda Workerは顧客からは見えない独立したAWSアカウント上に存在しており、Firecrackerを通じてマイクロVMを実際に起動・実行する。
コントロールプレーン（管理層）
↓
データプレーン（実行管理層）
↓
Lambda Worker（独立AWSアカウント）
└── Firecracker
└── マイクロVM
└── Lambda関数のコード
イベント発火からコード実行までの流れ
■処理の流れ
SQSにメッセージが届く
↓ ①通知
Lambdaコントロールプレーンが検知
↓ ②起動命令
データプレーンがLambda Workerに割り当て
↓ ③マイクロVM起動
FirecrackerがマイクロVMを125ms以下で起動
↓ ④コード実行
Lambda関数が処理を実行
↓ ⑤結果返却
処理完了 → マイクロVMはウォームスタンバイへ
※図には④以降の処理が記載されていません
コールドスタートとウォームスタート
【コールドスタート】
初回またはスケールアウト時に新規マイクロVMを起動
起動時間：125ms以下
【ウォームスタート】
処理後もマイクロVMを一定時間残して再利用
コールドスタートより高速
ネットワーク通信について
LambdaはSSHやtelnetで「中に入る」概念がない。
通信はすべてHTTPSで行われる。
【Lambdaが外部と通信する時】
Lambda関数
↓ HTTPSリクエスト
S3 / DynamoDB / 外部API等
↓ HTTPSレスポンス
Lambda関数に結果が返る
ネットワーク機能はLambdaが持つのではなく、FirecrackerのマイクロVMが持つ機能を使っている。
IPアドレスは起動のたびにAWSがDHCPで自動に割り当て、処理後に返却されるため固定IPは持たない。
固定IPが必要な場合はNATゲートウェイを別途用意する必要がある。
まとめ
- 🔥 Lambdaの実体はコンテナではなくマイクロVM。Firecrackerという技術で動いている
- 🛡️ Firecrackerが生まれた理由はコンテナエスケープ問題。カーネルを共有するコンテナではマルチテナント環境のセキュリティを担保できなかった
- ⚡ マイクロVMはVMとコンテナの中間。独自カーネルを持ちつつ不要な機能を削ぎ落として125ms以下で起動する
- 🏗️ Lambdaはコントロールプレーンとデータプレーンに分かれており、Lambda Workerが実際にFirecrackerを動かしている
- 🌐 ネットワーク機能はFirecrackerのマイクロVMが持つ。LambdaはHTTPS通信のみでSSH・telnetで中に入る概念がない
- 📦 コンテナイメージをLambdaにデプロイできるが、それはマイクロVM上でコンテナランタイムを動かしているだけで、実行環境の実体はあくまでマイクロVMだ
今までなんとなく「サーバレスというのでコンテナっぽいもの」だと思っていたLambdaだが、実はAWSが独自開発したマイクロVMで動いていました。
色々不勉強だったなァと痛感した内容でした。