Introduction

Débutant | 10 minutes

Sans serveur - Découverte approfondie présente les concepts fondamentaux, les architectures de référence, les bonnes pratiques et les exercices pratiques pour vous aider à démarrer la création d'applications sans serveur. Ce contenu est parfaitement adapté pour les personnes qui découvrent le sans serveur. Si vous maîtrisez déjà le sujet, consultez nos ressources et nos liens traitant de problématiques plus complexes.

Qu'est-ce que le sans serveur ?

Le sans serveur permet de concevoir et d'exécuter des applications et des services sans se soucier des serveurs. Cela permet d'éliminer les tâches de gestion des infrastructures, comme le provisionnement de serveur ou de cluster, la correction, la maintenance des systèmes d'exploitation et la mise en service de capacités. Vous pouvez en concevoir avec pratiquement n'importe quel type d'application ou de service backend. Par ailleurs, tous les aspects nécessaires à l'exécution et au dimensionnement à haute disponibilité de votre application sont gérés à votre place.

Les applications sans serveur sont basées sur les événements et faiblement couplées via une messagerie ou des API indépendantes de la technologie. Le code basé sur les événements est exécuté en réponse à un événement, par exemple un changement d'état ou une requête de point de terminaison. Les architectures basées sur les événements découplent le code de l'état. L'intégration entre composants faiblement couplés est généralement asynchrone, par messagerie.

AWS Lambda est un service de calcul sans serveur parfaitement adapté aux architectures basées sur les événements. Les fonctions Lambda sont déclenchées par des événements via des sources d'événement intégrées telles que Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) et Amazon Kinesis, qui permettent de créer des intégrations asynchrones. Elles consomment et produisent des événements qui sont ensuite consommés par d'autres services.

Les schémas d'architecture sans serveur utilisent Lambda avec d'autres services gérés, eux-mêmes sans serveur. Outre les services de messagerie et de streaming, les architectures sans serveur utilisent des services gérés tels que Amazon API Gateway pour la gestion d'API, Amazon DynamoDB pour les magasins de données et AWS Step Functions pour l'orchestration. La plateforme sans serveur inclut également des outils de développement, dont le modèle SAM (Serverless Application Model), qui simplifie le déploiement et le test de vos fonctions Lambda et de vos applications sans serveur.

Pourquoi utiliser le sans serveur ?

Aucune gestion de serveur : Il n'est pas nécessaire d'allouer ni de maintenir le moindre serveur. Il n'y a pas de logiciel ni de moteur d'exécution à installer, à entretenir ou à administrer.

Dimensionnement flexible : Votre application peut évoluer automatiquement ou en ajustant sa capacité par l'activation des unités de consommation (comme le débit ou la mémoire) et non pas des unités de serveurs individuels.

Paiement pour des services de qualité : Payez pour un débit ou une durée d'exécution constants et non par unité de serveur.

Haute disponibilité automatisée : Le sans serveur fournit une disponibilité et une tolérance aux pannes intégrées. Vous n'avez pas besoin de développer ces capacités, car le service exécutant l'application les fournit par défaut.

Principaux services du sans serveur

Les applications sans serveur sont généralement développées par blocs fonctionnels avec des services entièrement gérés sur les différentes couches : calcul, données, messagerie et intégration, streaming, gestion et identité des utilisateurs. Les services tels que AWS Lambda, API Gateway, SQS, SNS, EventBridge et Step Functions sont au cœur de la plupart des applications et sont supportés par d'autres services tels que DynamoDB, S3 et Kinesis.

Catégorie
Service
Description
Calcul AWS Lambda AWS Lambda vous permet d'exécuter des applications sans serveur sans état sur une plateforme gérée
qui prend en charge les architectures de microservices, le déploiement et la gestion de l'exécution
au niveau fonctionnel.
Proxy API API Gateway Amazon API Gateway est un service entièrement géré qui permet aux développeurs de facilement
créer, publier, gérer, surveiller et sécuriser des API à n'importe quelle échelle. Il fournit une
plateforme complète pour la gestion des API. API Gateway vous permet de traiter
des centaines de milliers d'appels d'API simultanés et de prendre en charge la gestion du trafic,
l'autorisation et le contrôle d'accès, la surveillance et la gestion des versions d'API.
Messagerie et intégration SNS Amazon SNS est un service de messagerie pub/sub entièrement géré qui permet facilement de
découpler et mettre à l'échelle les microservices, les systèmes distribués et les applications sans serveur.
SQS Amazon SQS est un service de mise en file d'attente de messagerie entièrement géré qui permet facilement de
découpler et mettre à l'échelle les microservices, les systèmes distribués et les applications sans serveur.
EventBridge Amazon EventBridge est un bus d'événements sans serveur qui facilite la connexion d'applications
entre elles en utilisant des données de vos propres applications, des applications Saas
(Software-as-a-Service) intégrées et des services AWS.
Orchestration Step Functions
AWS Step Functions facilite la coordination des composants des applications
distribuées et des microservices à l'aide de flux de travail visuels.

Créons une application !

Vous trouverez ci-dessous quelques ressources pour vous aider à vous familiariser avec nos principaux services sans serveur.

Exécuter une commande « Hello, World! » sans serveur

Créez une fonction Lambda « Hello World » à l'aide de la console AWS Lambda et apprenez les bases de l'exécution du code sans provisionnement ni gestion des serveurs.

Début du didacticiel >>

Créer des miniatures à partir d'images téléchargées

Créez une fonction Lambda invoquée par Amazon S3 chaque fois qu'un fichier image est téléchargé dans un compartiment S3 et créez automatiquement une miniature de cette image.

Début du didacticiel >>

Construire sa première application avec AWS Lambda
Créer un microservice simple

Utilisez la console Lambda pour créer une fonction Lambda et un point de terminaison Amazon API Gateway pour la déclencher.

Début du didacticiel >>

Créer un flux de travail sans serveur

Apprenez à utiliser AWS Step Functions pour concevoir et exécuter un flux de travail sans serveur qui coordonne plusieurs fonctions AWS Lambda.

Début du didacticiel >>

Fondamentaux

Intermédiaire | 20 minutes

Dans cette section, vous découvrirez la conception guidée par les événements, qui est le principe de base des applications évolutives sans serveur.

Conception guidée par les événements

Une architecture guidée par les événements s’appuie sur des événements pour déclencher la communication entre des services découplés. Un événement est un changement d'état, ou une mise à jour. Il peut, par exemple, correspondre au fait de placer un article dans un panier sur un site de commerce électronique. Les événements peuvent soit désigner un état (par exemple, l'article acheté, son prix et une adresse de livraison), soit être des identificateurs (par exemple, une notification d'expédition d'une commande).

Les architectures guidées par des événements comportent trois éléments clés : les producteurs d'événements, les routeurs d'événements et les consommateurs d'événements. Un producteur envoie un événement au routeur, qui filtre les événements et les transmet à son tour aux consommateurs. Les services des producteurs et des consommateurs sont découplés, ce qui leur permet d'être mis à l'échelle, actualisés et déployés de manière indépendante.

Pour comprendre l’intérêt d’une architecture guidée par les événements, examinons un appel d'API synchrone.

Serverless deep dive synchronous api call

Les clients tirent parti de vos microservices en effectuant des appels d’API HTTP. Amazon API Gateway héberge des requêtes HTTP RESTful et répond aux consommateurs. AWS Lambda contient la logique métier pour traiter les appels API entrants et exploiter DynamoDB comme un stockage persistant.

Lorsqu'elle est invoquée de manière synchrone, la passerelle API Gateway attend une réponse immédiate et dispose d'un délai d'attente de 30 secondes. Avec les sources d'événements synchrones, si la réponse Lambda dépasse 30 secondes, vous devez rédiger le code de nouvelle tentative et de traitement des erreurs. De ce fait, toute erreur ou problème de mise à l'échelle survenant avec un composant en aval du client, tel que les unités de capacité de lecture/écriture dans DynamoDB, sera renvoyé au client pour que le code de front-end soit traité. En utilisant des modèles asynchrones et en découplant ces composants, vous pouvez construire un système plus robuste et très évolutif.

Envoyer des notifications d'événements de distribution

Apprenez à mettre en œuvre un scénario de messagerie déployé dans lequel les messages sont envoyés par notification push à plusieurs abonnés, ce qui rend inutile toute vérification ou recherche régulière des mises à jour, et autorise le traitement asynchrone parallèle du message par les abonnés.

Début du didacticiel >>

Intégrer Amazon EventBridge dans vos applications sans serveur

Découvrez comment créer un producteur et un consommateur d'événements dans AWS Lambda, et créer une règle pour l'acheminement des événements..

Début du didacticiel >>

Opter pour des architectures guidées par les événements
Déclencheurs et sources d’événement

Les fonctions Lambda sont déclenchées par des événements. Elles exécutent ensuite le code en réponse au déclencheur et peuvent également générer leurs propres événements. Il existe de nombreuses possibilités pour déclencher une fonction Lambda. Vous disposez par ailleurs d'une grande souplesse pour créer des sources d'événements personnalisées afin de répondre précisément à vos besoins.

Les principaux types de sources d'événements sont les suivants :

  • Les magasins de données comme Amazon S3, Amazon DynamoDB ou Amazon Kinesis peuvent déclencher des fonctions Lambda. S’ils stockent des données dont vous souhaitez suivre les modifications, vous pouvez les utiliser comme source d'événements.
  • Les terminaux qui émettent des événements peuvent invoquer une fonction Lambda.. Par exemple, lorsque vous demandez à Alexa de faire quelque chose, elle émet un événement qui déclenche une fonction Lambda.
  • Les services de messagerie comme Amazon SQS ou Amazon SNS peuvent également constituer des sources d’événement.. Par exemple, lorsque vous envoyez quelque chose vers une rubrique SNS, cela peut déclencher une fonction Lambda.
  • Lorsque certaines actions se produisent au sein d'un référentiel, par exemple lors de l'envoi de code à votre compte AWS CodeCommit, cela peut déclencher une fonction Lambda pour, par exemple, lancer votre processus de construction de CI/CD.
Serverless deep dive event source trigger
Appel des fonctions AWS Lambda

Découvrez en plus sur l’appel des fonctions Lambda AWS dans le Guide du développeur.

Consultez le Guide du développeur >>

Choisir des événements, des files d’attente, des rubriques et des flux dans une application sans serveur
Architectures de référence

Dans cette section, vous trouverez une suite d'architectures de référence couvrant les cas d'utilisation courants d'applications sans serveur.

  • Microservices RESTful

    Les technologies sans serveur s'appuient sur une infrastructure hautement disponible et tolérante aux pannes, ce qui vous permet de mettre en place des services fiables pour vos charges de travail critiques. Les principaux services AWS sans serveur sont étroitement intégrés à des dizaines d'autres services AWS et bénéficient d'un riche écosystème d'outils AWS et de partenaires tiers. Cet écosystème vous permet de rationaliser le processus de construction, d'automatiser les tâches, de coordonner les services et les dépendances, et de surveiller vos microservices. Avec les services sans serveur AWS, vous payez à l’utilisation uniquement. Cela vous permet de développer l'utilisation avec votre entreprise et de maintenir des coûts bas lorsque l'utilisation est faible. Toutes ces fonctionnalités font des technologies sans serveur l'outil idéal pour mettre en place des microservices résilients.

    Exemple d’architecture de microservices RESTful

    Serverless deep dive restful microservice architecture

    Les clients tirent parti de vos microservices en effectuant des appels d’API HTTP. Idéalement, vos consommateurs doivent avoir un contrat de service étroitement lié à votre API pour atteindre des attentes cohérentes en matière de niveaux de service et de contrôle des changements.

    Amazon API Gateway héberge des requêtes HTTP RESTful et répond aux consommateurs. Dans ce scénario, la passerelle API offre des fonctions intégrées d'autorisation, de limitation, de sécurité, de tolérance aux pannes, de mappage des demandes/réponses et d'optimisation des performances.

    AWS Lambda contient la logique métier pour traiter les appels API entrants et exploiter DynamoDB comme un stockage persistant.

    Amazon DynamoDB stocke en permanence des données sur les microservices et s’adapte en fonction de la demande. Comme les microservices sont souvent conçus pour un but précis, un magasin de données NoSQL sans schéma est régulièrement incorporé.

  • Traitement des images

    Le traitement des images est une charge de travail courante qui peut être déclenchée par des événements et qui nécessite une mise à l'échelle dynamique. Pour cela, les technologies sans serveur sont idéales. En général, les images sont stockées dans Amazon S3, qui peut déclencher des fonctions Lambda pour le traitement. Après traitement, la fonction Lambda peut renvoyer la version modifiée vers un autre compartiment S3 ou vers la passerelle API.

    Le diagramme ci-dessous présente l'architecture Serverless Image Handler que vous pouvez déployer automatiquement à l'aide du guide d'implémentation de la solution et du modèle AWS CloudFormation fourni.

    Serverless deep dive image handler

    AWS Lambda récupère les images de votre compartiment Amazon Simple Storage Service (Amazon S3) et utilise Sharp pour retourner une version modifiée de l'image à Amazon API Gateway. La solution génère un nom de domaine Amazon CloudFront qui fournit un accès en cache à l'API de gestionnaire d'images.

    De plus, elle solution déploie une interface utilisateur de démonstration facultative dans laquelle vous pouvez interagir directement avec le point de terminaison de votre API de gestionnaire d'images à l'aide de fichiers image qui existent déjà dans votre compte. L'interface de démonstration est déployée dans un compartiment Amazon S3 pour permettre aux clients de commencer immédiatement à manipuler des images avec une interface Web simple. CloudFront est utilisé pour restreindre l'accès au contenu du compartiment de site Internet de la solution.

    Déployer la solution >>

  • Traitement des flux

    Vous pouvez utiliser AWS Lambda et Amazon Kinesis pour traiter en temps réel des données diffusées en continu dans les cas suivants : suivi des activités d'une application, traitement d'ordres de transaction, analyse de parcours de navigation, nettoyage de données, génération de mesures, filtrage de journaux, indexation, analyse de réseaux sociaux, télémétrie et mesure des données d'appareils de l'Internet des objets (IoT).

    Exemple d’architecture de traitement des flux

    serverless deep dive stream processing

    L'architecture décrite dans ce diagramme peut être créée avec un modèle AWS CloudFormation. Le modèle permet :

    • de créer un flux Kinesis ;
    • de créer la table DynamoDB -EventData ;
    • de créer la fonction 1 Lambda Function (-DDBEventProcessor) qui reçoit les enregistrements de Kinesis et les consigne dans la table DynamoDB ;
    • de créer un rôle et une stratégie IAM pour permettre à la fonction Lambda de traitement des événements de lire dans le flux Kinesis et d’écrire dans la table DynamoDB ;
    • de créer un utilisateur IAM autorisé à regrouper les événements dans le flux Kinesis avec des informations d’identification que l’utilisateur pourra utiliser dans un client API.
  • Application Web

    Grâce à l'informatique sans serveur sur AWS, vous pouvez déployer toute votre pile d'applications web sans avoir à gérer de serveurs, de capacité de provisionnement ou à payer pour des ressources inutilisées. De plus, vous n'avez pas à faire de compromis sur la sécurité, la fiabilité ou les performances. Les applications web construites à l'aide de technologies sans serveur offrent une haute disponibilité et peuvent s'étendre à l'échelle mondiale à la demande.

    serverless deep dive web application
    1. Les consommateurs de cette application web peuvent être géographiquement concentrés ou répartis dans le monde entier. L'utilisation d'Amazon CloudFront permet non seulement d'améliorer les performances de ces consommateurs grâce à la mise en cache et au routage optimal de l'origine, mais aussi de limiter les appels redondants vers votre backend.
    2. Amazon S3 héberge les actifs statiques des applications web et est desservie de manière sécurisée par CloudFront.
    3. Un pool d’utilisateurs Amazon Cognito offre des fonctions de gestion des utilisateurs et de fournisseur d'identité pour votre application web.
    4. Dans de nombreux cas, comme le contenu statique d'Amazon S3 est téléchargé par le consommateur, le contenu dynamique doit être envoyé à votre application ou reçu par elle. Par exemple, lorsqu'un utilisateur soumet des données via un formulaire, Amazon API Gateway sert de point d'accès sécurisé pour effectuer ces appels et renvoyer les réponses affichées par votre application web.
    5. Une fonction AWS Lambda fournit à votre application web des opérations de lecture, de mise à jour et de suppression (CRUD) par-dessus DynamoDB.
    6. Amazon DynamoDB peut fournir le magasin de données NoSQL en arrière-plan pour s'adapter de manière élastique au trafic de votre application web.
Déploiement

Une des meilleures pratiques pour les déploiements dans une architecture de microservices consiste à s'assurer qu'un changement n’interrompt pas le contrat de service du consommateur. Si le propriétaire de l'API effectue une modification qui interrompt ce contrat et que le consommateur n'y est pas préparé, des défaillances peuvent survenir.

Pour comprendre l'impact des changements de déploiement, vous devez savoir quels consommateurs utilisent votre API. Vous pouvez collecter des métadonnées sur l'utilisation à l’aide de clés d'API. Celles-ci peuvent également servir de contrat si un changement disruptif est apporté à une API.

Lorsque les clients souhaitent atténuer l'impact des modifications apportées à une API, ils peuvent cloner l'API et diriger les clients vers un autre sous-domaine (par exemple, v2.my-service.com) pour s'assurer que les consommateurs existants ne sont pas touchés. Cette approche permet aux clients de ne déployer que les nouveaux changements apportés au nouveau contrat de service API, mais s'accompagne de compromis. Les clients adoptant cette approche doivent maintenir deux versions de l'API, et s'occuper de la gestion de l'infrastructure et faire face à des frais de mise en service.

Déploiement
Impact sur les consommateurs
Rollback Facteurs de modèle d'événement
Vitesse de déploiement
Tout en un Tout en un Redéployer une version plus ancienne N’importe quel modèle d'événement à faible taux de simultanéité Immédiat
Blue/Green Tout en un, avec un certain niveau de test préalable de l'environnement de production Retour à l'environnement antérieur du trafic Meilleur pour les modèles d'événements asynchrones et synchronisés à des charges de travail simultanées moyennes De quelques minutes à plusieurs heures de validation, puis immédiatement aux clients
Canari/Linéaire 1 à 10 % de déplacement initial typique du trafic, puis augmentations progressives ou tout en un Rétablissement de 100 % du trafic au déploiement précédent Amélioration pour les charges de travail hautement simultanées De quelques minutes à plusieurs heures
  • Déploiements tout en un

    Les déploiements « tout-en-un » consistent à apporter des changements en plus de la configuration existante. Un avantage de ce style de déploiement est que les changements en arrière-plan des magasins de données, tels qu'une base de données relationnelle, nécessitent un niveau d'effort beaucoup plus faible pour rapprocher les transactions au cours du cycle de changement. Bien que ce type de déploiement soit peu coûteux et puisse être effectué avec peu d'impact dans les modèles à faible taux de change, il ajoute un risque lorsqu'il s'agit de revenir en arrière et entraîne généralement des temps d'arrêt. Un exemple de scénario pour utiliser ce modèle de déploiement est celui des environnements de développement où l'impact sur l'utilisateur est minimal.

    Essayer un déploiement tout en un >>

  • Déploiements Blue/Green

    Avec le schéma de déploiement Blue/Green, les clients déplacent une partie du trafic vers le nouvel environnement en direct (Green) tout en gardant l'ancien environnement (Blue), au cas où le système ait à être réinstallé. Avec ce modèle, il est préférable de limiter les changements afin de pouvoir faire des retours en arrière rapidement et facilement. Les déploiements Blue/Green sont conçus pour réduire les temps d'arrêt et de nombreux clients les utilisent pour les déployer en production. La passerelle API vous permet de définir facilement quel pourcentage du trafic est transféré vers le nouvel environnement Green, ce qui en fait un outil efficace pour ce schéma de déploiement.

    Ce style de déploiement est particulièrement adapté aux architectures sans serveur, qui sont à la fois sans état et dissociées de l'infrastructure sous-jacente.

    Vous devez disposer des bons indicateurs pour savoir si un rollback est nécessaire. Comme meilleure pratique, nous recommandons aux clients d'utiliser les métriques haute résolution de CloudWatch, qui peuvent surveiller à intervalle d'une seconde et saisir rapidement les tendances à la baisse. Utilisé avec les alarmes de CloudWatch, vous pouvez permettre un rollback accéléré.. Les métriques CloudWatch peuvent être saisies sur API Gateway, Step Functions, Lambda (y compris les métriques personnalisées) et DynamoDB.

  • Déploiements Canary

    Les déploiements Canary sont un moyen de plus en plus fréquent de tirer parti de la nouvelle version d'un logiciel dans un environnement contrôlé et de permettre des cycles de déploiement rapides. Ces déploiements impliquent le déploiement d'un petit nombre de requêtes au nouveau changement pour analyser l'impact sur un petit nombre de vos utilisateurs.

    Avec les déploiements Canari dans API Gateway, vous pouvez déployer un changement sur votre terminal de backend (par exemple, Lambda) tout en conservant le même terminal HTTP API Gateway pour les consommateurs. En outre, vous pouvez contrôler quel pourcentage du trafic est acheminé vers un nouveau déploiement et pour une coupure de trafic contrôlée. Un nouveau site web peut constituer un scénario pratique pour un déploiement Canari. Vous pouvez surveiller les taux de clics sur un petit nombre d'utilisateurs finaux avant de transférer tout le trafic vers le nouveau déploiement.

    Mise en œuvre de déploiements Canary de fonctions Lamba AWS avec migration du trafic d’alias

    Découvrez comment mettre en œuvre les déploiements Canary des fonctions AWS Lambda.

    Lire le billet de blog >>

    Déployer progressivement des applications sans serveur

    AWS SAM prévoit des déploiements Lambda progressifs pour votre application sans serveur.

    Consultez le Guide du développeur >>

Ressources supplémentaires

Didacticiels de prise en main
Accédez à la liste complète des didacticiels sur les systèmes sans serveurs et bénéficiez d'un apprentissage plus pratique.
Visionner les didacticiels de prise en main >>
Blog AWS Serverless
Lisez les dernières nouveautés et mises à jour relatives aux activités sans serveur sur le blog AWS Serverless.
Lire les articles de blog >>
Découverte approfondie d'une catégorie
Plongez-vous dans des technologies spécifiques et tirez le meilleur parti du Cloud AWS.
Voir la découverte approfondie d'une catégorie >>