それは突然牙を剥く
このご時世で、増え始めたリモートワーク。
出勤時間という無駄な概念がなくなり、家では猫に癒されながら仕事ができると、いいことずくめだったりします。
そんな癒しの猫様なわけですが、時として牙を剥く事があります。
- 高いところにのぼって物を落とす
- キーボードの上を颯爽と踏み抜けていく
- Web会議中に乱入
- etc.etc...
等、ひやりとすることも多々。
時に心臓に悪かったり、仕事の中断を余儀なくされたりすることもしばしば。
そんなあなたにフェイルセーフ
フェイルセーフとは、fail（失敗）safe（安全）が組み合わさった言葉で、ようは何か異常事態が起きた時に被害を最小にするための対策をどう講じるかを指す言葉です。
例えば上記の猫の例から考えると、
- 高いところにのぼって物を落とす
①高いところに物を置かない（生活空間に物が溢れる可能性が...）
②高いところに物を置くなら落とされてもいいものを置く（一部例外が発生した時に、元の問題が起こる）
③高いところに登れないようにする（見た目も考慮しようと思ったらコストが...）
④ものが落ちてもある程度大丈夫なように床をクッションフロアにする（足元の感触とコストが...）
⑤いっそ壊れてもいいように予備を用意しておく（予備を買うコスト、および壊れるものを掃除するコストは解決できず）
⑥猫を飼わない（却下）
と、１つの事象から色々な対策を考える事ができます。
そういった様々な対策の中、今の状況に合った対策を選択する事で、いざアクシデントが発生した際の被害を可能な限り最小にすることができます。
例えばお金をかけることができないのであれば、①か②で対応する感じになるかと思います。
その場合、コストは物を置く場所を確保するために生活空間を一部犠牲にする事になるかと思われ...
システム構築におけるフェイルセーフ
フェイルセーフはシステム構築の現場では日常的に考慮する話です。
特にシステムのダウンタイムに猶予が無いようなシステムを構築する際は、取り外し可能な部品も含めて対策します。
例えば某緊急システムを構築していた時は以下の観点でフェイルセーフの対応を行っていました。
- 電源
- ストレージ
- NIC
- アプリケーション
- サーバ
- システム全体
電源のフェイルセーフ
想定障害
- 電源のダウン
対策
電源の入力を複数（一般的には２つ）用意する。
電源は別々の系統から入力するようにする。
※片系統の電源が死んでも、別系の電源が生きている可能性にかけるため。
電源ユニットの交換は電源を落とす必要があるので、システムが止められない場合はサーバのクラスタ化は必須。
当時の案件では構成に含まれてなかったが、ＵＰＳの導入も検討するとさらに以下の障害に耐性がつく。
- 瞬時停電
- 電源ダウン時の正常なシステムダウン
ストレージのフェイルセーフ
想定障害
- ストレージエラー
対策
ストレージを２個１組（赤枠）として、それを３組用意（計６個）し、RAID10で構成。
※この２個１組を用意する本数によって、障害耐性が上がる。
各組１個ずつ、計３個までのストレージ障害に耐えられるように設計。
※赤枠内の両方で障害が発生した場合はアウト
交換後はリビルドが必要になるので、システムが止められない場合はサーバのクラスタ化は必須。
NICのフェイルセーフ
想定障害
- NICボードの障害
- ケーブル破損による障害
対策
NICを複数枚（画像は２枚の場合）用意する。
各NIC毎に同一ネットワークに繋いで組にする（赤枠を１組とする）。
※注意：ここを同一NIC内で組にした場合、ケーブル破損による障害には対応できるが、NICの障害には対応できなくなるので注意。
オンボードNICはそのNIC自体に障害が発生した場合、マザーボードごと交換となるので使用しない方が望ましい。
NICの交換は電源を落とす必要があるので、システムが止められない場合はサーバのクラスタ化は必須。
アプリケーションのフェイルセーフ
想定障害
- 例外によるアプリケーションのダウン
- アプリケーションのフリーズ
対策
アプリを複数起動し、互いにデータ共有し動作させる。
サーバがクラスタ構成をとる場合は、クラスタ間でデータの共有を行い、処理に差異が出ないように気を付ける。
処理が止まっている事や、アプリケーションがダウンしていることは、外部のミドルを使用し、アプリケーションに対してヘルスチェックを行い、問題があればアプリケーションの再起動を行うようにする。
サーバのフェイルセーフ
想定障害
- サーバメンテナンス
- マザーボード障害
対策
同一の構成のサーバをもう一台用意し、クラスタ（Act/Sby）構成にする。
サーバにアクセスするアプリケーションがAct/Sbyを意識しないように、サーバへのアクセスは仮想IP（VIP）を使用するようにする。
※クラスタ構成の運用で使用する一般的なHAミドルウェアについてはまた次回
システム全体の障害対策
想定障害
- 拠点の停止（大規模地域災害等）
対策
同一の構成のシステムを別の拠点に設置。
拠点間でデータを同期させる仕組みの導入。
実際にこのシステムを構築／テストして気づいた事
かなり対策を入れる事で安定して稼働できるように一見みえるのですが、意外と協調動作している部分が多く、万が一どこか一か所でも切替に失敗してしまうと、元のサービス稼働状態に戻すのに非常に手間がかかる代物でした。
ひとが作るシステムなので、絶対に失敗しないという事はあり得ません。
なので対策もほどほどにしておかないと、最終どうしようもなくなった時に元に戻すところにコストが多大にかかる可能性があります。
ですので出来る限りシンプルな作りにしておくのも一つの手ですね。
このあたりは、要求されているシステムの規模によるので、案件毎にバランスを見て考えるようにしましょう。
まとめ
システム構築の中ではよく目にするフェイルセーフですが、この考え方は日常生活でも自然とそういう行動をとっていることが多い概念だったりします。
防災対策もフェイルセーフの１つですね。
地震が発生した時の事を考えて、ものが倒れたりしないように突っ張り棒で天井と棚を突っ張るとか。
あなたの生活の中にもフェイルセーフをどんどん取り入れて、日常生活を安定させてはいかがでしょうか？