前回は、大規模データ処理を支えるサーバ/インフラ入門についてまとめた。ここでは、規模の増大とシステムの拡張といったスケーラビリティの確保について解説する。
１ レイヤとスケーラビリティ
スケーラビリティへの要求
多くのサービスはサーバ1台で動く。はてなでは数億PV/月である。大規模サービスはサーバ1台では動かない。サーバの特徴は以下の通り。
- はてなの標準サーバ：4core CPU、8GB RAM。ピーク性能は数千リクエスト/分で、100万PV/月
- 高性能サーバ：4 core CPU×2、32GB RAM。200万PV/月
レイヤごとのスケーラビリティ
レイヤごとのスケーラビリティには主に以下の2つがある。
- APサーバ：構成が同一で状態を持たないため容易
- データソース（DB、ファイルサーバなど）：readの分散は比較的容易だが、writeの分散は難しい
２ 負荷の把握、チューニング
負荷の把握
負荷の把握にははてなが独自に作成しているサーバ管理ツールを使用している。はてなブックマークの管理画面には、サーバの役割（Role）とバックエンドサーバ（backend）が乗っている。
負荷を測るための項目
主な負荷を測る項目には以下の3つがある。
- ロードアベレージ：待ち時間にあるプロセス数の平均値。それらのプロセスがいつでも動ける状態なのにまだ実際CPUが割り当てられないために起こる
- メモリ関連：消費メモリ、共有メモリ、バッファメモリ
- CPU関連
用途ごとに合わせたチューニング
ユーザ用のサーバ、ボット用のサーバなど、用途に合わせたチューニングをすることで効率的にサーバを活用することができる。例えば、ユーザ用のサーバではレスポンスタイムを重視するために処理待ちプロセスを貯めないという工夫や、ボット用のサーバでは処理数を最大化させるためにリソースを使い切る工夫をしている。
APサーバ/DBサーバのチューニングポリシーとサーバ台数
仮にユーザ用のチューニングのままでボット用にして同じ程度の負荷で処理しようとすると、必要なサーバ台数が増えてしまう。このことはDBサーバでも当てはまる。
サービスの規模とチューニング
チューニングの目的は以下の2つである。その上でOSの動作原理を知り、サーバの性能を正しく引き出すことが重要である。
- 負荷の把握：負荷の可視化
- 状態の監視：ボトルネックや異常の把握
スケーラビリティの確保
スケーラビリティの確保でロードバランサを使ったり、パーティショニング（DB分割）をしたりしている。
最後に
スケーラビリティを確保するためには、レイヤごとのスケーラビリティや負荷の把握、そしてチューニングを行う必要がある。つまり、APサーバとデータソースを区別し、負荷の可視化と状態の監視を実施することが求められる。
次回は、高稼働率を実現するしくみである冗長性の確保とシステムの安定化について解説する。
 |
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB DB PRESS plusシリーズ) |
