AWSのAuto Scalingグループの概要について(概念に関する用語とスケーリングポリシーの種類)
今週はAuto Scalingグループの概要について調べました。
Auto Scalingグループ
EC2 AutoScaling と Auto Scalingグループ はなんのためにあるのか
EC2のインスタンスは起動時間に対して料金が請求される従量制の課金形式となっています。 なので、1日の負荷のピークなど必要なときは多くの台数に、必要ないときは少ない台数にしておけるといいですよね。
CloudWatchからのアラートや事前のスケジュール設定をもとにEC2の台数を増減してくれるのがEC2 AutoScalingです*1。
EC2 AutoScaling はプログラムにより自動的にEC2のインスタンスを立ち上げるので、
- 起動したい数、最小数、最大数
- どういったインスタンスを起動するのか
- どういった条件で台数を増減するのか
といった設定が必要になります。Auto Scaling グループはそれらの設定と台数を増減させるEC2インスタンスの集合を管理する単位です。
利用するために必要なものやその呼び方
上の説明の段階でもふれたのですが、Auto Scalingグループは基本的に負荷に応じたEC2の台数増減をプログラムにやってもらおうという趣旨のものなので
- 起動したい数、最小数、最大数
- どういったインスタンスを起動するのか
- どういった条件で台数を増減するのか
を事前に「Auto Scalingグループ」のインスタンスに設定しておく必要があります。
「起動したい数、最小数、最大数」はAuto Scalingグループを作成する際、「EC2インスタンスの希望する数(desired count), 最小数, 最大数」としてAuto Scalingグループ自身の属性として設定します。
「どういったインスタンスを起動するのか」については、
- AMI ID
- インスタンスタイプ
など自分たちがEC2インスタンスを手動で起動する際にも必要となるパラメータをまとめた「起動テンプレート」*2を作成し、どの起動テンプレートを利用するかをAuto Scalingグループの属性として指定します。
「どういった条件で台数を増減するのか」については、条件の種別に応じて設定する項目が異なります。
増減を行わず一定の台数を維持したい場合*3は、「EC2インスタンスの希望する数(desired count), 最小数, 最大数」の設定で可能です。
午後7時にテレビで紹介されるから暖機を含めて午後6時半から起動したい、といった事前にスケーリングしたいタイミングがわかっている場合は、Auto Scalingグループに対して Scheduled Action(スケジュールされたアクション) を作成することで対応できます*4。
その時々のグループ内のEC2インスタンスの状態によって台数を追加したり減らしたい場合は、 スケーリングポリシーという単位で設定し、これをAuto Scalingグループのインスタンスに追加します。
スケーリングポリシーは、スケールイン用とスケールアウト用に別個に作成する必要があります。
EC2 Auto Scalingのスケーリングポリシーには
- Target tracking scaling
- Step scaling
- Simple scaling
の3種類があります*5。少しスケーリングポリシーの概要についてもふれておきましょう。
EC2 Auto Scalingのスケーリングポリシー
3種類のスケーリングポリシーの中で一番古くからあるのは、Simple Scalingです。Step Scalingが次に出て来ました。 この二つの違いですが、
- Simple Scalingはアラートをうけてスケーリング中に追加のアラートを受け取ることができませんが、
- Step Scalingは追加のアラートを受け取ることができます*6
また、この二つのポリシーではスケーリングの値のために監視しているメトリクスの値によって、一度に増やす台数を調整するためのステップ調整値*7があります。
- Simple Scalingはステップ調整値として1つの値しかスケーリングポリシーに設定できませんが
- Step Scalingは複数のステップ調整値をスケーリングポリシーに設定できます
これがどういうことかというと、ステップ調整値は、スケーリングの際にいまの台数から何台調整するかというのを調整値とすると、調整値を適用する範囲と適用する調整値そのものの組からなります。
ステップ調整値が一つしかないSimple Scalingの場合、一つのステップ調整値でアラートが来る全部の範囲を賄う必要があるので
- アラートが来たら常にN台増やして/減らして
- CPU利用率が51%のときも99%のときも10台ずつ増やして、的な
となってしまうのですが、Step Scalingの場合、
- メトリクス値が50以上60より小さいとき 下限: 0, 上限: 10, 調整: 0
- メトリクス値が60以上70より小さいとき 下限: 10, 上限: 20, 調整: 10
- メトリクス値が70以上のとき 下限: 20, 上限: null, 調整: 30
のように複数ステップ調整値が設定できて、たとえばこのように設定した場合、
- アラートが来ているといっても、メトリクスが60より小さいときはまだ見守るだけでdesired countを増やしたりしない
- メトリクスが60になった場合、現在の台数より10%追加(PercentChangeInCapacity の場合 *8 )
- さらにメトリクスが70にまでなった場合、11台の30%(PercentChangeInCapacity の場合)、3台を追加
といった具合に、メトリクスの値による増減台数の調整が可能となります。また、 PercentChangeInCapacity という単語が出て来ましたが、増減させる時の台数をどうやって計算するか(今の台数基準/絶対値など)の方法を スケーリング調整タイプ という項目で設定します。
さて、最後に出てきたスケーリングポリシーが、Target tracking scalingです。
Target tracking scalingの場合は、メトリクス値がいくつのときに何台増やすか、ではなく、ターゲット値として指定したメトリクスが指定された値になるように自動的にスケーリング調整値を計算する、といったもので、ステップ調整値の設定が簡素化できるようです*9。
現場からは以上です。
*1:他のサービスでもAutoScalingを利用できるんですが、細かく差異を調べている余裕はなかったのでドキュメント読んだEC2 AutoScalingに限って話を進めます
*2:https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/create-asg-launch-template.html
*3:正確に言うとスケーリングではないですが、Amazon Auto Scalingはこの目的でも利用できます。インスタンスの集合の中に不具合が生じたインスタンスを自動的に入れ替えるなどの使い方で「オートヒーリング」と呼ばれるそうです。 https://www.nttdocomo.co.jp/corporate/technology/rd/tech/nfv/nfv01/05/03.html
*4:https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/schedule_time.html
*5:https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scale-based-on-demand.html
*6:https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scaling-simple-step.html
*7:公式ドキュメントによるとスケジューリング調整値ともいうみたい https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-scale-based-on-demand.html
*8:https://docs.aws.amazon.com/ja_jp/autoscaling/application/userguide/application-auto-scaling-step-scaling-policies.html
*9:https://docs.aws.amazon.com/ja_jp/autoscaling/application/userguide/application-auto-scaling-target-tracking.html https://aws.amazon.com/jp/about-aws/whats-new/2017/07/introducing-target-tracking-scaling-policies-for-auto-scaling/
