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

冗長化（じょうちょうか）とは、システムを構成する機器や回線、データに同じ役割の予備を用意し、1か所が故障してもサービスを止めずに動かし続けるための仕組みです。「冗長」は日常では「無駄が多い」という否定的な意味で使われますが、システムの世界では、あえて余裕を持たせて止まりにくくするという前向きな意味になります。

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

目次

開く

閉じる

1. 冗長化したのに止まる？ 予備を用意したあとの運用で差がつく理由
2. 冗長化とは｜意味・読み方と、目的は可用性を高めること
3. 冗長化のメリットとデメリット
4. 冗長化の種類｜アクティブ・スタンバイとアクティブ・アクティブ
5. 冗長化の費用はどこで増えるか
6. 冗長化とBCP（事業継続計画）の関係
7. 冗長化を進める手順
8. 冗長化導入でよくある失敗パターン
9. よくある質問(FAQ)
10. まとめ
11. 参考文献

冗長化したのに止まる？ 予備を用意したあとの運用で差がつく理由

冗長化とは、片方が壊れても残りで動き続けられる状態をつくることです。ただし、二重にした時点で終わりではありません。本番機が壊れて予備に切り替わっても、利用者からは普段どおりに見えるため、誰も気づかないまま予備1台で動き続け、次の故障で全面停止するという事態が起こります。冗長化の効果は、構成そのものより、片系の故障や切り替わりに気づける運用があるかどうかで決まります。

監視を自社で担う場合は、夜間や休日の当番、通知先の整備、定期的な切り替え訓練が必要です。人手が足りない会社では、24時間の監視体制を持つ外部サービスに任せる選択肢もあります。AWSなどのクラウド上で冗長構成を組んでいるなら、監視と運用の代行、そしてAWS利用料の支払い管理を担うサービスが候補になります。下の表は、自社で扱う商品ページの内容から、役割の違いを整理したものです。

AWS上で冗長構成を組んでいる会社の運用面の一例が、AWS監視・運用 マネージドクラウド for AWSです。商品ページによると、AWSの運用保守と監視・障害対応を代行するサービスで、24時間365日の有人監視体制をとり、監視ツールはAmazon CloudWatch、Zabbix、Mackerelから選べます。夜間や休日の対応も可能とされているため、片系の故障に夜間に気づけないという課題の受け皿になります。一方で、障害発生時の一次対応は手順書に沿った復旧が基本で、自社の要件に合わせるにはオプションの確認が必要です。対象はAWS環境なので、オンプレミス中心の会社は、自社の構成が対象になるかを資料で確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

3ヶ月に一度は発生していたサーバートラブルがほぼゼロに

出典: HACラボ株式会社の導入事例（CloudCREW公式サイト。マネージドクラウド for AWSの導入による成果の見出し）

冗長化とは｜意味・読み方と、目的は可用性を高めること

冗長化とは、システムの構成要素について同じ役割を持つ予備を用意し、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か所のことです。IPAの「高回復力システム基盤導入ガイド 計画編」でも、システムを構成する機器や部位には単一障害点が多数あり、これを許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目になると説明されています。サーバーを2台にしても、その2台が同じスイッチ1台につながっていれば、スイッチが単一障害点になります。電源、インターネット回線、DNS、データベース、さらには設定を知っている担当者1人も、単一障害点になり得ます。冗長化の設計は、構成図を見ながら「ここが止まったらどうなるか」を1つずつ確かめ、単一障害点を減らしていく作業です。

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

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

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

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

冗長化と二重化は何が違うのか

二重化は、予備を1つ持って2系統にすることを指します。冗長化は、三重化以上や、予備の台数を変えるN+1構成まで含めた、予備を持たせること全般を指す言葉として使われるのが一般的です。ただし、現場では同じ意味で使われることも多く、見積書や提案書では、予備の数と切り替え方法まで具体的に書かれているかを確認すると誤解を防げます。

冗長化のメリットとデメリット

冗長化のメリットは、故障による停止時間を短くでき、事業の継続性を高められることです。デメリットは、予備の分だけ費用が増え、構成が複雑になって運用の手間も増えることです。両方を把握したうえで、守る対象を絞って導入するのが現実的です。

区分	内容	注意したい点
メリット1：停止時間の短縮	故障した機器を予備に切り替え、サービスを続けながら復旧できる	切り替わる仕組みが正しく動くかを、事前に試しておく必要がある
メリット2：保守・更新のしやすさ	片方を止めて部品交換やソフトの更新をしても、もう一方でサービスを続けやすい	作業中は予備のない状態になるため、作業時間と手順を決めておく
メリット3：負荷の分散	アクティブ・アクティブ構成なら、アクセスが集中しても複数台で処理を分け合える	1台減ったときの残りの台数で処理しきれるかを見込む
デメリット1：費用の増加	予備の機器やクラウドの利用料、ライセンス、保守費が増える	止まったときの損失と比べて、守る水準を決める
デメリット2：運用の手間	本番と予備の設定をそろえ、データの同期や監視を続ける必要がある	監視する機器が増えるほど、見落としが起きやすくなる
デメリット3：設計の難しさ	サーバー、ネットワーク、データの同期方式を合わせて設計する必要がある	一部だけの冗長化では、残った単一障害点で止まる

デメリットを避けようとして冗長化を見送るのではなく、止まったときの影響が大きいシステムから優先して取り組むのが基本です。受発注や決済、顧客に公開しているWebサイトのように、止まると売上や信用に直結するシステムが優先度の高い対象になります。

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

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

アクティブ・スタンバイ

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

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

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

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

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

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

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

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

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

ネットワークとストレージで使われる主な技術

構成の考え方を実際に形にするときは、対象ごとに決まった技術を組み合わせます。提案書に出てくる用語を、役割で整理しておきましょう。

技術	守る対象	役割
RAID	ディスク	複数のディスクにデータを分散・複製し、1本が壊れてもデータを読めるようにする。サーバー全体の冗長化ではない点に注意する
ロードバランサー	サーバーへのアクセス	アクセスを複数のサーバーに振り分け、止まったサーバーを切り離す
レプリケーション	データベース・ストレージ	データを別のサーバーや拠点へ複製し、片方の障害に備える
VRRP	ルーター（ゲートウェイ）	複数のルーターで1つの仮想的なルーターとして振る舞い、障害時に引き継ぐ
リンクアグリゲーション・チーミング	回線・ネットワークカード	複数の回線やネットワークカードを束ねて1つのように扱い、1本が切れても通信を続ける

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

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

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

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

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

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

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

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

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

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

AWSで複数台構成にすると、台数が増えた月は請求額も増えます。そうした利用料の支払いを整理する手段の一例が、CloudCREW AWS請求代行です。商品ページによると、AWSの利用料を円建ての請求書で支払えるサービスで、初期費用や手数料が無料とされ、障害・停止や不正アクセスなどで生じた損害を補償する保険が標準で付帯します。注意点として、監視や運用のサービスを使いたい場合は有料オプションの扱いになります。対象はAWSの利用料なので、AWS以外のクラウドを使う場合は対象外になる点も確認が必要です。料金はプランによって異なるため、資料や公式サイトで確認してください。

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

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

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

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

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

BCP（Business Continuity Plan、事業継続計画）とは、自然災害や大火災などの緊急事態に備え、中核となる事業を続ける、または早く再開するための企業の危機管理の手法です。中小企業庁は「中小企業BCP策定運用指針」を公開し、被害を受けてから対応するのではなく、事前の備えをしておくことが最も効果的な災害対策だと述べています。冗長化は、このBCPのうち情報システムを止めない、あるいは早く再開させるための技術的な手段にあたります。

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

同じ建物の同じラックにサーバーを2台並べる冗長化は、機器1台の故障には強いものの、建物ごと停電したり浸水したりする災害には対応できません。IPAの「高回復力システム基盤導入ガイド 計画編」も、サーバーやネットワーク機器のコンポーネントを冗長化することは機器単体の耐障害性を高めるうえで有効だが、大規模災害からの回復力向上には大きく寄与しないとしています。災害まで想定するなら、離れた地域に待機系を置く、クラウドの別リージョンにデータを複製するといった、拠点の冗長化が必要になります。どこまでの事態を想定するかによって、必要な冗長化の範囲と費用は大きく変わります。

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

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

システムを新しく作ったり、ベンダーに構築を頼んだりする場合、冗長化の水準は「非機能要件」として発注側が決めておく必要があります。IPAの非機能要求グレードに沿った上記ガイドでは、可用性の中に継続性、耐障害性、災害対策といった項目が整理され、目標復旧時点（RPO）、目標復旧時間（RTO）、目標復旧レベル（RLO）といった目標も要件として扱われています。こうした枠組みに沿って「どの機器を、どの水準で冗長化するか」を事前に決めておくと、ベンダーとの認識のずれを防げます。

BCPの観点で見落とされやすいのが、冗長化した仕組みを実際に動かす人と手順です。障害が起きた夜間に、誰が異常に気づき、誰が切り替えを判断し、復旧後に誰が本番機へ戻すのか。ここが決まっていないと、仕組みとしては冗長化されていても、事業の継続にはつながりません。

冗長化を進める手順

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

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

迷ったときは、影響が大きく、構成が比較的単純なサーバーから手をつけるのが現実的です。社内で設計まで担うのが難しい場合は、クラウドサービスやホスティング事業者が用意している冗長化済みの基盤を使うことで、構築と保守の負担を大きく減らせます。手順の5番目から7番目にあたる監視と訓練は、構築後に長く続く作業です。自社の今の運用が足りているかを、次のチェックで確かめてみてください。

2サービスの役割を比較表で見る

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

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

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

表の6つの失敗のうち、多くは「冗長化した後の運用」に原因があります。とくに最初の、予備に切り替わったことに気づかないという失敗は、冗長化がうまく働いたからこそ起きるもので、利用者からの苦情も出ないため発見が遅れがちです。機器ごとにばらばらの監視画面やメールを人が見回る運用では、担当者が少ないほど見落としが増えます。AWS上で動かしているシステムであれば、24時間365日の有人監視体制をとる運用・監視の代行サービスに、見回りと一次対応を任せる方法もあります。自社で当番を回す場合と、委託する場合の違いを、資料で比べておくと判断しやすくなります。

よくある質問(FAQ)

Q1. 「冗長化」の読み方は？ 「冗長」は悪い意味ですか？

A. 「冗長化」は「じょうちょうか」、「冗長」は「じょうちょう」と読みます。日常の文章では「無駄が多い」という否定的な意味で使われますが、ITの冗長化は、故障に備えてあえて予備を持たせるという前向きな意味です。

Q2. ビジネスにおける冗長化とは何ですか？

A. 業務を止めないために、止まると影響の大きい箇所へ予備を用意しておくことを指します。ITの現場ではサーバーや回線、電源、データの二重化を指すのが一般的で、システムの話では、予備を持たせて可用性を高めるための設計だと考えると分かりやすくなります。

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

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

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

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

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

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

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

A. 予備に切り替わったことや片方の機器の故障に気づける監視を整えること、定期的に切り替えの訓練を行うこと、本番と予備の設定をそろえておくことの3点が基本です。AWS上のシステムで夜間・休日の対応に人手を割けない場合は、24時間365日の有人監視体制をとる運用・監視の代行サービスを比べてみる方法もあります。

まとめ

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

1. 止まったときの損失から、システムごとに守る水準（稼働率、目標復旧時間、目標復旧時点）を決め、すべてを最高水準にしない
2. 単一障害点を洗い出し、アクティブ・スタンバイとアクティブ・アクティブ、ホットとコールドを対象に合わせて使い分ける。バックアップは冗長化とは別に用意する
3. 予備への切り替えに気づける監視と、定期的な切り替え訓練までを含めて冗長化と考える
4. 夜間・休日の監視に人手を割けない場合は、AWS監視・運用 マネージドクラウド for AWSやCloudCREW AWS請求代行のようなサービスの資料を取り寄せ、自社の運用体制と比べて検討する

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

参考文献

• 中小企業庁「中小企業BCP策定運用指針 公開にあたって」https://www.chusho.meti.go.jp/bcp/contents/level_c/bcpgl_00.html
• 独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）紹介ページ」https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• 独立行政法人情報処理推進機構（IPA）「高回復力システム基盤導入ガイド 計画編」（2012年5月）https://www.ipa.go.jp/archive/files/000004632.pdf
• GMOグローバルサイン・ホールディングス株式会社 CloudCREW byGMO「HACラボ株式会社様事例」https://managed.gmocloud.com/case/hac-lab.html