Questions fréquentes (FAQ) sur Amazon Managed Streaming for Apache Kafka

Vous pouvez suivre le guide de démarrage Amazon MSK pour configurer un cluster, produire et consommer à partir de celui-ci. En résumé, vous pouvez créer votre premier cluster en quelques étapes dans la console de gestion AWS ou en utilisant les kits SDK AWS. Tout d’abord, dans la console Amazon MSK, sélectionnez une Région AWS dans laquelle créer un cluster MSK. Choisissez un nom pour votre cluster, le cloud privé virtuel (VPC) avec lequel vous voulez exécuter le cluster, et les sous-réseaux de chaque zone de disponibilité. Si vous créez un cluster alloué, vous pouvez également choisir un type d’instance d’agent et le nombre d’agents par zone de disponibilité.

Les clusters alloués contiennent des instances d’agent et des nœuds de métadonnées abstraits. Les clusters sans serveur constituent une ressource en soi, qui fait abstraction de toutes les ressources sous-jacentes.

Dans Apache Kafka, les agents sont les serveurs individuels qui constituent le cluster Apache Kafka. Ils sont responsables du stockage et de la réplication des données publiées dans les rubriques Kafka, de la gestion des partitions au sein de ces rubriques, de la gestion des demandes des clients (production et consommation de messages) et de la coordination entre elles pour maintenir l’état général du déploiement de Kafka. Les agents sont les principaux composants qui permettent à l’architecture distribuée, évolutive et tolérante aux pannes de Kafka.

Pour les clusters alloués, vous pouvez choisir les instances EC2 T3.small ou celles des familles d’instances EC2 M7g et M5. Pour les clusters sans serveur, les agents sont complètement abstraits. MSK propose également des types d’agent Standard et express.

Non, chaque agent que vous approvisionnez comprend le stockage de volume de démarrage géré par le service Amazon MSK.

Certaines ressources, telles que les interfaces réseau Elastic (ENI), s’afficheront dans votre compte Amazon EC2. Les autres ressources Amazon MSK ne s’afficheront pas dans votre compte Amazon EC2, car elles sont gérées par le service Amazon MSK.

Pour les clusters alloués, vous devez allouer les instances d’agent pour chaque cluster que vous créez. Sur les agents Standard, vous allez allouer le stockage et activer éventuellement le débit de stockage alloué pour les volumes de stockage, qui peut être utilisé pour mettre les E/S à l’échelle sans avoir à allouer des agents supplémentaires. Avec les agents Express, vous n’avez pas besoin d’allouer ou de gérer le stockage. Pour tous les types de clusters, vous n’avez pas besoin d’allouer des nœuds de métadonnées tels que les nœuds Apache ZooKeeper ou KRaft, car ces ressources sont incluses gratuitement avec chaque cluster que vous créez. Pour les clusters sans serveur, vous créez uniquement un cluster en tant que ressource.

Amazon MSK utilise la réplication leader-suiveur d’Apache Kafka pour répliquer les données entre les agents. Amazon MSK facilite le déploiement de clusters grâce à la réplication multi-AZ. Avec les agents Standard, vous avez la possibilité d’utiliser une stratégie de réplication personnalisée par sujet. Les agents Express garantissent une disponibilité accrue en répliquant toujours vos données dans trois zones de disponibilité. Les agents leaders et suiveurs seront déployés et isolés en utilisant le type d’agent et la stratégie de réplication spécifiés. Par exemple, si vous sélectionnez des agents Standard avec une stratégie de réplication d’agent sur trois zones de disponibilité avec un agent par cluster de zone de disponibilité, Amazon MSK créera un cluster de trois agents (un agent sur trois zones de disponibilité dans une région) et par défaut (sauf si vous choisissez de remplacer le facteur de réplication de la rubrique), le facteur de réplication de la rubrique sera également de trois. Pour en savoir plus sur ce qui se passe lors d’un basculement client, consultez notre documentation relative au basculement client.

Oui, Amazon MSK vous permet de créer des configurations personnalisées et de les appliquer à des clusters existants ou nouveaux. Les agents Express protègent un plus grand nombre de configurations contre des valeurs sous-optimales susceptibles d’affecter la disponibilité et la durabilité. Les agents Express proposent également une expérience plus simple en faisant abstraction des configurations liées au stockage, étant donné qu’Amazon MSK gère entièrement la couche de stockage. Pour plus d’informations sur les configurations personnalisées, consultez la documentation de configuration.

Une fois votre cluster Apache Kafka créé, vous pouvez créer des rubriques à l'aide des API Apache Kafka. Toutes les actions et les configurations au niveau des rubriques et des partitions sont effectuées à l’aide des API Apache Kafka. La commande suivante est un exemple de création de rubrique à l'aide des API Apache Kafka et des détails de configuration disponibles pour votre cluster :

<path-to-your-kafka-installation>/bin/kafka-topics.sh --create — bootstrap-server <BootstrapBrokerString> --replication-factor 3 --partitions 1 -- topic TopicName

Amazon MSK propose deux options de déploiement pour les clusters Apache Kafka : Amazon MSK alloué et Amazon MSK sans serveur. MSK alloué vous offre différents niveaux de contrôle sur votre cluster tout en supprimant la plupart des frais opérationnels liés à la gestion des clusters Apache Kafka. Avec MSK alloué, vous pouvez mettre votre cluster à l’échelle en unités d’agents. Vous pouvez choisir parmi différents types d’agents, notamment les agents Standard et Express. En revanche, MSK sans serveur est un type de cluster qui fait totalement abstraction de la mise à l’échelle et de la gestion des clusters. Avec MSK Serverless, vous pouvez exécuter vos applications sans avoir à allouer, configurer ou optimiser des clusters, et vous payez pour le volume de données que vous diffusez et retenez. Amazon MSK propose également plusieurs options pour simplifier la connexion à vos clusters MSK. Ces options incluent Amazon MSK Connect, le réplicateur Amazon MSK et d’autres intégrations AWS natives. Consultez les sections suivantes pour plus de détails. 

MSK alloué est une option de déploiement de cluster MSK qui vous permet de configurer et de mettre vos clusters Apache Kafka à l’échelle manuellement. Cela vous permet de contrôler à différents niveaux l’infrastructure qui alimente votre environnement Apache Kafka.

Avec MSK alloué, vous pouvez choisir les types d’instance, les volumes de stockage selon le type d’agent Standard et le nombre de nœuds d’agent qui composent vos clusters Kafka. Vous pouvez également mettre votre cluster à l’échelle en ajoutant ou en supprimant des agents au fur et à mesure de l’évolution de vos besoins en matière de traitement des données. Cette flexibilité vous permet d’optimiser les clusters en fonction de vos exigences spécifiques en matière de charge de travail, qu’il s’agisse d’optimiser le débit, la capacité de rétention ou d’autres caractéristiques de performance.

Outre les options de configuration de l’infrastructure, MSK alloué offre une sécurité, une surveillance et des avantages opérationnels de niveau professionnel. Cela inclut des fonctionnalités telles que les mises à niveau de la version d’Apache Kafka, la sécurité intégrée via le cryptage et le contrôle d’accès, et l’intégration avec d’autres services AWS tels qu’Amazon CloudWatch pour la surveillance. MSK alloué propose deux principaux types d’agents : Standard et Express.

Les agents Standard vous offrent la plus grande flexibilité pour configurer vos clusters, tandis que les agents Express offrent plus d’élasticité, de débit, de résilience et de facilité d’utilisation pour exécuter des applications de streaming hautes performances. Consultez les sous-sections ci-dessous pour plus de détails sur chaque offre. Le tableau ci-dessous met également en évidence les principales comparaisons de fonctionnalités entre les agents Standard et Express.

Oui, Amazon MSK prend en charge les instances M7g basées sur AWS Graviton3 de taille .large à .16xlarge pour exécuter toutes les charges de travail Apache Kafka. Les instances Graviton offrent les mêmes avantages en termes de disponibilité et de durabilité que Amazon MSK, avec des coûts jusqu’à 24 % inférieurs à ceux des instances M5 correspondantes. Les instances Graviton offrent un débit par instance jusqu’à 29 % supérieur à celui des instances M5 d’Amazon MSK, ce qui permet aux clients d’exécuter des clusters MSK avec moins d’agents ou des instances de plus petite taille.

Les agents Standard pour MSK alloué offrent la plus grande flexibilité pour configurer les performances de votre cluster. Vous pouvez choisir parmi une large gamme de configurations de clusters pour atteindre les caractéristiques de disponibilité, de durabilité, de débit et de latence requises pour vos applications. Vous pouvez également allouer la capacité de stockage et l’augmenter selon les besoins. Amazon MSK gère la maintenance matérielle des agents Standard et des ressources de stockage associées, en réparant automatiquement les problèmes matériels qui peuvent survenir.

Les agents Express pour MSK alloué simplifient la gestion d’Apache Kafka, le rendent plus rentable à exécuter à grande échelle et plus souple grâce à la faible latence que vous attendez. Les agents proposent un stockage payant à l’utilisation qui se met à l’échelle automatiquement et ne nécessite aucun dimensionnement, aucune allocation ni aucune surveillance proactive. En fonction de la taille d’instance sélectionnée, chaque nœud d’agent peut fournir jusqu’à 3 fois plus de débit par agent, augmenter verticalement jusqu’à 20 fois plus vite et récupérer 90 % plus rapidement que les agents Apache Kafka standard. Les agents Express sont préconfigurés avec les pratiques exemplaires par défaut d’Amazon MSK et appliquent des quotas de débit aux clients afin de minimiser les conflits de ressources entre les clients et les opérations en arrière-plan de Kafka.

• Aucune gestion du stockage : les agents Express éliminent le besoin d’allouer ou de gérer des ressources de stockage. Vous bénéficiez d’un stockage élastique, pratiquement illimité, avec paiement à l’usage et entièrement géré. Pour les cas d’utilisation à haut débit, vous n’avez pas à vous soucier des interactions entre les instances de calcul et les volumes de stockage ni des goulots d’étranglement associés au débit. Ces fonctionnalités simplifient la gestion des clusters et éliminent les frais opérationnels liés à la gestion du stockage.
• Mise à l’échelle plus rapide : les agents Express vous permettent de faire mettre à l’échelle votre cluster et de déplacer les partitions plus rapidement que les agents Standard. Cette fonctionnalité est cruciale lorsque vous devez augmenter horizontalement votre cluster pour faire face aux pics de charge à venir ou le réduire horizontalement pour réduire les coûts. Consultez les sections sur l’extension de votre cluster, la suppression d’agents, la réattribution de partitions et la configuration du régulateur de vitesse de LinkedIn pour le rééquilibrage pour plus de détails sur la mise à l’échelle de votre cluster.
• Débit supérieur : les agents Express offrent jusqu’à trois fois plus de débit par agent que les agents Standard. Par exemple, vous pouvez écrire des données en toute sécurité à une vitesse maximale de 500 Mbit/s avec chaque agent Express de taille m7g.16xlarge, contre 153,8 Mbit/s sur l’agent Standard équivalent (les deux chiffres supposent une allocation de bande passante suffisante pour les opérations en arrière-plan, telles que la réplication et le rééquilibrage).
• Configuré pour une résilience élevée : les agents Express proposent automatiquement diverses pratiques exemplaires préconfigurées pour améliorer la résilience de votre cluster. Il s’agit notamment de garde-fous sur les configurations critiques d’Apache Kafka, de quotas de débit et de réserve de capacité pour les opérations en arrière-plan et les réparations imprévues. Ces fonctionnalités permettent d’exécuter des applications Apache Kafka à grande échelle de manière plus sûre et plus facile. Consultez les sections relatives aux configurations des agents Express et au quota d’agents Amazon MSK Express pour plus de détails.
• Aucune fenêtre de maintenance : il n’y a aucune fenêtre de maintenance pour les agents Express. Amazon MSK met automatiquement à jour le matériel de votre cluster de manière continue. Consultez la documentation relative aux agents Amazon MSK Express pour plus de détails.

Les agents Express fournissent plus de débit par agent, ce qui vous permet de créer des clusters avec moins d’agents pour la même charge de travail. En outre, une fois que votre cluster est opérationnel, vous pouvez surveiller l’utilisation de ses ressources et dimensionner correctement la capacité plus rapidement qu’avec les agents Standard. Vous pouvez donc allouer des ressources adaptées à la capacité dont vous avez besoin et bénéficier d’une mise à l’échelle plus rapide pour répondre à l’évolution de la demande.

Les clusters dotés d’agents Express fonctionnent avec les API et les outils Apache Kafka qui utilisent le client Apache Kafka standard.

Les agents Express sont préconfigurés avec les pratiques exemplaires par défaut d’Amazon MSK, qui optimisent la disponibilité et la durabilité. Vous pouvez personnaliser certaines de ces configurations pour optimiser davantage les performances de vos clusters. Pour en savoir plus sur les configurations d’agent Express, consultez le guide du développeur Amazon MSK.

Tout comme pour les agents Standard, Amazon MSK s’intègre à AWS Key Management Service (AWS KMS) afin d’offrir un chiffrement transparent côté serveur pour le stockage dans les agents Express. Lorsque vous créez un cluster MSK avec les agents Express, vous pouvez spécifier la clé AWS KMS que vous souhaitez qu’Amazon MSK utilise pour chiffrer vos données au repos. Si vous ne spécifiez pas de clé KMS, Amazon MSK crée une clé gérée par AWS pour vous et l’utilise en votre nom. Amazon MSK utilise également le protocole TLS pour chiffrer les données en transit pour les agents Express, comme il le fait pour les agents Standard.

La plupart des fonctionnalités et fonctionnalités de MSK alloué qui fonctionnent sur les agents Standard fonctionnent également avec des clusters qui utilisent des agents Express. Certaines différences incluent : la gestion du stockage, la disponibilité des types d’instance et les versions prises en charge. Le tableau comparant les agents Standard et Express sous MSK alloué met en évidence certaines similitudes et différences clés.

Oui, vous pouvez migrer les données de votre cluster Kafka vers un cluster composé d’agents Express à l’aide de MirrorMaker 2 ou du réplicateur Amazon MSK, qui copie à la fois les données et les métadonnées de votre cluster vers un nouveau cluster. Pour en savoir plus sur l’utilisation de MirrorMaker 2 et du réplicateur MSK, consultez le guide du développeur Amazon MSK.

Les agents Express améliorent vos performances tarifaires, offrent une plus grande résilience et réduisent les frais d’exploitation, ce qui en fait le choix idéal pour toutes les charges de travail Apache Kafka sur MSK alloué. Cependant, vous pouvez choisir les types d’agents Standard si vous souhaitez contrôler davantage les configurations et les paramètres de vos agents. Avec les agents Standard, vous pouvez personnaliser un ensemble plus large de configurations Kafka, notamment le facteur de réplication, la taille des fichiers journaux et les politiques d’élection des dirigeants, ce qui vous donne plus de flexibilité quant aux paramètres de votre cluster.

MSK Serverless est un type de cluster pour Amazon MSK qui vous permet d'exécuter facilement les clusters Apache Kafka sans avoir à gérer une capacité de calcul et de stockage. Avec MSK Serverless, vous pouvez exécuter vos applications sans avoir à allouer, configurer ou optimiser des clusters, et vous payez pour le volume de données que vous diffusez et retenez. 

MSK sans serveur gère complètement les partitions, y compris la surveillance et leur déplacement vers des charges égales dans un cluster.

MSK Serverless fournit jusqu'à 200 Mbit/s de capacité en écriture et 400 Mbit/s de capacité en lecture par cluster. De plus, pour garantir un débit disponible suffisant pour toutes les partitions dans un cluster, MSK Serverless alloue jusqu'à 5 Mbit/s de capacité instantanée en écriture et de 10 Mbit/s de capacité instantanée en lecture par partition. 

MSK sans serveur chiffre l’ensemble du trafic en transit et toutes les données au repos utilisant des clés gérées par le service, émises via AWS KMS. Les clients se connectent à MSK Serverless au moyen d'une connexion privée via AWS PrivateLink, sans exposer votre trafic sur l'Internet public. En outre, MSK sans serveur offre le contrôle d’accès AWS Identity and Access Management (IAM), que vous pouvez utiliser pour gérer l’authentification client et l’autorisation client pour les ressources Apache Kafka, comme les rubriques.

Quand vous créez un cluster MSK sans serveur, vous fournissez les sous-réseaux d’un ou de plusieurs Amazon Virtual Private Cloud (Amazon VPC), qui hébergent les clients du cluster. Les clients hébergés sur l’un de ces Amazon VPC peuvent se connecter au cluster MSK sans serveur en utilisant sa chaîne d’agent d’amorçage.

Pour obtenir des informations à jour sur la disponibilité régionale, veuillez consulter la page de la tarification d’Amazon MSK.

MSK sans serveur prend actuellement en charge l’IAM (Identity Access Management) pour l’authentification et l’autorisation des clients. Vos clients peuvent adopter un rôle IAM pour l’authentification et vous pouvez appliquer des contrôles d’accès à l’aide d’une politique IAM associée.

Vous pouvez utiliser n’importe quel outil compatible avec Apache Kafka pour le traitement des données dans vos rubriques de cluster MSK sans serveur. MSK sans serveur s’intègre avec le service géré Amazon pour Apache Flink pour le traitement des flux avec état et AWS Lambda pour le traitement des événements. De plus, vous pouvez utiliser les connecteurs cibles Apache Kafka Connect pour envoyer des données vers la destination de votre choix. 

Lorsque vous créez une partition, MSK sans serveur en crée deux répliques et les dispose dans des zones de disponibilité différentes. En outre, MSK sans serveur identifie automatiquement et restaure les ressources dorsales manquantes pour assurer une haute disponibilité.

Oui, vous pouvez utiliser des outils tiers ou open source tels que MirrorMaker2, pris en charge par Apache Kafka, pour répliquer les données de clusters dans un cluster MSK. Consultez ce laboratoire de migration Amazon MSK pour vous aider à planifier votre migration.

Oui, Amazon MSK prend en charge les mises à niveau de version Apache Kafka en place entièrement gérées pour les clusters alloués. Pour en savoir plus sur comment mettre à niveau votre version Apache Kafka et connaître les pratiques exemplaires en matière de haute disponibilité, veuillez consulter la documentation sur les mises à niveau de version.

Toutes les versions d’Apache Kafka sont prises en charge jusqu’à leur date de fin de support. Pour plus de détails sur la politique et les dates de fin de support, consultez notre documentation relative au support des versions.

Oui, Amazon MSK s'exécute toujours dans un Amazon VPC géré par le service Amazon MSK. Les ressources Amazon MSK seront disponibles pour votre propre Amazon VPC, sous-réseau et groupe de sécurité sélectionnés lors de la configuration du cluster. Les adresses IP de votre VPC sont attachées à vos ressources Amazon MSK via des ENI ; tout le trafic réseau reste au sein du réseau AWS et n’est pas accessible par Internet par défaut.

Les agents de votre cluster seront rendus accessibles aux clients de votre VPC via des ENI qui apparaîtront dans votre compte. Les groupes de sécurité sur les ENI dictent la source et le type de trafic d’entrée et de sortie autorisé sur vos agents.

Oui, Amazon MSK permet de se connecter en toute sécurité aux agents des clusters Amazon MSK qui exécutent Apache Kafka 2.6.0 ou des versions supérieures sur Internet. En permettant l’accès public, les clients autorisés externes à un Amazon VPC privé peuvent diffuser des données chiffrées vers et depuis des clusters Amazon MSK spécifiques. Vous pouvez activer l'accès public pour les clusters MSK après la création d'un cluster, et ce sans frais supplémentaires. Cependant, les coûts de transfert de données AWS standard pour l'entrée et la sortie des clusters s'appliquent. Pour en savoir plus sur l’activation de l’accès public, consultez la documentation relative à l’accès public.

Par défaut, le seul moyen de produire et d’utiliser des données à partir d’un cluster Amazon MSK est via une connexion privée entre vos clients de votre VPC et le cluster Amazon MSK. Cependant, si vous activez l’accès public pour votre cluster MSK et que vous vous connectez à votre cluster MSK à l’aide de la chaîne d’agents d’amorçage publique, la connexion n’est plus privée, bien qu’elle ait été authentifiée, autorisée et chiffrée. Nous vous recommandons de configurer les groupes de sécurité du cluster afin d'avoir des règles TCP sortants qui autorisent l'accès public depuis votre adresse IP de confiance, et de rendre ces règles aussi restrictives que possible si vous activez l'accès public.

Vous pouvez vous connecter à votre cluster MSK à partir de n’importe quel compte VPC ou AWS différent de l’Amazon VPC de votre cluster MSK en activant la connectivité privée multi-VPC pour les clusters MSK exécutant les versions 2.7.1 ou ultérieures d’Apache Kafka. Vous ne pouvez activer la connectivité privée qu’après la création du cluster pour l’un des schémas d’authentification pris en charge (authentification IAM, SASL/SCRAM et authentification mTLS). Vous devez configurer vos clients pour qu’ils se connectent en privé au cluster à l’aide des connexions VPC gérées par Amazon MSK qui utilisent la technologie PrivateLink pour activer la connectivité privée. Pour en savoir plus sur la configuration de la connectivité privée, consultez la documentation relative à l’accès au sein d’AWS.

Oui, Amazon MSK utilise le chiffrement côté serveur Amazon Elastic Block Store (Amazon EBS) et les clés AWS KMS pour chiffrer les volumes de stockage.

Oui, par défaut, le chiffrement en transit des nouveaux clusters est activé via TLS pour les communications entre agents. Pour les clusters alloués, vous pouvez désactiver l’utilisation du chiffrement en transit lors de la création d’un cluster.

Oui, par défaut, le chiffrement en transit est défini sur TLS uniquement pour les clusters créés depuis l’AWS CLI ou depuis la console de gestion AWS. Une configuration supplémentaire est requise pour que les clients puissent communiquer avec des clusters utilisant le chiffrement TLS. Pour les clusters approvisionnés, vous pouvez modifier le paramètre de chiffrement par défaut en sélectionnant les paramètres TLS/plaintext ou plaintext. En savoir plus sur le chiffrement Amazon MSK.

Oui, les clusters MSK prennent en charge le chiffrement TLS en transit entre les agents Kafka et les nœuds de métadonnées.

Pour les clusters sans serveur, vous pouvez utiliser le contrôle d’accès IAM pour l’authentification et l’autorisation. Pour les clusters alloués, les options suivantes s’offrent à vous :

• Contrôle d’accès IAM pour AuthN/AuthZ (recommandé)
• Authentification par certificat TLS pour AuthN et listes de contrôle d’accès pour AuthZ
• SASL/SCRAM pour AuthN et listes de contrôle d’accès pour AuthZ

Amazon MSK recommande d’utiliser le contrôle d’accès IAM. Il s'agit de l'option la plus facile à utiliser et la plus sûre, car elle propose par défaut l'accès au moindre privilège.

Si vous utilisez le contrôle d’accès IAM, Amazon MSK utilise les politiques que vous écrivez et son propre autorisateur pour autoriser les actions. Si vous utilisez l'authentification par certificat TLS ou SASL/SCRAM, Apache Kafka utilise des listes de contrôle d'accès (ACL) pour l'autorisation. Pour activer les listes ACL, vous devez activer l’authentification client à l’aide de certificats TLS ou SASL/SCRAM.

Si vous utilisez le contrôle d’accès IAM, Amazon MSK se chargera de l’authentification et de l’autorisation pour vous sans aucune configuration supplémentaire. Si vous utilisez l’authentification TLS, vous pouvez utiliser le Dname des certificats TLS des clients comme principal de la liste ACL pour autoriser les demandes des clients. Si vous utilisez l'authentification SASL/SCRAM, vous pouvez utiliser le nom d'utilisateur comme mandataire de la liste ACL pour autoriser les demandes des clients.

Vous pouvez contrôler les actions de l’API de service à l’aide d’IAM.

Oui, vous pouvez activer le contrôle d’accès IAM pour un cluster existant, depuis la console de gestion AWS ou à l’aide de l’API UpdateSecurity.

Non, le contrôle d’accès IAM n’est disponible que pour les clusters Amazon MSK.

Vous pouvez associer une politique de cluster à votre cluster Amazon MSK afin de fournir à vos clients Kafka multi-comptes les autorisations nécessaires pour configurer une connectivité privée à votre cluster Amazon MSK. Lorsque vous utilisez l'authentification du client IAM, vous pouvez également utiliser la politique de cluster pour définir de manière granulaire les autorisations du plan de données Kafka pour le client qui se connecte. Pour en savoir plus sur les politiques de cluster, consultez la documentation sur les politiques de cluster.

Vous pouvez contrôler les performances de vos clusters à l’aide de la console Amazon MSK, de la console Amazon CloudWatch, ou à l’aide de JMX et des métriques d’hôtes qui utilisent Open Monitoring with Prometheus, une solution de surveillance open source.

Le coût de la surveillance de votre cluster avec CloudWatch dépend du niveau de surveillance et de la taille de votre cluster Apache Kafka. CloudWatch facture par métrique et par mois et inclut une offre gratuite d’AWS. Pour plus d’informations, consultez la page de tarification Amazon CloudWatch. Pour plus de détails sur le nombre de métriques exposées pour chaque niveau de surveillance, veuillez consulter la documentation relative à la surveillance d’Amazon MSK.

Les outils qui sont conçus pour une lecture depuis des exportateurs Prometheus sont compatibles avec Open Monitoring, tels que Datadog, Lenses, New Relic, Sumo Logic ou un serveur Prometheus. Pour plus de détails sur Open Monitoring, veuillez consulter la documentation Amazon MSK Open Monitoring.

Vous pouvez utiliser n'importe quelle surveillance côté client prise en charge par la version d'Apache Kafka que vous utilisez. 

Oui, vous pouvez baliser des clusters Amazon MSK depuis l’AWS CLI ou la console de gestion AWS.

Les métriques du délai de consommation au niveau de la rubrique sont incluses dans le jeu de métriques par défaut qu’Amazon MSK publie sur Amazon CloudWatch pour tous les clusters. Aucune configuration supplémentaire n'est nécessaire pour obtenir ces métriques.

Les métriques de niveau de rubrique sont incluses dans le jeu par défaut des métriques gratuites Amazon MSK. Les métriques de niveau de partition sont facturées selon la tarification Amazon CloudWatch.

Vous pouvez activer la diffusion de journaux d'agent pour les clusters approvisionnés. Vous pouvez livrer des journaux d’agent à Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3) et Amazon Data Firehose. Firehose prend en charge le service Amazon OpenSearch Service entre autres destinations. Pour savoir comment activer cette fonctionnalité, consultez la documentation sur les journaux Amazon MSK. Pour en savoir plus sur les tarifs, consultez les pages relatives à la tarification d’Amazon CloudWatch Logs et d’Amazon Data Firehose.

Amazon MSK fournit des journaux de niveau INFO à tous les agents au sein d’un cluster alloué.

Oui, si vous utilisez le contrôle d’accès IAM, l’utilisation des API de ressources Apache Kafka est journalisée dans AWS CloudTrail.

De https://zookeeper.apache.org : « Apache ZooKeeper est un service centralisé qui vous permet de maintenir des informations de configuration, des noms, de fournir une synchronisation distribuée et des services de groupe. Tous ces types de services sont utilisés sous une forme ou une autre par des applications distribuées », y compris Apache Kafka.

Oui, Amazon MSK utilise Apache ZooKeeper pour la gestion des métadonnées. En outre, à partir de la version 3.7 d’Apache Kafka, vous pouvez créer des clusters en mode ZooKeeper ou en mode KRaft. Un cluster créé avec le mode KRaft utilise des contrôleurs KRaft pour la gestion des métadonnées au lieu des nœuds ZooKeeper.

Apache KRaft est le protocole de consensus qui déplace la gestion des métadonnées dans les clusters Kafka des nœuds externes Apache ZooKeeper vers un groupe de contrôleurs au sein de Kafka. Cette modification permet aux métadonnées d’être stockées et répliquées en tant que sujets dans les courtiers Kafka, ce qui accélère la propagation des métadonnées. Pour en savoir plus, consultez notre documentation Apache KRaft.

Aucune modification de l’API n’est requise pour utiliser le mode KRaft sur Amazon MSK. Cependant, si vos clients utilisent encore la chaîne de connexion --zookeeper, vous devez mettre à jour vos clients pour qu’ils utilisent la chaîne de connexion --bootstrap-server afin de se connecter à votre cluster et d’effectuer des actions d’administration. L’indicateur --zookeeper est obsolète dans la version 2.5 d’Apache Kafka et est supprimé à partir de Kafka 3.0. Nous vous recommandons donc d’utiliser les versions récentes du client Apache Kafka et la chaîne de connexion --bootstrap-server.

Vous devez vérifier que tous les outils que vous utilisez sont capables d’utiliser les API d’administration de Kafka sans connexion à ZooKeeper. Consultez notre documentation mise à jour sur l’utilisation de Cruise Control pour les clusters en mode KRaft. Cruise Control a également publié les étapes à suivre pour exécuter Kafka sans connexion ZooKeeper.

Le nombre de partitions par agent est le même sur les clusters basés sur KRaft et ZooKeeper. Toutefois, KRAFT vous permet d’héberger davantage de partitions par cluster en provisionnant davantage de courtiers dans un cluster.

Amazon MSK s’intègre aux services AWS suivants :

• Amazon S3 en utilisant Firehose pour transmettre des données à Amazon S3 depuis Amazon MSK sans code
• Amazon VPC pour l’isolement et la sécurité du réseau
• Amazon CloudWatch pour les métriques
• AWS KMS pour le chiffrement de volume de stockage
• IAM pour l’authentification et l’autorisation d’Apache Kafka et des API de service
• AWS Lambda pour le sourcing d’événements MSK
• AWS IoT Core pour le sourcing d’événements IoT
• AWS Glue Schema Registry pour contrôler l’évolution des schémas utilisés par les applications Apache Kafka
• AWS CloudTrail pour les journaux d’API AWS
• AWS Certificate Manager pour les autorités de certification privées pour l’authentification TLS des clients
• AWS CloudFormation pour la description et l’allocation des clusters Amazon MSK à l’aide de code
• Le service géré Amazon pour Apache Flink pour les applications Apache Flink entièrement gérées qui traitent des données de streaming
• Le service géré Amazon pour Apache Flink Studio pour le streaming SQL interactif sur Apache Kafka
• AWS Secrets Manager pour les informations d’identification des clients utilisées pour l’authentification SASL/SCRAM

Amazon MSK sans serveur s’intègre aux services AWS suivants :

• Amazon S3 en utilisant Firehose pour transmettre des données à Amazon S3 depuis MSK sans code
• Amazon VPC pour l’isolement et la sécurité du réseau
• Amazon CloudWatch pour les métriques
• IAM pour l’authentification et l’autorisation d’Apache Kafka et des API de service
• AWS Glue Schema Registry pour contrôler l’évolution des schémas utilisés par les applications Apache Kafka
• AWS CloudTrail pour les journaux d’API AWS
• AWS PrivateLink pour la connectivité privée

Le réplicateur Amazon MSK est une fonctionnalité d’Amazon MSK qui permet aux clients de répliquer des données de manière fiable sur des clusters Amazon MSK situés dans différentes Régions AWS (réplication entre régions) ou au sein de la même Région AWS (réplication dans la même région), sans avoir à écrire de code ni de gérer d’infrastructure. Vous pouvez utiliser la réplication entre régions pour créer des applications de streaming multirégionales hautement disponibles et tolérantes aux pannes pour une résilience accrue. Vous pouvez également utiliser la réplication entre régions pour fournir un accès à latence plus faible aux consommateurs dans diverses régions géographiques. Vous pouvez utiliser la réplication au sein d’une même région pour distribuer des données d’un cluster à plusieurs clusters afin de partager des données avec vos partenaires et vos équipes. Vous pouvez également utiliser la réplication au sein d’une même région pour agréger les données de plusieurs clusters en un seul à des fins d’analytique.

Pour configurer la réplication entre une paire de clusters MSK source et cible, vous devez créer un réplicateur dans la région de destination. Pour créer un réplicateur, vous devez spécifier des informations telles que l’Amazon Resource Name (ARN) des clusters MSK source et cible et un rôle IAM que le réplicateur MSK peut utiliser pour accéder aux clusters. Vous devez créer le cluster MSK cible s’il n’existe pas.

MSK Replicator prend en charge la réplication sur des clusters MSK uniquement. Les clusters MSK de types alloué et sans serveur sont pris en charge. Vous pouvez également utiliser le réplicateur MSK pour passer d’alloué à sans serveur ou inversement avec d’autres clusters Kafka qui ne sont pas pris en charge.

Oui, vous pouvez spécifier les sujets que vous souhaitez répliquer à l'aide des listes d'autorisation et de refus lors de la création du réplicateur. 

Le réplicateur MSK réplique automatiquement les métadonnées Kafka requises, telles que la configuration de rubriques, les listes de contrôle d’accès (ACL) et les décalages de groupes de consommateurs, afin que les applications consommatrices puissent reprendre le traitement de manière fluide après le basculement. Vous pouvez désactiver un ou plusieurs de ces paramètres si vous souhaitez uniquement répliquer les données. Vous pouvez également spécifier les groupes de consommateurs que vous souhaitez répliquer à l'aide de listes d'autorisation ou de refus lors de la création du réplicateur.

Non, le réplicateur MSK déploie, alloue et met à l’échelle automatiquement l’infrastructure de réplication sous-jacente pour prendre en charge les modifications de votre débit d’entrée.

Non, MSK Replicator prend uniquement en charge la réplication entre les clusters MSK d'un même compte AWS.

Vous pouvez utiliser Amazon CloudWatch dans la région de destination pour consulter les métriques relatives à ReplicationLatency,
MessageLag et ReplicatorThroughput au niveau de la rubrique et de l’agrégation pour chaque réplicateur, sans frais supplémentaires. Les métriques sont visibles sous ReplicatorName dans l’espace de noms AWS/Kafka. Vous pouvez également consulter les métriques ReplicatorFailure, AuthError et ThrottleTime pour vérifier si votre réplicateur rencontre des problèmes.

Vous pouvez utiliser réplicateur MSK pour configurer des topologies de clusters actif-actif ou actif-passif afin d’accroître la résilience de votre application Kafka dans toutes les régions. Dans une configuration actif-actif, les deux clusters MSK effectuent activement des opérations de lecture et d'écriture. En revanche, dans une configuration actif-passif, un seul cluster MSK diffuse activement des données, tandis que l’autre cluster est en veille.

Oui. En créant un réplicateur différent pour chaque paire de clusters source et cible, vous pouvez répliquer les données d’un cluster vers plusieurs clusters ou répliquer les données de plusieurs clusters vers un seul.

Le réplicateur MSK utilise le contrôle d’accès IAM pour se connecter à vos clusters source et cible. Vous devez activer vos clusters MSK source et cible pour le contrôle d’accès IAM afin de créer un réplicateur. Vous pouvez continuer à utiliser d'autres méthodes d'authentification en même temps pour vos clients, notamment SASL/SCRAM et mTLS, car Amazon MSK prend en charge plusieurs méthodes d'authentification simultanément.

Le réplicateur MSK réplique les données de manière asynchrone. La latence de réplication varie en fonction de nombreux facteurs, notamment la distance réseau entre les régions de vos clusters MSK, la capacité de débit de vos clusters source et cible et le nombre de partitions sur vos clusters source et cible.

Non, MSK Replicator crée de nouvelles rubriques dans le cluster cible avec un préfixe généré automatiquement et ajouté au nom de la rubrique. Par exemple, le réplicateur MSK répliquera les données de la rubrique du cluster source vers une nouvelle rubrique du cluster cible appelée <sourceKafkaClusterAlias>.topic. Le réplicateur MSK fait cela pour distinguer les rubriques contenant des données répliquées à partir du cluster source des autres rubriques du cluster cible et éviter que les données ne soient répliquées de manière circulaire entre les clusters. Vous pouvez trouver le préfixe qui sera ajouté aux noms de rubrique dans le cluster cible dans le champ sourceKafkaClusterAlias à l’aide de l’API DescribeReplicator ou de la page de détails du réplicateur sur la console Amazon MSK.

Oui. Par défaut, lorsque vous créez un nouveau réplicateur, il commence à répliquer les données à partir de l’extrémité du flux (dernière position) sur le cluster source. Sinon, si vous souhaitez répliquer des données existantes, vous pouvez configurer un nouveau réplicateur pour commencer à répliquer les données à partir du décalage le plus ancien dans les partitions thématiques du cluster source.

MSK Replicator agissant en tant que consommateur pour votre cluster source, il est possible que la réplication entraîne une limitation des autres consommateurs sur votre cluster source. Cela dépend de la capacité de lecture dont vous disposez sur votre cluster source et du débit des données que vous répliquez. Nous vous recommandons de fournir une capacité identique pour vos clusters source et cible et de prendre en compte le débit de réplication lors du calcul de la capacité dont vous avez besoin. Vous pouvez également définir des quotas Kafka pour le réplicateur sur vos clusters source et cible afin de contrôler la capacité que le réplicateur peut utiliser.

Oui, vous pouvez spécifier votre choix de codec de compression lors de la création du réplicateur parmi Aucun, GZIP, Snappy, LZ4 et ZSTD.

Oui, vous pouvez spécifier votre choix de codec de compression lors de la création du réplicateur parmi Aucun, GZIP, Snappy, LZ4 et ZSTD.

Vous pouvez augmenter verticalement le stockage de vos clusters alloués s’exécutant sur des agents Standard via la console de gestion AWS ou l’AWS CLI. Vous pouvez créer une stratégie d’autoscaling pour le stockage en utilisant la console de gestion AWS ou en créant une stratégie AWS Application Auto Scaling à l’aide de l’AWS CLI ou des API. Le stockage à plusieurs niveaux sur les agents Standard vous permet de stocker virtuellement un nombre illimité de données sur votre cluster sans avoir à ajouter des agents pour le stockage. Avec les agents Express, vous n’avez pas besoin d’allouer ou de gérer le stockage, et vous avez également accès à un stockage pratiquement illimité. Dans les clusters sans serveur, le stockage est mis à l'échelle rapidement en fonction de votre utilisation.

Apache Kafka stocke les données dans des fichiers appelés segments de journal. Lorsque chaque segment est complet, en fonction de la taille configurée au niveau du cluster ou du sujet, il est copié sur le niveau de stockage à faible coût. Les données sont conservées dans un stockage optimisé pour les performances pendant une durée ou une taille de rétention déterminée, puis elles sont supprimées. Il existe un paramètre distinct de limite de temps et de taille pour le stockage à faible coût, qui est plus long que le niveau de stockage principal. Si les clients demandent des données à partir de segments stockés dans le niveau à faible coût, l’agent lira les données et les servira de la même manière que si elles étaient fournies à partir du stockage principal.

Oui, vous pouvez augmenter ou réduire le nombre d’agents pour les clusters MSK alloués.

Oui, vous pouvez procéder à une mise à l’échelle vers un type d’agent plus petit ou plus grand sur vos clusters MSK alloués.

Vous pouvez utiliser Cruise Control pour rééquilibrer automatiquement les partitions afin de gérer l'activité I/O. Pour plus d’informations, veuillez consulter la documentation Cruise Control. Vous pouvez également utiliser l'API Kafka Admin kafka-reassign-partitions.sh pour réaffecter les partitions entre les agents. Dans les clusters sans serveur, Amazon MSK équilibre automatiquement les partitions.

La tarification dépend des ressources que vous créez. Pour en savoir plus, consultez la page de tarification Amazon MSK.

Non, tous les transferts de données au sein d’un cluster sont inclus avec le service, sans frais supplémentaires.

Pour plus d’informations sur les régions dans lesquelles Amazon MSK est disponible, consultez le tableau des Régions AWS. 

Avec les clusters alloués, vous devrez payer les frais de transfert de données AWS standard pour les données transférées vers et depuis un cluster MSK. Vous ne serez pas facturé pour le transfert de données dans le cluster au sein d’une région, y compris le transfert de données entre agents et le transfert de données entre agents et nœuds de métadonnées.

Avec les clusters sans serveur, les frais de transfert de données standard d’AWS vous seront facturés à hauteur des données transférées vers ou depuis une région et pour les données transférées vers l’Internet public.

Non, pas à l’heure actuelle.

Amazon MSK est conforme ou éligible pour les programmes suivants :

• Éligible HIPAA

• PCI

• ISO 

• SOC 1, 2 et 3

Pour obtenir une liste complète des services AWS et des programmes de conformité, consultez la rubrique Services AWS concernés par le programme de conformité.

Notre contrat de niveau de service Amazon MSK garantit un pourcentage de temps de fonctionnement mensuel d'au moins 99,9 % pour Amazon MSK (non applicable pour MSK sans serveur). 

Si les déploiements multi-AZ sur Amazon MSK ont un pourcentage de durée de fonctionnement mensuel inférieur à 99,9 % au cours d’un cycle de facturation mensuel, vous pouvez bénéficier d’un crédit de contrat de niveau de service pour Amazon MSK dans le cadre du contrat de niveau de service Amazon MSK.

Pour consulter l’intégralité des conditions générales du contrat de niveau de service et en savoir plus sur la marche à suivre pour envoyer une demande, veuillez consulter la page détaillée du contrat de niveau de service Amazon MSK.