Firecracker のソースを読んでみた 古賀信哉 株式会社アットマークテクノ ※LT のスライドに加筆した版 

なんで Firecracker？ この頃 AWS Lambda を使っているから Lambda の仕組みに興味が湧いたから extension の実装を試して気づいたこと Rust で実装されている VMM だから 「カーネルランド Rust 勉強会」のネタ探し 

AWS Lambda と Firecracker AWS Lambda の実行環境 関数／ハンドラ Lambda ランタイム 言語ランタイム（Node.js, Python, Java, .NET, Ruby) OS (Amazon Linux): ルートファイルシステム OS (Amazon Linux): カーネル + ユーザーランド ??? 仮想サーバー（EC2 Bare Metal） 物理サーバー AWS がメンテナンス／責任を持つ コンテナイメージ 実行時にコンテナ内に 展開される 

AWS Lambda と Firecracker AWS Lambda の実行環境 関数／ハンドラ Lambda ランタイム 言語ランタイム（Node.js, Python, Java, .NET, Ruby) OS (Amazon Linux): ルートファイルシステム OS (Amazon Linux): カーネル + ユーザーランド Firecracker (MicroVM + VMM) ?? 仮想サーバー（EC2 Bare Metal） 物理サーバー AWS がメンテナンス／責任を持つ コンテナイメージ 

AWS Lambda と Firecracker AWS Lambda の実行環境 関数／ハンドラ Lambda ランタイム 言語ランタイム（Node.js, Python, Java, .NET, Ruby) OS (Amazon Linux): ルートファイルシステム OS (Amazon Linux): カーネル + ユーザーランド Firecracker (MicroVM + VMM) 仮想サーバー（EC2 Bare Metal） 物理サーバー AWS がメンテナンス／責任を持つ コンテナイメージ N:1 1:1 

AWS Lambda と Firecracker AWS Lambda の実行環境 関数／ハンドラ Lambda ランタイム 言語ランタイム（Node.js, Python, Java, .NET, Ruby) OS (Amazon Linux): ルートファイルシステム OS (Amazon Linux): カーネル + ユーザーランド Firecracker (MicroVM + VMM) 仮想サーバー（EC2 Bare Metal） 物理サーバー AWS がメンテナンス／責任を持つ コンテナイメージ N:1 1:1 

AWS Lambda の動作モデル 外部からのリクエストが届くと起動 Lambda サービスがランタイムを生成・起動 既に起動済みのものがあれば再利用 リクエストを処理し終えると停止 スタンバイ状態：CPU を全く使わない しばらく経つと自動解放 Lambda サービスがランタイムを破棄 

AWS Lambda の動作モデル 外部からのリクエストが届くと起動 Lambda サービスがランタイムを生成・起動 既に起動済みのものがあれば再利用 リクエストを処理し終えると停止 スタンバイ状態：CPU を全く使わない しばらく経つと自動解放 Lambda サービスがランタイムを破棄 関数／ハンドラとは別のプロセス (extension) を作って動かしても止まる！ 

AWS Lambda の動作モデル 外部からのリクエストが届くと起動 Lambda サービスがランタイムを生成・起動 既に起動済みのものがあれば再利用 リクエストを処理し終えると停止 スタンバイ状態：CPU を全く使わない しばらく経つと自動解放 Lambda サービスがランタイムを破棄 関数／ハンドラとは別のプロセス (extension) を作って動かしても止まる！ “pause” なので、/tmp のファイルや、メモリ内容（: 大域変数）が残る。 

AWS Lambda の動作モデル 外部からのリクエストが届くと起動 Lambda サービスがランタイムを生成・起動 既に起動済みのものがあれば再利用 リクエストを処理し終えると停止 スタンバイ状態：CPU を全く使わない しばらく経つと自動解放 Lambda サービスがランタイムを破棄 関数／ハンドラとは別のプロセス (extension) を作って動かしても止まる！ “pause” なので、/tmp のファイルや、メモリ内容（: 大域変数）が残る。 次のリクエストでキャッシュとして利用することも可能！ （※ランタイムが破棄されて新たに生成されるまでの間） 

AWS Lambda の動作モデル 外部からのリクエストが届くと起動 Lambda サービスがランタイムを生成・起動 既に起動済みのものがあれば再利用 リクエストを処理し終えると停止 スタンバイ状態：CPU を全く使わない しばらく経つと自動解放 Lambda サービスがランタイムを破棄 関数／ハンドラとは別のプロセス (extension) を作って動かしても止まる！ “pause” なので、/tmp のファイルや、メモリ内容（: 大域変数）が残る。 次のリクエストでキャッシュとして利用することも可能！ （※ランタイムが破棄されて新たに生成されるまでの間） ただし、リクエストの実行中に別のリクエストが届くと、自動的に 新たなランタイムが生成・起動されて同時実行される。そのことは 考慮すべし。 ※DynamoDB など、他サービス上の永続データをキャッシュする 場合は、分散並列環境であることを正しく意識しなければならない。 

Firecracker のソース https://github.com/firecracker-microvm/firecracker ソースツリー 

Firecracker のソース https://github.com/firecracker-microvm/firecracker ソースツリー MicroVM の pause/resume の動きは、 この二つが責務を担っている。 

Firecracker のソース 主要な登場人物／エンティティ Vmm (vmm/src/lib.rs) Vm / ArchVm VcpuHandle / Vcpu Kvm vmm/src/vstate/ と vmm/src/arch/{aarch64,x86_64}/ ApiServer (firecracker/src/api_server/mod.rs) jailer 

Firecracker のソース 主要な登場人物／エンティティ Vmm (vmm/src/lib.rs) Vm / ArchVm VcpuHandle / Vcpu Kvm vmm/src/vstate/ と vmm/src/arch/{aarch64,x86_64}/ ApiServer (firecracker/src/api_server/mod.rs) jailer Virtual Machin Monitor としての Firecracker の メインモジュール MicroVM（仮想マシン）と仮想 CPU KVM に対するインタフェース Lambda サービスから制御するための REST API を提供（？） pivot_root による隔離用 

Firecracker のソース 主な動きに対するソース src/firecracker/src/api_server/mod.rs src/vmm/src/rpc_interface.rs src/vmm/src/lib.rs (Vmm) src/vmm/src/vstate/vcpu.rs (VcpuHandle) src/vmm/src/utils/sm.rs (StateMachine) vsock (AF_VSOCK) なソケットで通信 Vmm は、ApiServer から Vm の pause/resume リクエストを受け取り、 MicroVM に割り当てている VCPU（個数は構成次第）を制御する。 

Firecracker のソース 主な動きに対するソース src/firecracker/src/api_server/mod.rs src/vmm/src/rpc_interface.rs src/vmm/src/lib.rs (Vmm) src/vmm/src/vstate/vcpu.rs (VcpuHandle) src/vmm/src/utils/sm.rs (StateMachine) vsock (AF_VSOCK) なソケットで通信 Vmm は、ApiServer から Vm の pause/resume リクエストを受け取り、 MicroVM に割り当てている VCPU（個数は構成次第）を制御する。 ※UNIX ドメインソケット上に vsock の多重チャネルを構築する 仕組みが実装されている。 

ソースを眺めた感想 「エッジ側でも使えないかな」 「そこそこ大きなソースは参考になる」 関連して調べることが出てきて面白い 

自己紹介 現在の会社（2021/04～） 株式会社アットマークテクノ 「めんどくさいところ」担当 プライベートの活動 GitHub : https://github.com/Shin-yaKoga SlideShare : https://www.slideshare.net/ShinyaKoga X : @shkoga ET ロボコン北海道地区大会実行委員 最近: IoT デバイス監視・運用サービス（Armadillo Twin） 引っ越し先: SpeakerDeck