はじめに
前回の投稿からだいぶ時間が空いてしまいました。
ゲーム開発が楽し過ぎて、そっちに専念してしまってましたw
さて、今回は個人開発アプリをAWSに公開するためのTerraform Packを作る中で、Auto Scaling Group について書きます。
前回は、Public SubnetとPrivate Subnet、NAT Gateway料金も含めた構成判断について書きました。
今回はその続きとして、本番環境のEC2をどう管理するかを考えます。
ヒトリ開発のEC2 Planでは、本番環境のEC2をAuto Scaling Groupで管理する構成にしています。
ただ、ここで最初に思ったのがこれです。
EC2 1台なのにAuto Scaling Groupって必要なの？
Auto Scalingと聞くと、アクセスが増えたときにEC2を増やす仕組みをイメージしがちです。
もちろんそれも正しいです。
ただ、小規模な個人開発では、最初から何台もEC2を並べたいわけではありません。
今回使いたかったのは、スケールアウトというより 自動復旧 です。
Auto Scaling万能説笑
今回考える構成
今回考えるのは、ALBの後ろに本番用のEC2を置く構成です。
前回までの記事では、以下のような構成を扱ってきました。
このEC2を、単体で直接作るのではなく、Auto Scaling Groupで管理します。
見た目としては、EC2は1台です。
ただし、Terraform上では aws_instance を直接本番サーバーとして置くのではなく、Launch TemplateとAuto Scaling Groupを使って起動します。
Auto Scaling Groupとは
Auto Scaling Groupは、EC2の台数を指定した状態に保つための仕組みです。
よくある使い方は、アクセス増加に合わせてEC2を増やす構成です。
ただ、今回のように1台構成でも使い道があります。
- EC2が異常になったときに置き換える
- 起動設定をLaunch Templateで管理する
- 本番EC2を手作業で作らない
つまり、Auto Scaling Groupは「増やすため」だけではなく、期待した状態を保つため にも使えます。
今回の構成では、まずは1台で運用しつつ、壊れたら新しい1台に置き換えることを狙っています。
desired_capacity = 1 の考え方
ヒトリ開発の本番環境では、ASGの台数を次のように設定しています。
desired_capacity = 1
min_size = 1
max_size = 2
通常時に維持する台数は、desired_capacity で指定した1台です。
min_size と max_size は、ASGが取り得る台数の下限と上限です。
そのため、max_size = 2 と指定しただけで、アクセス増加時に自動で2台へ増えるわけではありません。
負荷に応じて台数を増やすには、スケーリングポリシーなどを別途設定する必要があります。
今回の主な目的は、スケールアウトではなく自動復旧です。
稼働中のEC2が異常になったり、何らかの理由で終了したりしても、ASGが新しいEC2を起動し、desired_capacity = 1 の状態へ戻そうとします。
ただし、これは1台構成を冗長化するものではありません。
異常なEC2が停止してから、新しいEC2が起動してALBのヘルスチェックを通過するまでは、アプリへアクセスできない時間が発生する可能性があります。
つまり、今回の構成で得られるのは「無停止」ではなく、手作業を減らした自動復旧 です。
EC2が置き換わることを前提にする
Auto Scaling Groupによる自動復旧を成立させるには、EC2の中だけに重要な状態を持たせないことが大切です。
例えば、次のようなデータをEC2のローカルだけに保存すると、インスタンスの置換時に失われる可能性があります。
- アプリケーションの成果物
- 環境ごとの設定値やシークレット
- アプリケーションログ
- ユーザーがアップロードしたファイル
そこで、今回の構成では、できるだけEC2の外へ状態を逃がします。
- アプリケーションの成果物はS3から取得する
- 設定値はSSM Parameter Storeなどで管理する
- ログはCloudWatch Logsへ送信する
- 永続化が必要なデータはRDSやS3などに保存する
このようにしておけば、新しいEC2が起動したときも、Launch Templateと user_data をもとに同じ状態を再現しやすくなります。
ASGで管理するEC2は、「手作業で育てるサーバー」ではなく、「いつでも作り直せるサーバー」として設計する必要があります。
ALBヘルスチェックをASGの置換判定に使う
Auto Scaling Groupを使うなら、ALBのヘルスチェックも置換判定に利用できます。
ALBは、Target Groupに登録されたEC2へ定期的にヘルスチェックを行います。
正常に応答していれば Healthy、応答できなければ Unhealthy と判定されます。
ただし、Target GroupをASGへ関連付けただけでは、ASGはALBのヘルスチェック結果をEC2の置換判定に使用しません。
Terraformでは、次のようにヘルスチェックの種類を明示します。
resource "aws_autoscaling_group" "prd" {
health_check_type = "ELB"
health_check_grace_period = 300
# ...
}
health_check_type = "ELB" を指定すると、ASGはEC2のステータスチェックに加えて、ALBのヘルスチェック結果も確認します。
ALBから Unhealthy と判定された状態が続くと、ASGはそのEC2を異常と判断し、新しいEC2へ置き換えます。
health_check_grace_period は、EC2の起動直後にヘルスチェックを始めないための猶予時間です。
user_data によるセットアップやNginxの起動に必要な時間を考慮して設定します。
Launch Templateで起動設定を管理する
Auto Scaling Groupでは、EC2を起動するための設定としてLaunch Templateを使います。
Launch Templateには、EC2起動時に必要な情報をまとめます。
- AMI
- Instance Type
- IAM Role / Security Group
- user_data
特に大事なのが user_data です。
ヒトリ開発では、EC2起動時にNginx設定やフロント成果物の配置などを行うため、起動時処理をLaunch Template側へ持たせています。
これにより、ASGによって新しいEC2が起動しても、最低限同じ状態で立ち上がるようにできます。
手元で一度だけ設定したEC2に依存すると、置き換わった瞬間に環境差分が出ます。
ASGを使うなら、EC2は「手作業で育てるサーバー」ではなく、「起動時に再現できるサーバー」として考える必要があります。
実際に置換テストを行う
実際の販売基盤では、本番EC2の置換テストを行い、新しく起動したインスタンスでアプリが復旧することを確認しました。
確認した項目は次のとおりです。
- 新しいEC2がSSM Session Managerから接続可能になること
- Nginxが自動で起動すること
- フロントエンドの成果物が自動配置されること
- ALBのTarget Healthが
Healthyになること - 実際にブラウザからアプリへアクセスできること
TerraformでASGを作成できただけでは、自動復旧できるとは言い切れません。
EC2が本当に置き換わったとき、起動処理が最後まで成功し、アプリが再び利用可能になるところまで確認する必要があります。
1台構成でASGを使うメリット
1台構成でAuto Scaling Groupを使うメリットは、スケールアウトよりも運用面にあります。
- EC2異常時に置き換えやすい
- 起動設定をコードで管理しやすい
- 将来の複数台構成へ広げやすい
何より、常時1台なので鯖代にやさしい（笑）
最初は1台で十分でも、将来的にアクセスが増えたとき、ASG構成にしておけば台数を増やす方向にも進みやすいです。
ただ、個人開発の初期段階では、まず自動復旧の意味合いが大きいと思っています。
もちろん万能ではない
Auto Scaling Groupを使ったからといって、すべてが自動で解決するわけではありません。
例えば、以下のようなものは別で考える必要があります。
- アプリケーション自体のバグ
- DBや外部サービスの障害
- 古い成果物や設定ミスの配布
ASGができるのは、主にEC2インスタンスの置き換えです。
アプリのコードや設定が間違っていれば、新しいEC2も同じように失敗します。
そのため、ASGは監視やデプロイ設計とセットで考える必要があります。
「ASGがあるから安心」ではなく、「ASGでどこまで復旧できるか」を理解しておくのが大事だと感じました。
個人開発でどこまでやるか
個人開発では、最初から大規模な冗長構成を組む必要はないと思っています。
ただ、公開して誰かに使ってもらうなら、最低限の復旧性は考えたいです。
僕の中では、以下のような判断になりました。
学習・検証だけ:
EC2 1台でもOK
外部公開する本番:
ALB + ASGで自動復旧を考える
アクセス増加後:
ASGの台数やECS化を検討する
最初から大きくしすぎると、コストも理解コストも増えます。
一方で、何も考えずにEC2 1台を直接公開すると、障害時の復旧が手作業に寄りすぎます。
その中間として、EC2は1台でもASGで管理する構成は、個人開発向けとしてちょうどよい落としどころだと感じました。
まとめ
今回は、EC2が1台の構成でもAuto Scaling Groupを使う理由について書きました。
Auto Scaling Groupという名前から、僕は最初、「アクセスが増えたときにEC2を増やすための仕組み」だと思っていました。
しかし実際には、指定した台数を維持し、異常なEC2を新しいEC2へ置き換える目的でも利用できます。
今回のポイントは次のとおりです。
-
desired_capacity = 1でもASGによる自動復旧を利用できる - ALBのヘルスチェックを置換判定に使うには、ASG側の設定が必要
- Launch Templateと
user_dataでEC2の状態を再現できるようにする - EC2の中だけに重要なデータを持たせない
- 1台構成の自動復旧は、無停止や冗長化を意味するわけではない
個人開発では、最初から大規模な構成を作る必要はないと思っています。
一方で、外部へ公開する本番環境であれば、「EC2が壊れたときに、どうやって元へ戻すか」は考えておきたいところです。
EC2は1台のままでも、ASGで管理すれば、手作業に頼りすぎない復旧の仕組みを取り入れられます。
小さく始めつつ、将来のスケールアウトにもつなげられる構成として、個人開発には扱いやすい選択肢だと感じました。
補足
今回のようなALB + Auto Scaling Group構成や、SSM Session Manager、ACM、Route53、Public / Private構成などを含めた個人開発向けAWS公開環境を、ヒトリ開発というTerraform Packとして整理しています。
個人開発向けAWS公開環境の構成図や、検証環境で利用できる無料版TerraformのGitHubリンクを以下にまとめていますので、よければ参考にしてみてください。
Freeを実際に使用してみた方がいらっしゃれば、コメントで感想を頂けますと今後の励みになります。