はてなのnaoyaさんのところで見かけて購入したこの本。あれだけ巨大なシステムがどうやって動いているのか、興味深いところが解説されていてとても面白かった。
よくC10K問題といってクライアントが1万人を越えた途端、どんなシステムでも耐えられなくなると言われています。この先をどうやって維持していくか。はててやmixiなどでは、
普通サーバと言えば、とりあえずRAIDをして、電源ユニットを冗長化して、とにかく基幹システムが壊れないように構成します。基幹システムが落ちなければ、サブシステムは基幹システムによって障害対応しようというものです。
システムは、普通のPC（それもハイパフォーマンスPCではなく、コストパフォーマンスのいいPC）を使います。メモリもそこそこ、HDDはIDEディスクです。ネットワークは100Mbpsや1000Mbpsの普通のLAN。
その代わり、マシン台数を増やすことで徹底した負荷分散を行います。
しかしこれ、言うのは簡単ですが実際どうするのか。Googleのもっとも優れたところは、このような負荷分散システムを作り上げたところにあります。
ファイルシステムやデータベースシステムなどは「実に単純な機能」を効率的に実装します。例えば、GFS（Google File System）にはファイルの読み込みと書き込みの機能はあってもオフセットを指定して書き換えたりできないそうです。必要なら読み出して再度書き込むべしという具合です。
書き込みは多くのPCに分散・冗長化して行われ、障害発生時の切り離し対策を何重にも行って対応します。逆に言えば障害対策はすべて「障害発生PCの切り離し」によって復旧するということを徹底して行っています。
そして基幹システムの Chubby は、どれかが特別に優先するわけではなく、複数マシンによる合議制によって作られていて、半数以上のマシンが停止しない限りシステムが稼働し続けるように作られています。
どっかのO社と違って実装がとっても素直そうな2ch専用サウンドカードです。PRODIGY HD2 ADVANCEとかも出てますが、ノーマルの方が遊びがいがありそうです。載せ替えの手間考えたらPRODIGY HD2 ADVANCEでもいいのかも。
オペアンプ交換して、抵抗を置き換えてみたいココロ。誰か突進しません？
192VEのチップ出力抵抗、DAC/ADCまわりのアナログ電源コンデンサ交換と回路変更（ノイズ対策）をしました。SE-U55SX（改）と同等の音質。もしかしたら越えたかも？ という感じになりました。ついでにADCまわりも強化して録音品質向上に挑戦。
結果、またも原形留めてない説（笑）
「SE-U55SX（改）があるのになぜ？」という疑問もあると思いますが、結局のところProdiy（AudioTrak）はソフト（ドライバ）がとても使いやすいという一点に尽きます。裏を返せば…ry
PCM2901 DACの録音部分の回路を作ろうと思ったのですが、録音ボリュームを付けようかどうか迷っています。下手なボリュームつけると劣化するし、かといってWindows側からの録音制御もまったく効かない状況ですので、困ってしまいました。
ボリュームは諦めるかな……。
このサイトで一番人気なコレですが、次期バージョンのため色々調査していると面白いことが分かってきました。
(1)は今更すぎてみなさまに申しわけない感じですが、どうやらその傾向があります。
(2)については、出力抵抗による劣化などあらゆる要因を疑って聞き比べてますが、どうやら出力インピーダンスがまだ高いという結論に達しそうです。比較的インピーダンスの低い、40Ωヘッドホンに対して４～５Ωなら十分だと思ったのですが、細かい変化がまだあります。
現時点で調査中であり、確定的なことはまだわかりませんが、あの回路を作られた方の中で「試してもいいよー」という方がいましたら、(1)または(2)について個別に追試して感想を教えて頂けると嬉しく思います。（(2)については発振の危険があります。特に、出力抵抗削除は高確率で発振します。）
とにかく出力インピーダンスを下げるのは発振との戦い（もしくは出力抵抗16個という嬉しくない状況との戦い）。またブレッドボードでの調査かな…。*3
完全パラレル（全FETで出力抵抗共有）での試験＠ブレッドボード
発振させるには：電源にＬ成分、パラ数を増やす、電圧を上げる、出力抵抗を低くする。
安全性を鑑みて「4パラ/0.33Ω(0.47Ω)×2」。
2008/04/21 注意！！ ここに書かれている情報は古くなっています。LM6172はあまり音がよくありませんし、OPA627より安価で良い音質のオペアンプがたくさんあります。
Chu-Moyヘッドホンアンプを使ってオペアンプの音質を比較しました。
関連記事
某所に設置してある『固定IPを持ったメールサーバ』からメールを送信した際、ブラックリストに入っていると跳ねられてしまいました。
というサイトでIPアドレスを入力すると、ブラックリスト入りを調べることができます。この中で、引っかかってしまったのが真ん中のPBLです。どうも原因は
Ref: PBL2102xx
222.210.xx.0/20 is listed on the Policy Block List (PBL)
と出てきました。PBLというデータベースに入っているようです。
他人のIPですが、このようにナンバリングされて管理された、ダイナミックIP（と想像される）リストです。このリストをどうやって作っているのかつらつらと説明がありますが、逆引き名から推測しているようです。要するに、メールサーバを中継せずにクライアントIPから直接送信してくるサーバを排除する仕組みです。
そもそも、この仕組みはブラックリストではないそうですが、……まああからさまにブラックリスト向けですよね。でも、こんなのブラックリストとして使うな。 ＞某有名サーバメーカー
解除するため説明を読んでみると、このデータベース（ブラックリスト）からの削除は自動処理であり、２つの条件を満たすよう書かれています。
You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server, and (B) if you have a specific technical reason for needing to run a 'direct-to-MX' email service, such as a mail server appliance, off the Static IP address. In all other cases you should NOT remove an IP address from the PBL.
イマイチ分からないところもありますが、逆引きが設定された静的IPならば消してくれるようです。フォームから申請したところ無事解除されました。
