AWSで学ぶコンテナの基礎 (5) Auto Scaling

ようやく最後のシステム追加、AutoScaling になります。気合だ気合ー！

これからはじめる AWS Auto Scaling 2019年版では EC2 Autoscaling について多く触れましたが、今回は AppAutoscaling を扱います。でも基本的な仕組みは同じでシンプルなので、デザートは別腹な感じで終わらせましょう。

AppAutoscaling でコンテナ自動増減

前の記事でこの辺はだいぶ飽きたので、細かいことはそっちでおねしゃす。今回も同じ感じで、CPU50% を保つようにAutoScalingの設定をします。

進行図

最初の図に戻った～！感慨深い！！（疲）

ECS用AutoScalingのターゲット作成

とりあえずゼロ台で作成し、1以上の変更は管理画面でやります。

resource "aws_appautoscaling_target" "ecs-service-web" {
  count = "${local.on_ecs_web ? 1 : 0}"

  service_namespace  = "ecs"
  resource_id        = "service/${aws_ecs_cluster.web.name}/${aws_ecs_service.web.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  min_capacity       = 0
  max_capacity       = 0

  lifecycle {
    ignore_changes = ["min_capacity", "max_capacity"]
  }
}

resource "aws_appautoscaling_target" "ecs-service-web" {

count = "${local.on_ecs_web ? 1 : 0}"

service_namespace = "ecs"

resource_id = "service/${aws_ecs_cluster.web.name}/${aws_ecs_service.web.name}"

scalable_dimension = "ecs:service:DesiredCount"

min_capacity = 0

max_capacity = 0

lifecycle {

ignore_changes = ["min_capacity", "max_capacity"]

}

ポリシーで条件作成

ECSサービスの平均CPUが50％以下になるように祈りを込めます。

resource "aws_appautoscaling_policy" "ecs-service-web" {
  count = "${local.on_ecs_web ? 1 : 0}"

  name               = "ECSServiceAverageCPUUtilization:${aws_appautoscaling_target.ecs-service-web.resource_id}"
  policy_type        = "TargetTrackingScaling"
  resource_id        = "${aws_appautoscaling_target.ecs-service-web.resource_id}"
  scalable_dimension = "${aws_appautoscaling_target.ecs-service-web.scalable_dimension}"
  service_namespace  = "${aws_appautoscaling_target.ecs-service-web.service_namespace}"

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }

    target_value       = 50
    scale_out_cooldown = 180
    scale_in_cooldown  = 300
  }
}

resource "aws_appautoscaling_policy" "ecs-service-web" {

count = "${local.on_ecs_web ? 1 : 0}"

name = "ECSServiceAverageCPUUtilization:${aws_appautoscaling_target.ecs-service-web.resource_id}"

policy_type = "TargetTrackingScaling"

resource_id = "${aws_appautoscaling_target.ecs-service-web.resource_id}"

scalable_dimension = "${aws_appautoscaling_target.ecs-service-web.scalable_dimension}"

service_namespace = "${aws_appautoscaling_target.ecs-service-web.service_namespace}"

target_tracking_scaling_policy_configuration {

predefined_metric_specification {

predefined_metric_type = "ECSServiceAverageCPUUtilization"

}

target_value = 50

scale_out_cooldown = 180

scale_in_cooldown = 300

}

AutoScaling 確認

ECSサービスのAutoScalingタブに、最小／最大台数と条件が記載されます。

サービスの「更新」からAutoScalingのページで台数を指定して起動すると、最低台数が起動し、あとはサービスメトリックのCPUを利用して増減が発動します。

CloudWatch 確認

CloudWatchを確認すると、アラームに TargetTracking-service/* というデータが自動的に作成されています。

1つは 3分間内3データポイントで CPU > 50 の場合に増加、
もう1つは、15分間内15データポイントで CPU < 45 の場合に減少、です。
これらは TargetTrackingScaling が作成したもので、編集や削除はできません。

増加速度に注意

AutoScalingの記事でも触れましたが、こちらはコンテナの起動速度と最低台数に特に注意していただきたいです。

EC2インスタンスよりはFargateの方が起動速度が遅いことが多いようで、急激なトラフィック増には少々耐えづらくなっているからです。原因がFargateだからなのか、CPU性能が2世代ほど前だからなのか、は不明ですが今の所そういう声が見受けられます。

また、EC2 AutoScaling では AWS Auto Scaling を使うことでスケジュールが自動挿入され、1時間単位のスケジュールを手動編集することもできましたが、ECS では AutoScaling機能としてのスケジューリングは API でしか操作できないようなので、よほど定期的な増減にしか対応は現実的じゃなさそうです。

コンテナの起動速度を速くする努力と、最低台数の調整を怠らない、両建てでの対応から安定させていくことになりそうです。

次へまいります：費用と性能