Flickrのエンジニアリングマネージャが書いた、スケーラブルなシステム・ネットワーク設計についての本。
開発環境や監視体制なども含まれ、網羅的。
大規模サイトでなくとも参考にできることが多い。
■ボトルネックの特定
パフォーマンスが劣化した際は、場当たり的に対応するのではなく、ボトルネックになっている箇所を特定する。
1. CPUのボトルネック
CPUがボトルネックになることは殆どない。むしろディスクI/OやネットワークI/O、メモリI/Oの問題による、他のリソースの割当待ちで、プロセッサが空転し、これをプロセッサの問題としてとらえてしまうことが多い。
本当にCPUが足りないのならば、サーバを増設するか、強力なCPUを購入すればよい。
2. ディスクI/Oのボトルネック
iostatで劣化時は発見できるが、問題になる前に、可能なパフォーマンスを割り出しておくのが望ましい。
Bonnie, Bonnie++を使うと、ディスクのパフォーマンスをベンチマークできる。
ディスクI/Oの速度を制限するのは、主にディスクの回転数である。ディスクの回転数を上げる方が、ディスクやマシンを増設するよりも低コストである。ディスクの読み込み/書き込みキャッシュは、性能向上につながるが、電源バックアップの機能がないと、ハードウェアダウン時にデータが失われる可能性がある。
単純にディスクを追加するだけでも、高速化される。
3. ネットワークI/Oのボトルネック
netstatやslurmで特定する。
設定ミスなどで、イーサネットの性能を使い切れていない場合がある。
またブロードキャストドメインの中にあるホスト数が多いと、ブロードキャストストームという現象が起こる。この場合はルータでネットワークを適切に分割する必要がある。
その他に、データベースのレプリケーションでトラフィックが埋まることがあり、セグメントを分割した方が望ましい。
4. メモリI/Oのボトルネック
メモリからの読み込み速度、プロセッサキャッシュへの書き込み速度、メモリとキャッシュ間のバンド幅の3要因から発生。これを改善するのは容易ではないが、マシンの数を増やせば直線的にメモリのバンド幅を増大させることができる。
5. スワップ
ps -axlでVSZからRSSを引くことで、それぞれのプロセスのスワップ使用量がわかる。
MySQLやSquiidなどディスクからメモリに大量のデータをキャッシュしているようなアプリケーションは、スワッピングするとパフォーマンスがひどく低下する。
スワッピングを減らすにはメモリを増やすか、アプリケーションのメモリ割当を減らす方法がある。
後者だけでも問題を解決できることがある。
6. 外部サービス
そのサービスのせいにしたくなるが、通信方法がボトルネックになっていることがある。
リクエストの発信とレスポンスの受信が高速に行われているかをまず確認する。
実際に外部サービスの問題だとすると、打つ手があまりなくなってしまう。
7. データベース
標準的なLAMPシステムで最大のボトルネックになるのは、データベースの処理量で、通常原因はディスクI/Oである。ただネットワークI/O が問題になっていることもあり、始めに調べて切り分けておく。
負荷の高いクエリを特定することが必要だが、MySQLではクエリーにコメントを埋め込めるので、processlistだけではわからないときは有用。
クエリのチューニング以外に、データをキャッシュしたり、データを非正規化して複数テーブルに保持する方法もある。
■スケーリング
スケーラブルなシステムとは以下の3つを備えたもの
- 使用量が増えても対応できる
- データセットが増えても対応できる
- メンテナンスが可能
よく誤解されるが、スケーラブルとは関係ないもの
- スピードや性能
- Javaなどのコンパイル言語
- XML
ハードウェア的な視点から、拡張容易に設計し、将来的なソフトウェア変更の可能性を減らすのが望ましい。はじめはハードウェアがコスト高に見えるが、次第にソフトウェアのコストが上回るようになるから。
垂直方向のスケーリングと水平方向のスケーリングがある。
・垂直方向
より強力なマシンに交換する。
よい：設計が容易
悪い：マシンスペックは青天井ではない。強力なマシンが存在しないか、非常に高価になる。
・水平方向
ハードウェアを次々に買い足していく
よい：追加コストが低い。
悪い：マシンの所有コストがかかる。管理費、電力、スペース、ラック代など。
スペックを活用しきれないマシンが出てくる。
結論
コストと便益を比較しながら、垂直/水平のスケーリングを組み合わせた設計にすることが望ましい。
(2 reviews)
(6 reviews)
これ一冊で十二分
