高可用性と耐障害性を理解する
サーバーの電源が入っていても、注文を受け付けられなければ利用者には使えないサービスです。可用性は業務として利用できるかを見ます。故障しないことだけに頼らず、故障したときも継続・回復する構成を、障害範囲と残った能力から考えます。
この単元で学ぶこと
- 高可用性と耐障害性を停止時間と故障時の継続から説明できる
- 単一障害点と共通の障害範囲を見つけられる
- 冗長化・検知・切替え・バックアップの役割を区別できる
本文解説
可用性を利用者の機能で見る 可用性は必要なときに使える性質です。Webサーバーが動いていても、DBに接続できず全注文が失敗するなら、注文機能の可用性は失われています。対象となる機能、測定期間、許容する応答時間や失敗の条件を明確にして評価します。機器が稼働している時間だけを集計すれば十分とは限りません。
停止時間の比率で考える 学習用に、測定対象が1000分で、そのうち10分利用できなかったとします。利用可能時間は990分なので、時間で測った可用性は990÷1000=99%です。99.9%なら同じ1000分で停止を1分に抑える必要があります。実際の目標では何を停止と数えるかも明確にします。
高可用性と耐障害性 高可用性は停止を起こしにくくし、起きても短くする考え方です。耐障害性は想定した部品の故障下でも必要な機能を継続する性質です。言葉だけで優劣を付けず、「1台停止」「1AZ停止」などの条件で何が続くかを確認します。高可用性の構成でも切替えに時間がかかる場合はあり、停止ゼロを自動保証しません。
台数だけでなく障害範囲を分ける 同じAZへEC2を2台置けば1台の故障へ備えられる場合がありますが、そのAZ全体が使えなくなると両方に影響します。複数AZへ分散し、利用できる処理先へ振り分ける構成を考えます。一方で全Webが一つのDBだけへ依存しているなら、そのDBが単一障害点になります。
残った処理能力を確認する 通常は2台で処理が間に合っても、1台故障後の残り1台で能力が不足すれば、受付を継続できない場合があります。故障時に必要な能力と、追加起動が間に合うかを評価します。冗長化は単に複製を置くことではなく、正常な側が必要な仕事を引き受けられることまで含めて設計します。
検知と切替えも必要 正常性を確認して、異常な処理先へ要求を送り続けない仕組みを用意します。ヘルスチェックが機器の生存しか見なければ、アプリの必要機能の失敗を見逃すことがあります。また切替えがあっても利用者の状態やデータを引き継げなければ継続できません。検知・経路変更・状態の扱いを合わせて考えます。
バックアップは別の目的を補う 冗長化した2台へ同じ誤削除が反映されることがあります。バックアップは過去の状態へ戻すために必要ですが、復元して起動するまで時間がかかるなら、その間は利用できません。複製による継続と、過去データの復元を分けて用意します。
例題：複数リージョンなら必ず適切か 1AZの障害に備える要件だけなら、複数AZで満たせる場合があります。複数リージョンにはさらに広い障害への備えが期待できますが、データ複製や切替え、整合性、費用、運用が増えます。必要な障害範囲と復旧条件から選び、地域を増やすだけで完成と考えないようにします。
図解
重要ポイント
- 業務機能が使えるかを定義して可用性を測る。
- 高可用性でも切替え時間がゼロとは限らない。
- 台数・AZ・共通依存先・故障後の能力を合わせて考える。
- 継続のための冗長化と過去復元のバックアップを分ける。
間違えやすい点
- 2台あるだけでAZ障害まで耐えると判断しない。
- ロードバランサー追加だけで全データや状態が複製されると思わない。
- 要件を超えて複数リージョンを使うことが常に最良とは限らない。
用語解説
- 可用性
- 必要なときにシステムを利用できる性質。測定期間中に利用可能だった時間の比率などで評価する。
- 高可用性
- 停止の発生や継続時間を抑え、利用できる状態を高い水準で保つこと。短い切替え時間もゼロになるとは限らない。
- 耐障害性
- 想定した構成要素の故障が起きても、必要な機能を継続できる性質。どの故障まで耐えるかを具体的に定める。
- 単一障害点
- その一か所が故障すると、他が正常でも全体の必要な機能を失う箇所。
- 冗長化
- 必要な機能を複数の構成要素で提供できるようにすること。同時に止まる共通の依存先にも注意する。
- ヘルスチェック
- 処理先が正常に応答できるかを確認し、振り分けや復旧判断に用いる検査。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。