ニュース

Com Net Work Com Net Work .inc

ネットワーク冗長化の方法とは?止まらない仕組みの作り方

ニュース

「止まらないネットワーク」は設計と運用がセット

【この記事のポイント】

ネットワーク冗長化とは、「一つが止まっても、もう一つが自動で引き継ぐ仕組みをあらかじめ組み込んでおくこと」であり、回線・ルータ・スイッチ・電源・経路など、止まると困るポイントごとに「代わりのルート」を用意する考え方である。

正直なところ、よくあるのが「インターネット回線を2本にしたから安心」と思い込んでしまい、ルータやL2スイッチ、電源、構内配線が単一障害点(SPOF)のまま残っているケースである。実務では、「どこが壊れても業務継続が必要か」を決めてから、そこにだけお金と設計リソースを集中させる方が、コストと効果のバランスが取れる。

行動としては、「①業務上『止められない』システムと時間帯を洗い出す」「②回線・機器・電源・経路ごとに単一障害点を書き出す」「③優先度の高い箇所から『2系統化・デュアル化』を進める」という順番で考えると、「とりあえず全部二重化」ではなく、現実的な冗長化設計に落とし込める。

今日のおさらい:要点3つ

  • ネットワーク冗長化は「全部を二重化する」のではなく、「止めてはいけないポイントを絞り込んで、そこを経路・機器・電源レベルで二重化する」のが現実解である
  • 回線・ルータ・L3スイッチ・電源など、どこが単一障害点かを可視化し、RTO(復旧時間)に応じて優先度をつけることが重要である
  • 二重化しただけでなく、自動フェイルオーバ設定と定期的な切替テストを含めて初めて「止まりにくいネットワーク」が実現できる

この記事の結論

一言で言うと、「ネットワークを止めないための冗長化は、『止めてはいけないポイントを絞り込んで、そこを経路・機器・電源レベルで二重化する』のが現実解である」。

最も重要なのは、「①インターネット回線・ルータ・L2スイッチ・配線・電源など、どこが単一障害点かを可視化すること」「②L3冗長化・リンクアグリゲーション・デュアル回線などの手段を、目的に応じて組み合わせること」「③『切り替えの仕組み(フェイルオーバ/VRRP/ダイナミックルーティング)』を含めて設計し、定期的にテストすること」である。

失敗しないためには、「冗長化=高価な装置を買うこと」だと思い込まず、「業務インパクトの大きさ」と「復旧時間(RTO)」を先に決めてから、どのレイヤーをどのレベルまで冗長化するかを決めるのが大切である。正直なところ、「止まっても数時間は許容できるシステム」に、データセンター並の冗長化を施す必要はない。

社内チャットが一斉に静まり返った、「あの30分間」のこと

ネットが落ちた瞬間、キーボードを打つ手が止まり、無意識にルータのランプを見に行く

正直なところ、「ネットワーク冗長化は後回しにできない」と痛感したのは、ある平日の午前10時だった。いつも通りリモート会議の準備をしていると、突然Teamsの画面が固まり、チャットも更新されなくなった。

最初は「相手側の回線かな」と思いながら何度かリロードボタンを押してみたものの、ブラウザはくるくると回るだけ。しばらくして、隣の席からも「ネット繋がってます?」と声が上がり、オフィス全体の空気が少しざわつき始めた。

気づけば、3〜4人が同時にルータのあるラックの前に集まり、無意識にランプの状態を覗き込んでいる。LANケーブルが抜けていないか、ONUの再起動で直らないか、スマホのテザリングで急場をしのげないか。そんな「場当たり的な対応」をしながら、心のどこかで「これ、もっと早く考えておくべき話だったな」と、小さな後悔が湧いてきた。

実は、「止まること」より「止まったときの選択肢がないこと」が一番怖い

このときの障害は、結果的に回線業者側の設備トラブルで、30分ほどで復旧した。ただ、その30分の間に飛んだ会議は2件、止まっていた受注入力は十数件分。「もしこれが半日続いていたら」と考えると、ぞっとした。

数日後、保守ベンダーと話したとき、担当エンジニアにこう言われた:

「正直なところ、『絶対に止まらないネットワーク』は存在しません。大事なのは、『止まったときにどんな選択肢があるか』です。」

「例えば、回線を2本にして自動フェイルオーバするのか、ルータを二重化するのか、最悪のときはどの業務を優先的に動かすのか。それを決めておかないと、いざというときに『全部が止まって全部が困る』状態になってしまいます。」

その言葉を聞いたとき、「冗長化=機器の話」だと思い込んでいた自分の視野の狭さに気づいた。本当に考えるべきだったのは、「業務視点で、どこまで止めてはいけないか」だったのだと。

ネットワーク冗長化の基本 ― どこを二重化するのか

冗長化の対象 ― 回線・機器・経路・電源

ネットワーク冗長化で考えるべき対象は、大きく以下の4つである:

回線の冗長化

インターネット回線/閉域網を2系統以上用意する(キャリア多重・メディア多重)。例:フレッツ光+他社光、光+LTE/5Gなど。

機器の冗長化

ルータ・L3スイッチ・ファイアウォール・コアスイッチなどを二重化(HA構成)。VRRP/HSRP、クラスタリングなどで自動フェイルオーバを実現。

経路の冗長化

構内配線・ルーティングパス・スイッチ間リンクの多重化。例:コアスイッチ2台構成+各フロアから両方に接続、リンクアグリゲーションなど。

電源の冗長化

二重化電源・UPS・別系統コンセントへの給電。電源トラブル時にも片系で動作継続。

「全部をMAXで二重化」は現実的ではないので、業務インパクトに応じて優先順位を付ける。

単一障害点(SPOF)を見つける ― 図に描き出す

正直なところ、冗長化の議論がふわっとする最大の原因は、「どこがSPOFなのかがそもそも見えていない」ことである。一度ホワイトボードや図面に、回線、ルータ、ファイアウォール、コア/フロアスイッチ、無線AP、サーバ・クラウドを線で結んだ「現在のネットワーク構成図」を描いてみると、「この1台のL3スイッチが落ちると、全部門の通信が止まる」「この1本の光回線に、全拠点VPNが集中している」といった「細い首」が見えてくる。

実際に、一緒に図を描いたインフラ担当から「ここが『首』になってるんですよね。そこだけは太くしておきたい。」と言われたことで初めて、自社ネットワークの「弱いところ」を実感できた。

冗長化レベルの考え方 ― RTOとRPOで線を引く

冗長化の深さを決めるには、以下を業務側と話し合いながら決める必要がある:

RTO(復旧目標時間):どれくらいの時間まで停止を許容できるか

RPO(目標復旧時点):どこまで遡って元に戻せれば良いか

例えば、社内の一般Web閲覧やメール→RTO 1〜2時間でも許容、ECサイトのフロントやコールセンター→RTO 5〜10分以内に抑えたいといったレベルの違いに応じて、「回線はシングルだがルータだけ二重化する」「回線もキャリア多重、機器もHA、電源も二重化する」など、投資レベルを変えることができる。

具体的な冗長化パターンと「よくある失敗」

パターン① 回線冗長化 ― キャリア多重とメディア多重

最も分かりやすい冗長化が、「回線を2本にする」ことである。代表的なやり方は以下の通りだ:

キャリア多重

異なる事業者(例:NTT系+KDDI系)で回線を契約し、片方が障害でももう片方で稼働する。

メディア多重

光回線+CATV/LTE/5Gなど、物理的な伝送路も分ける。

よくあるのが、同じキャリアの別プラン2本で「冗長化したつもり」になり、局所障害やキャリア全体障害で両方落ちるパターンである。「正直なところ、回線冗長化はキャリアを分けて初めて『本当の冗長』に近づく」というのは、現場エンジニアの口からもよく出る言葉である。

また、回線を2本用意しただけでフェイルオーバ設定をしておらず、片方が落ちてもルータが自動で切り替わらない、手動でケーブルを挿し替えないといけない状態のまま、障害時に慌てるケースもある。

ここはルータやUTM側で、デュアルWAN、経路監視(Dead link検知)、自動フェイルオーバを組み合わせて設定しておくことが重要である。

パターン② 機器冗長化 ― ルータ/L3/FWのHA構成

コアとなる機器(ルータ・L3スイッチ・ファイアウォール)が止まると、回線が残っていても通信は止まる。ここでは、VRRP/HSRPによるデフォルトゲートウェイ冗長化、FWやルータのクラスタ構成(アクティブ/スタンバイ、アクティブ/アクティブ)などが代表的な手段である。

現場の声でよく聞くのは、「実は、ルータを2台置いているのに、片方が完全な予備機で、切り替えるには手作業が必要」というパターンである。この場合、「壊れてから復旧までの時間(RTO)」は短くならず、真の意味での冗長化とは言えない。

一方、きちんとHA構成を取ると、片方の機器が落ちたときに数秒〜数十秒で自動切替、セッション維持や動的ルーティングとの連携も可能といった「止まりにくさ」が実現できる。

パターン③ 経路・スイッチ冗長化 ― コア二重化とリング構成

配下のフロアスイッチや無線APが、単一のコアスイッチにしかつながっていない場合、そのコアがSPOFになる。対策としては、コアスイッチを2台構成にして、各フロアから両方にリンクを張る、リンクアグリゲーション(LACP)で帯域と冗長性を両立、スパニングツリーやループ防止機構を適切に設定などがある。

よくある失敗は、物理的には二重化しているが、スパニングツリー設定が不適切でループが発生し、大規模障害になる、コア二重化といいつつ、実際には片系しか使っておらず、切り替えテストもしていないというパターンである。

正直なところ、「二重化しただけ」で安心するのではなく、「半年に一度は片系を意図的に落としてフェイルオーバ試験をする」くらいの運用があって初めて、「止まらないネットワーク」に近づく。

実際の現場事例と、「こうしておけば良かった」の声

事例① コールセンターでの回線多重化 ― 30分の障害が5分で収束した話

ある中規模コールセンターでは、以前、キャリア障害で1時間以上電話とシステムが使えなくなった経験をきっかけに、インターネット回線を2社契約(光×光)、IP-VPNとインターネットVPNを組み合わせたハイブリッド構成、ルータ側で自動フェイルオーバ設定を導入した。

数か月後、再び一方のキャリアで障害が発生したものの、担当者はモニタのアラートで回線切替を認識、通話とCRMシステムは数分の瞬断で復旧となり、以前のような「全員が何もできない1時間」を避けることができた。

担当マネージャーは、「実は、二重化しても『どうせそんな障害は当分来ないだろう』と思っていました。でも、いざ同じような障害が来たときに、『あのときやっておいて良かった』と心から思いました。」と話していた。

事例② 本社のコアスイッチ停止で全フロア停止 ― 「電源」を甘く見たケース

別の企業では、本社のコアスイッチが入っているラックのブレーカが落ち、社内の有線LAN、Wi-Fi、一部のサーバ接続が全て止まる事態になった。機器そのものには冗長化構成が組まれていたが、両方のコアスイッチが同じ電源タップ・同じ系統に接続されていた、UPSも1台のみで、そのUPS自体がブレーカ落ちの影響を受けたという結果、「電源系統」という見落としていた単一障害点で、冗長化が一撃で無効化されてしまった。

障害後、インフラ担当はこう振り返った:「よくあるのが、『機器を2台にすれば安心』と思い込んでしまうことです。正直なところ、今回の件で、『電源やラック単位でもSPOFを見ないと意味がない』と痛感しました。」

その後、電源系統の二重化、UPSの二重化、ラック分散などを進め、同じ事故が起きても片系で動き続けられるように改善した。

「こういう企業は今すぐ相談すべき」「この状態ならまだ間に合う」

こういう企業は今すぐ相談すべきである:

  • 社内ネットワーク図が最新でなく、「どこが止まると何が止まるか」を誰も説明できない
  • ここ1〜2年の間に、ネットワーク障害で30分以上業務が止まったことがある

この場合は、一度ネットワーク構成を棚卸しし、「単一障害点の洗い出し」と「業務影響の棚卸し」から着手するのがおすすめである。

この状態ならまだ間に合う:

  • 拠点数は多くないが、クラウド利用やオンライン会議が増えてきている
  • 次のルータや回線更新のタイミングが近い

迷っているなら、「次の更新で最低限どこを二重化しておくべきか」をベンダーに相談し、小さな範囲から冗長化を始めるのがおすすめである。

よくある質問

Q1. 小規模オフィスでもネットワーク冗長化は必要ですか?

A1. 全てを二重化する必要はないが、クラウド依存度が高い・オンライン決済が多いなど「止まると売上に直結する業務」がある場合、その範囲だけでも回線やルータの冗長化を検討する価値がある。

Q2. 回線を2本引けば安心でしょうか?

A2. 同一キャリア・同一設備に依存している場合、局所障害で両方止まるリスクがある。キャリアやメディアの多重化、ルータ側の自動フェイルオーバ設定まで含めて設計することが重要である。

Q3. クラウドサービスを使っていれば冗長化は不要ですか?

A3. クラウド側は冗長化されていても、そこまでのネットワーク経路が単一だと、回線やルータ障害でアクセスできなくなる。クラウド利用が増えるほど、社内側のネットワーク冗長化も重要になる。

Q4. 冗長化にはどれくらいコストがかかりますか?

A4. 対象とレベルによって大きく変わる。回線の追加で月数万円~、コア機器のHAで数十万~といったイメージだが、まずは「1時間止まるといくら損失か」を算出し、投資額とのバランスを見て検討するのが現実的である。

Q5. どこから手を付ければ良いですか?

A5. 最初は「ネットワーク構成図の整備」と「SPOFの洗い出し」からである。その上で、インターネット出口やコアスイッチなど、「止まると業務影響が大きい場所」から順に冗長化していくのが定石である。

Q6. 冗長化した後の運用で注意することは?

A6. 定期的なフェイルオーバテストと、設定変更時の影響範囲の確認が重要である。「二重化したけれど、いざという時に切り替わらない」状態を防ぐため、運用手順とログ管理もセットで整備してほしい。

Q7. 冗長化せずに、障害時はテザリングやモバイルルータで凌ぐのはNGですか?

A7. 短時間かつ小規模なら現実的な選択肢だが、コールセンターや店舗・工場など、ネット前提の業務では限界がある。どの業務なら「手動対応で耐えられるか」を決めた上で、優先度の高い部分だけは自動冗長化するのがおすすめである。

まとめ

ネットワークを止めないための冗長化は、「回線・機器・経路・電源」のどこをどのレベルまで二重化するかを、業務インパクトとRTOを基準に決める設計の話である。全部を守ろうとすると予算がいくらあっても足りないため、「止められないところ」にだけ集中投資するのが現実的である。

正直なところ、「とりあえず2台・2本にする」だけでは不十分で、「自動で切り替わる仕組み」と「定期的な切替テスト」まで含めて初めて「冗長化している」と言える。まずは現状の構成を図に起こし、単一障害点と業務影響を整理するところから、一歩を始めてみてほしい。


💻 IT・通信に関するご相談はこちら

「業務効率を改善したい」
「通信環境を見直したい」
「自社に合うシステムを導入したい」

そんなお悩みはありませんか?

コムネットワーク株式会社では、
お客様の課題に合わせた最適なIT・通信ソリューションをご提案します。

まずはお気軽にご相談ください。

📞 フリーダイヤル:0120-56-9665
📞 TEL:052-533-0331
📠 FAX:052-533-0306

👉 お問い合わせはこちら
https://comnetwork.co.jp/contact/

―――――――――――――――

👩‍💼 採用エントリーはこちら

新卒・中途ともに募集しています。
IT業界で活躍したい方はぜひご応募ください。

👉 エントリーはこちら
https://comnetwork.co.jp/recruit/

News 一覧