Les entreprises qui utilisent le traitement par lots réagissent souvent aux heures de données ou même aux jours qui suivent les événements. En revanche, les pipelines de traitement de données en temps réel permettent de prendre des décisions immédiates, de détecter les anomalies et de personnaliser les expériences des utilisateurs. Les technologies sans serveur éliminent les frais généraux opérationnels de la gestion des serveurs, ce qui permet de construire ces pipelines avec un fardeau d'infrastructure minimal.

Quelles sont les technologies sans serveur?

L'informatique sans serveur est un modèle d'exécution en nuage où le fournisseur de cloud gère dynamiquement l'allocation et la fourniture des serveurs. Les développeurs écrivent et déploient le code sous forme de fonctions ou de conteneurs, et le fournisseur gère l'échelle, le patching et la disponibilité. Le terme «serverless» ne signifie pas que les serveurs sont absents; plutôt, la gestion du serveur est supprimée. Les principaux fournisseurs tels que AWS Lambda[, Fonctions d'Azure[, et Google Cloud Functions[ sont les services de calcul les plus courants.

Au-delà de la calcul, sans serveur, les services gérés pour l'ingestion de données, le stockage, la messagerie et l'analyse peuvent être assemblés en pipeline sans fournir une seule machine virtuelle. Les caractéristiques principales sont l'échelle automatique, le prix à l'usage et la tolérance aux défauts.

Composantes clés des pipelines de données en temps réel

Un pipeline de données en temps réel est un flux continu où les données sont ingérées, traitées, stockées et mises en œuvre en quelques secondes ou millisecondes.

  • Ingestion des données — le point d'entrée qui capture les événements des producteurs (capteurs IoT, applications mobiles, journaux de serveurs web, bases de données). Les services de flux gérés tels que Amazon Kinesis Data Streams, Azure Event Hubs et Google Cloud Pub/Sub sont conçus pour gérer l'ingestion d'événements durables à haut débit. Ils tamponnent les événements et les rendent disponibles aux consommateurs en ordre.
  • Le traitement des données[ — la transformation, le filtrage, l'agrégation, l'enrichissement ou l'analyse des événements au fil du pipeline.Les fonctions sans serveur — AWS Lambda, Azure Functions, Google Cloud Functions — sont l'option la plus légère pour le traitement apatride, dirigé par un événement.
  • Stockage de données — la destination où les résultats traités sont maintenus pour l'analyse, les tableaux de bord ou la rétention à long terme. Les options vont des magasins à valeur clé (Amazon DynamoDB, Azure Cosmos DB) aux bases de données colonnelar (Google BigQuery, Amazon Redshift Serverless) et aux magasins objets (Amazon S3, Azure Blob Storage). Le choix dépend des modèles de requête, des exigences de latence et du coût.
  • Visualisation et surveillance[ — outils qui fournissent des tableaux de bord, des alertes et une observabilité en temps réel. Les services BI gérés tels qu'Amazon QuickSight, Microsoft Power BI (connecté via des ensembles de données en streaming) et Google Looker Studio peuvent consommer des données en direct. De plus, la surveillance du pipeline lui-même est critique : des services comme Amazon CloudWatch, Azure Monitor et Google Cloud Operations Suite invocations de la fonction de piste, décalage de flux, taux d'erreur et débit.

Ces composants doivent être câblés avec la messagerie, la sécurité et l'orchestration. Les technologies sans serveur rendent chaque pièce évolutive indépendamment, et la colle est souvent fournie par la couche d'intégration d'événements de la plate-forme cloud.

Modèles architecturaux pour pipelines en temps réel sans serveur

Bien que les éléments de construction soient communs, l'architecture que vous choisissez dépend de la nature des données et des garanties requises. Trois modèles dominent :

Fan-out avec les requêtes de message

Les événements arrivent à un seul point d'ingestion (par exemple, un hub ou un flux d'événements) et sont ensuite aspirés à plusieurs fonctions sans serveur ou puits de stockage. Ce modèle est idéal lorsque le même événement brut doit déclencher plusieurs actions indépendantes – par exemple, mettre à jour un tableau de bord en temps réel, écrire un enregistrement au stockage à froid, et envoyer une alerte.

Traitement en chaîne avec fonctions étape

Certains pipelines nécessitent des étapes de traitement séquentielles où la sortie d'une fonction se nourrit dans la suivante. Plutôt que d'orchestrer ces appels manuellement avec du code, des orchestres de service comme AWS Step Functions, Azure Logic Apps ou Google Cloud Workflows coordonnent une séquence de fonctions sans serveur. Ceci est utile pour les transformations comme ETL où les données doivent être validées, enrichies, puis agrégées. L'orchestreur gère les réticulations, la manipulation des erreurs et les branches parallèles, simplifiant la logique globale du pipeline.

Traitement du flux avec le calcul de l'état

Pour les cas d'utilisation impliquant des agrégats fenêtrés (par exemple, en comptant les clics par minute) ou un traitement d'événements complexes (comparaison de modèles d'événements), les fonctions apatrides sont insuffisantes.Les moteurs de traitement de flux sans serveur comme Apache Flink sur Kinesis Data Analytics ou Google Dataflow gèrent l'état, les fenêtres temporelles et exactement une fois sémantique.Ces services fonctionnent de façon sans serveur — vous définissez la logique de traitement (SQL ou Java/Python) et les travailleurs auto-échelles de la plate-forme.

Construction d'un pipeline : exemple de SMA

Pour ancrer les concepts, considérez un scénario concret : ingérer des données de clic web, les traiter pour compter les vues de page par URL dans des fenêtres d'une minute, et stocker les résultats pour un tableau de bord en temps réel.

  1. Ingestion des données: Un flux de données Kinesis avec deux shards (échelles au besoin).Chaque shard peut ingérer 1 MB/s ou 1000 enregistrements/s. Les producteurs — comme une application web ou une session CloudFront — envoient des événements JSON au flux.
  2. Processus de données:[ Une fonction Lambda est déclenchée par le flux Kinesis (en utilisant la cartographie des sources d'événements). La fonction lit des lots d'enregistrements, analyse le JSON et compte le champ `url`. Cependant, les fonctions Lambda sont apatrides et chaque invocation traite un micro-batch. Pour effectuer le comptage par fenêtre, on pourrait écrire des comptes dans une table DynamoDB avec un TTL, puis utiliser un autre Lambda pour agréger.
  3. Storage:[ Le flux de sortie déclenche une autre fonction Lambda qui écrit les comptes agrégés (URL, nombre, temps de fin de fenêtre) à DynamoDB avec un TTL de, par exemple, 24 heures. Simultanément, les événements bruts peuvent être archivés dans S3 en utilisant Kinesis Firehose pour une analyse ultérieure.
  4. Visualisation: Amazon QuickSight se connecte à DynamoDB via Athena (avec un connecteur Athena DynamoDB) pour créer un tableau de bord en temps réel qui rafraîchit chaque minute.

Ce pipeline entier n'utilise aucune instance EC2, aucune mise à niveau manuelle et n'entraîne des coûts que lorsque les données circulent. Les fonctions Lambda, la capacité de lecture/écriture DynamoDB et les heures de travail du Kinesis sont les principaux moteurs de coûts.

Avantages de l'utilisation sans serveur pour les pipelines en temps réel

  • Les services sans serveur s'échelonnent de zéro à des milliers d'exécutions simultanées en secondes. Lors d'une vente flash ou d'un événement viral, le pipeline se partitionne automatiquement pour fonctionner dans plusieurs instances de fonction ou dans des flux de shards — aucune planification de capacité n'est nécessaire.
  • Coût-Efficacité:[ Ne payez que pour les ressources consommées. Les fonctions sont facturées par milliseconde d'exécution; le stockage du flux est par heure GB; les opérations de base de données sont par lecture/écriture. Il n'y a pas de coût pour l'infrastructure en panne.
  • Réduction des frais opérationnels:[ Pas de correctifs de serveur, pas de mises à jour de l'exploitation, pas de prévision de capacité. L'équipe peut se concentrer sur la logique opérationnelle et la qualité des données plutôt que sur la gestion de l'infrastructure.
  • Flexibilité et intégration:[ Chaque fournisseur de cloud offre des dizaines de sources d'événements qui peuvent déclencher des fonctions ou des processeurs de flux — flux de changement de base de données (DynamoDB Streams, Change Data Capture from RDS), téléchargements de fichiers (S3 Events), webhooks, et plus encore.
  • Isolation par défaut:[ Une défaillance dans une fonction invocation ne s'écrase pas d'autres parties du pipeline. Les services comme Lambda ont intégré la logique de ré-essai et les DLQ ( queues de lettres mortes).

Défis et considérations

Les pipelines en temps réel sans serveur sont puissants, mais ils présentent des défis spécifiques que les architectes doivent relever :

  • Cold Starts:[ Lorsqu'une fonction sans serveur n'est pas invoquée pendant une période, la plate-forme doit initialiser un nouveau conteneur, ajoutant de la latence (souvent 100 à 500 ms).Pour les pipelines en temps réel où la latence inférieure à 100 ms est critique, les démarrages à froid peuvent poser problème.
  • Gestion de l'état: Les fonctions sont apatrides par conception. Si un pipeline doit corréler les événements dans le temps (p. ex., détecter une session utilisateur), l'état doit être stocké de l'extérieur (DynamoDB, ElastiCache, ou un processeur de flux sans serveur).
  • Les fonctions Lambda invoquées depuis un flux peuvent recevoir des enregistrements en double en raison de la saisie. Le traitement des données (p. ex., en utilisant des identifiants d'événements uniques et en augmentant le stockage) est un must. Les moteurs de traitement du flux comme Flink peuvent fournir exactement une sémantique dans le pipeline vers les puits en aval, mais les puits eux-mêmes doivent également le soutenir.
  • Surveillance et débogage:[ Avec de nombreuses invocations de fonctions éphémères, l'analyse traditionnelle des log devient écrasante. L'enregistrement centralisé (CloudWatch Logs, Azure Log Analytics), le traçage distribué (AWS X-Ray, OpenTelemetry) et l'enregistrement structuré sont nécessaires.
  • Vendor Lock-in:[ Chaque fournisseur de cloud a sa propre saveur de services sans serveur et d'intégrations d'événements. Un pipeline construit sur Kinesis + Lambda + DynamoDB n'est pas directement portable aux Hubs d'événements Azure + Fonctions Azure + Cosmos DB. Mitigate en abstractionnant la logique du pipeline en code portable (par exemple, en utilisant le standard CloudEvents) et en utilisant des cadres de traitement de flux open-source comme Apache Flink ou Apache Kafka.

Stratégies d'optimisation des coûts

Les modèles de tarification sans serveur nécessitent une conception soignée pour éviter les surprises :

  • Événements par lots: Les fonctions peuvent traiter plusieurs enregistrements par invocation. Avec Kinesis, configurer la taille des lots et la fenêtre des lots pour minimiser le nombre d'invocations. Par exemple, le traitement de 1000 enregistrements dans une exécution de fonction coûte le même coût qu'une exécution – bien moins cher que 1000 invocations distinctes.
  • Compte de taille droite: L'allocation de mémoire Lambda est directement liée au processeur et au débit réseau. Pour les transformations de données liées au processeur (par exemple, analyse JSON, compression), l'augmentation de la mémoire (et donc CPU) peut réduire le temps d'exécution et le coût total (parce que le coût = mémoire * durée).
  • Utilisez les processeurs de flux gérés pour un volume élevé: Pour un débit supérieur à quelques milliers d'enregistrements par seconde, Lambda peut devenir cher en raison des frais par demande. Kinesis Data Analytics ou Azure Stream Analytics, tout en ayant un coût horaire de base, se révèle souvent moins cher par million d'événements parce qu'ils traitent par lots en interne et chargent par unité de streaming.
  • Compresse Données: La compression des événements avant l'envoi au flux réduit les coûts de stockage et le temps d'exécution de Lambda. Gzip ou snappy peut réduire la taille de charge utile significativement. Décompresser dans la fonction.
  • Leverage TTLs:[ Le stockage temporaire (DynamoDB, politiques du cycle de vie S3) devrait avoir une expiration automatique.

Considérations en matière de sécurité

Les pipelines en temps réel traitent souvent des données sensibles. Les meilleures pratiques de sécurité sans serveur sont les suivantes :

  • Least-Privilege IAM:[ Chaque fonction devrait avoir un rôle IAM étroit qui ne subventionne que les actions requises sur des ressources spécifiques. Par exemple, une fonction Lambda de Kinesis devrait avoir `GetRecords`, `DescribeStream`, et `ListShards` sur ce flux spécifique, rien de plus. Utilisez les touches de condition pour limiter aux paramètres VPC source spécifiques si nécessaire.
  • Encrypter les données en transit et au repos:[ Activer le chiffrement sur les flux de Kinesis (AWS KMS), les tables DynamoDB et les seaux S3. Utilisez TLS pour tout appel d'API externe. Les fonctions sans serveur peuvent également utiliser des variables d'environnement avec le chiffrement KMS pour les secrets.
  • VPC Placement:[ Si le pipeline a besoin d'accéder aux ressources à l'intérieur d'un VPC (p. ex., une base de données privée), placez les fonctions de Lambda dans le VPC avec les groupes de sécurité et les sous-réseaux appropriés.
  • Validation et désinfection des entrées:[ Comme les événements peuvent provenir de sources non fiables, les fonctions sans serveur doivent valider et désinfecter toutes les entrées afin d'éviter les attaques par injection ou les données malformées lors de l'écrasement du pipeline.

Cas d'utilisations réelles dans le monde

Des pipelines en temps réel sans serveur sont déployés dans toutes les industries :

  • Personnalisation E-commerce: Diffusion de données de clic pour mettre à jour les modèles de recommandation en temps réel. Les fonctions Lambda enrichissent les événements avec les profils d'utilisateurs de DynamoDB, puis poussent vers un cache comme ElastiCache pour le moteur de recommandation. Les résultats sont affichés sur le site Web en quelques secondes.
  • Détection d'anomalie IoT: Les appareils envoient la télémétrie (température, vibration) aux Hubs d'événements Azure. Une fonction sans serveur dans Azure Functions exécute un modèle de détection d'anomalie légère (par exemple, en utilisant ML.NET ou Python scikit-learn) et déclenche une alerte via Azure Logic Apps si les valeurs dépassent les seuils.
  • Détection de fraude financière : Les événements transactionnels passent par Google Cloud Pub/Sub vers les fonctions Cloud, puis vers Bigtable. Un travail de traitement de flux utilisant Dataflow (Apache Beam) applique des schémas de fenêtre correspondant pour détecter les tests de cartes ou les tentatives de prise en charge de compte.
  • Log analytique à l'échelle:[ Les journaux d'application sont ingérés via Kinesis Firehose directement dans S3 et Elasticsearch (Amazon OpenSearch Serverless). Lambda fonctionne parse et les journaux de structure avant l'indexation.

Ressources extérieures

Pour les plongées plus profondes, consultez ces documents et guides officiels :

Conclusion

En exploitant les services d'ingestion gérés, les ordinateurs axés sur les événements et le stockage évolutif, les équipes peuvent construire des systèmes qui répondent aux données en quelques secondes tout en minimisant le travail d'infrastructure. La clé est de choisir le bon modèle - fonctions apatrides pour des transformations simples, processeurs de flux gérés pour des analyses de fenêtre d'état, et orchestreurs pour des flux de travail en plusieurs étapes. Avec une attention particulière aux démarrages à froid, gestion de l'état et surveillance des coûts, pipelines sans serveur en temps réel peuvent fournir l'élasticité et l'efficacité que les applications modernes exigent. Les fournisseurs de cloud continuent d'investir dans des latences plus faibles, une meilleure gestion de l'état et des intégrations simplifiées, rendant cette approche de plus en plus viable pour les charges de flux critiques pour la mission.