フォールトトレランス実践ガイド：冗長化と分散設計で高可用性を実現する
エバープレイ編集部フォールトトレランスとは
フォールトトレランス（fault tolerance）は、システムがハードウェアやソフトウェアの障害（フォールト）を受けても、期待されるサービスや機能を継続できる能力を指します。単に「故障しない」ことではなく、故障が発生してもその影響を吸収し、エラーや障害（failure）に至らせない・最小化する設計思想と技術の集合です。金融取引、航空管制、医療機器、クラウドサービスなど、可用性と信頼性が重要な領域で不可欠な概念です。
基本概念：フォールト、エラー、フェイリュアの違い
- フォールト（fault）：システム内部の欠陥や不正な状態（例：メモリのビットフリップ、ソフトウェアバグ、ネットワーク輻輳）。潜在的原因であり必ずしも即時に外部から見えるわけではない。
- エラー（error）：フォールトが原因で内部状態が誤った値になった状態。エラーは伝播する可能性がある。
- フェイリュア（failure）：外部から観測される機能やサービスの不具合。システムの仕様が満たされなくなる状態。
主要な設計手法
- 冗長化（Redundancy）
ハードウェア冗長（複数の電源、RAID、冗長NIC）、ソフトウェア冗長（レプリケーション、アクティブ/パッシブ構成）、情報冗長（パリティ、チェックサム、ECC）など。代表例としてRAIDやマルチAZ構成があります。
- フェイルオーバーとスタンバイ
ホットスタンバイ（即時切替）、ウォーム/コールドスタンバイ（切替に準備や起動が必要）。自動フェイルオーバーは可用性を高める一方で、スプリットブレインや整合性問題に注意が必要です。
- 冗長化パターン（N冗長、Nモジュール冗長）
複数実装を用い結果を多数決で決めるNバージョンプログラミングやN-Modular Redundancy。安全クリティカル領域での手法です。
- グレースフルデグラデーション
全機能停止よりも一部機能を限定してサービスを継続する設計（例：非必須機能のオフ、低解像度配信）。
- チェックポイントとロールバック
長時間処理で途中状態を保存し、障害時に最後の一貫した状態から再開。
- フォールト検出と隔離
監視（ヘルスチェック、メトリクス、ログ）で早期検出し、自動的に隔離して影響を局所化する（サーキットブレーカー、バルクヘッド）。
分散システム特有の技術
- レプリケーション
データを複数ノードに複製し、読み取り／書き込みの冗長性を確保。同期レプリケーションは強い整合性を提供するが遅延が増える。非同期レプリケーションは可用性に優れるがデータの一貫性に注意。
- コンセンサスアルゴリズム（Paxos, Raft）
分散ノード間で単一の合意を取るためのアルゴリズム。リーダー選出やログ複製を通じて一貫性を保ちます。Raftは実装の理解性を重視して設計されました。
- ビザンチン耐性（BFT）
ノードが悪意を持つ場合でも正当な合意を得るための手法。f個のビザンチン故障を許容するには少なくとも3f+1ノードが必要（古典的条件）。ブロックチェーン分野でも応用されています。
- CAP定理とトレードオフ
ネットワーク分断時に整合性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）のうち選択が必要。設計では用途に応じた妥協が求められます。
評価指標と運用メトリクス
- MTTF（Mean Time To Failure）／MTBF（Mean Time Between Failures）— 故障までの平均時間
- MTTR（Mean Time To Repair）— 修復に要する平均時間
- 可用性（Availability）＝稼働時間／総時間。SLAでよく「99.9%（3ナイン）」など目標が設定される
- 信頼性（Reliability）＝故障なく動作する確率や期間
テスト手法と検証
- フォルト注入（Fault injection）：意図的に障害を発生させてシステムの応答を確認する。Chaos Engineering（例：Netflix Chaos Monkey）が有名。
- FMEA（Failure Modes and Effects Analysis）：故障モードごとの影響を洗い出し対策を優先付けする手法。
- 耐障害試験（Stress test / Load test）：高負荷環境での挙動確認。スローダウンによるタイムアウトやリトライの影響も検証する。
実運用でのパターンとベストプラクティス
- 冪等性を保証する（再試行時に副作用を二重発生させない）ことでリトライ戦略を安全に使える。
- タイムアウトとエクスポネンシャルバックオフを組み合わせ、過負荷時にシステムがさらに追い込まれないようにする。
- 監視とアラートは「何を監視するか」だけでなく閾値とノイズ対策を設計する。SLO／SLAを明確にし、アラート疲れを防ぐ。
- インフラは不可避の障害を前提に、フェイルオーバー手順と定期的な復旧訓練を行う（復旧演習やカオス実験）。
- データの整合性を守るために、トランザクション境界、整合性チェック、整合性回復手順を明文化する。
トレードオフと留意点
フォールトトレランスは万能ではなく、導入にはコスト増、設計・運用の複雑化、パフォーマンス劣化などのトレードオフがあります。どのレベルの耐障害性が必要かは業務上の影響度（ビジネス影響、法令、顧客期待）を基に決定すべきです。
実例と歴史的教訓
- RAIDやECCメモリ：ハードウェアレイヤの冗長化による信頼性向上。
- 分散データベースでのレプリケーションとコンセンサス（Paxos / Raft）：クラスタのリーダー障害からの復旧や一貫性保証に寄与。
- Chaos Engineering（Netflix等）：意図的な故障注入で実運用の脆弱性を発見・改善する文化が普及。
- AWSや大手クラウド事業者の障害事例：多くは単一障害点（SPOF）や想定外の相互依存が原因で、設計段階での障害ドメイン分離が重要であることが示されている。
導入チェックリスト（実務向け）
- 重要コンポーネントのSPOFを洗い出す
- 故障モードごとの業務影響（RTO/RPO）を定義する
- 冗長化レベル（冗長数、同期/非同期）を決める
- 監視・アラート・自動復旧フローを実装する
- フォールト注入テストと定期的なリハーサルを計画する
- 運用手順書とロールを整備し、定期的に見直す
まとめ
フォールトトレランスは、単一技術ではなく設計方針、アルゴリズム、運用プロセスが組み合わさった総合的な取り組みです。ビジネス要件に応じて、どこまでの耐障害性を確保するかを明確にし、冗長化・監視・検証を体系的に実施することが重要です。最新の分散合意アルゴリズムやカオスエンジニアリングといった実践手法を取り入れることで、実用的で効果的なフォールトトレランスを実現できます。
参考文献
- フォールトトレランス - Wikipedia（日本語）
- In Search of an Understandable Consensus Algorithm (Raft) — Diego Ongaro & John Ousterhout
- Paxos papers — Leslie Lamport
- Netflix Tech Blog — Chaos Engineering
- Amazon S3 の障害報告（2017年等の事例）
- Byzantine fault - Wikipedia (英語)
- RAID - Wikipedia (英語)
投稿者プロフィール
