冗長性とは：SPOF排除からクラウド実装までの設計・運用ベストプラクティス
エバープレイ編集部冗長性とは──概要と定義
冗長性（じょうちょうせい、redundancy）は、システムやデータ、ネットワーク、電源などの要素において「同じ機能や情報を複数用意する」ことで、障害発生時にサービスの継続性や可用性を確保する設計理念・手法を指します。ITの文脈では単に“余分に用意する”という意味を超えて、可用性（Availability）、耐障害性（Fault tolerance）、サービス品質の維持を目的とした体系的な設計・運用の総称として扱われます。
なぜ重要か
単一障害点（SPOF: Single Point Of Failure）を排除し、業務継続性を確保するため。
SLAs（サービスレベル合意）や顧客期待に応じた稼働率を満たすため。
データ損失や長時間のダウンタイムが企業に与える経済的・信用的損失を軽減するため。
冗長性の種類
ハードウェア冗長性：サーバの二重化（ホットスワップ対応の電源、複数NICなど）、RAIDによるディスク冗長化、冗長化されたネットワークスイッチ等。
ソフトウェア冗長性：アプリケーションレベルのレプリケーション、クラスタリング、負荷分散。
データ冗長性：バックアップ、レプリケーション、スナップショット、エラージャーコーディング（erasure coding）など。
地理的冗長性：同一地域内の複数AZ（アベイラビリティゾーン）や、別リージョン／別DCへのレプリケーション。
電源・冷却などインフラ冗長性：UPS、2回線の電力供給、冗長化された空調設備。
設計パターン：Active-Passive と Active-Active
Active-Passive（アクティブ/パッシブ）：本番系ノードが稼働し、予備ノードは待機。障害時にフェイルオーバーする。実装が単純で一貫性管理も容易だが、待機リソースが無駄になりがち。
Active-Active（アクティブ/アクティブ）：複数ノードが同時に稼働し負荷分散。スケールしやすくリソース効率が良いが、データ一貫性・同期やコンフリクト解決が課題になる。
代表的な技術と手法
RAID：ディスク冗長化の古典。RAID 1（ミラーリング）、RAID 5（シングルパリティ）、RAID 6（デュアルパリティ）、RAID 10（ミラー＋ストライプ）などがあり、各レベルで性能・耐障害性と容量効率のトレードオフがある。
レプリケーション：同期（同期レプリケーション）・非同期（非同期レプリケーション）でデータを複製。同期は一貫性が高いがレイテンシ増、非同期はRPO（許容データ損失量）と引き換えにパフォーマンスを保てる。
ロードバランサと負荷分散：トラフィックを複数のバックエンドに配分して耐障害性とスケーラビリティを確保。ヘルスチェックで異常を検知しトラフィックを迂回させる。
分散ストレージとエラージャーコーディング：複数ノードにデータ断片を分散して保存し、一定数失われても復元可能にする。コピー数を減らして容量効率を改善できる（例：オブジェクトストレージの多くが採用）。
クラスタリングとコンセンサス：分散システムでの状態同期やリーダー選出には、PaxosやRaftといった合意アルゴリズムが用いられる。これにより分散環境での一貫性とフォールトトレランスを実現する。
フェンシング（STONITH）とハートビート：クラスタで分裂（スプリットブレイン）を防ぎ、障害ノードを確実に隔離する仕組み。STONITHは「障害と判断したノードの電源を強制的に切る」等の手法を指す。
可用性と一貫性のトレードオフ（CAPやRPO/RTO）
分散システムでは、可用性（Availability）、整合性（Consistency）、分断耐性（Partition tolerance）の関係（CAP定理）を考慮する必要があります。ネットワーク分断時には完全な一貫性を優先するか、サービス継続（可用性）を優先するかで設計が変わります。また、ビジネス要件からRTO（復旧目標時間）とRPO（復旧目標点）を定め、それに沿った冗長化（同期or非同期レプリケーション、バックアップ頻度等）を選ぶのが現実的です。
運用面の考慮点
テストが最重要：フェイルオーバーテストやリカバリ手順の定期検証を行わないと、冗長化は机上の空論になる。自動化された切替テストやDR演習を実施する。
監視とアラート設計：冗長構成の稼働状況（レプリケーション遅延、デグレード状態、スピンアップした予備リソースなど）を可視化し、早期対応を可能にする。
運用手順とオペミス対策：誤操作で冗長構成が破壊されるリスクを回避するため、変更管理や段階的ロールアウト、ロールバック手順を整備する。
コスト最適化：すべてをフル冗長化するのは費用対効果が悪い。ビジネスインパクト分析に基づく優先度付け（ミッションクリティカルな部分に重点）を行う。
セキュリティとの両立：冗長化のために作成したバックアップやレプリカも保護対象。アクセス制御や暗号化、ログ管理を怠らない。
クラウド環境での実装例
マルチAZ設計（例：AWS）：同リージョン内の異なる物理データセンターにリソースを配置し、AZ間レプリケーションで可用性を高める。低レイテンシでのフェイルオーバーが可能だが、リージョン全体障害には無力。
マルチリージョン設計：地理的冗長性を確保することで、大規模災害やリージョン障害に対する耐性を持たせる。ただしレイテンシとデータ整合性の設計がより難しくなる。
実務上のベストプラクティス（まとめ）
まずはビジネス要求（RTO/RPO、SLA）を明確にする。
重要システムから順に冗長性を設計し、全てに同じレベルを適用しない（コスト最適化）。
単一障害点を洗い出し、優先順位を付けて冗長化する。
自動化されたフェイルオーバーと戻し処理（フェイルバック）を準備し、定期的にテストする。
監視とアラート、運用手順を整備してヒューマンエラーを減らす。
セキュリティ、コスト、性能のトレードオフをドキュメント化し関係者合意を取る。
最後に：冗長性は「当たり前」ではない
冗長性は単なる技術的オプションではなく、ビジネス要件と整合した設計判断です。過剰な冗長化はコスト増を招き、不十分な冗長化は重大なダウンタイムにつながります。設計段階での意思決定（どこまで冗長にするか）は、技術的な理解だけでなく事業リスク評価や運用体制の成熟度を踏まえた総合判断が必要です。
