WEBサーバの障害についてとその対策

そのため中規模以上の企業でWEBサーバ障害発生時の運用を考えておくのであれば、
出せる費用との兼ね合いですがバックアップとしてレンタルサーバを2社契約するとか、
自社でバックアップサーバを構築するとかをしておいた方が良いと思います。
最低でもFTPアップロード前のデータをPCに置いておく（置いていることを確認する）
とかrobocopyやバッチなどでWEBからPCへの毎日バックアップは必要かと思います。

また、バックアップデータは別サイト（拠点）に保管するのが望ましいと
されています。よって、レンタルサーバを複数契約し冗長するのであれば
データセンターの場所も分けられた方がより良いですね。
エックスサーバや多くのレンタルサーバ会社はさくらインターネットの
データセンターに間借りしていたり、または再販でのサーバで有るため
別サイトにバックアップしたと思ってもデータセンターの場所は
さくらインターネットや他のレンタルサーバで契約しているサーバと
同一の場所だった、となる場合があります。

WEBサーバの障害対策について

企業でのWEBサーバの障害対策について、私であれば以下を
行うかもしれません。机上で考えただけで検証はしていません・・。
どうしてもレンタルサーバ会社の想定していない障害について考える
場合は、レンタルサーバ会社の想定していない対策になってしまいますね。
レンタルサーバ会社の想定していない障害については対策しないので
あれば、それはそれでも良いのかもしれませんね・・。

障害対策その1　CNAMEレコード使用

・DNSサーバとバックアップ用WEBサーバはレンタルサーバ会社Aを使用する。

レンタルサーバ会社Aと契約しWEBサーバ「a.com」を構築するものの
DNSサーバのCNAMEレコードでa.comは常にb.comへ転送する。
そして、レジストラに伝えるDNSサーバはこちらのDNSサーバ。

※DNSレコードを編集できるレンタルサーバとしては、
エックスサーバやお名前.comなどが有ります。

・現用のWEBサーバはレンタルサーバ会社Bのサーバを使用する。

レンタルサーバ会社Bと契約しWEBサーバ「b.com」を通常運用する。
データはa.comへ毎日コピーしておく。また、可能であればa.comの
独自ドメイン設定（内訳はメール設定、Apacheのバーチャルホスト設定、
DNSサーバへのゾーンの登録など）も行っておく。
サーバを移転する時の流れを事前に行っておく感じですね。

・障害発生時には

通常運用しているb.comのWEBサーバに障害が発生した際には
CNAMEレコードを辞めてAレコードでa.comのWEBサーバに向かせる。

・備考

DNSの伝播時間等々の検証が必要ですが、備えておくのは悪く無いと思います。
あとはオープンリゾルバなどセキュリティに関する対策を行っているDNSサーバ
自体が攻撃や障害で停止するのは、WEBサーバ障害よりは可能性は低いと
思います。障害の発生要因の1つである人為的なミスで考えても、アクセス数、
データ量、作業量がWEBサーバの方が桁違いに多いと思われるため。

また、本当に複数のレンタルサーバ会社のサーバは別のデータセンターに
有るかも確認しておきたいですね。複数のレンタルサーバ会社は、結局
同じさくらインターネットのデータセンターだったという場合は多いかと思います。

・利点

b.comのWEBサーバの周囲のDNSサーバ等を含むデータセンターまるごとが
火災などで障害になっても（＝レンタルサーバ会社Bの全体障害）
使用しているDNSサーバはa.comのWEBサーバがあるレンタルサーバ会社A
のものであるため影響を受けない。

・欠点

通常運用中にほぼ無いと思いますが万一使用しているレンタルサーバ会社A
のDNSサーバが丸っきり使えないような障害になった場合は、復旧を待つのが
最善の策になってしまうかと思います。
次善の策としてはドメインのレジストラのサイトへログインし、使用するDNSサーバ
をレンタルサーバ会社BのDNSサーバへ変更、かと思います。

障害対策その2　Aレコード使用

Aレコードでも良いかもしれません。
※2つのレンタルサーバ会社で同じドメイン名設定（WEBサーバ移転中と
同じような状態）をしコールドスタンバイさせておくのはレンタルサーバ会社
で想定しているのか不明です。問題は無さそうに思えます。
メールやApacheのバーチャルホスト設定が残っていれば良いだけなので。
且つDNSサーバのゾーン情報も複数のレンタルサーバ会社のDNSサーバで
持つことになるのでより良いかと思います。

・設定

レンタルサーバ会社Aでa.comの独自ドメイン設定を行い
このWEBサーバを通常稼働させるサーバとする。
（内部の処理としてはApacheでのバーチャルホスト設定、メールの設定、
DNSサーバにa.comのドメイン情報追加などが行われます。）

レンタルサーバ会社Bでa.comの独自ドメイン設定を行う。

レジストラで登録するDNSサーバ（＝そのドメインの情報を持っているDNSサーバは
こっちのDNSサーバだよと教えること）はレンタルサーバ会社Bの
DNSサーバが良いかな。通常稼働させるレンタルサーバ会社AのWEBサーバとは
別の拠点にあるDNSサーバの方が良いかと思うので。

レンタルサーバ会社BのDNSサーバの設定変更をし、
a.comのAレコードにレンタルサーバ会社AのWEBサーバのIPアドレスを記載しておく。

・障害発生時には

レンタルサーバ会社AのWEBサーバに障害が起きれば、レンタルサーバ会社Bの
DNSサーバを編集しa.comのAレコードをレンタルサーバ会社BのWEBサーバの
IPアドレスにする。

・利点

レンタルサーバ会社AのDNSサーバもWEBサーバも同時に障害となっても
（＝データセンターまるごと障害）使用しているDNSサーバはレンタルサーバ会社B
のものであるため影響を受けない。

・欠点

通常運用中にほぼ無いと思いますが万一使用しているレンタルサーバ会社B
のDNSサーバが丸っきり使えないような障害になった場合は、復旧時間にも
よりますがドメインのレジストラのサイトへログインし、使用するDNSサーバ
をレンタルサーバ会社AのDNSサーバへ変更、かと思います。
レンタルサーバ会社Aでの独自ドメイン設定（a.comのドメイン情報追加など）
は事前に行っているため問題無いかと思います。

障害対策その3　DNSラウンドロビン

また、DNSラウンドロビン（同じドメイン名でIPアドレスが異なるAレコードを
複数作成し負荷分散すること）でも良いかもしれません。

※エックスサーバのDNSサーバでのDNSラウンドロビンの
実施について、以下のページに記載しました。

自宅サーバ構築その5　機器構成：自宅回線とルータとWindows

DNSラウンドロビンの欠点としては、通信の継続性を保てる保証が無いことや
Aレコードに記載しているWEBサーバの障害の有無について検知する仕組み
が無く、障害の発生しているWEBサーバのIPアドレスを返答してしまうことも
有るということです。

また、メリットにもデメリットにもなりうるのが「DNSサーバは自分のアドレスに
近いアドレスを優先的に選択する」ことを定めたRFCが有るといいうことです。
このメリットとしては、遠いサーバをコールドスタンバイ的に設置できる。
デメリットとしては、近いサーバに負荷が偏る。

※このRFCでも均等に負荷分散できるようYoutubeなどではIPアドレスの
上位プレフィックスを同じ値で揃えています。

障害発生をすぐに検知できるHTTPサービスなどの監視が有り、且つ
障害発生時にすぐAレコードを削除できる体制が有るのであれば
良いかもしれませんね。

障害対策その4　SRVレコード使用

HTTPなどのサービス名、プライオリティ、ウェイトなどを使用して
負荷分散する際に使用します。

障害対策その5　負荷分散装置を導入する

WEBサーバにアクセスしに来た際、自動で負荷分散装置が障害の発生
していないWEBサーバ群へアクセスを渡す方式です。