• 9 mars 2016

    AWS ELB Best Practices

    Cross-Zone

    La première fonctionnalité importante au niveau des ELB est appelée cross-zone.

    Celle-ci permet de répartir la charge sur plusieurs AZ en tenant compte du nombre d’instances sur chaque AZ. La répartition n’est donc pas simplement effectuée entre chaque AZ.

    Par exemple nous disposons de 4 instances sur la zone A et de 2 instances sur la zone B. Sans l’activation de cette fonctionnalité, le trafic serait réparti de manière égale sur les deux zones. Les instances de la zone B étant moins nombreuses la charge serait donc plus importante sur ces instances.

    aws elb best pratices oxalide

    aws elb best practices oxalide

    Pre-Warming

    Le service AWS ELB est un service flexible. En effet, celui-ci évolue en fonction de son utilisation. Concrètement, si votre trafic augmente progressivement, les ressources allouées au service ELB évolueront également afin de pouvoir absorber l’augmentation du trafic.

    Cependant si le trafic augmente de manière importante, il est possible que l’augmentation des ressources au niveau de l’ELB ne soit pas assez rapide. Dans ce cas, le service ne sera pas en mesure de traiter l’ensemble des demandes. Ce qui aura pour conséquence l’apparition d’erreurs 503. Ce fonctionnement peut donc être très contraignant notamment lors de test de charge.

    Pour cela AWS met à disposition une fonctionnalité de pre-warming. Celle-ci va donc nous permettre en amont d’augmenter les ressources d’un l’ELB en prévision d’un pic de trafic. Il faut pour cela contacter le support AWS.

    Health-check

    Un autre point important concerne la fonctionnalité « Healt-check ». Cette fonctionnalité permet de détecter un disfonctionnement sur un serveur de backend. En cas d’erreur, le trafic ne sera plus redirigé vers ce serveur.

    Il ne faut donc pas négliger cette partie. En effet, en cas de mauvaise politique de « healt-chek », le trafic pourra toujours être envoyé sur un backend alors que celui-ci est non fonctionnel.

    En fonction des besoins il est donc recommandé d’effectuer des test de validation plus lourd en les espacent, plutôt que des tests rapide mais très rapprochés.

    Il faut donc bien définir vos besoins. Avez-vous besoin d’une page légère qui effectue une vérification fréquemment afin de vous assurer que le serveur web répond correctement ou à l’inverse avez-vous besoin d’une page plus évoluée avec une fréquence moins importante, mais qui vérifie que toutes les parties de votre application fonctionnent correctement

    Monitoring

    Lors de cette conférence, il a été montré qu’il est également très important de monitorer le service ELB. Pour cela AWS CloudWatch fournit un nombre intéressant de sondes :

    • Latence
    • Nombre de requêtes
    • Hosts actifs
    • Hosts inactifs
    • Nombre de requêtes en status 2xx-5xx sur le backend.
    • Nombre d’erreurs 4xx et 5xx

    Ces métriques peuvent également être exploitées grâce à une stack ELK.

    Article rédigé par Mathieu Cassan – RTE chez Oxalide

Newsletter

Inscrivez-vous et tenez vous au courant de l’actualité Oxalide