Hadoopとかに入門してみる 〜 分散技術が出てきた背景

調べたメモ。色々思い込みや想定に基づいた事も書いてるので、鵜呑みして騙され注意報発令さしとく。

最近分散技術系の話題をよく聞くようになりました。企業内グループ内で使うような業務システムであれば、そこまで無茶な数のアクセスも無いだろうから、数台〜数十台規模のサーバを立てればだいたい事足りたのだろう。例えば、サーバ構成を「Webサーバ - APサーバ - DBサーバ」という3レイヤにして、各サーバを冗長化していく、等の手法でどうにかなった。

ただ、処理リクエスト数の増大や、処理対象データの増大、そして処理ロジックの複雑化に伴って、大量のデータを逐次処理するだけでは処理が追いつかない世界が出てきた。業務システムではなく、サービスプロバイダの世界では、この現象は顕著。

また、Webサーバ層とAPサーバ層の冗長化は比較的簡単だけども、DBサーバ層は大量のステートを持っているレイヤだから冗長化がめんどくさい。1つのサーバに更新をかけても同時に他のサーバに更新がかかる訳じゃない。一瞬かもしれないけど整合性が崩れる。っていうか、負荷分散のための冗長化なのに、レプリケーションのコスト大きすぎて逆効果だったりしないのか心配になります。

等々。なんか、今までのパラダイムだと、このような大きな情報処理にはついていけない。ということで分散コンピューティングとかいう考え方が話題になってきた。ってところかな。（他にも理由は色々ありそうだけど）

例えば大量のアクセスログから、特定の条件にマッチしたものを抽出する場合。今までだったら、ログを頭から読んでいって、1エントリ毎に条件を検討して、マッチしていたら別に出力。というようなことをするだろう。そうではなくて、大量のログを例えば100個に分割して、100個のタスクを同時並行処理して、それぞれの結果をマージする、とすれば処理速度上がるよね？ という話。

ただ、1台のマシン（ノード）に複数のスレッドなりプロセスを乗せて並行処理をしても、処理スケールには限度がある。前の例では、恐らく処理速度は数倍にはなったとしても100倍には及ばないだろう。元々1ノードの限界は決まってるのだから。従って、複数のノードにまたがって処理を分散させなければ、あまり大きな効果は望めない。ノードの数を100台にできれば、処理速度100倍は無理にしても、それに近いパフォーマンスは出せるのではないか。

また、並行処理（マルチスレッド等）プログラミングってのは異様に難しい。例えば「ここに大量（数TB規模）のasciiの英文テキストファイルがある。この中で使われている英単語の中で1番出現頻度の高い単語を抽出せよ。」というジョブがあったとする。この処理プログラムを単ノード単プロセス単スレッドで書くのは難しいことじゃない。しかし、条件として「結果は1分以内に返してください。ハードウェアの数はいくらでも用意しますので…」とか言われたらどうでしょう？ 突然難しくなると思います。

従来のコーディングのパラダイムでロジックを実装すると、分散に対応できる実装にはならない。分散処理を目的としたロジックの書き方、というものがある。ならば分散向きのロジック記述の枠組み、すなわち、フレームワークが欲しい。というのがMapReduceだ。この枠組みの上でロジックを実装すれば、あとはフレームワークが上手いことジョブをタスクに分割して、タスクを各ノードに分散させて、結果をマージしてくれる。

MapReduceは、ジョブをこういう仕組みの上に実装すると、分散しやすくなるよ、という指針であり、そのように実装されたジョブをどのように分散処理すべきなのかを記した仕様。そして、この仕様をJavaで実装したのがHadoop。

今までフリーダムに実装してきたロジックを、どのように MapReduce という枠組み上に乗せ、それを実装するのか？ってのがキモになりそうだ。手続き型からオブジェクト指向へのパラダイム転換と同じ様に、プログラム記述の考え方をひっくり返さなきゃいけないかもですね。