第 6 章 Docker が切り開くソフトウェア開発の未来 131
6.12 Docker プラットフォームの未来
Docker
の人気が高まるにつれて、Docker
社がそのプラットフォームを拡大しようとしている点は注目に値します。
執筆時点では、アプリケーションとしての
Docker
がサポートしているのはx86_64
プラッ トフォーム上のLinux
だけです。ARM
等の他のハードウェアアーキテクチャ上では利用できませんし、
32bits
に対する対応も十分ではないようです*20。一方、
2014
年10
月に「Docker
社がマイクロソフト社と提携する」というニュースが発表されました。「
Docker
とは（Linux
）コンテナベースのソフトウェア」と捉えていると、この ニュースはショッキングというか「何アホ言ってんだ」という内容に見えます。しかし、
Docker
によるマイクロサービスの世界観と、マイクロソフト社とDocker
社の提携は矛盾しないと筆者は考えます。
この提携に関して、執筆時点ではプレスリリース*21以上の情報があまりないのですが、
Windows Server
で動作するアプリケーションコンテナ配布もDocker Hub
経由で行え、Windows Server
上で"docker pull"
といった各種コマンドを実行できるようになる、といっ た内容ではないかと筆者は解釈しています。エンドユーザに提供する「マクロ」なサービスを考えた場合、個別のマイクロサービス用コ ンテナに期待されるのは、結合させたときのその「マクロサービス」の品質に与える、使用 する外部から見たコンテナそのものの性質です。たとえば「
SQL DB
サービスを提供するコ ンテナ」を考えたとします。そこで重要なのは中のデータが正しく扱われ、高速で、どうい う意味であれ「セキュア」であることです。そこで使用されるOS
がCentOS
かWindows
Server
かは、互換性が提供される限り重要ではなくなるかもしれません（その配置を受けもつ、
Kubernetes
のようなコンテナスケジューラにとっては依然大事です）。同等の機能を提供するコンテナへ切り替える選択肢が提供される状況は、マイクロサービ ス・アーキテクチャに基づくソフトウェア開発では歓迎されるでしょう。プロプライエタリな ソースコードを含むコンテナを
Docker Hub
で「売る」というエコシステムも、ユーザと販 売する企業に恩恵を与えるでしょう。ここにクラウド事業者が独自に提供する、データセン ター内限定のプロプライエタリ・マイクロコンテナがあったとしても、おかしくありません。強いていえば、コンテナに基づく流通を見落とした業者が販売経路を失う程度です。
ただしそこに至るには、
Docker
がユーザに信用を担保する必要があります。たとえばDocker 1.3
では、追加されたコンテナへの署名機能が追加されました。上記のようなコンテナの「流通」を
Docker Hub
が担保する上では、このような機能は必要不可欠です。ソフトウェアとしての
Docker
はオープンソースになっていますが、Docker
社は企業です。Docker
社がプラットフォームとして成功するには、単純にコンテナが勝手にアップロードさ*20 たとえばhttps://github.com/docker/docker/issues/611
*21 http://weblogs.asp.net/scottgu/docker-and-microsoft-integrating-docker-with-windows-server-and-microsoft-azure
れてダウンロードされるだけでは足りません。
Docker
プラットフォームは、アプリケーショ ンをサンドボックス上で実行する選択肢を提供し、その販売すら仲立ちする、OS
独立なプ ラットフォームを目指すかもしれません。現在見られるいくつかの諸機能と提携はそのよう な方向性を示唆しています。もちろんこのプラットフォーム拡大をすべてのユーザが歓迎することは有り得ません。た とえばごく単純に単なる
VM
代替としてLinux
のコンテナ技術をを使用したい場合、Docker
プラットフォームの増大し続ける複雑さは、逆に管理上の重荷になるはずです。Docker
アプ リケーションがすべての運用局面で安定して使えると仮定すること自体にも無理が生まれて きます。サーバサイドアプリケーションの開発に話を絞るとして、マイクロサービスに基づくアプ ローチが常によいわけではありません。開発スタイルを切り替えること自体にはコストが発 生しますし、細粒度化したことによる恩恵を受けられるかは個別のプロジェクトによります。
前述した筆者の例に登場するような大量のサンドボックス実行は自明に相性の良い稀有な プロジェクトです。開発者が成立させたい（マクロ）サービスの中で、このような小規模な
「マイクロサービス」に分解できるようなコンポーネントが自明に発見できて、それがサービ ス内に複数成立する必要性あるいは少なくともその意味があり、そのコンポーネントの廃棄や 再生成を行うことがマクロサービスを成立させる前提になっているのであれば、
Docker
コン テナを利用してマイクロサービス的に設計を行う有効性は高いでしょう。筆者など、Docker
を見て飛び上がって喜んだほどです。同様の性質をもつソフトウェアスタックは、おおよそDocker
コンテナと合う「側面をもつ」とは思います。そのような「自明」な分割が見いだせない状況では、より慎重な判断が必要です。そもそ も、分断された環境をまたぐソフトウェア開発を支援する技術は、結合したアプリケーション に対するそれと比べると、ひどく貧弱で未成熟です。現状では「複数の独立した環境向けの異 なるソフトを独立に開発してあとでくっつける」以上のものではありません。接合部を数学的 に検証するようなメカニズムの普及には時間がかかるでしょうし、そもそもこういった分野 は、現状の開発ではやや放置されがちな印象を筆者は持っています。
当座、コンポーネント間検証と調整は開発者が行うことになるのでしょう。しかし特に社内 開発というコンテクストであれば、この分離は単に無駄が発生しているだけのように感じるは ずです。マクロサービスを構成する個別のマイクロサービスに対して、担当者を個別に特定で き、それぞれが相互に物言いをできる体制になっていたりしない限り、モノリシックな設計に
して単一のビルドプロセスとしておくほうが、シンプルで迅速で、効果も高いはずです*22。 単なる並列・並行処理したいだけなら、まず落ち着いて、その分野特化した良い選択肢が ないかを考えたほうがよいでしょう。
Docker
がもつ良い性質は、既存の技術よりも特に複 数インスタンスの生成・破棄を伴う単一のユーザランドアプリケーションの実行に偏ってい ます。ハードウェアも含めて発達した処理機構をもつ仕組みが特定の分野で発達していれば、Docker
コンテナを敢えて使う必要性は全くありません。Kernel
やGPU
のレベルでの支援が前提となって発達している分野では、そもそもコンテナは使用できません。