AWS Lambdaは俺が作った 2023/7/19 クラスメソッド CX事業本部 岩⽥智哉 1

このセッションで話さないこと • みなさんのビジネスに役⽴つ話 • みなさんの開発/運⽤されているシステムを より良いものにするために役⽴つ話 • 仮想化やVMMガチ勢向けのコアな話 2

⾃⼰紹介 3 • CX事業本部 サーバーサイドチーム • ⼤阪オフィス所属 • 2023 Japan AWS Top Engineer • 好きなAWSサービスはAWS Lambda • Firecrackerコントリビューター 岩⽥ 智哉

AWS Lambdaは 俺が作った!! 4

もちろんそんなことはなくて… でも全くの嘘というわけではありません これからその辺の話をしていきます 5 本当にLambdaを作ったワケではなく…

6 AWS Lambdaの舞台裏

AWS Lambdaの舞台裏(簡易版) 7 ハードウェア ホストOS MicroVM Firecracker ゲストOS Lambda Function ʜ

Firecrackerの概要 8 • AWSが開発した OSSのVMM(Virtual Machine Monitor) • Rust製 • Linux KVM(kernel-based virtual machine)を利⽤ • MicroVMを⾼速(125ms)に起動可能 • 仮想化によるメモリのオーバーヘッドは5M以下

AWS Lambdaは Firecrackerに⽀えられている Firecrackerを作っている⼈ それすなわち Lambdaを作っている⼈ 9 つまり…

Firecrackerにコントリビュートすれば 「AWS Lambdaは俺が作った」 と⾃慢して良いのではないか︖ 10 FirecrackerはOSS

11 Firecracker開発の経緯

昔のLambda 12 ホストOS ゲストOS (AWSアカウントA) ゲストOS (AWSアカウントB) Lambda Function (AWSアカウントA) Lambda Function (AWSアカウントB) コンテナ コンテナ コンテナ コンテナ コンテナ

こうでは無い 13 ホストOS ゲストOS (AWSアカウントA,AWDアカウントB,…) Lambda Function (AWSアカウントA) Lambda Function (AWSアカウントB) コンテナ コンテナ コンテナ コンテナ コンテナ

あるいはこうでも無い 14 ホストOS Lambda Function (AWSアカウントA) Lambda Function (AWSアカウントB) コンテナ コンテナ コンテナ コンテナ コンテナ

セキュリティのトレードオフ 15 • AWSにとってセキュリティは最優先事項 • コンテナによる環境分離だけでは不⼗分 • CVE-2019-14271 docker cp コマンドの脆弱性によりホストOSのroot権限が利⽤可能 • CVE-2019-5736 runcの脆弱性によりホストOSのroot権限が利⽤可能 • ゲストOSレベルで環境を分離することでより強 ⼒な環境分離を実現

Firecracker開発以前の課題 セキュリティを重視すると ワークロードの集約率が低くなる 16

セキュリティレベルを担保しつつ 効率よく⼤量のワークロードを集約できる 「うまい、安い、早い」VMMが欲しい… ⾃分たちで作ろう︕︕ 無ければ作ろう 17

Firecrackerのコンセプト 18 USBデバイス、サウンドデバイス、ビデオデバイス … これらは全て不要 • セキュリティが最優先 • FaaSやCaaSの基盤としての役割に特化

Firecrackerを活⽤した多層防御の実現 19 ホストOS Firecracker ゲストOS Lambda Function KVM Jailer Sandbox Inner Sandbox MicroVM VMMによる環境分離 コンテナ型仮想化による環境分離

Firecrackerによるワークロード集約 20 ホストOS アカウントB アカウントC アカウントA アカウントD アカウントE アカウントA アカウントB アカウントC アカウントC アカウントD アカウントA

FargateもFirecracker上に構築されている 21 ワークロードの集約率が上がり、 ⼤幅値下げが実現

FirecrackerでMicroVMを起動する様⼦ 22

23 Firecracker プロジェクト 概要

関連するプロジェクト 24 CrosVM 2017/4 ~ Firecracker 2017/10 ~ Rust-vmm 2018/12 ~ Cloud Hypervisor 2019/5~

Slackワークスペースは誰でも参加可能 25 https://firecracker-microvm.slack.com/

ロードマップはGitHubで確認可能 26 https://github.com/firecracker-microvm/firecracker/projects/13

27 コントリビューション実績紹介

初めてのコントリビューション 28 エラー⽤のenumが thiserror::Errorを使うように修正

Good first issue発⾒︕︕ 29 re:inventが間近に迫った2022年11⽉ Lambdaのスナップショットサポートが気になり Firecrackerのリポジトリを覗きに⾏く 「Good first issue 」のついたissueを発⾒

thiserrorを使ってリファクタリング 30 これを こうしただけ

4つのPRがマージ 31

ちょっと裏話 32 東京リージョンでa1.metalインスタンスの起動 に⼿間取っている間に他の⼈に先を越される ※InsufficientInstanceCapacity

ドキュメントの記述ミス修正 33 ドキュメントの 記述ミスを修正

ドキュメントの記述ミス修正 34 Dockerイメージのタグが間違っていたのを修正

Blackの除外ルール調整 35 Pythonのコードフォーマッター Blackの除外ルール調整

Blackの除外ルール調整 36 • FirecrackerのintegrationテストはPythonで実装されている • PythonのコードはBlackでフーマット • integration_tests/build配下のコードがフォーマットされない

Blackの除外ルール調整 37 • Blackは特定のディレクトリ配下のコードをフォーマットしない • デフォルトだと`build`ディレクトリは対象外 • pyproject.tomlに独⾃ルールを定義して対応完了

38 integrationテストの 重複コード削除

integrationテストの重複コード削除 39 • テスト実⾏環境のカーネルバージョンを取得する関数が重複 • 重複定義を削除し、全てのテストケースが単⼀の `get_kernel_version`を利⽤するように修正

重複していたコード 40

おまけ 41 コンテナイメージのスリム化 ※マージされず

コンテナイメージのスリム化 42 • 開発⽤コンテナイメージの/tmpにゴミが残っていた • Ubuntu18→Ubuntu22へのアップグレードに合わせてCLOSE • もう少し早くPR上げていればマージされていたかも︖

つまり… 43 Firecrackerコントリビューターとかいいつつ 実は何も⼤したことをしていない Rustや仮想化の知識が無くても Firecrackerにコントリビュートできる︕︕

44 Firecracker に コントリビューションしてみよう︕

まずは開発環境の構築 45 • 何はともあれまずは開発環境の構築 • Firecrackerの動作にはKVMが必須 • 開発環境から/dev/kvmが⾒える必要がある

適当な物理マシンを⽤意する 46 • 適当な物理マシンが⽤意してLinuxをインストールする • 物理マシンが余っていればFirecracker開発環境として転⽣ • ドゥアルブートさせるもよし • ⼀応ラズパイ4でもいけるはず… https://dev.classmethod.jp/articles/firecracker-with-raspi4b/

パブリッククラウドを使う 47 • AWSならi3.metal等が利⽤可能 • ベアメタルインスタンスなので⾼い… • a1.metalはサポート対象外(とはいえ多分動く) • Google CloudのCompute Engineを使う • Nested Virtualizationが使える︕︕ • Intel Haswell以降のプロセッサが必要なので注意

ローカルマシンで仮想化ソフトウェアを使う 48 • Nested Virtualizationに対応したソフトウェアを導⼊ • VMware Fusion • 有償 • Virtual Box • 6.1.0からIntel CPUのNested Virtualizationに対応

開発環境のLinux OSが準備できたら 49 • ソースコードをクローン • git clone https://github.com/firecracker-microvm/firecracker.git • Docker環境の準備 • 開発⽤のコンテナをpull • docker pull public.ecr.aws/firecracker/fcuvm • ./tools/devtool shell 等

Devctrについて 50 • Firecracker開発⽤のコンテナイメージ • メージはECR Publicで公開 • Rust等の必要な環境構築済み

オススメツール 51 • VS CodeのExtension Remote Developmentがオススメ • Remote – SSHで開発環境に接続 • Dev Containersで開発⽤のコンテナといい感じに連携

devcontainer.jsonの設定例 52 KVMが必須なので特権モードで VS Code⽤にrust-analyzerを導⼊

うまく設定できたら… 53 ⼊⼒補完が効いて”Run Test”がポチれるようになればOK

54 Issueを探そう

何もともあれGood first issueだが… 55 Good first issue付きのissueはだいたいPR作成済み/マージ済み

たまに簡単なissueも起票される 56 • issueをwatchしておくと気付けるかも • 即座に「やりたいです︕」と意思表⽰すればチャンスがあるかも

このissueがとっかかりにできそう 57 • TODOコメントが付いている箇所から探してみよう • CrosVMやCloud Hypervisorのコードをポーティングできないか︖ https://github.com/firecracker-microvm/firecracker/issues/3273

58 開発時のTIPS

./tools/devtoolで便利コマンドを実⾏ 59 ./tools/devtool --help Firecracker devtool Usage: devtool [] [] Global arguments -y, --unattended Run unattended. Assume the user would always answer "yes" to any confirmation prompt. Available commands: build [--debug|--release] [-l|--libc musl|gnu] [-- []] Build the Firecracker binaries. Firecracker is built using the Rust build system (cargo). All arguments after -- will be passed through to cargo. --debug Build the debug binaries. This is the default. --release Build the release binaries. -l, --libc musl|gnu Choose the libc flavor against which Firecracker will be linked. Default is musl. --ssh-keys Provide the paths to the public and private SSH keys on the host (in this particular order) required for the git authentication. It is mandatory that both keys are specified. …略

ユニットテストもpytest経由で実⾏ 60 • pytest ./tests/integration_tests/build/test_unittests.py • ./tools/devtool test -- integration_tests/build/test_unittests.py ユニットテストの実⾏はcargo testではない pytest経由で呼び出すことでcargo testの諸々のオプションが 適切に設定される

コミット時の注意事項 61 git commitするときは -s オプションを We require that every contribution to Firecracker is signed with a Developer Certificate of Origin. DCO checks are enabled via https://github.com/apps/dco, and your PR will fail CI without it. https://github.com/firecracker-microvm/firecracker/blob/main/CONTRIBUTING.md

コミットメッセージのチェック 62 • コミットしたらgitlintでチェック • pytest integration_tests/style/test_gitlint.py • tools/devtool test integration_tests/style/test_gitlint.py

カバレッジの調整 63 • ユニットテストのカバレッジは事前定義された値 と差分が0.05%以内である必要がある • CIの結果を⾒て調整 tests/integration_tests/build/test_coverage.py

64 まとめ

このセッションで⾔いたかったこと 65 • RustやVMMの知識が無くてもLambda愛があれ ばFirecrackerにコントリビュートできる • ⼀歩踏み出してコントリビュートしてみよう • 「AWS Lambdaは俺が作った」と⾔ってみよう

ありがとう ございました 66