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

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

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

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のエンドで
処理をしているだろう。

まぁ、そんな感じだ。

富山県高岡市の「牛角高岡店」で食事をした客２０人が腹痛や下痢などの症状を訴え、うち１５人から腸管出血性大腸菌Ｏ―１５７が検出された。感染源と疑われるのは、富山県などで死者４人を出した「焼肉酒家えびす」のケースと同じ生肉ではなく、加熱用のハラミ。肉を取り分ける道具「トング」を使わず、直接ハシで生肉を取って焼いたことで感染したとみられる。

外川産業が兵庫県姫路市の駅前で鍛冶屋を始めて90年が過ぎ、
また、ツルハシやハンマーを主たる製造製品として製造してきて約６０年を過ぎました。

しかしながら、主な理由は姫路市の区画整理事業にともない
当社の大部分が換地処分（近くの別の場所に交換）となり
また、換地後の土地の種別が商業となるために、
もはや鍛冶屋を再度その場所で起こすことができないため
どこか別の場所への移転を余儀なくされました。　　　

もともと、従業員の高齢化も問題でしたが、
当社の特徴は従業員に身体障害者が昔から（祖父の代）たくさん働いていて
それはそれで、家庭的な雰囲気のままの仕事をしてきました。

移転場所として、長年探してはきましたがどうしても大きな音と振動のために制約があり、
また、障害者の雇用の継続を考えるとあまりにも　遠方へ移るわけにもいかず、
ついに昨年、工場を閉鎖して生産拠点を中国等の他の国へ移す決断をしました
それにともない、従業員の解雇、再就職支援等々を行ってまいりました。

幸い日本の国は障害者支援に関して手厚くサポートがあり
当社が長年障害者雇用をしてきたことをご理解いただき、
何とか再就職への道が開けそうで安心しております。

そのようなわけで、当社はこれまでの製造製品をすべて（ごくごく一部を除いて）廃盤とせざるを得ません。
また、残念ながら、兵庫県姫路市で、日本で一件で支えていたツルハシの製造から
撤退することになりました。これで、日本ではツルハシの製造と言うことに関して
全くできなくなり、すべて輸入品に頼ることになりました。　　
ごく一部の地方ではまだ一日に数本の製造されている野鍛冶はあるかもしれませんが。

それでも、当社の今までの得意先にご迷惑をおかけするに当たり、
中国本土で数社協力工場を探しましたが、残念ながら製造能力、規模、価格は十二分に満足するのですが、
どうしても当社の希望する形状、製品には程遠く困難を極めております。
残された時間はなく、とりあえず製造して輸入はしてまいりましたがこのままでは、
従来の「やま外」マークを刻印して当社の製品として販売する自身が無く苦慮しているところです。

残された道はやはり中国以外の国での工場建設、製造を目標としてがんばってみようと思い、
現在その方向で検討中です。

いろいろと残念なことも多いのですが、これも時代の流れとあきらめています。

しかし、日本の国から製造業を発達させることが難しい世の中になっているのが残念です。
その昔は、家庭が貧しくて中学を出てそのまま商人に向いている子供は商売の道へ、
ものづくりに向いている子は製造業への丁稚奉公に、勉強の好きな子供は高校、大学へと進学してきました。

その中で、才能のあるものはどんどんとその道のスペシャリストへなり、
生計を立てていける世の中だったと思います。

でも、今はどのような製造業でも派遣、営業でも派遣、を主な従業員として使い、
安い人件費には外国人を雇い入れて使い捨てているように思います。

そのような中でも、当社は中学を出た子供を従業員として雇い入れ、一から教え、
従業員の半分ぐらいは障害者を雇用し、いろいろなトラブルもありましたがひとつずつ解決しながら、
みんなでツルハシ、ハンマーを製造してきました。これが、90年続けてきた中でも、ひとつの自慢でしょう。

会社の経営とは苦しいもので、限りある資源と資金で従業員の生活を守り続けなければいけないのです。