ブログ執筆の機会をいただき、当初は「TCPヘッダにDTH（Death）フラグ（※RFC9401）がセットされている場合、サーバはどのような挙動を示すのか」という検証を企画しましたが、興味深い結果にならなそうだったので取りやめました。このまま原稿を落とすと、筆者自身にDTHフラグがたちそうなので、本稿ではネットワークの冗長構成についてこれまで経験し考えてきたことを整理してみたいと思います。なお本稿はネットワーク設計者でなくとも冗長化の仕組みや考え方を楽しんでいただけるよう構成しました。
※RFC9401：2023年のエイプリルフールに発行された、TCPに「死亡フラグ」を追加するというジョーク規格
ネットワーク設計書において冗長構成を検討するにあたっての前提として「単一のリンクないしノード障害を前提とし、二重障害は考慮しない」という記述を見かけることがあります。これは、同じ役割や機能を求められる階層内で、必ず1つは稼働していればいいことになるので、図のような正副2台のノードで構成されるクラスタの集まりで設計されることになります。
「N＋1」でいうと「N＝1」のときの構成です。多くのシステムが求める可用性はこれで満たせることになるでしょう。しかし、共同利用型サービスを提供するネットワークなどにおいてはリスクの高い構成になります。例えばノードのメンテナンス作業のときです。正副2台構成のうち一台を切り離して作業を実施することになった場合、その個所は作業中、冗長のないSPOF（単一障害点）となります(図)。
作業時間が長いほどリスクにさらされる時間が長くなり、ひとたび障害が発生すると重大な被害をおよぼします。そういった重要な区間ではN=2以上の構成設計が求められます(図)。
多ければ多いほど安心は得られるでしょうが、稼働率やコスト面を考慮した適切なNの値の決定と、いざ切り替わった際に使えないことが発覚することのないよう、普段から分散して利用しておくような工夫が求められます。
ネットワークは図にも描いたように特定の役割・機能でクラスタがあり、隣接したクラスタ内のノード間でリンクを形成しています。隣のクラスタとのリンクは図のようにたくさんあるほど使えなくなるリスクは軽減されますが、その分構成が複雑になってしまいます。
また必要な回線やインタフェースが増えることで大型機器が必要となりコストも大きくなるのが想像できます。その対応策として、いくつかの役割・機能のかたまりを一つのブロックとして、途中他の系統へ移ることのない設計を考えるのも有効な考え方です。ブロック一つだけでは冗長性はないですが、前述のようなN＋1の構成を全体でとることで維持管理のしやすさとシステム全体の耐障害性を維持することができます(図)。
ここまではリンク（機器間のケーブル）とノード（機器そのもの）というネットワーク構成図上認知しやすいレイヤでの話が続いてきましたが、それだけ意識していればいいのでしょうか？
ネットワーク機器の中を見てみましょう。スイッチやルータの中にはいろいろなチップが入っていてインタフェースの動作を制御しています。一つのチップですべてのポートを制御しているものもあれば、いくつかのポート毎にチップが分かれているものもあります。では複数あるチップの1つが壊れた時はどうなるでしょう？ノードの障害とまではならず、複数ポートでのリンク障害となりそうですね(図)。その結果、冗長設計の前提としている「単一のリンクないしノード障害」ではないことが起きます。モジュール（ネットワーク機器に装着するカードのようなもの）ならば想定される障害箇所として気が付きやすいですが、ボックス内部までチェックして設計するのはなかなか大変です。この機会に皆さんが使っているネットワーク機器の内部のアーキテクチャについて一度調べてみるといいでしょう。
逆に視点を広げてみましょう。データセンターなどではラックの中にネットワーク機器を設置して運営しています。一つのラック内でシステムが完結することはなく、ほかのラックへのケーブルやセンター外へとつなぐ回線を使ってラック外とつながっています。それらのリンクが同じ管路（ケーブルの保護を目的として敷設された管）や多芯ケーブル（複数のケーブルをひとまとめにしたもの）を途中使っているとどうなるでしょう？センター内での不慮の事故で同時にたくさんのリンクが障害になるリスクがあるということになります(図)。対策としては、配線経路を分散することが望ましいですが、特定のセンター内で想定以上の障害が起きてもサービスを継続して提供できるように、複数センターで運営する施策が最終的には必要になります。
さらに視点を広げてみましょう。一つのセンターで想定以上の障害が起きても何とかなるように2つのデータセンターで稼働するシステムを作ったとします（図）。
このシステムの利用者がいる拠点と2つのデータセンターはキャリアが提供する回線サービスを使って接続しています。図の通りだと一方のセンターが不全になっても、もう一方のセンターで稼働し続けそうですね。しかしキャリア内の構成はどうなっているでしょうか？キャリア側にはPE（プロバイダーエッジ）と呼ぶネットワーク機器が、拠点やデータセンターにあるCE（カスタマーエッジ）と呼ぶネットワーク機器と回線を通じてつながっています。このPEがカバーする範囲が広く、データセンターを分けていてもキャリアのPEで一つになっていることがあります。そういう状態だとPEの障害1つで立ち行かなくなります（図）。
これを回避するためには複数のキャリアを採用することや分散するセンターの距離を十分とるということが必要です。
以上のようにネットワーク構成図で意識できる範囲以外のレイヤにも冗長設計を考える必要が出てきます。
ここまで私が携わってきたネットワークの冗長設計を検討するにあたって意識し検討してきたことを整理しました。これらはあくまで一部であって、本稿で挙げていないこともたくさん考慮点として出てくるはずで、非常に多岐にわたるものになるでしょう。同時に、それらすべてに対処していくことは、システムが求めるレベルと、費用とのバランスから現実的ではないことも想像できるのではないでしょうか。
そこで、考慮の対象から外した事項で起きた障害が想定外の事象として我々にやってきたときの対応方針を考えておくべきです。想定外のことが起きた時、どういったことを優先し、チーム・部署でそれぞれどういう役割をもって、この事態に取り組むかを意識合わせしておくことが大事です。暫定復旧方法としては、想定外の事象から、我々が考慮している状態にもっていって解決することが有効だと考えています。おそらく、リンク障害やノード障害のことは考慮済みでテストを実施しているはずです。そういったテスト済みの状態に持っていくことが暫定復旧策として有効です。
言い換えると、「被疑箇所を特定し、電源OFFなどで切り離す対応を障害検知後速やかに実行できるように、行動指針を策定し、実際に指針にそって行動できるように定期的に訓練しておく」こと、それが想定外事象の障害影響を早く、収束させる対策となります。
これからネットワーク設計に携わる人たちの一助になると幸いです。また、当社サービスをご利用いただいている方、現在ご検討されている方におきましては、安心安全にご利用いただけるようセキュリティ面だけでなく可用性の面でも品質維持の努力を積み重ねていることを、本稿を通じて少しでも実感いただけたのならばうれしい限りです。