Étant donné que vous avez déjà créé un cluster ECS, AWS fournit des instructions sur Scaling cluster instances with CloudWatch Alarms.
En supposant que vous voulez à l'échelle du cluster basé sur la réservation de mémoire, à un niveau élevé, vous devez faire ce qui suit:
- Créer une configuration de lancement pour votre groupe Auto Scaling.
- Créer un groupe Auto Scaling, de sorte que la taille du cluster puisse être augmentée et réduite.
- Créer une alarme CloudWatch à l'échelle vers le haut de cluster si la réservation de mémoire est plus de 70%
- Créer une alarme CloudWatch à l'échelle du cluster vers le bas si la réservation de mémoire est inférieure à 30%
Parce qu'il est plus ma spécialité, je rédigea un exemple CloudFormation modèle qui devrait vous aider à démarrer pour la plupart de ceci:
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
cela crée un ECS Cluster, une configuration de lancement, un groupe AutoScaling, ainsi que les alarmes sur la base ECS Memor y Réservation.
Maintenant nous pouvons arriver aux discussions intéressantes. Pourquoi ne pouvons-nous pas passer à l'échelle en fonction de l'utilisation de l'UC Et Mémoire de réservation?
La réponse courte est que vous pouvez totalement Mais vous êtes susceptible de payer beaucoup pour cela. EC2 possède une propriété connue: lorsque vous créez une instance, vous payez un minimum d'une heure, car les heures partielles sont facturées en heures complètes. Pourquoi est-ce pertinent, imaginez que vous avez plusieurs alarmes. Supposons que vous ayez un tas de services actuellement inactifs et que vous remplissiez le cluster. L'alarme de l'UC redescend le cluster ou l'alarme de mémoire augmente le cluster. L'un d'entre eux va probablement mettre à l'échelle le cluster au point que son alarme n'est plus déclenchée. Après le temps de recharge, l'autre alarme annulera sa dernière action. Après le temps de recharge suivant, l'action sera probablement refaite. Ainsi, les instances sont créées puis détruites plusieurs fois sur un autre cooldown. Après avoir réfléchi à tout cela, la stratégie que j'ai imaginée consistait à utiliser Application Autoscaling for ECS Services en fonction de l'utilisation de l'UC et de la réservation de mémoire basée sur le cluster.Donc, si un service est chaud, une tâche supplémentaire sera ajoutée pour partager la charge. Cela remplira lentement la capacité de réservation de mémoire de cluster. Lorsque la mémoire est pleine, le cluster augmente. Lorsqu'un service se refroidit, les services commencent à arrêter les tâches. À mesure que la réservation de mémoire sur le cluster diminue, le cluster sera réduit.
Les seuils des alarmes CloudWatch doivent être testés en fonction de vos définitions de tâches. La raison en est que si vous augmentez le seuil d'augmentation de l'échelle, il se peut que la mémoire ne soit pas consommée, et lorsque l'autoscaling va placer une autre tâche, vous constaterez qu'il n'y a pas assez de mémoire disponible. instance dans le cluster, et donc être incapable de placer une autre tâche.
Lequel est le plus important, CPU ou mémoire? Que devrait-il se passer si le processeur dit «scale up», mais la mémoire dit «scale down»? –
Merci Jamie. Je dirais la mémoire pour mon cas. Dans ECS, il existe un tableau de bord qui indique le nombre d'unités cpu/mémoire allouées par rapport à non allouées. Je pense qu'il est basé sur la définition de la tâche du conteneur. J'aimerais mettre à l'échelle en fonction de ces statistiques ECS – codeshark