今回は、大規模サービス技術入門というはてなの中の人(もう元だけど)が書いた本のメモをちょこっと書いていく。本自体は、いろいろ実践的なことも書いてあるので、サーバなどをちょこちょこいじりながら読むのがたぶん正しいやり方だ。
大切なこと
- 推測するな、計測せよ 対処はそれからだ
- 如何にI/Oをなくし、メモリアクセスを増やすかを考える
- ファイル圧縮を活用する
- メモリに展開する時間 < ディスクのアクセス時間 CPU処理の方が圧倒的に早い
- キャッシュの分散化は、テーブル単位かデータ範囲の単位(垂直か水平か)
- 大規模化するほど、テーブル間の結合度は意識しておく必要がある
- joinは控える形になる
- DB分散時 マスタ-スレーブ構成では4台が推奨構成
- 一台故障すると、一台はコピー用に取られる
- システム安定化のためにはピークの7割を保つ
- チューニングはしすぎない
- 外部システムの不安定化に引きづられないように、フェイルセーフ的は実装も必要
- 稼働率向上ではSPOF(Single Point of Failure)単一故障点の除去を考える
- 一箇所の故障がシステムダウンにつながる部分の除去
- リソースの消費傾向に応じてサーバを分配
- 似てるもの同士、負荷が高い物同士は同居避ける
ポイント
- 計算量の話
- O(n)の意味:n件に対してn件の処理
- O(logn)の意味:n件に対してlogn件の処理
- O(n^2) >>>> O(nlogn)
- O(n^2)は単純な二重ループ
- nを如何にlognにするかがポイント
- オーダ量が同じでも定数項(入力データサイズには影響しない計算量)で差が出る → CPUキャッシュ等の利用率も影響
- 圧縮の基本
- 記号の確率分布を見る
- 頻度が多いものには短い記号で符号化
- 頻度が少ないものには長い記号で符号化
- キャッシュの話
- ディスクアクセスをなるべく無くすにはキャッシュを使う
- Linuxはメモリが空いていれば、読み込んだファイルのブロックはどんどんキャッシュする
- DBは長期間動かしていた方がキャッシュが最適化され、処理が早くなる
- 再起動時は要注意 キャッシュがないので遅くなることもある
- データは圧縮した方がキャッシュに載せれる→キャッシュの内容がディスクの内容なので、展開した情報自体は展開したアプリケーションが使用する
- キャッシュ規模が大きくなってきた場合、アクセスパターンを考慮して分散化する→まずはアクセスパターンを分析する
- 分割のパターンは、テーブル単位かデータ範囲の単位
- 負荷分散のノウハウはOSの動作原理を知ることが第一歩
参考文献
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)
- 作者: 伊藤直也,田中慎司
- 出版社/メーカー: 技術評論社
- 発売日: 2010/07/07
- メディア: 単行本(ソフトカバー)
- 購入: 75人 クリック: 1,809回
- この商品を含むブログ (121件) を見る