2011年2月25日金曜日

jcloudsを採用したGigaSpaces

クラウド市場にあって、GigaSpacesのポジションはユニークだ。通常のクラウドプロバイダーは自社データセンターの余力などを用いてクラウド機能を提供する。しかし、GigaSpacesの本来の発想は、パブリックなサービスとして展開するクラウドプロバイダーと競合するのではなく、OSやミドルウェア、アプリなど多層ソフトウェアスタックで構成される大規模ITシステムの硬直化を解消するためのものである。その核となるのがJavaSpacesだ。

◆ JavaSpacesとは何か
JavaSpacesは複数のJVM(Java Virtual Machine)上にあるオブジェクト(データ)を共有するための仕組みとしてJCPで制定された。これにより個々のオブジェクトはどのJVM上にあろうとも(即ち、どのサーバー上でも)システム内で自由にアクセスが出来る。この自由さは、配下のハードウェアやOSを意識しないJavaと共にクラウドでは重要な要素となる。JavaSpacesではこのオブジェクトが存在するメモリー空間を“スペース”と呼ぶ。GagaSpacesはこのJavaSpacesを実装し、さらに処理ロジックまで推し進め、データ(オブジェクト)と処理を同じ“スペース”内に共存させるアーキテクチャーSBA(Space Based Architecture)を考え出した。
企業のITシステムは通常何層かのスタックされたソフトウェアからなるが、SBAではこれら積み重ねた層をケーキを切るように縦割りにしたプロセシングユニットを横に並べる。この構造によって、必要に応じユニットを追加してスケールアウトを保証する。

◆ GigaSpaces XAP
こうした設計方針のもとで開発されたアプリケーションサーバーがXAP(eXtreme Application Platform)だ。XAPは企業向けの新しいアプリケーションサーバーとして2000年の設立以来、ユニークな地位を築いてきた。XAPは多様なアプリケーションを走らせるだけでなく、システムをダイナミックに構成することができる。この特徴を生かしてグローバルな大企業に浸透を図ってきた。そしてクラウド時代が到来した。2008年6月、XAPのこれまでの企業向け販売だけでなく、AmazonのAWS Solution ProviderとしてEC2上でXAPをリリースした。

最新版(8.0)ではXAPをより汎用性のあるクラウドPaaSとするため、Multi-Tenant Elastic Deployment Frameを採用し、さらにMulti-Cloud Adaptorを組み込んだ。
これによって、未仮想化のオンプレミスでもプライベートクラウドでも、さらにはパブリック上でも稼働が可能となった。

◆ jcloudsプロジェクト
XAP 8.0の要となるMulti-Cloud Adaptorは、多様なクラウドプロバイダーの提供するサービスを抽象化するインターフェースだ。このため採用したのがjcloudsである。jcloudsはオープンソースのクラウド向けライブラリーで、AWS、CloudSigma、Eucalyptus、GoGrid、Google App Engine、IBM Smart Business Development & Test Cloud、Rackspace、vCloud(BlueLock、Terremark)、Windows Azureなどに対応。プロジェクトを立ち上げたのはAdrian Cole氏だ。彼は16才からコードを書き始め、数年前に大規模開発のJavaに携わった。それらの経験の全てを注ぎ込んで、jcloudsを2009年から立ち上げた。


---------------------------
GigaSpacesとjcloudsの動きには、何か共通するものを感じる。
新しいITの世界を切り開こうとする力だ。置かれた環境や現状に臆することなく、定めた目標に向かって世界を変えて行こうというエネルギーである。今日のITを見渡せば、殆どのアプリケーションサーバーがJava EE仕様であるのに対し、XAPはJavaSpaces仕様だ。同社はこの仕様を実装している唯一のベンダーだと言っても良い。前述のように、JavaSpacesではプロセシングユニットを横に並べてスケールアウトする。これは並列処理の世界だ。この技術を遡ればTuple Spaceにたどりつく。この流れはJavaSpaces
だけでなく、LispやPython、Rubyなどにも引き継がれている。
もうひとつのjcloudsもオープンソースでありながら、どのような組織にも属することなく、Adrian Cole氏は黙々と開発を続けてきた。jcloudsはクラウドの未標準化やベンダーのエゴを全て抽象化する。このためにはニュートラルであらねばならない。だから、自分の仕事だと決めていたという。

2011年2月22日火曜日

タテとヨコの戦い、そしてハイブリッド 
                -Building a Hybrid Cloud-

ハイブリッドクラウドに対する要求が高まってきた。
企業は既に仮想化技術を導入してサーバーを統合、次にパブリッククラウドを使ってその有用性を確かめてきた。そして徐々にプライベートクラウドの検討が始まった。しかしデータセンターの仮想化と違い、プライベートクラウド構築には障害が幾つかある。ひとつは有効なクラウドインフラが少ないこと、もうひとつはベンダーロックイン(縛りつけ)だ。

◆ クラウド・バトル(Cloud Battle)-タテかヨコか-
この2つの問題は絡み合って見える。
仮想化ではVMwareを筆頭にCitrix/Xen、Red Hat/KVM、Windows/Hyper-Vなどが市場を分け合い、彼らはその上に運用管理領域の整備、そしてクラウドインフラの提供と勢力をタテ方向に伸ばしてきた。まさにベンダーロックインである。しかし彼らのクラウドインフラはVMwareのvCloud Directorでさえ予定を大きくずれてやっと出てきたばかりだ。Xen Cloud PlatformRed Hat Cloud Foundationは開発途上と言って良い。
これを回避し、迎え撃つのはオープンソースを基本としたプロダクト群である。
UC Santa Barbaraで開発されたEucalyputus、 RackspaceにNASAが協力して動き出したOpenStack、SunのJVMエンジニアが興したCloud.com、さらにスペインから始まった欧州のOpenNebulaなどだ。これらのプロダクトは仮想化技術を抽象化して、ベンダーに縛られずにクラウドを作ることが出来る。現段階ではシステム毎にどの仮想化技術を適用するかを決める場合が多いが、少しづつ同時に複数の仮想化対応も可能となり始めた。この技術が確立できればユーザーは仮想化技術にまたがったリソースプールが可能となる。まさにヨコへの展開だ。


◆ RightScaleのハイブリッドアプローチ
タテ・ヨコの戦いを横目に、RightScaleはもうひとつのアプローチを追っている。
ユーザー企業には沢山のアプリケーションがあり、これを 「Application Portfolio」とすると、それらを「Requirements Filter」で条件付けし、「Resource Pool」から該当するプラットフォームを選んで実行させる。例えば、アプリ-Ⅰは実行コストを重視してPublic Cloudで処理、アプリ-Ⅱはセキュリティーの観点からPrivate Cloudで実行、アプリ-Ⅲはダウン回避から高信頼性HA(High Availability)に振り向けるといった具合だ。ここでRequirements Filterの項目には、処理能力やコスト、セキュリティー、コンプライアンス、信頼性などが該当する。また、Resorce Poolにはパブリックやプライベートクラウド、さらにはオンプレミスや単なる仮想化マシン、ホスティングなどでも良い。勿論、プライベートには本格的なクラウドから外部委託(Managed Private Cloud Hosting)も含まれる。つまり、タテ・ヨコの論点とは別な視点で、アプリケーションと実行リソースを結びつける現実的なアプローチだ。

RightScaleの利用の仕組みを振り返ってみよう。
まずデベロッパーには意図する実行イメージ(Runnable Abstraction)があって、それを具体化するためにRightScaleが用意したテンプレート(Server Template)を利用する。これによって作業のリードタイムは大幅に軽減する。同社の初期製品はAmazon Web Servicesのみのサポートであったが、徐々にマルチ対応が進み、Eucalyptus、GoGrid、FlexiScale、最近ではCloud.comも対象となった。

しかしマルチインフラ化は簡単な仕事ではない。
リソースAPI(Resource Set、Format、Multiple Version)の差、ネットワーク(VLAN、NAT、IPs、ACLs)やストレージ(Local、Attachable、Backup、Snapshot)の考え方の違いなどが複雑に絡み合っている。これをひとつづつ解きほぐして、同社では異なるクラウドなどのインフラで稼働させる実行イメージ(Runtime Config)を作り出している。これが同社の考えるハイブリッドクラウドという訳だ。

Nimbulaのハイブリッドアプローチ
Amazonクラウドの生みの親Chris Pinkham氏が始めたNimbulaのアプローチも期待が高い。Nimbulaが現在βリリースしているNimbula Directorは、主として企業向けに自社データセンターとAWSなどをハイブリッドにした総合運用環境の構築を目指している。つまり、オンプレミスのプライベート環境に拡張性のあるAWSなど外部パブリッククラウドを組み合わせて運用することで、これまでにない柔軟性を生み出す狙いだ。
実際、プブリッククラウドを試した企業ユーザーは、その弾力性(Elastic)に驚かされる。しかしだからと言って、全てのアプリケーションをパブリッククラウド上で構築することはありえない。そこで、 同社では自社クラウドの構築と外部クラウドを組み合せた新しい社内インフラのあり方を提案する。これがNimbula流ハイブリッドクラウドである。
Nimbulaの特徴は仮想化技術の抽象化だ。
β版ではXenとKVMに対応し、出来上がったクラウドは同じものをネットワークブートで複数サーバーに次々にインストレーションできる。次にユーザ(User, Group, Permission)、イメージ(Machine Image)、ネットワーク(Virtual Ethernet, Virtual DHCP)、インスタンス(View Instance, Launch Instance)管理などを設定。
これで大型クラウドが出来上がる。このクラウドインフラは論理的なセグメントに分けて、マルチテナント利用が可能だ。正式版では個々のセグメントにAccess PolicyやSLAを設定して、同様の設定をしたAWSとの連携も可能となる。こうなれば、まさに自営AWSと本物のAWSを連携運用している気分である。

------------------------------------------
今回は、クラウドインフラの領域でタテかヨコかという問題を提起した。
仮想化ベンダーによるタテ、対するオープンソースのヨコ。この2つが共存するのか、
はたまたどこかが勝ち抜いてくるのか、今年1年が注目となる。これは企業ユーザーにとって重要な問題だ。一方でRightScaleやNimbulaのようなアプローチもある。
RightScaleは丹念にクラウドの差異を繋ぎ合せてハイブリッドを可能とし、ユーザーの反応は上々だ。こうして、同社製品は初期のAWS用テンプレート対応から、現在では“Cloud Management Platform”となった。Nimbulaの場合は、俊敏性のあるAWSの良さを自営クラウド化する試みである。両社の提案するハイブリッドは、 RightScaleが現状拡張型、Nimbulaは新規導入型だ。いずれも、クラウド構築に付き纏う仮想化技術からの回避である。  

2011年2月16日水曜日

Oracleとオープンソースの深まる対立

米経済の低迷は続き、どのハイテク企業も生き残りを賭けた活動が続いている。
このような環境では、オープンソースを支えるスポンサー企業の台所事 情も大変だ。
ApacheやMozillaを サポートするGoogleやEclipseの IBMなどは経営も健全で心配はない。しかし数多くのプロジェクトを支援していたSunやNovellは買収されてしまった。周知のように、メインフ レームからUnix、そしてLinuxへと時代が進んでコンピュータ産業は成熟し、今やユーザーを代表するデベロッパーの協力なくしては製品/サービス開 発は進まない。世界中のデベロッパーの技術力は高く、OSからBrowser、Application /Web Server、Databaseなどの殆どをオープンソースとして開発し、NASAのクラウドNebulaは、全てがオープンソースで構築されている。過去、何度かコミュニティーと悶着を起こしたMicrosoftですら、この辺りの事情は解っていて、Windows関連のオープンソースサイトCodeplexを2006年から開設している。しかし、残念だがAppleとOracleに限っては理解が違うようだ。Appleの独自技術指向は総指揮官であるSteve Jobs氏の好みだし、Oracleの場合もLarry Ellison氏には、オープンソースなど眼中にないように見える。そして、この2社は共に、この不況下でも大きな利益を出しているのだから、
彼らは当分、その理屈を変えないだろう。

◆ OpenOfficeから LibreOfficeへ
Oracleとコミュニティーの最初の騒動が外部に表面化したのは昨年9月だった。
これまで OpenOfficeを支えてきた主要メンバーがDocument Foundationを設立し、 OpenOffice.orgからフォーク、新たにLibreOfficeとして開発を進める発表した。しか しこれは突然のことではなかった。Sunの買収後、これまで通り継続的なサポートを期待するコミュニティーとOracleの対応にはギャップがあり、何度も話し合いが行われた。

振り返ってみると1999年にSunがMicrosoft Officeに対抗するStarOfficeを開発していた独Star Divisionを買収、2000年にはOpenOffice.org(OOo)を立ち上げてオープンソース化して、2002年5月に最初のOOo 1.0(StarOffice 6.0ベース)」が出た。
それから10年、昨年はコミュニティーの10周年記念だというのにSunの買収、 Oracleとの話し合いの難航、そして独立と苦難の年だった。しかし、殆どのコミュニティーメンバーは新しい組織に移り、FSF(Free Software Foundation)やGNOME Foundation、OASIS、Open Source Business Foundation、Open Source Consortium、Open Source Initiativeなどオープンソース関連の組織、民間からはCanonicalやGoogle、Novell、Red Hatなどの支持も取り付けた。
OOo からのフォークにあたって、 これだけ普及しているOpenOfficeの名称をOracleに譲るように求めたが、応えはNOだった。一方で昨年12 月、OracleはOracle Cloud Officeを発表。これはフォーク後、2つの組織(Oracleと Document Foundation)から出されたOOo3.3をベースにしたものだが、さらにWeb化されてスマートフォーンからのアクセスが出来る。3つのエディ ションのHome(未定)、Standard($40)、Professional($90)は全て有料だ。


◆ OpenSolarisも暫時終了か
Sunがデベロッパー拡大のために始めたOpenSolarisプロジェクトも心配だ。
当初、 OracleはOpenSolarisの継続を約束していたが、その後の動きを見ると、このプロジェクトも暫時終了の方向に見える。Oracleが発表したサポート計画Service Life Status for OpenSolaris Operating System ReleasesでもOpenSolaris 2008版は今年の春から冬にかけて、2009版は来年早々にサポートが打ち切られる。昨年夏にはSolarisプロジェクトのMike Sharpiro氏、Bill Nesheim氏、Chris Armes氏の連名でOpenSolaris Cancelled, to be Replaced with Solaris 11 Expressというメール出た。このメールではSolarisの重要性を説きながら、一方で投資の効率化から、今年リリース予定の Solaris 11開発にOracleは集中し、結果として、今後はオープンソース版と商用版のリリース順序を逆にするとしている。つまり、SunはSolarisの改良のため、世界中のデベロッパーの協力を仰ぎながら、OpenSolarisを先出しし、その後に、正式版を出すという戦略だった。これを改め、Oracle内だけで開発し、OpenSolarisは暫時取りやめということのようである。

◆ AppcheがJCPから脱退
昨年12月9日、Apache Software Foundationは、 かねてからの通告通りJCP (Java Community Process)のJava SE/EE Executive Committeeから脱退すると発表した。問題はライセンス解釈に伴うJava SE TCK(Technical Compatibility Kit)の提供拒否からだった。Apacheではトップレベルプロジェクトとして2006年からクライアントでのJava開発と実行環境プラットフォームApache Harmonyを進めてきた。
Harmonyは、勿論、適用製品のソースコードに公開義務のないApache License 2
リリースされる。問題の核心はHarmonyがJava SEの認定品かどうかを検定するTCKの「Field of Use(FOU)」制限である。FOUとは、適用製品が適合するプラットフォームかどうかを規定するもので、場合によっては不可となる可能性がある。 Apacheから見れば、HarmonyがTCKでJava SE仕様に適合していれば、その先にある最終の適用製品はApache License 2に準拠していれば良いという考えだ。JCPの目的とは、Javaをデベロッパーが円滑に利用するための制度をコミュニティーが主体として定めるものであり、さらなる制限事項には承服できない。これでは何のためのJCPかわからないというわけである。ただ、この問題はSun時代から始まっていた。Java開発元のSunは、Javaの基本理念である“Write Once, Run Anywhere(一度(プログラムを)書けば、どこでも実行できる)”を保証するためには、必要な制約事項だとしながらも妥協の道を探っていた。当時、OracleはHarmonyの支援企業としてこの制限をなくすようSunに要求していたからややこしい。しかし、買収後は一転した。また昨年10月には、今回と同様の問題から、コミュニティーに影響力の大きいDoug Lea氏もExecutive Committeeを辞めている。


◆ HudsonからJenkinsへ
アジャイル開発のHudsonについ ては前回触れた。
Sunのエンジニアだった川口耕介氏が始めたオープンソースプロジェクトだ。
HudsonはOracleの買収に伴ってOracleのプロジェクトとなったが、ここでもOracleとコミュニティーの関係は躓き、コミュニティーがホスティングサイトをJava.netからGitHubに移行することを決めると、OracleはHudsonの商標権を主張。コミュニティーは議論の末、1月末、 Hudsonの名称変更を投票で決定し、新名称はJenkinsとなった。Oracleは同日、Hudsonを継続すると表明し、結果、奇妙なことに2つのプロジェクトが存在する。今後、JenkinsプロジェクトのサイトはJenkins-CI.org、コードはGitHubを利用する方針だ。

----------------------------
オープンソースプロジェクトとは誰が何をするためのものなのだろうか。
どの企業がオープンソースをサポートするにしても、その運営が難しいことはよく解る。
資金や人材を出すためには企業側のメリットが無ければならない。SunやGoogleのようにコミュニティーと連携して、製品改良や技術の普及を図ることにメリットが見出せれば、サ ポートするだろう。Codeplexを運営する現在のMicrosoftにもその傾向は見える。
そしてサポートするプロジェクトの成果は自社製 品や技術となり、一方でコミュニティーは自分たちが欲しかったプロダクトを手に入れる。この構図が見出せなければ、企業は動かないし、コミュニティーも納得しない。Oracleの場合は何を考えているのだろうか・・・

関連記事:ありがとうSun、そしてジョナサン・シュワルツ!

2011年2月10日木曜日

アジャイル開発クラウドのCloudBees  
             -HaaS(Hudson as a Service)-

CloudBeesInfraDNAが参加したのは昨年11月のことだ。
元Sunのエンジニアだった川口耕介氏が買収したOracleを辞め、2010年4月に興した会社がInfraDNAだ。
氏は2001年に渡米し、2003年からSunに勤務、主にJavaで書かれたJavaEEのオープンソース版GlassFishの開発に係わりながら、2004年から余暇を見て、Javaのアジャイル開発Hudsonプロジェクトを開始、2008年からは社内でも徐々に認知されてほぼ専業となった。

◆ CI Serverとは何か
アジャイル開発の要は“継続的インテグレーション(Continuous Integration-以下CI)”である。CIはエクストリーム・プログラミング-XP(Extreme Programming)などの技法を採用し、早い段階からバラバラに開発した部品を持ち寄って検証(ビルド→テスト→フィードバック)を行い、結果を修正(エディット→コミット)、この全体サイクルを何度も 繰り返し、これによって開発期間を大幅に短縮させるのが狙いだ。これら一連の作業を する製品がHudsonプロジェクトのCI(Continuous Integration) Serverである。
このサーバーはJava.net上でオープンソースとして公開されており、1人で始めたプロジェクトは、現在、330人強のCommitterと310以上のPlug-inを持つ大型プロジェクトに成長した。その普及は、Eclipseコミュニティーの調査によると、2009年が9.1%、2010年は21.8%と急上昇、適用も .NET、C++、Python、Ruby、PHPなど多岐に わたっている。

◆ CloudBeesアーキテクチャー
InfraDNAに続き、昨年12月にはCloudBeesがJavaベースのPaaSプロバイダーStax Networksを買収、こうして現在のサービス体系が姿を現した。下図上段左側が開発エンジンとなるInfraDNAのCI ServerでDEV@cloudと呼ばれる。右側が実行環境を提供するStax Networks製品のRUN@cloudだ。この2つを連携させて、CloudBeesは開発から実行までを一環して提供するクラウド環境を整えた。


CloudBessは実際のところ、Amazon EC2上で稼働する。
つまり、CloudBees自身はデータセンターを持たず、アジャイル開発(DEV@cloud)と実行プラットフォーム(RUN@cloud)をAWS上で提供し、現在、2つは共にβ版としてリリースされている。
DEV@cloudのオリジナルはオンプレミスで動くHudsonだが、その後、HudsonはOracleとの商標問題からJenkinsと改名されている。DEV@cloudはそのクラウド版だ。CloudBeesからはさらにNectar 1.0も発表された。
このベースとなっているのはInfraDNAが開発したICHCI(InfraDNA's Certified Hudson for Continuous Integration) だ。ICHCIはオリジナルのHudson CI Serverに、セキュリティー機能としてLDAP、さらにコード分析ツールやソースコード
管理、プロジェクト管理などをインテグレーションしたエンタープライズ向けの商用版で、Nectarはそのリパッケージ版だ。
もうひとつのRUN@cloudは、基本的にWebアプリケーションやJava EE、さらにSpringのアプリケーションを実行させるのに最適化されたプラットフォームだ。つまり、Java用のアプリケーションサーバーのクラウド版である。そして、Javaと親和性の良いJRubyScalaCFML(ColdFusion)なども実行可能だ。

---------------------
Hudson、改めJenkinsは順調に伸び始めている。
現在、30,000近くのインストレーションベースを持ち、想定ユーザー数は50万人を超える。しかし、これまでの道のりは容易ではなかった。2004年に1人で始めたHudsonは、2006年7月にやっと2人目のCommitterが現われ、それからやっと成長曲線に乗り、2008年にはメーリングリストが1,000、プラグインも100を超えた。そして2010年4月のOracleによるSun買収、この流れを踏み台に氏は退社して起業、さらにCloudBeesと統合、こうしてクラウド化が実現した。一方、オープンソースプロジェクトJeskinsも順調だ。CI Serverのリリースは毎週金曜日、もちろん、Jeskinsを使った作業である。リリース番号は390から400に近づき、今年はクラウド上で力強く、羽ばたくことになるだろう。