GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
News
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
MagLev：GemstoneがSmalltalk VMをベースに構築するRubyランタイム
作者 Werner Schuster , 翻訳者 編集部 投稿日 2008年5月21日
InfoQ: VMレベルではGemstone/SとMagLevの関係はどうなっているのでしょうか。
MagLevとGemstone/Sは確かに多数のコードと機能を共有していますが、VMレベルを含めて両者は別個の製品です。MagLev VMが使っている多数のバイトコードとアルゴリズムはRuby特有のものになっています。しかし、Smalltalkのコードを動作させる能力は保持しています。
InfoQ:プロジェクトは何人体制になっているのでしょうか。現時点での予定はどうなっていますか。
専任でない者も含めると、約8名がMagLevに取り組んでいます。実のところ今は予定についてお話しできませんが、RailsConfでは少しお話しできると思います。
InfoQ: MagLevは何で記述しているのでしょうか。「Turtles all the way down」なのでしょうか。
私たちの目標はRubiniusプロジェクトの目標に似ており、パフォーマンスに影響される数個のプリミティブを除き、標準ライブラリの全メソッドをRubyに実装することです。VMはCで記述しています。
InfoQ:VM向けにバイトコードを作成しているのでしょうか。つまり、RubyはどのようにVMにヒットするのでしょうか。
はい、VM用のバイトコードを作成しています。このバイトコードはいくつかのアーキテクチャでネイティブコードを任意で作成できます。
InfoQ: Rubyのパースには何をお使いですか。（純粋なRuby ruby_parserでしょうか、自前で構築したものでしょうか。）
私たちは多数のパーサーから内部表現に翻訳できるので、それを使ってコンパイレーションします。最終製品に同梱するパーサーについては、まだ決めていません。
InfoQ: Rubiniusプロジェクトから（Rubyのスペック以外で）使っているものはありますか。
Rubinius bmのスクリプトとテストを使って、Ruby実装の様々なパフォーマンス数値を収集しています。それから、進化し続けるRuby標準とMagLevのAPIレベルの互換性を約束する上で何が役立つかを確認するために、MSpec実装やスクリプト、テストに注目してきました。とは言っても、この他いくつかのRuby実装でも同様のことを試しています。Rubiniusとは、最終的には可能な限りたくさんの標準ライブラリコードを共有できればと思っています。
InfoQ: 1.0では、どういったパフォーマンスを目標にしていますか。
生の性能よりも、スケールに焦点を当てています。他の実装と比較した場合、パフォーマンスで断然有利と思いますが、スケールに強いアーキテクチャこそが最も興味深い差別化要因であると確信しています。
InfoQ: MagLevのスレッディングはどうなっているのでしょう。ネイティブの１対１ですか、それともm対nモデルや、単純なユーザー空間スレッドでしょうか。
個々のVMには単純なユーザー空間スレッドがあります。しかし、複数のVMは同一オブジェクトへトランザクションで同時アクセスできるため、最終的にはm対nモデルに似たものとなります。
InfoQ: WalkerさんがRailsConfに出席なさることを考えると、Rails互換性を目標にすると言ってしまって大丈夫なのでしょうか。それとも、まずやっておくこと（たとえばMerb）があるのでしょうか。
とても興味深い質問で、私たちも真剣に考えているところです。私たちの計画では、MagLevは間違いなくRails可能／互換になります。その過程で非常に多くの潜在的な（そして実際の）了解事項に遭遇するでしょうから、達成は容易ではありません。Railsに取り掛かる前に、完全にRubyで動作可能でなければならないと、私は考えています。代替案も検討中で、おそらく、Rubyで書かれたものならどんなものでもサポートできるようになるでしょう。何を、どんな順番で行うかの優先順位づけについては、Rubyコミュニティからのフィードバックや関心によって大半が決定します。
InfoQ: OODBでActiveRecordを使えるようにするのでしょうか。それとも、ユーザーはMagLevで特定のAPI使用を望んでいるのでしょうか。あるいは使用しなければならないのでしょうか。
MagLev DBでActiveRecordを使用可能にすることは、非常に価値ある目標ですが、ActiveRecordのAPIにはオブジェクト状態をSQLベースのRDBに格納すると想定する部分が存在するため、これが難題となる可能性があります。とにかく、ActiveRecord下にいかなるAPIを用意したとしても、ActiveRecordを使いたくない方々はそのAPIを利用できるようになるだろうと思われます。この件に関してこれ以上お話しするのは時期尚早であり、コミュニティにとってどのようなタイプのアプローチが一番有益であるかを、コミュニティが教えてくれたらありがたいと思っています。
InfoQ: MagLevを標準Rubyのドロップイン代替物とするおつもりでしょうか。それともSmalltalk風のイメージのようなデプロイメントを使う予定でしょうか。
ドロップイン代替物としてのMagLevの使用は間違いなく可能でしょう。イメージベースのアプローチを好まれる方々には、そうしたサポートもありますが、利用を強制するものではありません。
InfoQ: RubyコードはSmalltalk風のイメージにプロセスを持続できるでしょうか。
一言で言えば、できます。たとえば、GLASS製品では現在、エラーのあったプロセスをリポジトリに保存でき、後でそれを引っ張り出してローカルのVMでデバッグできます。同じことをRubyでできない理由はありません。
InfoQ: GLASS製品同様のライセンス・モデルをご利用になる予定ですか。
現在、様々なモデルを検討中です。MagLevでも同様になるでしょう（が、保証はできません）。
InfoQ: すでにMagLevに関するツールの話はありますか。Ruby IDEを（GUIのデバッギング向けなどに）フロントエンドとしてサポートするおつもりでしょうか。
もちろん、IRBシェルや、MagLev上でRubyコードを動作させるためのRuby様のコマンドになる予定です。IDEプラグインも希望していますが、GUIツールが現実になる時期を憶測するのは危険です。MagLev開発チームは、Rubyコミュニティに手を差しのべ、サポートする心づもりであることをお伝えしたく、また、コミュニティの皆さんがMagLevへ貢献したくなるような理由を見つけてくださることを願っています。GemStoneは、動的言語やスケーラブルなバーチャルマシン、ネイティブ言語のオブジェクト持続性を得意分野としています。ツールやUIを得意とする方々は他に多数いらっしゃり、そうした方々のMagLevに向けた尽力を私たちは喜んでサポート致します。
InfoQ: MagLevにRubyコードを載せて、Smalltalkコードやオブジェクトと相互作用させる可能性はないのでしょうか。
MagLev VMはRubyを理解する以外にも、Smalltalkを完全に理解できます。相互作用させる可能性はかなり高いと言えますが、後戻りできないところまで進んでしまう前に、相互作用が望まれている機能で、コミュニティの役に立つかを検討したいと思います。
Gemstoneがオープンソース技術を扱うようになってからしばらく経ち、たとえば、Gemstone/S上でSeaside (サイト・英語)Webフレームワークを動作させるソリューションを提供している。これが、GLASS（GemStone、Linux、Apache、Seaside、Smalltalk）(サイト・英語)として利用可能になっている。GLASSは最大4GBのデータベースまで無料で、他のライセンスも利用できる。
SeasideはAvi Bryant氏が作成したもので、氏はRuby向けにSmalltalk VMを再利用しようというアイデアを推奨する一人である(source)（同じトピックのBryant氏の記事「Turtles all the way down」(source)を参照のこと）。Bryant氏はビデオインタビュー（近日InfoQでリリース予定）の中で、Seaside(サイト・英語)およびDabbleDB(サイト・英語)の仕事や、GemStone、MagLebとの関わり合いについて話している。MagLevプロジェクトについて、氏は次のように語っている。
RubyにSmalltalkの技術とノウハウを応用せよと、私はSmalltalkのベンダーに何年もロビー活動を行ってきましたが、それがようやく現実となり、わくわくしています。MagLev実装を始めて3ヵ月足らずですが、これまでの成果で非常に自信がつきましたし、RailsConfではすばらしいデモをお見せします。RailsConfまで、残念ながら詳細は教えられませんので、Confでご覧ください。
Bryant氏は最近のブログで、Gemstoneのソリューションと、memcachedb や同様の技術を用いてRailsプロジェクトで構築したソリューションを比較することにより、GemstoneのようなOODBの利点を紹介している(source)。
Gemstoneはどうでしょうか。偶然にもアーキテクチャはまったく同じで、単一の記憶エンジン（「ストーン」という）とサーバー毎にメモリーキャッシュ（「共有ページキャッシュ」）、多数のSmalltalk VMのワーカープロセス（「ジェム」）があります。ジェムが要求を処理してコードを実行し、スピードを求めてオブジェクトをページキャッシュに置き、また、持続性を求めてストーンにしまいます。Gemstoneでの違いは、すべてが可能な限り迅速かつシームレスに連携するように、ゼロから設計されているところです。
注記：ブログではさらに掘り下げ、ソリューションや異なるアプローチについて詳細にわたる概要を説明している。
GemStoneは、5月のRailsConf 2008において、MegLevの詳細を披露する予定である(source)。
原文はこちらです：http://www.infoq.com/news/2008/04/maglev-gemstone-builds-ruby
関連情報
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
No comments
スレッド表示 返信