2

J'ai récemment commencé à utiliser ECS. J'ai été en mesure de déployer une image conteneur dans ECR et de créer une définition de tâche pour mon conteneur avec des limites CPU/mémoire. Mon cas d'utilisation est que chaque conteneur sera une application longue durée (pas de serveur web, pas de mappage de port nécessaire). Les conteneurs seront générés à la demande 1 à la fois et supprimés sur demande 1 à la fois. Je suis capable de créer un cluster avec N instances de serveur.Comment mettre à l'échelle automatiquement les serveurs dans ECS?

Mais j'aimerais pouvoir faire évoluer les instances de serveur automatiquement vers le haut/bas. Par exemple, s'il n'y a pas assez de CPU/mémoire dans le cluster, j'aimerais qu'une nouvelle instance soit créée.

Et s'il y a une instance sans conteneur en cours d'exécution, j'aimerais que cette instance spécifique soit réduite/supprimée. Cela permet d'éviter l'arrêt automatique d'une instance de serveur exécutant des tâches.

Quelles sont les étapes nécessaires pour y parvenir?

+0

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»? –

+0

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

Répondre

1

É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:

  1. Créer une configuration de lancement pour votre groupe Auto Scaling.
  2. Créer un groupe Auto Scaling, de sorte que la taille du cluster puisse être augmentée et réduite.
  3. Créer une alarme CloudWatch à l'échelle vers le haut de cluster si la réservation de mémoire est plus de 70%
  4. 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.