可用性と耐障害性の違いとは？初心者向けに意味・設計・確認方法をわかりやすく解説
可用性は「必要なときにシステムを利用できる度合い」、耐障害性は「障害が発生しても処理やサービスを継続できる能力」です。
可用性はサービス全体の利用しやすさを表す考え方であり、耐障害性は可用性を高めるための仕組みの一つです。
例えば、サーバーが故障しても待機系サーバーへ自動で切り替わり、利用者が業務を続けられるシステムは耐障害性が高く、結果として高い可用性を実現できます。
可用性とは
可用性とは、システムやサービスが必要なときに正常に利用できる度合いです。英語ではAvailabilityと呼びます。
サーバーが起動しているだけでは、必ずしも利用可能とはいえません。ネットワーク障害、認証障害、アプリケーション停止、データベース障害などによって利用者が操作できなければ、可用性は低下します。
可用性が関係する場面
- 社内システムへログインできるか
- Webサイトを継続して閲覧できるか
- メールやチャットを利用できるか
- 共有フォルダへアクセスできるか
- 業務時間中にシステムが停止しないか
耐障害性とは
耐障害性とは、サーバー、ネットワーク機器、ディスクなどの一部で障害が発生しても、システム全体を停止させずに処理を継続できる能力です。英語ではFault Toleranceと呼びます。
単に障害から早く復旧するだけではなく、障害発生中もサービスを継続できることが重要です。
耐障害性を高める仕組み
- サーバーを複数台構成にする
- ロードバランサーで通信を分散する
- ディスクをRAID構成にする
- 電源やネットワーク回線を二重化する
- データベースをレプリケーションする
- 障害時に待機系へ自動切り替えする
可用性と耐障害性の違い
| 比較項目 | 可用性 | 耐障害性 |
|---|---|---|
| 英語 | Availability | Fault Tolerance |
| 意味 | 必要なときに利用できる度合い | 障害が起きても継続できる能力 |
| 考え方 | サービス全体の結果 | 障害へ備える技術や設計 |
| 主な指標 | 稼働率、停止時間 | 切り替え可否、冗長構成 |
| 目的 | 利用できる時間を増やす | 障害による停止を防ぐ |
| 関係 | 最終的に実現したい状態 | 可用性を高める手段の一つ |
身近な例で違いを理解する
コンビニエンスストアに例えると、営業時間中に買い物ができる状態が可用性です。
一方、1台のレジが故障しても別のレジで会計を続けられる仕組みが耐障害性です。
別のレジがあっても停電で店舗全体が閉店すれば、サービスは利用できません。つまり、耐障害性を高めるだけで、すべての可用性問題を防げるわけではありません。
稼働率で見る可用性
可用性は、稼働率で表されることがあります。基本的な計算方法は次のとおりです。
稼働率＝稼働時間÷全体時間×100
| 稼働率 | 年間停止時間の目安 |
|---|---|
| 99％ | 約3日15時間 |
| 99.9％ | 約8時間46分 |
| 99.99％ | 約52分 |
| 99.999％ | 約5分 |
稼働率の小数点以下が一つ増えるだけでも、許容される停止時間は大きく短くなります。その分、冗長化、監視、運用体制などにかかる費用も増える傾向があります。
可用性を高める主な方法
- サーバーやネットワークを冗長化する
- システムを定期的に監視する
- 障害発生時の復旧手順を整備する
- バックアップを取得する
- 予防保守やセキュリティ更新を行う
- 変更作業の手順と切り戻し方法を準備する
- 運用担当者への連絡体制を整える
可用性には技術だけでなく、監視、運用手順、担当者の対応速度も影響します。
耐障害性を高める主な方法
冗長化
同じ役割を持つ機器やサーバーを複数用意します。1台が故障しても、別の機器で処理を継続できます。
フェイルオーバー
稼働中のシステムに障害が発生した際、待機系へ処理を切り替える仕組みです。自動切り替えと手動切り替えがあります。
ロードバランシング
ロードバランサーを使い、複数のサーバーへ通信を振り分けます。障害が発生したサーバーを通信先から外すことで、正常なサーバーだけで処理を継続できます。
データの複製
データベースやストレージのデータを別環境へ複製します。ただし、誤削除やデータ破損も複製される場合があるため、バックアップも必要です。
どのような場面で使われるのか
高い可用性が必要なシステム
- 金融機関の決済システム
- 医療機関の電子カルテ
- ECサイト
- 社内の認証基盤
- メールやチャットなどのコミュニケーション基盤
高い耐障害性が必要なシステム
- 24時間稼働が必要なサーバー
- 停止すると売上や業務へ大きく影響するシステム
- Active DirectoryやDNSなどの基盤サービス
- データベースサーバー
- ネットワークの中核機器
実際のIT現場での利用例
| 構成 | 目的 | 関係する考え方 |
|---|---|---|
| Webサーバーを2台にする | 1台故障時もサービスを継続する | 耐障害性 |
| 24時間の監視を行う | 障害を早期発見して停止時間を短くする | 可用性 |
| DNSサーバーを複数台にする | 名前解決の停止を防ぐ | 耐障害性 |
| 復旧手順書を整備する | 障害から早く復旧する | 可用性 |
| 別リージョンへシステムを配置する | 大規模障害時も継続する | 耐障害性と可用性 |
初心者が混乱しやすいポイント
冗長化すれば必ず高可用になるわけではない
サーバーを2台用意しても、両方が同じ電源、同じネットワーク、同じストレージを使用している場合、共通部分の障害で両方停止する可能性があります。
この共通の弱点をSPOF（Single Point of Failure）、日本語では単一障害点と呼びます。
障害から早く復旧することと、止まらないことは違う
バックアップから1時間で復旧できるシステムは復旧性が高いといえますが、その1時間はサービスが停止しています。
障害発生中もサービスを継続する耐障害性とは別の考え方です。
メンテナンス停止も可用性へ影響する
機器故障だけでなく、Windows Update、アプリケーション更新、設定変更に伴う計画停止も可用性へ影響します。
可用性と信頼性の違い
信頼性は、一定期間に故障せず正常に動作できる性質です。英語ではReliabilityと呼びます。
可用性は、故障したかどうかだけでなく、故障後にどれだけ早く復旧できたかも含めて評価します。
- 信頼性：故障しにくいか
- 耐障害性：故障しても続けられるか
- 可用性：最終的に利用できる時間が長いか
業務でよくあるトラブル
待機系へ切り替わらない
- フェイルオーバー設定に誤りがある
- 監視機能が障害を検知できていない
- 待機系サーバーが停止している
- データ同期が完了していない
- 切り替えに必要な権限が不足している
サーバーは正常だがサービスを利用できない
- DNSで名前解決できない
- Active Directoryの認証に失敗している
- ロードバランサーが異常な接続先へ通信している
- データベースへ接続できない
- ファイアウォールで通信が拒否されている
冗長構成なのに全台停止する
- 共通ストレージが故障した
- 同じ設定ミスが全台へ反映された
- 共通のネットワーク機器が停止した
- 同一拠点の電源が停止した
- 証明書の期限切れが全台で発生した
障害発生時の確認順序
- 利用できない機能と影響を受けている利用者を確認する
- 問題の発生時刻を確認する
- 全体障害か一部障害かを切り分ける
- サーバー、ネットワーク、認証、DNSの状態を確認する
- 監視アラートとログを確認する
- 冗長構成やフェイルオーバーの状態を確認する
- 直前の変更作業を確認する
- 復旧または切り替え方法を判断する
影響範囲の切り分け
| 確認対象 | 確認内容 |
|---|---|
| ユーザー側 | 特定ユーザーや特定端末だけか |
| Windows側 | サービス停止やOSエラーがないか |
| ネットワーク側 | 通信経路やロードバランサーが正常か |
| Active Directory側 | 認証やドメインコントローラーが正常か |
| DNS側 | 正しいIPアドレスを返しているか |
| サーバー側 | 各ノードとアプリケーションが正常か |
| データベース側 | 接続、同期、応答時間に問題がないか |
Windowsで状態を確認する方法
GUIで確認する方法
- Ctrl＋Shift＋Escを押してタスクマネージャーを開く
- 「パフォーマンス」でCPU、メモリ、ディスク、ネットワークを確認する
- Windowsキー＋Rを押す
- 「services.msc」と入力してサービス一覧を開く
- 対象サービスが実行中か確認する
イベントビューアーで確認する方法
- Windowsキー＋Rを押す
- 「eventvwr.msc」と入力してEnterキーを押す
- 「Windowsログ」の「システム」を開く
- 「アプリケーション」も確認する
- 障害発生時刻付近のエラーと警告を探す
イベントID、ソース、発生日時、エラー内容を記録します。フェイルオーバークラスターを利用している場合は、クラスター関連のイベントも確認してください。
CUIで確認する方法
コマンドプロンプト
ping 接続先のホスト名
接続先との基本的な通信を確認できます。ただし、pingが成功してもサービスが正常とは限りません。
nslookup 接続先のホスト名
DNSが正しいIPアドレスを返しているか確認できます。
netstat -ano
待受ポートや通信状態を確認できます。
sc query サービス名
Windowsサービスの状態を確認できます。
PowerShell
Get-Service
Windowsサービスの一覧と実行状態を確認できます。
Test-NetConnection 接続先 -Port ポート番号
対象サーバーの特定ポートへ接続できるか確認できます。
Get-WinEvent -LogName System -MaxEvents 50
システムログの直近50件を確認できます。
確認結果の見方
| 確認結果 | 考えられる原因 | 次の確認 |
|---|---|---|
| 特定ユーザーだけ利用できない | 端末、アカウント、権限の問題 | 別端末や別ユーザーで確認する |
| 全ユーザーが利用できない | サーバー、ネットワーク、認証基盤の障害 | 監視と共通基盤を確認する |
| 1台のサーバーだけ異常 | 個別ノードの障害 | ロードバランサーから切り離す |
| 待機系も異常 | 共通設定や単一障害点の問題 | 電源、回線、ストレージを確認する |
| 名前解決だけ失敗する | DNS障害 | DNSサーバーと登録情報を確認する |
筆者が現場で経験した失敗例
以前、Webサーバーを2台構成にしていたため、1台が停止しても問題ないと考えていました。しかし、2台とも同じデータベースサーバーへ接続しており、そのデータベースが停止するとWebサービス全体が利用できなくなりました。
Webサーバーは冗長化されていましたが、データベースが単一障害点になっていたため、システム全体の耐障害性は十分ではありませんでした。
その後、データベース、ロードバランサー、ネットワーク経路を含めて構成を見直し、定期的に切り替えテストを行う運用へ変更しました。
初心者がやりがちなミス
- サーバーを2台にしただけで高可用だと判断する
- 単一障害点を確認しない
- 待機系サーバーの監視を行わない
- 切り替え手順を用意していない
- 冗長構成の動作テストを実施しない
- バックアップと耐障害性を同じものだと考える
- 障害時に承認なくフェイルオーバーを実行する
高可用性設計の注意点
可用性や耐障害性を高めるほど、機器、クラウド利用料、監視、保守などのコストが増えます。すべてのシステムを同じ水準にするのではなく、業務への影響に応じて必要なレベルを決めます。
冗長化していても、バックアップは必要です。誤削除、ランサムウェア、設定ミスなどは複数のサーバーへ同時に反映される可能性があります。
本番環境でフェイルオーバーを実行すると、通信断やデータ不整合が発生する場合があります。手順、承認、切り戻し方法を確認してから実施してください。
上司へ報告するポイント
- 障害の発生日時
- 利用できないサービスや機能
- 影響を受けている利用者と業務
- 正常なサーバーと異常なサーバー
- フェイルオーバーの実施状況
- 監視アラートとエラーログ
- 単一障害点の有無
- 想定される復旧時間
- 実施した確認と対応内容
「システムが停止しています」だけでなく、「Webサーバー1号機が停止しましたが、2号機へ自動切り替え済みで、利用者への影響は確認されていません」のように、現在の利用可否を明確に報告します。
エスカレーションするタイミング
- 本番サービスが利用できない
- 冗長構成が正常に動作していない
- 待機系への切り替えが必要
- 複数のサーバーや拠点へ影響している
- データ不整合の可能性がある
- 単一障害点が原因で全体停止している
- 復旧見込みを判断できない
- 設定変更や再起動に承認が必要
現場で評価される確認手順
- 利用者から見たサービスの利用可否を確認する
- 影響範囲と発生時刻を整理する
- 正常系と異常系を分けて確認する
- 監視、イベントログ、アプリケーションログを確認する
- ネットワーク、DNS、認証、データベースを切り分ける
- 冗長構成と切り替え状態を確認する
- 事実と数値をまとめて報告する
応用知識
HAとは
HAはHigh Availabilityの略で、日本語では高可用性と呼ばれます。障害やメンテナンスによる停止時間をできるだけ短くする設計です。
SLAとは
SLA（Service Level Agreement）は、サービス提供者と利用者の間で定めるサービス品質の合意です。稼働率やサポート時間などが示される場合があります。
フェイルバックとは
障害時に待機系へ切り替えた後、復旧した元の環境へ処理を戻すことです。データ同期や停止時間を確認して実施します。
関連するIT用語
- HA（High Availability）
- Fault Tolerance
- 冗長化
- フェイルオーバー
- フェイルバック
- ロードバランサー
- SPOF（Single Point of Failure）
- SLA（Service Level Agreement）
- 信頼性
- 保守性
- バックアップ
- レプリケーション
よくある質問
可用性が高ければ障害は発生しませんか？
障害が発生しないわけではありません。障害が起きても影響を小さくし、早く復旧することで、利用できる時間を長くします。
耐障害性と冗長化は同じですか？
同じではありません。冗長化は耐障害性を高めるための方法です。複数台構成でも、切り替えられなければ十分な耐障害性を得られません。
バックアップがあれば耐障害性は高いですか？
バックアップは障害後の復元に役立ちますが、復元中はサービスが停止する可能性があります。障害中も継続する耐障害性とは目的が異なります。
クラウドを利用すれば自動的に高可用になりますか？
クラウドを利用するだけでは高可用になりません。複数ゾーンへの配置、ロードバランサー、データ複製、監視などを適切に設計する必要があります。
可用性と耐障害性はどちらが重要ですか？
どちらか一方ではなく、業務要件に応じて考えます。最終的な目標は必要な可用性を確保することであり、その実現方法として耐障害性、監視、保守、復旧手順などを組み合わせます。
まとめ
可用性と耐障害性は似ていますが、意味は異なります。
- 可用性は必要なときにシステムを利用できる度合い
- 耐障害性は障害が発生しても処理を継続できる能力
- 耐障害性は可用性を高めるための手段の一つ
- 冗長化だけでなく、監視や復旧手順も可用性へ影響する
- 構成全体から単一障害点を探すことが重要
- 冗長構成は定期的に切り替えテストを行う
「利用できる状態を表すのが可用性、障害が起きても続ける力が耐障害性」と覚えると整理しやすくなります。障害対応では、機器が動いているかだけでなく、利用者が実際に業務を継続できているかを確認することが大切です。