Exploration de la technologie sans serveur via l'évaluation comparative d'AWS Lambda


Chez Coinbase, nous sommes enthousiasmés par le potentiel sans serveur: s'il est correctement implémenté, il peut fournir des garanties de sécurité robustes et une évolutivité "infinie" à un coût considérablement inférieur. Alors que nous explorons le potentiel de l’absence de serveur, nous sommes curieux de connaître les performances réelles de certains cas d’utilisation. Parmi les questions que nous avons commencé à poser, citons:

  • Quelle est l'ampleur de la pénalité de démarrage à froid VPC? Cela a un impact important sur la technologie de base de données que nous avons choisie (AWS DynamoDB et AWS Aurora Serverless ont des API "publiques"). Nous avions entendu dire qu’ENI Cold Start pouvait durer jusqu’à 10 secondes, est-ce vraiment vrai? Combien de fois?
  • Comment la taille Lambda affecte-t-elle les heures de démarrage à froid? Si un paquet plus petit peut réduire les temps de démarrage à froid, il peut être judicieux de scinder Lambdas en paquets plus petits. Sinon, il pourrait être plus logique de prendre Lambdas "monolithe".
  • Nous avions lu que Python pouvait afficher des temps de démarrage à froid plus rapides que Golang dans le contexte de l'exécution Lambda. En tant que magasin Ruby / Golang, nous sommes curieux de voir comment les résultats de nos temps d'exécution s'accumulent.

Terminologie

Si vous lisez les points précédents sans perdre de temps, n'hésitez pas à passer à la section suivante. Sinon, la section de vocabulaire ci-dessous devrait aider à mettre à jour certains des termes utilisés dans la publication.

  • AWS Lambda– Compute entièrement géré en tant que service. AWS Lambda stocke et exécute le code ("fonctions") sur demande. Les fonctions s'exécutent à l'intérieur de conteneurs d'espaces isolés sur les machines hôtes gérées par AWS et sont automatiquement créées pour répondre à l'évolution de la demande.
  • Démarrage à chaud– Parmi les exécutions de fonctions, les conteneurs sont "mis en pause" sur la machine hôte. Un démarrage à chaud est toute exécution d'une fonction AWS Lambda dans laquelle un conteneur inactif existe déjà sur un ordinateur hôte et est exécuté à partir de cet état de pause.
  • Nouveau départ– Lorsqu'une fonction est exécutée mais qu'un conteneur inactif n'existe pas, AWS Lambda démarrera un nouveau conteneur pour exécuter sa fonction. Etant donné que la machine hôte doit charger la fonction en mémoire (probablement à partir de S3), les exécutions à démarrage à froid présentent des temps d'exécution plus longs que les exécutions à démarrage à chaud.
  • ENI– Les interfaces réseau Elastic représentent une carte réseau virtuelle et Lambdas doit communiquer avec les ressources au sein d'un VPC (réseau privé virtuel) d'AWS pour accéder à des ressources telles que des équilibreurs de charge internes ou des bases de données telles que RDS ou Elasticache.
  • ENI Cold Start– Pour communiquer au sein d'un VPC, il doit exister une ENI correspondant au groupe de sécurité Lambda sur la machine hôte lorsqu'une fonction est initialisée. S'il n'existe pas d'ENI sur la machine hôte, vous devez le créer avant de pouvoir exécuter une fonction. Les ENI peuvent être réutilisés entre des serveurs Lambda qui partagent le même groupe de sécurité, mais ne peuvent pas être partagés entre des groupes de sécurité, même pour le même VPC. AWS prévoit de résoudre ces problèmes quelque temps en 2019.
  • Diagramme de boîte– Une méthode pour représenter visuellement les données numériques par quartiles. Dans cet article, les valeurs aberrantes sont indiquées sous forme de points prêts à l’emploi.

La start-up

Nous avons commencé à fouiller dans Internet pour trouver les réponses à nos questions et avons trouvé plusieurs articles et d’excellents blogs. Cependant, certaines questions ne nous semblaient pas avoir reçu de réponse directe, ou du moins pas dans le contexte des technologies spécifiques que nous utilisions. En outre, même si nous faisons confiance aux résultats des tests, pourquoi ne pas le vérifier? Nous avons donc décidé d'essayer de découvrir nos propres réponses à ces questions.

Nous avons écrit un petit harnais de test et une série de Lambdas simples pour effectuer ces tests. Nous n'avions vraiment besoin que de notre cadre pour effectuer une série d'invocations à chaud et à froid d'un paquet Lambda donné. Nous pouvons détecter si un Lambda est appelé cold ou hot en définissant la variable globale "cold" sur false lors de la première exécution, de sorte que, même si la première invocation renvoie "cold = true", chaque invocation suivante renvoie "cold = false". Nous pouvons forcer les démarrages à froid en rechargeant simplement la charge utile d'une fonction.

Nous utilisons trois sources différentes pour mesurer le temps d'appel: la durée de facturation, la durée observée et les statistiques de suivi AWS X-ray. Comme la durée de facturation n'inclut pas l'heure de démarrage à froid et que les statistiques de suivi par rayons X n'incluent pas le temps de création d'ENI, nous utilisons l'heure observée pour la plupart de nos tests.

Performance de la base de données / VPC

Notre premier test a été conçu pour tester les performances de nos bases de données les plus courantes de Lambda. Comme la plupart des bases de données dont nous tirons parti au sein d'un VPC AWS, ce test prouverait également les performances Lambda créées au sein d'un VPC (il s'agit principalement du temps supplémentaire nécessaire pour initialiser un ENI sur l'hôte. où notre Lambda a vécu).

Nous avons testé six bases de données: Aurora Serverless, Aurora MySQL, DynamoDB, Elasticache Redis, Elasticache Memcached et MongoDB (Atlas). Tous, sauf Aurora Serverless et DynamoDB, nous ont obligés à créer le Lambda dans un VPC.

Les résultats du test de démarrage à froid nous ont surpris. Nous nous attendions à ce que la création d’ENI contribue plus fréquemment à l’heure de démarrage à froid des Lambda créées dans une VPC. En revanche, les heures de démarrage à froid semblaient être les mêmes dans tous les domaines, à l'exception du VPC Lambdas atypique.

À partir de ces résultats, il est devenu évident que tous les démarrages à froid de VPC ne nécessitent pas la création d’ENI. En revanche, AWS réutilise les ENI existants lors de l'exécution Lambda. Ainsi, bien que sur le plan technique, les Lambda dans une VPC étaient plus susceptibles de subir un démarrage à froid ENI, le nombre de démarrages à froid expérimentés dépendait du nombre total d’ENI existant dans le groupe de sécurité Lambda qu’il invoquait.

Nous voulions mieux comprendre l'impact d'un démarrage à froid ENI sur le temps d'invocation Lambda. Nous avons donc relancé le test et forcé la création d’ENI en recréant VPC Lambdas dans un nouveau groupe de sécurité temporaire avant chaque appel. Ces tests mettent plus clairement en évidence la lourde pénalité d’un démarrage à froid ENI, qui nécessite un minimum de 7,5 secondes et souvent plus de 20 secondes.

Usain Bolt peut courir 100 m plus vite qu'il ne faut. ENI Démarrage à froid à Lambda

Ces tests nous rappellent de faire attention lorsque vous placez VPC Lambdas sur des routes chaudes ou orientées client. Certaines des stratégies que nous envisageons d’atténuer pour atténuer l’impact d’ENI Cold Starts consistent à permettre au Lambda concerné de partager les groupes de sécurité (et donc les ENI) ou de placer tous les VPC Lambda sur une minuterie de 5 à 15 heures. 10 minutes pour s'assurer que les ENI sont créés avant exécution.

Tailles de colis

Notre deuxième test a été conçu pour comprendre les performances de démarrage à froid des tailles de package dans les tailles de mémoire AWS Lambda. Nous lisons que la quantité de calcul fournie à une fonction AWS Lambda donnée est basée sur la mémoire fournie avec la fonction.

Ce test n'était pas différent du test précédent, sauf que cette fois, nous avons simplement inclus des fichiers volumineux générés de manière aléatoire dans le fichier zip que nous avons chargé dans Lambda.

Les résultats de cet essai étaient clairs: les grands formats d’emballage équivalaient à de lourdes pénalités pour démarrage à froid. Il s’ensuit que Lambda déploie le package d’une fonction pour l’hôte qui appelle de manière instable, mais ce qui est moins clair est la raison pour laquelle il existe une amende aussi importante pour les paquets plus volumineux. Le calcul est simple: un démarrage à froid de 10 secondes pour un paquet de 249 Mo correspond à une vitesse de téléchargement de 200 Mbps, bien inférieure à 25 Gbps par rapport à un fichier r5.metal ou similaire. pourrait fournir Cela indique qu'AWS réduit la bande passante de démarrage à froid sur une base permbda. L'absence d'augmentation des performances de la mémoire Lambdas plus grande semble impliquer que cela ne dépend pas de la taille de la mémoire Lambda.

Temps d'exécution

Notre dernier test a été conçu pour comprendre les performances de démarrage à chaud et à froid des différentes durées d'exécution AWS Lambda. Nous avons choisi de comparer Ruby et Golang (avec Python en tant que contrôle) car ce sont les langues principales dont nous tirons parti en interne. Ce test exécute un script très simple qui renvoie simplement la variable globale "à froid" et l'ID de suivi de rayons X racine.

Les résultats du test indiquent que, même si Golang se situe au sommet des performances de démarrage à froid et de démarrage à chaud, il n’ya pas de différence spectaculaire de temps d’exécution entre les trois langues. Les résultats de ce test nous permettent de nous sentir à l'aise, ce qui permet aux ingénieurs d'écrire des fonctions Lambda dans la langue dans laquelle ils se sentent le plus à l'aise.

résumé

En résumé, certaines de nos principales conclusions comprennent:

  • Tout démarrage à froid ENI sur une route chaude / orientée client entraînera ce que nous considérons comme un pic inacceptable de latence. Les démarrages à froid ENI peuvent être atténués en autorisant les fonctions Lambda partagées à partager des groupes de sécurité (au moins jusqu'à AWS). résoudre ces problèmes à un moment donné en 2019).
  • La taille du paquet Lambda est importante pour les exécutions à démarrage à froid. Les utilisateurs doivent veiller à éviter les routes d'accès rapides avec des packages de plus de 100 Mo.
  • La taille de la mémoire Lambda fournie importe moins que prévu: à l'extrémité inférieure de l'échelle (128 Mo), nous avons pu observer des temps de réponse élevés, mais l'impact de la taille sur les lambdas supérieurs à 512 Mo était négligeable.
  • La différence entre les langages compilés et interprétés (Golang vs Ruby) s’est avérée beaucoup moins dramatique que prévu. En conséquence, nous pouvons nous sentir à l'aise, permettant aux développeurs d'écrire des fonctions dans le langage qui leur convient le mieux.

Nous sommes heureux d’effectuer ces mêmes tests à l’avenir pour voir l’évolution des performances d’AWS Lambda au fil du temps.

Si vous souhaitez nous aider à construire une plate-forme moderne et évolutive pour l'avenir des marchés de la cryptographie, nous embauchons à San Francisco!

Ce site Web peut contenir des liens vers des sites Web tiers ou d’autres contenus à des fins d’information uniquement («sites tiers»). Les sites tiers ne sont pas sous le contrôle de Coinbase, Inc. et de ses sociétés affiliées ("Coinbase"), et Coinbase n'est pas responsable du contenu des sites tiers, y compris, sans toutefois s'y limiter, les liens contenus dans des sites tiers. Le site de la partie, ou toute modification ou mise à jour vers un site tiers. Coinbase n'est pas responsable des transmissions via Internet ni de toute autre forme de transmission reçue d'un site tiers. Coinbase vous fournit ces liens uniquement pour votre commodité, et l’inclusion de tout lien n’implique en aucun cas l’approbation, l’approbation ou la recommandation du site par Coinbase, ni aucune association avec ses opérateurs.

Sauf indication contraire, toutes les images fournies dans ce document proviennent de Coinbase.