8月20日には、社内向けの仮想化セミナで「バズワードとしてのコンテナ型仮想化とDocker」を解説し、それに先立ってこのところDocker周りの耳学問に励んだ。また22日には、「意識低いDocker勉強会」で技術面を聞いたりもした。

コンテナ型仮想化（以下コンテナ型）についてそこで学んだことと、僕なりに仮想マシン型仮想化（いわゆる仮想化、以下では区別がつくように仮想マシン型と呼ぶ）を机上比較して考えたことを、一度まとめてアウトプットしておきたいと思う。勉強中の僕の書くものなので、間違いなどはあるかもしれない。できるだけの確認はしたつもりだけど、それでも眉につばをつけて読んでください。

意識低い勉強会

「意識低い」の意味は、前佛さんからこう説明された。

問題意識が低いということではなく、カタカナ用語になるけど、ローコンテキストということかなと思う。Dockerそのものに加えて、この指摘は改めて意識させられるものがあって勉強になった。

ところでこの勉強会に参加していて、仮想マシン型仮想化と、コンテナ型仮想化は似ている部分があって、用語の整理を最初にしないと混乱するかもしれないと思った。僕の知っている範囲でも、仮想マシンを扱いなれた人でも仮想マシン型の用語を正しく（つまりベンダがドキュメントに記載しているとおりに）使えてるとは限らない。するとコンテナを扱うのに長けた人でも、同様のことがあるかもしれない。

僕のおぼつかない理解の範囲でだが、以下の図にまとめておく。

VMware vSphereやHyper-V、XenServerなどの仮想マシン型仮想化では、仮想化レイヤーを「ハイパーバイザ」と呼ぶ。物理マシンにインストールされているのはこのソフトウェアなので、仮想化OSと呼ばれることもある。この上に仮想ハードウェアからなる「仮想マシン」が作られ、仮想マシン内にインストールされたOSは「ゲストOS」と呼ばれる。ゲストOSは、個々に仮想ハードウェアを制御するカーネルやファイルシステムを持つ。

コンテナ型仮想化では、物理マシンにインストールされたOSがコンテナ機能を提供する。このため「ホストOS」とも呼ばれる。ホストOSは（ざっくり言えば）ファイルシステムとカーネルと仮想化する。この仮想のファイルシステムとカーネルを「コンテナ」とみなせばいいのかもしれない。コンテナ内に構築されたOS環境は「コンテナOS」と呼ばれる。

対応関係で言えば「ハイパーバイザとホストOS」「仮想マシンとコンテナ」「ゲストOSとコンテナOS」という感じなのかな。仮想マシン型仮想化は「OSに対してハードウェア（マシン）を仮想化する」と言われるし、コンテナ型仮想化は「アプリケーション（プロセス）に対してOSを仮想化する」と言われる。

Dockerの世紀

最初に登壇した横田さんのプレゼンテーションの表題は「Dockerの世紀」だった。それはもうすぐそこまで来ていると思う。

僕の仕事はVMware製品を扱うことで、同社はCoreOSにも似た軽量なLinuxコンテナホストOSを提供する「project photon」などを提供している。とは言え、ハイパーバイザであるVMware vSphere ESXiがホストOSを兼ねるとか、ESXi上にコンテナを直接載せられる、というわけではない。

だってそんなことをしても、僕の理解ではコンテナOSはホストOSのカーネルを使いまわせるものに限られるから、そのコンテナは「ESXiコンテナ」になってしまう。ESXi上のコンテナ上でESXiを動かして何の意味があるだろう（現実にNested ESXiというニッチ需要があることは否めないけど）。その意味では、Dockerは僕の仕事ではない。

でも20日に開催した、VMwareと仮想化に関する社内セミナー（6時間に渡り、うち4時間は僕が喋り通すものだった）では、Dockerに触れざるを得なかった。Red Hat社員の公開した「Docker is not Container」や、MS社の「MS版Docker誕生！Windows Server Containersとは？」「New Windows Server containers and Azure support for Docker」などに触れながら、スライド5枚を割いて簡単な紹介をした。

VMware vSphereによる仮想化型を主選択とする僕達（つまり僕がイメージする僕の会社）にとって、いよいよDockerの世紀が来る、採用するにせよ採用しないにせよ、コンテナ型を意識しないわけにはいかなくなると思う理由が3つある。

SIはWindowsコンテナで変わる

1つ目は、Windowsコンテナだ。Microsoft社は、Windows Server 2016でWindowsコンテナとDockerサポート（およびdocker.exe）を提供する予定だ。

簡単に言えば、これまではコンテナ型仮想化の上でLinuxは動かせても、Windowsは動かせなかった。ホストOSになってコンテナ機能を提供するLinux OSはあっても、ホストOSになるWindows OSはなかったからだ。コンテナOSは、ホストOSと同じカーネルを使い回せるものに限られる。だから、これまではWindowsは、コンテナ上で動かなかった。Windows Server 2016の登場以降であれば、Windowsはコンテナ上で動作する。

クラウドサービスとして機能を提供するケースと違い、従来通りお客様が所有するシステムを構築するSI（システムインテグレーション）事業では、Dockerを採用するためにWindowsを採用しないという選択は難しい。お客様が日常の運用に困らないことというのはとても重要な条件で、OSもお客様と意見をすり合わせながら選択する必要がある。

Windowsを稼働させられないコンテナ型は、技術としては同じx86サーバー仮想化の選択肢ではあっても、僕達のSIの採用部品として「仮想化型 or コンテナ型？」とか「vSphere or Docker？」とか比べられるものではなかった。

LinuxはコンテナOSにしてDockerで操作、Windowsは仮想マシンにしてvSphereのクライアントで操作なんて併用モデルを採用するには、社内1000人に至る技術者達の教育コストと運用コスト（OPEX）の壁を乗り越える必要がある。併用モデルでは所有コスト（CAPEX）も下がらないから、増加する教育コストと運用コストに釣り合う見返りを説明しにくいんだ。

でもLinuxもWindowsも動くなら、システムごとに仮想マシン型かコンテナ型のどちらかに統一できる。もちろん両方を品揃えすることはやはり教育コスト増を招く。でもリソース使用量が少ないので集約率を上げられ、ハードウェア台数を減らして所有コストを下げられるコンテナ型という選択肢を品揃えに加えられることは、競争力の点でビジネスメリットがある。

コストはコンテナで変わる

2つ目は、コンテナの利点だ。コンテナ型の仕組み上の強みは「コンテナOSはホストOSのカーネルを使い回す」こと。これには、以下のメリットがあると理解している。

・カーネル分のディスク容量が節約できる。
・カーネル分のCPUリソース使用量やメモリ使用量を節約できる。
・カーネル分の起動/停止時間を節約できる。

この理解が正しいなら、案件のマネージャーやセールスパーソンにとってはディスク、CPU、メモリの節約は明らかに大きな関心事だ。それだけ一台の物理マシン上へのOS集約率を高め、ハードウェアを減らし、総所有コストを下げられる。

一方、システム管理者や開発者にとっては、起動と停止時間の節約は大きな関心事だ。システム管理者にとっては、メンテナンス作業時間をそれだけ短縮できる。一般に運用コストの大きな部分は、実際にオペレーションにかかる時間を分単位で計測した人件費で測られ、それにオペレーション時間中のシステム停止時間による業務影響の観点が加わる。

1人が100台のOSを管理し、月例で年12回パッチ適用に伴う再起動が少なくとも発生するデータセンターであれば、起動と停止合わせて1分節約できれば、スタッフ一人当たり年間1,200分、20時間の節約になる。20時間に意味があるかどうかは、システム管理者に聞いてみよう。

僕の予想では、20時間＝2.5人日の人件費をどう思うかは管理者次第だけど、20時間≒0.23%の停止時間には、ほとんどの管理者が興味を示すんじゃないかと思う。当たり前のレベルで99%、ちょっとがんばるレベルで99.5%といった稼働率だから。

品質と技術者はコンテナで変わる

3つ目は、コンテナの利点がもたらす副次効用だ。起動と停止時間の節約は、開発者にとっても大きな意味を持つ。開発者にとって、1時間に何回、あるいは1日に何回OSを起動/再起動できるか、というのは、意外と死活問題だ。

いまどきの成果物試験では、試験を繰返す際、環境のクリンナップをするかわりに毎回まっさらなOS環境を用意する。間違いが起きないし、仮想化環境であればその方が手っ取り早い。でも仮想化でも、仮想マシンをデプロイ（用意）してパワーオンしてOSが立ち上がるまで、それなりの時間がかかる。感覚的にいえば、5～10分でできたら早いほうだ。コンテナでは1分でできるだろう。試験の時間コストは、試験の上限回数を決めるし、試験のめんどくささを減らして、開発者が試験を行う頻度を変える。

成果物試験だけではない。要件を満たすのに「こうすれば実現できそう」というアイデアが浮かべば、最初にやってみるのは「まず試そう」ということだと思う。大げさに言えば実証実験、Proof of Conceptだけど、アイデアを実験で確かめて採用することほど、先進的で堅牢なアプリケーション作りと技術者のスキル向上を促進するものはない。そしてここでも、実験ができるかというのはその人の気質、環境≒OSの調達コスト、そして所要時間＝ヒューマンコストに左右される。

ただでさえOSの調達、起動、停止時間にコンテナと仮想マシンでは開きがあるけど、いわゆる「家畜とペット」モデルでいえば、VMware vSphereの利用者達は仮想マシンにペットに対するように手間をかけがちだ。なおさら即時調達・使い捨て（イミュータブル）を前提としたつくりをせず、調達時間の差が大きい。

コンテナ型は仮想マシン型以上に起動や停止を軽量化し、それにより運用コストを抑える。また試験時間が抑えられ、試験回数や実験頻度は高まる。それは品質と技術レベルに寄与する。両方を品揃えしたり、両方をスキルセットに加えることは、充分に価値があると思う。

仮想マシンはコンテナを補完する

ところで仮想マシン上でコンテナとDockerを動かすハイブリッドモデル、Container on VM（Virtual Machine）、あるいは二階建てモデルは、ばかばかしいだけだろうか？VMware社とMicrosoft社はそうは思っていないらしい。VMware社は、CoreOSやRHEL Atomic Hostと同様に軽量なLinuxコンテナのホストOSを仮想マシンとして提供するProject Photonを推進し、すでにテクノロジープレビューを公開している。

Microsoft社はWindowsコンテナと同時に、Windowsコンテナを仮想マシンとして（つまり1コンテナ1仮想マシンという構成で）提供するHyper-Vコンテナも開発している。少し長いが、「コンテナー: Docker、Windows、および動向 | S/N Ratio」の以下の説明が、その意味を理解させてくれた。

Hyper-Vコンテナーは、コンテナー化に対して少し異なるアプローチを取っています。さらなる分離を提供するために、各Hyper-VコンテナーはWindowsカーネルの独自コピーを持っており、各コンテナーに直接割り当てられたメモリを持っています。これは、強力な分離の主な要件です。我々は、CPU、メモリ、(ネットワークやストレージといった) IOの分離のためにHyper-Vを使っており、VMと同じレベルの分離を提供します。VMと同様に、ホストは、ホスト リソースの通信と共有のために、小さな制約されたインターフェイスをコンテナーに公開しているだけです。

この非常に制限された共有は、Hyper-Vコンテナーが、Windows Serverコンテナーに比べて起動時間と密度に関して少し効率が悪いが、信頼されていない「敵対的マルチテナント」アプリケーションを同じホスト上で実行できるようにするために必要となる分離を提供していることを意味しています。

僕なりの理解でまとめれば、より確実なリソースの分離には、ホストOSの分離が有効ということだと思う。Hyper-Vコンテナは、その上で1コンテナ1仮想マシンという構成をとっているけど、たとえばWeb-AP-DBを1ホストOS上にまとめるなど、1システム1仮想マシンという構成もありじゃないかな。

でもサービス開発者やアプリケーション開発者ではなく、僕たちインフラ技術者や仮想化/データセンター技術者であればもっとはっきりしたハイブリッドモデルの魅力に簡単に気づくだろう。

Linuxコンテナを動かすにはLinuxホストOSが必要で、Windowsコンテナを動かすにはWindowsホストOSが必要だ。1台の物理マシン上で、LinuxコンテナもWindowsコンテナも動かしたければ、どうすればいいだろう？仕組みから言えば多分、1台の物理マシンに2台の仮想マシンを配置して、それぞれをLinuxホストOSとWindowsホストOSにすればいいはずだ。ザッツ・オール。QED。

Container on VMには魅力がある。2つの意味がある。セキュリティとリソースの分離のために、ホストOSを分離する。そして物理マシンリソースをLinux OSとWindows OSの間でより柔軟にシェアするために、コンテナ型仮想化の下に仮想マシン型仮想化を敷く。

Dockerと仮想化の世紀

「意識低いDocker勉強会」でDockerの仕組みや歴史を学びながら、これまでに耳学問したDocker周辺の動きとあわせて、いろいろと考えることがあった。コンテナ型仮想化にようやく入門したばかりの僕の机上検討だけど、こんな可能性を感じる。

(1)コンテナ型仮想化は、「x86サーバOSの仮想化」という同じニーズ内で、仮想マシン型仮想化とシェアを分ける。

(2)Windowsコンテナが登場するWindows Server 2016年以降、SIでもコンテナ型は仮想マシン型と同様に広く検討される。

(3)コンテナ型はOSの集約度で総所有コスト（CAPEX）、OS起動/停止時間の短縮で運用コスト（OPEX）を改善する。またデプロイとOS起動/停止時間の短縮し、それにより試験/PoC所要時間が短縮され、品質の改善と技術者スキルの向上を促す。

(4)仮想マシンとコンテナを併用するContainer on VMのデプロイモデルも、第一にサービスレベル（リソース分離）とセキュリティの保障のため、第二におなじ物理マシン上にLinuxコンテナとWindowsコンテナを収容可能にするために、必要とされる。

前佛さんのプレゼンで、「Dockerにまつわる（誤った）都市伝説」の解説があった。もっとも大きなものは「コンテナは仮想化を駆逐する」で、僕もそれは誤っていると思う。コンテナと仮想マシンは使い分けられるもので、またContainer on VMの形で併用もされるものだ。

ティッピングポイントは、もしかしたらWindows Server 2016ではないかなと思う。そしてもしかしたら、そこでDockerと仮想化の世紀が来るかもしれないだ。たぶん2016年はコンテナの年で、そのとき仮想マシンとコンテナは仮想化の両輪。...たぶん、ね？