二台にしたのに、止まったままだった

架空事例：青葉機材が予約システムの停止へ備える。確率、運転時間、切替時間は単純化した計算例であり、実際の設備の測定値や推奨目標ではない。

壊れたのは一台、止まったのは全体

予約サーバを二台用意した。片方が壊れても、もう片方が動く構成である。ところが、主系が停止した日に、営業は三十分間予約できなかった。

待機系は起動していた。しかし、利用者の接続先を切り替える作業が手動で、担当者が障害を確認してから対応する必要があった。さらに、待機系の接続設定が古く、予約DBへ接続できないことが切替後に分かった。

二台あることと、一台を失っても業務を継続できることは違う。

冗長化は、残っている構成要素で、必要な機能を提供できる論理を設計することである。監視、切替え、設定、状態の引継ぎ、容量が不足すれば、予備の機械があっても、その論理は成立しない。原教材第13章の「部品故障」と「サービス不能」の区別が、現実の構成を読むために必要になる。1

二台とも必要なら、直列になる

AとBの二つが独立に動作し、ある観測時点でそれぞれが利用可能である確率を0.9とする。両方が必要なら、全体が利用可能である確率は 0.9×0.9＝0.81 となる。

一方、片方だけで必要な機能を提供でき、切替えなどを理想化するなら、両方が利用不能である確率は 0.1×0.1＝0.01 なので、全体の利用可能確率は 1−0.01＝0.99 となる。同じ二台でも、「両方必要」か「どちらか一方でよい」かで結果が変わる。

図で並んで見えるから並列、ケーブルが順につながるから直列と決めるのではない。業務が成功するために、どの要素の動作が必要かを読む。二つのWebサーバのどちらかが動けばよくても、両方が一つのDBへ依存しているなら、そのDBは全体に必要な要素として残る。

NISTの信頼性資料では、修理を扱わない寿命モデルについて、独立した要素がすべて必要な直列系と、少なくとも一つが生きていればよい並列系を区別している。2 その一定期間の生存確率と、本節で置いた観測時点の利用可能確率は、同じ名称の量ではない。どちらも独立性と成功条件から積や補集合を使うが、何の確率を計算しているかを明示する。

独立性は、台数を数えても分からない

二台のサーバは、同じ電源装置につながっていた。電源が止まれば、二台とも停止する。独立に故障するとした計算へ、この構成をそのまま入れることはできない。

同じ設定ファイルの誤り、同じプログラムの欠陥、同じ認証基盤への依存でも、同時に使えなくなる可能性がある。物理的に別の筐体だから、すべての故障原因が独立するわけではない。独立性を仮定した式は、共通の原因を見つけるための問いと一緒に使う。

説明のため、共通の電源が利用可能である確率を0.99とし、電源が動く条件の下では二台がそれぞれ0.9で独立に動くと置く。片方でよいサーバ群を含む全体は 0.99×0.99＝0.9801 となる。この値は、本節が置いた条件付きのモデルから導いた例である。実際の電源障害と機器障害の関係を測定した値ではない。

対策を考える際は、単にさらに一台増やすより、共通原因を取り除く方が効果を持つ場合がある。ただし、電源を分ければ同じソフトウェア欠陥まで消えるわけではない。何の故障を分離したかを個別に説明する必要がある。

予備機は、常に動いている並列要素とは限らない

一台を停止したまま保管しておき、主系の故障後に起動する構成は、最初から両方が動作する単純並列モデルとは条件が異なる。待機中の状態、起動の成否、切替えに必要な時間が関係する。

本事例では、待機系を毎日起動確認するだけでなく、予約DBへの接続、必要な設定、切替えた後の処理能力を確認する。主系と同じ台数の接続を受けられるかも必要だ。一台を失った後に、残る一台へ負荷が集中して停止すれば、名目上の冗長化は業務を守れない。

また、主系と待機系のどちらが更新してよいかを決める仕組みも必要になる。互いに相手が停止したと思い込み、両方が独立に正本を書き換えれば、停止を避けるための構成がデータの矛盾を生む。ネットワークから応答がないことは、相手の電源が切れたことの証明ではない。

切替えの高速化だけを評価せず、切替え後に誰が正しい状態を持ち、何を更新できるかを確かめる。可用性と整合性は、別々の設計図の話ではない。

故障しにくいことと、すぐ戻れること

修復可能なシステムについて、本節ではMTBFを一回の復旧から次の故障までの平均稼働時間、MTTRを平均修復時間と定義する。稼働と修復を繰り返す単純な定常モデルなら、稼働率は MTBF÷(MTBF＋MTTR) で表せる。1

平均稼働時間が990時間、平均修復時間が10時間なら99%。修復を1時間へ短縮すると、990÷991 で約99.899%になる。故障の発生間隔を変えなくても、復旧を速めることで利用できる時間の割合を改善できる。

ここで、MTBFというラベルの付いた計測値が、修復時間を含む故障発生から次の故障発生までの経過時間だったら、同じ式へそのまま入れてはいけない。修復時間を二度足すことになるからである。名称だけでなく、時間の開始と終了の定義を確認する。

また、99%の稼働率は、任意の一時間を必ず59分24秒利用できるという保証ではない。長期間に一度の大きな停止と、短い停止の繰返しは、同じ平均値になり得る。業務が連続運転を必要とする期間や、許容する停止の長さも別に考える。

続けるべきか、止めるべきか

点検情報が取得できなくなった。予約サイト全体を停止する案と、点検済みと確認できない機材の確約だけを止め、依頼の受付や既存予約の照会を継続する案がある。

本事例で後者を採るなら、機能を限定して業務を継続するフェールソフトの考え方になる。一方、装置の故障時に危険を避ける状態へ移すフェールセーフでは、何を安全と定義するかが先に必要である。停止すればどんなシステムでも安全、とはいえない。1

予約業務では、貸出し条件が不明なのに成功と表示して顧客へ確約することを避けたい。そのため、確認中として扱う。これは何も表示せず全業務を止めることとは違う。何を継続し、何を保留するかを、保証できる情報の範囲から選ぶ。

フォールトトレランスは、構成要素の故障があっても所定のサービスを保つための性質であり、フェールオーバーは切替えの動作を指す。切替えたという事実だけで、必要なサービスを維持できたことにはならない。似た名称でも、対象が目的、性質、操作のどれかを区別する。

復旧は、起動後の確認まで続く

バックアップからDBを復元した。接続でき、表も存在する。しかし、障害直前に受け付けた予約と、外部へ送った通知の状態が一致していない。利用者にとって、まだ業務へ戻れる状態ではない。

復旧の検証では、データを読み戻せること、必要な時点まで戻れること、アプリケーションが利用できること、外部との処理状態を照合できることを分ける。RTOを「サービスを再開できるまで」と定義したなら、OSが起動した時点だけを終了にしない。

青葉機材では、障害中の依頼をどこへ記録し、どの順に取り込むかも定める。復旧後の記録へ手入力するとき、同じ受付を二度登録しない識別が必要だ。保守担当だけが復旧を確認しても、営業が未処理の依頼を扱えなければ、業務上の回復は終わらない。

シラバス16-3の運用テスト計画や、8-4の運用・保守の実現可能性は、この実際の回復を確認するための観点につながる。1 二台の機械ではなく、障害後にも成立する仕事を設計するのである。

知識を答案へ戻す

午前Ⅱ。 直列・並列は成功条件で判断し、独立性や理想的な切替えの仮定を読む。信頼度、稼働率、修復時間、切替操作、安全側への移行は異なる対象を表す。

午後Ⅰ。 構成図の共通電源、共有DB、認証、手動切替え、復旧手順に着目する。二台あるだけで単一障害点がなくなったと判断しない。停止時に継続できる業務も本文の条件から選ぶ。

午後Ⅱ。 冗長化の台数だけでなく、想定した故障、共通原因、切替えの成立条件、復旧完了の判定を説明する。計算の理想値と、実際に確かめた運用の時間を混ぜない。

立ち止まって考える：二台の稼働率がそれぞれ90%なら、全体は99%か

どちらか一台で必要な機能を提供でき、独立性や切替えの理想化が成立する場合の計算である。両方が必要なら81%となり、共有電源や切替失敗を含めれば別のモデルになる。数字の前に、成功の条件を確定する。

出典と照合範囲

[1] コンプリートテキスト第10・13・15章、IPA「SAシラバス Ver.5.2」4-14、5-5、8-4、16-3：信頼性、可用性、冗長化、復旧と運用検証を出発点とした。MTBFを用いる式では本章の稼働時間の定義を明示した。数値例と構成上の失敗は独自の仮定である。公式シラバス

[2] NIST/SEMATECH e-Handbook, Series model / Parallel or redundant model：独立な要素と全体の成功条件を参照した。同資料は非修理系の寿命モデルであり、本章の修復可能系の稼働率と無条件に同一視していない。直列系 / 並列系