0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

3分で理解する#09 冗長化してるのに落ちる理由——SPOF(単一障害点)の見落としパターン

0
Posted at

HSRPも組みました、回線も二重化しました。なのに全部落ちました

HSRP/VRRPでゲートウェイを二重化し、回線も2本引いて、スイッチもペアで組みました。設計書にも「冗長構成」と書いてあります。

なのに両系まとめて落ちました。

こういうとき原因を追うと、たいてい冗長化した「つもり」の場所とは別の場所に、たった1つの共有点(SPOF)が残っていたという結末になります。プロトコルレベルでは完璧に二重化されていても、その下や外側に潰し忘れたSPOFがあれば、冗長化は意味を持ちません。

今回は、経験上よく見落とされるSPOFのパターンを俯瞰的に整理します。


SPOFとは何か

SPOF(Single Point of Failure / 単一障害点) とは、そこが1つ壊れるだけでシステム全体が止まってしまう箇所のことです。

冗長化の目的は「SPOFを潰すこと」に尽きます。ところが実務では、見えているレイヤーのSPOFだけ潰して、見えていないレイヤーのSPOFを残すというミスが繰り返し起きます。HSRPを組んだから安心、というのは早計です。それはネットワーク層(L3)のSPOFを潰しただけであり、その下にある電源やラック、その外側にあるDNSやISPはまったく別問題だからです。


見落とされがちなSPOFパターン

①電源系統の共有

二重電源(デュアルPSU)搭載機器を使っていても、両系統とも同じPDU、同じブレーカー、同じUPSにつながっていれば、そのブレーカーが落ちた瞬間に両方とも道連れになります。「電源が二重化されているか」ではなく「二重化された電源の『大元』が分かれているか」を見る必要があります。

②設置場所(ラック・フロア・拠点)の共有

冗長構成のペア機器を同じラックに並べて設置していないでしょうか。空調故障、誤結線、作業ミス、水漏れなど、ラック単位・フロア単位で発生する障害には、機器が別々でも意味がありません。可能であれば別ラック・別フロア、拠点をまたぐなら別拠点に分散させましょう。

③上流回線・経路の物理的な相関

インターネット回線を2社契約して冗長化しても、その2本が同じ電柱、同じ管路、同じ収容局を通っていることは珍しくありません。論理的には別回線でも、物理的には1本の工事で同時に切れます。契約時に「経路が分離されているか(ルートダイバーシティ)」まで確認しないと、冗長化の効果はありません。

④帯域外管理(OOB)が本番経路に相乗りしている

本番トラフィックが流れる経路がダウンしたときに、機器にログインして復旧作業をする経路まで一緒に落ちるケースがあります。管理用のアクセス経路(OOB管理、コンソールサーバー経由の回線など)は、本番系とは独立させておかないと、障害発生時に「機器は生きているのに誰もアクセスできない」状態になります。

⑤同一ベンダー・同一バージョンによる共通モード故障

冗長ペアを同一機種・同一ソフトウェアバージョンで組むのは基本ではありますが、裏を返せば片方で踏んだバグはもう片方でも踏むということでもあります。特定条件で発生するソフトウェアバグや、ライセンスや証明書の有効期限切れなどは、両系同時に発症する典型的な「見えないSPOF」です。

⑥属人化というオペレーション上のSPOF

機器は冗長化されていても、「切り替え手順を知っているのが1人しかいない」状態はSPOFそのものです。手順書がない、切り戻し手順が検証されていない、深夜に対応できるのが特定の1人だけ、という体制は、機材の冗長化とは別の軸で潰しておく必要があります。

⑦ネットワークの「外側」にあるSPOF

経路を何重にも冗長化しても、その先にあるDNSサーバーが1台しかない、認証基盤(RADIUS/AD)が1系統しかない、証明書の発行元が単一障害点になっている、といったケースは意外と見落とされます。ネットワークがつながっていても、名前解決や認証で止まればサービスは止まります。


SPOFを見抜くための視点

洗い出すときは、プロトコルの冗長化構成図だけを見ても不十分です。次の視点で重ねて確認しましょう。

  • 物理と論理を両方たどる:config上は別機器・別回線でも、電源・ラック・配線・収容局まで遡ると同じ場所に行き着かないかを確認します。
  • 冗長化の「単位」を明確にする:何が壊れたときに、何が生き残ればよいのかを先に定義します(1台故障か、1ラック消失か、1拠点消失か)。
  • 切り替え試験を実際にやる:構成上は冗長化されていても、実際にフェイルオーバーが発動するかは切ってみるまでわかりません。「組んだ」で終わらせず「切り替わることを確認した」まで含めて冗長化と呼びます。
  • 人・手順もリソースとして数える:機材だけでなく、対応できる人と手順が複数系統あるかも合わせて確認します。

冗長化構成図に「二重化済み」と書かれていても、それは多くの場合プロトコルレベルの話でしかありません。電源・設置場所・経路・運用体制まで含めて初めて「SPOFが潰れている」と言えます。


まとめ

  • 冗長化の目的はSPOFを潰すことですが、見えているレイヤーだけ潰して満足しがちです
  • 電源系統、設置場所、上流回線の物理経路、帯域外管理、ソフトウェアバージョン、属人化した運用体制、ネットワーク外のDNS/認証基盤——これらは見落とされやすい代表的なSPOFです
  • 冗長化は「組んだ」だけでは判断できず、実際に切り替え試験をして初めて効果が確認できます
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?