Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unike...
Search
Kohei Ota
June 06, 2020
Technology
7
5.1k
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world
Kohei Ota
June 06, 2020
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers
inductor
4
3k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
130
Cracking the KubeCon CfP
inductor
2
630
KubeCon Recap -Platform migration at Scale-
inductor
1
1k
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
530
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
28
6.4k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
860
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.3k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
22
6.5k
Other Decks in Technology
See All in Technology
Kiroでインフラ要件定義~テスト を実施してみた
nagisa53
3
360
薬屋のひとりごとにみるトラブルシューティング
tomokusaba
0
330
猫でもわかるQ_CLI(CDK開発編)+ちょっとだけKiro
kentapapa
0
3.5k
AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAIエージェント実践入門(Findyランチセッション)
smiyawaki0820
6
1.1k
AIに頼りすぎない新人育成術
cuebic9bic
3
310
10年以上続くプロダクトで今取り組んでること、取り組もうとしていること
sansantech
PRO
2
110
開発 × 生成AI × コミュニケーション:GENDAの開発現場で感じたコミュニケーションの変化 / GENDA Tech Talk #1
genda
0
230
Claude Codeは仕様駆動の夢を見ない
gotalab555
23
6.6k
Bet "Bet AI" - Accelerating Our AI Journey #BetAIDay
layerx
PRO
4
1.7k
ファッションコーディネートアプリ「WEAR」における、Vertex AI Vector Searchを利用したレコメンド機能の開発・運用で得られたノウハウの紹介
zozotech
PRO
0
320
「AIと一緒にやる」が当たり前になるまでの奮闘記
kakehashi
PRO
3
150
Strands Agents & Bedrock AgentCoreを1分でおさらい
minorun365
PRO
8
330
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Into the Great Unknown - MozCon
thekraken
40
2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Visualization
eitanlees
146
16k
Rails Girls Zürich Keynote
gr2m
95
14k
KATA
mclloyd
32
14k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
How STYLIGHT went responsive
nonsquared
100
5.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
The Invisible Side of Design
smashingmag
301
51k
Transcript
コンテナ目線で考えるUnikernelと microVM Kernel/VM/探検隊online part1 Presented by @inductor
自己紹介
自己紹介 名前: 太田 航平 (@inductor) 所属: HPE (Hewlett Packard Enterprise)
役職: ソリューションアーキテクト (Cloud Native and DevOps) Docker MeetupとかCloud Native Daysの運営、謎のアンバサダー業 好きなこと: 無限にスケールする(無限にスケールするとは言ってない)インフラ
宣伝 ブログで気が向いたときに論文の 翻訳的なことをやったりしてます (権利関係がめんどくさくてあまり 進めていない)
コンテナの仕組み
コンテナの仕組み 雑に言えばすごいchroot → 特定のディレクトリをルートディレクトリに見立てて仕切りを作る技術 例: ホスト上の /var/docker/container1 をルートにしてそれ以下で別のOSが動くため の環境を作るみたいなことができる 隔離したファイルシステムに対してnamespaceで分離したユーザー、プロセス、NWな
どを割り当て、cgroupsで利用できるリソース量を制限すると、まるでVMみたいなもの をプロセスの単位で作れるみたいなやつ
Dockerがもたらした変革 システム領域としてコンテナを利用することは(Linuxに限らず)前からあった DockerがもたらしたDockerfile、Dockerイメージというパッケージング技術と、それを 配布するための仕組みが開発者にとって親和性が高く、アプリケーションを内包する ファイルシステムの共有を簡単に行えるようになった Dockerはtarで固められたレイヤー状のFSをpivot_rootで区切られた空間上で展開 し、ホストOS上でプロセスとして動かすところまでを全部いい感じにした
Dockerが使う低レベルランタイム runCの仕組み(おさらい)
runCの仕組み ホストマシン Linuxカーネル コンテナ コンテナ コンテナ runC Docker & CRI
ファイルシステムの展開 プロセスの初期化 イメージの管理
runCの仕組み ホストOS、カーネルはマシンごとに共通 DockerまたはCRIから受けた命令をもとにカーネルに命令を送ってコンテナの実態で あるリソースの隔離を行い、アプリケーションを実行する 普通にやるとホストOSの特権が必要 → runCの脆弱性が見つかるととても危ない
MicroVM
microVMとは 軽量かつ起動が高速で、動的に生成削除されるVMのこと → マイクロ仮想化(Micro-Virtualization)技術で使われるVM Amazonが作っているFirecrackerがOSSとしては有名 → Rust製で125ms程度の速さで起動するのが特徴 ここからはFirecracker前提で話を進めます
microVMの仕組み ホストOS microVM microVM microVM Firecracker CLI or REST Client
ゲストOS ゲストOS ゲストOS
コンテナでの利用例 Firecracker-containerd と組み合わせる → Firecracker上のrunCとcontainerdを組み合わせて動かすためのOSS 軽量なVM + Dockerよりも軽量なcontainerdの組み合わせによって Dockerイメージを動かすことができる Fargateと呼ばれるAWSの仮想化技術もこれに準拠したものが使われている
Ref. https://aws.amazon.com/jp/blogs/news/under-the-hood-fargate-data-plane/
コンテナでの利用例 ホストOS microVM microVM microVM Firecracker + runC + containerd
CLI or REST Client ゲストOS ゲストOS ゲストOS コンテナ ランタイム コンテナ ランタイム コンテナ ランタイム
microVMのメリット・デメリット 既存のVM技術と比べリソースの割当が柔軟で動的 → REST APIでVMの操作が可能、起動が高速なのでスケールも速い VMであることに変わりはないのでホスト環境との隔離性が高い VMレイヤの起動オーバーヘッドなどが無視できない要件の環境だと厳しい
Unikernel
Unikernelとは Library OSを用いて特定のアプリケーションに必要なコンポーネントだけを内包した空 間を分離する技術 → カーネルで使わない機能すら排除して、余計なものを入れないという考え方 Library OS、それすなわち、OSがライブラリとして機能する(必要なものだけを入れたも のになる)という本当に最低限の動作環境なのでセキュア・軽量・高速
コンテナでの利用例 IBMが作っているNabla ContainersプロジェクトではUnikernelを採用 低レベルコンテナランタイムとしてRunncを使う → Seccompで使えるシステムコールを制限 → Library OSを使って必要なコンポーネントのみを入れる Unikernelの特性上通常のDockerイメージが使えない
→ ランタイムが使うunikernelのバイナリをイメージに組み込む必要があるため ここからはRunnc(Nabla Containers)前提で話を進めます
Unikernelの仕組み ホストOS Runnc ホスト上のnabla run tender が専用にコンパイルされたア プリのバイナリを読み出して 実行
Unikernelのメリット・デメリット VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高 速 不要なカーネルの機能は含まれないため、ホストとの接地点が少ない Unikernelの技術自体の知名度が低く、知見があまりない + Runncというものを導入するハードルの高さ イメージのビルド環境が特殊でフォーマットの互換性もない
Appendix: gVisorとの違い gVisor(Runsc)はユーザー領域にカーネルを再実装したものを展開し、 あたかもそれがシステム領域であるかのように動作する仕組みになっている Unikernelと違ってDockerベースのイメージが動き、Containerdも動作するが、その 下にいるgVisorがLinuxカーネルのフリをして動くことによってホストとの環境を分離 している
Appendix: Kata Containerとの違い Kata ContainerはContainerdなどのランタイムから命令を受けたあと、namespace やcgroupsを使う代わりにQEMU/FirecrackerベースのVMを立ち上げ、その上にコン テナを展開する つまり、runCと同様にOCIのインターフェースを持ちコンテナの起動などを 行うが、実際にコンテナが動く環境がKVMで作られたVMになる
今選ぶならどれ? Runnc(Nabla Container)は最近開発がストップしている → どうやらLupine Linuxという新しい仕組みに夢中のよう 今度のKubeCon Virtualで発表があるようなので楽しみ 論文も春に公開されてて、雰囲気で読んだ(そのうちまた解説を書く) Runsc(gVisor)+高レベルランタイムとFirecracker+Firecracker-containerdが有力だ
が、気軽にサンドボックス環境を楽しみたいなら前者、カーネルの互換性を保ちたい なら後者がよさそう(?) ※参考: GCPのCloud RunはgVisorを、FargateはFirecrackerをそれぞれ使用
結論: どっちもどっち(暴論)
結論: 課題を感じなければ 多分Dockerでも大丈夫
まとめ Dockerで使われるrunCには特権を渡す必要がありコンテナ間の隔離性が低いなど の問題がある MicroVMでは隔離性は高いが起動時の遅延がシビアになりやすい Unikernelでは高いパフォーマンスと隔離性の代わりに汎用性が低くなりやすい 要件に合わせていろいろなスタックを組み合わせて使うことで様々な問題を解決する アプローチが現在進行系で(アカデミックな場でも)提案されている
ご意見お待ちしております ありがとうございました!
参考資料 KubeCon 報告:コンテナランタイムやFirecrackerの話題ひととおり 振り返ってみよう by 徳永航平さん https://www.slideshare.net/KoheiTokunaga/kubecon-firecracker makocchiさんのスライドいろいろ https://speakerdeck.com/makocchi/ A
Linux in Unikernel Clothing @ EuroSys '20 Firecracker: Lightweight Virtualization for Serverless Applications