業務系処理の分散処理の実行基盤について(Asakusa0.2.6)

Asakusa supports for the multi-clusterというお話で、多分解説がいるので書いておく。公式に書くものではない、という意見も強いので、ここで書く。先日のSIGMOD日本支部のMtgでも発表した内容ともかぶりますが。

具体的にはここで
http://asakusafw.s3.amazonaws.com/documents/0.2/release/ja/html/yaess/multi-dispatch.html

いろいろ細かい内容は以下を参照で。
「AsakusaFW0.2.6の見どころ」
http://blog.goo.ne.jp/hishidama/e/2ba82d5ad404000de52d1a4029eb7346

まず、前提として現在のAsakusaは業務処理のバッチ処理、特に非同期処理を対象している。その上で実際に使われているし、SIも行われている。そこで出てきた問題として、「スモールデータ・スモールバッチの問題」が起きている。これは、まず一義的にはAsakusaの対処する課題ではあるが、俯瞰すれば、今後の分散環境の「統合のありかた」にも影響すると思う。

「スモールデータ・スモールバッチの問題」とは、端的に言うと、どう見てもHadoopクラスターで処理すべきではない、というサイズのデータや処理がジョブネットに入り込むという問題だ。

例として以下の二つを挙げる。一つはデータ自体が極小であるようなケースだ。

例えば下図の例、POSデータのクレンジングのケースでいうと、小さなデータを結合するような処理で、片方が全部メモリーにのってしまうようなケース。これはわりと普通にある。普通にサイドデータで乗っければよい、という話にはなるが、回数が頻繁になってくるとオーバーヘッドが馬鹿にならない。

もう一つは例外処理による分岐だ。これが問題になる。

例外処理は普通に正常系処理を行う。業務系では基本になる。情報系の処理では例外データはログに書いて「これはノイズです」とマークして、データ処理は続行させないだろう。しかし、業務系では100のインプットに対しては、アウトプットは100が必須だ。異常系の処理は可能な限り正常系のデータ処理の流れに乗せることが鉄則になる。これは、その方が業務的にハンドルしやすいので、最終的にトータルコストがさがるという歴とした理由もある。

それで実際の処理はどうかと言えば、大抵のデータは正常系であり、たまに例外系データが発生する、という感じになる。これがどの程度の頻度かというと、当然、業務によって異なるが、経験的には1%以下で、また、PPM単位であることも多い。問題は正常処理だろうと、異常処理だろうと処理のオーバーヘッドは実行環境が同じであれば、同じコストになるということだ。すなわち異常系の処理が圧倒的に効率が悪い。

で、これらの不必要におおきいオーバーベッドをどうすればよいか？という問題がある。まず正論から言うと、小さい処理はRDBMSで、大きな処理はHadoopクラスターで処理というのが基本である。当たり前と言えば、当たり前で、万能の実行基盤などないわけで、それぞれ見合った実行基盤で処理を行う方が圧倒的に効率がよい。

確かに、それはそうなんですが・・・・大規模開発では、そんな器用な事はとてもできない。普通に業務系は処理が複雑怪奇になることが多い。んで、実行層までとても視野にいれて実装することは非常に困難になってしまう。仮にやるとしても、かなり明確に仕切りをおこなって、サブシステムとして疎にしておくことが基本になる。しかし、混在では手の打ちようがない。

また、複数の開発基盤で開発することは障害が多い。品質も落ちる。なにより、工数がかさむ。それに加えて、そもそもどのデータ・どの処理が小さくて、どれが大きいか、ということを事前に決めるというのはかなりリスクが発生する。事後的に実行基盤を変えるというは、ほぼ作り直しに近い。

・・・つまりとてもマズイ感じになるのですよ。

なので、どうするか、ということでのAsakusaの解は、DSLレベルでは統一的に開発し、ジョブ実行時に「適切な実行環境を選択すればよい」ということになった。本来的に言えば、AsakusaDSLが自律的に、小さい処理はRDBMSに任せて、大きい処理をHadoopに振るというのが筋ではある。が、まずは「現状のAsakusa」が割とMapReduceに引っ張られているので、善後策として、小さい処理については、Stand-aloneモードでの実行を行っている。やってみれば分かるが、意外と速い。（尚、現時点では実行環境の選択は静的に行う。YAESSで指定する形になっている。）

俯瞰して見ると、これは割と大事なことを示唆する結果になったと思う。分散環境が普通に使われるようになってくると、ある程度「透過的に」分散環境と単独環境を意識せずに利用することが必要になってくる、ということだ。ちょっと前までは、まー、別々に使うものでしょう、という意見が大勢であったとは思う。自分も最初はそう思っていた。

ところが、実際にマジで使い始めるとそれは単なる絵空事でしかないことがわかる。「意識しての使いわけなどやってられない」というのが現実ではある。当然、この制御はミドル層で管理していく必要があり、アプリ層では制御はできない。そんなコストはアプリ側でとても負担できない。

さらに思うのは、分散基盤の実行環境がクラウド上ということになれば、アプリ層からは分散クラウドであろうと、オンプレ単ノード処理であろうと、「実行環境を明示的に指定することが必要ない」ということができるようになることが必要かな、と思う。これは当たり前と言えば、当たり前で、「この処理はクラウド上で分散処理した方がよいな〜」とプログラムが判断できるのであれば、実行基盤を動的に変えた方が、時間的・金額的なコストを最小化することが可能になるからだ。（・・・個人的には、実はこの辺を実際に（結果として）予言的にみていたのはMSだったりするな、とは思いますが・・）

ここまで俯瞰した上で、今後はAsakusa的には、以下の２点の方向に進む（と個人的には考えているが、チームのメンバーも相当いろいろ考えているし、いろいろ各所から知恵を頂いているので、どうなるかは不透明ですが・・）。その一里塚が今回のリリースになっている。

一つは、「実行環境の動的な選択の制御」と、もう一つは、「選択される、Hadoop以外の実行環境をどうするか？という問題」になる。

実行環境の動的な選択はコンパイラ技術と分散DB技術の良い所取りということになる。これは自分がどうこう言うよりもそのうちチームで結論が出てくるとは思うので、またしばらくしたら、実装をみてください、ということでここでは一旦パス。現在は、静的な選択になっていますね。

後者については、まずもって、ある程度のデータ規模（別にビッグデータでなくてよい）があり、全件にフェッチし、ソートやデータ生成を行う非同期処理の実行環境については、Hadoopで決まりだと思う。問題はそれ以外の実行環境で、これはまさに乱立状態でしょう。大本命は言わずもがなのRDBMSですが、いろいろダークホースもあると思う。現在は、単純にスタンドアローンモードを選択しています、という解になっているわけで。

このあたりの分散環境の、既存環境への透過的な統合、というのは課題ではあるし、いろんな手法が出てくるな〜と、そう感じております。
まぁ、そんな感じですわ。

PS:今日(2012/6/11)流れていた論文
http://www.eecs.berkeley.edu/~ychen2/professional/eurosys2012paper125-cameraReady.pdf
途中に、facebookでのjobの統計情報がなにげにあり、現実に98%近いjobが'7M程度のデータサイズ＋実行時間が1minということになっているのが読めて・・これだけではなんとも言えませんが、ビッグデータであろうと業務系であろうと同じ結論がでるのではないかと思う訳ですが、さてどうなるか。