"サーバ/インフラを支える技術"を読み終えた

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

凄い勢いで読み終えた。内容を一言で表現すると「不当廉売やろ、これ」
サーバやネットワーク運用というのはともすれば根性論で語られがちだけど、よくよく練られた運用というのは先手先手を打つことでいかに根性を必要としないで上手く回すかという戦略論になってくる。この本ではそれに必要な各種戦術が豊富で、普通の入門書クラスだと一冊使うような記事が何本も載っている。
運用レベルの技術がこれほど系統立てて学べる本というのは恐らく日本で初めて。だからもちろんこの分野では最高の一冊

HTTPを使ったストレージ

書き込みをNFSにして、読み出しをHTTPのGETを使う方法が紹介されているけど、いっそ書き込みもHTTPのPOSTにしてDAVみたいな使い方はどうなのだろう。
追記したいとか、この行を書き換えたいとか細かい要望に応えるにはフルスペックのファイルシステムを作る必要があるけど、大半はGET/POSTで事足りるんじゃないかな、とか。

DNSサーバの冗長化

凄いパラノイアだと思った。
多分、以前にDNSのレゾルバ周りでトラブった経験があってのことだと思うけど、この執念というかこだわりは正直見習いたい。一度トラブルを経験しても、そのときなんとか対応してそれで終わりにしてしまうような執念の薄い人間は運用には向かないと思う。

L2の冗長化

RSTPとかを使ってL2SWをループ状に構成して、冗長化をとろうという話。KLabの勉強会でも出ていた話だけど、個人的にL2SWに難しいことをやらせること自体に否定的。
3のつく日でも無いのに突然アホになって全てのVLANを忘れてくれるL2SWとか、素直に縮退するはずのtrunkが一本切れた瞬間に箱ごと刺さるとか、per packetで散らす仕様が使い続けると微妙に片方に寄ってくるSWなどなど。特殊な経験といえばそれまでなのだけど、L2SWの追求し難い変な挙動に悩まされたことのある私はL3で冗長化をとる方が安定するという「信仰」がある。L2SWは欠損なくワイヤレートでパケットを流してくれれば、それ以上は期待しないことにしている。
tagged VLANを使って物理構成を単純化するという話も、理屈としては分るのだけどここまで思い切った構成には踏み切れない。

Linuxのコードリーディング

もちろん運用では現象によっては、kernelぐらい追いかける必要がある。
負荷という軸で実際のコードレベルの記述までブレイクダウンして深追いするのは非常に実践的で楽しい。CPUステータスにXenなどの仮想化絡みの数字が出てくるのは、現代的だなと思った。
私はGNU Globalとgrepとlvと紙のメモという原始的なツールで読んでいくのだけど、最近だともう少し便利なツールがあったりするのだろうか。

Apacheのチューニング話

workerとpreforkはコンテキストスイッチがTLBの関係から「性能に与える影響は顕著です」とあったのが、ちょっと気になった。apache2.0が出始めたときぐらいに、preforkとworkerの性能をマイクロベンチマークで測ってみたのだけど、そのときはworkerの方がやや遅いぐらいだった。
それがOS側の実装の問題だったのか、Apache側の問題だったのかはわからないけど、最近だと実装が改善されたのかな。単純なファイルを配るだけのロードではなく、mod_perlなどで複雑な処理をさせれば差がつくのだろうか。
あと、私が単純に使ったことがないだけなのだが、lighttpd+FastCGIで使ったときのFastCGI側はどのような多重化を行っているのだろう。マルチプロセスモデルなら結局メモリ使用効率が問題にならないのだろうか。APサーバとして使っていると、CPUが先に無くなるから問題ないとか？

MySQLのチューニング話

よくあるtips系の話のうちパラメータチューニングは、複数ある要素のうちの一つに過ぎませんよというのに全く同意。金科玉条のごとくパラメータの値の決め方を信じてしまう人が居るけど、あんなのは性能向上の最後の方でやる一手でしかなくて、王道はSQLの見直しだと思う。パラメータで向上するのは良くても数十%程度だけど、SQLを直せば100倍以上改善することも珍しくない。
メモリ関連のパラメータの上限チェックについてはKLabの人のスクリプトを重宝をしていたのだけど、あれを守っていても徐々にプロセスが太って死ぬという症状に悩まされていたな。いまどき32bitの上限に引っかかる方が悪いとは思うのだけど、どこかでリークしているのではないかという疑いを持っている。Apacheのように定期的にプロセスが死んで入れ替わってくれればいいのに。

リソースモニタリング

Gangliaが紹介されているけど、エージェント方式は構築前に導入計画を立てておかないと後付けでは難しいかな。snmpもエージェントと言えばそうなのだが、普通は導入済みだし。
あと、グラフの拡張をするためにphpを直接いじらなればならないのはやはり敷居が高い。cactiはその辺が凝っていて、ほとんどのグラフが設定が出来るので使っていた。次のバージョンにはCLIからの設定ツールも入るし、コードが複雑なのと設定が多岐にわたるけどわりとお勧め。

Puppet

サーバを一杯動かしたことがある人なら一度は同じような事を考えると思うが、そこまで踏み切れない人がほとんどだと思う自動化ツール。
やはりroot権限であらゆる設定ファイルをリモートから変更するためのソフトが動いているのは気持ち悪い。passwdエントリなどを触られた日には、思わず全ホストに入って変更点を確認しそう。
実際には使いどころ次第だし、有用なツールだとは思うので小さいところからでも入れていくべきなのだろう。

ネットワークブート

これも使うことを前提に設計をしておかないと、後付けでは導入できない技術だな。
実トラフィックが流れている中で、DHCPやtftpみたいな認証がないトラフィックが流れるというのがちょっとキモいというのもある。現場に行かなくともOSも含めた構成変更をできるというのは便利なんだけどな。

はてなの中身

剥き出しのサーバってまだ使っているのかな。あれって排熱効率が悪そうなので、案外高密度で実装していくには難しい気がする。空冷効率を考えて金属板を加工とかし出すとまた違うのかもしれないが、それだと市販の1Uサーバと大差なるなると思う。
MySQLのマルチマスタは実践的に使っているのは珍しい。auto incrementの制約を回避するためのあの特殊な設定は入れてしまうとそのカラムでorder byしたときに、追記順にならなくなるのは痛いな。auto incrementはよく主キーにするし、日付でソートするよる遥かに速いので便利に使うことが多いので。
あと、OCFS2を実用で使っているのか!凄い!標準のkernelに統合されてから随分経つので全く実用にならないはずはないだろうが、サービスで使っているのは初めて聞いた。Lustreとかにも挑戦して欲しい。
Perlをヘビーに使っているはてならなではだけどCPANをパッケージにして、puppet経由で一括デプロイしているのは流石。PHPが普及初期にPerlに対して有利だったのは、とりあえず使えるライブラリ群が一緒になって配布されていた事だと思っている。私にとってはCPANを本番機で展開する上手い方法が永らくの課題だった。下手をすれば一台ずつ入って"cpan install hoge"なんて打つこともあったぐらい。

DSASの中身

DSASの具体的な中身については、今までの勉強会などで見聞きしていたので省略。
よくよく思うのはKLabの特異性。
運用の現場はいくつか見たことがあるけど、どこでも前線に立つ担当者レベルでは現状に不満を持ち改善案について一家言ある。だけど導入前に考慮しておかなければならない大掛りな仕組みとか体制とか予算など諸々に阻まれて、日々のオペレーションに磨り減ってしまいがち。DSASの個々の要素技術自体はどれも突飛なものではなく、いい意味で教科書的な構成。ではどの現場でもこれが作れるかと言ったら、なかなかそうは行かない。
大掛りな構成変更を決断出来る立場の管理職も決して技術を知らないわけではないはずだが、現場で不満を抱いていたときの改革への情熱は冷め、保守的になり、現場の根性運用に頼ってしまう。(私だけかもしれないが)現場は現場で根性運用がそれなりに楽しかったりするので、ついつい手を動かすことで満足してしまう。
この本は間違いなく日本の運用の現場のレベルを底上げするだろうが、全てがDSASクラスの高可用で柔軟性の高いシステムになるかと言われれば、否だろう。続編があるならば、技術者を指揮してシステムを作り上げた管理職の方の、エンジニアの焚き付け方とか部分最適からの抜け出し方とかそちらの話が読みたい。