高可用性と耐障害性のシナリオ判断
注文サイトにはWebサーバーが2台あります。しかし「2台あるから止まらない」という報告だけでは十分ではありません。配置先、DB、処理能力、正常性検査、データ復旧を追い、どの障害を乗り越えられるのかを具体的に判断します。
この単元で学ぶこと
- 構成図と障害条件から残る単一障害点を指摘できる
- 故障後の能力を計算し業務継続を評価できる
- 切替え試験とバックアップ復元試験を分けて設計できる
本文解説
事例の条件 Webは2台、1台あたり毎秒100件を処理できると仮定します。通常の要求は毎秒150件です。2台は同じAZにあり、DBもそのAZの1台だけです。この例の能力値は学習用の仮定で、製品の性能保証ではありません。まず構成要素と依存関係を書き出します。
故障1：Webが1台停止 平常時の合計能力は毎秒200件で足りますが、1台停止後は100件になります。要求150件を満たせないため、残ったサーバーが稼働しているだけでは業務要件を満たしません。追加起動の時間や事前の余裕を含め、故障後も必要能力を保つ構成を考えます。
故障2：AZ全体が使えない 2台とも同じAZなら両方が影響を受けます。別AZへ分散するとその範囲の故障へ備えられますが、DBが元のAZに1台だけなら、Webだけ生き残っても注文を記録できないかもしれません。部品単位ではなく、注文受付の一連の依存関係を確認します。
故障3：プロセスは生きているが業務は失敗 ヘルスチェックが単に固定の成功文字列を返すだけでは、実際の注文処理の不具合を検出しない場合があります。必要な機能を代表する検査を設計します。ただし依存先の一時的な遅延だけで全処理先を同時に外してしまうこともあるため、判定条件と振り分けの結果を検証します。
切替えで失われる状態 障害サーバーのメモリだけにカート情報があれば、正常な別サーバーへ移しても利用者は作業を続けられない場合があります。共有可能な保存先などで必要な状態を維持し、再試行した注文が二重にならないよう設計します。通信先を変える機能と業務の継続は別の段階です。
誤削除と復元 複数AZにデータを複製していても、誤った更新が全てへ反映される可能性があります。バックアップから必要な時点へ戻せるかを試験します。復元時間や、最後に復元できるデータの時点を測定し、業務が許容する条件と照合します。正常系へ切り替えるだけの試験では、この能力は分かりません。
広い災害への追加対策 要件がAZの障害を超え、リージョン全体を利用できない場合も含むなら、別リージョンへの復旧や継続を検討します。配置先を増やすだけでなく、データ、ネットワーク、必要なサービス設定、切替え手順を準備します。別リージョンが元リージョンへ常時依存していては独立に稼働できないおそれがあります。
例題：合格とする条件 Web1台停止の試験なら、停止を検知して正常側へ要求を送り、必要な処理件数と応答時間を満たし、注文が失われないことを確認します。AZ障害ならDBを含む別AZでの継続も対象にします。「台数が2と表示される」ことは構成情報であって、この試験の合格基準ではありません。
図解
重要ポイント
- 毎秒150件を1台100件では処理し切れない。
- WebのAZ分散だけで共通DBの障害は解決しない。
- 検知・切替え先・状態保持・残存能力を試験する。
- AZ障害、リージョン障害、誤更新の復旧は異なる条件として扱う。
間違えやすい点
- 余剰台数の存在だけで障害時性能を保証しない。
- 固定文字列の成功だけを業務の正常性とみなさない。
- 別リージョンへ置いただけで元リージョンへの依存が消えたと思わない。
用語解説
- 可用性
- 必要なときにシステムを利用できる性質。測定期間中に利用可能だった時間の比率などで評価する。
- 高可用性
- 停止の発生や継続時間を抑え、利用できる状態を高い水準で保つこと。短い切替え時間もゼロになるとは限らない。
- 耐障害性
- 想定した構成要素の故障が起きても、必要な機能を継続できる性質。どの故障まで耐えるかを具体的に定める。
- 単一障害点
- その一か所が故障すると、他が正常でも全体の必要な機能を失う箇所。
- 冗長化
- 必要な機能を複数の構成要素で提供できるようにすること。同時に止まる共通の依存先にも注意する。
- ヘルスチェック
- 処理先が正常に応答できるかを確認し、振り分けや復旧判断に用いる検査。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。