冗長化とは？仕組み・種類・費用の考え方とBCPとの関係をわかりやすく解説

お役立ち記事

Share

Check!

  • 冗長化の意味と、稼働率・単一障害点という基本の考え方がわかる
  • アクティブ・スタンバイとアクティブ・アクティブの違いと、費用が増えるポイントがわかる
  • BCPとの関係と、予備への切り替えに気づけないといったよくある失敗の防ぎ方がわかる

「サーバーが1台止まっただけで、受注システムが半日使えなくなった」「冗長化しておけば大丈夫と言われたが、何をどこまでやればよいのか分からない」。社内システムやWebサービスを抱える会社にとって、障害で業務が止まるリスクは避けて通れません。冗長化とは、システムを構成する機器や回線、データについて同じ役割を果たす予備を用意し、どこか1か所が故障してもサービスを止めずに動かし続けるための仕組みです。

本記事では、冗長化の意味と目的、アクティブ・スタンバイやアクティブ・アクティブといった構成の種類、ミラーリング・バックアップとの違い、費用がどこで増えるのか、BCP（事業継続計画）との関係、導入でよくある失敗までを順に解説します。情報システム部門の担当者だけでなく、ITに詳しくない総務担当者や経営者が、ベンダーの提案を読み解くための基礎知識として使える内容にしています。

冗長化、どこから知りたい？ かんたん診断

Q1. 冗長化について一番知りたいことは？

おすすめ記事

目次

開く

閉じる
  1. 冗長化した基盤の運用・監視を支える統合運用管理ツールの比較
  2. 冗長化とは｜システムを止めないために予備を用意する仕組み
  3. 冗長化の種類｜アクティブ・スタンバイとアクティブ・アクティブ
  4. 冗長化の費用はどこで増えるか
  5. 冗長化とBCP（事業継続計画）の関係
  6. 冗長化を進める手順
  7. 冗長化導入でよくある失敗パターン
  8. よくある質問（FAQ）
  9. まとめ
  10. 参考文献

冗長化した基盤の運用・監視を支える統合運用管理ツールの比較

冗長化した基盤を安定して動かすには、運用と監視の仕組みが欠かせません。予備の機器を用意しても、本番機が止まったことや、予備に切り替わったことを誰も把握していなければ、予備が1台で踏ん張っている間に次の故障が起きて、結局サービスが止まってしまいます。冗長化は「二重にしたら終わり」ではなく、二重の状態が保たれているかを日々確かめて初めて効果を発揮します。

ところが、サーバーやネットワーク機器が増えるほど、監視の画面やアラートの通知先はばらばらになり、担当者が少ない会社では目が届かなくなります。そこで検討されるのが、サーバーや業務システムの稼働状況、ジョブの実行、IT資産をまとめて管理できる統合運用管理ツールです。下の表は、比較記事で紹介されているツールのうち、タイプの異なる3つを掲載されている強みと留意点で並べたものです。

サービス名（提供会社） タイプ 強み 留意点
JP1（株式会社日立製作所） ジョブ管理型 長年の導入実績があり、多様な環境に対応。長期の保守サポートが用意されている 詳細な機能構成や費用は問い合わせで確認が必要
SAMS（アイビーシー株式会社） ジョブ管理型 24時間365日の有人監視に加え、分析や改善提案まで受けられるサポートの手厚さ レポートやコンサルティング支援を受けるには別製品の利用が前提
Senju/EN（株式会社野村総合研究所） 自動化特化型 既存システムを変えずに導入でき、アラートを絞り込むフィルタリング機能で運用の手間を減らせる 詳細な機能や料金は問い合わせが必要

表の内容は比較記事の掲載情報をもとにした概要で、機能や提供条件は時期によって変わります。サーバーが数台で、監視する項目も限られている会社なら、OSやクラウドに標準で備わっている監視機能とメール通知だけで足りる場合もあります。ツールの導入が向いているのは、冗長化した機器が拠点やクラウドをまたいで増えている、夜間や休日の異常に気づけない、障害のたびに原因の切り分けに時間がかかっているといった状況です。自社がどちらに当たるかを考えながら、比較記事で選び方と導入時の注意点を確認してみてください。

冗長化とは｜システムを止めないために予備を用意する仕組み

冗長化とは、システムの構成要素について同じ役割を持つ予備を用意し、1か所が故障してもシステム全体が動き続けるようにすることです。「冗長」という言葉には本来「無駄が多い」という意味がありますが、ITの世界では、あえて余分を持たせることで止まりにくくするという前向きな意味で使われます。

目的は「可用性」を高めること

冗長化の目的は、システムが使いたいときに使える状態にある度合い、つまり可用性を高めることです。可用性は稼働率で表されることが多く、年間を通じてどれだけ止まらずに動いたかを割合で示します。稼働率の数字は小さな差に見えますが、年間の停止時間に直すと大きく違います。

稼働率 年間の停止時間の目安 イメージ
99% 約87.6時間（約3.7日） 1台構成で、障害時は修理や交換を待つ
99.9% 約8.8時間 主要な機器を冗長化し、切り替えに人の操作が入る
99.99% 約53分 自動で切り替わる構成と、常時の監視体制がある
99.999% 約5分 拠点も含めて多重化し、計画停止もほぼ発生させない

停止時間は「365日×24時間×（1から稼働率を引いた値）」で計算した単純な目安です。イメージの列は一般的な傾向を示したもので、同じ稼働率でも構成の組み方は会社ごとに異なります。社内の会議室予約システムと、24時間受け付けているECサイトの決済とでは、求められる稼働率がまったく違います。すべてを最高水準にする必要はなく、止まったときの損失に見合った水準を選ぶことが出発点です。

「単一障害点」をなくすという考え方

冗長化を考えるうえで鍵になるのが、単一障害点（SPOF：Single Point of Failure）という考え方です。単一障害点とは、そこが壊れるとシステム全体が止まってしまう、代わりのない1か所のことです。サーバーを2台にしても、その2台が同じスイッチ1台につながっていれば、スイッチが単一障害点になります。電源、インターネット回線、DNS、データベース、さらには設定を知っている担当者1人も、単一障害点になり得ます。冗長化の設計は、システムの構成図を見ながら「ここが止まったらどうなるか」を1つずつ確かめ、単一障害点を減らしていく作業だと言えます。

冗長化の対象になる主な要素

冗長化の対象は、サーバーだけではありません。代表的な対象と、よく使われる方法を整理すると次のとおりです。

対象 止まると起きること 代表的な冗長化の方法
サーバー 業務アプリやWebサイトが使えなくなる 複数台構成、ロードバランサーによる振り分け、クラスタリング
ストレージ（ディスク） データが読めなくなる、失われる RAIDによる複数ディスクへの分散・複製、ストレージ間のレプリケーション
ネットワーク 拠点間やインターネットとの通信が途絶える 回線の二重化（別の通信事業者を含む）、ルーターの冗長化プロトコル、リンクアグリゲーション
データベース 登録や検索ができなくなる、整合性が崩れる レプリケーション（複製）、フェイルオーバー構成
電源 停電や瞬断で機器が一斉に停止する UPS（無停電電源装置）、電源ユニットの二重化、別系統からの給電
拠点（データセンター） 地震や水害で設備ごと使えなくなる 離れた地域への待機系の設置、クラウドの複数リージョン・複数ゾーンの利用

ハードウェア、ネットワーク、データ、電源といった層ごとの考え方は、冗長性の4タイプ分類と設計の基礎を解説した記事でも詳しく紹介しています。本記事では、実際に冗長化を進めるときの構成の選び方と運用に焦点を当てます。

冗長化の種類｜アクティブ・スタンバイとアクティブ・アクティブ

冗長化の構成は、本番と予備をどう動かすかによって大きく2つに分かれます。予備を待機させておくアクティブ・スタンバイと、複数台を同時に動かして処理を分け合うアクティブ・アクティブです。データベースなどでは、これに近い考え方としてマスター・スレーブ（プライマリ・レプリカ）という呼び方も使われます。

アクティブ・スタンバイ

アクティブ・スタンバイは、普段は本番機（アクティブ）だけが処理を行い、予備機（スタンバイ）は待機している構成です。本番機に障害が起きると、予備機に処理を引き継ぎます。この切り替えをフェイルオーバー、復旧後に本番機へ戻すことをフェイルバックと呼びます。仕組みが分かりやすく、データの整合性を保ちやすいため、データベースや基幹システムでよく使われます。一方、待機している間の予備機は処理に使われないため、設備の使い方としては効率がよいとは言えません。

アクティブ・スタンバイは、予備機をどのような状態で待機させるかによって、さらに細かく分けられます。

方式 予備機の状態 切り替えにかかる時間 費用・手間
ホットスタンバイ 電源が入り、本番と同じデータを常に同期している 短い（自動で数秒から数分程度の構成が多い） 高い。予備機も常時稼働させるため、電力や保守も本番並みにかかる
ウォームスタンバイ 起動はしているが、データの同期や一部の設定は切り替え時に行う 中程度 中程度
コールドスタンバイ 電源を切った状態、または機器だけを保管している 長い（起動、データの復元、設定に人手がかかる） 低い。ただし手順書と訓練がないと切り替えに失敗しやすい

アクティブ・アクティブ（負荷分散）

アクティブ・アクティブは、複数のサーバーを同時に動かし、処理を分け合う構成です。利用者からのアクセスはロードバランサー（負荷分散装置）が各サーバーに振り分けます。1台が止まっても、残りのサーバーが処理を続けるため、切り替えの待ち時間がほとんど発生しません。すべての機器が普段から処理に使われるので設備の無駄が少なく、アクセスが増えたときにサーバーを足して対応しやすい点も利点です。

注意したいのは、1台が止まったときに残りの台数で処理しきれるかどうかです。2台が普段からそれぞれ70%の負荷で動いていると、1台が止まった瞬間に残りの1台へ140%の負荷がかかり、連鎖的に止まってしまいます。アクティブ・アクティブでは、1台減っても耐えられる余裕を持たせて台数を決めます。必要な台数に1台を足しておく考え方は「N+1構成」と呼ばれます。また、データを書き換える処理を複数台で同時に行うと整合性の管理が難しくなるため、Webサーバーのように状態を持たない層で使われることが多い構成です。

クラスタリングとマスター・スレーブ

クラスタリングは、複数のサーバーを1つのシステムのようにまとめて扱う技術の総称です。障害時に別のサーバーへ処理を引き継ぐHAクラスタ（高可用性クラスタ）はアクティブ・スタンバイの実装方法の1つで、負荷分散クラスタはアクティブ・アクティブの実装方法の1つと考えると整理しやすくなります。マスター・スレーブは、データの更新をマスター側が受け持ち、その内容をスレーブ側に複製しておく構成で、マスターが止まったときはスレーブを昇格させて処理を引き継ぎます。読み取り専用の処理をスレーブに任せて負荷を分けることもできます。

比較の観点 アクティブ・スタンバイ アクティブ・アクティブ
普段の動き 本番機だけが処理し、予備機は待機 全台が同時に処理を分担
障害時 予備機へ切り替える（フェイルオーバー） 残りの台で処理を続ける
長所 仕組みが単純で、データの整合性を保ちやすい 切り替えの待ちがほぼなく、設備を無駄なく使える。拡張しやすい
短所 予備機が普段は遊んでいる。切り替えに時間がかかる場合がある 1台減っても耐えられる余裕が必要。データ更新の整合性管理が難しい
向いている対象 データベース、基幹システム、ファイルサーバー Webサーバー、APIサーバー、アクセスが変動するサービス

冗長化・ミラーリング・バックアップの違い

冗長化と混同されやすいのが、ミラーリングとバックアップです。ミラーリングは、データを書き込むたびにほぼ同時に別の場所にも同じ内容を書き込む方法で、冗長化を実現する手段の1つです。バックアップは、ある時点のデータを定期的にコピーして別の場所に保管しておく方法です。

大きな違いは、守れるものの範囲です。冗長化やミラーリングは機器の故障に強い一方、誤ってファイルを消した、ランサムウェアでデータを暗号化されたといった場合には、その変更までそのまま予備に複製されてしまいます。これを過去の状態に戻せるのはバックアップだけです。逆にバックアップだけでは、復元が終わるまでシステムは止まったままです。冗長化は「止めないため」、バックアップは「元に戻すため」の仕組みであり、どちらか一方で代わりにすることはできません。

冗長化の費用はどこで増えるか

冗長化の費用は、構成する機器の種類、求める稼働率、オンプレミスかクラウドかによって大きく変わるため、一律の相場を示すのは難しいのが実情です。具体的な金額はベンダーや構成ごとに見積もりで確認する必要がありますが、どこで費用が増えるのかという構造を押さえておくと、見積もりの比較や社内説明がしやすくなります。

費用の項目 増え方の考え方 見落としやすい点
機器・クラウドの利用料 予備の台数分だけ増える。2台構成なら単純計算で本体の費用はおよそ2倍 ロードバランサーやスイッチなど、冗長化のために追加する周辺機器も二重化が必要になる
ソフトウェアのライセンス 予備機にもライセンスが必要かどうかは製品ごとに異なる 待機系は無償、または割安になる製品もあれば、全台分が必要な製品もある
回線 回線を2本にすれば、月額費用も2本分かかる 同じ通信事業者で2本引くと、事業者側の障害で両方止まることがある
設計・構築 切り替えの仕組み、データの同期方法の設計に専門知識が必要 切り替えのテストまで見積もりに含まれているかを確認する
運用・監視 監視する機器が増えるほど、確認する項目と対応の手間が増える 夜間や休日の対応体制、定期的な切り替え訓練の工数が継続的にかかる

見積もりの段階では機器や利用料に目が行きがちですが、長く使うほど効いてくるのは運用・監視の費用です。冗長化した機器は、片方が壊れてもサービスが止まらない分、故障に気づくのが遅れやすいという性質があります。故障を早く見つけて予備のない状態の期間を短くするためには、監視の仕組みと対応の体制にも予算を割いておく必要があります。

オンプレミスとクラウドでの違い

自社で機器を持つオンプレミスでは、予備機の購入費用が最初にまとまってかかり、設置場所や電源、保守契約も自社で手配します。クラウドでは、サーバーを複数のゾーン（同じ地域内の独立したデータセンター群）に配置する、ロードバランサーのサービスを使うといった形で、比較的少ない手間で冗長化を組めます。費用は使った分だけの月額になり、初期投資を抑えやすい一方、常時2台以上を動かせばその分の利用料が毎月かかります。

クラウドを使う場合でも、すべてを事業者任せにできるわけではありません。事業者が冗長化しているのは主に設備や基盤の部分で、その上に載せるサーバーの台数や配置、データのバックアップは利用者側で設計するのが一般的です。どこまでが事業者の責任範囲かは、サービスの種類によって変わります。IaaS・PaaS・SaaSの違いと関係は、SaaSとクラウドの違いを整理した記事で解説しています。

費用を決める前に考える3つの問い

どこまで冗長化するかは、止まったときの損失と冗長化の費用を比べて決めます。判断のよりどころになるのは、次の3つの問いです。

  1. そのシステムが1時間止まると、売上の機会損失や取引先への影響、残業での挽回といった形で、どれだけの損失が出るか
  2. 止まってから何時間以内に再開できれば許容できるか（目標復旧時間）
  3. 障害が起きたとき、どの時点までのデータが戻れば業務を続けられるか（目標復旧時点）

1時間の停止で大きな損失が出る決済や受注のシステムは、ホットスタンバイやアクティブ・アクティブで手厚く守る価値があります。半日止まっても業務が回る社内向けのシステムなら、コールドスタンバイとバックアップの組み合わせで十分なこともあります。システムごとに守る水準を分けることが、費用を抑えながら効果を出すための近道です。

冗長化とBCP（事業継続計画）の関係

BCP（事業継続計画）とは、自然災害やシステム障害、感染症の流行といった緊急事態が起きても、中核となる事業を続ける、または早く再開するための計画です。中小企業庁の「中小企業BCP策定運用指針」でも、事前の対策として重要な情報のバックアップを取り、オフィス以外の場所にも保管しておくことが挙げられています。冗長化は、このBCPのうち情報システムを止めない、あるいは早く再開させるための技術的な手段にあたります。

機器の故障と災害では、守り方が違う

同じ建物の同じラックにサーバーを2台並べる冗長化は、機器1台の故障には強いものの、建物ごと停電したり浸水したりする災害には対応できません。災害まで想定するなら、離れた地域に待機系を置く、クラウドの別リージョンにデータを複製するといった、拠点の冗長化が必要になります。どこまでの事態を想定するかによって、必要な冗長化の範囲と費用は大きく変わります。

想定する事態 有効な冗長化 併せて必要な備え
機器1台の故障 サーバー・ディスク・電源ユニットの二重化 故障を検知する監視、交換部品の手配手順
回線や通信事業者の障害 別の通信事業者を含む回線の二重化 切り替えの手順と、切り替わったことの通知
建物の停電・浸水・地震 離れた拠点やクラウドの別リージョンへの待機系の配置 拠点を切り替える判断基準と、担当者の連絡手段
誤操作・ランサムウェア 冗長化だけでは防げない 世代管理したバックアップ、ネットワークから切り離した保管

非機能要件として冗長化の水準を決める

システムを新しく作ったり、ベンダーに構築を頼んだりする場合、冗長化の水準は「非機能要件」として発注側が決めておく必要があります。独立行政法人情報処理推進機構（IPA）が公開している「非機能要求グレード」では、非機能要件を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分け、可用性の中で継続性、耐障害性、災害対策、回復性といった項目を整理しています。こうした枠組みに沿って「どの機器を、どの水準で冗長化するか」を事前に決めておくと、ベンダーとの認識のずれを防げます。

BCPの観点で見落とされやすいのが、冗長化した仕組みを実際に動かす人と手順です。障害が起きた夜間に、誰が異常に気づき、誰が切り替えを判断し、復旧後に誰が本番機へ戻すのか。ここが決まっていないと、仕組みとしては冗長化されていても、事業の継続にはつながりません。稼働状況の監視や異常の通知、定型作業の自動化をまとめて扱える統合運用管理ツールは、少ない人数でこの体制を回すための選択肢になります。

冗長化を進める手順

冗長化は、機器を買い足すことから始めるのではなく、守る対象と水準を決めるところから始めます。一般的な進め方は次のとおりです。

  1. 業務で使っているシステムを洗い出し、止まったときの影響の大きさで優先順位をつける
  2. 優先度の高いシステムについて、目標復旧時間と目標復旧時点を決める
  3. 構成図を見ながら単一障害点を洗い出し、どこを冗長化するかを決める
  4. アクティブ・スタンバイかアクティブ・アクティブか、ホットかコールドかといった方式を選ぶ
  5. 監視の項目、異常の通知先、切り替えの判断者と手順を決め、手順書にまとめる
  6. 構築後に実際に本番機を止めて、予備に切り替わることを確認する
  7. 年に1回以上など頻度を決めて切り替え訓練を行い、構成の変更に合わせて手順書を更新する

迷ったときは、影響が大きく、構成が比較的単純なサーバーから手をつけるのが現実的です。社内で設計まで担うのが難しい場合は、クラウドサービスやホスティング事業者が用意している冗長化済みの基盤を使うことで、構築と保守の負担を大きく減らせます。

冗長化導入でよくある失敗パターン

冗長化は「導入したのに、いざというときに役に立たなかった」という失敗が起きやすい分野です。よくあるパターンと対策を整理しました。

失敗パターン 何が起きるか 対策
予備に切り替わったことに気づかない 本番機の故障が放置され、予備機1台の状態が続く。次の故障で全面停止する 切り替えや片系の停止を検知して通知する監視を設定し、通知先を複数にする
一度も切り替えを試していない 本番の障害時に、設定の誤りや手順の不備で切り替わらない 構築時と定期的な訓練で、実際に本番機を止めて確認する
一部だけを冗長化している サーバーは2台なのに、スイッチや回線、電源が1つで、そこが止まると全体が止まる 構成図で単一障害点を洗い出し、優先度をつけて順に解消する
1台減ったときの負荷を見込んでいない アクティブ・アクティブで1台が止まると、残りの台に負荷が集中して連鎖的に停止する 1台減っても処理しきれる台数にし、普段の負荷を定期的に確認する
冗長化をバックアップの代わりにしている 誤削除やランサムウェアの被害が予備にも複製され、元に戻せない 世代管理したバックアップを、別の場所に保管する
本番と予備で設定がずれている 本番機だけに更新や設定変更を行い、切り替え後に動作がおかしくなる 変更作業の手順に予備機への反映を含め、変更の記録を残す

表の6つの失敗のうち、多くは「冗長化した後の運用」に原因があります。とくに最初の、予備に切り替わったことに気づかないという失敗は、冗長化がうまく働いたからこそ起きるもので、利用者からの苦情も出ないため発見が遅れがちです。機器ごとにばらばらの監視画面やメールを人が見回る運用では、担当者が少ないほど見落としが増えます。稼働状況とアラートを1か所に集めて確認できる仕組みを整えることが、冗長化を本当に役立てるための前提になります。

よくある質問（FAQ）

Q. 冗長化と二重化は同じ意味ですか？

A. ほぼ同じ意味で使われます。二重化は予備を1つ持って2系統にする場合を指し、冗長化は三重化以上も含めた、予備を持たせること全般を指す言葉として使われるのが一般的です。

Q. 冗長化していればバックアップは不要ですか？

A. 不要ではありません。冗長化は機器の故障でシステムを止めないための仕組みで、誤ってデータを消した場合やランサムウェアの被害は、予備にもそのまま複製されます。過去の状態に戻すには、世代管理したバックアップを別の場所に保管しておく必要があります。

Q. アクティブ・スタンバイとアクティブ・アクティブはどちらを選べばよいですか？

A. データの整合性が重要なデータベースや基幹システムにはアクティブ・スタンバイ、アクセスが多く処理を分け合いたいWebサーバーなどにはアクティブ・アクティブが向いています。1つのシステムの中でも、層によって使い分けるのが一般的です。

Q. 冗長化の費用はどのくらいかかりますか？

A. 構成や求める稼働率によって大きく変わるため、具体的な金額は見積もりで確認が必要です。機器やクラウドの利用料は予備の台数分増え、2台構成なら本体部分はおよそ2倍が目安です。加えて、設計・構築、監視、切り替え訓練といった運用の費用も継続的にかかります。

Q. クラウドを使えば冗長化は不要ですか？

A. 不要にはなりません。クラウド事業者が冗長化しているのは主に設備や基盤の部分で、その上で動かすサーバーの台数や配置、データのバックアップは利用者側で設計するのが一般的です。複数のゾーンに配置するなど、クラウドの機能を使って冗長化を組む必要があります。

Q. 冗長化した後に、運用で気をつけることは何ですか？

A. 予備に切り替わったことや片方の機器の故障に気づける監視を整えること、定期的に切り替えの訓練を行うこと、本番と予備の設定をそろえておくことの3点が基本です。監視する機器が多い場合は、稼働状況とアラートをまとめて確認できる統合運用管理ツールを使うと、少ない人数でも見落としを減らせます。

まとめ

冗長化は、システムの構成要素に予備を持たせ、1か所の故障で全体が止まらないようにする仕組みです。導入を検討するときは、次の3点を押さえておきましょう。

  1. 止まったときの損失から、システムごとに守る水準（稼働率、目標復旧時間、目標復旧時点）を決め、すべてを最高水準にしない
  2. 単一障害点を洗い出し、アクティブ・スタンバイとアクティブ・アクティブ、ホットとコールドを対象に合わせて使い分ける。バックアップは冗長化とは別に用意する
  3. 予備への切り替えに気づける監視と、定期的な切り替え訓練までを含めて冗長化と考え、必要に応じて統合運用管理ツールで運用の負担を減らす

冗長化の効果は、障害が起きたその日に初めて試されます。仕組みを用意するだけでなく、それが正しく働き続けているかを確かめる運用までを含めて計画してください。

参考文献

この記事に興味を持った方におすすめ

同じカテゴリの記事を探す

同じタグの記事を探す

同じタグの記事はありません

掲載希望の方はこちら
top