Même les natifs numériques – qui ont démarré leur activité dans le cloud sans applications héritées dans leurs propres centres de données – doivent moderniser leur architecture d’entreprise native du cloud pour améliorer les processus métier, réduire les coûts et fournir des informations en temps réel à leurs applications en aval. Cet article de blog explore les avantages d’une plate-forme de diffusion de données ouverte et flexible par rapport à une file d’attente de messages propriétaire et à des services cloud d’ingestion de données. Un exemple concret montre comment DoorDash a remplacé AWS SQS et Kinesis natifs du cloud par Apache Kafka et Flink.
File d’attente de messages et ETL par rapport au streaming de données avec Apache Kafka
UN file d’attente de messages comme IBM MQ, RabbitMQ ou Amazon SQS permet envoi et réception de messages. Cela fonctionne très bien pour la communication point à point. Cependant, des outils supplémentaires comme Apache NiFi, Amazon Kinesis Data Firehose ou d’autres outils ETL sont nécessaires pour l’intégration et le traitement des données.
UN plate-forme de flux de données comme Apache Kafka fournit de nombreuses fonctionnalités :
- Produire et consommer des messages pour la messagerie en temps réel à n’importe quelle échelle
- Intégration de données pour éviter les architectures spaghetti avec de nombreux composants middleware dans le pipeline de bout en bout
- Traitement de flux traiter et corréler en continu les données de différents systèmes
- Stockage distribué pour un véritable découplage, la gestion de la contre-pression et la rejouabilité des événements, le tout sur une seule plateforme
Le streaming de données avec Kafka fournit un hub de données pour accéder facilement aux événements de différentes applications en aval (peu importe la technologie, l’API ou le paradigme de communication qu’ils utilisent).
Si vous avez besoin de mélanger une infrastructure de messagerie avec des plates-formes ETL, une architecture spaghetti en est la conséquence. Que vous soyez sur site et que vous utilisiez des outils ETL ou ESB, ou que vous soyez dans le cloud et que vous puissiez tirer parti des plateformes iPaaS. Plus vous (devez) combiner de plates-formes dans un seul pipeline de données, plus les coûts, la complexité des opérations et les garanties SLA sont élevés.. C’est l’un des principaux arguments pour lesquels Apache Kafka est devenu la norme de facto pour l’intégration de données.
Cloud-Native est le nouveau noir pour l’infrastructure et les applications
La plupart des architectures d’entreprise modernes tirent parti de l’infrastructure, des applications et du SaaS natifs du cloud, que le déploiement se fasse dans le cloud public ou privé. Une infrastructure cloud-native fournit :
- Automatisation via DevOps et livraison continue
- Échelle élastique avec des conteneurs et des outils d’orchestration comme Kubernetes
- Développement agile avec une conception axée sur le domaine et des microservices découplés
Dans le cloud public, les offres SaaS entièrement gérées sont le moyen privilégié pour déployer l’infrastructure et les applications. Cela inclut des services comme Amazon SQS, Amazon Kinesis et Confluent Cloud pour Apache Kafka entièrement géré. La rare équipe d’experts peut se concentrer sur la résolution de problèmes commerciaux et de nouvelles applications innovantes au lieu d’exploiter l’infrastructure.
Cependant, tout ne peut pas fonctionner en mode SaaS. Le coût, la sécurité et la latence sont les principaux arguments pour lesquels les applications sont déployées dans leur propre VPC cloud, un centre de données sur site ou à la périphérie. Les opérateurs et les CRD pour les scripts Kubernetes ou Ansible sont des solutions courantes pour déployer et exploiter votre propre infrastructure cloud native si l’utilisation d’un produit cloud sans serveur n’est pas possible ou faisable.
DoorDash : de plusieurs pipelines à la diffusion de données pour l’intégration de Snowflake
DoorDash est une société américaine qui exploite une plateforme de commande et de livraison de nourriture en ligne. Avec une part de marché de plus de 50 %, il s’agit de la plus grande entreprise de livraison de nourriture aux États-Unis.
Évidemment, un tel service nécessite des pipelines évolutifs en temps réel pour réussir. Sinon, le modèle économique ne fonctionne pas. Pour des raisons similaires, tous les autres services de mobilité comme Uber et Lyft aux États-Unis, Free Now en Europe ou Grab en Asie utilisent le streaming de données comme base de leurs pipelines de données.
Défis avec plusieurs pipelines d’intégration utilisant SQS et Kinesis au lieu d’Apache Kafka
Événements sont générés à partir de nombreux services DoorDash et appareils utilisateur. Ils doivent être traités et transportés vers différentes destinationsy compris:
- OLAP entrepôt de données pour l’analyse commerciale
- Plateforme d’apprentissage automatique (ML) pour générer des fonctionnalités en temps réel telles que les temps d’attente moyens récents pour les restaurants
- Backend de métrique de séries temporelles pour la surveillance et l’alerte afin que les équipes puissent identifier rapidement les problèmes dans les dernières versions d’applications mobiles
Les pipelines d’intégration et les consommateurs en aval exploitent différentes technologies, API et paradigmes de communication (en temps réel, en temps quasi réel, par lots).
Chaque pipeline est construit différemment et ne peut traiter qu’un seul type d’événement. Cela implique plusieurs sauts avant que les données n’entrent finalement dans l’entrepôt de données.
Il est peu rentable de construire plusieurs pipelines qui tentent d’atteindre des objectifs similaires. DoorDash a utilisé des systèmes de messagerie et de streaming AWS natifs du cloud comme Amazon SQS et Amazon Kinesis pour l’ingestion de données dans l’entrepôt de données Snowflake :
Le mélange de différents types de transport de données et le passage par plusieurs systèmes de messagerie/file d’attente sans observabilité soigneusement conçue entraînent des difficultés d’exploitation.
D’Amazon SQS et Kinesis à Apache Kafka et Flink
Ces problèmes ont entraîné latence élevée des données, coût important et frais généraux opérationnels chez DoorDash. Par conséquent, DoorDash déplacé vers une plate-forme de streaming native du cloud alimentée par Apache Kafka et Apache Flink pour le traitement de flux continu avant l’ingestion de données dans Snowflake :
Le passage à une plate-forme de flux de données offre de nombreux avantages pour DoorDash:
- Sources et destinations de données hétérogènesy compris les API REST utilisant le proxy REST Confluent
- Facile d’accès depuis n’importe quelle application en aval (quel que soit la technologie, l’API ou le paradigme de communication)
- Gouvernance des données de bout en bout avec application du schéma et évolution des schémas avec Confluent Schema Registry
- Évolutif, tolérant aux pannes et facile à utiliser pour une petite équipe
REST/HTTP est complémentaire au streaming de données avec Kafka
Toutes les communications ne sont pas en temps réel et en streaming. Les API HTTP/REST sont cruciales pour de nombreuses intégrations. DoorDash exploite le proxy REST Confluent pour produire et consommer via HTTP vers/depuis Kafka.
Tous les détails sur cette optimisation de l’infrastructure cloud-native sont dans Article de blog d’ingénierie de DoorDash: « Construire un traitement d’événements en temps réel évolutif avec Kafka et Flink. »
Ne sous-estimez pas le verrouillage des fournisseurs et le coût des offres SaaS propriétaires
Une des clés les raisons je vois des clients migrer loin des services cloud propriétaires sans serveur comme Kinesis coûte cher. Bien que cela semble correct au départ, cela peut devenir fou lorsque les charges de travail de données évoluent. Très durée de conservation limitée et capacités d’intégration de données manquantes sont d’autres raisons.
L’exemple DoorDash montre comment même les nouveaux projets natifs du cloud nécessitent une modernisation de l’architecture d’entreprise pour simplifier les pipelines et réduire les coûts.
Un avantage secondaire est l’indépendance d’un fournisseur de cloud spécifique. Avec des moteurs open source comme Kafka ou Flink, l’ensemble du pipeline d’intégration peut être déployé partout. Les déploiements possibles incluent :
- Liaison de clusters entre les pays ou même des continents (y compris le filtrage, l’anonymisation et d’autres traitements pertinents pour la confidentialité des données avant le partage et la réplication des données)
- Plusieurs fournisseurs de cloud (par exemple, si GCP est moins cher qu’AWS ou parce que la Chine continentale ne fournit qu’Alibaba)
- Charges de travail à faible latence ou environnements de sécurité zéro confiance à la périphérie (par exemple, dans une usine, un stade ou un train.
Comment voyez-vous les compromis entre les frameworks open source comme Kafka et Flink et les services cloud propriétaires comme AWS SQS ou Kinesis ? Quels sont vos critères de décision pour faire le bon choix pour votre projet ? Avez-vous déjà migré des services de l’un à l’autre ?