ReInvent 2021 : AWS s’aligne sur la tendance serverless
AWS lance de nouvelles options serverless pour ses services de streaming et d’entreposage de données. Selon les responsables d’AWS, les clients réclament ce mode de déploiement alors que les concurrents et les partenaires du géant du cloud le proposent déjà.
Lors du deuxième jour de sa conférence annuelle, AWS a annoncé plusieurs nouveautés consacrées à son portfolio analytique, comprenant Amazon Athena, EMR, OpenSearch Service, AWS Glue, Lake Formation et Redshift.
Le géant du cloud a présenté la disponibilité en préversion de trois options serverless pour les services Redshift, EMR et MSK (Apache Kafka).
S’il ne s’agit pas de supprimer les serveurs sur lesquels s’exécutent les services, les fournisseurs de cloud promettent aux clients que l’approche serverless permet se débarrasser de la gestion de l’infrastructure sous-jacente. Aussi l’objectif est de ne payer que les ressources de calcul et de stockage utilisées par une application ou une architecture.
La promesse du serverless dédié aux architectures Pub/Sub
« Si certains clients sont soucieux de maîtriser l’infrastructure, la plupart d’entre eux espèrent ne plus l’administrer du tout », assure Rahul Pathak, vice-président, Analytics chez AWS.
« Le serverless réduit la charge que représentent les opérations. Aussi, vous pouvez assez précisément facturer l’usage réel des services. »
Rahul PathakVP, Analytics chez AWS
« Le serverless réduit la charge que représentent les opérations. Aussi, vous pouvez assez précisément facturer l’usage réel des services. Comme la plupart des systèmes Pub/Sub ou de streaming génèrent des charges de travail irrégulières, les gains sont intéressants. C’est moins le cas quand les clients ont des usages linéaires, mais ils sont peu nombreux », ajoute-t-il.
Ainsi, les options serverless d’EMR, de Redshift et de MSK doivent permettre l’élasticité des infrastructures en fonction des charges de travail.
« Les clients peuvent toujours configurer des ressources limites et maximales, le système adaptera automatiquement le calcul et le stockage suivant la charge », affirme Rahul Pathak.
Avec ce modèle, AWS affirme prendre en charge le provisionnement de l’infrastructure, l’élasticité et la sécurité de ces opérations. « Les clients peuvent se concentrer sur le cas d’usage : quelles données peuvent-ils charger ? Quels jobs exécutent-ils ? Quelles applications bâtissent-ils avec ce type de services ? », liste-t-il.
Or dans un projet de streaming de données ou Pub/Sub, l’optimisation des performances est clé. « Nous essayons d’automatiser le plus possible l’optimisation. Nous nous concentrons sur la distribution des données, la compression des données, afin que les requêtes soient efficaces. Le client doit avoir le moins de travail de ce côté-là », préconise Rahul Pathak.
Les concurrents tels Azure avec Synapse, Google avec Spark Serverless suivent la même voie. Des éditeurs spécialisés, dont Confluent, proposent aussi à leurs clients de s’abstraire de la gestion de l’infrastructure et de s’intégrer avec différentes plateformes analytiques, de data lake et autres data stores.
La gestion des ressources ne disparaît pas vraiment
Chez AWS, plusieurs étapes sont encore nécessaires pour accéder à ces options serverless. La première consiste à activer ce modèle depuis le compte principal AWS. Si la configuration du IAM et du VPC est commune aux trois services, ils disposent tous de leurs particularités. Amazon EMR Serverless permet de déployer des applications après avoir choisi le framework Apache Hive, Spark (EMR 6.5 ou l’équivalent de Spark 3.1.2) ou – à l’avenir – Presto pour exécuter des jobs enclenchés depuis une API, la console AWS ou EMR Studio. Ces jobs – par exemple, des requêtes HiveQL ou des scripts PySpark – peuvent s’exécuter dans de multiples zones de disponibilité depuis une seule région et de manière simultanée.
Si les développeurs ou les data engineers n’ont pas la main sur l’infrastructure sous-jacente, ils peuvent toujours récupérer des métriques et ajuster manuellement la configuration des machines nécessaires à l’exécution de leurs workloads.
L’application EMR Serverless s’appuie sur des workers, chacun doté par défaut de 4 VCPU, 30 Go de RAM et de 20 Go de stockage. Ici, AWS a choisi la configuration maximale disponible sur catalogue. Pour des raisons d’efficience ou de coûts, les utilisateurs du service peuvent modifier la taille de chaque worker en modulant le nombre de VCPU par CPU (1, 2 ou 4) et de gigaoctets de RAM, de 1 à 30 Go.
Au moment d’exécuter une tâche, EMR Serverless appelle et planifie les workers configurés par les développeurs. Il invoque automatiquement le nombre de workers nécessaire à un job, qui peuvent être « préinitialisés » (préchauffés en quelque sorte) quand les workloads sont lancés très régulièrement.
Kinesis Data Streams a aussi le droit à son mode à la demande, en disponibilité générale dans toutes les régions AWS cette fois-ci. Le service était déjà identifié comme étant serverless, sauf qu’il fallait tout de même provisionner et gérer les capacités pour traiter les flux de données. Le mode de capacité à la demande fait varier les ressources en fonction du trafic, c’est-à-dire du nombre de gigaoctets écrits, lus et stockés.
AWS promet le même niveau de haute disponibilité, de sécurité et de temps de réponse que la version standard de Kinesis. Une application de streaming bénéficie d’une capacité de 4 Mb/s, et 4 000 enregistrements par seconde en écriture. Kinesis Data Streams On Demand peut aller jusqu’à 200 Mb/s, et 200 000 enregistrements par seconde en écriture, selon un billet de blog d’AWS. Ici, la console de Kinesis suffit à paramétrer ce mode à la demande, sans devoir ajouter de paramètres ou de snippet via un CLI.
Le géant du cloud ne livre pas autant de détails techniques pour Amazon MSK Serverless. Il faut se contenter d’un laïus sur l’automatisation du provisionnement et d’une configuration plus aisée des clusters Apache Kafka, à consommer à la demande. Pourtant, selon les propos relayés par un communiqué de presse AWS, c’est une capacité attendue par les clients, dont Riot Games (l’éditeur du jeu vidéo League of Legend), Intuit, et The Orchard, filiale de Sony Music. La compagnie pharmaceutique suisse Roche, elle, utilise déjà RedShift Serverless pour les nouveaux cas d’usage analytiques.
Avec RedShift, il s’agit de déployer une application comprenant un point de terminaison serverless et une base de données qui peut être requêtée depuis l’éditeur SQL du service. Plusieurs paramètres dont les autorisations, la configuration de la sécurité ou l’audit de logs peuvent être modifiés ou laissés par défaut. AWS précise, dans sa documentation, que la majorité des capacités du data warehouse cloud sont aujourd’hui disponibles en mode serverless sauf certaines dont Spectrum, les paramètres de groupes, la gestion des workloads, l’intégration avec un partenaire AWS et, plus important les fenêtres de maintenance et de mise à jour.
Ici, le mode de facturation dépend du nombre de RedShift Processing Units (RPUs) consommées. Un niveau minimal de 32 à 512 RPUs est configurable par incrément de 8 RPU depuis la console de Redshift Serverless pour les capacités de base. Un niveau maximum peut être instauré. Le prix du stockage des données et des snapshots est identique à celui pratiqué pour la version standard de Redshift.
Lors de la conférence, les responsables d’AWS ont insisté sur la complémentarité de RedShift Serverless, des services de streaming ou Pub/Sub et de QuickSight, la solution de self-service BI.
Enfin, si le serverless est largement mis en avant par AWS, Rahul Pathak assure que le fournisseur de cloud « continuera à développer les autres instances ou modes de déploiement plus traditionnels ».
