こんにちは。日本ヒューレットパッカードのオープンソース、Linuxテクノロジーエバンジェリストの古賀政純です。前回の記事では、HPEの開発部門がDocker基盤を導入する上でのハードウェア面での検討と、DevOpsを実現するCD/CDモデルとDockerのもたらすメリットについて簡単に紹介しました。
HPEの開発部門のDocker事例の連載第3回目の今回は、従来の仮想化におけるゲストOSとDockerイメージの対比について、HPEの開発部門の検討事項を簡単にご紹介します。また、Dockerイメージに関する留意点や、最近の傾向なども合わせてご紹介します。
仮想化におけるゲストOS vs. Dockerコンテナ
以前の連載（第9回） でお知らせしたように、HPEの開発部門の決意には、仮想化ソフトウェアのライセンス排除がありました。HPEの開発部門は、ハイパーバイザー型の仮想化ソフトウェアをやめて、Dockerに移行することを決意したわけです。
従来の仮想化基盤において、仮想化ソフトウェア上で稼働する仮想マシン（Virtual Machine：VM）には、ゲストOSが稼働します。このゲストOSは、「物理基盤と全く同様の手順でインストールされたOS」です。ゲストOSはファイルとして管理され、イメージファイルと呼ばれます。このゲストOSのイメージファイルの中に、開発者の開発したソフトウェア（今回の事例では、HPE OneViewのモジュールの一部など）が格納されます。開発部門が開発したモジュール（ソフトウェアの部品）の大きさにも依存しますが、ゲストOSのファイルサイズは、組み込むアプリケーションやライブラリ、データなどを含めると、数十ギガバイトになることも珍しくありません。
一方、Dockerでは、OSの全てのコンポーネントをコンテナのもととなるDockerイメージ内にインストールする必要はなく、あくまで、アプリケーションが稼働するために必要な最小限のバイナリファイルやライブラリのみが格納されます。そのため、Dockerイメージは、通常、数百メガバイト程度で収まります。非常に小規模な開発環境であれば、数十メガバイト程度で済んでしまいます。Dockerイメージは、通常、仮想化ソフトウェア基盤で利用されているゲストOSのイメージファイルに比べて非常に小さいのが特徴的です。このため、ゲストOSに比べて、Docker環境では、ストレージ容量の大幅な節約が期待できます。
複数の開発チームが協調して開発する場合は、大量の開発環境を簡単に、かつ、素早くコピーし、共有できなければなりません。VMのゲストOSを他部署にコピーし、稼働させるとなると、ディスクスペースを大量に消費しますし、コピーに膨大な時間もかかります。従来のゲストOSのイメージをコピーするような運用は、効率化の観点において、避けなければなりません。
HPEの開発部門では、大勢の開発者がDockerイメージの保管庫からのDockerイメージの入手（ダウンロード）や登録（アップロード）を頻繁に行います。Dockerイメージ自体のサイズが小さいため、データ転送の負荷を減らすことができ、転送時間も大幅に短縮できるのです。
仮想マシンのサイズとDockerイメージのサイズ
Dockerコンテナ内では、目的のアプリケーションのみが稼働するため、OSのように大量のプロセスを稼働させる必要がないことから、必要なシステムリソースが少なくて済み、結果的に、ハイパーバイザ型仮想化基盤に比べて、物理サーバ上で圧倒的に多くのアプリケーションが稼働できます。さまざまな開発ツールを仕込んだ開発環境を共有して利用するといったシーンでは、スピードと数の面で仮想化よりも、サイズが小さく軽量なDockerコンテナが威力を発揮します。
スピードと数でVMを圧倒するDockerコンテナ
