高可用システム(High Availability, HA)の実現方式
~止められないサービスのために必要な考え方と構成技術~
目次
🔎 概要
可用性(Availability)とは、「システムが使いたいときに使える状態であること」。
ビジネスの継続性や信頼性の根幹に関わるこの要素を支えるのが、高可用性(HA: High Availability)システムです。
この記事では、以下の観点からHAの全体像を解説します:
- 可用性に影響する事象の理解
- 可用性評価の指標(MTBF, SLA等)
- 高可用システムの構成方法(Pacemaker, クラスタ, LB等)
- 地理的・物理的冗長の概念
① 可用性に影響する要因とは?
主な事象
| 種類 | 内容 |
|---|
| 故障・障害 | ハードウェアの劣化、ソフトウェアバグ、オペミスなど |
| 物理障害 | 電源断、HDDクラッシュ、ネットワークケーブル断 |
| 論理障害 | 誤設定、DB破損、ソフトバグによる停止 |
| メンテナンス | 計画停止(アップグレード等)/緊急停止(障害対応等) |
| SPoF(単一障害点) | 一部が壊れるとシステム全体が停止する構成 |
② 可用性の評価指標
以下の指標を使って、可用性を数値的に把握します(試験範囲では計算式不要)。
| 指標 | 意味 |
|---|
| MTBF (Mean Time Between Failures) | 平均故障間隔:障害が起きない平均時間 |
| MTTR (Mean Time To Repair) | 平均修復時間:復旧にかかる平均時間 |
| 稼働率 | 「MTBF ÷ (MTBF + MTTR)」で算出される稼働割合(%) |
| SLA (Service Level Agreement) | サービス提供者が保証する稼働率(例:99.99%) |
| RPO (Recovery Point Objective) | データ損失の許容時間(例:10分前まで復旧可能) |
| RTO (Recovery Time Objective) | サービスを復旧させるまでの目標時間(例:30分以内) |
③ 高可用システムの構成と技術
💡 基本戦略:冗長化(Redundancy)
| 冗長対象 | 概要 |
|---|
| サーバー冗長 | 2台以上のサーバーでサービス提供(フェイルオーバー) |
| ネットワーク冗長 | 複数NIC、ルーター、回線による切替 |
| ストレージ冗長 | RAIDや分散ファイルシステム |
| 電源冗長 | UPS, 二重化電源 |
🛠️ 高可用構成の代表例
| 構成方式 | 説明 |
|---|
| クラスタ構成 | 同一サービスを複数ノードで構成。1台が故障しても他が対応 |
| アクティブ/スタンバイ | 1台が稼働、もう1台が待機(例:Pacemaker構成) |
| ロードバランシング構成 | 複数ノードに負荷分散して同時処理(例:HAProxy, nginx) |
🧩 HAクラスタ管理ソフト
🧠 Pacemaker + Corosync
| コンポーネント | 役割 |
|---|
| Pacemaker | クラスタのリソース管理とフェイルオーバー |
| Corosync | ノード間通信とハートビート管理 |
# 例:Pacemaker構成確認
pcs status
④ 分散構成と可用性
🌐 物理・地理的冗長の違い
| 分散種類 | 説明 |
|---|
| 物理的冗長 | 同一データセンタ内でノードや機器を多重化 |
| 地理的冗長 | 異なるロケーションにバックアップやミラーを配置(災害対策) |
- 地理的冗長は、RPO/RTOの向上と**ディザスタリカバリ(DR)**に有効
- オンプレでは高コスト、クラウド(AWS, Azure)では手軽に導入可能
✅ まとめ:高可用性設計のポイント
| 要素 | 考慮事項 |
|---|
| 可用性指標 | MTBF、MTTR、RPO、RTO、SLA |
| 障害分類 | 物理/論理、計画/緊急停止 |
| 冗長化技術 | RAID, フェイルオーバー, LB, UPS |
| ソフトウェア | Pacemaker, Corosync, Keepalived など |
| 分散構成 | クラスタ、LB、地理的冗長によるDR対応 |
コメント