Don'tStopMusic - DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる , るびま 21 号

2007-09-28

_ [ソフトウェア] DB分散の次は非同期処理がウェブアプリのスケーリングのトレンドになる

サイボウズも memcached + MySQL DB 分散

Cybozu Developer Network: MySQL Users Conference Japan 2007 講演概要を読んで、memcached でキャッシュ＆複数の MySQL をアプリのロジックで分散化というのは、もうすっかりスケーラブルなウェブアプリの作り方として常套手段になったと思いました。

2004 年 4 月の MySQL カンファレンスでの Brad Fitzpatrick の発表 Inside LiveJournal's Backend (PDF)から約 3 年半。Mixi やはてなのようなエッジな企業はだいぶ前からこの構成を採用してますが、対法人のビジネスをしているサイボウズでも採用されたというのは一つの節目じゃないかと感じました。

その次

で、タイトルに戻りますが、memcached やデータベース分散化の次には非同期処理がトレンドになると思います。非同期処理といっても Ajax のようなクライアント側ではなくて、サーバ側です。

また Brad Fitzpatrick の発表ですが、YAPC::Asia 2007 LiveJournal: Behind The Scenes Scaling Storytime (PDF) をぜひ読んでみてください。Inside LiveJournal's Backend 以降の LiveJournal のスケーリングの経緯が分かります。

Inside LiveJournal's Backend から増えた構成要素には MogileFS、Perlbal、gearman、TheSchwartz があります。それぞれ注目すべきソフトウェアですが、今回は gearman と TheSchwartz に言及したいと思います。

ウェブアプリは同期処理

プレゼン資料中では、gearman は「待ち時間の少ないリモートファンクションコール“ルータ”」、TheSchwartz は「非同期ジョブ管理システム」と説明されています。これだけでは分かるような分からないような説明ですが、それぞれどのようにウェブアプリで利用すると嬉しいのでしょうか。

「非同期処理ができるから」がその答えですが、その前にウェブアプリが同期処理ということを説明します。サーバは、ユーザのリクエストに対してレスポンスを返すまで何らかの一連の処理を実施しますが、この処理はほとんどの場合シーケンシャルです。

例を挙げて説明します。例えばブログでトラックバックを受信する処理を想像してください。典型的には、

パラメタを解析
スパムかどうかチェック、スパムだったら終了
データベースにトラックバックを追加
ページを静的に生成するシステムの場合は HTML 生成
ブログの持ち主にメール通知

のような流れになると思います。この一連の処理がすべて終わったら、トラックバックの送信元に対して成功/失敗を返すわけです。

処理の非同期化

ところで、これらの処理はすべてシーケンシャルに実施する必要があるでしょうか。言い換えれば、トラックバック送信元に対してレスポンスを返すにあたり、すべての処理が必須でしょうか。

そう考えると、「データベースにトラックバックを追加」が成功した時点で、トラックバック送信元にレスポンスを返せることがわかります。HTML 生成やメール通知が終わるまで待たせる理由は「アプリの作りがそうなっているから」以外にありません。

こうした場合で、HTML 生成やメール通知がボトルネックになっている時に、gearman が活用できます。HTML 生成やメール通知を「リモートファンクション」として実行することで、ウェブアプリのアクションの中でシーケンシャルに処理させず、非同期にできます。別プロセスで実行するといえば想像しやすいでしょうか。非同期になると HTML 生成やメール通知の処理を待たなくて済むので、そこがボトルネックだった場合にはレスポンスが改善されます。

ジョブ管理システムで負荷を平準化

さて、トラックバック処理の一部を非同期にしましたがまだレスポンスが悪い、例えば大量のスパムのためにトラックバック処理がアプリケーション全体の負荷の多くを占めているとします。こうした時、トラックバック処理全体を「リモートファンクション」として非同期にすることで性能を改善できる可能性があります。

スパムが高負荷の原因になるのは短時間に集中してやってくるからです。ウェブアプリはリクエストがあったら即時に処理しますので、処理の一部分を非同期にしてもリクエストが溢れる恐れはなくなりません。

要約すると、「短時間に集中・即時に処理 → 高負荷」です。短時間に集中させず即時に処理しなければ高負荷に繋がらないことになります。ただし、クライアントにレスポンスを即時に返さなくてはならないことは変わりませんので、この例では必ずトラックバックは成功したことにするといった仕様上の割り切りが必要です。

「即時に処理」についてはトラックバック処理全体を「リモートファンクション」として非同期にすることで対応できそうです。では「短時間に集中」はどうやって対処すればよいでしょうか。ここで The Schwartz です。

The Schwartz はジョブの実行制御ができます。与えられたジョブを即時に実行せずに、少し待ってから実行することなどが可能です。これにより負荷の平準化を図れます。

まとめますと、ウェブアプリは gearman にトラックバック処理を依頼、gearman は The Schwartz にジョブ登録、The Schwartz はトラックバック処理を高負荷にならないようゆっくり実行、という図式です。

Ruby/Rails ユーザの場合

gearman と The Schwartz は Perl で書かれていますが、gearman の方は Ruby のクライアントがあります。

また、Ruby には非同期処理を実現するためのライブラリとして AP4R があります。gearman が投げっぱなしなのに対して、AP4R はより信頼性の高いアーキテクチャになっています。AP4R については、AP4R，Rubyで非同期メッセージングという開発者による連載記事があります。その中で Rails で AP4R を使うチュートリアルがあります。結構簡単に使えますのでぜひ試してみてください。

ジョブ管理システムには BackgrounDRb があります。また、Rails Conf Europe 2007 で　Twitter の開発者 Britt Selvitelle のセッション Really Scaling Rails がありました。この発表の資料 A Small Talk on Getting Big で、Twitter で使用していると思われる独自の分散キューシステム Starling のことを触れています。オープンソースではありませんが、いずれそうするかもと匂わせてますので期待されます。