nabeの雑記帳

はてなのnaoyaさんのところで見かけて購入したこの本。あれだけ巨大なシステムがどうやって動いているのか、興味深いところが解説されていてとても面白かった。

よくあるサーバの考え方

よくC10K問題といってクライアントが1万人を越えた途端、どんなシステムでも耐えられなくなると言われています。この先をどうやって維持していくか。はててやmixiなどでは、

• DNSによるサーバグループの切り離し（障害発生時）
• リバースプロクシによる負荷分散
• データベースレプリケーションによる負荷分散、障害対策

普通サーバと言えば、とりあえずRAIDをして、電源ユニットを冗長化して、とにかく基幹システムが壊れないように構成します。基幹システムが落ちなければ、サブシステムは基幹システムによって障害対応しようというものです。

Googleの考え方

システムは、普通のPC（それもハイパフォーマンスPCではなく、コストパフォーマンスのいいPC）を使います。メモリもそこそこ、HDDはIDEディスクです。ネットワークは100Mbpsや1000Mbpsの普通のLAN。

その代わり、マシン台数を増やすことで徹底した負荷分散を行います。

しかしこれ、言うのは簡単ですが実際どうするのか。Googleのもっとも優れたところは、このような負荷分散システムを作り上げたところにあります。

ファイルシステムやデータベースシステムなどは「実に単純な機能」を効率的に実装します。例えば、GFS（Google File System）にはファイルの読み込みと書き込みの機能はあってもオフセットを指定して書き換えたりできないそうです。必要なら読み出して再度書き込むべしという具合です。

書き込みは多くのPCに分散・冗長化して行われ、障害発生時の切り離し対策を何重にも行って対応します。逆に言えば障害対策はすべて「障害発生PCの切り離し」によって復旧するということを徹底して行っています。

そして基幹システムの Chubby は、どれかが特別に優先するわけではなく、複数マシンによる合議制によって作られていて、半数以上のマシンが停止しない限りシステムが稼働し続けるように作られています。

まるで本を読んだかのように自慢できる、要点

• PCの中身は冗長化しない
• PCの数を用意するだけで冗長化・障害対策できるシステムを構築する
  • コピーを複数作り障害が起きたら自動的に切り離す
  • 早急に別の新マシンを起動させデータを自動的にコピーする
• PCの数を用意するだけで性能が向上するようにシステムを構築する
  • 大きなデータは複数のブロックに分割し、手分けして処理をする
  • このような手分け処理をシステム化（ライブラリ化）する

1Mspsで16bitといった製品が出てるらしい。

その辺に転がっているみかけ16bitではなく、SN比もきちんと91dBとか93dBとか。

1Msps/16bitで計測……例えばオーディオ録音とかしたら、どうなるんだろう？　なんか未知の世界が開けそうですよね。信号処理とかでも面白いような気がする。