読書メモ：(Web開発者のための)大規模サービス技術入門

2010年初版の本。昔の"はてな"の裏側が垣間見えるのも面白い。
サービスの規模に対して、とても少ない人数で運用、開発してたことに驚く。
あと、この本はインターンシップで教えていた内容がベースらしいけど、これだけの内容をインターンシップで教えているのは凄い。

もともとノウハウを凝縮したような本なので、内容が濃い。
検索システムなどあまり興味のない章もあったけれど、現在のはてなのインターンシップでも既に別の説明に置き換わっているらしい。

2001年に「人力検索はてな」開始。従業員3名、PC1台。

登録ユーザー数150万人
1500万UU(ユニークユーザー)/月
数十億アクセス/月(画像などへのアクセスは除く)
ピーク時の回線トラフィック量は850Mbps
サーバー台数600台。22ラック。仮想化台数は1300台

インフラ部は仮想ホストを管理。社員4名、アルバイト数名
サービス開発部はサービスごとに3〜4名。

エンジニアの共通言語。お互いが知ってれば、ハッシュの一言で済む。
アルゴリズムを学ぶわかりやすい利点は、新しい問題にも対処できるかもしれない点。

O(1) < O(log n) < O(n) < O(n log n) < O(n²) < O(n^k) < O(2ⁿ)
オーダー表記は定数項を無視する。

実際の速度はキャッシュの効きにもよるので計測しないとわからない。
何がネックになっているか計測して、最適化か、アルゴリズム変更か、HW変更か判断。
人間の直感よりも、さくっと実装して試してみるのも大事。最近のコンピュータは速いのでスペックで殴った方が早いことも。

小規模な段階での最適化はベストではない。
でも、なにも考えずに見切り発車も考えもの。
大規模化の壁は突如として目の前に現れます。たとえばデータ規模が増加することによるI/O負荷の上昇は、それほどなめらかに増加するわけではありません。

自分が扱っているサービスは規模はぜんぜん違うけど、ホントこれ。忘れないようにしたい。

プロキシ (Proxy) サーバ、ウェブキャッシュサーバなどに利用される。
キャッシュサーバーを使うことで大量のアクセスを捌く。

1回のクエリで1つのインデックスしか使わない
インデックスとして作用するのは、明示指定したインデックス、プライマリキー/UNIQUE制約を指定したカラム
インデックスが効いているかどうかはexplainコマンドで確認できる
keyは使用したインデックス。
Using filesortやUsing temporararyが出るのあまり筋のよくないクエリ
インデックスの付け忘れは目を増やすことでカバー
- slow.log
- SQL文が画面に表示されるようにライブラリに手を入れる
- O/Rマッパで都度explainして怪しいクエリは自動で報告
異なるサーバにあるテーブルをJOINする機能はない(MySQL5.1ではFEDERATEDテーブルを利用すれば可能)