マルチAZ構成における可用性テスト

この記事の背景

コードを書く作業と、マネジメントの作業を行ったりきたりすると忘れるので、自分のために
メモ

可用性とは

「可用性（Availability）」とは、システムやサービスが必要なときに継続して利用できる状態を維持できる能力のことを指します。言い換えると、ダウンせずに使い続けられるかどうかです。

---

✅ 可用性の計算方法

可用性 = 稼働時間 ÷ 総時間

たとえば、1年間（365日 = 8760時間）のうち、ダウンしていたのが8.76時間だけなら：

$$可用性 = \frac{8760 - 8.76}{8760} = 99.9\%$$

---

✅ SLA（Service Level Agreement）と可用性

多くのクラウドベンダーやインフラでは、SLAとして可用性の目標値を設定しています：

可用性 (%)	年間ダウン時間の目安
99%	約3.65日
99.9%	約8.76時間
99.99%	約52分
99.999%	約5分

---

✅ 可用性を高める技術・設計の例

方法	説明
マルチAZ構成	複数のデータセンターにシステムを配置して冗長化
フェイルオーバー機構	障害時に自動で別のシステムに切り替える
ロードバランサー	トラフィックを複数のサーバーに分散させる
冗長化（冗長構成）	データベースやストレージを二重化
監視とアラート	障害をすぐに検知して対応できるようにする

---

✅ 可用性と混同しやすい他の用語

用語	説明
信頼性（Reliability）	長期にわたって故障せず動作し続ける能力
耐障害性（Fault Tolerance）	部分的な障害が発生しても全体が止まらない設計
保守性（Maintainability）	障害が起きたときに素早く復旧できる能力
拡張性（Scalability）	負荷に応じてシステムをスケールできる能力

---

✅ 一言でまとめると：

「可用性が高い」とは、ユーザーがいつアクセスしてもサービスが正常に使える状態を保っていること。

---

なぜマルチAZ構成だと単一AZ構成より可用性が上がるのか

マルチAZ構成が単一AZ構成より可用性が高くなる理由は、障害の影響を局所化し、他のゾーンでサービスを継続できるようにする冗長性と耐障害性があるからです。

---

✅ AZ（Availability Zone）とは？

• AWSなどのクラウドサービスでは、物理的に分離された複数のデータセンターを「アベイラビリティゾーン（AZ）」と呼びます。
• 同じリージョン内に複数のAZがあり、地震・停電・ネットワーク障害などの影響を独立して受けます。

---

✅ 単一AZ構成のリスク

• 全てのサービス・データが1つのAZに集中している。
• そのAZが障害を起こした場合、サービス全体がダウンする。
• 可用性 = そのAZの稼働率に依存。

---

✅ マルチAZ構成のメリット

機能	説明
障害耐性の向上	片方のAZがダウンしても、もう片方が稼働を継続できる。
自動フェイルオーバー	DBやサービスによっては、障害発生時に自動で別AZに切り替わる。
ロードバランシング	複数AZに跨るアプリサーバーに対し、トラフィックを分散可能。
データの冗長性	データベースのレプリケーションで、AZ間でデータを同期。

---

✅ 具体例（RDS）

AWS RDS（リレーショナルデータベース）では：

• 単一AZ構成：DBが1つのAZにしか存在しない → AZ障害でDB停止。
• マルチAZ構成：DBが2つのAZにレプリケートされており、プライマリが障害を起こしても、セカンダリが自動昇格されて継続稼働。

---

✅ 可用性向上のイメージ

構成	可用性の例（概算）
単一AZ構成	約 99.5%（障害で即停止）
マルチAZ構成	約 99.99%以上（自動切替で継続）

---

✅ 一言でまとめると：

マルチAZ構成は、データと処理の拠点を複数に分散することで「障害を局所化」し、「サービスの継続性」を担保します。だからこそ可用性が向上するのです。

---

可用性が上がったのかどうかテストする

マルチAZ構成による可用性向上のテストを行うには、障害シナリオを意図的に発生させてシステムが正常に動作を継続できるかどうかを検証する必要があります。

---

🔧 前提条件

• システムはマルチAZ構成（例：Amazon RDS, EC2, ECS, ALBなど）で構築済み
• 各AZにインスタンス／コンテナが適切に配置されている
• 自動フェイルオーバー設定済み（RDSなど）

---

✅ 検証すべきストレステスト／障害シナリオ

テスト項目	具体的な方法	検証ポイント
AZ障害のシミュレーション	一時的に片方のAZのリソースを意図的に停止（例：EC2停止、AZ指定のターゲット除外）	リクエストが他AZに自動でルーティングされるか（ALB/Route 53）
RDSのフェイルオーバーテスト	RDSのプライマリインスタンスを再起動（またはフェイルオーバーを手動実行）	DB接続が切れずに再確立されるか。ダウンタイムの秒数を測定
ネットワーク分断シミュレーション	iptables などで一部AZへのネットワークを遮断	自動的に切り替わるか、障害がクライアントに影響しないか
高負荷シナリオ	負荷ツール（Apache Benchmark, Locust, JMeterなど）でリクエストを集中させる	一方のAZに偏らずバランスよく負荷分散されるか
障害後のリカバリ	停止したAZの復旧後、トラフィックが自動で戻るかを確認	自動リバランスが正常に動作しているか

---

📊 評価指標（可用性の向上を定量的に確認）

• フェイルオーバー時間：ダウン検出から復旧までの秒数（例：RDSでは30秒未満が望ましい）
• 成功リクエスト率：AZ障害中のHTTP 200率
• SLO（サービスレベル目標）：99.9%可用性を満たすか（1ヶ月で約43分以内のダウンタイム）
• ユーザー影響度：障害発生時にエンドユーザーのレスポンスが著しく劣化しないか

---

🧪 補足：テストツール

• Chaos Engineering系：

  • AWS Fault Injection Simulator (FIS)
  • Gremlin

• 負荷ツール系：

  • Apache Benchmark (ab)
  • Locust
  • Artillery
  • k6

---

ローカルでのテスト

---

✅ ローカル環境でテストする「意味がある点」

テスト内容	ローカルでもできること
アプリのフェイルオーバー対応確認	DB接続が切れた時のリトライ、タイムアウト処理などの挙動確認
負荷試験（縮小スケール）	1台 or 仮想AZ相当の複数コンテナに負荷をかけ、アプリがクラッシュしないか確認
自動復旧ロジックの確認	再接続や再起動スクリプトの検証（e.g. systemd, retry, healthcheck）
設定・コードの事前検証	マルチAZ環境に移す前に、設定ファイルや障害ハンドリングが想定通り動くかの確認

---

⚠️ ローカルで「できない or 難しい」こと

項目	理由
実際のAZ障害シナリオの再現	物理的に複数のAZやVPCの切断を再現できない
AWSの自動フェイルオーバー機構の検証	RDSやALBの挙動、Route 53のFailover設定はAWS環境依存
本番同等の負荷テスト	ローカルのマシンスペックに限界があるため、スケールした環境での挙動確認ができない

---

🧩 まとめ

• ローカル環境は事前検証・ユニットテスト・例外処理の動作確認には有効
• 可用性（HA）の本質的な検証＝クラウド（AWSなど）環境が必要
• 実際のAZ障害やRDSフェイルオーバーなど、インフラに依存する挙動はローカルでは再現が難しい

---

✅ おすすめの進め方

1. ローカルでユニット的な確認（障害時の処理・タイムアウトなど）
2. ステージング環境で本番相当のマルチAZテストを実施
3. 本番リリース前に AWS FIS（Fault Injection Simulator）などでカオスエンジニアリング的な検証