EC2 Auto Scalingを試してみた
AWS公式のEC2 Auto Scalingのハンズオンをやってみたのでメモしておきます。
ハンズオンに必要なリソースはCloud Formationで準備されるので、 Auto Scalingの設定に集中して取り組めました。
Auto Scaling以外にもたくさんのハンズオンがあり、下記リンク先に一覧があります。 サービスの雰囲気を掴むのに役立つので一通りやってみたいなと思っています。
EC2 Auto Scalingとは
あらかじめ設定した条件に応じて、EC2インスタンスを自動的に追加・削除することで 可用性の維持とコスト最適化をはかることができるサービスです。
Auto Scalingの設定の流れ
Auto Scalingの設定は下記の流れになります。
起動テンプレート
を作成Auto Scalingグループ
を作成- 自動スケーリングの設定
1. 起動テンプレートを作成
Auto Scalingによって追加・削除されるインスタンスの設定を定義します。 主に下記のような項目を指定します。
- AMI
- インスタンスタイプ
- ネットワーク設定
2. Auto Scalingグループの作成
Auto Scalingグループを作成します。主に下記の項目を指定します。
3. 自動スケーリングの設定
最後にスケーリングを実行する条件を設定します。
作成したAuto Scalingグループを開き、自動スケーリング
のタブから設定できます。
スケーリングする方法にはいくつかありますが、ハンズオンでは下記を実際に試します。
- スケジュールスケーリング(予定されたアクション)
- 動的スケーリング
スケジュールスケーリング
設定したスケジュールに基づいてインスタンスの増減を行なう仕組みです。 特定の時間帯にアクセスが集中するなど、負荷がある程度予測できる場合に利用します。
反復条件として「毎日」「毎週」以外にも、Cron形式で指定することもできます。
ハンズオンの中では特定の時刻に一度だけ実行されるスケーリング設定を行ないました。
動的スケーリング
設定した閾値に基づいてインスタンスの増減を行なう仕組みです。 負荷が予測できない場合に利用します。
スケーリングには数分かかるので、急激なアクセス増加(スパイクアクセス)での利用には注意が必要とのことです。
ハンズオンの中では「ターゲット追跡スケーリング」として、平均CPU使用率が閾値を超えたらインスタンス台数を増やす設定を行ないました。
異常なインスタンスの置き換え
インスタンスに障害が発生して、維持したい最小台数を下回った時もAuto Scalingがインスタンスを追加してくれます。
ハンズオンでは、最小キャパシティが「2台」に設定されている環境で、 1台のインスタンスを停止させた時の様子を確認しました。
まとめ
EC2 Auto Scalingのハンズオンをやってみました。 負荷状況に応じてインスタンスの増減を自動でやってくれるのは便利ですね。
一方で、インスタンスに固有の値を持たせると、スケールイン時にインスタンスが破棄されたときにその値も一緒に消えてしまいます。
アプリケーションのログなどはインスタンスに保持せず、外に出しておく設計が必要だと感じました。