OpenStackのJunoリリースはビッグデータとネットワーク仮想化が目玉

パブリックやプライベートのクラウドを構築するための基盤となるオープンソースのソフトウェアOpenStackは、業界の多様な大物たちが支えている。その同社が今日(米国時間10/16)、最新リリースJunoをローンチした。

いつもと同じくこのリリースにも、このプラットホームのサービスすべてにわたるアップデートが含まれている。それらはクラウドコンピューティングからストレージサービス、アイデンティティ管理、大量のデータを処理するためのツールなど、多岐にわたる。しかし今日のリリースのハイライトは、ビッグデータクラスタの配備を自動化する新たなデータ処理サービスが加わったこと、Object Storageのポリシーコントロールの粒度の柔軟化、そして、主に通信業界のOpenStackユーザから求められていたネットワーク機能の仮想化(network function virtualization, NFV)が初めてサポートされたことだ。

OpenStack FoundationのCOO Mark Collierによると、このリリースにはOpenStackのユーザとオペレータの意向が色濃く反映している。その最強の例が、たぶんNFVだろう。“これは、OpenStackにとってとても大きな機会になるだろう”、とCollierは言う。通信企業や自前のネットワークを持つ大企業などは、NFVによってネットワーキングサービスの多くを高価なプロプライエタリのハードウェアからコモディティの(==安価な日用品的)サーバに移せる。それは巨額なコスト節減をもたらすが、しかしそのためのソフトウェアには非常に高度な安定性と、リアルタイムの高パフォーマンスが要求される。

Collierはこう述べる: “もしもぼくが通信企業で音声通話用のハードウェアシステムをソフトウェアに移行させたいと思ったら、そういう仮想化を行うレイヤで通話が絶対に落ちないことを事前に確証する必要がある”。そこで今回の最初のリリースでは、高パフォーマンスの安定供給に力を入れ、さらに今後のリリースでは機能の多様化を図りたい、という。

OpenStackのJunoリリースには、新しいデータ処理サービスが加わる。これによって、ビッグデータ分析のためのHadoopやSparkクラスタの配備と管理が自動化される。このサービスは単純なApache Hadoopのサービスとしてスタートしたが、その後徐々に、HortonWorksやClouderaのHadoopサービス、それにSparkも加えていった。

また、上でも触れた、OpenStackのObject Storageのポリシーの粒度をより細かく管理できることも、多くのユーザにとって重要だ、とCollierは指摘する。これによってユーザは、複数のバックエンドやリージョンにまたがるデータの保存、複製、そしてアクセスを、より緻密にコントロールできるようになる。たとえばこれからは、一つあれば十分なバックアップを、三箇所に分割して作る必要がなくなる。

さらに今回のアップデートでは、OpenStackの複数のクラウド間で認証を統一できるようになる。たとえばCERNのようなOpenStackユーザは、自分のプライベートクラウドを持ちつつ、それの容量をパブリックなサービスで増強できる。しかもこれからは、研究者が自分の単一の認証データで、それら二つのクラウドにアクセスできるようになる。

このJunoリリースには、新しい機能が合計310、バグフィクスが3200箇所ある。詳しいリリースノートは、ここで見られる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


クラスタ管理のMesosphereがデータのスケーラビリティのためにグラフデータベースのOrlyAtomicsを買収

分散プロセス(クラスタ群)の生成と、それらが適正に動くためのリソース管理をデベロッパ/アドミンに代わってやってくれるMesosphereが、分散/並列データベース技術(グラフデータベース)のOrlyAtomicsを、どうやら人材獲得を目的として買収した。OrlyAtomicsの4名の技術者は、ただちにMesosphereのチームに加わる。買収の価額などは、公表されていない。

Mesosphereは、オープンソースのMesosプロジェクトに便利なユーザインタフェイスを着せたサービスで、‘データセンターのオペレーティングシステム’を自称している。このMesosユーザインタフェイスの下では、どんなに複雑大規模なデータセンターでもまるで1台のPCのように簡単に効率的に管理できてしまうことが、メインの売りだ。一方OrlyAtomicsは、スケーラビリティのたいへん高いデータベース技術だ。クラスタ管理とデータベースでは一見互いに無関係なようだが、Mesosphereの協同ファウンダでCEOのFlorian Leibertによると、その下部構造は共通点がとても多い。

まずどちらもルーツがオープンソースで、どちらもC++で書かれている。だからOrlyAtomicsの連中はMesosphereに来たその日から一緒に仕事ができる。しかしLeibertによると、そういうレベルの互換性がすべてではない。プログラミングの技能以上に重要なのが、データ構造のスケーラビリティについて理解を共有することだ。

“大規模なシステムを管理し、大規模な分散システムの稼働状態を管理することは、言うは易く行うは難しの典型だ”、と彼は説明する。彼によると、OrlyAtomicsの連中が、これまでのMesosphereに欠けていたユニークな、そして願ってもないスキルセットを持参してくれたのだ。同社はOrlyAtomicsの知財をひとかけらも買い上げていないが、いずれにしてもオープンソースだから必要ならGitHubにアクセスすればよい。OrlyAtomicsのCEOだったPatrick Reillyは、いずれは同社の技術をMesosphereに合体させたい、と言っている。それはもちろん、データベースのプロジェクトを、という意味ではない。

“自分たちが築いてきたグラフストレージというビジョンには、今でも愛着がある。グラフデータベースによって人びとは、新しいクリエイティブなデータの利用方法に目覚めるだろう。これからはデータベースを作るのではなく、そういう機能をAPI的なプリミティブ集合として作っていく。もちろん、OrlyのオープンソースデータベースをMesosの上で動かしてみたいけどね”、とReillyは語る。

いずれにしても、Leibertによれば、Mesosphereにとって関心があるのはOrlyAtomicsの既存のプロダクトではなく、彼ら独特の技術能力と、彼らとの今後の協働関係だ。“プロダクトはそのままうちで利用できるものではない。むしろ貴重なのは、彼らがそれらを作りながら獲得した専門的知識と技術だ。それは巨大な分散システムが陥りがちな無秩序状態をすっきりまとめることに、関係がある”、とLeibertは言う。

どちらもC++で書かれているので、MesosphereとしてはOrlyAtomicsのチームがこれまでの経験から獲得した技能をMesosphereのプロダクトに持ち込んでくれることを期待している。Leibert曰く、“彼らはレイテンシを抑えスループットを上げることに邁進してきた。うちが大規模分散システムで実現したいと思っている価値も、まさにそれだ”。

Reillyのチームにとっても、魅力はそこにあった。彼曰く、“C++はパフォーマンスが高いから好きだ。Mesosに来てから最初のほんの数時間で、OrlyとMesosのコードを合体させると良さそうなところを、何箇所も見つけた。アプリケーションが何千もの専用コンテナに分散していて、それらが数十箇所ものデータセンターにまたがって動き、しかもそれらの全体がまるで一台の大きなコンピュータへと癒合しているようなMesosphereの世界は、すごくエキサイティングだ”。

LeibertがOrlyとの交渉を始めたのは4週間前だが、でも彼らは過去にすでに数週間、Mesosphereで仕事をした経験があるので、決心も早かった。Mesosphereの社員はわずか27名と少ないので、新しい社員を入れるにしても、相性がきわめて重要だった。

Mesosphereの社員たちは、一般の新入社員の場合と同じようにOrlyのチームを評価し、うまくやっていける、と判断した。

一方Reillyのチームは、Mesosphereのプロジェクトの大きさに感動し、また自分たちがそこに持ち込める貢献にもわくわくしていた。Reillyは曰く、“技術者はチャレンジすることが好きだが、大きな、そして複数のデータセンターの集まりを一台のコンピュータと見立てて、それのオペレーティングシステムを作るなんて、とてつもなくすごい。Mesosphereのコードベースを調べ始めてすぐに、そこがまるで自分の家のように感じた”。

Mesosphereから見ると、Orlyには同社の長期的な目標の実現に欠かせないものがある。“データセンターのためのオペレーティングシステム、という抽象を構築していくためには、データのコーディネーションが何よりも重要だ。彼らは、まさにそれをやっていたのだ”、とLeibertは語る。

オープンソースプロジェクトOrlyAtomicsは、ソーシャルディスカバリサイトTaggedで生まれた。後者は今、全世界に3億3000万のユーザがいるといわれる。Taggedはある時点で、データの大規模なスケーラビリティを実現するためのソリューションが必要になり、そこからOrlyAtomicsが生まれた。それはまさに、今のMesosphereが必要としているものだった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


サーバクラスタのためのオペレーティングシステムMesosを開発すMesosphereがアプリケーションコンテナDockerをサポート

Mesosは、サーバのクラスタを効率的に管理し、リソースの隔離も行うオープンソースのプロジェクトだ。今は主に、プロジェクトの生誕の地であるTwitterAirbnbなどで使われている。Googleにも”Borg”と呼ばれるよく似たシステムがあり、それはMesosが登場するかなり前に単独で開発され、データセンターの稼働の最適化に利用されてきた。

今Mesosは、TwitterとAirbnbのエンジニアだったFlorian Leibertと元AirbnbのエンジニアTobias Knaupが作ったスタートアップMesosphereで開発されている。オープンソース系のスタートアップの例に漏れずMesosphereも、関連サービスを将来的な収益源として考えているが、Leibertによると、今はMesosのエコシステムの育成と、そのコンセプトの普及に注力している。

Mesosは今ではApache Foundationがホストしているが、発端はカ大バークリー校の研究プロジェクトで、研究グループの一人、当時博士課程の学生だったBenjamin Hindmanが、それをのちにTwitterに持ち込んだ(彼は今Twitterの上級技術者だ)。

Mesosの基本的な考え方は単純明快だが、それはかなり前に時流から外れてしまっていた。それはつまり、アプリケーションの各部向けにそれぞれ専用のサーバクラスタをセットアップするのではなく、むしろサーバのプールを作っておいて、それを各部…Hadoop、Webサーバ、etc.…が共有し自分を動かす、という今のMesosのアーキテクチャだ。アプリケーションはお互いを邪魔することなく、むしろリソースを必要に応じて動的に割り当てる。たとえばビッグデータ分析の仕事が終わったら、リソースをトラフィックの多いWebサーバに回す、とか。

もっと概念化して言うと、Leibertの説明では、いろんなプロセスが並行で動くデータセンターをマルチコアのCPUにたとえると、Mesosはいわば、そのCPUの動作を管理するオペレーティングシステムのカーネルだ。オペレーティングシステムはカーネルの外側にいろんな実働部隊を要するが、今それらの部位の開発にMesosphereは取り組んでいる。たとえばAirbnb時代にLeiberが作りChronosと名づけたスケジューラは、伝統的なcronに代わって、Mesos上で動く各サービスの開始と停止(とエラー処理)を自動化する。またMarathonは、いわばMesosにおけるinit.dとして、始動プロセスの役を担う。その後のサービス(Chronosなど)が利用する、開始、停止、スケーリングなどの基本的なプロセス管理タスクは、MarathonがAPIとして提供する。

背後でChronosとMarathonが動くことを前提として、チームは今日(米国時間9/26)、Mesosが動かして管理するアプリケーションコンテナDockerを発表した。デベロッパは自分のアプリケーションをこの軽量でポータブルなコンテナに収めることによって、展開を…新しいマシン上の展開でも…自動化できる。つまりMesosのレベルで言えば、クラスタ上のアプリケーションの展開が大幅に簡易化される。彼らのブログ記事によると、“アプリケーションをDockerに入れてMesosに渡すことにより、オンプレミスやクラウド上の多様なアプリケーションを展開し動かすための、真にエラスティックで効率的で首尾一貫性のあるプラットホームが約束される”。Leibertによると、アプリケーションがDockerを着ているとクラスタ全域にわたるサービスの発見が容易になる。つまり、クラスタをセットアップしたらそれで終わり、ではなく、いろんなサーバがお互いを見つけられる必要があるのだ。

Mesosなどクラスタシステム上のサービス~アプリケーションをDockerのようなもので抽象化することは、Leibertによると、過去にもいろんな人が試みたが、その実現はとても困難だった。しかしMesosphereの6人のチームは、Mesosを誰よりも熟知しているので、アプリケーションコンテナの組み込みに成功できた。

以上のようなビルディングブロックが揃ったところで、チームが次に挑戦するのは、Mesosを新人ユーザでも使いこなせるための、ユーザフレンドリーなユーザインタフェイスの構築だ。その仕様は、Mesosのコミュニティからの要望に基づき、またその具体的な部位もユーザからの求めに応じて加えていく予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


サーバクラスタのためのオペレーティングシステムMesosを開発すMesosphereがアプリケーションコンテナDockerをサポート

Mesosは、サーバのクラスタを効率的に管理し、リソースの隔離も行うオープンソースのプロジェクトだ。今は主に、プロジェクトの生誕の地であるTwitterAirbnbなどで使われている。Googleにも”Borg”と呼ばれるよく似たシステムがあり、それはMesosが登場するかなり前に単独で開発され、データセンターの稼働の最適化に利用されてきた。

今Mesosは、TwitterとAirbnbのエンジニアだったFlorian Leibertと元AirbnbのエンジニアTobias Knaupが作ったスタートアップMesosphereで開発されている。オープンソース系のスタートアップの例に漏れずMesosphereも、関連サービスを将来的な収益源として考えているが、Leibertによると、今はMesosのエコシステムの育成と、そのコンセプトの普及に注力している。

Mesosは今ではApache Foundationがホストしているが、発端はカ大バークリー校の研究プロジェクトで、研究グループの一人、当時博士課程の学生だったBenjamin Hindmanが、それをのちにTwitterに持ち込んだ(彼は今Twitterの上級技術者だ)。

Mesosの基本的な考え方は単純明快だが、それはかなり前に時流から外れてしまっていた。それはつまり、アプリケーションの各部向けにそれぞれ専用のサーバクラスタをセットアップするのではなく、むしろサーバのプールを作っておいて、それを各部…Hadoop、Webサーバ、etc.…が共有し自分を動かす、という今のMesosのアーキテクチャだ。アプリケーションはお互いを邪魔することなく、むしろリソースを必要に応じて動的に割り当てる。たとえばビッグデータ分析の仕事が終わったら、リソースをトラフィックの多いWebサーバに回す、とか。

もっと概念化して言うと、Leibertの説明では、いろんなプロセスが並行で動くデータセンターをマルチコアのCPUにたとえると、Mesosはいわば、そのCPUの動作を管理するオペレーティングシステムのカーネルだ。オペレーティングシステムはカーネルの外側にいろんな実働部隊を要するが、今それらの部位の開発にMesosphereは取り組んでいる。たとえばAirbnb時代にLeiberが作りChronosと名づけたスケジューラは、伝統的なcronに代わって、Mesos上で動く各サービスの開始と停止(とエラー処理)を自動化する。またMarathonは、いわばMesosにおけるinit.dとして、始動プロセスの役を担う。その後のサービス(Chronosなど)が利用する、開始、停止、スケーリングなどの基本的なプロセス管理タスクは、MarathonがAPIとして提供する。

背後でChronosとMarathonが動くことを前提として、チームは今日(米国時間9/26)、Mesosが動かして管理するアプリケーションコンテナDockerを発表した。デベロッパは自分のアプリケーションをこの軽量でポータブルなコンテナに収めることによって、展開を…新しいマシン上の展開でも…自動化できる。つまりMesosのレベルで言えば、クラスタ上のアプリケーションの展開が大幅に簡易化される。彼らのブログ記事によると、“アプリケーションをDockerに入れてMesosに渡すことにより、オンプレミスやクラウド上の多様なアプリケーションを展開し動かすための、真にエラスティックで効率的で首尾一貫性のあるプラットホームが約束される”。Leibertによると、アプリケーションがDockerを着ているとクラスタ全域にわたるサービスの発見が容易になる。つまり、クラスタをセットアップしたらそれで終わり、ではなく、いろんなサーバがお互いを見つけられる必要があるのだ。

Mesosなどクラスタシステム上のサービス~アプリケーションをDockerのようなもので抽象化することは、Leibertによると、過去にもいろんな人が試みたが、その実現はとても困難だった。しかしMesosphereの6人のチームは、Mesosを誰よりも熟知しているので、アプリケーションコンテナの組み込みに成功できた。

以上のようなビルディングブロックが揃ったところで、チームが次に挑戦するのは、Mesosを新人ユーザでも使いこなせるための、ユーザフレンドリーなユーザインタフェイスの構築だ。その仕様は、Mesosのコミュニティからの要望に基づき、またその具体的な部位もユーザからの求めに応じて加えていく予定だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


日立がWesternに売ったHGSTがハードディスクにナノテクを応用して容量を倍増

HGST-1.2Tbit-cropped-2013SPIE[4]

モバイルプロセッサに詳しい人は、Qualcommなどが作る現世代のチップを比較して論じるとき、32nm vs. 28nm(nmはナノメーター)なんて話をよく聞いているだろう。それはプロセッサのサイズを言い表す言葉で*、この数字が小さいほど電力消費が少なく、素子を小型化でき一定スペースに多量の回路を詰め込めるので機能も性能も上がる。〔*: この数字はVLSIの配線の太さ(幅)ないし配線間の間隔の幅のこと。〕

またディスクドライブでは、一つのビットを記録する磁性体単位の大きさ(パターンサイズ)を20nmよりも小さくするのは難しい、と言われている。ディスクドライブも、プロセッサと並んで、ムーアの法則が当てはまる分野だったが、どちらもそろそろ、限界に突き当たろうとしている。ところが今日、Western Digitalが日立製作所から買収したハードディスク企業HGST発表した画期的な技術によれば、10nmのパターンを作ることが可能だという。その工程は“ナノリソグラフィー(nanolithography)”(ナノサイズの平版印刷)と呼ばれ、これによりハードディスクドライブの最大容量を今の倍にすることができる*。〔*: 2×2=4倍ではない。原文のコメント参照。〕

HGSTのこのナノプロセスは、テキサス州オースチンのシリコン加工スタートアップMolecular Imprints, Inc.との共同開発で、これまで広く使われていたフォトリソグラフィー(photolithography)(写真製版平版印刷)技術を使わない。感光剤を用いる写真的な製版では、プロセスのサイズを光の波長より小さくすることはできない。HGSTの研究担当VP Currie Munceによると、HGSTの技術では将来的に10nm以下にすることも可能、という。

HGSTは今の2010年代内に一般市販製品の完成を目指している。そのための低価格化と安定性能を達成できれば、‘ストレージ欲’に限度のない今日の顧客たちが、こぞって採用するだろう。とくにWebは、クラウドサービスの増加と、Facebook、Apple、Amazonなどのビッグ企業のデータセンターの大型化がこれからも続くから、ストレージの費用効率とスペース効率はきわめて重要だ。HGSTのナノリソグラフィープロセスでは、磁性体の同じ面積のストレージ能力が従来の倍になるのだから、ざっと言って、効率も倍になることになる。

このプロセスは、顕微鏡レベルのちょっとした粗(あら)を冗長性によって回避できるディスクストレージに向いているようだ。Munceによれば、HGSTのナノリソグラフィーはモバイル用プロセッサなど、ナノレベルのVLSIの製造には向いていない。

“プロセッサでは、回路パターンに粗(あら)があることは絶対に許されない。ハードディスクドライブでは、つねにエラー修正コードが動いているし、パターンの欠陥を特殊な信号処理で補うこともできる”、と彼は説明する。

しかしそれでも、ハードディスクとメモリの方面では、今から5〜6年先にHGSTの画期的な技術が、クラウドコンピューティングやモバイルデバイスを中心として、テク業界全般に大きな影響を与えていくだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))