ScalingとSelf-Healingを既存環境へ導入する

ゴール

既存環境で人が担当している処理を確認し、その処理をどのAWS管理機能へ移すか判断できるようにします。

手動設定
→ 再現可能な起動定義

手動再作成
→ Amazon EC2 Auto Scalingによる置き換え

手動ターゲット登録
→ Auto Scalingグループとターゲットグループの連携

既存監視による障害検知
→ 必要に応じてAuto Scalingの正常性判断へ接続

手動増設・縮退
→ スケーリングポリシー

Auto Scaling、ヘルスチェック、自己修復、希望するキャパシティ、スケーリングポリシーなどの基本動作は既習として扱います。

1. 最初に確認するのは「現在の1台を再現できるか」

既存環境では、長期間稼働しているEC2インスタンスへ次のような変更が蓄積していることがあります。

AMIから起動
↓
パッケージを手動追加
↓
設定ファイルを手動変更
↓
アプリケーションを手動配置
↓
運用中にさらに修正

この状態でAuto Scalingグループを作成しても、置き換え後に起動するインスタンスは、現在稼働しているインスタンスと同じ状態になるとは限りません。

したがって、スケーリングや自動置き換えより先に、同じ役割のインスタンスを起動定義から再現できるかを確認します。

2. 手動変更を起動定義へ戻す

現在のインスタンスだけに存在する設定を、再作成可能な形へ移します。

AMI
Launch Template
User Data
構成管理
デプロイ自動化

などを組み合わせます。

重要なのは特定の手段を必ず使うことではなく、インスタンスAだけに存在する変更をなくし、新しく起動したインスタンスでも同じ役割を再現できる状態へ変えることです。

3. 既存インスタンスをAuto Scalingグループへ追加しても設定は保存されない

既存のEC2インスタンスをAuto Scalingグループへ追加できる場合があります。

ただし、

既存インスタンスをグループへ追加
↓
現在のOS設定や手動変更
↓
Launch Templateへ自動保存

とはなりません。

したがって、既存インスタンスを利用しながら移行する場合でも、現在の状態を起動定義へ反映する作業は別に必要です。

このページでは、既存インスタンスを追加するための細かな条件一覧までは扱いません。

4. 「正常に起動する」と「業務を処理できる」を分けて確認する

Launch Templateから新しいEC2インスタンスを起動できても、それだけでは移行準備完了とは限りません。

確認対象は、

OS起動
↓
必要なソフトウェア起動
↓
設定取得
↓
アプリケーション起動
↓
依存先へ接続
↓
業務リクエスト処理可能

までです。

Auto Scalingで数を増やす前に、まず1台の新規インスタンスが本番と同じ役割を果たせることを確認します。

5. Auto Scalingグループは再現可能な起動定義から作る

移行前の考え方が、

現在動いている6台を維持する

であれば、移行後は、

必要な6台を
起動定義からいつでも作り直せる

へ変えます。

ここでAmazon EC2 Auto Scalingへ渡すのは、既存インスタンスそのものではなく、次に起動するインスタンスを正しく作れる定義です。

6. 既存の手動ターゲット管理をAuto Scalingへ移す

Elastic Load Balancingやターゲットグループの基本動作は既習です。

既存環境で、

EC2を追加
↓
運用担当者がターゲットグループへ登録

EC2を削除
↓
運用担当者が登録解除

しているなら、その管理をAuto Scalingグループへ移します。

Auto Scalingグループ
+
既存ターゲットグループ

を関連付けることで、Auto Scalingグループが管理するインスタンスのライフサイクルとターゲット登録を連携させます。

ここでの判断点は、ロードバランサーの仕組みそのものではなく、既存の手動登録を残さないことです。

7. 新規インスタンスが自動で参加できることを確認する

移行途中では、既存の単独インスタンスとAuto Scalingグループのインスタンスが同時に存在する場合があります。

この段階で、

新規インスタンス起動
↓
アプリケーション準備完了
↓
ターゲットとして参加
↓
実際にリクエストを処理

できることを確認します。

新規インスタンスが正常に参加できない状態で既存インスタンスを先に削除すると、移行そのものが障害原因になります。

8. 既存監視を置き換え判断へ利用できるか確認する

既存環境では、ロードバランサーからは検知できない障害を別の監視ツールが検知している場合があります。

例えば、

HTTP API
→ 正常

バックグラウンド処理
→ 停止

という状態です。

Application Load BalancerのヘルスチェックではHTTP応答が正常でも、業務上はそのインスタンスを置き換える必要があるかもしれません。

その場合は、

既存監視
↓
対象インスタンス固有の障害を検知
↓
SetInstanceHealth などで
対象インスタンスをUnhealthyとして通知
↓
Auto Scalingの置き換えへ接続

という形を検討できます。

ここで重要なのはヘルスチェック方式を一覧暗記することではなく、現在人が見ている障害シグナルを、自動置き換えへ接続できるかです。

9. 共通障害をインスタンス障害として扱わない

既存監視をAuto Scalingへ接続するときは、何を「そのインスタンスの故障」と判断するかが重要です。

例えば、

外部API全体が停止
↓
すべてのEC2で業務処理失敗

しているとします。

これを、

全EC2が故障した

と判断してすべてUnhealthyにすると、正常なインスタンスを大量に置き換えても外部API障害は解消しません。

したがって、インスタンス固有の異常と、複数インスタンスに共通する外部障害を分けます。

10. 手動復旧手順の中から自動化対象を探す

既存の障害対応手順が、

監視アラーム確認
↓
対象EC2へログイン
↓
復旧できなければEC2を削除
↓
新しいEC2を作成
↓
設定を適用
↓
ターゲットグループへ登録

であれば、自動化後も人が同じ操作をする必要がないか確認します。

例えば、

再作成
→ Amazon EC2 Auto Scaling

構成再現
→ 起動定義

ターゲット登録
→ Auto Scalingグループとターゲットグループの連携

へ移せます。

11. 既習の自己修復ループへ既存運用を接続する

異常インスタンスを検知して置き換える基本動作自体は既習です。

ここで新しく考えるのは、現在は人が「このEC2を作り直す」と判断している地点を、Auto Scalingが置き換え可能なシグナルへ変換できるかです。

自己修復の仕組みをもう一度設計するのではなく、現在の手動復旧を既習の置き換え制御へ移管することが目的です。

12. 需要対応も「人が台数を変える運用」から外す

既存環境で、

キャンペーン前
↓
EC2を2台追加
↓
ターゲット登録

終了後
↓
2台削除
↓
登録解除

を人が行っている場合があります。

起動定義、Auto Scalingグループ、ロードバランサー連携が正常に動作することを確認した後は、需要変動に応じた台数変更をスケーリング制御へ移します。

ここでは自己修復と伸縮性の定義を再説明するのではなく、障害対応と需要対応の両方から手作業を外す導入順序を扱います。

13. インスタンスローカルな状態が置き換えを妨げないか確認する

インスタンスを置き換え可能にするには、その1台を削除すると復元できない重要データが消える状態を避ける必要があります。

例えばローカルディスクだけに重要な業務データを保持している場合、Auto Scalingによる置き換えをそのまま有効にすることはできません。

このページでは、置き換え可能にするためインスタンス固有状態を残さないところまでを判断します。

同期・非同期、RPO、マルチAZ、マルチリージョンなど、データをどの方式で複製するかは別途判断します。

14. 移行後も1台だけを直接修正しない

Auto Scalingグループへ移行した後に、

障害調査
↓
1台へSSH
↓
設定を直接修正
↓
そのまま本番運用

すると、その修正は次の置き換え時に失われる可能性があります。

必要な恒久変更は、

Launch Templateから再現される構成
AMI
User Data
構成管理
デプロイ処理

など、次のインスタンスにも適用される場所へ戻します。

15. 誤った起動定義をスケーリングで大量複製しない

Auto Scalingを有効にする前に、

Launch Templateから起動
↓
正常に初期化
↓
ターゲットへ参加
↓
業務処理成功

を確認します。

設定が不足したインスタンスを再現する起動定義のままスケーリングを有効化すると、

負荷増加
↓
インスタンス追加
↓
同じ誤設定を持つインスタンスが増加

するだけです。

したがって原則は、

正しいインスタンスを再現可能にする
↓
その後でスケーリングする

です。

16. 既存インスタンスを一括置換しない

既存環境をAuto Scalingへ移行するとき、最初からすべての単独インスタンスを削除する必要はありません。

起動定義を作成
↓
Auto Scalingグループを作成
↓
既存ターゲットグループへ接続
↓
新規インスタンスを起動
↓
業務処理を確認
↓
既存インスタンスを段階的に退役

と進めることで、新しい起動経路を確認しながら移行できます。

17. スケーリングは移行の最後に有効化する

需要スケーリングを先に有効化すると、まだ検証されていない起動定義から複数のインスタンスが起動する可能性があります。

したがって、

再現可能性
↓
ロードバランサー連携
↓
正常性判定
↓
新規インスタンスの実動作確認
↓
既存インスタンスの段階退役
↓
需要スケーリング

の順序で考えます。

18. 既存環境から移管する対象を整理する

ポイントは、AWSサービスを新しく置くだけではなく、既存手順のどこをそのサービスへ引き渡すのかを明確にすることです。

19. 混同ポイント

20. SAP-C02での判断フロー

既存EC2環境
↓
障害時・負荷増加時に人が何をしている？
↓
現在のEC2を起動定義から再現できる？
│
├─ できない
│   ↓
│   AMI / Launch Template / User Data /
│   構成管理 / デプロイ処理へ設定を戻す
│
└─ できる
    ↓
    Auto Scalingグループを作成
    ↓
    既存ターゲットグループへ接続
    ↓
    必要な障害シグナルを
    置き換え判断へ接続
    ↓
    新規インスタンスが
    正常に業務参加できるか確認
    ↓
    既存単独インスタンスを段階退役
    ↓
    需要スケーリングを有効化

問題文に、

固定EC2
手動設定
手動増設
手動再作成
手動ターゲット登録

が並んでいたら、単純にAuto Scalingグループを追加するのではなく、現在の手動状態を再現可能な構成へ変えた後で、自動管理へ移管する順序を考えます。

21. 導入後にどの手動作業が消えるかで確認する

導入後も、

新EC2へ毎回手動設定
新EC2を毎回手動登録
異常EC2を毎回手動再作成
負荷増加時に毎回手動増設

が残っているなら、既存環境の自動化はまだ途中です。

完成後は、

起動定義から同等構成を再現
+
Auto Scalingグループがインスタンスを管理
+
ターゲット参加を連携
+
必要な障害シグナルを置き換えへ接続
+
需要変動による台数変更を自動化

できる状態を目指します。

まとめ

既存EC2環境へAmazon EC2 Auto Scalingを導入するときは、最初にスケーリングポリシーを設定するのではありません。

現在の構成を確認
↓
同等インスタンスを再現可能にする
↓
Auto Scalingグループへ管理を移す
↓
既存ロードバランサーへ接続
↓
既存の障害検知を必要に応じて接続
↓
新規インスタンスの正常参加を確認
↓
既存インスタンスを段階退役
↓
需要スケーリングを有効化

最も重要なのは、現在動いているインスタンスを守るから、必要なインスタンスを何度でも正しく作り直せるへ運用モデルを変えることです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• Amazon EC2 Auto Scaling — Launch TemplateとAuto Scalingグループ
• Amazon EC2 Auto Scaling — ロードバランサーとターゲットグループの連携
• Amazon EC2 Auto Scaling — インスタンスの正常性管理
• Amazon EC2 Auto Scaling API — SetInstanceHealth