冗長性とは｜4タイプ分類と設計基礎

「冗長性」と「冗長化」は似た言葉ですが、指しているものが異なります。冗長性は予備リソースを備えた状態を指す言葉で、冗長化はその状態を作り出す行為・設計手法を指す言葉です。本記事では、冗長性という状態が「なぜ必要か」「どこに備えるべきか」という設計思想の側面から解説します。Active-Standby型・同時稼働型といった具体的な実現方法や切り替え時の実務ポイントは、冗長化とは｜仕組みと2つの種類で詳しく扱っています。

目次

開く

閉じる

1. 冗長性とは(バックアップとの違い)
2. 冗長性の4タイプ分類
3. なぜ・どこに冗長性が必要か(業界別の可用性要件)
4. 冗長性の水準をどう判断するか
5. 導入コストの考え方
6. 冗長性設計でよくある失敗パターン3つ
7. 冗長性は構築して終わりではない(監視・訓練の重要性)
8. クラウドとオンプレミスで冗長性の確保方法はどう変わるか
9. よくある質問(FAQ)
10. まとめ｜今日からできる3つのこと

冗長性とは(バックアップとの違い)

冗長性とは、システムが障害時にも継続稼働できるよう、予備リソースを二重・三重に備えている状態を指す言葉です。単発の障害対応であるバックアップとは異なり、平常時から予備の仕組みを常に備えておく点が特徴です。バックアップは「壊れたら復元する」という事後対応であるのに対し、冗長性は「壊れても止まらない」という事前設計の考え方に基づきます。この違いを理解しないまま設計を進めると、後述する失敗パターンにつながりやすくなります。

冗長性の4タイプ分類

ハードウェア、ネットワーク、データ、電源という4つの層で、冗長性を分類できます。それぞれの層は独立して障害が発生しうるため、1つの層だけを手厚くしても、他の層が単一構成のままではシステム全体の可用性は上がりません。設計時には4層すべてを見渡し、どこにボトルネックが残っているかを確認する視点が欠かせません。

層	主な技術要素
ハードウェア	RAID構成
ネットワーク	複数回線・経路の確保
データ	マルチAZ・マルチリージョン構成
電源	無停電電源装置・複数系統化

ハードウェア層では、サーバーやストレージ機器そのものの故障に備えます。RAID構成によってディスク1台が壊れても稼働を継続できますが、サーバー本体や筐体単位の故障には対応できないため、冗長化構成と組み合わせて検討する必要があります。

ネットワーク層では、回線や通信経路の断絶に備えます。単一の回線・経路しか持たない構成では、その回線が切れた瞬間にシステム全体が外部と通信できなくなるため、複数の通信事業者・複数経路を確保しておくことが基本になります。

データ層では、データそのものの喪失・破損に備えます。クラウド環境であれば、複数のデータセンター(アベイラビリティゾーン)や複数のリージョンにデータを分散配置するマルチAZ・マルチリージョン構成が代表的な手法です。1つのデータセンターが災害等で機能停止しても、他の拠点でデータを保持し続けられます。

電源層では、停電や電力供給の障害に備えます。無停電電源装置(UPS)や自家発電設備、電力供給経路の複数系統化などが該当し、他の3層がどれだけ冗長化されていても、電源が単一系統のままでは全体が停止するリスクを残します。見落とされやすい層である点に注意が必要です。

なぜ・どこに冗長性が必要か(業界別の可用性要件)

4層のどこに重点的に投資するかは、業界特性に応じて求められる可用性の水準によって変わります。金融・医療業界は99.999%といった高い可用性が求められる一方、製造業・小売業・物流業でも業種に応じた水準が必要とされています。可用性要件を数値で確認しないまま設計を始めると、必要な層への投資が不足したり、逆に不要な層まで過剰に冗長化してコストを膨らませたりする結果になりかねません。

金融機関ではシステム停止が直接の経営リスクや顧客への影響につながるため、4層すべてで高水準の冗長性を確保するのが一般的です。医療機関では診療データへの継続的なアクセスが患者の安全に関わるため、特にデータ層の可用性が重視されます。製造業では生産ラインの制御システムが止まると生産そのものが止まるため、ハードウェア層・電源層の冗長性が重要になるなど、業界ごとに優先すべき層の傾向が異なります。自社が置かれている業界・業務特性を踏まえて、4層のうちどこから着手するかを判断することが、設計段階での実践的なアプローチです。

冗長性の水準をどう判断するか

4層それぞれにどこまでの冗長性を持たせるかは、「そのシステムが止まった場合に何が起きるか」という業務影響の大きさから逆算して判断します。すべての層を一律に最高水準まで冗長化しようとすると、必要以上のコストがかかります。逆にすべての層を最低限の構成にとどめると、業務上重要な処理を守れない事態を招きます。設計段階では、まず業務プロセスのうち止まったときの影響が大きいものを洗い出し、それを支えているシステムがどの層に依存しているかを確認する、という順序で検討するのが実践的です。

たとえば顧客向けの受発注システムであれば、ネットワーク層とデータ層の停止が売上に直結するため優先度が高くなります。一方、社内の分析用バッチ処理のように多少の遅延が許容できる業務であれば、電源層・ハードウェア層の対策を段階的に進める判断も成り立ちます。このように、業務ごとの優先順位を先に整理してから4層への投資配分を決めることで、可用性要件と予算のバランスが取れた設計になります。判断に迷う場合は、まず自社が属する業界で一般的に求められている可用性の水準を確認し、それを基準線として各層の投資優先度を決めていくとよいでしょう。

冗長性を設計する際には、構成図や運用手順書、契約書といった関連文書も蓄積されていきます。障害発生時にすぐ参照できるよう、こうした文書を検索・参照しやすい形で管理しておくことが実効性を左右します。

導入コストの考え方

中小企業であれば、月額数万円程度の初期段階から冗長性の導入を始めることができます。費用は4層のうちどこをどの方式で冗長化するかによって大きく変わるため、具体的な費用相場や方式ごとのコスト差は、冗長化とは｜仕組みと2つの種類で解説しています。設計段階では、まず4層のうちどこに予算を優先配分すべきかを、前述の業界別可用性要件から逆算して検討することが実践的です。

冗長性設計でよくある失敗パターン3つ

特定の層だけを冗長化する、可用性要件を確認せず設計する、冗長性とバックアップを混同するという3つが、冗長性の設計段階でよく見られる失敗の典型です。いずれも実装に入る前の設計思想の段階でつまずくパターンであり、実装方式(Active-Standby型・同時稼働型等)の選定ミスとは性質が異なります。

失敗パターン1:特定の層だけを冗長化する。データは冗長化しても電源やネットワークが単一構成のままといった、対策の抜けが残るケースです。前述の4タイプ分類に沿って、4層すべてを確認する設計プロセスを踏むことが回避策になります。

失敗パターン2:業界の可用性要件を確認せず設計する。必要な水準を下回る設計をしてしまう、あるいは逆に過剰な投資をしてしまうケースです。着手前に自社の業界・業務特性に応じた可用性要件を数値で確認することが回避策になります。

失敗パターン3:冗長性とバックアップを混同する。バックアップだけで冗長性を確保したと考えてしまい、実際の障害時には復元作業が必要になって停止時間が長引くケースです。平常時から予備を備える冗長性の考え方と、事後対応であるバックアップの違いを設計チーム全体で共有しておくことが回避策になります。

これら3つの失敗パターンに共通するのは、いずれも実装に着手する前の設計プロセスの段階で見落としが生じている点です。実際にどの方式で冗長化を実現するか(Active-Standby型・同時稼働型等)を検討し始める前に、4層の網羅性・業界の可用性要件・冗長性とバックアップの違いという3点を設計チームで確認しておくことで、実装段階でのやり直しを防ぎやすくなります。

冗長性は構築して終わりではない(監視・訓練の重要性)

冗長性は、予備リソースを備えた構成を組んだ時点では完成しません。実際に障害が起きたときに予備系へ正しく切り替わるかどうかを、平常時から監視し、定期的に訓練しておく必要があります。4層それぞれに予備を用意していても、監視の仕組みがなければ、片方の系統がすでに機能停止していることに気づかないまま運用を続けてしまうリスクがあります。いわゆる「冗長化構成のはずが、実際には片肺運用になっていた」という事態は、構成そのものの不備ではなく、監視・運用の不備が原因で発生することが少なくありません。

監視の基本は、4層それぞれの予備系が正常に稼働しているかを常時確認できる状態を保つことです。ハードウェア層であればディスクやサーバー本体の稼働状況、ネットワーク層であれば複数経路それぞれの通信状態、データ層であれば複製先のデータセンター・リージョンとの同期状況、電源層であれば無停電電源装置のバッテリー残量や自家発電設備の点検状況といったように、層ごとに確認すべき指標が異なります。これらを一元的に把握できる体制を整えておくことで、予備系の異常を早期に発見し、本番系に障害が及ぶ前に対処できる可能性が高まります。

もう1つ重要なのが、実際に障害が発生した想定で予備系への切り替えを試す訓練です。設計上は問題なく切り替わるはずの構成でも、実際に手を動かしてみると、切り替え手順が古いままだった、担当者間で役割分担が曖昧だった、といった課題が見つかることがあります。こうした課題は、平常時の訓練でしか洗い出せません。訓練の頻度や範囲は業界の可用性要件や業務の重要度に応じて判断する必要がありますが、少なくとも年に一度は、主要なシステムについて切り替え訓練を実施し、その結果を運用手順書に反映させる、というサイクルを回しておくことが実践的です。訓練で見つかった課題を放置せず、次回までに手順書や体制を見直す運用こそが、冗長性という「状態」を実効性のあるものに保つための土台になります。

クラウドとオンプレミスで冗長性の確保方法はどう変わるか

クラウド環境とオンプレミス環境では、4層のうち自社で対応すべき範囲が大きく異なります。クラウドサービスを利用する場合、ハードウェア層や電源層の冗長性の多くは、クラウド事業者側のデータセンター設備によってすでに確保されていることが一般的です。一方でオンプレミス環境では、サーバー機器の二重化から電源設備の確保まで、4層すべてを自社(または委託先)の責任で構築・維持する必要があります。この責任範囲の違いを理解しないまま設計を進めると、すでにクラウド事業者側で対応済みの層に自社でも重複した投資をしてしまったり、逆に自社で対応すべき層への対策が抜け落ちてしまったりする事態が起こり得ます。

クラウド環境を利用する場合でも、データ層とネットワーク層の一部については、利用者側の設定次第で可用性が変わる点に注意が必要です。マルチAZ・マルチリージョン構成を実際に選択して有効化するかどうか、通信経路を単一のクラウド事業者・単一リージョンに依存させるかどうかといった判断は、多くの場合、利用者側が構成時に選ぶ項目になっています。クラウド事業者が高い可用性の基盤を提供していても、利用者側がその基盤を活かす構成を選ばなければ、期待した水準の冗長性は得られません。契約・利用しているクラウドサービスの提供範囲(どこまでが事業者側の責任で、どこからが利用者側の設定次第か)を、4層の分類に沿って一度整理しておくことが、過不足のない冗長性設計につながります。オンプレミス環境から段階的にクラウドへ移行する場合は、この責任範囲の切り替わりを意識しながら、移行後に対策が抜け落ちる層がないかを確認する作業が特に重要になります。

よくある質問(FAQ)

Q1. 冗長性と冗長化はどう違いますか?

A. 冗長性は予備リソースを備えている状態、冗長化はその状態を作り出す行為・設計手法を指す言葉です。詳しい実現方法は冗長化とは｜仕組みと2つの種類で解説しています。

Q2. 冗長性とバックアップの違いは何ですか?

A. 冗長性は平常時から予備を備える設計思想で、バックアップは障害後の復元手段という違いがあります。

Q3. 4層のうちどこから冗長性を確保すればよいですか?

A. 自社の業界・業務特性に応じた可用性要件を確認したうえで、影響が大きい層から優先的に検討するのが実践的です。

Q4. RAID構成の限界は何ですか?

A. ハードウェア層の対策であり、ネットワークや電源の障害には対応できません。

Q5. 個人情報保護法との関連はありますか?

A. データの可用性確保という観点で、個人情報の適切な管理にも関連します。

Q6. 外部委託時に確認すべきポイントは何ですか?

A. 委託先がどの層まで冗長化に対応しているかを確認することが重要です。

まとめ｜今日からできる3つのこと

1. 4層すべてを確認する:特定の層だけに頼りません。
2. 業界の可用性要件を数値で確認する:確認せず設計しません。
3. 関連文書を検索しやすく管理する:障害時に探せない状態にしません。