KubeCon NA 2020 CERNの巨大な分析ジョブをコンテナ化する際の高速化から見るOSSの有機的な繋がり

KubeCon＋CloudNativeCon NA 2020のセッションの中から、今回はCERNが発表した、分析のためのアプリケーションをコンテナ化する際にコンテナ生成時間を短縮した事例を紹介する。CERNと言えば世界最大の素粒子物理学の研究機関として有名だが、一方でITの世界ではOpenStackの巨大なユーザー事例としても知られている。そんなCERNが行った今回のセッションのタイトルは「Speeding Up Analysis Pipelines with Remote Container Images」である。

この事例のベースになった技術は、複数の組織、コミュニティ、プロジェクトが開発するオープンソースソフトウェアや研究をベースにしている。一例を挙げると、CNCFから卒業したコンテナランタイムのcontainerd、Googleが開発した圧縮フォーマットのstargz/eStargz、それを応用してコンテナのイメージ生成時間を短縮することを研究したNTTのエンジニア、その研究結果を応用してCERNのシステムに実装したエンジニアとなる。オープンソースを通じた複数の組織、エンジニアのコラボレーションの成果が、有機的に繋がることを実感できる内容となった。

KubeConのセッション：Speeding Up Analysis Pipelines with Remote Container Images - Ricardo Rocha & Spyridon Trigazis, CERN

セッションの動画：Speeding Up Analysis Pipelines with Remote Container Images - Ricardo Rocha & Spyridon Trigazis

このセッションはCERNで利用されている分析のためのワークロードを、仮想マシンの上で実装するのではなくコンテナイメージとして実装する際に、コンテナイメージ生成のためのライブラリーなどの外部モジュールをダウンロードする場合の処理時間を短縮する方法を解説するものだ。

CERNのエンジニアが解説するコンテナイメージに関するセッション

この内容を理解するためには、まず以下の動画とスライドを参照されたい。ここではNTTの徳永航平氏がlazypullという方法でコンテナイメージのためのダウンロード時間を短縮する方法を解説している。

動画：Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する

スライド：Stargz Snapshotter: イメージのpullを省略しcontainerdでコンテナを高速に起動する

Stargz Snapshotterでイメージ起動を高速化する手法

これは多くのライブラリーなどに依存するコードをコンテナにまとめる際に、処理時間の多くがPullに費やされており、この状態を打破するためにlazypullを使うという手法を紹介するものだ。

コンテナイメージの処理時間は多くの場合、コードのPullに費やされている

徳永氏が解説しているのは、コンテナランタイムであるcontainerdのプラグインとして開発されているStargz Snapshotterだ。

Stargz Snapshotterの概要

通常であれば、コンテナのビルド～実行の際に、コンテナの仕様書であるManifestをダウンロード、その中で記述されているライブラリーなどをレイヤーとしてダウンロードという順番になる。ここですべてのレイヤーを毎回ダウンロード（Pull）することで処理時間が長くなるという状況を解決するためにlazypull、つまり怠け者（lazy）的にPullするやり方を、containerdのプラグインとして実装したというのがポイントだ。

通常のコンテナイメージの作られ方

Stargz Snapshotterは、コンテナのビルド時ではなく実行時に必要に応じてPullを行うことになる。そのためすべてのイメージを毎回ダウンロードする必要がなくなり、処理時間が大幅に短縮されることになる。

Stargz Snapshotterの仕組み

その際に圧縮のフォーマットとしてtarではなくstargzを使う。これはGoogleがコンテナレジストリーのファイルシステムであるcrfsを開発する中で提案され、実装されたフォーマットだ。

stargzの解説

結果としてコンテナ起動に必要な時間が短縮されていることが確認できる。

Stargz Snapshotterによる高速化のベンチマーク

このグラフの「legacy」は従来のすべてをダウンロードするやり方であり、「estargz」はstargzを最適化したフォーマットだ。stargz、estargzのどちらのフォーマットも、legacyと比較して大幅に高速化されていることがわかる。最後にまとめとしてstargz/estargzを使うStargz Snapshotterでコンテナイメージの起動が高速化することが解説されている。

徳永氏はスライドの最後のページで「使えそうなユースケースがあったら教えてください」と呼びかけているが、CERNのユースケースはまさにそれに当てはまるものというわけだ。

CERNが利用するソフトウェア配信のためのファイルシステム、CernVM-FSの紹介

ここで紹介されているCernVM-FSは、CERNと関連する研究機関がアプリケーションのイメージを共有するために作られたものだ。コンテナがそのパッケージのためのフォーマットとして利用されるに従って、コンテナイメージの起動時間やそれに必要とされるネットワークトラフィックが問題として浮かんできたという背景を紹介している。

CERNにおけるソフトウェア配信の問題点

そして、その解決策がlazypullだったというのがこのセッション前半の要点だ。

lazypullでコンテナイメージの起動時間を短縮

その具体的なツールとして挙げられたのが、NTTの徳永氏が紹介したcontainerdのプラグイン、Stargz Snapshotterだ。

CERNが使うStargz Remote Snapshotter

コンテナイメージの圧縮フォーマットとしてstargzを使うことで、tarball（tarコマンドでまとめられたアーカイブファイル）の中に何が収められているのかを素早く検知し、実際にダウンロードせずに実行時まで遅延させることで高速化するのが、Stargz Snapshotterだ。

解説には徳永氏が利用した図版が使われていることがわかる

CERNで実際に測定されたベンチマークも紹介された。ここでは特にPulling time、Pullにかかった時間に注目しよう。ネイティブの場合の3分37秒に対して、16秒と大幅に高速化されていることがわかる。

CERNによるベンチマークテスト

CERNとしては、この結果に満足しているというところだろう。CERNが利用しているGitLabのリポジトリーでは、HTTPによってアクセスする際のRangeというクエリーがサポートされていないなどの問題点も挙げられているが、おおむね高速化、ネットワークトラフィックの低減、オーバーヘッドの少なさなどが利点として挙げられている。

CERNにおける現状の評価

また今後の改善点としてマルチコアの利用、KubernetesのレジストリーであるHarborでの対応などが挙げられている。

最後にNTTの徳永航平氏や、ルート権限を持たないコンテナであるRootless Containersのコントリビュータである同じくNTTの須田瑛大氏などへの謝意を表して、セッションを終えた。

このセッションでは「いかにコンテナの起動時間を短縮するのか？」という命題について、Googleのstargz/eStargz、containerd、Stargz Snapshotterといった複数のプロジェクトを連携させることで、CERNの求めるシステムを実装できたことが紹介された。組織の枠を超えて、コミュニティが機能していることがわかる良い実例と言える。コミュニティへの貢献が他のコミュニティに繋がることで、最終的に全体が良くなるというオープンソースプロジェクトのベストシナリオを、CERNが示してくれた形と言えるだろう。

コンテナイメージ生成時にレイヤーのイメージをすべてダウンロードするのではなく、lazypullによってダウンロード時間を短縮する技法については、KubeCon＋CloudNativeCon EU 2020のセッションでNTTの徳永氏が使用した資料も参考になるだろう。

KubeCon EUのスライド（PDF）：Startup Containers in Lightning Speed with Lazy Image Distribution

また徳永氏のブログでも詳細に紹介されている。

徳永氏のブログ：Startup Containers in Lightning Speed with Lazy Image Distribution on Containerd

またCERNのファイルシステムCernVM-FSについては、以下を参照されたい。

参照（PDF）：Software Distribution with CernVM-FS