AWS EC2の可用性を向上！CloudWatch × Auto Recoveryの実践テクニック

学べること

CloudWatchでEC2の自動復旧（Auto Recovery）を設定する方法
CPU負荷をかけてEC2の自動復旧を検証する手順
Auto Recoveryと再起動アクションの違いと使い分け

記事に関連するサービス

CloudWatch

※ 直接 EC2 の可用性を担保しているわけではないが、関連するので記載

• AWS 各サービスのメトリクスを収集し監視する。
  • 例 : EC2インスタンスのCPU使用率が90%を超えたら異常判定する

EC2AutoRecovery

• CloudWatchでEC2の状態が異常であればインスタンスの復旧が可能
  • 他にも 「停止,削除,再起動」ができる
• ハードウェア障害やネットワーク障害に強い
• 再起動では解決しない場合でも、自動復旧で別ホストに移行できる
• 手動介入なしで高可用性を確保できる

AutoScalling

• 負荷状況に応じて 適切に EC2インスタンスの数を調整(スケール)する

• インスタンス数の設定は 3種類

  インスタンス数の調整は 最小と最大の間で行われる。

  • Minimum size(最小数)
  • Desired capasity (希望するキャパシティ)
  • Maximum size(最大数)

EC2AutoRecoveryの自動再起動検証

EC2の作成とSSH接続

• EC2 インスタンスを作成
  

• 鍵ファイルに 実行権限を与え ssh -i 鍵ファイル ec2-user@publicip でsshする

• stressコマンドを yum install する

  sudo yum install -y stress-ng

CloudWatchアラームの設定手順

• アラートを設定するEC2を選択 > 画面下部 の 「モニタリング」を選択
  

• CPU使用率 (%) を 選択し、「メトリクスで表示」をクリック
  

• 遷移先で 「🔔」をクリック
  

• 統計を「最大」, 期間を「1分」, 条件を以下のように設定
  

• 通知は「削除」で設定を削除し、「EC2アクション」よりアラーム状態での動作設定を行う
  

• アラート名を好きに設定してアラートを作成する

CPU負荷テストの実施と自動再起動結果確認

• sshでインスタンスへ接続

• 以下のコマンドで cpu使用率 70%の負荷をかける

  stress-ng --cpu 1 --cpu-load 70

  (t2.microはvcpu 1, 7割負荷をかける)

• 負荷がかかっていることをアラートのグラフより確認する
  

• 自動で再起動される
  
  stressをかけていた ec2が再起動されてsshが追い出された
  アラート状態も解放された🎉

おまけ 再起動アクション vs. 復旧アクション

	復旧アクション	再起動アクション
実行される動作	インスタンスを新しいホストに移動	OSレベルで再起動
影響	ホスト障害に強い、インスタンスストアは消える	ホストは変わらない、問題が解決しない可能性あり
使う場面	ハードウェア障害、ネットワーク障害	ソフトウェアの不具合、メモリリーク
パブリックIP	変更なし（EIPがあれば）	変更される可能性あり
EBSボリューム	維持される	維持される
インスタンスストア	失われる	維持される

結局どっちを使う?

• NW障害 や インスタンスホスト障害など HW環境を変更して解決するようなアラート
  • 復旧アクション。
    • 永続化していないデータは引き継げないのでストレージの永続化が必須。
• ソフトウェア不具合 や リソース負荷 の OSレベルの再起動で解決する可能性のあるアラート
  • 再起動アクション

迷った時にこう考える

👉「基本的にハードウェアやネットワークの問題なら復旧、アプリやOSの問題なら再起動！」

👉「データが消えるリスクがあるなら、EBSやS3にちゃんと保存できる設計にしておこう！」