タグ: コンテナ

いまどき開発者会議に行って、ソフトウェアコンテナについて聞かずに済ますことはできない：Docker、Kubernetes、Mesos、その他多くの海事にちなんだ名前が耳に入ってくる。Microsoft、Google、Amazonそして他の皆も、昨年あたりからこのバンドワゴンに飛び乗っているようだ、だが皆が夢中な理由は何だろう？

コンテナがこのように大変な注目を集める理由を理解するために、まず物理的コンテナのことを少し考えてみよう。現代の海運業界が、現行の形で機能しているのは、私たちが輸送用コンテナサイズに対して、限られた数の標準化をしているおかげである。この規格が出現する前には、大量に何かを出荷することは、複雑で面倒なプロセスだった。たとえばスマートフォンが載せられたパレット（フォークリフトですくい上げることのできる荷台）を、船から降ろしてトラックに積むときに、どれほど苦労するか想像してみると良いだろう。アジアからスマートフォンを持って来る際に、特化した船を使う代わりに、私たちは、荷物を全てコンテナに収納することができる。そうしたコンテナがどのコンテナ船にもフィットすることは保証されている。

ソフトウェアコンテナの背後にある考えは基本的に同じだ。完全なオペレーティングシステムとソフトウェア（およびあなたのソフトウェアが依存するソフトウェアも）を出荷する代わりに、単にあなたのコードとそれが依存するものだけをコンテナへパックすれば、どこでも動作させることができる ‐ それらは通常かなり小さいため、1台のコンピュータ上に多くのコンテナを詰めることができる。

なぜこれが、そんなに大したことなのだろう？コンテナが普及する前には、いわゆる「仮想マシン」が、1台のサーバーで互いに独立した多くの異なるアプリケーションを実行させる手段として、有力なものだった。それこそが第1世代のクラウドアプリケーション（そしてウェブホスティングサービスまでも）を可能にしたテクノロジーだったのだ。すべてのアプリケーションのために、いちいち新しい物理サーバーを立ち上げていたら、コストが屋根を突き破ってしまっていただろう。

仮想マシンの動作は、オペレーティングシステムとコードを一緒にパッケージすることで行われる。仮想マシン上のオペレーティングシステムは、自分自身の専用サーバー上で動作していると思っているものの、実際には、サーバーを多くの別の仮想マシンたちと共有しているのだ ‐ それぞれの仮想マシンがそれぞれのオペレーティングシステムを持ち、そしてお互いを知ることはない。それら全ての仮想マシンの下にあるのが、ホストオペレーティングシステムで、これら全てのゲストそれぞれに、自分が世界の中心だと思わせる役割を果たしている。しかしこれが問題であることはおわかりだろう。ゲスト仮想マシンは基本的にエミュレートされたサーバー上で動作し、そのことは多くのオーバーヘッドを生み出し、動作を遅くする（まあその代わり、同じサーバー上で沢山の異なるオペレーティングシステムを実行できるのだが）。

輸送用コンテナの話に沿うならば（そしてそのメタファーを不条理まで突き詰めるならば）、これは巨大なコンテナ船を所有することに似ている。その巨大なコンテナ船には沢山のプールがあり、そのプールにはそれぞれ特別なコンテナ船が浮かんでいるのだ。

それぞれのコンテナは全く異なる動作をする。それらは単にアプリケーションと、それが依存するライブラリやフレームワークなどだけを含むので、1つのホストオペレーティングシステム上に沢山のコンテナを置くことができる。サーバー上のオペレーティングシステムは、1つのホストオペレーティングシステムだけで、コンテナたちはそれと直接対話をすることができる。これによって、コンテナを小さく、オーバーヘッドも著しく低く保つことが可能になる。

仮想マシンは、ゲストとホストオペレーティングシステム間のエミュレーション層として、いわゆる「ハイパーバイザー」を使用する。コンテナの場合、コンテナエンジンが大雑把ではあるがこれに対応している。中でもDockerエンジンが現在最も人気の高いものである。

コンテナは、ずいぶん昔にLinuxのコア機能となったのだが、それらはまだまだ使うことが難しかった。Dockerはコンテナを使いやすくするという触れ込みで立ち上がり、開発者たちは素早くそのアイデアを理解した。

コンテナは、開発者たちが、自分のコードがどこにデプロイ（配備）されても、変わらずに実行できるようにすることを容易にする。そしてそれは、しばしば「マイクロサービス」と呼ばれるものを実現可能にする。ひとかたまりの大きなモノリシックなアプリケーションにする代わりに、マイクロサービスはアプリケーションを互いに対話できる小さな部分に分割する。これが意味することは、異なるチームがアプリケーションのそれぞれ異なる部分に対して作業をしやすくするということだ。それぞれの部分が対話する方法を大幅に変えない限りは、という条件付きだが、チームは独立して仕事を進めることができる。これにより、ソフトウェア開発が加速され、起き得るエラーを簡単にテストすることができるようになる。

これらのコンテナすべてを管理するには、他の専用ソフトウェア群が必要だ。その1つの例がKubernetes（当初Googleによって開発された）で、これはコンテナを異なるマシン上に送り出す手伝いを行い、きちんと実行されることを保証し、需要が高まった際に特別なアプリケーションを載せた幾つかのコンテナを自動的に立ち上げる。そしてもしコンテナ同士にお互いを認識させたいのなら、それぞれのコンテナにIPアドレスを割り当てる、仮想ネットワークを設定する手段が必要となる。

コンテナは、あらゆる種類のアプリケーションを実行することができるものの、仮想マシンとはかなり異なっているために、大企業がいまだに使っている多くの古いソフトウェアが、このモデル上には移行していない。しかしながら、仮想マシンは、そうした古いアプリケーションをAWSやMicrosoft Azureなどのクラウドサービスに移行させる役に立つ。このため、コンテナには多くの利点があるにも関わらず、仮想マシンも簡単にはなくなることはないだろう。

[ 原文へ ]
（翻訳：Sako）