AWS High Availability Lab

本番環境とは別に学習用AWS環境を構築し、 Application Load BalancerとAuto Scaling Groupを用いた高可用性構成と自己修復の仕組みを検証しました。

ALB / Auto Scaling / Multi-AZ / Self Healing

Architecture

Internet
    ↓
Application Load Balancer
    ↓
Auto Scaling Group
   ↙                 ↘
EC2 (AZ1)         EC2 (AZ2)

Internet-facingのApplication Load Balancerを構築し、外部からのHTTPリクエストを受け付ける入口を作成しました。

HTTP:80のListenerを設定し、受信したリクエストをTarget Groupへ転送する構成を確認しました。

この構成により、利用者はバックエンドのEC2を直接意識せず、ALB経由でサービスへアクセスできます。

Target GroupにEC2インスタンスを登録し、 Health Checkによって正常なインスタンスへルーティングされることを確認しました。

登録済みターゲットがHealthy状態になっていることを確認し、ALBから正常に振り分けられる状態にしました。

Health Checkに失敗したインスタンスは転送対象から外れるため、障害時にも正常なEC2へリクエストを流せます。

Auto Scaling Groupで利用するために、 AMI・インスタンスタイプ・キーペア・Security Groupなどの起動設定をLaunch Templateとして定義しました。

Launch Templateにより、同じ構成のEC2インスタンスを自動生成できるようにしました。

個別のサーバーを手作業で復旧するのではなく、テンプレートから再作成するクラウドらしい運用を検証しました。

Desired Capacityを2台、Minimum Capacityを2台、Maximum Capacityを4台に設定し、常に2台以上のEC2を維持する構成を作成しました。

2台のEC2がInService / Healthyの状態で管理されていることを確認しました。

複数のAvailability Zoneに分散することで、単一インスタンス障害に強い構成を検証しました。

EC2インスタンスを1台Terminateし、障害発生を想定した検証を行いました。

Terminate後、Auto Scaling GroupがDesired Capacityを維持するため、数十秒後に新しいEC2インスタンスを自動生成することを確認しました。

この検証を通して、障害発生時にサーバーを手作業で修復するのではなく、設計図から自動的に再作成するSelf Healingの考え方を学びました。