Bienvenue dans le Manuel du développeur Amazon MSK - Amazon Managed Streaming for Apache Kafka

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bienvenue dans le Manuel du développeur Amazon MSK

Bienvenue dans le Manuel du développeur Amazon MSK. Les rubriques suivantes peuvent vous aider à démarrer avec ce guide, en fonction de ce que vous essayez de faire.

Pour connaître les détails et les points forts du produit, ainsi que son coût, consultez la page consacrée à Amazon MSK.

Qu'est-ce qu'Amazon MSK ?

Amazon Managed Streaming for Apache Kafka (Amazon MSK) est un service entièrement géré qui vous permet de créer et d'exécuter des applications utilisant Apache Kafka pour traiter des données de diffusion. Amazon MSK fournit les opérations de plan de contrôle, telles que les opérations de création, de mise à jour et de suppression de clusters. Il vous permet d'utiliser les opérations de plan de données Apache Kafka, telles que celles pour la production et la consommation de données. Il exécute des versions open source d'Apache Kafka. Cela signifie que les applications, outils et plug-ins existants des partenaires et de la communauté Apache Kafka sont pris en charge sans nécessiter de modification du code d'application. Vous pouvez utiliser Amazon MSK pour créer des clusters utilisant n'importe quelle version Apache Kafka répertoriées sous Versions Apache Kafka prises en charge.

Ces composants décrivent l'architecture d'Amazon MSK :

  • Nœuds d'agent : lors de la création d'un cluster Amazon MSK, vous spécifiez le nombre de nœuds d'agent qu'Amazon MSK doit créer dans chaque zone de disponibilité. Le minimum est d'un courtier par zone de disponibilité. Chaque zone de disponibilité dispose de son propre sous-réseau VPC (Virtual Private Cloud).

  • ZooKeeper nœuds — Amazon MSK crée également les ZooKeeper nœuds Apache pour vous. Apache ZooKeeper est un serveur open source qui permet une coordination distribuée très fiable.

  • Contrôleurs KraFT — La communauté Apache Kafka a développé KraFT pour remplacer Apache ZooKeeper pour la gestion des métadonnées dans les clusters Apache Kafka. En mode KraFT, les métadonnées du cluster sont propagées au sein d'un groupe de contrôleurs Kafka, qui font partie du cluster Kafka, plutôt qu'entre les nœuds. ZooKeeper Les contrôleurs Kraft sont inclus sans frais supplémentaires pour vous et ne nécessitent aucune configuration ou gestion supplémentaire de votre part.

    Note

    À partir de la version 3.7.x d'Apache Kafka sur MSK, vous pouvez créer des clusters utilisant le mode KraFT au lieu du mode. ZooKeeper

  • Producteurs, consommateurs et créateurs de rubriques : Amazon MSK vous permet d'utiliser les opérations de plan de données Apache Kafka pour créer des rubriques ainsi que pour produire et consommer des données.

  • Opérations de cluster Vous pouvez utiliser le AWS Management Console, le AWS Command Line Interface (AWS CLI) ou les API du SDK pour effectuer des opérations sur le plan de contrôle. Par exemple, vous pouvez créer ou supprimer un cluster Amazon MSK, répertorier tous les clusters d'un compte, consulter les propriétés d'un cluster et mettre à jour le nombre et le type d'agents dans un cluster.

Amazon MSK détecte et récupère automatiquement les scénarios de défaillance les plus courants pour les clusters. Ainsi, vos applications de producteurs et de consommateurs peuvent poursuivre leurs opérations d'écriture et de lecture avec un impact minimal. Lorsque Amazon MSK détecte une défaillance de l'agent, il l'atténue ou remplace l'agent malsain ou inaccessible par un nouveau. En outre, dans la mesure du possible, il réutilise le stockage de l'ancien agent pour réduire les données qu'Apache Kafka a besoin de répliquer. Votre impact sur la disponibilité est limité au temps nécessaire pour que Amazon MSK termine la détection et la récupération. Après une récupération, vos applications de producteurs et de consommateurs peuvent continuer à communiquer avec les mêmes adresses IP d'agent que celles utilisées avant l'échec.