コンテナーの世界！（４）－SDSスタートアップ －Portworx & ClusterHQ－

前回、コンテナー技術を標準化するOpen Container Projectについて述べた。
それにしても、このところのDocker人気は凄く、その周りにスタートアップがエコシステムを形成するようになってきた。今回はそれらの中から、Docker向けストレージの利便性向上を目指す２社を紹介しよう。

＝Docker向けスケールアウトブロックストレージ－Portworx！＝
初めに紹介するPortworxは6月にステルスモードから抜けでたばかりだ。同社はSDS（Software Defined Storage）製品を鋭意開発中である。Docker人気の陰でストレージの扱いは課題となっていた。Dockerは同一OS上で仮想空間のコンテナーを複数稼働させて、各種リソースの効率化を図る。しかし幾つものコンテナーからなるアプリと膨大な容量のストレージのプロビジョニングは容易ではない。加えて開発段階と本番、さらには使用条件によってその要求は変わる。同社が開発しているPortworx PWXは、ローカルでもクラウドでも構わず、全てのストレージをブロックの仮想プールとして扱い、それらをステートフルなアプリにスケールアウトさせながら提供する。現在はSandBox（α）段階だが、今夏にはプレビュー版（β）が予定されている。

同社幹部はTintriがVMセントリックなSSD利用のハイブリッドで成功しているように、PWXもよりDockerセントリックなストレージ提供を目指すと明言する（Tintriに関する記事）。つまり、Docker本来にはないマルチノード間のデータベースのポータビリティー（Portability: 携行性）やコンシステンシー（Consistency: 一貫性）を保持し、さらにスナップショットやレプリケーションについても計画中だ。これによってDockerユーザのストレージに関する利便性を大きく向上させる。ただ、これらは前回述べたOCPの課題と一部重なる可能性もあり、その際は調整が必要となるだろう。同社はまた、先月中旬、DellのMicheal Dell氏とMayfieldからシリーズAとして$8.5M（約10億円）の資金を調達した。実際のところ、Portworxの経営陣3人は、Dellが2010年に買収したOcarina NetworkのCo-Founderだ。今後、Dellとの関係も要注意である。

＝コンテナーアプリ向け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社の問題意識＝
以上見てきたように、上記２社の問題意識は良く似ている。
2社ともコンテナー利用におけるストレージの継続性をテーマとし、そのために扱うストレージをブロックとしてプールする。Portworxは汎用的なストレージシステムを目指して開発を進め、ClusterHQ FlockerはZFSを利用して、その上により利便性のある機能を提供する。言い換えれば、Portworxはコンテナーストレージのインフラに挑戦し、FlockerはインフラはZFSに任せて、ストレージのPaaS化に力点を置いている。今後の両社の開発に注目したい。

コンテナーの世界（３）－コンテナー戦争に終止符を！ －Open Container Project－

少し遅れたがOpen Container Project（OCP）について述べようと思う。
このプロジェクトは6月22日、DockerCon 2015でローンチした。コンテナー戦争に終止符を打つためだ。これまでのDockerのプレゼンは我こそが実質的にデファクトであり、正統な技術だと言わんがばかりだった。しかし昨年末CoreOSがこの分野に参入、さらにDockerへの一部批判もあってややこしくなってきた。この状況を打開するために、Linux Foundationのガバナンスのもとで始まったのがOCPである。

＝これまでの流れと解決すべき課題！＝
現在のコンテナー技術はLinuxカーネルの仮想化機能を利用している。

本家、Linuxからはこの機能を使ったLinux Containers（LXC）が登場した。LXCの構造はシンプルだ。その分、周りの機能が十分ではなく、Dockerはまさにこの分野を先取りして人気を得てきた。初期のDocker 0.9まではLXCをデフォルトとしてLinuxカーネルとインターフェースさせたが、その後、別なドライバーlibcontainerを開発して置き換えた（関連記事）。昨年末になると、軽量Linuxディストリビューションを開発するCoreOSが動き出した。CoreOSが初めに公開したRocketはプロトタイプのコンテナー実行環境（ランタイム）でDockerと完全に競合する。その後、Rocketはrkt（rock-it）と改称し、関連する仕様はApplication Container Specificationとして公開された。この仕様にはラインタイムやコンテナーのイメージフォーマットなど幾つかの要素が含まれている（後述）。こうしてCoreOSのrktがDockerに挑戦する構図となった。何故こうなったのか。それにはDockerに対する問題意識がある。セキュリティーの甘さやファイルの使い勝手、レジストリの不便さなどだ。Dockerが真のデファクトを目指すなら、これらへの総合的な対応が必須となる。つまりプラットフォームとしての全体スケッチが重要だ。さらに言うなら、Dockerランタイムさえあれば、どこでも実行できるという彼らのコンセプトは頂けない。ベンダーロックインそのものだという批判のBoycott Dockerというサイトまで現れた。

＝OCPの目的＝
OCPは発足に際し、「この2年、コンテナーベースのソリューションへの興味と利用は急増している。殆どのITベンダーやクラウドプロバイダーはその対応を発表しており、さらに関連するスタートアップも増えている。 このような状況は好ましいことではあるが、課題も多い。取り分け、コンテナーのポータビリティー（携行性）には、そのフォーマットとランタイムの標準化が望まれている。つまり、特定のクライアントやオーケストレーションスタックに依存せず、商用ベンダーやプロジェクトにも拘束されることなく、さらにOSやCPUアーキテクチャーなどのハードウェア、そして個別クラウド仕様にも従属されない、よりフォーマルでオープンな業界標準への対応が必要となっている」と説明した。この趣旨に沿って、プロジェクトはOpenDaylightやOpen Virtualization Allianceなどと同様、Linux Foudatonのコラボレーションプロジェクトのひとつとなった。スポンサーとなったのは、Apcera, AWS, Cisco, CoreOS, Docker, EMC, Fujitsu, Google, Goldman Sachs, HP, Huawei, IBM, Intel, Joyent, Pivotal, the Linux Foundation, Mesosphere, Microsoft, Rancher, Red Hat, VMWareなどだ。

＝標準コンテナーの5つの原則＝
計画の実行にあたって、Dockerからはイメージフォーマットとランタイムのコードなどが寄贈された。作業面ではCoreOSが技術的なリーダーシップをとる予定だ。最初の仕事は新仕様書を作成すること、現在、鋭意作業中である。この下敷きは勿論CoreOSのApplicationContainer Specificationで、①App Container Image（実行に必要なイメージファイルやメタデータの形式）、② App Container Image Discovery（イメージファイルの探し出しに必要なイメージ名と場所・署名・公開鍵の規定）、③App Container Pod-Pod（複数アプリコンテナーのグループ化規定）、④App Container Executor（Podの実行に関する規定）が含まれている。一方、作成中の新仕様書には、その前提となる「標準コンテナーの5つの要件（The 5 Principals of Standard Containers）」が定められている。

　　　　① Standard Operations（標準操作）
　　　　② Content-agnostic（コンテンツ非依存型）
　　　　③ Infrastructure-agnostic（インフラ非依存型）
　　　　④ Design for automation（自動化デザイン）
　　　　⑤ Industrial-grade delivery（業界標準の提供）

＝これからどうなるか！＝
コンテナー技術が注目されてたった２年。
Dockerが独走してきたが、この流れにデベロッパーやCoreOSが異論を唱え出した。コンテナー技術の周りでは、既に軽量OSの動きも顕在化したが、これらは全てLinuxの土俵上のことで、上手く回っている。Dockerがこれまでのようにあまり強調しすぎると、新たなOSの登場のように映る。しかし、現在はDockerも事情が呑み込めて、OCPに協力的だ。OCPの活動を通して、コンテナー仕様が標準化され、ベンダーが競い合って、安全で、使い易く、より高いリソース削減が出来る製品が開発されることが望まれている。そうすれば次なる時代が見えてくる。

OpenStackプレイヤーの統合は終わったか！

昨年来、OpenStackを取り巻くプレイヤーは慌ただしかった。
それらの状況はこのブログでも何度か取り上げた。そのような中、Forbesの「OpenStackの統合は（殆ど）終わった-OpenStack Consolidation is (almost) complete」という記事が目についた。RackspaceとNasa Amesが2010年夏、結束してAWS対抗として始めたOpenStackプロジェクト。その後は多くの賛同を得て、企業メンバーも300社以上に膨らみ、関連プレイヤーも増え、2012年秋にはOpenStack Foundationとなった。現在、Best BuyやBloomberg、CERN、Comcast、Ericson、Intel、PayPal、Walt Disney、WebExなど名だたる企業がOpenStackを導入している。大手企業の採用が進むと、当然のことのように関連プレイヤーに注目が集まり、大手企業による買収合戦が始まった。まさに時代の変わり目である。

＝どのように統合が進んだのか！＝
ここで、これらOpenStackプレイヤーたちの統合がどのように進んだのか、時系列的に振り返ってみようと思う。

2014/9 by Cisco

＜Metacloud＞　CiscoがMetacloudを買収したのは昨年の9月、同社の進めるCisco Intercloud Fabric（以下、Intercloud）を補完するためだった。複数のPublic Cloudを連携させ、ハイブリッド化を促進させるIntercloudの成功には、企業クラウドの導入が大前提となる。こうして白羽の矢がたったのがMetacloudだ。同社のビジネスモデルは、独自のOpenStackディストリビューションを提供し、24H遠隔監視をするOpenStack-as-a-Serviceだ。このプラットフォームを整備し直したのがCisco OpenStack Private Cloudである。（Intercloud＆Metacloud 詳細記事）
 

2014/10 by EMC

 ＜Cloudscaling＞ 次に動いたのはEMC。昨年10月、Cloudscalingを買収した。金額は$50M（60億円）弱と伝えられている。この会社の価値はFounderのRandy Bias氏とその製品だ。彼はこの世界では誰もが認めるオープンシステムの主唱者（Advocate）であり、OpenStackベースの製品はOCS（Open Cloud System）アーキテクチャを採用、AWSやGoogle Cloud Platformなどとのハイブリッド化が可能だ。EMCは傘下のVMwareやPivotalなどグループ全体の戦略再構築に彼の意見やCloudscaling製品を参考にしているに違いない。
（Cloudscaling 詳細記事）

2015/4 Shutdown

＜Nebula＞　NebulaはNASAのNebula Cloudを指揮していたChis Kemp氏が2011年に興した会社だ。そのNubulaは今年4月にシャットダウン。実際のところ、元祖OpenStackの一翼（NovaをCompute EngineとしてOpenStackプロジェクトに寄贈）を担ったNASA Nebulaは、写真のような外置きのContainer Datacenterで、導入・運用性に優れていた。 Kemp氏が目指した製品Nebula Oneは、これをイメージして、全てが組み込まれアプライアンスだった。Nubula OneはX86ベースのNebula Cloud Controllerを核に最大40台のサーバーをスケールアウトさせたが、それでも、既存サーバー製品と差別化し、ユーザを惹きつけるには至らなかった。このために著名なVCから集めた資金は$38.5M（46.2億円）。シャットダウンに前後して、主なエンジニア40名はOracleに移籍した。

2015/6 by IBM

＜Bluebox cloud＞　Bluebox Cloudの買収には予兆があった。このところ、中小企業向けのHosted Private Cloudが活況だからだ。この業界のツートップはVirtustreamとDatapipe。そして今年5月、EMCによるVirtustream買収が実行された。$1.2B（1,440億円）という高額だ。SoftLayerが$2Bだと伝えられているので、如何に高値取引かが解るだろう。彼らのプラットフォームを見ると、Virtustreamは独自開発、DatapipeはCloudStackだ。Private CloudでOpenStack指向を強めるIBMにとって、残されたプロバイダーのうち、BlueboxだけがOpenStackだった。 これはラッキーだ。これまでに同社はIBM Cloud Manager with OpenStackを出荷し、そのホスティングをIBM Cloud OpenStack Servicesとしてリリースしている。今回のBlueboxがこの分野を補強することは間違いない。問題はどのように製品とサービスを統合するかである。（IBM/SoftLayerがOpenStackへシフト！詳細記事）

2015/6 by Cisco

＜Piston Cloud Computing＞　Ciscoも再度6月始め、Piston Cloud Computingの買収を発表。前述のMetacloudに次ぐ第2弾である。同社は独自OpenStackディストリビューションをUSBデバイスで配布して、複数クラスターのPrivate Cloudを容易に構築するビジネスとして始まった。その後、配布方法はダウンロードに代わり、さらにディストリビューションのアップデートを改良。現在の製品CloudOSは コンテナーやBig Data対応などを強化したものだ。さてCiscoはどうするだろう。考えられるシナリオは２つ。ひとつはMetacloudと併存させる形でPrivate Cloud製品を強化する。もうひとつは、Pistonの配布アップデート技術をMetacloudと統合させることだ。どうなるかは要注意だが、Ciscoは着々とIntercloud戦略を進めている。
 （Piston Cloud Computing 詳細記事 ）

＝その他の買収！＝　

OpenStackそのものではないが関係した買収もあった。 2013年3月、OracleがNimbula買収を発表。NimbulaはAWSのEC2を開発したエンジニア2人が興した会社で、新しいクラウドプラットフォームNimbula Directorを開発していた。しかし、Oracleのこの買収劇は、結果的にプロダクトを細々サポートするに留まり、上手く行かなかった。同社創業者のひとりChris Pinham氏は、1年間Oracleにいたが現在はTwitterのEngineering VP、もうひとりのWillem van Biljon氏は最初からOracleには移籍しなかった。また昨年9月には、HPもEucalyptusを買収。Rackspaceのホワイトナイト探しの最中だった。現在、HPはHelionとEucalyptusを併存させている。AWSへのブリッジはともかく、この買収が成功だったのかは疑問が残る。（Eucalyptus 詳細記事）

＝MirantisとRackspaceはどうなる！＝
残ったOpenStackプレイヤーはMirantisとRackspaceのみだ。彼らが今後どうなるかを占うレポートがある。 Forresterから出た「OpenStack Is Ready - Are You?」（OpenStackサイト参照）だ。このレポートはOpenStack Foundationが昨年暮れに行ったサーベイを彼らの視点でまとめたものである。下図から解るようにFortuneにリストされる大企業で導入が進んでいる。プロジェクトで見るとOpenStackのキーコンポーネントであるNova（Computeエンジン）、Keystone（ID統合管理）、Glance（イメージ管理）、Horizon（管理コンソール）などだけでなく、ファイル（SwiftやCinder）やネットワーク（Neutron）まで利用が進んでいる。OpenStackは実質、デファクトに近づいているが、一方で、かなり複雑なためシステム力がないと自社構築は難しい。

Forrester：　OpenStack Is Ready - Are You?

このような状況が好感され、MirantisはVCから昨年10月、何と$100M（120億円）の資金を調達 、そして、日本にも事務所を開設した。MirantisはOpenStack最強のSIベンダーだ。その実力は周知のとおりである（Mirantis詳細記事）。目指すはIPOだ。もう一方のRackspaceはNasdaq上場企業だが、このところ成長に陰りが見えていた。AmazonやGoogle、Microsoftは体力を武器に猛烈な価格競争を仕掛けてくる。OpenStackベースのPublic Cloudを運営するRackspaceに勝ち目はない。そこで現在、注力しているのはこれら3大クラウドと競合するのではなく、彼らのユーザにホスティングだけでなく各種のエンジニアリングサービスを提供し、共存する道である。結果、5月中旬に発表された今年1Qの決算は好調だった。5月中旬、同社はマルチクラウドのセキュリティー管理スタートアップScaleFTにシードファンドとして$800K（9,600万円）を投資した。複数クラウドに跨ったシステムのセキュリティーを容易にする技術だ。これはRackspaceの生きる道にとって先見性ある判断である。これなら何とかやっていけるかもしれない。　（Rackspace 関連記事1、2、3）