NewsInsight

REPLsに見る多言語プログラミングの可能性

グーグルクラウドのJava対応が意味する2つのこと

2009/04/20

　かねてから噂されていたことだが、グーグルは2009年4月8日にアプリケーションホスティングサービスの「Google App Engine」（GAE）でのJava対応を発表した。発表後1週間を経た4月15日には登録開発者数が2万5000人を超えたほか、国内では4月13日にサイオステクノロジーがいち早くGAE/J対応のビジネスアプリケーションとサポートサービスの提供開始を発表するなど、少しずつ動きが見られる。

　それまでGAEがサポートしていた唯一のプログラミング言語であるPythonに比べると、Javaへの対応は、エンタープライズ分野での影響が大きそうだ。しかし、GAE/JはJava対応というよりもJVM対応といったほうがいいのかもしれない。そうだとすると、GAE/Jは一般的なシステム設計や開発者のスキルセット習得という面でも、今後影響を与える可能性があるのではないだろうか。GAE/Jの与えうる影響を2つの面から考えてみたい。

【影響1】既存アプリケーションサーバビジネスに激震!?

　IBMは、GAE/Jの発表に合わせて、グーグルのクラウドとオンプレミス間の移植性の高さを示している。IBMが公開した「Porting Google App Engine Applications to IBM Middleware」という技術文書には、GAE/J向けに開発されたアプリケーションを、IBMが持つミドルウェア製品群が稼働するオンプレミス型のサーバに移植する具体的な方法が紹介されている。

　GAE/JはオープンソースのWebサーバ・サーブレットコンテナである「Jetty」をSDKで採用しているため、IBM WebSphere Application Serverへの移植は容易だという。データベースアクセスや、認証などで移植作業が発生することはっても、基本的にいずれもJavaに準拠しているため、互換性は高い。データベースも、業界標準のJDO（Java Data Object）を使っている限り、それはIBM DB2の永続化オブジェクトへと移植できるという。

　「GAE/J→IBM WebSphere」の移植が容易であることは、ロックインを案じる経営者やCIOには朗報だろう。いざとなれば、GAE/JからWebSphereへなど、クラウドから既存のアプリケーションサーバへとシステムを移し替えられるからだ。

　もちろん、逆もまた真だ。ハードウェアが不要で容量設計や運用管理が不要なGAE/Jがあるのに、高額のライセンス料が発生するアプリケーションサーバを維持する必要があるだろうか？ アプリケーションサーバを中心にSOA、ERP、CRMなどの製品ポートフォリオを作り上げてきたビジネスアプリケーションベンダ各社は、自社でSaaS型のサービスを展開するだけでなく、今後は他社クラウドサービスとの連携を加速させていく必要に迫られる可能性がある。

Google SDCでクラウドとオンプレミスが融合

　例えばオラクルはGAE/J発表直後の4月9日に、従来ではちょっと考えられなかったようなグーグルとの協業を発表している。発表資料の頭にあるのはGoogle Apps向けのガジェット作成ツール「Oracle Gadget Wizard」やポータルサイト構築サービス「Google Sites」と「Siebel CRM」との連携の文字が躍るので、一見すると単なる“マッシュアップ”というようにも見える。しかし、エンタープライズ領域でより注目すべきは「Google Secure Data Connector」（Google SDC）の存在だ。

　GAE/Jと同時に発表されたGoogle SDCは、高度なセキュリティ機能が求められる利用シーンで企業ユーザーが使うためのオープンソースのソフトウェアだ。Google SDCは一種のエージェントとしてクラウドとオンプレミスの間をトンネリングすることで取り持つ。Google SDCをファイアウォールの外に用意したLinuxマシンにインストールすることで、自ドメインで稼働するGoogle Appsなどからのリクエストをハンドルして、ファイアウォール内にある社内のデータにセキュアにアクセスできるようになる。つまり、外出先からGoogle Gadgets、Google App Engine、Google Spreadsheetsなどを利用する社員は、認証を経た後にSiebel CRMなどに保存されたデータを、これらクラウド上のアプリケーション上でセキュアに利用できるようになるのだ。

　アプリケーションから見ると、社内のURLであっても通常のインターネット上のURLのように取り扱うことができ、開発者にとっても設計が容易だ。もちろんシングルサインオン、ユーザー別・アプリケーション別のアクセスコントロールも可能だし、「bulkuploader」を使えば従来データベースに保存してあったデータを、いったんCSVを経由することで、まとめてGAEに放り込むこともできる。

　GAE/Jは、単にJavaというビジネス標準のプログラミング言語が使えるというだけでなく、クラウドとオンプレミスをセキュアにつないだ上でカスタムアプリケーションが利用できる環境でもあると考えられる。

【影響2】可能性が広がる多言語プログラミング

　開発者やシステム設計者にとっては、GAE/Jは「多言語プログラミング」という未来の可能性を感じさせてくれる存在でもある。グーグルのGAEチームが4月13日に公開した実験的アプリケーション「Lord of the REPLS」は、その未来を垣間見せてくれるデモンストレーションとして興味深い。同じJVM上で、Beanshell、Clojure、Groovy、JavaScript、Python、Ruby、Scala、SchemeのREPL（Read-eval-print loop）を切り替えながら使ってみることができる。

　多言語プログラミングという用語は、ITコンサルタントでソフトウェアアーキテクトのニール・フォード氏が使っているものだ。単に複数の言語を使ってシステムを作るというものではなく、単一のランタイム――、JVMやマイクロソフトの.NET（CLR/DLR）上で異なる言語を使ってシステム構築やプログラミングを行うという考え方だ。これは異なる言語で書かれたソフトウェアを疎結合で組み上げるというのとは異なる。

　多言語でシステムを開発する例として、従来でもFacebookのような事例がある。彼らは「Thrift」と名付けた多言語混在RPC開発フレームワークを自作。オープンソースで公開している。Thriftの汎用的な記述言語を使って型宣言とインターフェイス定義を行うだけでRPCを使った分散システムを構築できる。Facebookでは、C++、Java、Python、PHP、Ruby、Erlangなどを目的別に使い分けているという。例えば、RSSのパーザはC++で書くよりPython/Rubyのほうがいいだろうし、インメモリのサーチインデクスを作るにはC/C++のほうがいい。チャットチャンネルには分散処理に適したErlangを使っている。Twitterでも同様に、パフォーマンスとスケーラビリティを確保するためにScalaをコアで使いながら、Ruby（Ruby on Rails）も併用しているという。

　こうした多言語によるプログラミングをRPCやSOAP、RESTで行うことは従来からも行われていたし、Facebookのように独自フレームワークを作る例もあったかもしれない。

　しかし、グーグルが公開した「Lord of hte REPLS」が示しているのは、もっと劇的な多言語プログラミングの可能性だ。同じVM上で数々のプログラミング言語が利用可能になる。これまでもJRubyやScalaなど、すでに可能だったものだが、GAE/Jの登場とサードパーティによる多言語サポートにより、クラウド上での多言語プログラミングが当たり前になる可能性が出てきたのではないか。

　もともとの業務システムはJavaで組んであるかもしれないし、ミッションクリティカル系ならホストコンピュータとの通信もJavaで行うかもしれない。しかし、WebアプリケーションならRubyやGroovyとJavaScriptの組み合わせたほうがいいだろうし、高度に並列処理が必要なメッセージ系や並列計算処理系といった領域ならScalaやClojure、Jaskellなど関数型言語に置き換えたほうが、開発効率や処理効率がいい可能性がある。

　これまでこうした“マイナーな”プログラミング言語は、研究向けの特殊なものと見なされた来た面もあるだろう。しかし、多言語が同じJVMの上で動くとなれば話は別だ。すでに実績のある堅牢で安全性の高いプラットフォームで、基本的にJavaを使い続けながらも部分部分を多言語化していくというアプローチはあり得るだろう。並列分散へのニーズが高まる時代には、ますます関数型言語への注目が集まるだろう。システムの一部を書き換えることで実行効率を大幅に上げるられるスキルを持ったプログラマやシステム設計の人材が活躍できる場が広がるのではないか。

　GAE/Jには、単にJava対応ということにとどまらず、多言語プログラミング時代の到来を予見させるポテンシャルが感じられる。