AWSをいじり倒す(4.ELB+AutoScaling)
前回、単一EC2構成にELBを適用できたので、
巷でよく聞くAutoScailingとELBの組み合わせとやらを試してみることにする
まずはAutoScailingから・・・の前に。
にもあるように、
Auto Scalingを利用する上で必ず抑えておきたいのは、「Auto Scalingで管理されるEC2は起動設定で指定したAMIから起動する」ということです。
ということなので 、AMIを作っておかなければならない。
スケーリングを試すときに、Webサーバの立ってるインスタンスが複数必要なので
まずは、前回作ったインスタンスからAMIを生成する。
AMIの作成
インスタンスの画面から、イメージの作成を選ぶ
イメージの作成画面が出てくる。
イメージ名とイメージの説明は適当にtest、for_testとする。
再起動しない、は参考にするインスタンスを一度落としてからAMIを作るかどうか。
常識的に考えて落としてから作った方が良い（チェックは入れない）
ボリュームに、前回無意味にくっつけたsc1の500GBが指定されたままだった。
いらないので右端の×ボタンを押して消す。
こんな感じでイメージの作成ボタンを押した。
AMIの項目をみると・・・おお、やってるやってる。
３分かそこらでpendingがavailableの表示に変わった。
これで完成。
ということでAutoScalingの設定を進める
起動設定の作成
早速AMIの指定画面が出てきた。
さっき作った、testのマイAMIがある。選択選択。
インスタンスタイプの選択
こだわりないので最小スペック。
詳細設定
名前はtest-scalingとでもしよう。
でも値段が高い時は０台になっても良い使い方ってどんなだ？？
って思って調べたら、ちゃんとスポットとオンデマンドを組み合わせるプランがあった
複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ - Amazon EC2 Auto Scaling (日本語)
へ〜。
IAMロールとモニタリングは現時点では指定無し無し
ボリュームの設定
特に追加はいらないのでこのまま次へ
セキュリティグループの設定
前回作ったEC2に使っていたセキュリティグループを使うため、既存のセキュリティグループを選択。
しかしセキュリティグループに関しては、別リージョンの設定も全部丸見えなのね。
確認画面が出て、作成！
キーペアの設定画面がでてきた。
そもそもキーを指定したインスタンスからAMI作っていて、
そのAMIで新たなインスタンスを作ろうとしているんだから
なんでここで再度キー選択画面が入るの？って少しモヤる。
Amazon EC2 のキーペア - Amazon Elastic Compute Cloud
インスタンスから Linux AMI を作成し、AMI を使用して別のリージョンまたはアカウントの新しいインスタンスを起動すると、新しいインスタンスには元のインスタンスからのパブリックキーが含まれます。これにより、元のインスタンスと同じプライベートキーファイルを使用して新しいインスタンスに接続できます。
ほら、言ってること間違ってない。ここで別のキー選択したら、２つのキーでアクセスできるようになるんか？
・・・って、よくみたら上の画面内に書いとる！！
Note: The selected key pair will be added to the set of keys authorized for this instance. Learn more about removing existing key pairs from a public AMI.
ほんとに２つのキーでいけることになるっぽい。
そしてキーペア無しで続行の選択肢もあることに気づいた。本来はこれを選ぶべきか
なるほどなるほど
無事に設定ができた。
ここまではAutoScalingで起動するインスタンスの設定の作成、
次からがAuto Scalingグループの作成。
先ほど作った起動設定にチェックをいれて、
Auto Scalingグループの作成ボタンを押してみる
AutoScalingグループの詳細設定
グループ名はtest-scale-groupとする。
開始時インスタンス数はいったん3を選ぶ。
で、ネットワークは・・・
自分で作った10.0.0.0/16を選んだらなにやら警告が。
パブリックIPは割り当ててやんねーぞ、と。
まあ、今回はELB経由でアクセスするので問題無し。
サブネットは複数指定することができた。
たぶん各AZにいい感じにばらけてインスタンスを作ってくれるんだろう。
高度な詳細
ロードバランシングは
前回作ったELBの送り先であるtest-groupを指定。
test-groupに今回のAuto Scalingで作るEC2達を所属させる。
ヘルスチェックのタイプは今回ELBを使うのでELB。
ヘルスチェックを開始するまでの時間は300秒
モニタリングの間隔はデフォルトでこれも300秒。
インスタンスの保護は、
だと。
ロールは作ってないので空白。
スケーリングポリシーの設定
範囲は2〜4インスタンスにしてみる。
メトリクスタイプは何種類からか選べるようだ。
ターゲット値は・・・
ということは、
ALBのリクエスト数だと、自分しかアクセスしないし今回は3とか4とかそういうオーダー。CPUの平均使用率なら50とか。
ネットワーク入力なら単位バイトということは例えば1MBだと1000000みたいな値を入力するんだろう。
これらがモニタリングの間隔（300秒）で超えていたらアウトということか。
とりあえずリクエスト数：３で設定。
日本語訳が胡散臭い項目だが、起動してからグループにいれるまで何秒まつという設定
デフォルトで300秒となのかな？とりあえず空白
スケールインの無効化
は、条件を満たさなかったときに減らすかどうか。
これ、インスタンス増やすことで条件を満たさなくなって、インスタンス減らしたところ条件を満たして、ってなると短時間で増減繰り返しそうで怖いな。
通知の設定
イベントが起きたときに通知してくれるらしい。
せっかくなんで設定してみる。
（実際にはhogehoogeじゃなくて実在のメアドを入力）
タグ
確認画面
作成！！
・・・えっ
スケーリングポリシーの何があかんかったんや・・・
インスタンスは：のところ、秒数いれてなかったので、適当に20秒を入れてみる。
リトライ！
あ、できた。よかった。秒数は埋めないとあかんらしい。早く言ってよー
確認
ターゲットグループさんが賑やかになっていた。
今回ので３台作られたらしい。
開始時インスタンス数は確かに３にしたが、ポリシーで範囲は２〜４としたので、
５分待てば２台に減るんかな？
AZは2aと2bにいい感じに分散されている
インスタンスも賑やかに。
５分待ったら、思惑通り１台減ろうとしている瞬間を激写できた。
AutoScalingグループ上でも消されようとしているインスタンス君。さようなら。
まず先に、最初に作った単独インスタンスは不要なので、ターゲットグループから外すことにした。
ターゲットグループの画面から編集
チェックして、削除
画像きれてしまったけど、右下に保存ボタンがあるので押す
testさんさようなら〜
改めてインスタンスをみると、スケールインによるインスタンスの死骸がw
testさんもお役御免なので、落としておく。
ロードバランサーにアラームが出ていることに気づいた。
AlermLow・・・だから、下回ったぞ！ってことか。
さて、最後にELB経由でインスタンスに３回以上アクセスしたらスケーリングしてくれるのか、という点を試す。
いや、２台だから合計６回か。
まずは５回、アクセスしてみる。
でも、ロードバランスされてるから平均2.5で、スケールアウトはされない。
次の５分で１０回アクセスしてみる。
こえたぞーー
・・・あれ？アラームがでない
通知のオプションからClowdWatchの画面を開いてみる
赤線超えてません？（そういう赤線じゃないの！？）
１５回アクセスしてみることに
だめだ・・・スケールアウトしない
よくよくみると、小さく
3 分内の3データポイントのRequestCountPerTarget > 3
と書いてある。RequestountPerTargetの3は自分で設定した3だとして
３分以内の３データポイントってなんぞ？
文字通り受け取ったら、300秒ごとにチェックしてる状況だと永遠にひっかからないんだが。
編集できないか試してみる
期間が１分て・・・、怪しい。
５分に変えてみると
いい感じに１５分以内の３データポイントが赤線を上回る絵になった。
ついでに条件もよくみると
以上、じゃなくて、より大きいなのね。ぴったりじゃ反応しないと
アラームの更新を押すと即反応w
でもよくみたらこれLowのほうだ。
嵐が去ったあとのアラームがでたみたい。
ということでまた５分ごとに１０回ぐらいアクセスを３回くりかえす
でた。
しかし、アクセス連打してからアラームが出るまでが、くそ遅い。
１０分ぐらいはラグがあったと思う。
そして、アクセス連打しすぎたのか一気に４台へw
どうも待ちきれなくて１５分で４５回ぐらいクリックしてしまったらしい
平均１５回/５分。２台あるから１台あたり7.5回/5分のアクセス。
３台に増やしても１台あたり５回のアクセスなので
閾値の１台あたり３回には足りない、と判断して４台に増えたのね。賢いな。
思惑通り増えたのはいいが、アクセス過多からアラーム発生までが本当に遅いので、
バーストには向かないというのがよくわかった。
ちなみにスケールした時点で登録したメアドに以下のようなメールもきていた。
increasing the capacity from 2 to 4とかいてある。
sns.amazonaws.comさんから届いているので、期せずしてSNSも利用したことになる。
せっかく自動で生成してくれたアラーム条件を変更しないといけなかったのは少しモヤる。もっと上手な初期設定があったんだろうか。
とにかく、ELBと連携した状態でAutoScalingによるスケールアウト・スケールインの挙動は確認できたので、いったんよしとする。
また、AutoScaling設定中にELBのターゲットグループ指定があったことから、
０から作る時は、先にELBで空のターゲットグループを作ってから、AutoScalingの設定、という順番となるというのも気付き。こんなんやってみんとわからん。
おまけ1。
ELBへのアクセス状況をClowdWatchが監視して、閾値を超えたらAutoScalingするという流れだったが、そのAutoScalingは誰が指示しているのか？がよくわからなかったので色々みていたところClowdWatchのアラームトリガーにAutoScalingアクションというのを発見。
ということは、ClowdWatchさんがAutoScalingを直接指示しているのね。
間にまた何か別のサービスでも噛んでるのかと思った。
おまけ２。
終わらせ方ってどうするんだ。
削除・・・しかないのか。
削除することで、インスタンスからClowdWatchの設定まで綺麗に消えた。
次回以降はシングルインスタンス＋ELB構成ですすめることになりそう。
進捗。
