ハイアベイラビリティとは?システムを止めないための高可用性設計

システム開発・テクノロジー
ハイアベイラビリティとは?ざっくりと3行で
  • システムが障害やメンテナンスが発生しても「ほぼ停止することなく連続稼働できる状態を維持する」ための設計思想・構成のこと。「HA」と略されることが多い
  • 可用性は「稼働率(Availability)」で表され、99.9%(ナインスリー:年間8.7時間のダウンタイム許容)99.99%(フォーナイン:年間約52分のダウンタイム許容)などの目標値を設定する
  • 冗長化(サーバー・ネットワーク・電源の二重化)・負荷分散・フェイルオーバー(障害時の自動切り替え)を組み合わせることで、単一障害点(SPOF)をなくすことがHA設計の核心だ

【深掘り】これだけ知ってればOK!

可用性の「ナイン」による表現を整理しよう。99.9%(スリーナイン):年間ダウンタイム約8.7時間。99.99%(フォーナイン):年間約52分。99.999%(ファイブナイン):年間約5.2分。99.9999%(シックスナイン):年間約31秒。金融・医療・インフラシステムではファイブナイン以上が求められることが多い。可用性を上げるほどコストが指数関数的に増大するため、業務要件に見合う目標値の設定が重要だ。

HA実現のための主要な技術を整理しよう。冗長化(Redundancy):サーバー・ネットワーク機器・電源・データセンターを複数用意して単一障害点をなくす。負荷分散(Load Balancing):ロードバランサーで複数のサーバーにリクエストを分散し、1台が落ちても他のサーバーで処理を継続する。フェイルオーバー(Failover):プライマリシステムに障害が発生した際にスタンバイシステムへ自動的に切り替える仕組み。ヘルスチェック:サーバーの死活監視を行い異常を検知して自動的に切り離す。

クラウド環境でのHA設計の標準パターンとして、マルチAZ(アベイラビリティゾーン)構成がある。AWSではリージョン内の複数のAZ(物理的に分離されたデータセンター群)にサーバーを分散配置することで、1つのAZが障害を起こしても別のAZで継続稼働できる。RDSのMulti-AZ・ELB(Elastic Load Balancer)・Auto Scalingを組み合わせることがAWSでの標準的なHA構成だ。

HA設計で必ず考慮すべきRTO(Recovery Time Objective:目標復旧時間)とRPO(Recovery Point Objective:目標復旧時点)を理解しよう。RTOは「障害発生からサービス再開まで何分以内に復旧するか」の目標値。RPOは「障害発生時に最大どの時点までのデータ損失を許容するか」の目標値。これらを事前にビジネス要件として定義しておくことが、適切なHA構成選択の根拠になる。

HAと密接に関連する概念としてDR(Disaster Recovery:災害対策)がある。HAは主にシステム障害への対策で同一サイト内や近距離での冗長化が多い。DRは地震・洪水などの大規模災害で主サイト全体が使えなくなる状況への対策で、地理的に離れた場所にバックアップサイトを用意する。HAとDRを組み合わせたBCP(事業継続計画)の設計が企業の重要システムには必要だ。

よくある誤解

ハイアベイラビリティ=バックアップを取ることだと思っている

バックアップはデータを保護するためのもので、HAとは別の概念だ。HAはシステムが止まらずに稼働し続けるための冗長化・フェイルオーバーの仕組みで、バックアップからの復旧はRTOの観点から時間がかかりすぎてHAの要件を満たせないことが多い。

HAを実現すればシステムは絶対に止まらないと思っている

100%の可用性は現実的には不可能で、HAはダウンタイムを最小化するための設計だ。定期的なメンテナンス・ソフトウェア更新・予期しない障害に対してもある程度のダウンタイムは発生する。適切な目標稼働率(SLA)を定めてビジネス要件と照らし合わせることが重要だ。

会話での使われ方

ITKAGYO運営者デプロイ太郎のアイコン画像

このシステム、DBが1台しかないのでSPOF(単一障害点)になっています。MySQL Multi-AZに変更してフェイルオーバーを自動化しましょう。

インフラエンジニアがシステムの可用性の問題を指摘して改善策を提案している場面。

ITKAGYO運営者デプロイ太郎のアイコン画像

SLAで99.99%の可用性を約束しているので、年間のダウンタイム許容は52分です。今年のインシデントで既に30分消費しているので残り22分です。

サービスマネージャーがSLAの達成状況をチームに共有している場面。フォーナインの可用性目標をダウンタイム許容時間として具体的に管理している。

ITKAGYO運営者デプロイ太郎のアイコン画像

マルチAZ構成にしてからAZのどれかに障害が発生しても自動フェイルオーバーで30秒以内にサービスが復旧するようになりました。

クラウドインフラエンジニアがHA構成の改善効果をチームに報告している場面。

【まとめ】3つのポイント

  • 稼働率で表す目標値に向けて冗長化・フェイルオーバーを実装する:スリーナイン(99.9%)からファイブナイン(99.999%)まで可用性の目標値を定めてビジネス要件とコストのバランスを取り、単一障害点をなくす設計で目標を達成する
  • SPOF(単一障害点)をなくすことがHA設計の核心:サーバー・DB・ネットワーク・電源のどこか1箇所の障害でシステム全体が停止するSPOFを特定して冗長化することが、HA設計の出発点となる考え方だ
  • RTO・RPOを先にビジネス要件として定義してから設計する:目標復旧時間(RTO)と目標復旧時点(RPO)をビジネス側が求める要件として先に定義し、それを満たすHA構成を選択するというアプローチが適切なコストと可用性のバランスを実現する

よくある質問

Q
99.9%と99.99%の可用性の違いを年間ダウンタイムで教えてください。
A

99.9%(スリーナイン)は年間約8.7時間のダウンタイムが許容されます。99.99%(フォーナイン)は年間約52分。99.999%(ファイブナイン)は年間約5.2分です。ナインが増えるほど許容ダウンタイムは10分の1になりますが、実現コストは大幅に増加します。

Q
AWSでのHA構成の基本パターンを教えてください。
A

基本的なHA構成は、複数AZにEC2インスタンスを配置してELB(Elastic Load Balancer)で負荷分散し、RDSをMulti-AZ設定にしてDBの自動フェイルオーバーを有効化し、Auto Scalingでインスタンスの自動増減を設定するというパターンです。

Q
SPOFとは何ですか?
A

SPOF(Single Point of Failure:単一障害点)とは、その箇所が障害を起こすとシステム全体が停止してしまう箇所のことです。HAを実現するためには、システムの全ての構成要素を見渡してSPOFを特定し、それぞれを冗長化することが必要です。

Q
ハイアベイラビリティとフォールトトレランスの違いは何ですか?
A

HAは障害が発生した際に素早く自動切り替えしてサービスを再開する設計で、瞬間的なダウンタイムを許容します。フォールトトレランス(耐障害性)は障害が発生しても全くダウンタイムなしに動作し続ける設計で、より高度な冗長化が必要でコストも高くなります。

この用語と一緒に知っておきたい用語

用語 この記事との関連
可用性 可用性は関連分野でよく登場する重要キーワードです。必要なときにシステムを使える状態を維持し続ける能力のこと。英語でAvailabilityといい、情報セキュリティの三大要素(CIA)の一つに数えられる
ダウンタイム 次のステップとしてダウンタイムを学ぶと知識が広がります。サーバーやシステムが停止してサービスを利用できなくなる時間のこと。計画的なメンテナンス停止と突発的な障害による停止の2種類がある
冗長化 冗長化を押さえると本記事の理解がさらに深まります。障害が発生しても継続稼働できるように、同じ役割を持つコンポーネントを複数用意するシステム設計の手法だ
フェイルオーバー フェイルオーバーを押さえると本記事の理解がさらに深まります。システムや機器に障害が発生したとき自動的にスタンバイ機・バックアップシステムに切り替えてサービスの継続を実現する仕組みのこと
サーバー サーバーを押さえると本記事の理解がさらに深まります。ネットワークを通じて情報やサービスを提供する側のコンピューターのこと。レストランで料理を運んでくれる給仕係(server)をイメージするとわかりやすいよ

【出典】参考URL

https://docs.aws.amazon.com/ja_jp/whitepapers/latest/real-time-communication-on-aws/high-availability-and-scalability-on-aws.html :AWSのHA設計ホワイトペーパー
https://learn.microsoft.com/ja-jp/azure/architecture/framework/resiliency/reliability-patterns :Azureの信頼性パターン(HA設計)
https://cloud.google.com/architecture/framework/reliability?hl=ja :GCPのアーキテクチャフレームワーク信頼性

コメント

「IT用語、難しすぎて心が折れそう……」という方のための、ハードル低めな用語辞典です。

情報レベルは「基礎中の基礎」。会話を止めないためのエッセンスだけを抽出しています。分かりやすさを追求するあまり、時々例え話が暴走しているかもしれませんが、そこは「ほどよく」聞き流していただけると幸いです。
ほどよくIT用語辞典システム開発・テクノロジー
デプロイ太郎のSNSを見てみる!!