Warm Pool (AutoScalingGroup) についての調査

f:id:lirlia:20210630181310p:plain

今回紹介する技術/仕組み

なんか便利そうなのでたな、どれぐらい早くなるんだろう？

AutoScalingGroup(以下ASG) を使ってEC2の動的な管理をする場合、EC2のプロビジョニングに時間がかかっていた。これを回避するためにEC2を多めに起動したりしていたが、価格が上がるのでなんとかしたかった。

ASGにWarm poolを設定することで、起動したいインスタンスを事前にイニシャライズし(Pre-Initializing)必要なときに高速に追加することができるようになる。

これによりスパイク発生時に早くインスタンスが増やせることになり、ユーザ影響範囲をへらすことができるようになる。ただしあくまでAutoScalingを早くするだけなので、見えている需要があるなら事前に増やせばよい。

ということでクリティカルに効くのは「事前対策をしていなかった(もしくは目論見を超えた)スパイクへの影響軽減」となる。

AWSの試験によるとそれまで4分ほどかかっていた起動が36秒になったとのこと。EKSでASGを使っていた感覚からすると4分は信頼できる値なので、それが36秒は驚愕ですね。(WarmPoolの値はStopped)

ASGをWarm Poolに参加させるだけで設定可能。

aws autoscaling put-warm-pool \
  --auto-scaling-group-name "Example Auto Scaling Group" \
  --pool-state Stopped \
  --region us-west-2

ASGのよこに設置する形で利用する。あらかじめWarmPool側に用意しておき、ASGで必要になったタイミングで移動する。

f:id:lirlia:20210630175734p:plain

そのため計算式がちょっとあって、WarmPoolのサイズは以下の図の通り「ASGのmaxインスタンス数 - ASGの現在のインスタンス数」となる。

f:id:lirlia:20210630175749p:plain

ただし例外でWarmPoolに--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

WarmPool上に置くEC2はStopped or Runningの状態が選べる。

Runningは起動している状態なので普通にEC2の起動代金がかかると思われる。これは正直ほとんど意味がないと思っていて、起動しているならASGに追加すればいいじゃないかという話になる。（わざわざ使わない意味がほぼない/なにかのライセンスとか同時接続数が〜という話ならまた変わるのか…？）

ということで実質Stopped一択になる。この時かかるコストは以下の通り。

ということで実質EBS代(汎用 SSD (gp3)なら0.08USD/GB 月)で運用できる。

混合インスタンスポリシーを持つ、またはスポットインスタンスを起動するASGにはWarm-Poolを使えない
Amazon Elastic Container Service（Amazon ECS）またはElastic Kubernetes Service（Amazon EKS）のマネージドノードグループでウォームプールを使用しようとすると、これらのサービスがインスタンスのジョブをウォームプールに到達する前にスケジュールする可能性がある
- Podの配置命令のほうが先にでるということ
WarmPool -> ASGにEC2が移動中はCloudWatch metricsのAggregate対象にはならない(ASGとしてはまだEC2はもらってないよ状態)ので、ASGとしてはEC2がまだ足りていないと判断してASG自身がEC2を起動する可能性もある
- また下手すると設定したScalingPolicy以上にEC2が増える場合もある