写真:Getty Images
写真:Getty Images

グーグル、IBM、マイクロソフト、レッドハット、ヴイエムウェア、アマゾン・ウェブ・サービス――。名だたる米国の大手ベンダーが、オープンソースソフトウエア(OSS)のコンテナ管理ソフト「Docker」を、自社の製品やサービスに取り込み始めている。新興PaaS(プラットフォーム・アズ・ア・サービス)事業者が2年前に公開したOSSが、なぜこれほどまでに注目を集めるのか。ITインフラ市場の新しい台風の目、Dockerに迫る。

 今から2年前にさかのぼる。米国サンフランシスコ市の中心部「SOMA」地区に、新興のPaaS(プラットフォーム・アズ・ア・サービス)事業者があった。

 会社の名前は米ドットクラウド。同社が2011年に開始した「dotCloud」は、米セールスフォース・ドットコムの「Heroku」や米グーグルの「Google App Engine(GAE)」など大手ベンダーの競合サービスに押され、業績は低迷が続いていた。

 「Docker」はこのドットクラウドが2013年3月に、起死回生を狙って公開したオープンソースソフトウエア(OSS)だ。DockerはLinuxの中に「コンテナ」と呼ぶ仮想的なOS環境を作り出す。コンテナにはミドルウエアやアプリケーションを自由にインストール可能で、コンテナ上のプログラムは他のコンテナから隔離された状態で動く。

 コンテナは古くからある技術で、商用UNIXの「Solaris」には2004年に搭載されているだけでなく、Linux用のコンテナも複数存在していた。公開当初のDockerは「小規模なPaaS事業者が開発した最後発のコンテナ管理ソフト」に過ぎなかった。

 それが今では、IT業界の最重要ソフトへと変貌を遂げた。

 米マイクロソフトでクラウド&エンタープライズ部門を統括するスコット・ガスリー上級副社長は「Dockerに対するファーストクラスのサポートを提供する」と述べ、同社の「Microsoft Azure」や2015年に発売する予定の次期版「Windows Server」で、Docker対応が目玉機能になると強調する。

 マイクロソフトだけではない。2014年には米IBMや米ヴイエムウェア、米レッドハットなどがドットクラウドから社名を変更したドッカーと相次ぎ提携。Dockerを自社の製品に取り込み始めた。米グーグルや米アマゾン・ウェブ・サービスも、Dockerのクラウドサービスを開始している。

 なぜDockerにこれほど注目が集まるのか。本特集ではDockerに対する米国IT業界の動きをまとめると共に、Dockerの技術的特徴や、ユーザーにとっての利用メリットを解説する。

次世代サーバーOSの主役

図1 Dockerに関連する主な製品やサービス
コンテナ中心のエコシステムが誕生
図1 Dockerに関連する主な製品やサービス
[画像のクリックで拡大表示]

 Dockerの周辺には既に、大手ITベンダーや新興ベンダーによる強固な「エコシステム」が形成されている(図1)。各社はDockerを使いやすくするための様々な製品をリリースしたり、Dockerをサービスとして利用できるクラウドを提供し始めたりしている()。

表 Dockerに関する主な取り組み
大手ベンダーが熱視線
表 Dockerに関する主な取り組み
[画像のクリックで拡大表示]

 DockerはOSの中に仮想的なOS環境であるコンテナを複数個作り出すことで、一つのサーバーを複数のユーザーや複数の用途で使えるようにするものだ。さらに、複数台のサーバーでDockerコンテナを使用する際の効率を上げる運用管理ソフトの「オーケストレーター」も登場している。

 オーケストレーターはDockerが動作するサーバーの稼働率などを監視し、ユーザーから新しいコンテナ作成のリクエストを受けた際には、リソースに余裕があるサーバーを優先的に割り当てる。またコンテナ同士でクラスタ構成を組めるようにすることで、Dockerの安定稼働を実現する。

 オーケストレーターとしては、米グーグルが2014年5月にOSSとして公開し、マイクロソフトやIBM、レッドハットなども開発に参加する「Kubernetes(クバネティス)」や、ベンチャー企業の米メソスフィアが開発する「Mesos」などがある。

 IaaS(インフラストラクチャー・アズ・ア・サービス)構築ソフトの「OpenStack」や、PaaS構築ソフトの「OpenShift」や「Cloud Foundry」も、Dockerのオーケストレーターとしての機能を備え始めている。2014年12月にはドッカー自身が、「Docker Machine」「同Swarm」「同Compose」という三つのコンポーネントからなるオーケストレーターをリリースした。

レッドハットとベンチャーが火花

 Dockerの稼働に特化した、軽量なLinuxOSも登場している。従来のLinuxディストリビューションには、Linuxカーネルだけでなくさまざまなミドルウエアが含まれていた。Dockerを使用する場合、ミドルウエアはコンテナの上にインストールすることになるので、Dockerを稼働する「ホストOS」にはミドルウエアは必要ない。ミドルウエアを省き、カーネルのアップデートなどを容易にする仕組みを搭載したのが軽量OSだ。

 最初に登場したのは米国のベンチャー企業、米コアOSが開発した「CoreOS」だ。レッドハットがそれに追従して、2014年11月にDocker専用の軽量OS「Red Hat Enterprise Linux 7 Atomic Host」をリリースした。

 Dockerのクラウドサービスも始まった。グーグルの「Google Container Engine」やアマゾンの「Amazon EC2 Container Service」である。これらは「既存のIaaSの仮想マシンの上で、Dockerを利用しやすくするサービス」(アマゾンデータサービスジャパンの大谷晋平エマージングソリューション部 部長)。クラウド事業者がユーザーに代わってオーケストレーターを運用する。

IaaS上でDockerを利用

 ユーザーは仮想マシン単位でコンピュータ資源を借り、オーケストレーターのユーザーインタフェース(UI)などを使用してDockerコンテナを仮想マシン上に展開する。グーグルのGoogle Container EngineはオーケストレーターとしてKubernetesを使用。Amazon EC2 Container Serviceではアマゾンがオーケストレーターを自社開発している。

 ヴイエムウェアや日本IBMも、Dockerを既存のIaaSで利用可能にする予定だ。

 Dockerに対抗する動きも始まっている。Docker用の軽量OSを開発するコアOSは2014年12月、独自のコンテナである「Rocket」を発表した。コアOSはドッカーがコンテナの機能を肥大化させていると批判し、よりシンプルなコンテナとしてRocketを開発したと主張している。ヴイエムウェアも2014年8月に、Docker対抗の軽量仮想マシン「Project Fargo」を発表している。

 「現在は様々なベンダーが、クラウド時代に最適な新しいサーバーOS像を再考している時期。Dockerはその有力な選択肢だ」。レッドハット ソリューションアーキテクト部の中井悦司シニアソリューションアーキテクトはそう指摘する。新しいサーバーOSの主役であるDockerに、注目が集まるのも当然と言えそうだ。

開発者のためのITインフラ

 Dockerと、「VMware vSphere」のような既存のサーバー仮想化製品との違いは大きく二つある。サーバー仮想化が「仮想マシン(VM)」を使うのに対して、Dockerは「コンテナ」を使う点。そしてより重要なのは、サーバー仮想化が運用担当者を主なターゲットに作られているのに対して、Dockerが開発担当者をターゲットにしている点だ。

 まず仮想マシンとコンテナを比較しよう(図2)。仮想マシンは「ハイパーバイザー」が物理マシン上に作り出した仮想的なマシンだ。ユーザーは仮想マシンにOSやミドルウエア、アプリケーションをインストールして利用する。仮想マシン上のプログラムの命令やI/Oは、ハイパーバイザーによる変換を経てサーバーで実行される。この変換作業が仮想マシンの性能ボトルネックになっている。

図2 仮想マシンとコンテナの比較
コンテナなら管理すべきOSの数が減少
図2 仮想マシンとコンテナの比較
[画像のクリックで拡大表示]

 一方のコンテナは、Linux OSがOSの中に仮想的に作り出した「OS環境」だ。コンテナごとに独立したファイルシステムやプロセスの名前空間、ネットワーク設定、CPUやメモリーの使用上限などが割り当てられている。

 アプリケーションやミドルウエアは、コンテナ単位で独立した形で実行できる。プログラムの命令やI/OはOS上で直接処理されるため、「変換によるオーバーヘッドは発生しない」(レッドハットの中井シニアソリューションアーキテクト)。コンテナごとにOSをインストールする必要もないため、仮想マシンに比べてストレージ容量が少ないことも特徴だ。コンテナを起動する時間は、仮想マシンを起動する時間に比べて短い。

「GitHub」に影響を受けたDocker

 Dockerは、Linuxが以前から備えていたコンテナを、アプリケーション開発者が容易に使いこなせるように機能拡張している。具体的には、インストールするソフトや設定情報といった「コンテナのディスクの内容」を、アプリケーションの「ソースコード」のように更新したり管理したりできる(図3)。

図3 Dockerでの運用管理の手順
ソースコード管理と同じ手順でコンテナを管理
図3 Dockerでの運用管理の手順
[画像のクリックで拡大表示]

 Dockerコンテナのディスクの内容のことは、「Dockerイメージ」と呼ぶ。開発元のドッカーは、ミドルウエアがインストール済みのDockerイメージを入手できるリポジトリサーバー「Docker Hub」を運営している。Dockerの主要ユーザーであるアプリケーション開発者はまず、Docker Hubから自分が利用したいDockerイメージを入手する。

 続いて開発者は「Dockerファイル」というテキストファイルを記述することで、Dockerイメージにソフトをインストールしたり、ソフトの設定情報を変更したりする。OSのコマンド画面からコマンドを入力する必要はない。開発者はDockerファイルを「プログラミング」することで、コンテナをカスタマイズできる。開発者がプログラミングによってITインフラをコントロールする「Infrastructure as a Code」という考え方に基づいている。

 カスタマイズしたDockerイメージは、改めてDocker Hubに登録し、Docker Hubから運用環境へ展開する。リポジトリサーバーを中心にしたこれらのワークフローは、「先進的なWebアプリケーション開発者に人気が高いソースコード共有サービス、『GitHub』の影響を受けている」(Pivotalジャパン カスタマーサクセス部の三宅剛史氏)という。

 Dockerではアプリケーションのデータのほか、ネットワーク設定などITインフラ環境の設定情報(環境変数)を、Dockerイメージに書き込まない。アプリケーションのデータは外部のストレージに、環境変数はDockerファイルに保存する。こうすることでDockerイメージは、ITインフラの環境に左右されない「ステートレス」の状態に保たれ、他のITインフラ環境にDockerイメージを移行しやすくなる。

 ヴイエムウェア マーケティング本部の桂島航シニアプロダクトマーケティングマネージャは、「Dockerイメージは、開発環境から本番環境、あるOSから別のOS、あるクラウドから別のクラウドといった、環境をまたいだ移行が容易。このようなポータビリティ(可搬性)の高さが、Dockerが開発者に支持されているポイントだ」と説明する。

使い捨てインフラを実現

 日本でも既に、Dockerを本番環境で使っている企業がある。セキュリティ関連のSaaS(ソフトウエア・アズ・ア・サービス)を手がけているHDEだ。

 HDEはDockerを導入することで、アプリケーション開発の効率が向上しただけではなく、システムの安定稼働や、運用担当者の管理負荷の軽減も実現できたと評価する。

 HDEは同社が提供するSaaSのバックエンドで部分的にDockerを使用している。HDEは顧客の要望に応える形で、SaaSを一部カスタマイズして提供。カスタマイズしたアプリケーションを稼働するサーバーは、他のユーザーのサーバーとは別に運用している。これらサーバーの運用環境として、2014年秋からDockerを使い始めた。

 Dockerコンテナは、「Amazon EC2」の仮想マシン上で運用している。HDEでは従来からSaaSのITインフラにAmazon EC2を全面採用しており、DockerのためにITインフラを変更する考えはなかった。HDE プロダクト開発部の田辺兼一氏は、「EC2の仮想マシンをそのまま使うよりも、仮想マシン上でDockerを使う方が、アプリケーション開発の効率が上がる」と語る。

運用自動化で効率向上

 田辺氏が考える開発者にとってのDockerのメリットは、「『イミュータブル(使い捨て)インフラストラクチャー』の考え方を実践できること」(同氏)だ。イミュータブルインフラストラクチャーとはシステムに何か変更があった場合に、同じ本番環境を使い続けるのではなく、丸ごと新規に環境を構築し直すことで、安定的なシステム更新を実現するという考え方である。

 開発者はアプリケーションに変更を加えたら、続いてDockerファイルを更新し、新しいアプリケーションサーバーのDockerイメージを作成する。そのDockerイメージを基にコンテナを起動して、まずはテストを実行する。Dockerファイルの更新からコンテナの起動、テストの実行までは、CI(継続的インテグレーション)ツールの「Jenkins」を使って自動化している。

 テストが成功したら本番系を新しいコンテナの方に切り替える。アプリケーションの開発からテスト、本番環境への切り替えまでを、開発者が運用担当者に頼らずに完結できるため、開発効率の向上につながる。

 このような運用の自動化は、「Heroku」や「Google App Engine」といったPaaSを使うことでも実現できる。しかし田辺氏は「既存のPaaSはミドルウエアのバージョンなどをユーザー側で自由に変更するのが難しく、柔軟性に欠ける。Dockerなら『自分好み』のPaaSを、自らの手で作ることができる」と分析する(図4)。

図4 IaaS、Docker、PaaSの比較
IaaSの利点とPaaSの利点を併せ持つ
図4 IaaS、Docker、PaaSの比較
[画像のクリックで拡大表示]

Docker採用でコスト削減

 運用上のメリットもある。HDEで運用を担当するサービスエンジニアリング部の山中悠氏は「当社では障害の切り分けなどを容易にするために、『一つのアプリケーションに付き一つのOS環境を用意する』という運用方針を採用している。1台のEC2仮想マシン上で複数個のコンテナを運用すれば、アプリケーションごとに仮想マシンを用意するのに比べて、仮想マシンの台数を削減できる。OSの運用管理工数も減る」と語る。

 さらに「Amazon EC2では低スペックの仮想マシンよりも高スペックの方がコストパフォーマンスは高い。そのため、たくさんの低スペック仮想マシンをDockerに移行し少数の高スペック仮想マシンに集約すれば、コスト削減が実現できる」(山中氏)という。

 HDEは現時点では、オーケストレーターのサービスである「Amazon EC2 Container Service」を使っていない。同サービスがまだ評価版であるためだ。それでも「将来的にはオーケストレーターをぜひ使いたい」(山中氏)と言う。

 オーケストレーターは、複数台のサーバーを一元管理して「リソースプール」を作り、Dockerコンテナの安定稼働に必要なクラスタリングなどを自動化する(図5)。「現在は、どのサーバーにコンテナを配置するかなどを手動で制御している。オーケストレーターがあれば、リソースプールの中で稼働率に余裕のあるサーバーを自動的に選択してくれるようになるため、運用の手間をさらに省ける」(山中氏)と見る。

図5 オーケストレーターの役割
リソースプールを管理し、適切なサーバーにDockerコンテナを展開
図5 オーケストレーターの役割
[画像のクリックで拡大表示]