次世代アーキテクチャ - 急がば回れ、選ぶなら近道

次世代アーキテクチャについての考えをまとめておく。

まずは、Hbaseの勉強会のお話。
某界隈では割と話題になったので、
細かいブログやサイトは結構、紹介されている。
ので特に詳細は省く。

一応tatsuyaさんのSlideshareは
Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB…

slideを見ているだけでは、よくわからないと思うが
Jonathanとの会話では、FBはバックエンドの部分を含めて
バッチ処理は別のHadoop クラスターで行っている。
相当バリバリ使っているようだ。

したがって、割と話題になっているHbase上でHadoopMRはどうよ？
っていう話は「分ける」ってのが正解に近く、
フロント処理とバック処理は明快にわけることが基本になるようだ。

その上での印象で、
自分の思ったことを最近のやっていることと絡めてまとめおく。

1.次世代アーキテクチャ（といってももうすぐそこだが）は
多分フロントのインクリメンタル分散逐次処理と
バックエンド分散バッチ処理の組み合わせになると思う。
別にFBがどうだということではなく、
現状のHadoop基幹での処理をしていると思うことではあるので、
まぁFBのケースは判断の確証にはなった。

フロント周りは、非同期分散処理で逐次に必要な処理を
処理していく。バックエンドは必要に応じて
分散バッチ処理を行う。この場合、フロントとバックで
同時に処理が走るとリソース競合がシビアになるので
クラスターは基本的に分割することになる。

なので、ではフロントクラスターからバックにどう
データを移すか、ということがポイントになるだろう。

また、別の視点からみると、
これは従来のIT的な言い方であれば
オンラインとバッチを適正に利用するということに
他ならない。

派手な分散処理に目を奪われがちだが、
普通に見ると、必要に応じて最適なものを選択している
ということでしかない。

実はオンラインとバッチは本来は業務要件ベースでの
選択でなければならない。例えば一律連番をとったり
ある程度まとめて作業をする場合のデータのまとめ等は
絶対にバッチになるし、逆に引当データを共有するような場合は
できるだけフロント周りで処理することが基本だ。

しかし、残念ながら現行のオンライン・バッチの腑分けはむしろ
IT制約によることがほとんどだ。パフォーマンスや作りの問題で
バッチに倒すか、オンラインに倒すかは、むしろ技術的な都合で
決まることが多い。

「本当はバッチじゃない方がいいんだけどね」とか
「バッチにしたら負けだからオンラインの方に置いておく」なんて
話は、普通にある通りだ。

これ大抵はパフォーマンスネックの問題と技術の習熟の問題。

これからのアーキテクチャは両者でスケールアウトできて
かつ同じプラットフォームで行えるということになるだろうと思う。

2.時代は確実に非同期処理中心に動く
非同期の逐次処理、まぁカッコつきの「リアルタイム」処理とも言うべきか。
これでフロント処理をしておき、必要に応じて後方で
分散バッチ処理を走らせる、ということが基本になると思う。

これ全部非同期。

ということはどういうことかというと、
むしろ「当面は」一貫性要求が強いということだ。
非同期連携をしていくことが基本になる場合、
EventuallyConsistentは無理がある。

FBでは明確にCassandaraは使われていない。
生みの親が使っていない、というのは
それなりに理由があるわけで、一貫性という話も明確に出ていた。

これは、基幹バッチ的にどうか、という視点で見ても同意できる。

実際、基幹ではノンストップが最低ラインだけど
バッチが転けたとき、どうするかっていうと、
可能な限り速やかに復旧がマスト。
落ちないっていうのは、当然だけど、原発と同じで
まぁ1000年一回ってのは割とある。数年に一回はある。
残念ながらある。

駄目なときどうするか？
トレードオフとして取るのは一貫性になる。
残念ながらSplitBrainになるぐらいならきれいにダウンしてくれる方がよい。
FbのHbase勉強会で、エンプラ系が多かったのは本能的なものだろう。

3.フロントエンドの逐次処理は、あのFacebookですら
20-30secかかっている。
勿論凄まじい量のTXが来ているので
この時間でも驚異的である事はあるが、まったく勝負にならない
という時間ではない。

というか、むしろ今後はフロントの分散逐次処理は
普通の行われるであろうから、その時の基準として
20-30secというのは、良い線になると思う。

分散逐次処理は今後の焦点になる。
バックがHadoopというのはもうデファクトだろう。
この辺は、FBはPumeという独自のフレームワークにしているが、
ここの技術力競争が始まるはずだ。

ポイントはおそらくバックエンドとの親和性の問題が
クライテリアになる。

逐次処理もバッチ処理も・・・

3-1同じインフラで動くモノがよい
FBのHbaseの選択理由はおそらくこれだ。
HDFSを環境を利用したい（または、そのエンジニアが多い）ということだろう
たしかに別々のインフラでは、運用は間違い無く高くつく

3-2同じ開発手法が望ましい
多分ここはまだFBもできていないと思う。
基本は逐次もバッチも意識なく同じ開発手法で開発し
必要に応じて逐次・バッチが選べるという方が望ましい。

以上でござる。

あとまぁ脱線しますが・・HadoopはBI以外にも確実に使われている。
どうみてもFBでのHadoopの使われ方はBI以外の方が多いようにみえる
集計処理や非同期で大量アクセスが必要なものはHadoopのエンドで
処理をしているだろう。

まぁ、そんな感じだ。