Cette rubrique décrit les éditions d'instance disponibles pour Message Queue for Apache Kafka. Ces informations vous aideront à choisir l'édition la mieux adaptée à vos besoins métier.
Types d'instance
single-zone : votre service et vos données sont déployés dans une seule zone de disponibilité. En cas de panne au niveau de la zone, votre service devient indisponible et vous risquez de perdre des données. Si vous optez pour une instance single-zone, nous vous recommandons de créer une instance dans une autre région et d'utiliser un connecteur pour sauvegarder les messages. Pour plus d'informations, consultez la rubrique Bonnes pratiques pour la reprise après sinistre en zone unique.
multi-zone : votre service et vos données sont répartis sur plusieurs zones de disponibilité. Cette architecture protège contre les interruptions de service et la perte de données en cas de défaillance d'une zone de disponibilité. Nous recommandons le déploiement multi-zone pour les services critiques.
Le tableau suivant présente les éditions d'instance pour Message Queue for Apache Kafka.
Élément | Standard edition (High-write) | Professional edition (High-write) | Professional edition (High-read) | Serverless basic edition | Serverless standard edition | Serverless professional edition |
Coût de stockage | Capacité réservée. Les coûts sont comparables à ceux d'un cluster auto-géré. Par exemple, si vous achetez un disque de 300 Go, 100 Go sont disponibles pour vos données métier et les 200 Go restants sont réservés aux réplicas. | Capacité réservée, permettant d'économiser jusqu'à 66 % par rapport à un cluster auto-géré. Par exemple, si vous achetez un disque de 300 Go, la totalité des 300 Go est disponible pour vos données métier. Un espace de stockage supplémentaire de 600 Go pour les réplicas est inclus gratuitement. | Modèle de paiement à l'utilisation. Vous êtes facturé en fonction de l'espace de stockage réellement utilisé et de la durée de conservation. Cela permet d'économiser plus de 70 % sur les coûts de stockage par rapport à l'utilisation de disques cloud pour un cluster auto-géré. | |||
Coût de calcul | Capacité réservée | Capacité réservée | Modèle de paiement à l'utilisation | |||
Interruption de service | Mise à l'échelle rapide pour gérer les pics de trafic soudains sans long rééquilibrage des données. | |||||
Architecture élastique | Après une mise à l'échelle horizontale, les nouvelles opérations de lecture et d'écriture sont prises en charge en quelques secondes. | L'architecture découplée entre le stockage et le calcul permet aux lectures, écritures et migrations de partitions de s'effectuer en quelques secondes. | ||||
Mise à l'échelle verticale transparente | Non pris en charge | Non pris en charge | Non pris en charge | Nécessite une mise à l'échelle manuelle. |
|
|
Ratio de trafic lecture/écriture maximal | 1:1 | 1:1 | 3:1 | 3:1 | ||
Architecture de déploiement | Instance partagée (isolation logique) | Instance dédiée (cluster physique exclusif) | Instance partagée (isolation logique) | Instance dédiée (cluster physique exclusif) | ||
TTL du topic | Non pris en charge | Pris en charge pour le stockage local | Entièrement pris en charge | |||
Durée de conservation des messages | Jusqu'à 7 jours | Personnalisable selon votre cas d'utilisation. | Prend en charge une conservation illimitée, avec une limite par défaut d'un an. Pour demander une période de conservation plus longue, soumettez un ticket. | |||
Reprise après sinistre | Les nœuds de calcul et de stockage sont déployés dans une seule zone de disponibilité. | Prend en charge le déploiement multi-zone. Si vous sélectionnez un déploiement en zone unique, les nœuds de calcul et de stockage sont déployés dans une seule zone de disponibilité. | Les nœuds de calcul et de stockage sont déployés dans une seule zone de disponibilité. | Déploiement multi-zone sur trois zones de disponibilité (3AZ). | ||
Optimisation des performances | Non pris en charge | Personnalisable selon votre cas d'utilisation. | Personnalisable selon votre cas d'utilisation. | |||
ACL | Non pris en charge | Pris en charge | Pris en charge | |||
Chiffrement SSL pour la transmission des messages dans les VPC | Non pris en charge | Pris en charge | Pris en charge | |||
Déploiement inter-zones | Non pris en charge | Pris en charge | Non pris en charge | Pris en charge | ||
Compatibilité des versions client | Compatible avec les clients Apache Kafka versions 0.11 à 3.x. | Compatible avec les clients Apache Kafka versions 0.11 à 3.x. | Compatible avec les clients Apache Kafka versions 0.11 à 3.x. | |||
Accord de niveau de service (SLA) | 99,95 % | Offre un SLA de 99,99 % pour les déploiements multi-zones et de 99,95 % pour les déploiements en zone unique. | Offre un SLA de 99,9 %, inférieur à celui des éditions Standard et Professional. Cette édition utilise une plus grande proportion de ressources à faible coût, telles que les disques durs, OSS et les instances spot. Recommandée pour les tests ou les charges de travail au trafic stable. Pour les charges de travail critiques nécessitant une haute stabilité, nous recommandons les éditions Serverless Standard ou Professional. | Offre un SLA de 99,95 %. Recommandée pour les environnements de production. | Offre un SLA de 99,99 % avec reprise après sinistre sur trois zones de disponibilité. Offre une élasticité accrue pour les instances ayant un débit réservé plus faible. Il s'agit de l'édition entreprise recommandée. | |
Chiffrement des disques cloud | Pris en charge | Pris en charge | Non pris en charge | |||
Spécifications de trafic et limitation
La spécification de trafic d'une instance Message Queue for Apache Kafka définit le débit maximal pour la production (écriture) et la consommation (lecture) de messages. Comprendre le calcul des limites de trafic et le déclenchement de la limitation vous aidera à diagnostiquer les problèmes de performance.
Répartition du trafic par nœud — La limite de spécification de trafic est répartie uniformément entre les nœuds broker d'une instance. Par exemple, dans une instance à 3 nœuds, la limite de trafic pour chaque nœud correspond approximativement au tiers de la spécification totale. Si le trafic réel d'un seul nœud dépasse sa limite individuelle, la limitation est déclenchée pour ce nœud, même si le trafic global de l'instance n'a pas atteint la limite de spécification.
Déséquilibre du trafic et limitation — Par défaut, Apache Kafka réplique les messages sur 3 réplicas. Si la production de messages est inégale — par exemple, en raison d'envois par lots planifiés ou d'une distribution inégale des clés de partition — le trafic se concentre sur des nœuds ou des partitions spécifiques. Cela provoque une surcharge locale et déclenche la limitation, même lorsque le trafic moyen au niveau de l'instance semble rester dans les limites de la spécification.
Afficher les spécifications de trafic — Dans la console, accédez à la liste des instances et cliquez sur le nom de l'instance. Sous l'onglet Instance Information, la section Basic Information affiche la Traffic Specification de votre instance, y compris les valeurs Maximum Read Traffic et Maximum Write Traffic en Mo/s.
Définition du trafic de pointe et estimation du nombre de partitions — La valeur de trafic de pointe indiquée dans le tableau des spécifications (par exemple, 20 Mo/s) fait référence au trafic de lecture/écriture de pointe côté métier. Il s'agit du débit de pointe auquel votre application produit (écrit) ou consomme (lit) des messages, et non de la limite physique de la carte réseau (NIC). Le trafic réel de lecture/écriture de la carte réseau qu'une instance peut prendre en charge est environ 3 fois supérieur à la valeur de spécification, car la capacité supplémentaire est réservée pour couvrir les frais généraux internes tels que la réplication des données pour les réplicas.
Lorsque vous estimez le nombre de partitions requises pour votre topic, basez le calcul uniquement sur votre trafic de pointe de production ou de consommation côté métier. Vous n'avez pas besoin de doubler le nombre de partitions pour tenir compte d'un ratio lecture/écriture de 1:1, car la valeur de spécification et le trafic sous-jacent de la carte réseau prennent déjà en compte les frais généraux de réplication.
Surveiller l'utilisation du trafic — Pour identifier la limitation sur un seul nœud ou un déséquilibre du trafic, accédez à Prometheus Monitoring dans le volet de navigation de gauche de la page des détails de l'instance. Consultez les métriques Node consumption traffic et Cluster consumption traffic pour comparer le trafic réel par nœud à la limite par nœud (spécification totale ÷ nombre de nœuds).
Partitions d'instance
Le nombre de partitions varie selon l'édition d'instance, comme décrit dans les tableaux suivants.
Instances Serverless
Édition | Réplicas de partition | Réplicas de partition maximum |
Basic Edition |
|
Pour demander une limite supérieure, soumettez un ticket. |
Standard Edition | ||
Professional Edition |
Instances par abonnement et paiement à l'utilisation
Standard edition (High-write)
|
Spécification de trafic |
Partitions incluses |
Partitions maximum |
|
alikafka.hw.2xlarge |
1 000 |
4 000 |
|
alikafka.hw.3xlarge |
1 000 |
4 200 |
|
alikafka.hw.6xlarge |
1 000 |
4 400 |
|
alikafka.hw.9xlarge |
1 000 |
4 600 |
|
alikafka.hw.12xlarge |
1 000 |
4 800 |
Professional edition (High-write)
|
Spécification de trafic |
Partitions incluses |
Partitions maximum |
|
alikafka.hw.2xlarge |
1 000 |
4 000 |
|
alikafka.hw.3xlarge |
1 000 |
4 200 |
|
alikafka.hw.6xlarge |
1 000 |
4 400 |
|
alikafka.hw.9xlarge |
1 000 |
4 600 |
|
alikafka.hw.12xlarge |
1 000 |
4 800 |
|
alikafka.hw.16xlarge |
2 000 |
5 000 |
|
alikafka.hw.20xlarge |
2 000 |
6 000 |
|
alikafka.hw.25xlarge |
2 000 |
7 000 |
|
alikafka.hw.30xlarge |
2 000 |
8 000 |
|
alikafka.hw.60xlarge |
2 000 |
9 000 |
|
alikafka.hw.80xlarge |
2 000 |
10 000 |
|
alikafka.hw.100xlarge |
3 000 |
12 000 |
|
alikafka.hw.120xlarge |
3 000 |
14 000 |
|
alikafka.hw.150xlarge |
3 000 |
16 000 |
|
alikafka.hw.180xlarge |
3 000 |
18 000 |
|
alikafka.hw.200xlarge |
3 000 |
20 000 |
|
alikafka.hw2.220xlarge |
4 000 |
24 000 |
|
alikafka.hw2.300xlarge |
4 000 |
26 000 |
|
alikafka.hw2.400xlarge |
4 000 |
28 000 |
|
alikafka.hw2.500xlarge |
4 000 |
30 000 |
|
alikafka.hw2.600xlarge |
5 000 |
32 000 |
|
alikafka.hw2.700xlarge |
5 000 |
34 000 |
|
alikafka.hw2.800xlarge |
5 000 |
36 000 |
|
alikafka.hw2.900xlarge |
5 000 |
38 000 |
|
alikafka.hw2.1000xlarge |
5 000 |
40 000 |
Professional edition (High-read)
|
Spécification de trafic |
Partitions incluses |
Partitions maximum |
|
alikafka.hr.2xlarge |
1 000 |
4 000 |
|
alikafka.hr.3xlarge |
1 000 |
4 200 |
|
alikafka.hr.6xlarge |
1 000 |
4 400 |
|
alikafka.hr.9xlarge |
1 000 |
4 600 |
|
alikafka.hr.12xlarge |
1 000 |
4 800 |
|
alikafka.hr.16xlarge |
2 000 |
5 000 |
|
alikafka.hr.20xlarge |
2 000 |
6 000 |
|
alikafka.hr.25xlarge |
2 000 |
7 000 |
|
alikafka.hr.30xlarge |
2 000 |
8 000 |
|
alikafka.hr.60xlarge |
2 000 |
9 000 |
|
alikafka.hr.80xlarge |
2 000 |
10 000 |
|
alikafka.hr.100xlarge |
3 000 |
12 000 |
|
alikafka.hr.120xlarge |
3 000 |
14 000 |
|
alikafka.hr.150xlarge |
3 000 |
16 000 |
|
alikafka.hr.180xlarge |
3 000 |
18 000 |
|
alikafka.hr.200xlarge |
3 000 |
20 000 |
|
alikafka.hr2.220xlarge |
4 000 |
24 000 |
|
alikafka.hr2.300xlarge |
4 000 |
26 000 |
|
alikafka.hr2.400xlarge |
4 000 |
28 000 |
|
alikafka.hr2.500xlarge |
4 000 |
30 000 |
|
alikafka.hr2.600xlarge |
5 000 |
32 000 |
|
alikafka.hr2.700xlarge |
5 000 |
34 000 |
|
alikafka.hr2.800xlarge |
5 000 |
36 000 |
|
alikafka.hr2.900xlarge |
5 000 |
38 000 |
|
alikafka.hr2.1000xlarge |
5 000 |
40 000 |
FAQ
Quelles sont les exigences en matière d'édition d'instance pour intégrer Kafka au moteur de règles MQTT ?
Il n'y a aucune exigence obligatoire concernant l'édition pour utiliser Message Queue for Apache Kafka avec le moteur de règles MQTT. Toute édition — Standard, Professional ou Serverless — prend en charge l'intégration de base.
Cependant, si votre environnement de production nécessite une authentification SASL ou un contrôle d'accès basé sur les ACL, vous devez utiliser l'édition Professional ou l'édition Serverless. L'édition Standard ne prend pas en charge les endpoints SASL ni les ACL.
Quelle est la limite maximale de capacité de disque pour l'édition Professional (High-write) ?
La capacité du disque est provisionnée au niveau du cluster et est répartie uniformément sur tous les nœuds broker du cluster. L'édition Professional (High-write) n'impose pas de limite explicite de capacité de disque maximale. Toutefois, chaque spécification de trafic impose une exigence minimale de capacité de disque ; la capacité de disque que vous pouvez sélectionner varie donc en fonction de la spécification de trafic choisie.
Lors de la création d'une instance, sélectionnez une taille de disque adaptée à vos besoins métier. Une fois que vous avez choisi un type de disque — ultra disk ou SSD — pour une instance, vous ne pourrez plus modifier ce type ultérieurement.
Combien de nœuds Broker une instance Kafka possède-t-elle ? Puis-je configurer ce nombre manuellement ?
ApsaraMQ for Kafka est un service de file d'attente de messages entièrement géré fourni par Alibaba Cloud. Le système ajuste automatiquement le nombre et la configuration des nœuds Broker en fonction de la spécification de trafic de votre instance ; vous n'avez donc pas besoin de suivre les détails de chaque nœud individuellement. La configuration ou la spécification manuelle du nombre de nœuds Broker n'est pas prise en charge.
Quel est le nombre maximal de connexions pour la spécification alikafka.hw.2xlarge de l'édition Professional (High-write) ?
Pour une instance dotée de la spécification de trafic alikafka.hw.2xlarge, si vous ne mettez pas à niveau la spécification de trafic, le nombre maximal de connexions par nœud commence à 1 000. Si votre activité nécessite une limite de connexion plus élevée, mettez à niveau la spécification de trafic de votre instance.
Mots-clés : connexions maximales, limite de connexion, alikafka.hw.2xlarge.