Dockerを大規模にスケールアップするには

2016年4月11日 7:00

Dockerはアプリケーションをパッケージ化する簡単で新しい手段として、
世界中で急速に受け入れられている。以前にも書いた通りアプリケーションをコンテナ化
できる事は素晴らしい事なのだが、同時に企業が直面している大きな課題として、
大規模なデプロイをどうするかという問題がある。

コンピューティングにおいてスケールと言えばCERNほどの所はないだろう。
スイスのジェノバ郊外に位置する素粒子研究所だ。LHC(Large Hadron Collider)を
擁するところでもあり、500の大学から8000名の科学者たちが詰めている。
CERNとデータセンターOSというコンセプトについて2014年に書いたMesosphereは、
実際に使われているDockerコンテナをスケールアウトするためのアプローチに取り組んでいる。

Mesosphereの共同設立者にしてApache Mesosの製作者、Benjamin Hindmanと、
この件についてより深く知る機会があった。

実際にDockerコンテナを保管、配布する上での課題とは何ですか?

Benjamin Hindman（以下、BH）: コンテナのいいところは仮想マシンなどと違いOS抜きでアプリケーションを
パッケージ化できる事です。つまりその分小さくできる。イメージのサイズが小さくなれば、
ストレージやネットワークに対する要求もそれだけ小さなものになります。

なのですが、コンテナのイメージサイズは巨大になりがちです。依存するライブラリや
ファイルを一緒にまとめてしまえばサイズはかなり大きくなります。
場合によってはいるのか要らないのか分からないものも一緒に入れてしまう事もあります。

Dockerではコンテナ間のファイルシステムの再利用のためにレイヤーを使います。
これによりコンテナは小さいままで保てますが、それも既存のレイヤー上に
全てのコンテナが無駄なく載ればの話です。
これには注意深い作業が必要ですし、私の経験上、実現することはほとんどありません。

Dockerのレイヤーが現実にうまくいかないのはなぜなのでしょうか?

BH: これまでの経験から言わせてもらえれば、開発者たちがお互いが用意するレイヤ上で
丁寧な実装を行う事は非常に珍しいケースです。
現にレイヤーを作る場合、それを使えば要らないものがたくさんついてくるため、
他の人が使いたがらないようなものになってしまう事は非常によくある話です。

この事がもたらす結果はひどいものです。

二つのケースを考えてみましょう。まずみんなが個別で自分のコンテナに
ライブラリを放り込む場合、そしてライブラリを含むレイヤー上にコンテナを構築する場合です。
コンテナがレイヤーに含まれているケースでは、最初にレイヤーをダウンロードすれば、
その後はコンテナが代わってもそれを再利用することになります。

それぞれがバラバラにライブラリを持つ場合、コンテナが変わるたびに
ライブラリをダウンロードし直さなければなりません。ストレージ的にも
ネットワーク的にも非常に無駄が多くなります。レポジトリのサイズは爆発的に増加し、
ギガバイト単位のDockerのダウンロードによってネットワークを圧迫することになります。

Mesosphereで我々はこの問題で実際に困っている場面に出くわし、
いくつかの代替手段を試してみました。

1つのアプローチは、まず最初にコンテナをいくつかのノードに展開し、
その後はP2Pをつかってノード自身が展開されていくという方法です。
この事から展開されるべきコンテナのイメージを理解し、展開されるデータは
これまで送られたことが無いものだけに限らなければいけないという結論に行きつきました。
つまりコンテンツを含んだレイヤよりも、コンテナに含まれるコンテンツ自体に
目を向けるという事です。

CVMFSとCERNの統合が、この問題の解決にどう役立ったのでしょうか?

BH: スイスのCERNで講演を行った際、2008年にCERNで開発された技術であるCernVM-FS(CVMFS)の
設立メンバーに合うことが出来ました。その時、CERNはアプリケーションのデプロイを
どう最適化するかという、今日のコンテナのようなハードウェアの仮想化手段を求めていました。

イメージやパッケージを作る代わりに、CERNはグローバルな分散ファイルシステムを
使う事を考えていました。これにより科学者たちは一度Webサーバにインストールしてしまえば、
世界中のどこからでもそれにアクセスすることが出来るようになります。
ジェノバにいたとき、彼らのCVMFSのデモを見ることが出来、即座にこれは問題を解決できる、
コンテナとの相性が完璧なものだと思いました。

拡張インデックス、冗長データの解消、キャッシングに地域的コストを考慮した
伝達を使って、各々のダウンロード量を自動的に最小化できる事から、
CVMFSはコンテナを展開するのに完璧なものです。
冗長なデータの転送量が飛躍的に縮小され、通信速度が大きく向上しました。

そこでもしCVMFSとApache Mesos、Mesosphere DCOSを統合することが出来れば、
冗長なデータ転送を大きく削減し、コンテナの伝送が相当速くなると気づいたのです。
笑いが止まらない瞬間でした。

Apache Mesos、Mesosphere DCOSはコンテナをどう扱うのですか?

MesosとDCOSは我々がコンテナライザと呼んでいるものに依存しています。
コンテナライザは実行中のタスクを他のタスクと分離するためのものであり、
同時にそれぞれのタスクが使用するリソース(CPU、メモリ、Disk、N/Wなど)を制限するものです。
コンテナライザはまたコンテナがタスクを実行するためのランタイム環境も提供します。

コンテナ自体はLinux上の低レベルなオブジェクトというよりは、コントロールグループ(cgroups)や
名前空間などを使った抽象化されたものです。MesosコンテナライザはDockerやappcを含む、
今日存在するイメージのあらゆるフォーマットをサポートしています。

Apache MesosとCVMFSの組み合わせはどの規模までスケール出来ると思いますか?

BH: 理論上は数百万コンテナの規模まで行けるはずで、これはテストしているところです。
いい知らせとしては、MesosとDCOSの組み合わせとCVMFSは両方ともスケールアウトできる事が
分かっている点です。

実際のインテグレーションは単純なものです。やり方としてはイメージ全体を
ダウンロードするのではなくCVMFSクライアントを使ってリモートのイメージを
ローカルにマウントするのです。インプットとしては(内部的にCVMFSサーバのURLと紐づいている)
CVMFSレポジトリ名とコンテナイメージのルートパスを取ります。

そうすれば同じCSMFSレポジトリ内で複数のコンテナイメージを持つことが出来ます。
コンテナライザからすればこれによって変わるところは何もありません。
コンテナをスタートするためのローカルにあるイメージのディレクトリツリー
を扱うのと同じです。

この事の大きな利点は、CVMFSの細かい冗長性排除(レイヤーというよりはファイルの集まり)により、
全体のイメージをダウンロードすることなくコンテナをスタートする事が出来るという点です。
一旦コンテナがスタートすれば、あとはCVMFSが必要に応じてファイルをダウンロードします。
CVMFSの機能により、同じファイルを2度ダウンロードする事はありません。
結果、ストレージやネットワークを乱用することなく、Dockerコンテナの大規模な
デプロイが可能になるというわけです。

ReadWrite Japan
[原文]