Nous sommes fin 2025, et un autre AWS re:Invent vient de se conclure, mais en tant qu'ingénieur profondément impliqué, je me retrouve à réfléchir moins aux annonces les plus récentes et davantage à celles qui ont véritablement mûri au cours de l'année écoulée. Plus précisément, les développements révolutionnaires dévoilés lors de re:Invent 2023 concernant les capacités de mise à l'échelle d'AWS Lambda et l'introduction d'Amazon S3 Express One Zone ont fondamentalement modifié notre approche des architectures serverless et de stockage haute performance. Il ne s'agit pas simplement de nouvelles fonctionnalités ; ce sont des outils éprouvés que nous avons mis à l'épreuve, et les chiffres racontent une histoire intéressante.
Dépassons le marketing et plongeons dans les réalités pratiques de ce que ces mises à jour signifient pour vos charges de travail de production, avec des benchmarks et les inévitables compromis.
Le nouveau paradigme de mise à l'échelle d'AWS Lambda : briser les goulots d'étranglement
Pendant des années, le talon d'Achille de nombreuses applications serverless hautement burstables sur AWS Lambda n'était pas la vitesse d'exécution des fonctions individuelles, mais plutôt la vitesse à laquelle Lambda pouvait provisionner de nouveaux environnements d'exécution. Avant re:Invent 2023, Lambda mettait à l'échelle les fonctions invoquées de manière synchrone en créant 500 à 3 000 nouveaux environnements d'exécution au cours de la première minute (selon la région), suivis de 500 environnements supplémentaires chaque minute. Il est crucial de noter que ces quotas de mise à l'échelle étaient partagés entre toutes les fonctions Lambda au sein d'un compte dans une région donnée. Cela signifiait qu'une augmentation soudaine du trafic vers une fonction populaire pouvait priver une autre fonction critique de la capacité de mise à l'échelle nécessaire, entraînant des limitations et une latence accrue.
Les chiffres racontent une histoire intéressante : 12 fois plus rapide, une mise à l'échelle indépendante
L'annonce de re:Invent 2023 a fondamentalement modifié cette dynamique. AWS Lambda met désormais à l'échelle chaque fonction invoquée de manière synchrone jusqu'à 12 fois plus rapidement, lui permettant de provisionner 1 000 exécutions simultanées tous les 10 secondes. Plus important encore, chaque fonction met désormais à l'échelle indépendamment jusqu'à ce que la limite de concurrence du compte soit atteinte. Il s'agit d'un changement significatif.
Voici une comparaison brute :
- Avant re:Invent 2023 : Pic initial de 500 à 3 000 exécutions simultanées au cours de la première minute, puis +500/minute, partagé entre les comptes.
- Après re:Invent 2023 : Pic initial de 1 000 exécutions simultanées tous les 10 secondes (soit 6 000 par minute), par fonction, indépendamment.
Cela se traduit par un système beaucoup plus réactif pour les architectures pilotées par les événements. Considérez un scénario avec un point de terminaison d'API basé sur Lambda et une file d'attente SQS traitant les tâches de manière asynchrone, les deux connaissant des pics simultanés. Dans l'ancien modèle, la mise à l'échelle de l'API pouvait être entravée par la demande du processeur de file d'attente, et vice versa. Maintenant, les deux peuvent s'étendre agressivement pour répondre à la demande, chacun consommant sa part de la concurrence totale du compte sans entraver directement la vitesse de montée en charge de l'autre.
Par exemple, le traitement des messages provenant des sources d'événements SQS et Kafka en bénéficie également, permettant un traitement plus rapide des messages et une réduction des arriérés de file d'attente pendant les périodes de pointe. Nous avons observé que cela réduit considérablement la nécessité de stratégies de préchauffage agressives ou de surprovisionnement pour de nombreuses de nos charges de travail burstables.
Vérification de la réalité : toujours un jeu au niveau du compte
Bien que la mise à l'échelle indépendante par fonction soit une amélioration robuste, il est essentiel de se rappeler que la limite de concurrence au niveau du compte existe toujours. Si votre demande globale sur toutes les fonctions dépasse cette limite, vous rencontrerez toujours des limitations. Le quota par défaut est généralement de 1 000 exécutions simultanées, bien qu'il puisse être augmenté de manière significative sur demande. L'implication ici est que, bien que les fonctions individuelles soient plus agiles, la planification globale de la capacité et la surveillance de la concurrence au niveau du compte restent essentielles.
De plus, cette mise à l'échelle rapide peut révéler des goulots d'étranglement dans les services en aval. Une API Gateway, avec sa limite par défaut de 10 000 requêtes par seconde, pourrait devenir le nouveau point de limitation si vos fonctions Lambda mettent désormais à l'échelle beaucoup plus rapidement que votre API Gateway ne peut gérer les requêtes. Une revue architecturale de l'ensemble de votre chemin de requête, et pas seulement de Lambda, est plus importante que jamais.
Un exemple de code rapide (conceptuel) :
Imaginez une fonction Python Lambda déclenchée par une requête HTTP API Gateway :
# app.py
import json
import os
import time
# Simuler une configuration initiale/chargement de dépendances (initialisation du gestionnaire préalable)
# Ce code s'exécute une fois par environnement d'exécution (démarrage à froid)
GLOBAL_RESOURCE = os.getenv('GLOBAL_RESOURCE', 'initialized')
print(f"[{os.getpid()}] Global resource: {GLOBAL_RESOURCE} (initialized at {time.time()})")
def lambda_handler(event, context):
start_time = time.monotonic()
# Simuler un travail qui évolue avec l'invocation
payload = json.loads(event.get('body', '{}'))
task_duration = int(payload.get('duration_ms', 50)) / 1000.0
time.sleep(task_duration) # Simuler un travail d'E/S ou de CPU
end_time = time.monotonic()
response_time_ms = (end_time - start_time) * 1000
print(f"[{os.getpid()}] Invocation completed in {response_time_ms:.2f}ms")
return {
'statusCode': 200,
'body': json.dumps({
'message': f'Processed in {response_time_ms:.2f}ms',
'pid': os.getpid(),
'global_resource': GLOBAL_RESOURCE
})
}
Avec la mise à l'échelle améliorée, le déploiement de cette fonction et sa sollicitation avec une augmentation soudaine de requêtes verrait de nouveaux pid (de nouveaux environnements d'exécution) apparaître beaucoup plus rapidement et de manière plus cohérente qu'auparavant, permettant au système d'absorber la charge beaucoup plus efficacement, à condition que la concurrence du compte et les services en aval puissent suivre le rythme.
Stabilité sous-jacente de la plateforme : Amazon Linux 2023
Une amélioration plus discrète mais fondamentale de re:Invent 2023 a été l'introduction d'Amazon Linux 2023 (AL2023) en tant qu'environnement d'exécution géré et image de base de conteneur pour Lambda. AL2023 fournit un environnement OS uniquement avec une empreinte de déploiement plus petite, des bibliothèques mises à jour (comme glibc) et un nouveau gestionnaire de packages par rapport à son prédécesseur, AL2. Il ne s'agit pas d'un accélérateur de performances direct au même titre que la mise à l'échelle, mais il s'agit d'une amélioration de la plateforme solide qui contribue à des environnements d'exécution personnalisés plus efficaces et servira de base aux futurs environnements d'exécution gérés par Lambda (par exemple, Node.js 20, Python 3.12, Java 21). Des images de base plus petites signifient potentiellement des temps de téléchargement plus rapides pendant les démarrages à froid et un environnement plus moderne et sécurisé.
S3 Express One Zone : une nouvelle couche pour les applications critiques en termes de performances
Pendant près de deux décennies, Amazon S3 est le pilier du stockage cloud, réputé pour sa scalabilité, sa durabilité et sa polyvalence. Cependant, pour les charges de travail extrêmement à faible latence et à QPS élevé (requêtes par seconde) telles que la formation de l'apprentissage automatique, l'analyse interactive ou le calcul haute performance, l'architecture multi-AZ de S3 Standard, bien qu'offrant une durabilité et une disponibilité incroyables, introduisait une latence réseau inhérente qui pouvait devenir un goulot d'étranglement. Des couches de mise en cache personnalisées étaient souvent utilisées, ajoutant de la complexité et des frais généraux opérationnels.
Le "Pourquoi" et le "Quoi" : quelques millisecondes, des millions de requêtes
Voici Amazon S3 Express One Zone, annoncé lors de re:Invent 2023. Cette nouvelle classe de stockage est conçue pour offrir le stockage d'objets cloud le plus rapide, promettant une latence constante de quelques millisecondes et la capacité de s'étendre à des centaines de milliers de requêtes par seconde, voire des millions de requêtes par minute, pour les données fréquemment consultées. La principale différence architecturale est son déploiement dans une seule zone de disponibilité (AZ).
Nuances architecturales pour la performance :
- Buckets de répertoire : Pour atteindre ses objectifs de TPS élevés, S3 Express One Zone introduit un nouveau type de bucket : les Buckets de répertoire. Contrairement aux buckets S3 à usage général qui s'étendent de manière incrémentale, les buckets de répertoire sont conçus pour une mise à l'échelle instantanée à des centaines de milliers de requêtes par seconde. Il s'agit d'une distinction cruciale lors de l'optimisation pour un débit extrême.
- Colocalisation avec le calcul : En stockant les données dans une seule AZ, vous pouvez colocaliser vos ressources de calcul (EC2, ECS, EKS) dans la même AZ, réduisant considérablement la latence du réseau entre le calcul et le stockage. C'est là que réside une partie importante du gain de performance, minimisant les sauts inter-AZ.
- Authentification basée sur la session : Une nouvelle API
CreateSessionest introduite, optimisée pour une authentification et une autorisation plus rapides des requêtes, réduisant encore de quelques millisecondes le chemin de la requête.
Benchmarks et comparaisons : les performances brutes
AWS affirme que S3 Express One Zone est jusqu'à 10 fois plus rapide que S3 Standard. Pour les petits objets, où le temps de premier octet est un facteur dominant, l'avantage est particulièrement prononcé. Lors de tests internes à re:Invent 2023, le téléchargement de 100 000 objets a montré que S3 Express atteignait un débit d'environ 9 Go/s par rapport aux 1 Go/s de S3 Standard, avec des latences moyennes de 80 ms pour S3 Standard tombant à quelques millisecondes pour S3 Express.
Au-delà de la vitesse brute, S3 Express One Zone offre également des coûts de requête 50 % inférieurs à ceux de S3 Standard. Cela, combiné à une utilisation plus efficace du calcul (moins de temps d'inactivité en attendant le stockage), peut entraîner une réduction globale des coûts, certains clients constatant une réduction de jusqu'à 60 % du coût total de possession pour des applications spécifiques.
Cette classe de stockage est un choix pratique pour :
- Formation et inférence IA/ML : Où les modèles accèdent fréquemment à de vastes ensembles de données, souvent petits.
- Analyse interactive : Accélérer les temps de requête pour des services tels qu'Athena ou EMR.
- Traitement multimédia : En particulier pour les flux de travail nécessitant un accès rapide à de nombreux actifs multimédias de petite taille.
- Calcul haute performance : Toute charge de travail extrêmement liée aux E/S.
Vérification de la réalité : compromis en matière de durabilité et de gestion
Le principal compromis avec S3 Express One Zone est son modèle de durabilité mono-AZ. Bien qu'il offre 11 neufs de durabilité dans cette seule AZ (grâce à des contrôles d'intégrité de bout en bout, un stockage redondant sur plusieurs appareils et une surveillance continue), il n'est pas résilient à la perte ou aux dommages d'une zone de disponibilité entière. Cela signifie qu'en cas de défaillance catastrophique d'une AZ (par exemple, incendie, dégât des eaux), les données stockées uniquement dans S3 Express One Zone dans cette AZ pourraient être perdues.
Pour les données critiques, les clients doivent explicitement construire une redondance inter-AZ ou des solutions de sauvegarde (par exemple, répliquer vers S3 Standard dans une autre AZ). Cela ajoute une couche de responsabilité architecturale que la durabilité régionale de S3 Standard abstrait.
Un autre point à considérer est l'introduction d'un nouveau type de bucket ("Directory"). Bien que fonctionnellement puissant, il ajoute une légère complexité à la gestion des buckets S3, obligeant les développeurs à choisir entre les buckets à usage général et les buckets de répertoire en fonction de leurs modèles d'accès et de leurs exigences de performance. Le coût de stockage par Go est également plus élevé que celui de S3 Standard, mais, comme mentionné, cela est souvent compensé par des coûts de requête réduits et une efficacité de calcul accrue.
Implications pratiques et perspectives d'avenir
Un an après leur annonce, la mise à l'échelle améliorée de Lambda et S3 Express One Zone se sont avérés être des ajouts solides et efficaces à la boîte à outils AWS. Nous les avons vus permettre des applications plus réactives, simplifier certains modèles architecturaux (comme la suppression des couches de mise en cache personnalisées pour un accès S3 haute performance) et fournir des économies de coûts tangibles grâce à une utilisation optimisée du calcul.
La mise à l'échelle indépendante des fonctions Lambda a considérablement amélioré notre capacité à gérer des pics de trafic imprévisibles sans préchauffage complexe ni crainte de contention de ressources entre les services. Pour S3, la classe Express One Zone a ouvert des portes aux charges de travail auparavant limitées par la latence du stockage d'objets, en particulier dans l'espace en plein essor de l'IA/ML. Le compromis explicite en matière de durabilité pour des performances extrêmes est un choix de conception clair que les développeurs doivent activement prendre en compte, et non une omission.
Ces développements de re:Invent 2023 soulignent l'attention continue d'AWS portée à la performance, à l'efficacité et à la fourniture aux développeurs d'un contrôle plus précis sur leur infrastructure, même au sein des services serverless et gérés. Alors que nous continuons à repousser les limites des applications cloud natives, ces améliorations fondamentales fournissent une base solide et pragmatique pour l'innovation.
Sources
🛠️ Outils connexes
Explorez ces outils DataFormatHub liés à ce sujet :
- JSON vers YAML - Convertir les modèles CloudFormation
- Encodeur Base64 - Encoder les charges utiles Lambda
