【感想】Kansai.pm第9回ミーティング

Kansai.pm第9回ミーティングに行ってきた。
その感想を書く。

【1】Naoyaさんの話～Hadoop Streaming で MapReduce

はてなのNaoyaさんの話。
一番興味があったが、期待通りすごく面白かった。

MapReduceとは、GoogleLabの論文に書かれた分散処理の高速アルゴリズムの一つ。
並列計算アルゴリズムの一種で、Googleが使っている。
Googleはこのアルゴリズムを使って、大規模データを多数のサーバーで並列処理させている。
つまり、バッチ処理を高速化したものと言える。

MapReduceのアルゴリズムのイメージは下記のようにすごく簡単。

入力ファイル→map()→シャッフル→reduce()→出力ファイル

つまり、計算モデルは、関数型言語の特徴である「map：写像」「reduce：畳込み」の2個の関数を組み合わせただけ。
これは、UnixのPipe and Filterと同じ発想だ。

但し、並列処理させるために、分散ファイルシステムが必要。
Googleは、独自の分散ファイルシステム(GFS)を持ち、これが強力。
特に、冗長性に特徴がある。

例えば、1テラバイトのバッチ処理のために、1テラバイトのデータをネットワーク転送するのは、非常に不安定。
ネットワーク転送するだけで1日以上かかるだろう。
GFSというGoogleの分散ファイルシステムは、1 TBを64Mbにchunkして、その単位でワーカーに処理させている。
また、壊れたノードは、別のノードが引き継ぐなど、フォールトレランス機能もあるらしい。

詳細は下記を見よ。

http://www.radiumsoftware.com/0608.html

ここに興味深い一文がある。

関数型プログラミングを会得しない限り， Google に強大なスケーラビリティをもたらしたアルゴリズム ― MapReduce を発明することはできないだろう。 -- Joel Spolsky [Joel]

MapReuceの利点は、計算アルゴリズムがmap, reduceだけでいいという簡単さ。
つまり、巨大なデータを細かい処理に分割し、透過的に処理させる。
その実装プログラムは、ストリーム的な処理で解けるため、関数型言語でなくとも、大抵のプログラミング言語で実装しやすい。

MapReduceで解ける問題としては、検索エンジンのインデックス作成、ソート、検索結果のPageRankの計算、ドキュメント内のリンク参照回数の計算からWebページの有用度計算、など非常に応用範囲が広い。

つまり、Googleは、このアルゴリズムを使って、検索エンジンのインデックス作成を高速化しているのだ！

例えば、MapReuceを使うと、DVD1枚をGrepするのにわずか0.2秒で処理できるらしい！！！
(ただしタスク分散のオーバーヘッド有り)

Naoyaさんは、MapReduceという分散処理の高速アルゴリズムを使って、Perlで実現したらしい。
話した内容の詳細は下記と殆ど同じ。

http://d.hatena.ne.jp/naoya/20080511/1210506301

※講演資料が下記で公開されています。

http://d.hatena.ne.jp/naoya/20080531/1212245982

Naoyaさんは、Googleの論文を読んで、Perlで独自実装したらしい。
使い道としては、巨大なApacheログ解析や検索インデックス作成など。
膨大なテキストファイルを1日ぐらいかけて読み込んでバッチ処理するのを高速化するのに向いている。

後で聞いたら、MapReduceには結構バッドノウハウがあるそうで、分散ファイルシステムだけでなく、シャッフルやReduceなどの処理で色々アレンジするらしい。

【2】バッチ処理の高速化が意味するもの

バッチ処理は業務システムの基本アーキテクチャだ。
特に金融系システムでは、毎日数万～数十万のトランザクションデータをバッチで一括処理するのも稀ではない。
この処理の実装は簡単であろうとも、テストして品質を確保するのは非常に難しい。

何故なら、高負荷な環境でしか再現できないバグは結構あるのに再現させにくい。
また、バッチ処理が異常終了した時、全件ロールバックさせると更に負荷がかかる。
だから、100件おきにチェックポイントを区切り、途中までCommitを実行し、途中から再開できるような仕組みを作る必要がある。

つまり、バッチ処理は、高負荷な環境のシステムテストや異常処理の設計がかなり難しいのだ。
しかし、Googleが適用しているMapReduceモデルでは、GFSというGoogle独自の分散ファイルシステムを使って、壊れたノードは別のノードが引き継ぐという冗長性を確保している。
並列処理なので、プロセスが死んでも他プロセスが引き継げばいい。

Naoyaさんも言っていたが、バッチ処理は冗長性が非常に大事。
いわゆるフォールトレランスが大事なのだ。

【3】日本のSIerの現状

上記の話を聞いて、非常に驚いた。
関数型言語の計算モデルがバッチ処理を抜本的に変えたとも言える。

日本の大手SIerのプログラマ、プロジェクトリーダーは、マンパワーでシステム開発し、マンパワーで品質を確保しようと懸命になっている。
Googleは、システム開発の前提条件そのものをひっくり返して、画期的アーキテクチャで作り直している。
当然、品質確保のやり方も日本のSIerと全く違う。

はてなのNaoyaさんは、少なくとも、Googleの論文を読んでいる。
日本の大手SIerにいるプログラマ、プロジェクトリーダーで、Googleの論文を読んでいる人はいるだろうか？
皆、残業に追われて、デスマーチに追われているうちに、Googleが生み出した技術などに取り残されている。
自分の技術が古くなっている事実にも気づかずに。

はてなは日本のGoogleみたいだ。