いま分散システムが面白い理由
最近 クラウド という単語が流行していますが、「大規模な計算資源を低コストで提供してくれるトコロがあるらしいので、自前で持っていた計算資源を委託しちゃえば運用する手間も知識も要らないし、そもそもサーバーを買う費用を省けちゃうから嬉しい」という発想に基づいているらしく、しかし技術的には 大規模な計算資源を低コストで構築する技術 がポイントでしょう。
大規模な計算資源をどうやって安く構築するか。
従来は、システムの能力を高めるためには、高性能・高機能（それゆえ高価な）マシンを導入するというスケールアップの手法が採られていたのだが、この手法では10倍に性能を上げるために、たとえば30倍のコストがかかるかもしれない。スケールアップと比べてスケールアウトでは、導入したコストにほぼ比例して、パフォーマンスの向上が見込める。
『UNIX magazine 2009年4月号』 p.31 *1
何百万円もするハイエンドなサーバーを1台買うより、チープなマシンを10台買って並べた方が革命的に安上がりだというわけです。要求される性能が高くなればなるほど、その差はどんどん開いていきます。
では10台のマシンをケーブルで繋げるだけで良いのかというと、そうはいかないところが面白い。
私はP2P型の分散プログラミングのたとえに、砂漠と電話を取り上げます。
あなたは広大な砂漠に立っています。
どうやらその砂漠には他にも何人もの人がいるようですが、あまりに広いために他の人がどこで何をしているのか知ることはできませんし、いつ誰が死んでしまうかも、新たな人がこの砂漠に迷い込むかも分かりません。しかしただ唯一、電話を使って他の人と連絡を取ることができます。
この電話はちょっと多機能で、他の人全員にメッセージを送る機能（ブロードキャスト）があるのですが、その場合は確実にメッセージが到達しないかもしれません。
- さて、その砂漠に何人の人がいるのか確認してください。
- 次に、あなたの名前を他の人全員に伝えてください。
- リーダーを1人選んでください。
（1人だけですよ）- オアシスを発見しました！他の人に確実に、できるだけ速く伝えてください。
（ブロードキャストすると到達しないかもしれません）- 誰かがオアシスの場所を知っているようです！確実に、できるだけ速く確認してください。
（全員が一斉にブロードキャストすると大量のメッセージが行き交って大変。伝言していく方式だと遅いですね…）- あなたはいずれ死ぬ運命ですが、すべてのオアシスの場所を未来永劫まで伝え残してください。
（誰かに同じ内容を伝えておくと良いですが、その人もいずれ死ぬ運命ですね…でも全員が同時に死んでしまうことはないでしょう）
少々無茶なたとえですが（笑）、要するに信頼性のないEthernetだけで繋がった、いつ壊れるかも知れないチープなマシン同士が、お互いに連絡を取り合いながらできるだけ高速に目的を達成したいわけです。台数が増えれば増えるほど どれか1台が故障する確率は増えるわけですから、故障に対する耐性は重要です。
私はいま分散システムの中でも分散key-valueストレージ（keyとvalueで表される単純なデータを分散して保存する、確実に、とてもとても速く）の開発に取り組んでいます。その設計上の特性として、一つ一つのデータは小さくて数が膨大になるケースに適しています。
key-value型の分散ストレージという対象を1つとっても、
- 対象とするデータのサイズはどれくらいか
（小さいならホップ数を減らして遅延を小さくした方がいい、大きければネットワークのスループットを最大限にする方がいい） - 数千台〜の規模にどうやって対応するか
（全員が全員のことを常に知っている状態を保つのは難しいので、伝言方式にするなど） - どこまで一貫性を保証するか
（参考：結果整合性） - リーダーが全体を管理するか、リーダー無しでも大丈夫なようにするか
（リーダーを使うならリーダーに負荷が集中しないようにする、リーダーが故障しても全体が止まらないようにする）
などの方針の違いによって、十人十色の設計が考えられます。
同じストレージでも、単純なkey-value型ではなくColumn-orientedな構造を持ったデータベースや、あるいは分散ブロックデバイスを目指すなどなど。
分散プログラムそのものだけではなく、分散プログラムの運用を支援するためのシステム（ネットワークブートシステムや負荷監視システム、ジョブ管理システムなど）も、今後重要度を増してくるかも知れません。
新しい潮流だけに、まだまだ手を付けられる余地がたくさんあります。分散システムの分野に進出してみるのも一興ではないでしょうか。
*1:今月のUNIX magazineはオススメです^^
