それにしても、このところのDocker人気は凄く、その周りにスタートアップがエコシステムを形成するようになってきた。今回はそれらの中から、Docker向けストレージの利便性向上を目指す２社を紹介しよう。
初めに紹介するPortworxは6月にステルスモードから抜けでたばかりだ。同社はSDS（Software Defined Storage）製品を鋭意開発中である。Docker人気の陰でストレージの扱いは課題となっていた。Dockerは同一OS上で仮想空間のコンテナーを複数稼働させて、各種リソースの効率化を図る。しかし幾つものコンテナーからなるアプリと膨大な容量のストレージのプロビジョニングは容易ではない。加えて開発段階と本番、さらには使用条件によってその要求は変わる。同社が開発しているPortworx PWXは、ローカルでもクラウドでも構わず、全てのストレージをブロックの仮想プールとして扱い、それらをステートフルなアプリにスケールアウトさせながら提供する。現在はSandBox（α）段階だが、今夏にはプレビュー版（β）が予定されている。
＝コンテナーアプリ向けData Volume Manager－ClusterHQ！＝
次に紹介するのはClusterHQ、設立は2008年。当初は別な開発を手掛けていたが、コンテナーの時代が到来した。そして今年2月シリーズAで$12M（約14億円）を集め、集めた資金合計は$16.6M（約20億円）となった。取り組んでいるのはストレージのライブマイグレーションだ。通常、コンテナーアプリを他のコンテナーに移動させる場合、そのストレージを引き連れることは出来ない。この課題に対するClusterHQの出した答えがFlockerである。
Flockerを使えば、Flocker APIやCLIで起動した別のコンテナーアプリにメッセージキューイングのRabbitMQや、MySQL／PostgreSQL、さらに分散DBのRiakなどステートフルなデータマイグレーションできる。Flockerの仕組みはこうなっている。コンテナーが実行される個々のホスト（Node）にはFlocker Agentが乗り、それらをFlocker Controllerが制御する。この仕組みをベースに、機能的にはフロントとバックエンドがある。フロントはネットワークプロキシレイヤーとなって、IPアドレス制御やルーティングを担当し、バックエンドはZFSを用いたデータボリュームレイヤーとなる。Dockerではコンテナーとデータボリュームはタイトな関係になっているが、Flockerではコンテナーアプリとデータボリュームが一緒に移動できる。実際にはZFSの持つクローン機能を使って相手先のアプリのデータボリュームを逐次アップデートする。この際、オリジナルのデータボリュームはRead/Writeが出来るが、受けて側はReadのみだ。つまり、オーナーシップがあって、これをハンドオフで切り替えることも出来る。勿論、扱うデータボリュームはローカルでもクラウド（AWS Elastic Block Storage (EBS)、OpenStack Cinder、EMC ScaleIO & XtremIO）上でも構わない。同社は昨年8月、Flocker 0.1（α）をリリース、今年6月には1.0（正式版）となった。
以上見てきたように、上記２社の問題意識は良く似ている。
2社ともコンテナー利用におけるストレージの継続性をテーマとし、そのために扱うストレージをブロックとしてプールする。Portworxは汎用的なストレージシステムを目指して開発を進め、ClusterHQ FlockerはZFSを利用して、その上により利便性のある機能を提供する。言い換えれば、Portworxはコンテナーストレージのインフラに挑戦し、FlockerはインフラはZFSに任せて、ストレージのPaaS化に力点を置いている。今後の両社の開発に注目したい。
