冗長性とは？ITでの意味とバックアップとの違い、設計パターンと稼働率の考え方

冗長性（じょうちょうせい）とは、システムの一部が故障しても全体の機能を維持できるように、構成要素を重複して持たせている性質のことです。英語ではRedundancy（リダンダンシー）と呼ばれ、冗長性を持たせるための取り組みを冗長化といいます。「冗長性が高い」とは、予備や切り替えの仕組みが整っていて止まりにくい状態のことです。ただし、サーバーを2台に増やしても、片方の故障に気づかなければ予備のない状態で動き続けることになります。本記事では、意味と読み方、冗長化・二重化・バックアップとの違い、設計パターン、稼働率から考えるコスト、運用でよくある失敗までを順に解説します。

目次

開く

閉じる

1. 冗長性があるのに止まるのはなぜか｜故障に気づく運用が冗長性を支える
2. 冗長性とは｜ITにおける意味と関連用語の違い
3. 冗長性が必要とされる場面と優先順位の付け方
4. 冗長性の設計パターン
5. 冗長化のコストとトレードオフ｜稼働率から考える
6. 冗長化の導入・運用でよくある失敗パターン
7. よくある質問(FAQ)
8. まとめ
9. 参考文献

冗長性があるのに止まるのはなぜか｜故障に気づく運用が冗長性を支える

冗長性があるのに止まるのは、片方の故障に利用者も担当者も気づかないまま予備のない状態で動き続け、次の故障で全体が止まるためです。

冗長構成の強みは「片方が壊れても動き続けること」ですが、裏を返せば、片方が壊れても利用者からは異常が見えません。冗長性は、構成を組んだ時点で完成するのではなく、故障を検知して元の状態に戻すまでの運用を含めて初めて意味を持ちます。機器の台数が増えるほど、一つひとつの管理画面を人が見て回る運用には限界があり、とくに夜間や休日は、異常に気づく人も対応する人も限られます。AWSなどのクラウド上でシステムを動かしている場合は、監視と障害対応を外部の専門チームに任せる方法もあります。ここでは、AWS上で冗長構成を運用する場合の選択肢を、役割の違いがわかるように2つ並べました。

AWS上で冗長構成を動かしていて、夜間や休日に片方の機器が止まったときの対応を自社だけで抱えるのが難しい場合の一例が、AWS監視・運用 マネージドクラウド for AWSです。商品ページによると、24時間365日の有人監視体制で、AWSアドバンストティアパートナーの専任チームが運用設計と監視、障害対応を担当します。専任のアカウントSEによる技術支援（プレミアムサポート）はオプションで、利用途中からも申し込めます。注意したいのは、プランごとに最低利用期間が設けられていることと、運用設計や運用フローの構築があるため申し込みから利用開始までに期間がかかる点です。料金はプランによって異なるため、資料や公式サイトで確認してください。

以前の体制では3ヶ月に一度は何かしらのトラブルが発生していたのですが、GMO-GSHD社との取り組みで目に見えてサーバートラブルはなくなりました。

出典：HACラボ株式会社の導入事例（CloudCREW）

冗長構成をAWS上に組むと、使う資源が増える分だけ利用料も増えます。AWSは従量課金制のため、請求金額の見通しや構成の見直しを相談できる窓口がほしい場合の一例が、CloudCREW AWS請求代行です。商品ページによると、AWSの利用料を円建ての請求書（月末締めで毎月メール送付、支払いは銀行振込）で支払えるほか、AWS認定資格者によるアセスメント支援や、請求金額や契約情報を確認できる管理画面「クラウドポータル」が用意されています。請求代行以外の「AWS監視・運用」などは有料オプションです。注意したいのは、固定のプランがなく個別の契約になることと、基本サービスのみの利用でも与信審査があり、利用開始まで1か月以上かかる場合がある点です。料金は契約内容によって異なるため、資料や公式サイトで確認してください。

AWS請求代行サービスによってAWS利用料のコストを大きく抑えることができ、取り組み当初に抱えていた最も大きな課題を解決できています。

出典：株式会社パムの導入事例（CloudCREW）

冗長性とは｜ITにおける意味と関連用語の違い

ITにおける冗長性とは、システムの構成要素を必要最小限より多く持たせ、一部が故障しても全体の機能を保てる性質を指します。冗長性を持たせる作業や構成のことを冗長化、冗長化した構成を冗長構成と呼びます。

冗長性の読み方と「冗長性がある」「冗長性が高い」の意味

冗長性は「じょうちょうせい」、冗長は「じょうちょう」と読みます。「助長（じょちょう）」とは別の言葉で、「助長性」「几長性」と入力や変換を誤らないよう注意が必要です。

ITで「冗長性がある」と言うときは、予備の機器や経路、切り替えの仕組みを備えていて、一部が故障してもサービスを続けられる状態を指します。「冗長性が高い」は、その備えが手厚い状態のことで、たとえば予備の数が多い、故障時に自動で切り替わる、電源や回線まで二重になっている、といった場合です。反対に「冗長性が低い」とは、1か所が壊れるだけで全体が止まる単一障害点が残っている状態です。台数が多いことと冗長性が高いことは同じではなく、台数が多くても全台が同じ電源や同じスイッチにつながっていれば、その1か所が弱点になります。

日常語の「冗長」とは評価が正反対

文章や会話で「冗長だ」と言うと、無駄が多く長たらしいという否定的な意味になります。一方、ITやインフラの分野では、あえて無駄に見える予備を持たせることで止まりにくくするという、肯定的な意味で使われます。同じ言葉でも、システムの話では「余裕がある」「備えがある」と読み替えると理解しやすくなります。通信の分野では、誤りを検出するためにデータに付け加える余分な情報も冗長性と呼ばれます。反対にデータ圧縮では、重複した余分な部分を取り除くことが目的になります。日常語の「冗長」の意味や冗長な文章の直し方は、別の記事「冗長とは？意味と冗長表現の直し方」で解説しています。

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

冗長化と混同されやすい言葉に、二重化、バックアップ、ミラーリングがあります。いずれも障害への備えですが、目的と復旧までの速さが異なります。あわせて、冗長構成の切り替えで使われるフェイルオーバーとフェイルバックも整理しておきます。

特に注意したいのが、冗長化とバックアップの関係です。ミラーリングのようにリアルタイムで同期する冗長構成では、誤ってデータを削除した操作や、ランサムウェアによる暗号化もそのまま予備側に反映されます。冗長化は「機器が壊れたとき」に強く、バックアップは「データが壊れたとき」に強いという役割分担があるため、どちらか一方で代用することはできません。

冗長性と可用性の関係

冗長性とセットで語られるのが可用性（Availability）です。可用性とは、システムを使いたいときに使える状態にある度合いのことで、稼働率という数値で表されることが一般的です。冗長性は可用性を高めるための手段の一つであり、目的ではありません。情報処理推進機構（IPA）の「非機能要求グレード」は、システムの発注側とつくる側が非機能要求について認識の行き違いを起こさないよう、項目を網羅的にリストアップし、要求レベルを段階的に示したものです。どの程度止まらないことを求めるのかも、こうした非機能要求として事前にすり合わせておく必要があります。

ITの外でも使われる冗長性｜電気回路や機械の安全制御

冗長性（重複性）という考え方は、ITだけでなく、機械や設備の安全制御でも使われます。オムロンの用語集では、部分的または全体的に重複を備えることで、電気回路の1つの故障が危険を生じる確率を最小限にできると説明されています。たとえば2個以上のリレーやスイッチを組み合わせ、1つが故障してももう片方が全体の機能を代行できる回路が例に挙げられています。「壊れる前提で、代わりを用意しておく」という発想は、サーバーの冗長化と共通です。

冗長性が必要とされる場面と優先順位の付け方

冗長性はあればあるほど安心ですが、すべてのシステムを二重、三重にすると費用も管理の手間も膨らみます。重要なのは、止まったときの影響が大きい部分から順に冗長性を持たせることです。

単一障害点を洗い出す

冗長化を考える出発点は、単一障害点（SPOF：Single Point of Failure）の洗い出しです。単一障害点とは、そこが1か所壊れるだけでシステム全体が止まってしまう部分のことです。サーバーを2台に増やしても、その2台が同じネットワークスイッチ1台につながっていれば、スイッチが単一障害点になります。電源、回線、データベース、認証の仕組み、さらには「その設定を理解している担当者が1人しかいない」という人の問題も単一障害点になり得ます。

洗い出しの方法としては、利用者がシステムを使うときにデータが通る経路を、端末から順に書き出していくのが分かりやすいでしょう。端末、社内ネットワーク、インターネット回線、ファイアウォール、Webサーバー、アプリケーション、データベース、ストレージと並べ、それぞれが1台しかないか、止まったら何が起きるかを確認していきます。

業務への影響で優先度を決める

単一障害点が見つかったら、そこが止まったときに業務がどれだけ止まるかで優先度を付けます。企業の規模よりも、止まったときの影響で判断するのが基本です。目安として、次のような整理ができます。

同じ種類のシステムでも、企業によって優先度は変わります。たとえば勤怠管理は多くの企業で中程度ですが、シフト制で毎日の打刻が給与計算に直結する業種では高くなることもあります。中小企業でも、決済や受発注のように止まると売上や信用に直結するシステムは優先して検討する価値があり、影響が小さいシステムは、バックアップと復旧手順の整備にとどめるという判断も合理的です。内閣府の事業継続ガイドラインでも、重要な業務を絞り込み、その継続に必要な資源を洗い出すことが事業継続計画（BCP）の基本とされています。システムの冗長化も、この考え方の一部として位置づけると、経営層への説明がしやすくなります。

冗長性が求められる代表的な場面

• 24時間止められないサービス：ECサイトや予約システムなど、夜間や休日も利用者がいるもの
• アクセスが集中するサービス：キャンペーンや繁忙期に負荷が急増し、1台では処理しきれないもの
• 法令や契約で稼働が求められるもの：取引先とサービス水準（SLA）を約束しているシステム
• 自然災害に備えたいもの：拠点が1か所に集中しており、地震や停電で全滅するおそれがあるもの

拠点そのものが使えなくなる事態への備えは、機器の冗長化だけでなく、BCPや災害復旧（DR）の一部として考えます。冗長化とBCPの関係は、別の記事「冗長化とは？仕組み・種類・費用の考え方とBCPとの関係をわかりやすく解説」で詳しく扱っています。

止められないサービスほど、冗長構成の片方が止まったことに、夜間や休日でも気づける体制が必要になります。AWS上で動かしている場合は、監視と障害対応を24時間365日の有人体制で任せられるサービスもあります。

冗長性の設計パターン

冗長化の方式は、予備をどのような状態で待たせるかという「稼働方式」と、どの部分を冗長化するかという「対象」の2つの軸で整理できます。

稼働方式による分類

データベースでは、書き込みを受け付ける機器（プライマリ、マスターとも呼ばれます）と、そのコピーを持つ機器（レプリカ、スレーブとも呼ばれます）に役割を分ける構成もよく使われます。参照の処理をレプリカに任せることで負荷を分散しつつ、プライマリが止まったときにはレプリカを昇格させて処理を引き継ぎます。複数の機器がそれぞれ書き込みを受け付けるマルチマスター構成もあり、予備側も稼働しているため止まりにくい一方、書き込みの衝突を調整する設計が必要になります。

対象による分類

冗長化はサーバーだけの話ではありません。データが通る経路のどこか1か所でも単一障害点が残っていれば、そこで全体が止まります。主な対象と代表的な技術は次のとおりです。

クラウドサービスを利用している場合、物理的な機器の冗長化は事業者側で行われていることが多いものの、その上に構築したサーバーやデータベースを複数の拠点に分散させるかどうかは、利用者側の設計に委ねられているのが一般的です。AWSでも、事業者と利用者の責任の分担は「責任共有モデル」として説明されており、利用者の責任は選んだサービスによって異なります。「クラウドだから止まらない」と考えず、どこまでが事業者の責任で、どこからが自社の設計範囲かを確認しておく必要があります。

冗長化のコストとトレードオフ｜稼働率から考える

冗長化にどこまで投資するかを判断するには、稼働率を年間の停止時間に置き換えて考えると分かりやすくなります。稼働率は小数点以下の数字が1桁違うだけで、許容される停止時間が大きく変わります。

上の表は、1年を8,760時間として、稼働率から逆算した停止時間です。計画的なメンテナンスによる停止を含めるかどうかで、実際の目標値の意味は変わります。

並列にすると稼働率はどう変わるか

稼働率99％の機器を1台で使う場合、停止する確率は1％です。同じ機器を2台並べて、どちらか1台が動いていればよい構成にすると、両方が同時に止まる確率は1％の1％にあたる0.01％になり、理論上の稼働率は99.99％まで上がります。これが冗長化によって可用性が高まる基本的な理屈です。並列にした台数と理論上の稼働率は、「1 – (1 – 1台の稼働率)の台数乗」で計算でき、次のようになります。

この表は、機器が互いに無関係に故障するという前提の理論値です。台数を増やすほど数字は伸びますが、実際には次に説明する共通の原因で同時に止まることがあり、費用と管理の手間は台数に応じて増えます。

反対に、Webサーバー、アプリケーションサーバー、データベースのように、すべてが動いていないと成り立たない機器を直列につなぐと、全体の稼働率は掛け算で下がります。稼働率99％の機器を3つ直列につなぐと、全体はおよそ97％になります。冗長化を考えるときは、個々の機器の稼働率だけでなく、直列につながる部分の数にも目を向けることが大切です。

理論値どおりにならない理由

並列の計算は「2台が互いに無関係に故障する」ことを前提にしています。実際には、同じ電源や同じ空調に依存している、同じ製造時期の部品を使っている、同じソフトウェアの不具合を抱えているといった理由で、2台が同時に止まることがあります。こうした共通の原因による故障は、台数を増やすだけでは防げません。電源の系統を分ける、設置場所を分ける、更新のタイミングをずらすといった工夫で、故障の原因そのものを分散させる必要があります。

また、切り替えを担う仕組み自体が新たな故障点になることもあります。ロードバランサーが1台しかなければ、それが単一障害点です。冗長化によって構成が複雑になると、設定の誤りや切り替えの失敗といった、新しい種類の障害も生まれます。

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

費用の内訳と判断の考え方

冗長化の費用には、機器やクラウドの利用料が増える分だけでなく、設計と構築の工数、監視の手間、定期的な切り替えテスト、保守契約の追加などが含まれます。判断の目安としては、1時間止まったときの損失（売上の機会損失、対応にかかる人件費、取引先への補償など）を見積もり、年間の想定停止時間を減らすことで防げる損失と、冗長化にかかる年間の費用を比べる方法があります。損失が小さいシステムでは、冗長化よりも、バックアップと復旧手順の整備にとどめるという選択も合理的です。

クラウド上で冗長化する場合は、機器を購入する代わりに、使う台数や拠点が増えた分だけ利用料が積み上がります。構成を厚くするほど利用料が増えるため、請求金額の見通しと、構成が信頼性や費用の面で適切かの見直しを、第三者の専門家に相談できる窓口があると判断しやすくなります。

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

冗長構成は、つくった後の運用で効果が大きく変わります。次のような失敗は、規模を問わず起こりやすいものです。

これらの失敗に共通するのは、「冗長構成をつくったこと」で安心してしまい、その後の状態を誰も見ていないという点です。とくに片系の故障は、冗長化しているからこそ見えにくくなる障害です。機器の台数が増えるほど、一つひとつの管理画面を人が確認して回る運用には限界があります。監視、障害の通知、対応履歴の記録を一つの仕組みにまとめておけば、少人数の情報システム部門でも、夜間や休日を含めて冗長構成の状態を把握しやすくなります。

自社で監視の仕組みを持つか、24時間の監視を外部に任せるかは、障害発生時に誰が気づき、誰が判断し、誰が復旧作業をするのかを整理してから決めます。この確認作業を毎回手作業や担当者の記憶に頼っているなら、見直しの余地があります。次のセルフチェックで、いまの運用の抜けを確認してみてください。

よくある質問(FAQ)

Q1. 「冗長性」の読み方は？

A. 「じょうちょうせい」と読みます。「冗長」は「じょうちょう」で、英語ではRedundancy（リダンダンシー）です。「助長（じょちょう）」とは別の言葉なので、「助長性」と書き間違えないよう注意してください。

Q2. 「冗長性がある」「冗長性が高い」とはどういう意味ですか？

A. ITでは、予備の機器や経路、切り替えの仕組みを備えていて、一部が故障してもサービスを続けられる状態を「冗長性がある」といいます。「冗長性が高い」は、その備えが手厚く、故障時に自動で切り替わるなど止まりにくい状態のことです。台数が多いだけでは高いとはいえず、共通の弱点が残っていないかも見る必要があります。

Q3. 冗長性と冗長化、二重化は何が違いますか？

A. 冗長性は、一部が故障しても機能を保てる性質のことです。冗長化は、その冗長性を持たせるために予備の機器や経路を用意する取り組みを指します。二重化は同じ機能を2系統で持つことで、冗長化の一種です。冗長化には三重化や、必要台数に予備を1台加えるN+1構成なども含まれます。

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

A. 不要ではありません。冗長化は機器の故障に備える仕組みで、リアルタイムで同期する構成では誤削除やランサムウェアによる暗号化も予備側に反映されます。過去の時点にデータを戻すためには、冗長化とは別に、世代管理されたバックアップを取っておく必要があります。

Q5. クラウドを使えば冗長性は確保されますか？

A. 物理的な機器の冗長化は事業者側で行われていることが多いものの、その上に構築したサーバーやデータベースを複数の拠点に分散させるかどうかは、利用者側の設計に委ねられているのが一般的です。契約しているサービスの責任範囲と、提示されている稼働率の条件を確認しておきましょう。

Q6. 冗長構成の片方が故障したことにはどうやって気づけますか？

A. 冗長構成では片方が止まっても利用者からは正常に見えるため、監視の仕組みが欠かせません。両系の稼働状態を監視し、異常があれば担当者に通知が届くように設定します。夜間や休日の対応が難しい場合は、監視と障害対応を外部の専門チームに任せる方法もあります。

まとめ

冗長性とは、構成要素を重複して持たせ、一部が故障しても全体の機能を保てる性質のことです。冗長性を活かすために押さえておきたいことは次の6つです。

1. 冗長化は機器の故障に、バックアップはデータの破損に備える仕組みで、両方が必要になる
2. データが通る経路を端から端まで確認し、単一障害点を洗い出す
3. 止まったときの業務への影響で優先度を決め、重要なシステムから冗長化する
4. 稼働率を年間の停止時間に置き換え、損失と費用を比べて投資の範囲を決める
5. 片系の故障を検知する監視と、定期的な切り替えテストまで含めて運用を設計する
6. AWS上で動かしている場合は、夜間や休日の監視と障害対応を外部に任せる選択肢も、資料で確認して検討する

冗長構成は、つくった時点ではなく、故障に気づいて元の状態に戻せたときに初めて役に立ちます。設計とあわせて、監視と運用の体制まで見直していきましょう。

参考文献

• 独立行政法人情報処理推進機構（IPA）「システム構築の上流工程強化（非機能要求グレード）紹介ページ」https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• 内閣府 防災担当「事業継続ガイドライン あらゆる危機的事象を乗り越えるための戦略と対応（令和5年3月）」https://www.bousai.go.jp/kyoiku/kigyou/pdf/guideline202303.pdf
• オムロン制御機器「冗長性(セーフティコンポーネント用語集)」https://faq.fa.omron.co.jp/tech/s/article/faq02367
• Amazon Web Services「責任共有モデル」https://aws.amazon.com/jp/compliance/shared-responsibility-model/