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.2k
コンテナ目線で考える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
3.1k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
130
Cracking the KubeCon CfP
inductor
2
640
KubeCon Recap -Platform migration at Scale-
inductor
1
1k
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
540
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
29
6.4k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
880
オンラインの技術カンファレンスを安定稼働させるための取り組み / 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
Oracle Cloud Infrastructure IaaS 新機能アップデート 2025/06 - 2025/08
oracle4engineer
PRO
0
110
Create Ruby native extension gem with Go
sue445
0
130
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
10
3.2k
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
640
20250913_JAWS_sysad_kobe
takuyay0ne
2
250
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
120
react-callを使ってダイヤログをいろんなとこで再利用しよう!
shinaps
2
260
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
100
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1.1k
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
470
TS-S205_昨年対比2倍以上の機能追加を実現するデータ基盤プロジェクトでのAI活用について
kaz3284
1
220
IoT x エッジAI - リアルタイ ムAI活用のPoCを今すぐ始め る方法 -
niizawat
0
120
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
140
7.1k
Optimizing for Happiness
mojombo
379
70k
Six Lessons from altMBA
skipperchong
28
4k
How GitHub (no longer) Works
holman
315
140k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Git: the NoSQL Database
bkeepers
PRO
431
66k
We Have a Design System, Now What?
morganepeng
53
7.8k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Writing Fast Ruby
sferik
628
62k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
530
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
113
20k
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