高可用性設計

高可用性とは

高可用性(HA: High Availability)は、障害が起きてもサービスをできるだけ止めない性質のことです。サーバーもネットワークもいつかは必ず壊れます。「壊れない前提」ではなく「壊れても止まらない設計」を目指すのが高可用性設計です。

可用性は稼働率(全時間のうちサービスが使えた時間の割合)で表します。「99.9%」なら年間の停止は約8.8時間まで、「99.99%」なら約53分まで、という具合に、9の数が増えるほど許される停止時間が短くなります。

単一障害点をなくす

高可用性設計の出発点は、単一障害点(SPOF: Single Point of Failure — そこが壊れると全体が止まる箇所)を見つけてなくすことです。基本戦略は冗長化(同じ役割の機器・サーバーを複数用意すること)です。

「ロードバランサを入れたのにロードバランサ自身が単一障害点」のように、冗長化は一段ずつ検証していく必要があります。

フェイルオーバー

冗長化した構成で、障害時に予備系へ自動で切り替わる仕組みをフェイルオーバーと呼びます。

• アクティブ・スタンバイ — 普段は1台が処理し、障害時に待機系が引き継ぐ
• アクティブ・アクティブ — 全台が普段から処理を分担し、1台落ちても残りでカバーする

切り替えには「壊れたことの検知」が前提になるため、[[監視とアラート]] やヘルスチェックの整備とセットで機能します。

初学者向けポイント

• 可用性はコストとのトレードオフ — 9を1つ増やすごとに構成は複雑に、費用は大きくなる。要件に見合う水準を選ぶ
• [[スケーリング]] のための複数台構成は、そのまま可用性向上にも効く(一石二鳥)
• 単一のデータセンター全体が使えなくなる規模の災害への備えは [[災害復旧(DR)]] の領域 — アベイラビリティゾーンとリージョンの違いは [[クラウドコンピューティング]] で整理している
• 同じ「可用性」でも [[CAP定理と分散データベース]] の A は意味が違う — あちらは分断中も各ノードが古い値でも応答を返すこと、こちらは冗長化とフェイルオーバーでサービスを止めないこと
• まず自分のシステム図を描いて「ここが壊れたらどうなる?」を全部に問うのが設計の第一歩

関連技術とのつながり

• [[ロードバランサ]] — サーバー冗長化の要。ヘルスチェックで故障機を切り離す
• [[レプリケーション]] — データベース層の冗長化手段
• [[災害復旧(DR)]] — 拠点ごと失われる規模の障害への備え。高可用性の延長線
• [[スケーリング]] — 複数台構成は性能と可用性の両方に効く
• [[監視とアラート]] — 障害の検知なしにフェイルオーバーは機能しない
• [[エラーハンドリングとリトライ設計]] — 冗長化では防げないカスケード障害をアプリ層で止める

Q: 単一障害点(SPOF)の説明として正しいのはどれ?
- [x] そこが壊れるとシステム全体が止まってしまう箇所
- [ ] 障害が絶対に起きないよう保証された機器
- [ ] 障害の記録を保存しておく場所
解説: SPOF はそこの故障が全体停止に直結する箇所で、冗長化によってなくしていくのが高可用性設計の基本です。

Q: 高可用性設計の基本戦略はどれ?
- [ ] 壊れない高級な機器を1台だけ使う
- [x] 同じ役割の機器やサーバーを複数用意して冗長化する
- [ ] 障害が起きたら手動で機器を買いに行く
解説: どんな機器も壊れる前提に立ち、複数用意して1つの故障に耐えられるようにする冗長化が基本戦略です。

Q: フェイルオーバーの説明として正しいのはどれ?
- [ ] 障害の原因を後から分析する会議のこと
- [ ] サーバーの性能を段階的に上げること
- [x] 障害時に予備系へ自動で切り替わる仕組みのこと
解説: フェイルオーバーは障害検知をきっかけに待機系や残りの系へ処理を引き継ぐ仕組みです。