なんか便利そうなのでたな、どれぐらい早くなるんだろう? AutoScalingGroup(以下ASG) を使ってEC2の動的な管理をする場合、EC2のプロビジョニングに時間がかかっていた。これを回避するためにEC2を多めに起動したりしていたが、価格が上がるのでなんとかしたかった。 ASGにWarm poolを設定することで、起動したいインスタンスを事前にイニシャライズし(Pre-Initializing)必要なときに高速に追加することができるようになる。 これによりスパイク発生時に早くインスタンスが増やせることになり、ユーザ影響範囲をへらすことができるようになる。ただしあくまでAutoScalingを早くするだけなので、見えている需要があるなら事前に増やせばよい。 ということでクリティカルに効くのは「事前対策をしていなかった(もしくは目論見を超えた)スパイクへの影響軽減」となる。 AWSの試験によるとそれまで4分ほどかかっていた起動が36秒になったとのこと。EKSでASGを使っていた感覚からすると4分は信頼できる値なので、それが36秒は驚愕ですね。(WarmPoolの値はStopped) ASGをWarm Poolに参加させるだけで設定可能。 ASGのよこに設置する形で利用する。あらかじめWarmPool側に用意しておき、ASGで必要になったタイミングで移動する。
そのため計算式がちょっとあって、WarmPoolのサイズは以下の図の通り「ASGのmaxインスタンス数 - ASGの現在のインスタンス数」となる。
ただし例外でWarmPoolに WarmPool上に置くEC2はStopped or Runningの状態が選べる。 Runningは起動している状態なので普通にEC2の起動代金がかかると思われる。これは正直ほとんど意味がないと思っていて、起動しているならASGに追加すればいいじゃないかという話になる。(わざわざ使わない意味がほぼない/なにかのライセンスとか同時接続数が〜という話ならまた変わるのか…?) ということで実質Stopped一択になる。この時かかるコストは以下の通り。 ということで実質EBS代(汎用 SSD (gp3)なら0.08USD/GB 月)で運用できる。今回紹介する技術/仕組み
できること / 解決すること
背景
できること
動作イメージ
aws autoscaling put-warm-pool \
--auto-scaling-group-name "Example Auto Scaling Group" \
--pool-state Stopped \
--region us-west-2
--max-group-prepared-capacity
を設定したら「--max-group-prepared-capacity - ASGの現在のインスタンス数」となる。aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
価格について
メリデメ
メリット
デメリット/できないこと/注意点
参考リンクなど