分散コンピューティングの8つの嘘
90年代前半、GhostScriptの作者として有名で、当時SunのフェローでもあったPeter Deutschは、「Eight Fallacies of Distributed Computing」という社内向けメモを書いた*1。どれも言われてみれば当たり前だし、頭ではわかっているんだけど、いざ開発が始まると、無意識にそのような前提でプログラミングしてしまい落とし穴にはまってしまうというものだ。
- The network is reliable／ネットワークは信頼性がある*2
- Latency is zero／遅延はゼロである*3
- Bandwidth is infinite／帯域は無限である
- The network is secure／ネットワークは安全である
- Topology doesn't change／トポロジーは変更されない
- There is one administrator／管理者は一人である
- Transport cost is zero／送信コストはゼロである
- The network is homogeneous／ネットワークは均質である
この教訓に対する詳しい解説には、「Fallacies of Distributed Computing Explained」があるので、興味がある人はあわせてどうぞ。
実際ネットワークプログラミングするときは、Plan9ユーザのような例外を除いては、直接なり間接なりに（バークレー）ソケットAPIを使っている*4。ソケットAPIはUNIXファイルI/Oモデルの考え方をベースに、クライアント・サーバ型のプログラムを簡単に書けるようにと設計された。その登場は1982年にリリースされた4.1c BSDからなので、もう四半世紀以上経ったことになる。その間にインタネットは爆発的に普及し、ネットワークを取り巻く環境は様変わりしたのにも関わらず、ソケットAPIの変更する必要に迫られたのは、IPv6対応ぐらいだった。
ソケットAPIにも問題がないわけではなく、今月のACMQに掲載されていた記事「Whither Sockets?」では、ソケットの問題点として、性能オーバヘッド（ゼロコピーデータ転送できない）、カーネルアップコールAPIの欠如、マルチホーミングの困難さが挙げられている。マルチホーミングに関して補足すると、要は別々のネットワーク（例えば、LANとWANとか）につながった複数のNICに対応するということだ。1982年頃はIMPと呼ばれていたルータ（の原形）以外は複数インタフェースを持つということはなかったので考える必要はなかった。最近登場したSCTPはマルチホーミングに対応したトランスポートプロトコルだが、ソケットAPIへのマッピングは何か残念な出来で、one-to-oneはTCPと同じようにread/writeできるが、one-to-manyはUDPのようにsendmsg/recvmsgで書くことになる。とにかく、どの問題に対しても何らかの改善案が提案されているが、なかなか標準にはならない。よくでき過ぎているがために、変更が難しいとは、ソフトウェアの世界ではよくある話だ。
（追記：2013-01-09）結局、SCTPって流行ってないね。Multi-Path TCPって話もよく聞くようになってきたけど、こちらはどうなることか。
*1:最初の4つBill JoyかDick Lyonが考えたもの。最初に発表されたときは7つだったが、1997年にJames Goslingが8つ目を追加した。
*2:インタネットの9割近くのトラフィックはTCPだろう。TCPは再送機構があるから信頼性があると思いがちだが、ディスクなど他のI/Oと比較するとMTBFは圧倒的に短い。
*3:ネットワークの帯域は年々広がっても、遅延（レイテンシ）は小さくならない。レイテンシはアプリケーションレベルのデータ転送にかかる時間なので、OS内部のプロトコルスタック処理時間と物理的な伝送遅延を含んだものになるが、基本的にはホップ数に比例して大きくなる。伝送遅延に関しては、パケットは光速より速く届くことはない。つまり、光速を300000km/sとすると、1kmあたりの遅延が3.3マイクロ秒になる。実測値はバッファリングや光ファイバの特性などの理由からこれより大きくなり、（数ホップしかない）ネットワークだと東京・大阪間（500kmぐらい）で4ミリ秒ぐらいになる。
*4:SysV系にはXTI/TLIってのもあったけど。
