前回は、規模の増大とシステムの拡張といったスケーラビリティの確保についてまとめた。ここでは、高稼働率を実現するしくみである冗長性の確保とシステムの安定化について解説する。
１ 冗長性の確保
まず前提として、ほぼ100%の稼働率を目指すのに重視する項目は、SPOF（Single Point of Failure、単一故障点の除去）である。
APサーバ
APサーバにおける冗長性の確保は、台数を並べることとロードバランサによるフェイルオーバ/フェイルバックによって行う。1-2台が停止しても十分処理できるようにしておくことや、壊れたサーバを自動的に外し復帰したら戻すという処理である。
DBサーバ
DBサーバにおける冗長性の確保は、台数を並べることとマルチタスクによってマスタの冗長化を行う。APサーバと同様に1-2台が停止しても十分処理できるようにしておくことや、相互にレプリケーションすることである。
レプリケーションはお互いがお互いのスレーブであるという状態にしていて、片方に書き込みをするともう片方に伝播するし、反対側に書き込んでもその反対側に伝播するという、両方向にレプリケーションするという方法である。切替のタイミングによっては同期がずれるリスクは残るが、現状では割り切り、手動で回復する手法をとっている。
ストレージサーバ
はてなでは、画像ファイルなどのメディアファイルを保存するための分散ストレージサーバとしてMogileFSを使っている。分散ファイルシステムを使用することで、大量のファイルを保存することができるスケーラビリティと、一部のサーバが落ちても障害とならない冗長性が確保できる。Perlで実装され、トラッカー、ストレージノード、メタ情報を格納するトラッカーDBという3つの要素から構成されている。
２ システムの安定化
システムを安定化させるためのトレードオフ
システムを安定化させるための主なトレードオフには、安定性と資源効率、安定性と速度の2つがある。例えばギリギリまでメモリをチューニングしているときに、メモリ消費が増えることで性能が低下し、障害が発生する。同様にギリギリまでCPUを使っているときにサーバが1台落ちることでキャパオーバーとなり、障害が発生する。
システムの不安定要因
典型的なシステムの不安定要因は以下の8つである。1-6までがアプリケーション/サービスレベルの負荷増大によるもので、7-8がハードウェアの能力低下が要因である。
- 機能追加
- メモリリーク
- 地雷：特定のURLが読まれた結果、応答が返ってこない現象
- ユーザのアクセスパターン：Squidのキャッシュサーバを用いるなど
- データ量の増加
- 外部連携の追加
- メモリ・HDD（Hard Disk Drive）障害
- NIC（Network Interface Card）障害
３ システムの安定化対策
実際の安定化対策
実際の安定化対策は、適切なバッファの維持と不安定要因の除去の2つである。前者は限界の7割運用を行い、システムのキャパシティの70%を上限としてそれを超えたらサーバを追加したりメモリを増やすなどを行う。後者はSQL負荷の上限規定、メモリリークを減らす、そして異常動作時の自律制御が挙げられる。異常動作時の自律制御は以下の3つを行っている。
- 自動DoS判定（mod_dosdetector）：F5アタックなどを自動的に遮断
- 自動再起動（APサーバ・ホストOS）：2-3日に1回
- 自動クエリ除去（所要時間の長いSQLをKILL）
最後に
冗長性の確保にはAPサーバ、DBサーバ、ストレージサーバのそれぞれについて対策する必要がある。システムの安定化にはトレードオフがあるが、不安定要因には典型的なものが多い。実際の安定化対策は、適切なバッファの維持と不安定要因の除去をすることが求められる。
次回は、リソース使用率を上げる仮想化技術と自作サーバといった効率向上作戦について解説する。
 |
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB DB PRESS plusシリーズ) |
