EventMachineは、Reactor設計パターン(リンク)に基づくネットワークおよび同時実行プログラムのためのフレームワークである。Reactorパターンは､イベントを受け入れるサービスハンドラを記述して、それらを登録されたイベントハンドラにディスパッチする。Reactorパターンの利点は、マルチスレッドコードを複雑にすることなく、イベントディスパッチとイベントを処理するアプリケーションロジックを明確に区別することである。
EventMachineは、ネットワークソケットへの高レベルのインターフェイスを提供し、低レベルの操作を表示しないようにする。EventMachineの目標は次のとおりである(リンク)。
- 最も要求の厳しい実稼動環境での卓越したスケーラビリティ、パフォーマンスおよび安定性。
- 高性能のスレッドネットワークプログラミングの複雑性を排除した APIにより､技術者がアプリケーションロジックに集中できるようにする。
次に､単純なチャットサーバの例を見てみよう。
require 'eventmachine'
module Chat
# Called after the connection with a client has been established
def post_init
# Add ourselves to the list of clients
(@@connections ||= []) << self
send_data "Please enter your name: "
end
# Called on new incoming data from the client
def receive_data data
# The first message from the user is its name
@name ||= data.strip
@@connections.each do |client|
# Send the message from the client to all other clients
client.send_data "#{@name} says: #{data}"
end
end
end
# Start a server on localhost, using port 8081 and hosting our Chat application
EventMachine::run do
EventMachine::start_server "localhost", 8081, Chat
end
InfoQは､EventMachine (EM) の開発責任者Francis Cianfrocca氏にインタビューを行い、EventMachineを開発した動機について尋ねた。
最初は、Rubyなどのスクリプト言語で簡単にプログラミングできる高性能のメッセージ指向のミドルウェアを作成したいと考えてプロジェクトに着手しました。その段階では、EMで作成されたプロジェクトは多数ありましたが、ミドルウェアのプロジェクトは皆無だったのです。わたしは、グローバル企業を対象とした高度にスケーラブルなアクセス ポリシー実施ソリューションを作成する方法を模索していました。また、高速でありながら、適切なセキュリティが組み込まれた通信フレームワークを求めていました。
EventMachineを使用しているのは、Thin(リンク)（高速で非常に単純なRuby Webサーバ）､Swiftiply(リンク)（Webアプリケーション用のクラスタリング・プロキシサーバ）、Evented Mongrel(リンク)（ネットワーク トラフィックがEventMachineによって処理される Mongrel）、Sparrow(リンク)（memcacheと対話する軽量のキュー）およびJuggernaut(リンク)（サーバの接続開始を可能にして、データをクライアントに送信する Ruby on Rails用のプラグイン）である。Francisは、自身のWebフレームワークも作成している。
わたしのWebフレームワークはUnicycleと呼び、Web要求に対応するために他のアプリケーションと接触する必要のある RESTfulアプリケーションを対象としています。また、EMを基盤としており、EMのビルトインHTTPサーバを使用しています。
EventMachineのVersion 0.12が最近リリースされた。
Version 0.12では、パフォーマンスがやや向上し、軽微な機能が多少追加されていますが、最大の動機は、0.8以降に追加したすべての機能を備えた Windows用のバイナリgemをリリースすることでした。
EventMachineの中核であるReactorは､本来C++に実装されており､Rubyに加えて他の言語へのバインドもある。ピュアRuby実装もあり、次のバージョンの1つでは、JRubyとともに使用するためのJava実装のリリースが見られるだろう。
まもなくリリースされる最も重要な機能は、JRubyの完全サポートになるでしょう。そのためには、ReactorのコアをJavaに完全に再実装する必要がありますが､実際かなり順調にいっています｡Charles Nutterと彼のチームは､JRubyに関して目覚しい働きをしてくれましたし､そこに大きな可能性があると考えています｡また､Rubiniusにも大きな関心を寄せています｡Rubiniusの興味深い点はファイバーのサポートであり､それによってEMのためのより自然なプログラミングのスタイルが可能になります｡わたしはすでにRuby 1.9 でファイバーのサポートを試みましたが､新しいプラットフォームを使用する人が増えないかぎり､APIを分岐する決心がつきません｡EMの重要な設計目標の1つは､常に最大の互換性だからです｡
FrancisにEventMachineの利点について詳細な説明を求めた。
EMを使用する重要な技術的理由は、スレッドを避けるプログラミングモデルを可能にすることです。スレッドプログラミングは、ネットワークサーバを主な対象とした周知のモデルですが､一部に根深い問題を抱えています｡スレッドモデルに相応の比較的小規模なクラスの問題があります。ネットワークサーバは、通常、各要求について非オーバーラップワーキングセットを構築することが可能であるため、そうした問題の1つになることがあります。しかし、当然、スレッド間に共有状況がある場合、あるいはサーバがスレッド間に適切に順序付けられた操作に依存する場合、スレッドプログラムを100%正確にすることは至難の業です。さらに、Rubyには、スレッド化が高価になるという問題もあります。
EMを使用する他の理由としては、当社が詳細設定の不要なネットワークプロトコルを幅広くサポートしていることが挙げられます。目標は、アプリケーションに簡単にドロップできる、成熟した高性能で大型のツールをプログラマーに提供することです。これこそ、EMが、たんに Reactorモデルを実装しようとする多数のプロジェクトと異なる点です。
イベント駆動型プログラミングについて、スレッド モデルと比較して扱いやすい理由なども尋ねた。
イベント駆動型プログラムは理論上、スレッドプログラムに比べて高速ではないという説に関しては多数の著述がありますが、これは真実です。しかし、実際には、最大の耐障害性を確保しつつ卓越したスケーラビリティとパフォーマンスを実現しようとする場合、イベント駆動型モデルは取り組みやすいと思います。わたしは、数ヶ月または数年間もクラッシュ、メモリリーク、パフォーマンスの不安定を起こすことなく実行できるプログラムを作成しているので、実際には、イベント駆動型プログラミングの方が良い結果を生みます。イベント駆動型プログラミングにも問題はあります。プログラムは "逆方向" に記述しなければなりません。スレッドモデルでは、プログラム状況を（非効率的に）ランタイムスタックのローカル変数に保存します。EMでは、これをプログラマーが手動で行う必要がありますが、スレッドに慣れたプログラマーにはわかりにくい作業です。わたしがファイバーに関心を持つ理由は、I/Oのブロックのようにプログラマーの目で確認できるものを記述する可能性が開けるためですが、いまだにイベントを扱い、スレッドは使用していません。
HTTPサーバを例に使用して、これを詳細に検討してみよう。
HTTPサーバを想定してみましょう｡スレッドの場合､ソケットを読み込み､リモートピアからすべてのデータが取得されるまでブロックするだけで済みます。イベントの場合、データが表示されると同時にデータを取得します。待つことはなく、オーバーヘッドのスケジュールもありませんが、完了しない可能性もあります。プログラムは、要求を解釈するために十分なデータを受信していないことを検出し、部分的なデータを保存する必要があります。しかし、プログラムが処理する次のイベントには、別の接続のデータが含まれる可能性があるので、これをすべて区別する必要があります。スレッディング抽象は、ワーキングセットを区別するかなり大掛かりな方法なので、プログラミングのタスクは間違いなく直観的になります。一方、イベントモデルは習得が難しいわけではありません。それでも、イベント駆動型プログラミングを普及させるには、習得時の難易度が最大の障害であると考えています。
幸運にも、ここからEventMachineが動き始めた。
EMの機能の1つは、標準のプロトコルをラップして、これらすべてがプログラマーにほとんど見えないようにすることです。Reactor コアのみを提供するlibevのような下位のライブラリとは異なり、EMは、e-メールなどのすべての標準ネットワークプロトコルに対して障害に強い実装を提供することを目指しています｡EMには､SMTPのクライアントおよびサーバ サイドの両方に使用できる高度なハンドラが含まれています。したがって、EMプログラマーだけが、完全なe-メールメッセージと関連付けられたイベントを処理するコードを記述する必要があります。基礎となるプロトコルに関与する必要はありません。それでも、イベントモデルの他のすべての利点（高速、高スケーラビリティ）が得られます。
EventMachineの詳細については、公式のRubyforge Webサイト(リンク)およびrubyeventmachine.com(リンク)を参照。
われわれが最近オープンしたコミュニティ サイト rubyeventmachine.com (リンク)は、Jason Roelofsによって行われた Trac実装です。EventMachine IRCチャネルもあります。Kirk Haines、James Tucker (raggi) および Aman Gupta (tmm1) を始めとする多数の技術者がEMに多大な貢献をしています。Thinを扱う Marc-André Cournoyerなどからも多数のアイディアをいただきました。