Comment concevoir vos applications Serverless pour le passage à l’échelle

Serverless est l’un des modèles de design les plus importants du cloud aujourd’hui, vous permettant de vous concentrer sur la création, la construction et l’innovation, plutôt que de vous soucier de la gestion des serveurs et de leur système d’exploitation. Dans cette publication, nous allons examiner les modèles d’architecture conçus pour passer à l’échelle avec l’approche serverless.

Considérations pour un passage à l’échelle

En général, les développeurs dans un monde « serveur » doivent s’inquiéter du nombre total de requêtes par serveur pouvant être traitées tout au long de la journée, de la semaine ou du mois, et de la rapidité avec laquelle leur système peut évoluer. Au fur et à mesure que vous pénétrez dans le monde serverless, la question la plus importante que vous devez vous poser est : « Quelle est le niveau de concurrence que votre système doit pouvoir gérer ? ».

La plateforme AWS Serverless vous permet d’évoluer très rapidement en réponse à la demande. Voici un exemple de conception serverless entièrement synchrone pour une application. Pendant les périodes de forte demande, Amazon API Gateway et AWS Lambda vont évoluer en fonction de votre charge entrante. En conséquence, cette conception impose une charge extrêmement élevée sur votre base de données relationnelle car Lambda peut facilement évoluer de milliers à des dizaines de milliers de demandes simultanées. Dans la plupart des cas, vos bases de données relationnelles ne sont pas conçues pour accepter le même nombre de connexions simultanées. Ce design peut créer des goulots d’étranglement dans votre base de données relationnelle et peut engendrer des pannes de service mais aussi la perte de données en raison de la limitation ou de la non disponibilité de la connexion à la base de données.

Cloud Native Design

Au lieu de cela, vous devriez envisager de découpler votre architecture et de passer à un modèle asynchrone. Dans cette architecture, vous utilisez un service intermédiaire pour mettre en mémoire tampon les demandes entrantes, telles qu’Amazon Kinesis ou Amazon Simple Queue Service (SQS). Vous pouvez configurer Kinesis ou SQS comme sources d’événements externes pour Lambda. Dans la conception ci-dessous, AWS interroge automatiquement votre flux Kinesis ou votre ressource SQS pour trouver de nouveaux enregistrements et les transmet à vos fonctions Lambda. Vous pouvez contrôler la taille du batch par livraison et placer d’autres paliers sur la base des fonctions Lambda. Cette conception vous permet d’accepter un volume extrêmement élevé de requêtes, de stocker les requêtes dans un datastore durable et de les traiter à la vitesse que votre système peut gérer.

Conclusion

Les services serverless vous permettent d’évoluer beaucoup plus rapidement en comparaison des applications basées sur des serveurs (virtualisés ou non), mais cela signifie que les architectes logiciels doivent toujours tenir compte en amont des effets de la mise à l’échelle vers vos services. Gardez toujours à l’esprit le coût, la vitesse et la fiabilité lorsque vous créez vos applications serverless. Notre prochain article de cette série abordera les différentes façons d’invoquer vos fonctions AWS Lambda et comment concevoir vos applications de manière appropriée.

À propos des auteurs

George Mao est Solutions architect spécialiste chez AWS, et plus particulièrement sur la plate-forme Serverless. George est chargé d’aider les clients à concevoir et à exploiter des applications serverless à l’aide de services tels que Lambda, API Gateway, Cognito et DynamoDB. Il est un conférencier régulier lors des AWS Summits, de re:Invent et de divers événements technologiques.

Traduit en français par Maxime Thomas, Partner Solutions architect chez AWS.

Source