introduction
Il y a dix ans, l’architecture sans serveur semblait être un rêve devenu réalité. Ce n'est plus le cas ! Avec Amazon Lambda, nous pouvons désormais créer et exécuter des applications sans penser aux serveurs. Le fournisseur de cloud gère de manière transparente tous les approvisionnements, mises à l'échelle et gestion des serveurs. Nous devons juste nous concentrer sur le code. Cela apporte une agilité, une automatisation et une optimisation sans précédent aux déploiements cloud. Cependant, pour réaliser tout son potentiel, il faut une solide maîtrise de l'architecture et des capacités uniques de Lambda. Cet article vise à dévoiler sa magie avec des exemples pratiques, des leçons apprises et un aperçu d'un ingénieur sur le fonctionnement interne !
| La communauté des développeurs de technologies cloud Amazon fournit aux développeurs des ressources technologiques de développement mondiales. On y retrouve des documents techniques, des cas de développement, des chroniques techniques, des vidéos de formation, des activités et concours, etc. Aidez les développeurs chinois à se connecter aux technologies, idées et projets les plus avant-gardistes au monde, et recommandez des développeurs ou des technologies chinois exceptionnels à la communauté cloud mondiale. Si vous n'y avez pas encore prêté attention/favori, ne vous précipitez pas lorsque vous voyez ceci, cliquez ici pour en faire votre trésor technique ! |
Qu’est-ce que l’informatique sans serveur ?
Avant de plonger dans Lambda, clarifions ce que signifie réellement « sans serveur ». Sans serveur ne veut pas dire pas de serveur du tout. Les serveurs physiques alimentent toujours l'infrastructure cloud. La principale différence est que les développeurs n'ont pas besoin de provisionner ou de gérer directement ces serveurs. Les fournisseurs de cloud éliminent la complexité de l’infrastructure. Notre code est déployé dans des conteneurs éphémères qui sont pilotés par des événements, évoluent automatiquement et ne sont facturés que pour les ressources consommées. Ce modèle « pas de serveur, pas d'opérations » aligne les coûts sur l'utilisation et accélère le développement. Les serveurs traditionnels, les machines virtuelles et les conteneurs jouent toujours un rôle dans de nombreuses charges de travail. Mais Lambda excelle dans la gestion des besoins informatiques événementiels et transitoires.
Modèle d'exécution Lambda
Le modèle d'exécution Lambda est fondamentalement différent des architectures traditionnelles. Voyons ce qui se passe sous le capot :
Quelques aspects clés :
- Sans état : chaque exécution se produit dans un conteneur séparé. Il n’y a aucune affinité entre les exécutions.
- Éphémère : les conteneurs peuvent être initialisés et détruits en quelques millisecondes.
- Basé sur les événements : l'exécution est déclenchée par des événements configurés.
- Évolutif : ajoutez et supprimez dynamiquement des conteneurs en fonction de la profondeur de la file d'attente.
- Serverless : Nous ne gérons pas l'infrastructure des conteneurs. Amazon Cloud Technology gère tout cela. Avec ce modèle, Lambda peut intrinsèquement gérer de nombreuses requêtes parallèles et évoluer à la demande. Notre code se concentre uniquement sur la logique métier. Nous examinons ensuite les événements du cycle de vie dans les exécutions Lambda.
Cycle de vie de la fonction Lambda
Lorsqu'un appel d'événement se produit, Lambda passe par un cycle de vie bien défini :
- Démarrage à froid : Pour le premier appel, Lambda doit initialiser un conteneur. Cela entraîne un certain retard.
- Initialisation et appel : le code est chargé et exécuté. Appelez la méthode du gestionnaire.
- Arrêt : une fois l'exécution terminée, le conteneur s'arrête. Toutes les exécutions ultérieures réutiliseront le conteneur chaud. Comprendre cette surcharge de démarrage à froid est essentiel pour optimiser les performances Lambda. Voyons comment procéder ci-dessous.
Optimisation du démarrage à froid Lambda
Il n'y a rien de plus douloureux qu'un lent démarrage à froid. Heureusement, il existe quelques techniques éprouvées pour atténuer ce problème :
- Utiliser la réutilisation du conteneur : définissez un délai d'expiration non nul pour que le conteneur persiste entre les appels.
- Optimisez la taille du package de déploiement : supprimez les dépendances et les artefacts inutiles pour minimiser le temps de téléchargement.
- Choisissez un runtime hautes performances : Go, Python et NodeJS ont une faible surcharge d'initialisation.
- Prefetch Containers : conservez les conteneurs initialisés avec une simultanéité provisionnée.
- Optimisez les rôles IAM : utilisez des services tels qu'Amazon SSO pour réduire le délai assumé par les rôles.
Réaliser un bon démarrage à froid est un art et une science ! Avec les astuces ci-dessus, nous pouvons facilement réaliser un démarrage à froid en moins d'une seconde. Passons maintenant à quelques exemples de Lambda en action.
Cas d'utilisation de Lambda
Avec le modèle d'exécution flexible de Lambda, les possibilités sont infinies. Voici quelques façons préférées d’utiliser Lambda :
traitement de l'information
- Traitement de flux pour des analyses en temps réel
- Conversion de données par lots
- Générer un rapport global
Intégration et messagerie
- Déclenché via SQS pour les charges de travail distribuées
- Répondre aux notifications SNS
- Le ciment d’intégration entre les services
application Web
- Exécutez le backend sans serveur
- Fournir la prise en charge de la passerelle API
- Prétraiter les requêtes HTTP
Automatisation des infrastructures
- Personnalisez les flux de travail automatisés
- Gestion des ressources programmatiques
- capacité d'auto-guérison
etc!
Lambda n'est limité que par notre créativité.
Pour être plus concret, passons ensuite en revue une véritable application Web sans serveur.
Créer une application Web sans serveur
Voyons comment Lambda prend en charge une architecture Web sans serveur évolutive :
- API Gateway : les fonctions Lambda prennent en charge les backends API.
- Travail asynchrone : SQS et SNS intègrent Lambda pour réaliser une charge de travail étendue.
- Actifs statiques : S3 héberge des actifs statiques front-end, tels que HTML/CSS/JS. Avec cette configuration, nous pouvons atteindre une forte évolutivité, d’excellentes performances en termes de coûts et de faibles frais de gestion. Les services Lambda gèrent les tâches lourdes de l'infrastructure, telles que la disponibilité, la redondance et la mise à l'échelle. Nous nous concentrons uniquement sur la livraison des produits de base ! Bien entendu, les applications sans serveur ont leurs propres nuances. L'article de demain partagera quelques conseils pratiques d'optimisation, de débogage, de CI/CD et d'autres conseils opérationnels.
pensées finales
Nous n'avons fait qu'effleurer la surface du potentiel révolutionnaire de Lambda et du sans serveur. Sous le capot, Lambda bouleverse la gestion de l'infrastructure avec une exécution sans état, éphémère et basée sur les événements. Cela apporte une agilité, une automatisation et une efficacité sans précédent à notre architecture cloud. N'oubliez pas qu'une grande puissance implique de grandes responsabilités ! Lambda nécessite toujours une conception et des opérations réfléchies pour fonctionner sans problème. J'espère que vous avez apprécié cette visite rapide d'Amazon Lambda. Faites-moi savoir ce qui vous intéresse ou tout autre sujet Lambda que vous aimeriez en savoir plus. Au revoir, continuez à créer ces solutions sans serveur !
Les références
- Guide du développeur Amazon Lambda
- Meilleures pratiques Amazon Lambda
- Architecture sans serveur utilisant Amazon Lambda
- Blog informatique Amazon
Source de l'article : https://dev.amazoncloud.cn/column/article/64e5cea684d23218430681f1?sc_medium=regulartraffic&sc_campaign=crossplatform&sc_channel=CSDN