はじめに
みなさん，はじめまして。
今回からRubyによるオープンソースのメッセージングライブラリ，AP4Rの連載をさせていただくことになった加藤です。一緒にAP4Rの開発を進めている篠原とともに 4回にわたってご紹介させていただきます。
筆者らはフューチャーアーキテクト株式会社にて，自社製のJavaによるメッセージングミドルウェアの開発，メンテナンスを行なってきました。大小さまざまなプロジェクトで稼動してきたものであり，数十台規模での導入実績もあります。そこで培った実装や経験をもとにRubyで書きあげたものが，AP4Rです。Ruby 会議 2007でも取りあげてもらえたので，名前くらいは聞いたことあるよ，という方もいるかもしれません。以下，RubyForgeのプロジェクトサイトと日本語ホームページのURLです。
本連載では，AP4Rの開発にいたった背景にはじまり，AP4Rを利用したアプリケーション作成を例にとりあげながら，実装，テスト，運用上のポイントに触れていきたいと思います。
AP4Rとは
AP4Rとは，Asynchronous Processing for Rubyの略です。その名のとおり，Rubyで非同期処理を実現するためのライブラリです。
2006年初頭より篠原，加藤にて開発を進め，同年 9月にオープンソースとして公開しました（このときのバージョンは 0.1.0）。その後いく度かの機能追加を経て，執筆時点ではバージョン0.3.2となっています。
非同期処理というと文脈によっていろいろな意味にとれますが，ここではアプリケーションを疎結合化することにあたります。非同期処理自体がピンとこない場合は，電話とメールの関係をイメージしてみてください。すぐにでも相手の答えが必要な場合には電話，それほど急がない場合にはメール，といったようにみなさんも使いわけていると思います。電話の場合はそのときに相手の返事がもらえますが，相手がとても忙しいときにかけてしまうかもしれません。一方，メールであれば，受け手はある程度自由なタイミング（余裕のあるときなど）に依頼内容をこなすことができます。また，送り手も受け手側での処理が終わるまで待たずに，次の作業に移ることができます。いずれかが優れているわけではなく，状況に応じて使いわけることで，より柔軟かつ効率的に対応できると思います。
システム上でも非同期処理をうまく使うことで効率的な処理が可能になります。ログ出力やメール送信，重いサマリデータの作成やシステム間連携など，ユーザーに直接的に関係のない処理を切り離すことで，ユーザーへの素早い応答が実現できるでしょう。また，連携しているシステムの障害に影響されてしまい，問題の起きてないシステムでも処理が正常に終了できないといったこともなくなります。
図1 同期処理のみのシステム
図2 非同期化したシステム
AP4Rでは，メッセージングという技術で非同期処理を実現しています。
メッセージングを介して複数のサーバに処理を分散することで，負荷増大時のスケールアウトにも比較的容易に対応できるでしょう。
図3 複数サーバに処理を分散
キーワードは「堅牢」かつ「軽量」
前節では，メッセージングを利用してアプリケーションを非同期化することのメリットをみてきました。単に処理を切り離すだけなら簡単にできそうに見えたでしょうか？ ひょっとしたらそういったものをすでに利用あるいは実装している方もいるかもしれません。
実装する上で注意が必要なのは，メッセージが受け手に確実に配送されることです。途中でメッセージが消えてしまったり，重複してしまったら大変なことになります。
たとえば，みなさんがあるオンラインのショッピングサイトで商品を購入したとしましょう（この例はこのあともよく登場します）。決済処理が重たいので，注文の受付処理から非同期化されていたとします。すなわち，注文の受付処理と決済処理がメッセージングを介して切り離されている状態です。このとき，メッセージの配送がしっかり保証されていないと，お金を支払ったにもかかわらず商品が届かなかったり，あるいは二重にお金が引き落とされているといった事態が起きてしまいます。後者に関しては，アプリケーションで対応できますが（むしろ本来そうするべきだとも思いますが），前者に関してはメッセージングライブラリで確実に保証する必要があります。
システムが常に正常に動いていれば上記のようなことはなかなか起きないかもしれません。しかし，世の中そうはいかないものです。
データベースやネットワークの障害，サーバの突然のダウンは，絶対にないとは言いきれません。あるいは，連携しているシステムの定期メンテナンスを見落とすといった人為的なミスもあるかもしれません。
たとえなにがあろうとも，メッセージを死守する。それが信頼性のあるメッセージングに求められる必須要件となります。
また，AP4RはRubyで書かれています。Rubyのもつ簡潔さ，柔軟さをうまくいかし，設定やAPIができるだけ使いやすいものになることを狙っています。実装／テスト／運用をオールインワンでサポートした，導入しやすいライブラリとなるよう開発を進めています。
信頼できるメッセージングとして「堅牢」でありながら，Rubyらしさをいかした「軽量」なライブラリ。それがAP4Rの目指す姿です。
非同期処理の活躍の場
さて，非同期処理の用途としてすでにいくつか例をあげてきましたが，ユーザーを待たせている/待たせる可能性のある処理は非同期化によって改善できる可能性があります。チューニングのひとつの方法としても検討できるでしょう。
tDiaryの作者としてもお馴染のただただしさんがRubyKaigi2007での発表直後に書かれていたエントリ（Ruby会議2007 2日目 - 非同期重要 - ただのにっき (2007-06-10)）も興味深いです。
ここでは，エンタープライズの分野における非同期の重要性が説かれ，それとともに ウェブの分野でも，非同期処理への潜在的なニーズがあることがうかがえます。ユーザビリティと効率性の向上はいずれの分野でも大きな課題ともいえます。導入と運用が容易になれば，非同期処理の利用はまだまだ広がる可能性が感じられます。
