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

スポンサーリンク

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

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

はてなについて

スタート

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

2010年当時の規模

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

当時の体制

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

技術選定基準

  • 言語
    ポリシーは同じレイヤーの言語は基本は1つに絞る。
    ただし、速度が求められる場合にはC/C++なども使う。

  • ミドルウェア
    DBもMySQLに統一

  • 基準
    新しいものはダメという基準はないが、枯れたものが使いやすい。
    クラウドは細かい挙動がわからないことがある。

アルゴリズム

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

アルゴリズムのオーダー表記

O(1) < O(log n) < O(n) < O(n log n) < O(n2) < O(nk) < O(2n)
オーダー表記は定数項を無視する。

処理の改善

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

その他

  • オープンソースライブラリを使ったり、必要な箇所だけ抜粋すると工数が減ることも。
  • 圧縮は地味だけど重要。例:HTTPのdeflate圧縮通信
  • プロトタイピングでうまくいっても、実運用で使うためには他の作業も結構ある。
  • GoogleIMEはLOUDSというデータ構造で巨大な辞書を50MBに圧縮。

サーバ・インフラ入門

エンタープライズWebサービスという軸での比較

安定化対策

  • システムを安定させるために余裕を持たせる。限界の7割で運用。CPUもメモリも7割が目安。
  • HDDだけでなく、メモリ、ネットワークの障害も日常的に発生する
  • 外部連携サーバーが落ちても動くようにする
  • メモリリークを日頃から除去
  • 発行するSQLを把握
  • 異常動作時の自立制御
    自動DoS判定
    リソース不足時の自動再起動
    処理時間の長いSQLをKILL(10秒に1回取得して判定)

システムの成長戦略(p.17)

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

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

コマンド、ツール

hdparm メモリとディスクの転送速度が見れる

sar OSの状況確認

  • 過去の統計データに遡ってアクセスする
  • 現在のデータを周期的に確認

Squid(スクウィッド)

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

MySQL

インデックス

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

DBへの更新/書込をスケール

  • 更新系クエリが増えると厳しい
  • テーブルを分割してテーブルサイズを小さくする
  • そもそもRDBMSを使わない

RDBMSの限界を超えたら

  • バッチ処理でデータを抽出
  • そのデータを提供するサーバーを作りWeb APIでクエリ
  • 用途を特化してるので早い

理論と実践

  • 開発スピードを求めるには実践力が必要。
  • 規模が大きくなると、小手先の実践は通用しなくなる。
  • 多くの問題はわりと教科書に載っているような古典的な理論で解けたりする。
  • Web開発には理論と実践の両方が必要
  • 計算機の問題として道筋を立てるには、ある程度知識の引き出しが必要。