Use Aws Elb #3

前回の続きです。

方針

0. AMIの作成

1. ELBの作成

2. ターゲットグループの設定

3. Auto Scalingの設定

   • 起動設定
   • Auto Scalingグループ

どのようなルール（＝Auto Scalingグループ）でどのようなインスタンス（=起動設定）を増減するか。

Auto Scalingグループをターゲットグループに紐付かせることによって、どのロードバランシング対象の管理化でスケールアウト、スケールインしますか、という振る舞いになる。

Auto Scaling起動設定の作成

自分で作成したAMIを選択

名前だけ入力して次へ

webサーバーのスケールアウト・インをするつもりなので、web用のセキュリティーグループを選択

作成後、「この起動設定を使用してAuto Scalingグループを作成する」ボタンを押下

Auto Scalingグループの作成

サブネットにパブリックサブネットの1aゾーンと1cゾーンを選択した。

高度な詳細

• ロードバランシングにチェック
• ターゲットグループに、前回作成したターゲットグループを指定して、ロードバランサー管理下のインスタンスと認識させる
• ヘルスチェックのタイプにELB

Auto Scalingのルールを設定 今回は最低1個のインスタンスで、最大2個

スケールアウトの設定
「ステップスケーリングポリシーまたは簡易スケーリングポリシーを使用した Auto Scaling グループのスケーリング」を押下

新しいアラームを追加を押下

CPUが40%以上の使用率になったらインスタンス1個立ち上げる

スケールインの設定

タグの設定

ウィザードを進めて作成後、Auto Scalingのプロビジョニングが終わったタイミングのターゲットグループ一覧の画面にて

登録済みターゲットにいま起動設定とAuto Scalingグループで設定したインスタンスが一個増えている

EC2一覧画面にて

ここで想定外だったのは、Web-1aというインスタンスがすでにロードバランサが管理しているターゲットにいるので、Auto Scaling最低1個から最大2個のインスタンス数設定に当てはまるかと思ったら、そうではないのですね。Auto Scalingから作成されたインスタンス数が、最低1個から最大2個の範囲で管理するのですね。

ということでWeb-1aを外してしまう。

web-1aのステータスがdrainingに変わる。 (Auto Scalingにインスタンス数を管理してもらうので、この後web-1aは削除しました)

本当にスケールアウト・スケールインされるか確認

CPU使用率を故意にあげたあと、作成されているインスタンスが出てきたこと確認

ステータスがinitial

ステータスチェックが初期化しています

インスタンス数と希望が2になっていること確認

今度はCPU使用率を元に戻した場合の振る舞いを確認

ステータスがdrainingに変わり、

削除される動きになったこと確認

申し訳ないのですが、Apacheが動いていてブラウザから確認できる箇所は記事中では省いてしまったので、本当にロードバランシングされているか分かりにくい記事になってしまったと思います。

あと、インスタンスを全部削除したときの振る舞いも確認したら、Auto Scalingがインスタンス起動させたことも確認しました。 インスタンスは全てストップさせたかったので、Auto Scalingの動作を無効にする、ということをしたかったのですが、操作方法が分からなかったので、作成した起動設定とAuto Scalingグループのルールは削除しました。

追記: Auto Scalingの無効化を、インスタンスのサイズを最小0にして実現してみました。

以上になります。

Written by Ta Toshio who lives and works in Saitama, Japan .You should follow him on Twitter