Instiq
第4章 · 非機能設計·v1.0.0·更新 2026/7/11·読了目安 約17分

変更要約: 初版

4.3可用性と災害対策

この節の要点

目標可用性からどの冗長構成を選ぶかという判断、複数サーバで単一システムのように振る舞うHAクラスタ、大規模災害に備えるDR(ディザスタリカバリ)BCP(事業継続計画)、そして復旧目標を定量化するRTO(目標復旧時間)RPO(目標復旧時点)を学びます。

前節では単一データセンター内の冗長化(直列/並列の稼働率計算)を扱いましたが、実務ではそれだけでは対応できない大規模災害(地震・火災・広域停電)によるデータセンター全体の喪失にも備える必要があります。ここで重要になるのが、「どれだけ早く復旧させるか」「どれだけのデータ損失まで許容するか」という2つの復旧目標を、業務の重要度に応じて定量的に定めることです。この節では、HAクラスタによる可用性向上、DR/BCPの考え方、そしてRTO/RPOという2つの指標を踏まえ、目標可用性と災害対策のレベルをコストと天秤にかけてどう設計するかを判断する力を養います。

4.3.1目標可用性からの構成判断

  • システムアーキテクトは、業務要件から目標可用性(例:99.9%/99.99%/99.999%)を定め、それを満たす構成を前節の直列/並列計算で逆算する。可用性が1桁(9の数)増えるごとに許容ダウンタイムは約10分の1になる(99.9%=年間約8.76時間、99.99%=年間約52.6分、99.999%=年間約5.3分)ため、目標を1桁上げるだけで実現コストが跳ね上がることをステークホルダーに説明できる必要がある。
  • 目標可用性を過剰に高く設定すると、並列化する構成要素の数や、後述のDR環境の常時稼働などでコストが指数的に増える。したがって設計判断としては、業務が実際に要求する可用性を見極め、過剰品質(オーバースペック)を避けつつ、単一障害点だけは残さないという優先順位で構成を選ぶことが重要である。

4.3.2HAクラスタ

  • HAクラスタ(High Availability Cluster)=複数のサーバを1つのシステムのように連携させ、稼働系(アクティブ)が故障した際に待機系(スタンバイ)へ自動的に処理を引き継ぐフェイルオーバーの仕組み。Active-Standby(待機冗長)=平常時は1台のみ処理し、もう1台は待機専用(切替に多少の時間を要するがシンプルでコストが低い)。Active-Active(多重系)=複数台が同時に処理を分担し、1台故障時も残りが処理を継続(切替が速く処理能力も活かせるが構成が複雑)。
  • フェイルオーバーの判断で重要なのは、切替に要する時間(フェイルオーバー時間)が業務の許容ダウンタイムに収まるかである。Active-Standbyはコストを抑えられる一方、待機系の起動や状態同期に時間がかかりダウンタイムが生じやすい。Active-Activeはこの切替時間をほぼゼロに近づけられるが、常時2台以上を稼働させるコストと、データ整合性を保つための同期機構の複雑さを伴う。

続きは無料登録で読めます

冒頭を無料で公開中。無料登録でこの節の全文と、第4章以降を含む全参考書・全問題集が読めます。