目次
ごあいさつ
こんばんは。
あれっ、いっつも「こんばんは」から始まっていたよね? と確認してしまうくらい
ブログの書き方を忘れたもに倉です。
今回は、Amazon EC2 Auto Scalingでいろいろと試していたときに
なんぞやこれ~となった小ネタをご紹介します。
Auto Scalingのこと、なにもわからない……。
Auto Scalingについておさらい
小ネタだけだと短すぎるブログになってしまうので、Auto Scalingについて、
少々おさらいをしておきましょう。
AWS Auto Scaling は、安定した予測可能なパフォーマンスを可能な限り低コストで
維持するためにアプリケーションをモニタリングし、容量を自動で調整します。
なるほどなぁ。
(なんもわからん)
AWS Auto Scalingとは、単純に言えば、必要な分だけ
リソースを増やしたり減らしたりしてくれる機能です。
EC2 Auto Scalingでは、EC2インスタンスをいいかんじに
増やしたり減らしたりしてくれるわけです。
増やす・減らすのトリガーはCPU使用率や前段に立つALBへのリクエスト数などを基準に指定でき、
例えばCPU使用率であれば「50%を超えたら新しいインスタンスを増やす」、
「常に50%を維持できる程度のインスタンス数を保つ」などいろいろな設定ができます。
また、増やしたい・減らしたいタイミングをスケジューリングすることも可能です。
思ったよりもいろいろと柔軟に対応してくれて便利ですね!
本編
ことのはじまり
ことのはじまりは、「キャパシティの設定全然わからん! これ、最小キャパが1の状態で
唯一グループ内に存在しているEC2をデタッチしたらどうなるの?
あと、アタッチするときもどう設定するのがベストなの?」と、
AS(Auto Scaling)グループとキャパシティの設定についての検証を実施したことです。
検証結果は割愛しますが(機会があれば別の記事に……)、そこで事件は起きました。
流れ
①キャパシティ設定をすべて「1」にしているAS(Auto Scaling)グループを作る
既存のEC2(monikura-test)をアタッチしています↓
②monikura-testサーバをデタッチ
最小キャパが1の状態で唯一グループ内に存在しているEC2をデタッチしたらどうなるの?
という疑問を解消するため、monikura-testサーバをデタッチしました。
すると、新しいサーバが建てられます↓
ASグループでは、設定された最小キャパの数のサーバが常に存在するようになっているようですね。
もちろん新しいサーバの名前は「monikura-AS」です↓
③改めてmonikura-testサーバをアタッチ
④なんか名前変わってるんだけど?!
真相
Auto Scaling グループとインスタンスにタグを付ける
既存のインスタンスをアタッチするときに、Auto Scaling グループは
タグをインスタンスに追加し、同じタグキーを持つ既存のタグを上書きします。
また、キーが aws:autoscaling:groupName で、
値がAuto Scalingグループ名のタグも追加されます。
仕様です。
あとがき
知らずに見ると結構ビビりますよ。
たまごのひび割れから身が見え始めたエンジニア。