耐障害性とは？障害に強いシステム設計の基本と実務解説

耐障害性とは、システムの一部に障害が発生しても、サービス全体ができるだけ止まらずに動き続ける能力を指します。サーバー、ネットワーク、データベース、外部サービス、クラウド基盤などは、どれだけ丁寧に設計しても永遠に壊れないわけではありません。そのため、現代のシステム設計では「障害を完全になくす」ことよりも、「障害が起きても影響を最小化し、できるだけ早く復旧できる構造を作る」ことが重要になります。

特にクラウド環境や分散システムでは、複数のサーバー、複数のサービス、複数のデータストアが連携して動きます。このような構成では、一部のサービス停止や通信遅延が全体に波及する可能性があります。耐障害性を考慮していない場合、たった1台のサーバー停止や一時的なネットワーク不安定化だけで、ユーザーがログインできない、購入できない、データが保存できないといった大きな問題につながります。

耐障害性の本質は、「壊れないシステムを作ること」ではありません。現実には、ハードウェアは壊れ、ネットワークは遅延し、外部サービスは失敗し、人間は設定ミスをします。そのため、耐障害性では、障害を前提条件として扱い、冗長化、障害切替、複製、再試行、負荷分散、自動復旧、監視、アラートなどを組み合わせながら、サービスを継続できる構造を作ります。

1. 耐障害性とは？

耐障害性とは、システムの一部が故障したり、通信が失敗したり、処理にエラーが発生したりしても、サービス全体として利用可能な状態を維持するための設計思想です。単にエラーを検知するだけではなく、障害が起きたときに別の経路へ切り替える、予備システムを使う、失敗した処理を再試行する、ユーザーへの影響を小さくする、といった仕組みを含みます。

耐障害性の特徴

1.1 障害を前提にした設計思想

耐障害性では、サーバーは必ず壊れる、ネットワークは必ず失敗する、データベース接続はいつか途切れる、外部サービスは常に正常とは限らない、という前提でシステムを設計します。これは悲観的な考え方ではなく、実務上きわめて現実的な考え方です。どれだけ高性能なクラウド基盤を使っていても、障害がゼロになることはありません。

たとえば、1台のアプリケーションサーバーだけでサービスを動かしている場合、そのサーバーが停止するとサービス全体が止まります。これは単一障害点が存在する状態です。耐障害性を高めるには、複数台のサーバーを用意し、片方が落ちても別のサーバーで処理を継続できるようにします。つまり、障害が起きないことを期待するのではなく、障害が起きても耐えられる構造を作ることが重要です。

1.2 目的

耐障害性の目的は、サービス停止を防ぎ、ユーザーへの影響を最小化することです。ユーザーにとって重要なのは、内部でどのサーバーが動いているかではなく、サービスが使えるかどうかです。たとえ内部で一部のサーバーや機能に障害が起きていても、ユーザーが通常通りログインできる、検索できる、購入できる、データを保存できる状態を維持できれば、サービス品質を守ることができます。

また、耐障害性はビジネス継続性にも直結します。ECサイトであれば、サービス停止は売上損失につながります。SaaSであれば、業務停止や顧客信頼の低下につながります。金融、医療、交通、インフラ系システムでは、障害の影響はさらに深刻になります。そのため、耐障害性は技術的な品質だけでなく、事業継続と信頼性を支える重要な設計概念です。

2. 耐障害性の基本考え方

耐障害性を考えるうえで重要なのは、「失敗を避ける」だけではなく、「失敗したあとにどう復旧するか」を設計することです。すべての障害を事前に防ぐことはできないため、障害発生後の切り替え、復旧、影響範囲の制限、再試行、劣化運転などを考える必要があります。

2.1 すぐ止めるより早く復旧する

耐障害性では、単に障害を検知して処理を止めるだけでは不十分です。もちろん、危険な処理やデータ破壊につながる処理はすぐ止める必要がありますが、サービス全体としては、できるだけ早く復旧し、利用可能な状態へ戻すことが重要です。そのため、実務では「失敗しない設計」だけでなく、「失敗してもすぐ戻れる設計」が求められます。

たとえば、一時的に外部APIへの通信が失敗した場合、すぐにユーザーへ完全なエラーを返すのではなく、短時間の再試行を行う、代替データを表示する、処理をキューに入れて後から再実行する、といった選択肢があります。これにより、一時的な障害をユーザーに見せずに吸収できる場合があります。耐障害性では、失敗を単なる停止ではなく、復旧可能な状態として扱うことが重要です。

2.2 単一障害点をなくす

単一障害点とは、そこが壊れるとシステム全体が止まってしまう箇所を指します。たとえば、1台だけのWebサーバー、1つだけのデータベース、1本だけのネットワーク経路、1つだけの認証サービスなどが単一障害点になり得ます。耐障害性を高めるには、この単一障害点をできるだけ減らす必要があります。

単一障害点をなくすためには、冗長化や分散化が使われます。複数のサーバーを用意し、負荷分散装置でアクセスを振り分ける。データベースを複製し、主系が落ちたら待機系へ切り替える。クラウドの複数ゾーンや複数地域にシステムを配置する。こうした設計によって、一部が壊れても全体が停止しにくい構造を作れます。

3. 主な実現方法

耐障害性を実現する方法には、冗長化、障害切替、複製、再試行処理などがあります。これらは単独で使うのではなく、システムの重要度や要件に応じて組み合わせます。たとえば、Webサーバーは冗長化し、データベースは複製し、外部API通信には再試行を入れ、障害時には自動で待機系へ切り替える、といった設計が一般的です。

3.1 冗長化

冗長化とは、同じ役割を持つシステム構成要素を複数用意することです。たとえば、Webサーバーを1台だけではなく2台以上用意しておけば、1台が停止しても別のサーバーがリクエストを処理できます。冗長化は、耐障害性の中でも最も基本的な考え方です。

ただし、冗長化すれば自動的に安全になるわけではありません。複数台のサーバーが同じ設定で動いているか、負荷分散装置が正しく振り分けているか、障害が起きたサーバーを自動で切り離せるか、データが正しく共有されているかを考える必要があります。冗長化は、単に台数を増やすことではなく、障害時にも正しく機能する構成として設計することが重要です。

3.2 障害切替

障害切替とは、稼働中のシステムに障害が発生したとき、予備のシステムや別のノードへ処理を切り替える仕組みです。たとえば、主系データベースが停止した場合に、待機系データベースを主系として昇格させる構成があります。これにより、障害発生後もサービスを継続しやすくなります。

障害切替で重要なのは、切り替えの自動化と正確性です。障害を検知しても、切替処理に時間がかかったり、切替先の状態が古かったりすると、ユーザー影響が大きくなります。また、誤検知によって不要な切替が発生すると、かえってシステムを不安定にすることもあります。そのため、障害切替は、監視、判定条件、データ同期、復旧手順を含めて設計する必要があります。

3.3 複製

複製とは、データを複数の場所に保持することです。データベースの複製、ストレージの複製、ログの複製などが代表例です。主系のデータベースに障害が発生しても、複製された待機系データベースがあれば、そこからサービスを復旧したり、読み取り処理を継続したりできます。

複製で重要なのは、データの整合性です。すべての複製先に常に同じデータがあるとは限りません。非同期複製では、主系に書き込まれたデータが複製先に反映されるまでに遅延が発生することがあります。そのため、障害発生時にどの時点までのデータが保証されるのか、データ欠損をどこまで許容するのかを事前に決める必要があります。

3.4 再試行処理

再試行処理とは、一時的に失敗した処理を一定条件で再実行する仕組みです。ネットワーク通信や外部API呼び出しでは、一時的なタイムアウトや接続エラーが発生することがあります。このような失敗は、少し待って再実行すれば成功する場合があります。

ただし、再試行は慎重に設計する必要があります。無制限に再試行すると、障害中のシステムにさらに負荷をかけ、障害を悪化させる可能性があります。また、注文作成や決済処理のように副作用のある処理では、再試行によって二重処理が発生しないようにする必要があります。実務では、再試行回数、待機時間、指数的な待機、冪等性、失敗時の保留処理を考慮します。

4. 耐障害性の構造

耐障害性を実現する構造には、主系・待機系構成、分散システム構造、負荷分散装置を使った構成などがあります。どの構成を選ぶかは、システムの重要度、アクセス量、求められる復旧時間、コスト、運用体制によって変わります。

耐障害性を支える構造

4.1 主系・待機系構成

主系・待機系構成とは、通常時に処理を行う主系と、障害時に切り替える待機系を用意する構成です。たとえば、主系データベースが停止した場合、待機系データベースに切り替えてサービスを継続します。この構成は、比較的分かりやすく、多くの業務システムやデータベース構成で使われます。

ただし、待機系が常に使える状態になっているとは限りません。データ同期が遅れている、設定が古い、切替手順が手動で複雑、待機系の性能が不足している、といった問題があると、障害時に期待通り動かない可能性があります。そのため、主系・待機系構成では、定期的な切替訓練や復旧テストも重要です。

4.2 分散システム構造

分散システム構造とは、複数のノードやサービスに処理を分ける構成です。1台のサーバーにすべての処理を集約するのではなく、複数のサーバーやサービスが協調して処理します。これにより、一部のノードが停止しても、他のノードで処理を継続しやすくなります。

一方で、分散システムは複雑です。ネットワーク遅延、通信失敗、データ整合性、部分障害、再試行、重複処理などを考慮する必要があります。耐障害性は高めやすい反面、設計や運用の難易度も上がります。分散システムでは、障害が完全にゼロになるのではなく、障害が局所化され、全体停止を避けられる構造を目指します。

4.3 負荷分散装置

負荷分散装置は、ユーザーからのリクエストを複数のサーバーへ振り分ける仕組みです。複数台のWebサーバーを用意し、負荷分散装置が正常なサーバーへアクセスを割り当てることで、負荷を分散しつつ、障害が起きたサーバーを切り離せます。

耐障害性の観点では、負荷分散装置の正常性確認が重要です。サーバーが停止しているのにリクエストを送り続けると、ユーザーにエラーが返ります。そのため、負荷分散装置は各サーバーの状態を確認し、異常なサーバーを自動的に除外する必要があります。また、セッション情報をどこに保持するかも重要です。特定サーバーにしかセッションがない構成では、切替時にログイン状態が失われる可能性があります。

5. 耐障害性と関連概念

耐障害性は、高可用性、信頼性、回復力と深く関係しています。これらは似た意味で使われることもありますが、厳密には見る観点が異なります。耐障害性は「障害に耐える能力」、高可用性は「使える状態を維持する能力」、信頼性は「正しく動き続ける確率」、回復力は「障害から戻る力」と整理できます。

5.1 高可用性

高可用性とは、サービスが利用可能な状態を高い割合で維持することです。ユーザーから見て、サービスが常に使える状態に近づけることが目的です。たとえば、システムの稼働率を高め、障害による停止時間を短くする設計が高可用性に関係します。

耐障害性は、高可用性を実現するための重要な手段です。サーバーが1台落ちても別のサーバーが処理を継続する、データベース障害時に待機系へ切り替える、外部サービス失敗時に代替処理を行う、といった耐障害設計によって、ユーザーがサービスを使えない時間を減らせます。

5.2 信頼性

信頼性とは、システムが期待通りに正しく動作し続ける能力です。サービスが動いていても、誤ったデータを返す、二重決済する、注文情報が欠落する、間違った通知を送るようでは信頼性が高いとは言えません。つまり、信頼性では「使えるか」だけでなく「正しく使えるか」が重要になります。

耐障害性と信頼性は密接に関係します。障害時にサービスを止めないことは重要ですが、誤った処理を継続するくらいなら、対象機能だけを安全に停止する方がよい場合もあります。実務では、耐障害性と信頼性のバランスを取りながら、どの障害なら継続し、どの障害なら止めるべきかを判断します。

5.3 回復力

回復力とは、障害が発生したあとに正常な状態へ戻る能力です。耐障害性が「障害中でもできるだけ動き続ける能力」だとすれば、回復力は「障害後に素早く立て直す能力」です。たとえば、障害が発生したサーバーを自動再起動する、問題のあるリリースをロールバックする、キューに溜まった処理を再実行する、といった対応が回復力に関係します。

現代のシステムでは、障害発生を完全に防ぐことは難しいため、回復力の設計が非常に重要です。障害を検知し、影響範囲を把握し、原因を特定し、安全に復旧し、再発防止を行う流れが整っているほど、サービス品質は安定します。耐障害性と回復力はセットで考えるべき概念です。

6. メリット

耐障害性を高めるメリットは、サービス停止リスクを下げられること、ユーザー体験を安定させられること、ビジネス継続性を確保できることです。特に、利用者が多いサービスや業務に直結するシステムでは、耐障害性の有無が信頼性に大きく影響します。

6.1 サービス停止リスク低下

耐障害性を高めることで、システムの一部に障害が発生しても、サービス全体が停止するリスクを下げられます。たとえば、複数のサーバーを用意しておけば、1台が停止しても別のサーバーで処理を継続できます。データベースを複製しておけば、主系障害時に待機系へ切り替えられます。

サービス停止リスクを下げることは、ユーザー満足度だけでなく、売上やブランド信頼にも関係します。特に、EC、SaaS、金融、予約、医療、業務システムでは、停止時間が直接的な損失につながります。耐障害性は、障害による損失を抑えるための投資とも言えます。

6.2 ユーザー体験の安定化

ユーザーにとって、システム障害は強いストレスになります。ページが表示されない、操作しても反応しない、データが保存されない、決済が失敗する、といった体験はサービスへの不信感につながります。耐障害性を高めることで、障害時でもできるだけ安定した体験を提供できます。

また、完全に正常な状態を維持できない場合でも、劣化運転によって最低限の体験を守ることができます。たとえば、レコメンド機能が停止しても商品検索は使える、画像生成が失敗してもテキスト機能は使える、外部通知が遅れても注文自体は完了する、といった設計です。耐障害性は、ユーザー体験を守る設計でもあります。

6.3 ビジネス継続性の確保

耐障害性は、ビジネス継続性にも直結します。事業にとって重要なシステムが停止すると、売上機会の損失、顧客対応の増加、契約上の問題、ブランド信頼の低下が発生します。特に、企業向けサービスでは、システムの安定性が契約継続や顧客満足に大きく影響します。

耐障害性を設計しておくことで、障害時にも主要機能を継続し、復旧までの時間を短縮できます。これは単なる技術対策ではなく、事業リスク管理の一部です。重要なサービスほど、どの程度の停止を許容するか、どの機能を優先的に守るか、どの復旧時間を目標にするかを明確にする必要があります。

7. デメリット・課題

耐障害性を高めるには、コスト、複雑性、データ整合性といった課題があります。高い耐障害性を求めるほど、サーバー台数、クラウド費用、監視運用、設計工数が増えます。そのため、すべてのシステムで最大限の耐障害性を目指すのではなく、重要度に応じて適切なレベルを決めることが重要です。

7.1 コスト増加

耐障害性を高めるには、追加のサーバー、複製データベース、複数地域への展開、監視ツール、バックアップ、運用体制などが必要になります。そのため、単一構成よりもコストが増えます。特に、待機系の環境を常に稼働させる場合、通常時には使われないリソースにも費用がかかります。

ただし、コストだけを見て耐障害性を削りすぎると、障害発生時の損失が大きくなる場合があります。重要なのは、サービス停止による損失と、耐障害性を高めるコストを比較することです。すべての機能に最高レベルの耐障害性を持たせる必要はありませんが、事業上重要な機能には十分な投資が必要です。

7.2 システム複雑化

耐障害性を高めるほど、システム構成は複雑になりやすくなります。サーバーを増やし、複製を行い、障害切替を設定し、再試行やキュー処理を入れると、障害時の動きも複雑になります。構成が複雑になると、設計ミスや設定ミスが新たな障害原因になることもあります。

そのため、耐障害性の設計では、複雑さを管理することが重要です。構成図、復旧手順、監視項目、アラート条件、切替手順、テスト手順を整理し、チーム全体で理解できる状態にする必要があります。耐障害性を高めるための仕組みそのものがブラックボックスになると、障害時に対応できなくなります。

7.3 データ整合性問題

耐障害性を高めるために複製や分散処理を行うと、データ整合性の問題が発生しやすくなります。複数のデータベースにデータを複製する場合、反映遅延によって一時的にデータが一致しないことがあります。複数ノードで処理する場合、同じ処理が重複して実行される可能性もあります。

特に、注文、決済、在庫、残高、契約情報のような重要データでは、整合性管理が非常に重要です。耐障害性を高めるために分散した結果、データが不正確になっては本末転倒です。実務では、どのデータは強い整合性が必要か、どのデータは最終的な整合性でよいかを分類し、適切な設計を選ぶ必要があります。

8. 実務での設計パターン

実務で耐障害性を高める設計パターンには、冗長サーバー構成、複数地域展開、キューイングシステム、サーキットブレーカーなどがあります。これらはシステムの性質に応じて使い分けます。

8.1 冗長サーバー構成

冗長サーバー構成は、最も基本的な耐障害設計の一つです。複数のWebサーバーやAPIサーバーを用意し、負荷分散装置を通してリクエストを振り分けます。1台のサーバーに障害が起きても、正常なサーバーへリクエストを流すことで、サービス全体の停止を防ぎます。

ただし、冗長サーバー構成では、サーバーごとの状態管理に注意が必要です。セッション情報を各サーバーのローカルメモリに持っていると、別サーバーへ切り替わったときにログイン状態が失われる可能性があります。そのため、セッションを外部ストアに保存する、ステートレスなAPI設計にする、設定を自動化して全サーバーを同じ状態に保つ、といった工夫が必要です。

8.2 複数地域展開

複数地域展開とは、システムを1つの地域だけでなく、複数の地域やデータセンターに配置する構成です。これにより、特定地域で大規模障害が発生しても、別地域の環境へ切り替えてサービスを継続できる可能性が高まります。

ただし、複数地域展開は高度な設計が必要です。データを地域間でどう同期するか、ユーザーをどの地域へ振り分けるか、地域間の遅延をどう扱うか、障害時にどのタイミングで切り替えるかを考える必要があります。コストも高くなるため、すべてのサービスで必要なわけではありませんが、重要度の高いシステムでは有効な選択肢になります。

8.3 キューイングシステム

キューイングシステムは、処理要求をキューに一時保存し、ワーカーが順番に処理する仕組みです。たとえば、注文後のメール送信や画像変換のように、ユーザーが即時完了を待つ必要がない処理をキューに入れることで、メイン処理を軽くできます。

耐障害性の観点では、キューは一時的な障害や負荷集中を吸収する役割を持ちます。処理側のワーカーが一時的に停止しても、キューにメッセージを保持しておけば、復旧後に処理を再開できます。ただし、キューが溜まりすぎると遅延が大きくなるため、監視や再試行、重複処理対策が必要です。

8.4 サーキットブレーカー

サーキットブレーカーは、外部サービスや他の内部サービスへの呼び出しが連続して失敗した場合、一時的に呼び出しを停止する仕組みです。電気回路のブレーカーのように、障害が広がる前に遮断する考え方です。これにより、失敗し続けるサービスへ大量のリクエストを送り続けて、さらに障害を悪化させることを防げます。

たとえば、決済サービスが不安定なときに、すべてのリクエストを送り続けると、ユーザー待ち時間が長くなり、自社システムのスレッドや接続も消費します。サーキットブレーカーを使えば、一定回数以上失敗した時点で一時的に呼び出しを止め、ユーザーには代替メッセージを表示したり、後続処理を保留したりできます。分散システムでは非常に重要な設計パターンです。

9. 代表的な技術

耐障害性を支える技術には、クラウド基盤、分散データベース、メッセージング基盤などがあります。これらは、冗長化、分散処理、複製、障害切替、キューイング、再試行を実現するために使われます。

代表的な技術領域

9.1 クラウド基盤

クラウド基盤は、耐障害性を実現するための重要な技術基盤です。複数の可用ゾーンにサーバーを配置したり、負荷分散装置を使ったり、マネージドデータベースの複製機能を使ったりすることで、単一障害点を減らせます。自前でデータセンターを運用するよりも、冗長化や拡張を設計しやすい点が大きなメリットです。

ただし、クラウドを使えば自動的に耐障害性が高くなるわけではありません。単一ゾーンにだけ配置している、バックアップを取っていない、権限設定が不適切、監視を設定していない、復旧手順がない、といった状態では障害に弱くなります。クラウド基盤は強力ですが、正しい設計と運用が前提です。

9.2 分散データベース

分散データベースは、データを複数のノードに分散し、複製しながら保持するデータベースです。一部のノードが停止しても、他のノードからデータを読み書きできるように設計されているものがあります。大規模サービスや高トラフィックなシステムでは、耐障害性とスケーラビリティを両立するために使われます。

一方で、分散データベースは通常の単一データベースよりも設計が難しくなります。データの整合性、読み取りの一貫性、書き込み衝突、クエリ制限、運用監視などを理解する必要があります。耐障害性を高めるために分散データベースを使う場合、どのデータにどの程度の整合性が必要かを明確にすることが重要です。

9.3 メッセージング

メッセージング基盤は、耐障害性を高めるために非常に有効です。リクエストをすぐ処理できない場合でも、メッセージとしてキューに保存しておけば、処理側が復旧したあとに再開できます。これにより、一時的な障害や負荷集中を吸収しやすくなります。

たとえば、メール送信サービスが一時的に停止しても、送信要求をキューに保持しておけば、復旧後に順番に送信できます。注文後処理、ログ処理、通知処理、画像変換、データ同期など、非同期化できる処理ではメッセージング基盤がよく使われます。ただし、同じメッセージが複数回処理される可能性があるため、冪等性の設計が重要です。

10. UXとの関係

耐障害性は、ユーザーから見えにくいインフラやシステム設計の話に見えますが、実際にはUXと深く関係しています。障害が起きたときに画面が真っ白になる、何度もエラーが出る、入力内容が消える、決済結果が分からない、といった体験はユーザーの信頼を大きく損ないます。

10.1 障害がUXに直結する

システム障害は、ユーザー体験に直接影響します。ユーザーは、内部でどのサーバーが落ちたか、どのAPIが失敗したかには関心がありません。重要なのは、サービスが使えるか、操作が完了したか、データが失われていないか、安心して使えるかです。

耐障害性が低いシステムでは、少しの障害でユーザー操作が止まり、離脱や不信感につながります。一方、耐障害性が高いシステムでは、一部機能が不安定でも主要機能を維持したり、分かりやすいエラー表示を出したり、後から処理を完了させたりできます。障害時のUX設計は、信頼されるサービスに欠かせません。

10.2 レスポンス安定性が信頼を作る

ユーザーは、毎回安定して反応するサービスに信頼を感じます。たとえば、ページ表示が速いだけでなく、アクセスが集中しても極端に遅くならない、ボタンを押したら確実に反応する、通信が一時的に失敗してもリカバリされる、といった安定性が重要です。

耐障害性は、このレスポンス安定性を支えます。負荷分散、再試行、キュー処理、劣化運転、キャッシュなどを使うことで、システム内部の不安定さをユーザーに見せにくくできます。UXにおいて重要なのは、平常時の美しい画面だけでなく、異常時にもユーザーを不安にさせないことです。

10.3 エラー設計もUXの一部

耐障害性を考えるとき、エラー表示もUXの一部として設計する必要があります。障害が起きたときに、ただ「エラーが発生しました」と表示するだけでは、ユーザーは何をすればよいか分かりません。再試行できるのか、あとで確認すべきなのか、処理は完了しているのか、入力内容は保存されているのかを伝える必要があります。

たとえば、決済処理で通信が不安定になった場合、「もう一度押してください」と安易に表示すると、二重決済のリスクがあります。このような場面では、処理状態を確認し、安全な案内を出す必要があります。耐障害性は裏側の技術だけでなく、障害時にユーザーへどのように伝えるかまで含めて考えるべきです。

11. AI時代の耐障害性

AI時代には、耐障害性の重要性がさらに高まります。AIシステムでは、モデル推論、外部API、GPU基盤、ベクトルデータベース、ワークフローエンジンなど、多くの要素が連携します。どこか一部が不安定になると、応答遅延、推論失敗、出力品質低下、処理停止につながります。

11.1 AIシステムの冗長化

AIシステムでも、冗長化は重要です。たとえば、1つの推論サーバーだけでAI機能を提供している場合、そのサーバーが落ちるとAI機能全体が停止します。複数の推論サーバーを用意し、負荷分散しながら処理することで、一部障害時にもサービスを継続しやすくなります。

また、AIシステムではGPUリソースがボトルネックになることがあります。GPUサーバーが高負荷になった場合、別の推論環境へ切り替える、軽量モデルへ切り替える、処理をキューに入れるなどの設計が必要です。AI時代の耐障害性では、通常のWebサーバーだけでなく、推論基盤そのものの冗長化も重要になります。

11.2 モデル障害切替

AIシステムでは、特定のモデルや外部AIサービスが使えない場合に、代替モデルへ切り替える設計が必要になることがあります。たとえば、高性能モデルが一時的に利用できない場合、軽量モデルや別プロバイダーのモデルへ切り替えることで、完全停止を避けられます。

ただし、モデルを切り替えると出力品質や応答形式が変わる可能性があります。そのため、代替モデルを使う場合は、品質差、応答速度、コスト、ユーザーへの表示方法を考える必要があります。AI機能では、単に応答できればよいのではなく、一定の品質を保つことも重要です。

11.3 自動復旧システム

AI時代には、自動復旧システムも重要になります。システムが異常を検知したら、自動で再起動する、別ノードへ切り替える、処理を再投入する、障害原因を分類する、といった仕組みです。特にAIワークフローでは、複数の処理が連続して動くため、一部失敗時に全体をどう復旧するかが重要です。

自動復旧を設計する際は、何でも自動でやり直せばよいわけではありません。再実行して安全な処理か、二重実行のリスクがあるか、ユーザーへの通知が必要か、手動確認が必要かを分ける必要があります。AIシステムでは、出力の再生成や外部処理の再実行が品質やコストに影響するため、復旧設計が重要になります。

11.4 予測障害対応

AIを使うことで、障害が起きてから対応するだけでなく、障害の兆候を予測する取り組みも可能になります。たとえば、CPU使用率、GPU使用率、メモリ使用量、応答時間、エラー率、キュー滞留数などの変化を分析し、障害が発生する前に対応する設計です。

予測障害対応では、過去の運用データをもとに異常パターンを検知します。たとえば、通常よりも推論時間が長くなっている、特定モデルのエラー率が上昇している、GPUメモリ使用量が継続的に増えているといった兆候を検知し、事前にスケールアウトや再起動を行うことができます。AI時代の耐障害性は、事後対応から予防的運用へ進化していきます。

12. 本質

耐障害性の本質は、「壊れないシステム」を作ることではなく、「壊れても動き続けられるシステム」を作ることです。障害は避けられない前提として扱い、一部の故障が全体停止につながらないように設計します。

耐障害性の本質整理

12.1 「壊れない」ではなく「壊れても動く」

耐障害性では、システムを絶対に壊れないものとして考えません。どれだけ高品質に設計しても、障害は発生します。そのため、重要なのは、壊れたときに全体が止まらない構造を作ることです。1台のサーバーが落ちても別サーバーが処理し、1つの外部APIが失敗しても代替処理を使い、1つの機能が止まっても主要機能は維持する、という考え方です。

この考え方は、現代のクラウド・分散システムでは非常に重要です。完璧に障害を防ごうとすると、コストも複雑性も過剰になります。現実的には、障害が起きても影響範囲を限定し、早く復旧し、ユーザーへの影響を小さくする設計が求められます。

12.2 障害は前提条件

耐障害性では、障害は例外ではなく前提条件です。サーバーは停止することがあり、ネットワークは遅延することがあり、データベース接続は失敗することがあり、外部サービスは期待通りに応答しないことがあります。これらを「滅多に起きない例外」として扱うのではなく、「いつか起きる通常のリスク」として設計します。

障害を前提にすると、設計の考え方が変わります。1つのサーバーに依存しない、外部API失敗時の処理を用意する、データをバックアップする、再試行とタイムアウトを設定する、障害時のユーザー表示を設計する、といった対策が自然に必要になります。耐障害性は、現実を前提にした堅実な設計思想です。

12.3 分散によって耐える設計

耐障害性を高めるには、処理やデータを分散することが重要です。複数のサーバー、複数のノード、複数の地域、複数の処理経路を用意することで、一部の障害が全体に波及しにくくなります。分散によって、システムは単一の故障点に依存しにくくなります。

ただし、分散すれば必ず安全になるわけではありません。分散システムでは、通信失敗、データ不整合、処理重複、監視複雑化といった新しい課題が生まれます。そのため、分散によって耐える設計では、可観測性、整合性、再試行、障害切替をセットで考える必要があります。

12.4 システムの現実的な安定性を作る

耐障害性は、理想論ではなく現実的な安定性を作るための考え方です。すべての障害を完全に防ぐことはできませんが、障害時にどの機能を守るか、どの処理を後回しにするか、どの程度の劣化を許容するかを設計できます。これにより、サービス全体としての安定性を高められます。

現実的な安定性とは、常に完全な状態で動くことではありません。たとえば、レコメンドが一時停止しても購入機能は守る、分析処理が遅れてもユーザー操作は守る、通知が遅延してもデータ保存は守る、といった優先順位が重要です。耐障害性は、システム全体の優先順位を設計することでもあります。

12.5 可用性の核心概念

耐障害性は、可用性を支える核心概念です。可用性とは、ユーザーがサービスを使える状態を維持することです。耐障害性が低いシステムでは、小さな障害でもサービス停止につながりやすく、可用性が低下します。逆に、耐障害性が高いシステムでは、障害が起きてもサービス継続や早期復旧が可能になります。

ただし、可用性を高めるにはコストや複雑性も増えます。そのため、どのレベルの可用性が必要かを事業要件から考える必要があります。すべてのシステムに最高レベルの耐障害性を持たせるのではなく、重要度に応じて適切な設計を選ぶことが実務では重要です。

おわりに

耐障害性とは、障害が起きてもシステム全体を止めにくくするための設計思想です。サーバー停止、ネットワーク障害、データベース障害、外部サービス失敗、処理エラーなどは、現代のシステム運用では避けられないものです。そのため、重要なのは、障害を完全にゼロにすることではなく、障害が発生してもユーザー影響を最小限に抑え、できるだけ早く復旧できる構造を作ることです。

耐障害性を高めるには、冗長化、障害切替、複製、再試行、負荷分散、キューイング、自動復旧、監視などを組み合わせる必要があります。特にクラウドや分散システムでは、一部の構成要素が失敗しても全体が継続できる設計が求められます。ただし、耐障害性を高めるほどコストや複雑性も増えるため、事業要件やシステム重要度に応じたバランスが重要です。

AIシステムや自動化基盤の普及によって、耐障害性の考え方はさらに重要になります。AI推論基盤、複数モデル構成、外部AIサービス連携、GPUリソース、リアルタイム処理など、新しい障害ポイントが増えるからです。耐障害性の本質は、「壊れないこと」ではなく、「壊れてもサービス価値を守り続けること」です。現代のシステム設計では、この考え方が安定運用と信頼性の土台になります。