IT-PRESSこの広告は、90日以上更新していないブログに表示しています。思い込みや想定に基づいた事も書いてるので、鵜呑みして騙され注意報発令さしとく。最近分散技術系の話題をよく聞くようになりました。企業内グループ内で使うような業務システムであれば、そこまで無茶な数のアクセスも無いだろうから、数台〜数十台規模のサーバを立てればだいたい事足りたのだろう。DBサーバ」という3レイヤにして、各サーバを冗長化していく、等の手法でどうにかなった。処理リクエスト数の増大や、処理対象データの増大、そして処理ロジックの複雑化に伴って、大量のデータを逐次処理するだけでは処理が追いつかない世界が出てきた。業務システムではなく、サービスプロバイダの世界では、この現象は顕著。Webサーバ層とAPサーバ層の冗長化は比較的簡単だけども、DBサーバ層は大量のステートを持っているレイヤだから冗長化がめんどくさい。1つのサーバに更新をかけても同時に他のサーバに更新がかかる訳じゃない。一瞬かもしれないけど整合性が崩れる。いうか、負荷分散のための冗長化なのに、レプリケーションのコスト大きすぎて逆効果だったりしないのか心配になります。なんか、今までのパラダイムだと、このような大きな情報処理にはついていけない。いうことで分散コンピューティングとかいう考え方が話題になってきた。(他にも理由は色々ありそうだけど)例えば大量のアクセスログから、特定の条件にマッチしたものを抽出する場合。今までだったら、ログを頭から読んでいって、1エントリ毎に条件を検討して、マッチしていたら別に出力。いうようなことをするだろう。1台のマシン(ノード)に複数のスレッドなりプロセスを乗せて並行処理をしても、処理スケールには限度がある。前の例では、恐らく処理速度は数倍にはなったとしても100倍には及ばないだろう。1ノードの限界は決まってるのだから。従って、複数のノードにまたがって処理を分散させなければ、あまり大きな効果は望めない。ノードの数を100台にできれば、処理速度100倍は無理にしても、それに近いパフォーマンスは出せるのではないか。並行処理(マルチスレッド等)プログラミングってのは異様に難しい。「ここに大量(数TB規模)のasciiの英文テキストファイルがある。この中で使われている英単語の中で1番出現頻度の高い単語を抽出せよ。」というジョブがあったとする。この処理プログラムを単ノード単プロセス単スレッドで書くのは難しいことじゃない。条件として「結果は1分以内に返してください。難しくなると思います。従来のコーディングのパラダイムでロジックを実装すると、分散に対応できる実装にはならない。分散処理を目的としたロジックの書き方、というものがある。分散向きのロジック記述の枠組み、すなわち、フレームワークが欲しい。いうのがMapReduceだ。この枠組みの上でロジックを実装すれば、あとはフレームワークが上手いことジョブをタスクに分割して、タスクを各ノードに分散させて、結果をマージしてくれる。MapReduceは、ジョブをこういう仕組みの上に実装すると、分散しやすくなるよ、という指針であり、そのように実装されたジョブをどのように分散処理すべきなのかを記した仕様。この仕様をJavaで実装したのがHadoop。いう枠組み上に乗せ、それを実装するのか?ってのがキモになりそうだ。手続き型からオブジェクト指向へのパラダイム転換と同じ様に、プログラム記述の考え方をひっくり返さなきゃいけないかもですね。分散技術が出てきた背景Tweet広告を非表示にする関連記事2011-06-04Mahoutで分散レコメンド(1)さて、ちょっと間があきましたが。前回まで、いったんレコメン...2009-12-25課題管理システムの勘所(3)しばらく間が開いてしまったが。コミットは、DB構成の同期も取って大抵、アプリケーション開発では、SCM*1を使って、変更履歴を管...2008-12-14interfaceについて本気出して考えてみた本気出す第二弾。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事クラスメソッド株式会社に転職しました!またな、山城。月別アーカイブはてなブログをはじめよう!daisuke-mさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。