一度スタートしたWebサイト。サービスを止めたくないというのは、Webシステムの開発者、担当者に共通するのはないでしょうか。しかし、実際にはハードウェアのトラブル、アクセス増加への対応など、さまざまな困難が襲ってきます。
そのようなトラブル、サイト状況への対応として、大まかに以下の二つの選択肢があります（図1）。
図1
- スケールアップ（Scale-up）
- スケールアウト（Scale-out）
前者のスケールアップは、1台のサーバ能力を高める方策で、一般的に機器が高価になります。後者のスケールアウトは、サーバの台数を増やして、複数台構成で処理能力を高めたり障害対応を行ったりする方策で、とくに一般的な中小規模のWebサイトではスケールアウトで対応することが多いようです。そこで、本記事では以下スケールアウトを念頭に、基本的な考え方を紹介します（※）。
スケールアウトの第1歩、つまり1台のサーバを、2台、4台、10台……と増やし、サーバやネットワークなどのインフラを整備する……、ここで基本になるのが「冗長化」（Redundancy）という概念です。冗長化とは、障害が発生しても予備の機材でシステムの機能を継続できるようにすることを指します。
Webサービスにおけるシステムの冗長化対策では、以下のステップを踏みます。
- ① 障害を想定する
- ② 障害に備えて予備の機材を準備する
- ③ 障害が発生した際に予備の機材に切り替えられる運用体制を整備する
図2のようなシンプルなシステム構成で、①～③について見てみましょう。
図2
まず①の障害の想定ですが、起こりうるシステムの障害として以下が挙げられます。
- サーバが故障してサービスが停止する
- ルータが故障してサービスが停止する
「サーバ」「ルータ」のどちらが故障してもサービスが停止します。
①を踏まえて、②の予備の機材を用意したのが図3です。まだ予備の機材であるサーバとルータはネットワークに接続していません。
図3
そして、図3の予備機をどう活用するかが③の運用体制の整備ですが、障害が発生した際に予備の機材に切り替える際、ルータとサーバとで対応が異なります。
ルータの場合、運用中に設定変更が頻発するものではないでしょうし、ルータに蓄積しなくてはならないデータもほとんどありません。そこで、予備のルータも現用のルータと同じ設定にしてスタンバイし、現用機が故障したら予備機につなぎ替えるという運用体制で問題ないでしょう。この運用体制を「コールドスタンバイ」（Cold Standby）と呼びます。
サーバの場合、設定変更が頻発しデータの蓄積もあるため、コールドスタンバイで予備機を準備しても、現用機が故障した際の設定やデータの状態と、予備機の状態が大きく食い違う状態になってしまいます。そこで、予備機もネットワークにつなぎ、現用機と同じ更新がかかるようにしておき、故障した際は現用機に切り替えます。この運用体制を「ホットスタンバイ」（Hot Standby）と呼びます。
以上が、図1のようなシンプルな構成における最低限の冗長化対策です。これから先のステップとしては、
- 現用機に障害が発生した場合、自動で予備機に切り替え処理を引き継ぎたい
- 現用機と予備機に分けるのではなく現用機を倍に数にして倍のリクエストを処理したい
……など、どんどんとシステムを成長させていく方向へと進んでいきます。これらの冗長化にかかわる対策は、サービスの性質や運用体制などより、千差万別で、さらに一つ一つの対策が互いに複雑に絡むため、実現への道のりは平坦とはいえません。しかしながら、これらの対策がとれた後、対策前と比べると、耐障害性、リクエストの処理能力、運用の手間などにおいてその効果は計りしれないでしょう。止められないサービスを支えるサーバ/インフラ、いま一度、見直してみませんか。
