Aujourd'hui, de nombreuses entreprises créent des applications en temps réel pour améliorer leur expérience client et obtenir des informations immédiates à partir de leurs données avant qu'elles ne perdent de leur valeur. En conséquence, les entreprises ont été confrontées à une demande croissante pour fournir des services de streaming de données tels que Apache Kafka pour les développeurs. Pour répondre à cette demande, les entreprises commencent généralement par un cluster Apache Kafka centralisé de petite ou moyenne taille pour créer un service de streaming mondial. Au fil du temps, ils adaptent la capacité du cluster pour répondre à la demande de streaming. Ils choisissent de conserver un cluster monolithique pour simplifier le staffing et la formation en réunissant toutes les expertises techniques en un seul lieu. Cette approche présente également des avantages en termes de coûts, car elle réduit la dette technique, les coûts opérationnels globaux et la complexité. Dans un cluster monolithique, la capacité supplémentaire est partagée entre toutes les applications, ce qui réduit généralement le coût global de l'infrastructure de streaming.

Dans cet article, j'explique quelques défis avec une approche centralisée et présente deux stratégies pour mettre en œuvre une approche décentralisée, en utilisant Amazon MSK sans serveur. Une stratégie décentralisée vous permet de provisionner plusieurs clusters Apache Kafka au lieu d'un monolithique. J'explique comment cette stratégie vous aide à optimiser les clusters en fonction des besoins de sécurité, de stockage et de performances de votre application. J'aborde également les avantages d'un modèle décentralisé et comment migrer d'un cluster monolithique vers un modèle de déploiement multi-cluster.

MSK Serverless peut réduire les frais généraux et les coûts de gestion des clusters Apache Kafka. Il provisionne et dimensionne automatiquement les ressources de calcul et de stockage pour les clusters Apache Kafka et gère automatiquement la capacité des clusters. Il surveille la façon dont les partitions sont réparties sur les nœuds principaux et réaffecte les partitions automatiquement si nécessaire. Il s'intègre à d'autres services AWS tels que Amazon Cloud Watch, où vous pouvez surveiller l'intégrité du cluster. Le choix de MSK Serverless dans cet article est délibéré, même si les concepts peuvent également être appliqués à l'offre provisionnée Amazon MSK.

Présentation de la solution

Apache Kafka est une plate-forme open source, hautes performances, tolérante aux pannes et évolutive pour la création de pipelines et d'applications de données de streaming en temps réel. Apache Kafka simplifie la production et la consommation de données en continu en dissociant les producteurs des consommateurs. Les producteurs interagissent simplement avec un seul magasin de données (Apache Kafka) pour envoyer leurs données. Les consommateurs lisent les données en flux continu, indépendamment de l'architecture ou du langage de programmation des producteurs.

Apache Kafka est un choix populaire pour de nombreux cas d'utilisation, tels que :

• Analyse en temps réel du Web et des journaux
• Sourcing transactionnel et événementiel
• Messagerie
• Découplage des microservices
• ETL en continu (extraction, transformation et chargement)
• Métriques et agrégation de journaux

Défis avec un cluster Apache Kafka monolithique

Monolithic Apache Kafka évite aux entreprises d'avoir à installer et à maintenir plusieurs clusters dans leurs centres de données. Cependant, cette approche présente des inconvénients communs :

• Toute la capacité de streaming est consolidée en un seul endroit, ce qui rend la planification de la capacité difficile et compliquée. Vous avez généralement besoin de plus de temps pour planifier et reconfigurer le cluster. Par exemple, lors de la préparation de ventes ou de grands événements de campagne, il est difficile de prévoir et de calculer une agrégation de la capacité nécessaire pour toutes les applications. Cela peut également freiner la croissance de votre entreprise, car la reconfiguration d'un grand cluster pour une nouvelle charge de travail prend souvent plus de temps qu'un petit cluster.
• Des conflits organisationnels peuvent survenir concernant la propriété et la maintenance du cluster Apache Kafka, car un cluster monolithique est une ressource partagée.
• Le cluster Apache Kafka devient un point de défaillance unique. Tout temps d'arrêt signifie la panne de toutes les applications associées.
• Si vous choisissez de augmenter la résilience d'Apache Kafka avec un déploiement multi-centres de données, alors vous devez généralement avoir un cluster de la même taille (aussi grand) dans l'autre centre de données, ce qui est coûteux.
• Les activités de maintenance et d'exploitation, telles que mises à niveau de version ou l'installation de correctifs de système d'exploitation, prend beaucoup plus de temps pour les clusters plus grands en raison de la nature distribuée de l'architecture Apache Kafka.
• Une application défectueuse peut avoir un impact sur la fiabilité de l'ensemble du cluster et d'autres applications.
• Les mises à niveau de version doivent attendre que toutes les applications soient testées avec la nouvelle version d'Apache Kafka. Cela empêche toute application d'expérimenter rapidement les fonctionnalités d'Apache Kafka.
• Ce modèle rend difficile l'attribution du coût d'exécution du cluster aux applications à des fins de refacturation.

Le schéma suivant montre une architecture Apache Kafka monolithique.

Modèle décentralisé

Un modèle de déploiement Apache Kafka décentralisé implique le provisionnement, la configuration et la maintenance de plusieurs clusters. Cette stratégie n'est généralement pas préférée car la gestion de plusieurs clusters nécessite de lourds investissements dans l'excellence opérationnelle, la surveillance avancée, l'infrastructure en tant que code, la sécurité et l'approvisionnement en matériel dans des environnements sur site.

Cependant, le provisionnement de clusters Apache Kafka décentralisés à l'aide de MSK Serverless ne nécessite pas ces investissements. Il peut augmenter et réduire instantanément la capacité et le stockage en fonction des besoins de l'application, en ajoutant de nouvelles charges de travail ou en faisant évoluer les opérations sans avoir besoin d'une planification complexe de la capacité. Il fournit également un modèle de tarification basé sur le débit, et vous payez pour le stockage et le débit utilisés par vos applications. De plus, avec MSK Serverless, vous n'avez plus besoin d'effectuer des tâches de maintenance standard telles que la mise à niveau de la version d'Apache Kafka, les réaffectations de partition ou les correctifs du système d'exploitation.

Avec MSK Serverless, vous bénéficiez d'un déploiement décentralisé sans la charge opérationnelle généralement associée à un déploiement Apache Kafka autogéré. Dans cette stratégie, les responsables DevOps n'ont pas à passer du temps à provisionner, configurer, surveiller et exploiter plusieurs clusters. Au lieu de cela, ils investissent davantage dans la création d'outils plus opérationnels pour intégrer davantage d'applications en temps réel.

Dans le reste de cet article, je discute de différentes stratégies pour mettre en œuvre un modèle décentralisé. De plus, je souligne les avantages et les défis de chaque stratégie afin que vous puissiez décider ce qui fonctionne le mieux pour votre organisation.

Écrire des clusters et lire des clusters

Dans cette stratégie, les clusters d'écriture sont responsables de l'ingestion des données des producteurs. Vous pouvez ajouter de nouvelles charges de travail en créant de nouvelles rubriques ou en créant de nouveaux clusters MSK Serverless. Si vous avez besoin d'adapter la taille des charges de travail actuelles, vous augmentez simplement le nombre de partitions de vos rubriques si l'ordre n'est pas important. MSK Serverless gère la capacité instantanément selon la nouvelle configuration.

Chaque cluster MSK Serverless fournit jusqu'à 200 Mo/s de débit d'écriture et 400 Mo/s de débit de lecture. Il alloue également jusqu'à 5 Mo/s de débit d'écriture et 10 Mo/s de débit de lecture par partition.

Les consommateurs de données au sein de toute organisation peuvent généralement être divisés en deux catégories principales :

• Charges de travail sensibles au facteur temps, qui nécessitent des données avec une latence très faible (telle que la milliseconde ou la sous-seconde) et ne peuvent tolérer qu'un objectif de temps de récupération (RTO) très court
• Charges de travail insensibles au temps, qui peuvent tolérer une latence plus élevée (latence inférieure à 10 secondes à une minute) et un RTO plus long

Chacune de ces catégories peut également être divisée en sous-catégories en fonction de certaines conditions, telles que la classification des données, la conformité réglementaire ou les accords de niveau de service (SLA). Les clusters de lecture peuvent être configurés en fonction de vos exigences commerciales ou techniques, ou même des limites organisationnelles, qui peuvent être utilisées par le groupe spécifique de consommateurs. Enfin, les consommateurs sont configurés pour s'exécuter sur le cluster de lecture associé.

Pour connecter les clusters d'écriture aux clusters de lecture, un pipeline de réplication de données est nécessaire. Vous pouvez créer un pipeline de réplication de données de plusieurs manières. Étant donné que MSK Serverless prend en charge les API Apache Kafka standard, vous pouvez utiliser les outils Apache Kafka standard tels que MiroirMaker 2 à mettre en place des réplications entre clusters Apache Kafka.

Le diagramme suivant montre l'architecture de cette stratégie.

Cette approche présente les avantages suivants :

• Les producteurs sont isolés des consommateurs ; par conséquent, votre débit d'écriture peut évoluer indépendamment de votre débit de lecture. Par exemple, si vous avez atteint votre débit de lecture maximal avec des clusters existants et que vous devez ajouter un nouveau groupe de consommateurs, vous pouvez simplement provisionner un nouveau cluster MSK Serverless et configurer la réplication entre le cluster d'écriture et le nouveau cluster de lecture.
• Il aide à renforcer la sécurité et la conformité réglementaire. Vous pouvez créer des tâches de diffusion en continu qui peuvent masquer ou supprimer les champs sensibles des événements de données, tels que les informations personnelles identifiables (PII), lors de la réplication des données.
• Différents clusters peuvent être configurés différemment en termes de rétention. Par exemple, les clusters de lecture peuvent être configurés avec différentes périodes de rétention maximales, pour économiser sur les coûts de stockage en fonction de leurs besoins.
• Vous pouvez donner la priorité à votre temps de réponse pour les pannes de certains clusters par rapport aux autres.
• Pour implémenter une résilience accrue, vous pouvez avoir moins de clusters dans la région de sauvegarde en répliquant uniquement les données des clusters d'écriture. D'autres clusters tels que les clusters en lecture peuvent être provisionnés lorsque le basculement de charge de travail est appelé. Dans ce modèle, avec le modèle de tarification MSK Serverless, vous payez en plus pour ce que vous utilisez (réplica plus léger) dans la région de sauvegarde.

Il y a quelques notes importantes à garder à l'esprit lors du choix de cette stratégie :

• Cela nécessite la mise en place de plusieurs réplications entre les clusters, ce qui s'accompagne d'une complexité opérationnelle et de maintenance supplémentaire.
• Les outils de réplication tels que MirrorMaker 2 ne prennent en charge qu'au moins une fois la sémantique de traitement. Cela signifie que pendant les pannes et les redémarrages, les événements de données peuvent être dupliqués. Si vous avez des consommateurs qui ne peuvent pas tolérer la duplication des données, je suggère de créer des pipelines de données qui prennent en charge la sémantique de traitement exactement une fois pour répliquer les données, comme Apache Flink, au lieu d'utiliser MirrorMaker 2.
• Étant donné que les consommateurs ne consomment pas de données directement à partir des clusters d'écriture, la latence est augmentée entre les écrivains et les lecteurs.
• Dans cette stratégie, même s'il existe plusieurs clusters Apache Kafka, la propriété et le contrôle résident toujours dans une seule équipe, et les ressources se trouvent dans un seul compte AWS.

Clusters de ségrégation

Pour certaines entreprises, fournir un accès à Apache Kafka via une plate-forme de données centrale peut créer des problèmes de mise à l'échelle, de propriété et de responsabilité. Les équipes d'infrastructure peuvent ne pas comprendre les besoins commerciaux spécifiques d'une application, tels que les exigences de fraîcheur ou de latence des données, la sécurité, les schémas de données ou une méthode spécifique nécessaire à l'ingestion des données.

Vous pouvez souvent réduire ces défis en donnant la propriété et l'autonomie à l'équipe qui possède l'application. Vous leur permettez de créer et de gérer leur application et l'infrastructure dont ils ont besoin, plutôt que de pouvoir utiliser uniquement une plate-forme centrale commune. Par exemple, les équipes de développement sont responsables du provisionnement, de la configuration, de la maintenance et de l'exploitation de leurs propres clusters Apache Kafka. Ils sont les experts du domaine de leurs exigences applicatives et ils peuvent gérer leur cluster en fonction de leurs besoins applicatifs. Cela réduit la friction globale et rend les équipes d'application responsables de leurs SLA annoncés.

Comme mentionné précédemment, MSK Serverless minimise les travaux d'exploitation et de maintenance associés aux clusters Apache Kafka. Cela permet aux équipes d'applications autonomes de gérer leurs clusters conformément aux meilleures pratiques du secteur, sans avoir besoin d'être un expert dans l'exécution de clusters Apache Kafka hautement disponibles sur AWS. Si le cluster MSK Serverless est provisionné dans leur compte AWS, ils sont également responsables de tous les coûts associés à l'exploitation de leurs applications et des services de streaming de données.

Le diagramme suivant montre l'architecture de cette stratégie.

Cette approche présente les avantages suivants :

• Les clusters MSK Serverless sont gérés par différentes équipes ; par conséquent, le travail de gestion global est minimisé.
• Les applications sont isolées les unes des autres. Une application défectueuse ou un temps d'arrêt d'un cluster n'a pas d'impact sur les autres applications.
• Les consommateurs lisent les données directement avec une faible latence à partir du même cluster où les données sont écrites.
• Chaque cluster MSK Serverless évolue différemment selon son débit d'écriture et de lecture.
• L'attribution simple des coûts signifie que les équipes d'application sont propriétaires de leur infrastructure et de son coût.
• La propriété totale de l'infrastructure de streaming permet aux développeurs d'adopter le streaming plus rapidement et de fournir plus de fonctionnalités. Cela peut également aider à raccourcir leur temps de réponse aux pannes et aux pannes.

Par rapport à la stratégie précédente, cette approche présente les inconvénients suivants :

• Il est difficile d'appliquer une sécurité unifiée ou une conformité réglementaire à travers de nombreuses équipes.
• Des copies en double des mêmes données peuvent être ingérées dans plusieurs clusters. Cela augmente le coût global.
• Pour augmenter la résilience, chaque équipe doit individuellement configurer des réplications entre les clusters MSK Serverless.

Passer d'une stratégie centralisée à une stratégie décentralisée

MSK Serverless fournit Interface de ligne de commande AWS (AWS CLI) et prise en charge des outils AWS CloudFormation modèles pour provisionner des clusters en quelques minutes. Vous pouvez mettre en œuvre l'une des stratégies que j'ai mentionnées précédemment via les méthodes fournies par AWS et migrer vos producteurs et consommateurs lorsque les nouveaux clusters sont prêts.

Les étapes suivantes fournissent des conseils supplémentaires sur la mise en œuvre de ces stratégies :

1. Commencez par vous concentrer sur les problèmes actuels avec le monolithique Apache Kafka. Ensuite, comparez les défis avec les avantages et les inconvénients, comme indiqué sous chaque stratégie. Cela vous aide à décider quelle stratégie sert le mieux votre entreprise.
2. Identifiez et documentez séparément les exigences de performance, de résilience, de SLA et de propriété de chaque application.
3. Essayez de regrouper les applications qui ont des exigences similaires. Par exemple, vous pouvez trouver quelques applications qui exécutent des analyses par lots ; par conséquent, ils ne sont pas sensibles à la fraîcheur des données et n'ont pas non plus besoin d'accéder aux données sensibles (ou PII). Si vous décidez que la séparation des clusters est la bonne stratégie pour votre entreprise, vous pouvez choisir de regrouper les applications en fonction de l'équipe qui les possède.
4. Comparez les exigences de stockage et de débit de streaming de chaque groupe d'applications avec les Quotas MSK sans serveur. Cela vous aide à déterminer si un cluster MSK Serverless peut fournir la capacité de streaming agrégée nécessaire. Sinon, divisez davantage les grands groupes en plus petits.
5. Créez des clusters MSK Serverless pour chaque groupe que vous avez identifié précédemment via le Console de gestion AWS, AWS CLI ou modèles CloudFormation.
6. Identifiez les rubriques qui correspondent à chaque nouveau cluster MSK Serverless.
7. Choisis le meilleur modèle de migration vers Amazon MSK selon les exigences de réplication. Par exemple, lorsque vous n'avez pas besoin de transformation de données et que les événements de données en double peuvent être tolérés par les applications, vous pouvez utiliser des outils de migration Apache Kafka tels que MirrorMaker 2.0.
8. Après avoir vérifié que les données sont correctement répliquées sur les nouveaux clusters, redémarrez d'abord les consommateurs sur le nouveau cluster. Cela garantit qu'aucune donnée ne sera perdue à la suite de la migration.
9. Une fois que les consommateurs ont repris le traitement des données, redémarrez les producteurs sur le nouveau cluster et arrêtez le pipeline de réplication que vous avez créé précédemment.

Au moment d'écrire ces lignes, MSK Serverless ne prend en charge que Gestion des identités et des accès AWS (IAM) pour l'authentification et le contrôle d'accès. Pour plus d'informations, reportez-vous à La sécurisation d'Apache Kafka est simple et familiarisée avec le contrôle d'accès IAM pour Amazon MSK. Si vos applications utilisent d'autres méthodes prises en charge par Apache Kafka, vous devez modifier votre code d'application pour utiliser le contrôle d'accès IAM à la place ou utiliser l'offre provisionnée Amazon MSK.

Résumé

MSK Serverless élimine les frais généraux opérationnels, y compris le provisionnement, la configuration et la maintenance d'Apache Kafka hautement disponible. Dans cet article, j'ai montré comment le fractionnement des clusters Apache Kafka permet d'améliorer la sécurité, les performances, l'évolutivité et la fiabilité de vos services et applications de streaming de données. J'ai également décrit deux stratégies principales pour diviser un cluster Apache Kafka monolithique à l'aide de MSK Serverless. Si vous utilisez l'offre provisionnée Amazon MSK, ces stratégies sont toujours pertinentes lorsque vous envisagez de passer d'un modèle centralisé à un modèle décentralisé. Vous pouvez décider de la bonne stratégie en fonction des besoins spécifiques de votre entreprise.

Pour en savoir plus sur Amazon MSK, visitez le site officiel page produit.

À propos de l’auteur

Ali Alémi est un architecte de solutions spécialiste du streaming chez AWS. Ali conseille les clients AWS sur les meilleures pratiques architecturales et les aide à concevoir des systèmes de données d'analyse en temps réel fiables, sécurisés, efficaces et rentables. Il travaille à partir des cas d'utilisation des clients et conçoit des solutions de données pour résoudre leurs problèmes commerciaux. Avant de rejoindre AWS, Ali a accompagné plusieurs clients du secteur public et partenaires de conseil AWS dans leur parcours de modernisation des applications et de migration vers le cloud.