冗長構成のフェールオーバー判断：やり過ぎはダメ

今どきのサービス提供側のシステムは、レベルの差はあるものの、冗長構成となっていることは当たり前でしょう。ネットワーク構成が冗長化されているのはもちろん、サーバも冗長化されているのは当然という感じだと思います。

私自身はネットワーク構築のプロではないので（ネットワークプログラミングでは飯を食っていますが、ルーターやスイッチの構築などは詳しくありません）、サーバの冗長化について少し書いてみます。

サーバ冗長化の目的は、サーバがサービスを提供し続けることです。サーバに考えられる障害は、大ざっぱに考えて、

・ハードウェア障害：ソフトウェア以外の問題全般

・OS障害：サーバ全体が正常に動かなくなる

・プログラム障害：あるプログラムだけが異常になる

と分類してみます。

一般的に、サーバの冗長化では、2台以上の同様なサーバ機（仮想環境も含めて）を準備し、片方がサービスを提供し（アクティブ機）、もう片方はアクティブ機が異常になった際に継続してサービスを提供できるように準備する（スタンバイ機）となります。このような形態を「アクティブ・スタンバイ構成」と呼ぶ感じです。他に、複数台がそれぞれサービスを分散して提供する構成「アクティブ・アクティブ構成」「負荷分散」などもあります。サービスの内容によって使い分けます。DHCPサーバなどのように、排他的な情報を管理する必要があるサービスでは「アクティブ・スタンバイ構成」が管理しやすく、WEBサーバのようにある固定的な情報を提供するだけのようなサービスでは「アクティブ・アクティブ構成」が向く、という感じです。

さて、「アクティブ・スタンバイ構成」のサーバの冗長化で難しいのは、切り替え（フェイルオーバー）の判断です。「アクティブ機がサービス不能状態になった際にフェイルオーバーさせる」と言うことは簡単ですが、実際に構築してみると意外と難しいのです。

「アクティブ機の電源が切れた」というような、分かりやすい障害であればフェールオーバーは簡単です。しかし、「アクティブ機のハードディスクが不調」となると、普通に動いているように見えても、処理によってはとても時間がかかることがあったりします。

「上位スイッチとのネットワーク疎通が途絶えたら障害」と判定するようにしていたところ、上位スイッチに設定を流し込んでいる間に疎通確認の応答が大きく遅延する特性があり、サービスには問題がないのに障害と判断してしまった、というケースもあります。

ネットワーク関連は負荷状態にも左右される場合があり、疎通確認パケットがたまにドロップすることもあるかもしれず、1回でも届かなかったら障害と判断してよいとも言えないものです。

1台のサーバで複数のサービスを立ち上げている場合はさらに難しくなります。どれか一つのサービスがおかしくなった時点でサーバごとフェールオーバーさせるべきか、あるいは、他のサービスが正常であれば異常になったサービスだけ再起動させるべきかも悩むところです。

今どきのサーバ機はそう簡単には異常になりません。私の経験では、新築マンション工事中に設置されたサーバ機はことごとくハードディスクが壊れましたが、コンクリートを削ったカスをどんどん吸い込むような場所に設置したり、あるいは運搬中に強い衝撃を与えたりしなければ、そう簡単には壊れません。実はProDHCPをはじめとした冗長化構成でのシステム運用で、「本当に冗長化のおかげで助かった」ケースは意外と少ないのです。大抵は「切り替わる必要がないときに切り替わってビックリした」ということばかりなのです。

もちろん、だからといって冗長化は不要ということではなく、たった1台でのサービス提供など怖くてできませんので、必要です。しかし、フェールオーバーの判断や構成は十分に検討し、過剰にならないように注意も必要なのです。

また、新築マンションの現場では、不調になったサーバをなんとか復旧させる作業も担当しましたが、あまりにも複雑な冗長化は、冗長構成から切り離して単独稼働させることすらとてつもなく困難でした。関係者から「冗長化をシンプルに構成できて、いざというときには簡単に単独稼働もできるものが欲しい」と言われ、自分でシンプルな冗長化システムを開発し、提供したものでした。今でもその時のノウハウを活かしたProDHCPと組み合わせて使える冗長化システムを提供していますが、実はあまりにもシンプルで汎用性も高いので、ProDHCPとは別の構築でもたくさん使われています。

ちょうど今もProDHCPとは別の冗長化の依頼を受け、検討しているところですが、なんと言ってもポイントは「判定基準を過剰にしないこと」です。困ったときに働いてくれるのは助かりますが、平常時に切り替わってしまうのはとても心配になるものですし、データの同期がバッチ的なものでは、切り替えが頻発するのはむしろ困ります。ProDHCPはリアルタイムデータ同期なので、いつでもいくらでも切り替えても困らないのですが、そうでないシステムの冗長化ではなおさら判定基準は重要です。

冗長構成は簡単なようで実は意外と気を使って設計しなければならないものなのです。