冗長化とは｜仕組みと2つの種類
Check!
- 冗長化の意味とバックアップとの違いがわかる
- 2つの方式と業界別の活用がわかる
- 導入でよくある失敗パターンがわかる
「冗長化」と「冗長性」は似た言葉ですが、指しているものが異なります。冗長化は予備リソースを備えた状態を作り出す行為・設計手法を指す言葉で、冗長性はその結果として実現される状態を指す言葉です。本記事では、冗長化を「どう実現するか」という実装・運用の側面から、方式の違いや切り替え時の実務ポイントを解説します。どの層にどれだけ冗長性を備えるべきかという設計思想・可用性要件の考え方は、冗長性とは｜4タイプ分類と設計基礎で詳しく扱っています。
おすすめ記事
目次
開く
閉じる
開く
閉じる
冗長化とは(バックアップとの違い)
冗長化とは、複数台の構成要素をあらかじめ用意しておき、障害が発生した場合でもサービスの稼働を継続できるようにする設計手法を指します。バックアップはデータの復元に時間を要するのに対し、冗長化は待機系への即時切り替えによって停止時間を大幅に短縮できる点が大きな違いです。冗長化を実現する具体的な方式には、大きく分けてActive-Standby型と同時稼働型の2つがあります。
冗長化の実現方式(Active-Standby型/同時稼働型)
Active-Standby型と同時稼働型という2つが、冗長化の主要な実現方式です。どちらの方式を選ぶかによって、コスト構造・切り替え時の挙動・運用の複雑さが変わるため、システムの要件(許容できる停止時間、予算、運用体制)に応じて選定する必要があります。
| 方式 | 特徴 |
|---|---|
| Active-Standby型 | 障害時に待機系へ切り替えて稼働を継続 |
| 同時稼働型 | 複数の系が常時稼働し負荷を分散 |
Active-Standby型は、普段は稼働系(Active)のみが処理を行い、待機系(Standby)は障害発生時にのみ処理を引き継ぐ方式です。平常時のリソース消費が少なく構成もシンプルですが、切り替え(フェイルオーバー)に一定の時間がかかる点、待機系が普段は処理をしていないため実際に切り替わるかどうかの検証を意識的に行わないと、いざという時に切り替わらないリスクが残る点に注意が必要です。
同時稼働型は、複数の系が常時稼働し、ロードバランサーによって処理を振り分ける方式です。1つの系が停止しても他の系が処理を継続するため切り替え時間がほぼ発生せず、平常時から全系が実際に処理をこなしているため動作検証もしやすい一方、常時複数系を稼働させる分のリソースコストがかかります。クラスタリング技術によって複数のサーバーを1つのシステムのように協調動作させ、ロードバランシング技術によってアクセスを各系に振り分けるのが、この方式を支える基本的な仕組みです。
切り替え(フェイルオーバー)時の実務上の注意点
どちらの方式を選んでも、切り替えが実際に機能するかどうかを事前に検証しておくことが実務上もっとも重要なポイントです。構成上は冗長化されていても、切り替え処理自体をテストしたことがなければ、実際の障害時に想定通り切り替わる保証はありません。
フェイルオーバーテストでは、稼働系を意図的に停止させて待機系(または他の稼働系)へ処理が引き継がれることを確認します。あわせて、切り替え完了までにかかる実際の時間(RTO:目標復旧時間)と、切り替え時点で失われるデータの範囲(RPO:目標復旧時点)が、事前に設定した許容範囲に収まっているかも確認します。切り替え自体はできても、想定より時間がかかりすぎる、あるいはデータの整合性が崩れるといった問題は、実際にテストして初めて判明することが少なくありません。切り替え先のリソース(サーバー台数・ネットワーク帯域等)が本番の負荷に耐えられる規模になっているかどうかも、平常時から定期的に見直しておく必要があります。
費用相場と業界別の活用
費用は方式や構成の規模によって幅があり、クラウド活用であれば比較的低コストで始められる一方、オンプレミスで大規模な冗長構成を組む場合は相応の投資が必要になります。同時稼働型はActive-Standby型に比べて常時稼働させるリソースが多い分、一般的にコストは高めになりますが、切り替え時間の短さや検証のしやすさというメリットとのバランスで選定します。金融機関はシステム停止が経営リスクに直結するため厳格な冗長構成を採用し、医療機関は診療データの継続的な参照のために、製造業は生産ラインの制御システムの継続稼働のために活用しています。どの層にどこまでの可用性を求めるべきかという業界別の要件は、冗長性とは｜4タイプ分類と設計基礎で解説しています。
冗長化を運用し続けるための体制づくり
冗長化は構成を組んで終わりではなく、平常時から監視・検証を続けて初めて機能する仕組みです。稼働系・待機系の双方の状態を常時監視する仕組みを整え、待機系や予備の系統に異常が起きていても稼働系が正常に動いているために気づかない、という状態を避ける必要があります。監視項目には、各系の死活状態だけでなく、切り替えに必要なリソース(帯域・容量等)が本番負荷に対して十分な余裕を保てているかも含めておくとよいでしょう。
また、誰がいつフェイルオーバーテストを実施し、その結果をどこに記録するかという運用ルールを、担当者個人の裁量に委ねず、チームとして明文化しておくことも重要です。担当者の異動や退職によって、テストの実施自体が立ち消えになってしまうケースは実務上少なくありません。テストの頻度・手順・合否基準・記録方法をあらかじめ定めておき、定期的な棚卸しの対象として運用体制に組み込むことで、冗長化構成が形骸化することを防げます。
冗長化構成の実効性を左右する要素のひとつが、前述したデータレプリケーションを支えるデータベース側の機能です。同期方式・非同期方式のどちらを選べるか、障害発生時の自動フェイルオーバーに対応しているかは、データベースソフト自体の仕様に依存します。RPO(目標復旧時点)の要件を満たせるかどうかは、冗長化構成の設計だけでなく、土台となるデータベースソフトの選定段階から検討しておく必要があります。
冗長化導入でよくある失敗パターン3つ
切り替えテストを行わないまま運用する、フェイルオーバー後の検証を省略する、SLA契約の内容を確認しないという3つが、冗長化の運用段階でよく見られる失敗の典型です。いずれも構成自体は正しく組まれていても、実際に動かして確認するプロセスを欠いたために起きる失敗であり、設計段階の失敗とは性質が異なります。
失敗パターン1:切り替えテストを行わないまま運用する。構成上はActive-Standby型・同時稼働型のいずれかで冗長化されていても、実際に稼働系を止めて切り替わることを確認したことがなく、本番障害で初めて切り替わらないことが判明するケースです。定期的なフェイルオーバーテストを運用計画に組み込むことが回避策になります。
失敗パターン2:フェイルオーバー後の検証を省略する。切り替え自体は成功しても、切り替え後のデータ整合性やアプリケーションの動作確認を行わず、利用者側で不具合に気づいて初めて問題が発覚するケースです。切り替え完了後の動作確認までを手順書に含めておくことが回避策になります。
失敗パターン3:SLA契約の内容を確認しない。提供事業者の保証範囲を把握せず、期待した稼働率が得られないケースです。契約内容を事前に確認し、自社が必要とするRTO・RPOの水準を満たしているかを照合することが回避策になります。
これら3つの失敗パターンに共通するのは、構成自体は正しく組まれていても、運用フェーズでの検証・確認を怠っていることです。どの層にどの水準の冗長性を持たせるべきかという設計段階の判断が正しくても、切り替えテストや契約内容の確認といった運用段階のプロセスが抜けていれば、実際の障害時には機能しません。設計と運用の両方を継続的に見直すことが、冗長化を実効性のある仕組みとして維持するポイントです。
冗長化を支える基盤技術(クラスタリング/レプリケーション/ロードバランシング)
冗長化を実際に機能させるには、クラスタリング・データレプリケーション・ロードバランシングという3つの基盤技術の役割を切り分けて理解しておく必要があります。それぞれが担う範囲が異なるため、どこか1つだけを導入しても冗長化としては不十分になりがちです。
クラスタリングは、複数台のサーバーを1つのまとまりとして協調動作させる仕組みです。クラスタを構成するサーバー群は互いの死活状態を監視し合い、いずれかに障害が発生したことを検知すると、残りのサーバーで処理を継続します。Active-Standby型・同時稼働型のどちらの方式であっても、この死活監視と切り替え判断の仕組みがクラスタリング技術によって支えられています。
データレプリケーションは、稼働系が保持するデータを待機系や他の稼働系にリアルタイムまたは一定間隔で複製する仕組みです。切り替え(フェイルオーバー)が正常に完了しても、切り替え先のデータが古い状態のままでは業務を継続できません。レプリケーションの方式には、書き込みのたびに即座に複製する同期方式と、一定間隔でまとめて複製する非同期方式があり、同期方式はデータの一貫性が高い一方で書き込み性能に影響が出やすく、非同期方式は性能への影響が小さい一方でわずかな時間差分のデータが失われる可能性がある点がトレードオフです。どちらを選ぶかは、前述のRPO(目標復旧時点)としてどこまでのデータ損失を許容できるかによって決まります。
ロードバランシングは、複数の稼働系にアクセスを振り分ける仕組みで、主に同時稼働型の冗長化構成を支えます。特定のサーバーへのアクセス集中を避けて負荷を分散させると同時に、死活監視の結果に応じて障害が発生したサーバーへの振り分けを自動的に停止する役割も担います。ロードバランサー自体が単一障害点にならないよう、ロードバランサー自体も冗長化しておく必要がある点は見落とされがちな注意点です。
クラウド環境における冗長化構成の考え方
クラウド環境では、物理的に離れた複数の設備(アベイラビリティゾーン・リージョン)にまたがって冗長化構成を組めるかどうかが、オンプレミス環境との大きな違いになります。同一設備内での冗長化に加えて、設備自体が停止するような大規模障害・災害を想定した構成まで検討できる点がクラウド活用のメリットです。
同一リージョン内の複数のアベイラビリティゾーンにまたがって構成を組む場合、通信の遅延を比較的小さく抑えながら、単一の設備障害(電源・空調設備のトラブル等)には耐えられる構成になります。一方、リージョンをまたいだ冗長化構成は、地震・水害といった広域災害への備えとしては有効ですが、リージョン間の通信距離が長くなる分、データレプリケーションの遅延が大きくなりやすく、同期方式でのレプリケーションが難しくなる場合がある点に注意が必要です。自社のシステムがどこまでの障害範囲を想定して冗長化すべきかは、事業への影響度や許容できる停止時間に応じて判断する必要があり、この判断軸自体は冗長性とは｜4タイプ分類と設計基礎で扱っている可用性要件の考え方と共通しています。
また、クラウド環境ではリソースを必要な時だけ確保して使うことができるため、待機系のリソースを平常時は最小限に抑え、切り替え発生時にのみ本番相当のリソースへ自動的に拡張する構成を組める場合があります。こうした仕組みをうまく活用できれば、Active-Standby型の弱点である平常時のリソース遊休をある程度緩和しながら、コストを抑えた冗長化構成を実現しやすくなります。ただし、この自動拡張が実際に想定通りの速度・規模で機能するかどうかも、フェイルオーバーテストの中で確認しておくべき項目のひとつです。
よくある質問(FAQ)
Q1. 冗長化と冗長性はどう違いますか?
A. 冗長化は予備を備えた状態を作り出す行為・設計手法、冗長性はその結果として実現される状態を指す言葉です。どの層にどこまでの冗長性を備えるべきかという設計思想は冗長性とは｜4タイプ分類と設計基礎で解説しています。
Q2. バックアップとの違いは何ですか?
A. バックアップは復元に時間を要するのに対し、冗長化は待機系への即時切り替えで停止時間を大幅に短縮できる点が異なります。
Q3. Active-Standby型と同時稼働型はどちらを選ぶべきですか?
A. 許容できる停止時間・予算・運用体制によって異なります。切り替え時間の短さを重視するなら同時稼働型、コストを抑えたい場合はActive-Standby型が選択肢になります。
Q4. 中小企業でも冗長化は必要ですか?
A. 事業への影響度に応じて必要性が異なり、クラウド活用によって比較的低コストで導入できる選択肢もあります。
Q5. RTO・RPOとは何ですか?
A. RTOは復旧までの許容時間、RPOはデータ損失の許容範囲を示す指標で、切り替えテストの合否を判断する目安になります。
Q6. 関連する手順書や契約書はどう管理すればよいですか?
A. 障害発生時にすぐ参照できるよう、検索・参照しやすい形で保管しておくことが望ましいです。あわせて、RPOの要件を満たすレプリケーション方式(同期/非同期)に対応しているかは、データベースソフト自体の選定段階で確認しておく必要があります。
まとめ｜今日からできる3つのこと
- フェイルオーバーテストを定期的に実施する:構成だけで満足しません。
- RTO・RPOを事前に設定し切り替え後まで検証する:目標値を決めずに導入しません。
- 関連書類を検索しやすく管理する:必要な時に探せない状態にしません。
