コンテナーの世界！（４）－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）

  

データセンターOS（DCOS）は普及するか？

ついこの間まで、クラウド基盤はハードウェアを隠ぺいする仮想化技術の戦いだった。君臨するVMwareにXenを担いで挑戦したCitrix、そしてイスラエルのQumranetを買収してLinuxカーネルにKVMを導入したRed Hat。これらの戦いは一巡し、今は更なるリソースの効率化を求めてコンテナー技術競争が賑やかだ。Virtuozzo、Solaris Containers、そしてDockerが登場、さらには沢山のコンテナーをオーケストレーションするKubernetesが出た。一方、このような動きの陰で、データセンターOS（Data Center OS…DCOS）も動き出した。

＝データセンターOSの登場！＝ 
理屈はこうである。
これまでの仮想化を俯瞰すれば、それは無数のアプリが巨大なサーバーを共用する仕組みである（下図左）。言い方を変えれば、沢山のクライアント（アプリ）が中央サーバーを利用するクライアント/サーバー時代（Client-Server Era）の産物に似ている。これに対し、クラウド時代（Cloud Era）の特徴のひとつは、Big Dataなど強力なパワーを必要とするアプリケーションが複数のサーバーをクラスターのように集合体として束ねて（Aggregation）利用する（下図右）。つまり、個々のアプリや業務、さらには企業特有のスケーリング要求に合った利用環境をすばやく構築する技術が渇望されている。出来れば、適用するマシンは自前のデータセンターでもPrivate CloudやPublic Cloud上のVMでも構わない。今、利用できるマシン群から必要なものを組み合わせて論理的なデータセンターを構築したい。この仕組みを提供するのがデータセンターOSである。
 

Applications in the Cloud Era

＝市場を作り出せるか、Mesosphere！＝
この世界を切り開き始めているのはMesosphereだ。

Mesosphereとは地球を覆う大気圏の上位の熱圏と下位成層圏の間に位置する中間圏のことだ。Mesoはギリシャ語で中間を意味する。つまり、既存のITフレームワークと新たなスケーリング要求の間に入って、必要とするIT環境を素早く整備する。MesosphereのベースであるオープンソースのApache Mesosは、2009年、UC Berkeleyの学生たちが立ち上げた。そしてMesosは2013年にApacheのトップレベルのプロジェクトとなり、同年Mesosphereが創業。学生時代からのリーダBenjamin Hindman氏が現在のCEOとなった。Mesosを一言で言えば、分散アプリケーションの実行環境を多様なITリソースに跨って整備するクラスターマネージャーである。その上でアプリケーションを稼働させるにはスケジューラーとなるフレームワークが必要だ。下図の2つは、Linux/Unix OS StackとMesos OS Stackを比べたものだ。図で解るようにLinuxやUnixではInitやUpstart、Systemdなどのデーモンがアプリの起動や終了などのスケジュールを管理する。一方、Mesosでは、MesosがKernelとなって、ユーザは各アプリに適したものや慣れ親しんだフレームワーク（AuroraやChronos、Marathonなど）を指定して利用する。 これらがアプリを分散環境で実行するスケジューラとなる。 
  

Linux/Unix OS Stack

Mesos OS Stack

少し説明を加えると、AuroraはTwitterのBill Farner氏が開発して公開し、Apacheのプロジェクトになったものだ。Auroraはひとつの仕事をJob→Task→Processとして実行させる。ChronosはMesosphereのFounderの一人Florian Leibert氏がAirbnb時代に仲間と開発したタイムベースのスケジューラーでCronを分散環境用に置き換えた（Cronos Replacement for Cron）ものである。また、Mesosは通常、Apache Zookeeperと共に用い、Master/Slave方式のフォールトトレラント構成を採用する。この構成下で、Mesosphereが開発したMarathonはInitやUpstartなどと同様の機能を提供し、さらにZookeeperやChronosと連携してノードクラッシュの対応を行う。

＝これからどうなるか、気になるGoogle！＝
果たしてデータセンターOSは普及するだろうか。 

それを占う手掛かりはGoogleにあるのかもしれない。GoogleはDockerにいち早く目をつけ、自身でもオーケストレーションのKubernetesを開発して、OpenStackにプロジェクトMagnumを立ち上げた。一方、Mesosphereも2013年9月にはDockerを早々とサポートし、同年11月にはAmazon上で稼働（Mesosphere on AWS）させると発表。翌2014年8月、今度は、MesosphereはGoogleとチームアップし、GCP上での稼働（Mesosphere for Google Cloud Platform）とKubernetesの取り込みを発表した。GoogleはDockerの時と同じように、こうしてMesosphereとの距離を詰つつ、次の手を考えているように見える。そんな折、Googleは今年4月中、Memosと似た技術をLarge-Scale Cluster Management at Google with Borgとして公開した。公開の意図は何か。GoogleにとってBorgは自社データセンターの中核技術であり、Kubernetesはその延長線上にある。Kubernetesの普及が確実となった今、次はBorgが前面に出てくるのかもしれない。BorgがMesosと共存関係を歩むのか、競合するのか、それはまだ解らない。折しも6月9日、Mesosphereは2013年来のβ版を抜けてGA（General Availability）になり、有償でサポート付きのCommercial Versionと無償Community Versionを発表。本当の戦いが今始まろうとしている。

High Level Architecture of Borg

IBM/SoftlayerがOpenStackへシフト！ ‐IBM Cloud OpenStack Services for Public Cloud‐

IBMのOpenStack傾斜が鮮明になってきた。
5月19日、米IBMは「IBM Delivers Broadest Set of OpenStack Services」と題するプレスリリースを出した。企業向けPrivate Cloud（LocalやDedicated）に、同社はこれまで独自のOpenStackディストリビューションを提供してきたが、今回の発表はこれをさらにPublic Cloudまで拡大したものである。これによって、顧客のLocalやDedicatedなOpenStackアプリケーションはPublic Cloudとハイブリッド化が可能となる。

＝OpenStack化するSoftLayer！＝

少しIBMのOpenStackへの取り組みを整理しよう。
記憶をたどれば、最初に出た製品は2013年3月のSmartCloud Orchestratorだった。SoftLyer買収（2013年6月）以前である。異機種混合のハイブリッド管理ができるオーケストレーション機能付きのこの製品は、翌年、SoftLayer買収に伴うリブランドでIBM Cloud Orchestrator（ICO）となった。その後、エンタープライズ向けPrivate CloudにOpenStackが浸透し始めると、IBMは本格的な製品としてIBM Cloud Manager with OpenStack（ICMO）を出荷（昨年5月発表）。この結果、ICOはICMOの上位エディションと位置づけられた。さらに時代が進み昨年10月、IBM Cloud OpenStack Services（ICOS）をリリース。ICOSはSoftLayer上にOpenStackのPrivate Cloud（Dedicated）を構築するサービスである。つまり、IBMはこれまでICMOやICOを用いてエンタープライズ向けのPrivate Cloud（Local）構築を支援してきたが、ICOSの発表でDedicatedなサービスにも乗り出した。

＝２つのアプローチ！＝
ここまで来れば、次なる戦略がPublic Cloud対応であることは明らかだ。

課題はSoftLayerとOpenStackをどう調和させるかである。IBMの取り組みは2つ。ひとつは2014年2月に発表したJumpgate。これはOpenStack APIを他のクラウドに変換させるミドルウェアレイヤーとしてライブラリー整備を進めるものだ。これが出来ればSoftLayerだけでなく、理論上はAWSなどへの適用も可能である。実際のところ、OpenStack APIを他のクラウド基盤に適用する方法は、他にもCloudscaling（現EMC傘下）のOpen Cloud System（OCS）やVMwareのVMware Integrated OpenStack（VIO）がある。（各々既報があるのでそれらを参照されたい（既報OCS、既報VIO）。ただ、これらの方法はOpenStack APIと連携させるクラウド基盤との機能マッピングが必須となり、かなりの作業が伴う。IBMの始めたJumpgateプロジェクトもまさに現在進行形である。そして、同社のもうひとつの取り組みが今回発表したものだ。これはSoftLayerが提供するベアメタル上にOpenStackインフラを展開したもので、SoftLayerとOpenStackインフラが併存する形だ。

＝OpenStackのハイブリッド化！＝
今回IBMが発表したICOS型のOpenStack Public Cloudは、現在、PaaS領域のBluemixで利用が出来るβ版だが、いずれ正式版となろう。そうなれば、これまでのオンプレのLocalなもの（ICMOやICO）や、ICOSによるSoftLayer上のDedicatedなもの、これらは共にPrivate Cloudであるので、ハイブリッド化が可能となる。IBMによると、このプロジェクトに約500名のデベロッパーを投入してきた。これが正式リリースとなれば、開発（Bluemix）から構築・本番まで、全てのOpenStackワークロードを自由に行き来させ、ハイブリッドの効果を最大化出来る。

＝Magic Quadrantに見るSoftLayer！＝
さて、5月18日、恒例のMagic Quadrant for Cloud IaaS 2015がGartnerから出た（下段上図）。それによると、リーダグループを形成するツートップのAWSとAzureの差が少し詰まってきた。Amazonは既報のように好調だが、Microsoftが追い上げている。続くビジョナリーグループは、昨年（下段下図）と比べると、異変が起きている。ひとつはCentulyLinkをGoogleが激しく追い上げていることだ。これはこのところのDocker対応やGoogleが始めたコンテナーオーケストレーションKubernetesなどが上手く機能し始めたことによるのだろう。もうひとつの変化はVMwareのvCloud Airが好調なことだ。その結果、IBMはやや埋没気味に見える。

＝結果はどれだけ早く走るかだ！＝
勿論、IBMの目指すPublic Cloudは、エンタープライズが主戦場であり、AmazonやGoogleとは異なる。しかし、同じエンタープライズ指向でもMicrosoftは善戦している。クラウドは仮想化技術の延長線上で始まり、今は更なる効率化を求めてコンテナーの扱いが花盛りだ。Microsoftは昨年夏にAzureでDockerとKubernetesをサポートし、この5月からは次期Windows Server 2016（含むNano Server）Technical Preview 2のパブリックレビューが始まった（このあたりの流れは前回号に詳述）。IBMも昨年7月にはKubernetesの支持を表明し、12月にはDockerと戦略的提携を発表、デッドヒートが繰り広げられている。翻って、Microsoftの企業ユーザに比べて、IBMの抱えるユーザはより大型だ。期待される要求も異なる。取り分け、これら大型ユーザのPrivate Cloudに対するOpenStackニーズは高い。これへの対応が一連のOpenStack傾斜である。これは正しい選択だろう。しかし、クラウドは技術が先乗りのビジネスである。GoogleはMirantisと組んでDocker/KubernetesをOpenStackに持ち込み、正式なプロジェクトMagnumとなった。幸いなことに、StackAｌｙticsを見ると、現在、このプロジェクトへの最大の貢献は、全体の32％をIBMが占める。遅れは許されない。出来るだけ早く、Magnumを適用できれば勝機が見える。そんな矢先、IBMは6月3日、OpenStackベースのHosted Cloud Provider、Blue Boxを買収した。今やIBMにとって、OpenStackのトラックをどれだけ早く走るかが勝負の分かれ目である。

コンテナーの世界！（２） －Kubernetesで息を吹き返えしたGoogle！ そしてAtomic Host, CoreOS, Snappy, Nano－

コンテナー技術の生い立ちと動向については前回述べた。
今の流れは２つある。ひとつは人気のDockerはほぼデファクトとなったが、その周りに出来つつあるエコシステムがどこまで広がるかだ。もうひとつは関連する専用OS化の流れである。今回はこの辺りを整理しよう。

＝Google Kubernatesプロジェクトが惹きつけるもの！＝
この分野でGoogleの動きは積極的だ。 

Googleは昨年11月、Google Cloud Platform LiveでDockerベースのGoogle Container Engine（GKE-現在パブリックα）を発表した。これはDockerに対抗するものではない。GKEはGoogle Cloud Platform（GCP）上でDockerコンテナーを実行する新しいサービスだ。そして自身が開発した膨大な数のコンテナー制御のクラスターオーケストレーションフレームワークKubernetesと連携する。元々このKubernetesはGKEと連携させるために始まったものだが、オープンソースプロジェクトとしてローンチし たのは昨年6月のGoogle I/O 2014だった。すぐに多くのデベロッパーやベンダーを惹きつけて、翌月には本家のDockerやCoreOS、IBM、Mesosphere、 Microsoft、RedHat、SaltStackなどが相次いでサポートを表明した。クラウド化を実践してきた米企業にとって、コンテナーは魅力的だが、その運用には不満もある。大規模システムをサポートするベンダーやプロバイダーは、この不満の解決策をKubernetesに見出した。既にAWSではDockerとElastic Beanstalkが連携し、AzureでもDockerサービスが始まっている。しかしAmazonのElastic Beanstalkは基本的にVMセントリックなフレームワークだが、Kubernetesはコンテナーセントリックだ。Googleの戦略はこれを公開してデファクトとし、Dockerを超えた新たなエコシステム目指すことのようだ。

＝Project Atomic、CoreOS、Ubunture Core！＝
もうひとつはDockerのための専用OS化の流れである。

昨年末、Red HatからDocker対応の専用OSとしてRed Hat Enterprise Linux 7 Atomic Host βが発表され、今年3月5日には、RHEL 7.1と共に正式版となった。遡ればRed HatがスポンサーのProject Atomicは、2013年から始まった。プロジェクトの開始時点では独自のコンテナー技術geardを目指したが、Docker人気でgeardからDockerに方向転換。その後Google Kubernatesがローンチし、Red Hatは直ちに支持を表明。こうしてProject AtomicにKubernetesが追加された。公開されたAtomic Host 7.1は、RHEL 7.1のインストーラが約4,400のパッケージ数であるのに対し、約400と必要最小限の構成だ。RHEL Atomic Hostはエンタープライズ向けだが、他に関連製品として将来志向の無償Fedora AtomicやRHELと完全互換を目指した無償のCentOS Atomic Hostもある。しかし、この分野で最初にDocker対応を出したのはCoreOSだ。正式版は昨年7月、Googleとの関係は深い。すぐにGoogle Compute Engine上でCoreOSのサポートが始まり、今年4月にはKubernetes対応のTectonicをリリース。同時にGoogle Venturesがリードした資金調達では$12M（14.4億円）を獲得。またもうひとつ、今年1月、CanonicalからもSnappy Ubuntu Core βが出た。これはクラウド展開がメインだが、それだけではなく、今後はIoTなどへの適用も目指している。

＝Microsoft AzureとWindows Nano Server！＝
もう1社のMicrosoftはどうか。

Microsoftは他ベンダーと共にKubernetesの支持を表明し、同社子会社のMicrosoft Open Technologiesから、昨年夏、Azure上でのDockerとKubernetesサポートがリリースされた。たった2ヶ月の早業だった。且つ、このインプリメントではKubernetesで管理するDockerコンテナーがビジュアルで確認できる。そのダッシュボードはAzureチームが主催したハッカソンで選ばれたAzure Kubernetes Vizualizerだ。さてもうひとつ目玉はどうか。昨年10月、前述のMicrosoft Open TechnologiesからWindowsによるDockerサポートの発表があった。その後もカンファレンスで何度か触れられたが、今年4月初め、正式にWindows Serverの次期版Windows Server 2016でコンテナー対応OSが出るとアナウンスがあった。最小構成版のNano Serverである。 

具体的には、Microsoft Open TechnologiesがDockerと提携して作業し、Docker EngineをWindowsに統合する。5月初めからレビューの始まったWindows Server 2016 Technical Preview 2では、Nono Serverはほんの一部しか窺うことが出来なかった。これまでのアナウンスでWindows Server 2016ではWindows Server ContainerとHyper-V Containerの２つのコンテナーを扱う。これらが本当の姿を現すのはTechnical Preview 3以降のようだ。

＝新たなエコーシステムを目指す！＝

OpenStackでもDockerやKubernetes対応が始まっている。
今年2月、GoogleがMirantisと組んでこれらを統合するとアナウンスした。その後、このプロジェクトは、3月にOpenStackの正式なプロジェクトMagnumとなった。5月18日から始まったOpenStack Summit Vancouver 2015でその詳細が姿を現した。それによると、MagnumはKubernetesやDocker Swanだけでなく、OpenStack自身が進めていたHeatなどとも連携する。Dockerが火をつけたコンテナー技術が他のVirtuozzoやSolaris Containerと決定的に異なるのは、前２者がひとつのコンテナー内で走るプログラムは複数プロセスから構成されるのに対し、LinuxコンテナーのDockerでは、ひとつのコンテナーにはひとつのプロセスしか走らない。それ故、単純な仕事でも複数のコンテナーを必要とし、大 きなアプリケーションでは無数のコンテナーの管理が必要となる。この点を改善したものがGoogleのKubernetesだ。もうひとつ、Dockerの利点はモビリティー（携行性）にある。つまり、Docker環境さえあれば、どのマシンやクラウド空間でもコンテナーの内容をイメージとして持ち出し、実行させることが出来る。これによって、PaaSの世界も様変わりが始まった。
こうしてVMwareやXenの仮想化技術で始まった現代のクラウドコンピューティングは、再度、コンテナーで大きなうねりとなって動き出した。もう図抜けた1社の技術で全体が動く時代ではない。ひとつの技術に幾つもの会社が関わり、さらに広大なコミュニティーとなって、新たなエコシステムが出来上がる。こうなれば本物である。

2015年１Qクラウド決算分析 －Amazon堅調、Microsoftも好調、IBMはどうか ・・・そしてRackspaceの売却再燃か－

＝Amazon独走鮮明に！＝
Synergy Resarchから１Qのクラウド各社の決算が出揃ったのを受け、分析結果が発表された。この分析はIaaSとPaaSに限られるが、Publicだけでなく、PrivateやHybridも含まれている。１Qの結果（下図-上）を見るとAmazonの売り上げが他の4社（Salesforce、Microsoft、IBM、Google）合計よりも大きく、その強さが際立った。過去と対比すればさらに良く解る。（下図-下）では、Iaas/Paasのクラウド市場は2013年から2014年にかけて世界で45％成長したが、 Amazonの成長率はそれより大きく49％だった。2014年2Q時の市場規模は推定で$3.7B（4,440億円-120円/㌦）、これを年間に引き延ばすと$13B（1兆5,600億円）となる。この時点でAmazonの売り上げは四半期当たり$1B（1,200億円）を超えているとみられた。そして、当ブログでも既報のように、Amazonは今年1Q決算からAWSの詳細なデータを公表した。それによると、昨年度売り上げは各期とも確かに$1Bを超えており、Synergy Resarchの調査が正確だったことが解る。そしてAWSの昨年度売り上げ合計は$4.6B（約5,500億円超）、営業利益は$660M（792億円）となった。今年度は$5B（6,000億円）が目標だ。

 

 

＝価格競争の激化！＝
もうひとつ参考になる報告がある。ITcadorからのものだ。このグラフは各期のデコボコを平準化するために四半期ローリングを施したもので解り易い。結果、Amazonの売り上げは順調に伸びているが、利益は昨年度初めを頂点に下降線をたどり、このところは横ばいであることが解る。この落ち込みは価格競争だった。その引き金を引いたのは、昨年3月、Googleによる30～85％という大幅な値引きアナウンスだ。これには直ぐにAmazonもMicrosoftも追従し、価格競争が激化した。

＝IBMは売り上げ$7.7B、Microsoftは$6.3Bと主張！＝
IBMやMicrosoftはどうなったか。
4月20日のIBMの発表によれば、IBM全体の売り上げは12%減であったが、クラウド売り上げは何と$7.7B（9,240億円）、前年比75%アップだという。 Amazonの昨年度売り上げが$4.6Bだからとんでもなく大きい。しかし、これにはソフト/ハード/サービスが含まれているので、このままの比較は禁物だ。IBMはまたカンファレンスコールの中でSoftLayerについては2桁の成長だったと触れただけだった。Microsoftの場合は年度決算が6月末なので発表された3Q Resultによると、（これも計上方法が異なるので直接の比較はできないが）SaaSに該当するOffice ３５６が1,240万人のサブスクライバ-となって35%増、さらにＤｙｎａｍｉｃs ＣＲＭが続き、そして本命のAzureを加えた総売り上げは$6.3B（7,560億円）となり、106%のアップだという。

＝Rackspaceの売却再燃か！＝
ところでRackspaceの売却問題が再燃しそうな気配である。
1Q決算があまり良くなかったことに加え、市場環境が変わってきたからだ。この問題については、昨年、ホワイトナイト探しとして何度か報告（報告１、報告2 報告3）したが、9月17日以降は沙汰やみとなっていた。同社1Q決算は、売り上げ$480M（576億円）となり、前年同期比14.1%のアップ、利益は$28M（33.6億円）で前年同期比マイナス6.0%となった。この利益幅の減少は強いドルによる海外売り上げの為替が作用したもので、内容はそれほど酷いものではなかった。

問題は今後の見通しである。決算発表後のカンファレンスコールで、同社幹部が2Qの利益予想は1.5-2.5%程度だと言及した。売り上げや利益が伸びても、為替の影響でドル建て決算が厳しくなる現象は、IBMやMicrosoftでも表れている。特にRackspaceのようなサービスのみを扱う中堅企業にとっては緩和策が見当たらず、頭の痛い問題だ。他方、クラウド市場に目を転じると、この半年で市場環境は大分変ってきた。独走するAWSのIPOを睨んだスピンオフが見え始め、Microsoftもエンタープライズ市場が好調だ。一方でHPがPublic Cloudから離脱（ 記事１、 記事2 ）するのではないかという噂が流れたり、IBM SoftLayerやGoogle Cloud Platformは伸び悩んでいるように見える。業界筋は、これらの企業がRackspaceを傘下に置けば、彼らの立場は大きく変わるだろうという。勿論、彼らだけでなく、米キャリアの再挑戦があるかもしれないし、Microsoftにだって十分に可能性がある。Rackspaceにとっては、直ぐではないかも知れないが、これは独立独歩路線を変える最後のチャンスかもしれない。同社のマーケットキャップは、5月15日現在、$6.32B（7,584億円）だ。