高速にコンテナを起動できるイメージフォーマット (NTT Tech Conference #2)

Copyright©2017 NTT Corp. All Rights Reserved.
日本電信電話(株)
ソフトウェアイノベーションセンタ
須田瑛大
<suda.akihiro@lab.ntt.co.jp>
高速にコンテナを起動できる
イメージフォーマット
NTT Tech Conference #2 (2017/8/10)
スライド: https://www.slideshare.net/AkihiroSuda

2
• 新卒 4年目
• GitHub: @AkihiroSuda / Twitter: @_AkihiroSuda_
• コンテナ関連OSSのメンテナ(所謂コミッタ)
• Docker Moby Core メンテナ
• BuildKit イニシャルメンテナ (github.com/moby/buildkit)
• 次世代 `docker build` (DockerfileをDAG化し並行実行)
• またの機会にこちらについても詳しく..
自己紹介
2017年4月，DockerプロジェクトはMobyプロジェクトに移行した．
Mobyプロジェクトの成果物を元として，Docker製品が開発されている．
: ≒ :
RHEL Fedora

3
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE，137MBでJDK
• その他，重複除去などの利点もあり
• OCI標準仕様との互換性を重視
お話しする内容

4
• Dockerとは
• Docker・OCIイメージの構成・問題
• 提案するイメージフォーマット
• 今後の技術的・コミュニティ的な取り組み方針
• デモ (時間があれば)
アウトライン

5
Dockerとは
• いわゆるコンテナ型仮想化基盤
• 仮想マシンより軽い
• イメージの作成・共有が簡単
• 昔のjailなどとの大きな違い
• 分散実行にも対応
• 標準: Swarm-mode / 3rd party: Kubernetes など
FROM ubuntu:17.04
RUN apt-get install foobar
COPY foobar.conf /etc
Dockerfileをコミットする
イメージがビルドされる
クラスタにデプロイできる

6
• Linuxカーネルが備えるcgroups・namespaceと，Copy-on-Write
(CoW)ファイルシステムとを組み合わせて実装されている
• AUFS, OverlayFS, BtrFS, ZFSに対応．DeviceMapperでのCoWにも対応．
• 対応しているディストリビューションや，安定性などの特性が違う
• Dockerfileの1行毎にCoWレイヤーが生成される
• イメージサイズは小さく抑えるのが鉄則 (VMとは使い勝手が違う)
• 小さいイメージを多数組み合わせて，マイクロサービス化する
• とは言っても，現実にはなかなか小さくしにくいものである
• 小さくしやすくする試みとしては，OracleのMicrocontainer (Smith)などが最近出てきている
Dockerとは
FROM ubuntu:17.04
mount –t overlay –o lowerdir=0,upperdir=1 ..

7
• DockerのCoWレイヤは，AUFSレイヤを固めたtarファイルとしてイメー
ジ化される
• 実際のCoWファイルシステムがOverlayFSでもDeviceMapperでも，AUFSレイヤー
のtarとして表現される
• QCOW2など，ハイパーバイザ用のブロックレベルのCoW技術とは対照的
Docker・OCIイメージの構成
後で説明します
TAR
TAR
FROM ubuntu:17.04
ベースレイヤは普通のtar
• 追加・変更されたファイル
• 削除されたファイルの情報
(whiteoutファイル)
TAR
/bin/bash
/bin/ls ...
/usr/bin/foobar
/usr/lib/libfoobar.so ...
/etc/foobar.conf

8
• TARファイルや，環境変数のJSONなどが，merkle tree構造を持つblob
ストアに格納される
• 一般にDocker Registryを用いて配信する．(バックエンドはS3やSwiftなど)
{
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 7143,
"digest":
"sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f"
}
}
/index.json
/blobs/sha256/e692418e...
... (次スライド)
JSON
JSON

9
{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"size": 7023,
"digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 33554432,
"digest": "sha256:61be55a8e2f6b4e172338bddf184d6dbee29c98853e0a0485ecee7f27b9af0b4"
},
{
"size": 1073741824,
"digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b"
},
{
"size": 73109,
"digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"
}
]
}
/blobs/sha256/b5b2b2c5...
(環境変数などのJSON)
/blobs/sha256/61be55a8...
(ベースレイヤのtar)
/blobs/sha256/3c3a4604...
(差分レイヤのtar)
/blobs/sha256/ec4b8955...
(更なる差分レイヤのtar)
TAR
TAR
TAR
JSON
JSON

10
• merkle tree構造を持っているので，manifestのSHA256値を指定すれば，
確実に環境を再現できる
(`docker pull foobar@sha256:e692418e..`)
/index.json
/blobs/sha256/b5b2b2c5...
/blobs/sha256/61be55a8...
/blobs/sha256/3c3a4604...
/blobs/sha256/ec4b8955...
Index
Manifest
環境変数などのconfig
AUFSレイヤのtar群
merkle tree

11
• 2017年7月，Linux Foundation傘下のOpen Containers Initiative
によりOCIイメージ仕様の策定完了
• CoreOS陣営が提案していたappc・ACIもOCIに合流した
• データ構造はDockerイメージと類似しており，高い互換性を持つが，
Docker Registry HTTP APIに依存しなくなった．
HTTP, NFS, IPFSなど，ディレクトリ的なセマンティックを持つ任意のプ
ロトコルで配信可能．
• 個人的にはIPFSなどP2Pを用いたイメージ配信に期待
• Dockerでも，近々正式に実装予定．
• ※混同に注意: Dockerfileの構文・命令が標準化されたわけではない
OCIイメージ≒Dockerイメージ

12
• tar = Tape ARchiverが現れたのは1979年 (UNIX 7th Edition)
• 磁気テープ前提のフォーマットのため，本来はDocker・OCIのユースケース
に合っていない
Docker・OCIイメージの問題
1970年代のUNIXがターゲットとしていた
PDP-11 ミニコンピュータ &
磁気テープドライブ
https://en.wikipedia.org/wiki/PDP-11

13
• tar内のファイルの一覧がわからない
⇒テープ全体を読み終わるまでmountできない
• ファイルがどのオフセットにあるかわからない
(tarとは別に索引を作成したとしても，
tarがgzipなどで圧縮されていると，
どのみちseekできない)
問題1: 「テープ」全体を走査しないとメタデータを取得できない
メタデータ0
ファイル0
メタデータ1
ファイル2
メタデータ{n-1}
ファイル{n-1}
終端 zero (1024B)
...
ファイル名や
パーミッションなど
ファイル内容

14
問題1: 「テープ」全体を走査しないとメタデータを取得できない
この問題が解決できれば，メタデータだけpullした時点でmount(2)しておき，
ファイル本体はread(2)が発生した時点でlazyにpullできるようになる!
• 巨大なコンテナイメージを多数のノードに配信する場合，起動時間短縮・ネッ
トワーク負荷軽減できて嬉しい
ユースケース
• 大量のHTMLや画像ファイルを含むWebアプリケーション
• 様々なビッグデータとコードとをひとまとめにしたイメージ
• 論文を`docker run foo@sha256:deadbeef..` 1発で確実に再現できる世界
になると嬉しい
• 巨大なOS (GNOME・KDE入りの仮想デスクトップ環境や，Windowsなど)
• 巨大な言語ランタイム (Java，.NETなど)
• 複数のソフトウェアを結合試験する環境など

15
• 1つのレジストリで，複数の似たようなイメージを配信することを考える
• バージョン違い
• アーキテクチャ違い
• 設定違いなど
• 同じファイルを多数含むtarであっても，別々のblobになるため，ストレ
ージが無駄になる
問題2: blobの重複を除去できない
FROM ubuntu:17.04
RUN apt-get install foo
FROM ubuntu:17.04
RUN apt-get install foo bar
FROM debian:9
FROM ubuntu:17.04
RUN echo … > /etc/apt/source.list
同じファイルを多数含んでいるが別物

16
• 巨大なtarレイヤのblobは，複数のrangeに分けて，複数のコネクション
を使って並列にpullしたい
• 複数のサーバを利用できる場合，短時間でのpull完了が見込まれる
• しかし任意のプロトコルで可能なわけではない
• HTTP/1.1 Range Requestsは RFC7233 にてOPTIONALとされている
問題3: 一般に，単一レイヤを分割して並列にpullできない
Range 0-1023 Range 1024-2047

17
1. 「テープ」全体を走査しないとメタデータを取得できない
2. 重複除去できない
3. 一般に，単一レイヤを分割して並列にpullできない
Docker・OCIイメージの問題まとめ

18
提案するイメージフォーマット
FILEgrain(仮称) https://github.com/AkihiroSuda/filegrain

19
• 単一のtar blobを，ファイル毎に別個のblobに崩す
• 各ファイルのSHA256ダイジェストをメタデータに記載しcontent-addressableにする
• メタデータのblobさえpullすれば，getdents(2)やstat(2)できるので，
イメージ全体をpullせず，mount(2)・コンテナ起動可能
• read(2)が発生した段階で初めて，lazyにpullすればよい
提案するイメージフォーマットの概略
メタデータ0
ファイル0
メタデータ1
ファイル2
ファイル{n-1}
終端 zero (1024B)
...
メタデータ0 ファイル0
メタデータ1
ファイル2
メタデータ{n-1} ファイル{n-1}
...
TAR
continuity ファイル名，パーミッション，
SHA256ダイジェストなど
content-addressable

20
• メタデータはcontinuityで表現する
• continuity.. containerdコミュニティで提案されている，ファイルシステ
ムメタデータ記述フォーマット
(https://github.com/containerd/continuity)
• ファイル名，パーミッション，xattr(7)，ダイジェスト値などをProtocolBuffers形式で
シリアライズする
• 次世代containerd(下位ランタイム)のテストで使われているほか，
Docker・Mobyでもイメージ検証に使う案がある (moby-core#32153)
• 類似フォーマットにBSDのmtree(8)がある
• 将来的にcontainerdに統合したいので，containerdコミュニティ系のcontinuityにした
• containerdコミュニティについては最後の方のスライドで説明
(Docker・Kubernetes共通の次世代ランタイム)
メタデータのフォーマット

21
• 単一のOCIイメージ中に，普通のOCIマニフェストと，提案フォーマットのマ
ニフェストの両方を格納できる
• ⇒提案フォーマットに対応・未対応のソフトウェアを容易に共存させることができる
OCIイメージとの互換性を重視
/index.json
/blobs/sha256/e692...
/blobs/sha256/b5b2... /blobs/sha256/61be...
/blobs/sha256/3c3a...
/blobs/sha256/ec4b...
Index
OCI Manifest
環境変数などのconfig (共通)
AUFSレイヤのtar群
/blobs/sha256/a8e3...
提案フォーマットのManifest
/blobs/sha256/de81...
continuity
/blobs/sha256/583f...
/blobs/sha256/3af1...
/blobs/sha256/5c2a...
/blobs/sha256/39c1...
/blobs/sha256/12ea... ばらされたファイル群(大量)
`docker pull foo:v1-filegrain` `docker pull foo:v1`
{"v1-filegrain": "sha256:a8e3..", "v1":"sha256:e692.."}

22
• 普通のOCIのtarレイヤに，提案フォーマットのレイヤを重ね合わせること
ができるので，欠点を補い合うことができる
• 細かい大量のファイルは普通のtarにまとめるほうが，I/Oが1回で済むし，圧縮率向上
も期待できるので，速い場合もある
OCIイメージとの互換性を重視
{
...
"layers": [
{
"size": 33554432,
"digest": "sha256:e692..."
},
{
"mediaType": "application/vnd.continuity.layer.v0+pb",
"size": 16724,
"digest": "sha256:a18b..."
}
]
}
TAR
continuity
頻繁に使うファイルや，
細かいファイルは
普通のOCIのレイヤ
(pullし終わるまでコンテナ
を起動できない)
かさばるファイルは提案フォーマットのレイヤ
(lazyにpullできるが細かいファイルに不向き)

23
問題1.「テープ」全体を走査しないとメタデータを取得できない
⇒ continuityのblobだけpullすればメタデータを取得できる．
ファイル本体をpullする前にmount・コンテナ起動可能．
問題2. 重複除去できない
⇒ ファイルを細かいblobにばらしたので，同じファイルを含むレイヤは自
ずと重複除去される
問題3. 一般に，単一レイヤを分割して並列にpullできない
⇒ ファイルを細かいblobにばらしたので，並列にpullできる
Docker・OCIイメージの問題を解決できる

24
評価

25
• read-onlyなFUSEファイルシステムとして実装
• 将来的にもread-onlyのままのつもり
• コンテナはVMとは違い，immutableにするのが鉄則．/tmp, /runとパーシステントボ
リューム以外への書き込みは行うべきではない．
• /tmpや/runは一般にtmpfsを別途マウントする
• パーシステントボリュームは，ホスト側のext4やXFSをbind-mountする
• 実際，OverlayFSやAUFSも書き込み操作のサポートは限定的
(https://github.com/AkihiroSuda/docker-issues)
• 1つのファイルに対してROなfdとRWなfdを両方openし，書き込むと，ROな方が意図しない
結果を返す．(yumなど実際のアプリケーションに影響するが，バグではなくoverlayの仕様)
• 今のところ，Dockerは任意にmountされたrootfsを使えないので，
Dockerそのものには統合できていない．runc (Docker, containerdの下
位ランタイム)を用いて評価した．
実装

26
評価に用いたイメージ
イメージ説明 rootfs
(tar+gzip展開後)
openjdk:8
sha256:5da842d59f76009fa27ffde06888ebd
560c7ad17607d7cd1e52fc0757c9a45fb
Debian 9.1, OpenJDK 8u141 671.7MB
kdeneon/all
sha256:e3e7f216a5f8f1fdcff4eab8807d7af
cd291c050099ab3e8a8355b7b28a19247
Ubuntu 16.04, KDE Plasma 5.10,
Firefox 54など
4.8GB
kaggle/python
sha256:335103c998aea22a5608c2eeca7dcf1
09e0828ed233b75f5098182c5b058fe98
Debian 8.5, 様々な機械学習フレー
ムワーク, NLTKデータセット(自然
言語関連)など
8.3GB
※詳細な再現手順は https://github.com/AkihiroSuda/filegrain/issues/17 に掲載．

27
• openjdk:8 (総blob容量 = 671.7MB + メタ 5.4MB)
• マウント: 5.4MB ( 2 blobs)
• イメージ本体のblobではなく，メタデータ(manifestとcontinuity)の読み込み
• `sh`: 累計 7.3MB ( 8 blobs)
• `java –version`: 累計 88.2MB ( 30 blobs)
• `javac HelloWorld.java`: 累計137.3MB ( 50 blobs)
• kdeneon/all (4.8GB + 34.5MB)
• `sh`: 累計36.7MB ( 8 blobs)
• `startkde`: 累計742.7MB (4,267 blobs)
• `firefox`: 累計866.6MB (4,506 blobs)
※各コマンドは続けて起動
評価: コンテナ起動に必要なblob量 (無圧縮)
1/5
1/5 以下

28
• kaggle/python (8.3GB + 38.2MB)
• `sh`: 累計 40.1MB ( 8 blobs)
• `ipython –c ‘echo(“hello”)’`: 累計 75.4MB (1033 blobs)
• `ipython –c ‘import nltk’`: 累計352.0MiB (2799 blobs)
評価: コンテナ起動に必要なblob量 (無圧縮)
1/24 以下

29
評価: 圧縮率
イメージ rootfs 従来のtarをまと
めてgzip -9
提案フォーマット
+各blobを個別
にgzip -9
openjdk:8 671.7MB 261.3MB 260.7MB
(-645,604B)
kdeneon/all 4.8GB 2.1GB 2.1GB
(-489,361B)
kaggle/python 8.3GB 3.6GB 3.6GB
(+4,345,701B)
今回試験したイメージでは圧縮率の違いは誤差の範囲
(似たようなblobが多いイメージでは圧縮率は悪くなりそう)

30
評価: 重複除去
kdeneon/all
(4.8GB)
kaggle/python
(8.3GB)
75.4MB の重複を除去できる
(互いに全然関係なさそうなイメージだが，
Debian系に共通のファイルがあるため重複blobがある)

31
評価: FUSEのオーバヘッド
0.1
1
10
100
1回目 2回目 3回目 4回目 5回目 6回目 7回目 8回目 9回目 10回目
openjdkの/usr以下をtarで固めるのに要する秒数
従来のDocker (overlay2) 提案フォーマットのFUSE(read-only)
Docker 17.06 / Fedora 26 / 2 vCPUs, 2GB RAM, 2GB swap (VMware Fusion, MacBook Pro 2016)

32
0.1
1
10
100
提案手法ではコンテナ起動後，readが発生して初めてblobをpullする．
そのため初回データにはpullの時間を含む．
(今回はlocalhostがリモートなのでネットワークのオーバヘッドは含まない).
※従来Dockerの方は，イメージをpullしてからコンテナ起動するので
pullの時間は含んでいない．

33
0.1
1
10
100
カーネルのキャッシュが効いて速くなる
実装上の何らかの理由で
カーネルのキャッシュが効いていない?
(read-onlyなので原理的には簡単なはず．楽観的．)

34
• PullのためのRPCの数が増えることのオーバヘッド
• プロトコルに依存する
• TODO: Docker Registry APIのクライアントを実装し評価する．
• 現在のPOCはローカルディレクトリをレジストリ代わりにしている．
評価: その他

35
今後の方針

36
• ファイルより細かい粒度への対応
• 大きいファイルはchunk毎にSHA256ダイジェストを計算し，continuityとはまた別
のフォーマットとして保存しておけばよい (continuity#85)
• コンテナ起動時にすぐ必要となりそうなファイルを検出し，予め1つのtar
にまとめておく
• pushする前に1回コンテナを起動し，FUSEの呼び出しをトレースしておけばよい
今後の技術的な方針

37
• 現在，Dockerは多数の”LEGOブロック”へ分解・再編成されつつある最中
• ガバナンスの明確化
• 拡張モジュール開発の容易化
コミュニティ的な取り組み方針
Docker CLI
Moby Core (dockerd)
containerd
runc
BuildKit (buildd) SwarmKit (swarmd)
CLI (これだけはDocker社がコミット権独占)
各モジュールのAPIを統合
分散実行Dockerfile的なDAGを実行
cgroups, namespace
OCIイメージ・CoW FSなど
赤枠内はKubernetesとも共通する (今後，Dockerの代わりのランタイムとして選択可能になる)
提案フォーマットをcontainerd周辺に導入することを目指す
(DockerやKubernetesの拡張機能として簡単に使えるようにする)

38
まとめ

39
• `docker pull` し終わる前に`docker run`可能になるような
イメージフォーマットを提案
• https://github.com/AkihiroSuda/filegrain
• 例えば Docker公式のOpenJDKイメージは全体で672MBある
が7MB pullした時点でsh起動可能になる
• 88MBでJRE，137MBでJDK
• その他，重複除去などの利点もあり
• OCI標準仕様との互換性を重視
まとめ

40
デモ (時間があれば)

41
予備スライド

42
1. blob数の肥大化
• イメージをファイルシステム上に配置する場合，/blobs/sha256 ディレクトリに大
量のファイルが出来るため，readdir(3) が遅くなりがち
• /blobs/sha256/deadbeef..を/blobs/sha256/de/deadbeef..のように"sharding"する
テクニックは不可 (OCIとの互換性のため)
2. RPCオーバヘッド増大
• 細かいファイルは単一のtarにまとめてpullするほうがRPCが少なくて済む
3. イメージによっては圧縮率低下
• 似たようなファイルを多数含むレイヤは，従来通り，単一のtarにまとめると高い圧
縮率が期待される
ただし，前述の通り，従来のOCIレイヤとの重ね合わせでカバー可能
提案フォーマットの欠点

43
没案: 外部ストアを併用する
⇒特定のプロトコルに依存するし，OCIのmerkle treeを使えなくなること
があり，環境再現性・セキュリティ面での懸念があるため，没
なぜ他の方法にしないか
類似研究:
Harter, Tyler, et al. "Slacker: Fast Distribution with Lazy Docker Containers." FAST. 2016.
• NFS上のext4イメージをループバックマウントし，ブロック粒度でのlazy-pull，重複除去を実現
Lestaris, George. "Alternatives to layer-based image distribution: using CERN filesystem for
images." Container Camp UK. 2016.
Blomer, Jakob, et al. "A Novel Approach for Distributing and Managing Container Images:
Integrating CernVM File System and Mesos." MesosCon NA. 2016.
• CernVM-FSを用いて，ファイル粒度でのlazy-pull，重複除去を実現
• CernVM-FSもmerkle treeを持っているが，OCIのmerkle treeに接ぎ木するには一手間要りそう
IPFS(P2Pでcontent-addressableなファイルシステム)の使用も考えたが，特定プロトコルに依存したく
なかったので没
※提案フォーマットはHTTPでもNFSでもCernVM-FSでもIPFSでも，任意のプロトコルで配信可能

44
没案2: tarを先頭からseekしていけばよいのではないか?
⇒没
• 圧縮されたtarではseek不可能
• 非圧縮tarでもプロトコルによってはseekできない
• メタデータ全体をとるためのリクエストが多発
メタデータ0
ファイル0
メタデータ1
ファイル2
ファイル{n-1}
終端 zero (1024B)
...
ファイル本体を読み飛ばしてseekし
メタデータだけ先に集める?
TAR

45
没案3: tarの代わりにzip(など)にすればよいのではないか?
⇒プロトコルによってはseekできないし，zipはメタデータのサポートが弱
いので没
ZIP
予備メタデータ0
圧縮済ファイル0
予備メタデータ1
圧縮済ファイル2
予備メタデータ{n-1}
圧縮済ファイル{n-1}
...
フッタ
メタデータ0
メタデータ1
...
メタデータだけまとめて先にpullできる?

高速にコンテナを起動できるイメージフォーマット (NTT Tech Conference #2)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 高速にコンテナを起動できるイメージフォーマット (NTT Tech Conference #2)

Similar to 高速にコンテナを起動できるイメージフォーマット (NTT Tech Conference #2) (20)

More from Akihiro Suda

More from Akihiro Suda (20)

高速にコンテナを起動できるイメージフォーマット (NTT Tech Conference #2)

Editor's Notes