考虑到您已经创建了 ECS 集群，AWS 在Scaling cluster instances with CloudWatch Alarms 上提供了说明。
假设您希望根据内存预留来扩展集群，在较高级别上，您需要执行以下操作：
- 为您的 Auto Scaling 组创建启动配置。这个
- 创建一个 Auto Scaling 组，以便集群的大小可以放大和缩小。
- 如果内存预留超过 70%，则创建 CloudWatch 警报以扩展集群
- 如果内存预留低于 30%，则创建 CloudWatch 警报以缩减集群
因为这更像是我的专长，所以我写了一个示例 CloudFormation 模板，它应该可以帮助您开始大部分内容：
Parameters:
MinInstances:
Type: Number
MaxInstances:
Type: Number
InstanceType:
Type: String
AllowedValues:
- t2.nano
- t2.micro
- t2.small
- t2.medium
- t2.large
VpcSubnetIds:
Type: String
Mappings:
EcsInstanceAmis:
us-east-2:
Ami: ami-1c002379
us-east-1:
Ami: ami-9eb4b1e5
us-west-2:
Ami: ami-1d668865
us-west-1:
Ami: ami-4a2c192a
eu-west-2:
Ami: ami-cb1101af
eu-west-1:
Ami: ami-8fcc32f6
eu-central-1:
Ami: ami-0460cb6b
ap-northeast-1:
Ami: ami-b743bed1
ap-southeast-2:
Ami: ami-c1a6bda2
ap-southeast-1:
Ami: ami-9d1f7efe
ca-central-1:
Ami: ami-b677c9d2
Resources:
Cluster:
Type: AWS::ECS::Cluster
Role:
Type: AWS::IAM::Role
Properties:
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
-
Effect: Allow
Action:
- sts:AssumeRole
Principal:
Service:
- ec2.amazonaws.com
InstanceProfile:
Type: AWS::IAM::InstanceProfile
Properties:
Path: /
Roles:
- !Ref Role
LaunchConfiguration:
Type: AWS::AutoScaling::LaunchConfiguration
Properties:
ImageId: !FindInMap [EcsInstanceAmis, !Ref "AWS::Region", Ami]
InstanceType: !Ref InstanceType
IamInstanceProfile: !Ref InstanceProfile
UserData:
Fn::Base64: !Sub |
#!/bin/bash
echo ECS_CLUSTER=${Cluster} >> /etc/ecs/ecs.config
AutoScalingGroup:
Type: AWS::AutoScaling::AutoScalingGroup
Properties:
MinSize: !Ref MinInstances
MaxSize: !Ref MaxInstances
LaunchConfigurationName: !Ref LaunchConfiguration
HealthCheckGracePeriod: 300
HealthCheckType: EC2
VPCZoneIdentifier: !Split [",", !Ref VpcSubnetIds]
ScaleUpPolicy:
Type: AWS::AutoScaling::ScalingPolicy
Properties:
AdjustmentType: ChangeInCapacity
AutoScalingGroupName: !Ref AutoScalingGroup
Cooldown: '1'
ScalingAdjustment: '1'
MemoryReservationAlarmHigh:
Type: AWS::CloudWatch::Alarm
Properties:
EvaluationPeriods: '2'
Statistic: Average
Threshold: '70'
AlarmDescription: Alarm if Cluster Memory Reservation is to high
Period: '60'
AlarmActions:
- Ref: ScaleUpPolicy
Namespace: AWS/ECS
Dimensions:
- Name: ClusterName
Value: !Ref Cluster
ComparisonOperator: GreaterThanThreshold
MetricName: MemoryReservation
ScaleDownPolicy:
Type: AWS::AutoScaling::ScalingPolicy
Properties:
AdjustmentType: ChangeInCapacity
AutoScalingGroupName: !Ref AutoScalingGroup
Cooldown: '1'
ScalingAdjustment: '-1'
MemoryReservationAlarmLow:
Type: AWS::CloudWatch::Alarm
Properties:
EvaluationPeriods: '2'
Statistic: Average
Threshold: '30'
AlarmDescription: Alarm if Cluster Memory Reservation is to Low
Period: '60'
AlarmActions:
- Ref: ScaleDownPolicy
Namespace: AWS/ECS
Dimensions:
- Name: ClusterName
Value: !Ref Cluster
ComparisonOperator: LessThanThreshold
MetricName: MemoryReservation
这会创建一个 ECS 集群、一个启动配置、一个 AutoScaling 组以及基于 ECS 内存预留的警报。
现在我们可以进行有趣的讨论了。
为什么我们不能根据 CPU 利用率进行扩展和内存预留？
简短的回答是你完全可以但是你可能会为此付出很多。 EC2 有一个已知属性，即当您创建实例时，您至少需要支付 1 小时的费用，因为部分实例小时数按完整小时数计费。为什么这很重要，假设您有多个警报。假设您有一堆当前空闲运行的服务，并且您填充了集群。 CPU 警报会缩小集群，或者内存警报会扩大集群。其中之一可能会将集群扩展到不再触发警报的程度。在冷却时间之后，另一个警报将撤消它的最后一个动作，在下一个冷却时间之后，该动作可能会被重做。因此实例被创建，然后在每隔一个冷却时间重复销毁。
想了这么多，我想出的策略是基于CPU Utilization 使用Application Autoscaling for ECS Services，基于集群使用Memory Reservation。因此，如果一个服务正在热运行，则会添加一个额外的任务来分担负载。这将慢慢填满集群内存预留容量。当内存变满时，集群会向上扩展。当服务冷却时，服务将开始关闭任务。随着集群上的内存预留下降，集群将被缩减。
可能需要根据您的任务定义试验 CloudWatch 警报的阈值。这样做的原因是，如果你将扩展阈值设置得太高，它可能不会随着内存的消耗而扩展，然后当自动扩展去放置另一个任务时，它会发现任何一个都没有足够的内存可用集群中的实例，因此无法放置另一个任务。