第三回Asakusaソースコードリーディングの感想

AsakusaSCR第参回に参加してきました。今回はMonkey Magic（ジョブの運用監視ツール）について。
Togetter： 20110727_AsakusaSCR第参回（#AsakusaReading）

現在のMonkeyMagicのバージョンは0.9で、2.0で大改修すると共に名前を「Tengine」に変えてOSS化するとのこと。「T」と「engine」をくっつけて「てんじん」。
（あと、特許もとったらしい）

MonkeyMagicは2年くらい前から作り始めたそうで、元々はクラウド基盤（のリソース最適化）をターゲットにしていたらしい。その他に（値段の高い）商用製品の代わりとか、Hadoop（AsakusaFW）向けとかがターゲットになっている。

まぁ、AsakusaFWの中にMonkeyMagicIDなんて項目があったくらいだし(笑)
と思ってたんだけど、今日の話の中ではあまりAsakusaFWとの関連は出てこなかった。AsakusaFWのデファクトスタンダードになるのかと思ってたんだけどなぁ。
（主なものは、今後“AsakusaFWが動的にスケジュールを変える為の”情報提供機能を入れたい、というくらいか）

そもそも2.0で大改修するのは現在の仕組みに不都合があるとのことで、どんな不具合があったかという話と解決策の提示された。
主な原因として自前で機能を作りこみすぎて外部との連携が出来てないとか、顧客の話を聞かずに（想像で）進めたとか、これは自分も自戒しないといけないとこですね(汗)

---

MonkeyMagicでは、MonkeyMagicのサーバーやキューのサーバー・DBサーバー（MongoDB使用）は全て複数台（Actice-Active）で構成されていて、スケーラブルであり、単一障害点が無い。
監視対象マシンにはエージェントを入れておき、サーバーと通信（サーバーからエージェントへ設定変更したり、エージェントからサーバーへ状態を送信したり）する。このエージェントはインテリジェントではなく、エージェント間の通信も行わない。

で、Tengineではエージェントを2種類（システム監視用とジョブ実行用）に分け、通信用のキューの種類も減らす。
しかしキューを減らすと、フロントとエージェント（想定200個）の直接通信が増えて、障害時とかに問題になるんじゃないかとか、議論になった。
（クラウドの規格である）OpenStackやCloudStackではキュー指向らしい。
キューを使うにしても、優先度ごとにキューを用意する（OSではこの実装が多いらしい）・追い越しをするといった方法がある。
どういった方法をとるかが運命の分かれ道だそうで！

ジョブの制御とか障害検知時の動作とかは、まとめて「イベント」という概念で管理する。イベントに対してイベントハンドラを割り当てる。画面から有効化・無効化を設定可能。イベントハンドラはセッション（情報）を持つことが出来る。

1つのイベントに複数のイベントハンドラを登録可能とするので、どのタイミングでACK（正常応答）を返すのか（つまり障害が発生した場合の挙動）が問題になる。
これは場合によって異なるので、以下の3つの中から選択できるようにする。
１．全てのハンドラが正常終了したらACKを返す
２．1つでも完了したらACKを返す（現状はハンドラの登録順だが、優先順位をつけるべき？）
３．ハンドラ実行前にACKを返してしまう

Rubyを使ったDSLでイベントハンドラの割り当てを記述するらしい。ソースも見せてもらったけどRubyはよく知らないので雰囲気しか分からなかった＾＾； しかしイベントとハンドラの数ってけっこう多くなるんじゃないかと思うんだけど、記述しやすいのかなぁ？

もうひとつ出てきた概念が、「リソーストークン」。これは制御対象のリソースを表現するもので、トークンが獲得できたら処理を実行する、というもの。
例えば（これは自分の想像なので間違っているかもしれないけど）、「メモリーが4GB確保できて、ハードディスクが100GB空いたら処理を開始する」とか、「ロックを獲得できたら実行する」とか、そんな感じだと思う。「メモリー」「ハードディスク」「ロック」がリソースで、それを「トークン」という言葉で一元的に扱うのだろう。
これはなかなか面白い考え。
さらには、これを売り買いするところまで話を広がった。AmazonEC2の名前が挙がっていたけれど、確かに、クラウド上（基盤を共有）で自分が持っているリソースを他の人に売る（貸し出す）とか、緊急で使いたいときに他の人から買うとか、要望はありそうだよなぁ。

今後やりたい事として挙げられていたのは、まずリソースプロビジョニング。実行状況に合わせたサーバーの再配置とか、そういうのらしい。これと共に、AsakusaFWがジョブ最適化に必要とするデータを提供する。
もうひとつは、自動テストで非同期処理のテストを行う。RubyのFiberとObserverパターンを利用して、特定パターンの状態を再現できるんじゃないかと。（でも、非同期処理を記述するのは研究では昔から行われていて、それ専用の言語を使った方がいいんじゃないかというツッコミが…）

---

最後に今後のロードマップ。
8月末にOSS版を公開、9月末にジョブ機能β版、11月末にジョブ機能正式版をリリースするとのこと。

「OSS化する」と聞いていたので、今まで使われていたバージョンを公開するのかと思ったら、現在作成中（仕様検討中）のバージョンをOSSとして公開するようだ。今日の話を聞いていても検討事項はまだかなり多そうで、本当に出来るのかなぁ…？
しかも作ってすぐ公開ということになるから、実績がまた1から積み上げ直しって感じだよね…。

ジョブの運用監視ツールとしてはJP1が筆頭に挙がるし（値段が高いらしいけど）、Hadoop関連ではGangliaが紹介されていたり、色々選択肢はあるはず。
Tengineの売りって何？という疑問が会場から上がっていた。他のツールとは違う点ということで、DSLに注力したら？なんて声も。

そういえば、HadoopのMapReduceでMonkeyMagicが監視するのはJobTraker（つまり各データノードのTaskTrackerは対象外）ということでちょっと意外に思ったんだけど、普通のプロセス監視ツールでも、やっぱりTaskTrackerは対象外なのかな？
うーむ、データノードが死んだらHadoopが自動的に他のノードに処理を再割り当てするから、他のツールが監視する必要は無いのか。故障したサーバーの対処を運用者がする必要があるので、Hadoopのジョブ監視とは別のサーバー監視が要るってことか。

---

運用監視ツールは、障害が起きた場合も検知してちゃんと動かなきゃならない。（バッチならロールバックしてやり直せばいい、と言っても、運用ツールはそれ自体を行うものだから）こういうツールもかなり大変そう。

発表者の@akimatterさん、お疲れ様でした。