Questions fréquemment posées

Le service Oracle Cloud Infrastructure (OCI) Streaming représente une solution de messagerie entièrement gérée, évolutive et durable qui permet d’ingérer des flux de données continus et de grand volume que vous pouvez consommer et traiter en temps réel. Streaming est disponible dans toutes les régions Oracle Cloud Infrastructure prises en charge. Pour en obtenir une liste, consultez la page Régions et domaines de disponibilité.

Streaming est un service sans serveur qui décharge la gestion de l’infrastructure allant de la mise en réseau au stockage et à la configuration nécessaire pour diffuser vos données en continu. Vous n’avez pas à vous soucier de la mise en place de l’infrastructure, de la maintenance continue ou des correctifs de sécurité. Le service Streaming réplique de manière synchrone les données dans trois domaines de disponibilité, ce qui assure une haute disponibilité et la durabilité des données. Dans les régions ayant un seul domaine de disponibilité, les données sont reproduites dans trois domaines de défaillance.

Streaming facilite la collecte, le stockage et le traitement des données générées en temps réel à partir de centaines de sources. Le nombre de cas d’utilisation est presque illimité, allant de la messagerie au traitement de flux de données complexes. Voici quelques-unes des nombreuses utilisations possibles du service Streaming :

• Messagerie : Utilisez Streaming pour découpler les composants de grands systèmes. Les producteurs et les consommateurs peuvent utiliser Streaming comme un bus de messages asynchrones et agir de manière indépendante et à leur propre rythme.
• Ingestion d’indicateurs et de journaux : Utilisez Streaming comme alternative aux approches traditionnelles de nettoyage de fichiers pour rendre les données opérationnelles critiques rapidement disponibles pour l’indexation, l’analyse et la visualisation.
• Ingestion de données d’activité web/mobile : Utilisez Streaming pour capturer l’activité des sites web ou des applications mobiles, comme les pages consultées, les recherches ou d’autres actions utilisateur. Vous pouvez utiliser ces informations pour la surveillance et l’analyse en temps réel, ainsi que dans les systèmes d’entreposage de données pour le traitement et le reporting hors ligne.
• Traitement des événements d’infrastructure et d’applications : Utilisez Streaming comme point d’entrée unifié pour les composants Cloud afin de signaler leurs événements de cycle de vie pour l’audit, la comptabilité et les activités connexes.

Vous pouvez commencer à utiliser Streaming comme suit :

1. Créez un flux en utilisant la Console Oracle Cloud Infrastructure ou l’opération API CreateStream.
2. Configurez les producteurs pour qu’ils publient des messages sur le flux. Consultez la section Publication de messages.
3. Créez des consommateurs capables de lire et de traiter les données du flux. Consultez la section Consommation de messages.

Vous pouvez également utiliser les API Kafka pour produire et consommer à partir d’un flux. Pour plus d’informations, reportez-vous à la section Utilisation de Streaming avec Apache Kafka.

Le débit de Streaming est conçu pour évoluer sans limites en ajoutant des partitions à un flux. Cependant, il y a certaines limites à garder à l’esprit lors de l’utilisation de Streaming :

• La période de conservation maximale des messages dans un flux est de sept jours.
• La taille maximale d’un message unique qui peut être produit dans un flux est de 1 mégaoctet (Mo).
• Chaque partition peut gérer jusqu’à 1 Mo par seconde de débit avec n’importe quel nombre de demandes d’écriture.
• Chaque partition peut prendre en charge un taux d’écriture de données total maximum de 1 Mo par seconde et un taux de lecture de 2 Mo par seconde.

Streaming fournit une sémantique basée sur les flux. La sémantique des flux offre des garanties strictes d’ordonnancement par partition, de rejouabilité des messages, de curseurs côté client et d’échelle horizontale massive de débit. Les files d’attente n’offrent pas ces fonctionnalités. Les files d’attente peuvent être conçues pour fournir des garanties de commande si l’on utilise des files d’attente FIFO, mais uniquement au prix d’un surcoût important en termes de performances.

Un flux est un journal de messages cloisonné, en annexe seulement, dans lequel les applications des producteurs écrivent des données et dans lequel les applications des consommateurs lisent des données.

Un pool de flux est un regroupement que vous pouvez utiliser pour organiser et gérer les flux. Les pools de flux offrent une facilité opérationnelle en offrant la possibilité de partager les paramètres de configuration sur plusieurs flux. Par exemple, les utilisateurs peuvent partager des paramètres de sécurité tels que des clés de chiffrement personnalisées sur le pool de flux pour chiffrer les données de tous les flux à l’intérieur du pool. Un pool de flux vous permet également de créer un point de terminaison privé pour les flux en limitant l’accès Internet à tous les flux d’un pool de flux. Pour les clients utilisant la fonctionnalité de compatibilité Kafka de Streaming, le pool de flux sert de racine d’un cluster Kafka virtuel, permettant ainsi à chaque action sur ce cluster virtuel d’être étendue à ce pool de flux.

Une partition est une unité de débit de base dans un flux qui permet une échelle horizontale et un parallélisme de la production et de la consommation à partir d’un flux. Une partition offre une capacité d’entrée de données de 1 Mo/s et de sortie de données de 2 Mo/s. Lorsque vous créez un flux, vous spécifiez le nombre de partitions dont vous avez besoin en fonction des exigences de débit de votre application. Par exemple, vous pouvez créer un flux avec dix partitions, auquel cas vous pouvez atteindre un débit de 10 Mo/s d’entrée et de 20 Mo/s de sortie à partir d’un flux.

Un message est une unité de données codées en base64 et stockées dans un flux. La taille maximale d’un message que vous pouvez produire sur une partition d’un flux est de 1 Mo.

Une clé est un identifiant utilisé pour regrouper les messages associés. Les messages ayant la même clé sont écrits sur la même partition. Streaming garantit que tout consommateur d’une partition donnée lira toujours les messages de cette partition exactement dans le même ordre qu’ils ont été écrits.

Un producteur est une application client qui peut écrire des messages sur un flux.

Un consommateur est une application client qui peut lire des messages à partir d’un ou plusieurs flux. Un groupe de consommateurs est un ensemble d’instances qui coordonne les messages de toutes les partitions d’un flux. À tout moment, les messages d’une partition spécifique ne peuvent être consommés que par un seul consommateur du groupe.

Un curseur est un pointeur vers un emplacement dans un flux. Cet emplacement peut être un pointeur vers un décalage ou un temps spécifique dans une partition, ou vers l’emplacement actuel d’un groupe.

Chaque message au sein d’une partition possède un identifiant appelé décalage. Les consommateurs peuvent lire les messages à partir d’un décalage spécifique et sont autorisés à lire à partir de n’importe quel point de décalage de leur choix. Les consommateurs peuvent également valider le dernier décalage traité afin de reprendre leur travail sans répéter ni manquer un message en cas d’arrêt et de redémarrage.

Streaming assure le cryptage des données par défaut, tant au repos qu’en transit. Le streaming est entièrement intégré à Oracle Cloud Infrastructure Identity and Access Management (IAM), qui vous permet d’utiliser les stratégies d’accès pour accorder de manière sélective des autorisations aux utilisateurs et groupes d’utilisateurs. Tout en utilisant les API REST, vous pouvez également PUT et GET en toute sécurité vos données à partir de Streaming via des points de terminaison SSL avec le protocole HTTPS. De plus, Streaming permet une isolation complète des données au niveau du locataire sans aucun problème de « voisinage bruyant ».

Les données Streaming sont cryptées au repos et en transit, tout en garantissant l’intégrité des messages. Vous pouvez laisser Oracle gérer le cryptage, ou utiliser Oracle Cloud Infrastructure Vault pour stocker et gérer en toute sécurité vos propres clés de cryptage si vous devez respecter des normes de conformité ou de sécurité spécifiques.

Vous pouvez modifier les paramètres de cryptage des données du pool de flux à tout moment si vous souhaitez passer de l’utilisation du « cryptage fourni par les clés Oracle » au « cryptage géré à l’aide de clés gérées par le client ». Streaming n’impose aucune restriction quant au nombre de fois que cette activité peut être effectuée.

Streaming est entièrement intégré à Oracle Cloud Infrastructure IAM. Chaque flux a un compartiment assigné. Les utilisateurs peuvent spécifier des stratégies de contrôle d’accès basées sur les rôles qui peuvent être utilisées pour décrire des règles précises au niveau de la location, du compartiment ou du flux unique.

La stratégie d’accès est spécifiée sous la forme « Autoriser <objet> à <verbe> <type de ressource> dans <emplacement> où <conditions> ».

L’authentification avec le protocole Kafka utilise des jetons d’authentification et le mécanisme SASL/PLAIN. Vous pouvez générer des jetons sur la page des détails de l’utilisateur de la console. Pour plus d’informations, consultez la section Utilisation des jetons d’authentification. Nous vous recommandons de créer un groupe/utilisateur dédié et d’accorder à ce groupe l’autorisation de gérer les flux dans le compartiment ou la location appropriés. Vous pouvez ensuite générer un jeton d’authentification pour l’utilisateur que vous avez créé et l’utiliser dans la configuration de votre client Kafka.

Les points de terminaison privés limitent l’accès à un réseau Cloud virtuel (VCN) spécifique au sein de votre location, de sorte que ses flux ne sont pas accessibles via Internet. Les points de terminaison privés associent une adresse IP privée dans un VCN au pool de flux, ce qui permet au trafic Streaming d’éviter de traverser Internet. Pour créer un point de terminaison privé pour Streaming, vous devez accéder à un VCN avec un sous-réseau privé lorsque vous créez le pool de flux. Pour plus d’informations, consultez les sections À propos des points de terminaison privés et VCN et sous-réseaux.

Vous pouvez écrire le contenu d’un flux directement dans un compartiment Object Storage, généralement pour conserver les données dans le flux pour un stockage à long terme. Cela peut être réalisé en utilisant Kafka Connect pour S3 avec Streaming. Pour plus d’informations, consultez l’article de blog Publication sur Object Storage à partir d’Oracle Streaming Service.

Vous pouvez ingérer des données à partir d’une table dans une instance Oracle Autonomous Transaction Processing. Pour plus d’informations, consultez l’article de blog Utilisation de Kafka Connect avec Oracle Streaming Service et Autonomous DB.

Vous pouvez utiliser les SDK Kafka pour produire et consommer des messages à partir de Streaming, et vous pouvez utiliser la prise en charge intégrée de Micronaut pour Kafka. Pour plus d’informations, consultez l’article de blog Messagerie facile avec le support Kafka de Micronaut et Oracle Streaming Service.

Pour plus d’informations, consultez l’article de blog Ingérer les données IoT des courtiers MQTT dans OCI-Oracle Streaming Service, OCI- Kafka Connect Harness et Oracle Kubernetes Engine.

Oracle GoldenGate for Big Data est désormais certifié pour s’intégrer à Streaming. Pour plus d’informations, consultez la section Connexion à Oracle Streaming Service dans la documentation Oracle GoldenGate for Big Data.

Vous devez utiliser Kafka JDBC Sink Connect pour transporter directement les données en streaming dans Oracle Autonomous Data Warehouse.

• L’article de blog Utilisation de Kafka Connect avec Oracle Streaming Service et Autonomous DB explique comment utiliser un connecteur source Kafka Connect, qui pousse les données d’Oracle Autonomous Data Warehouse dans des flux. Il vous faut le contraire, un connecteur de récepteur.
• L’article de blog Données OSS vers ADW en temps quasi réel explique comment utiliser une table externe avec un chemin de stockage d’objets pour obtenir des données dans Oracle Autonomous Data Warehouse.

Streaming utilise une tarification simple à l’utilisation, qui garantit que vous ne payez que les ressources que vous utilisez sans aucun coût initial. Les dimensions de la tarification comprennent :

• Prix des demandes GET/PUT - gigaoctets de données transférées
• Prix du stockage, déterminé par le nombre d’heures de la période de conservation utilisée pour conserver vos données - gigaoctets de stockage par heure

Veuillez consulter la page produit Streaming pour connaître les dernières informations sur les prix.

La tarification de Streaming, celle de pointe du secteur, garantit que vous ne payez que lorsque vous utilisez le service. Cela signifie que vous ne payez pas un prix supplémentaire pour les ressources lorsqu’elles ne sont pas utilisées.

Streaming ne facture pas de prix supplémentaire pour le transfert de données vers et hors du service. De plus, les utilisateurs peuvent tirer parti de la puissance de Service Connector Hub pour transférer des données vers et depuis Streaming sans serveur et sans frais supplémentaires.

Actuellement, Streaming ne fonctionne pas dans le volet gratuit.

Oracle Cloud Infrastructure Streaming garantit un pourcentage de disponibilité mensuel d’au moins 99,9 %. Le pourcentage de disponibilité mensuel est calculé en soustrayant le pourcentage d’indisponibilité du mois civil de 100 % pour le service Oracle Cloud Infrastructure Streaming applicable.

Veuillez vous reporter à la section 2.7.1.6.32 Oracle Cloud Infrastructure - Streaming, dans le Document Pillar Oracle PaaS et IaaS Public Cloud Services (PDF) pour obtenir tous les détails sur les conditions du SLA et l’éligibilité aux crédits de service.

Le service Identity and Access Management vous permet de contrôler qui a accès à vos ressources Cloud. Pour utiliser les ressources Oracle Cloud Infrastructure, vous devez obtenir le type d’accès requis dans une stratégie rédigée par un administrateur, que vous utilisiez la console ou l’API REST avec un SDK, une CLI ou d’autres outils. L’accès à la stratégie est spécifiée sous la forme suivante

Autoriser <objet> à <verbe> <resource-type> dans <emplacement> où <conditions>

Les administrateurs d’une location peuvent utiliser la stratégie

Autoriser le groupe StreamAdmins à gérer les flux dans la location

qui permet à un groupe StreamAdmins spécifié tout faire en ce qui concerne le streaming, depuis la création, la mise à jour, la liste et la suppression des flux et des ressources qui y sont liées. Cependant, vous pouvez toujours spécifier des stratégies plus granulaires afin que seuls certains utilisateurs d’un groupe ne soient éligibles que pour un sous-ensemble d’activités qu’ils peuvent effectuer sur un flux donné. Si vous débutez dans le domaine des stratégies, consultez les sections Pour commencer avec les stratégies et Stratégies communes. Si vous souhaitez approfondir la rédaction de stratégies pour Streaming, consultez la section Détails du service Streaming dans la référence sur les stratégies IAM.

Vous pouvez provisionner un flux et tous ses composants associés tels que les stratégies IAM, les partitions, les paramètres de cryptage, etc., en utilisant Oracle Cloud infrastructure Resource Manager ou le fournisseur Terraform pour Oracle Cloud Infrastructure. Pour plus d’informations sur le fournisseur Terraform, consultez la rubrique Terraform pour le service Streaming.

Lorsque vous créez un flux, vous devez spécifier le nombre de partitions du flux. Le débit attendu de votre application peut vous aider à déterminer le nombre de partitions pour votre flux. Multipliez la taille moyenne des messages par le nombre maximal de messages écrits par seconde pour estimer votre débit attendu. Étant donné qu’une seule partition est limitée à un taux d’écriture de 1 Mo par seconde, un débit plus élevé nécessite des partitions supplémentaires pour éviter la limitation. Pour vous aider à gérer les pics d’application, nous vous recommandons d’allouer des partitions légèrement supérieures à votre débit maximal.

Vous créez des partitions lorsque vous créez un flux, que ce soit sur la console ou par programmation.

Interface utilisateur de la console :

Par programmation :

Créer un flux

CreateStreamDetails streamDetails =

        CreateStreamDetails.builder()

                .compartmentId(compartmentId)

                .name(streamName)

                .partitions(partitions)

                .build();

Un exemple plus détaillé est fourni avec le SDK.

Streaming gère les partitions en interne afin que vous n’ayez pas besoin de les gérer. Un utilisateur ne peut pas supprimer directement une partition. Lorsque vous supprimez un flux, toutes les partitions associées à ce flux sont supprimées.

Le débit d’un flux Oracle Cloud Infrastructure est défini par une partition. Une partition fournit 1 Mo par seconde d’entrée de données et 2 Mo par seconde de sortie de données.

Le débit d’un flux Oracle Cloud Infrastructure peut être augmenté en y ajoutant davantage de partitions. Il n’y a pas de limite supérieure théorique sur le nombre de partitions qu’un flux peut contenir. Toutefois, chaque location d’Oracle Cloud Infrastructure est assortie d’une limite de partition par défaut de 5 pour les comptes de type Universal Credits. Si vous avez besoin de plus de partitions, vous pouvez toujours demander une augmentation de vos limites de service.

Vous pouvez demander une augmentation de la limite de service en suivant ces étapes :

1. Dans l’angle supérieur droit de la console, ouvrez le menu Utilisateur et cliquez sur Location : <nom_location> .
   
   
2. Cliquez sur Limites de service, puis sur Demander une augmentation de la limite de service.
   
   
3. Remplissez le formulaire en sélectionnant Autres pour le champ Catégorie de service et Autres limites pour le champ Ressource. Dans Motif de la demande, demandez d’augmenter le nombre de partitions pour le service Streaming dans votre location.

Voici quelques bonnes pratiques à garder à l’esprit lors de la création d’un flux :

• Les noms de flux doivent être uniques dans un pool de flux. Cela signifie que vous pouvez créer deux flux avec le même nom dans le même compartiment uniquement s’ils se trouvent sur des pools de flux différents.
• Une fois qu’un flux est créé, vous ne pouvez pas modifier le nombre de partitions qu’il contient. Nous recommandons d’allouer des partitions légèrement supérieures à votre débit maximal. Cela peut vous aider à gérer les pics d’application.
• La période de rétention d’un flux ne peut pas être modifiée après sa création. Par défaut, les données sont stockées dans un flux pendant 24 heures. Cependant, il peut être configuré pour conserver les données entre 24 et 168 heures. La quantité de données stockées dans un flux n’a aucun impact sur les performances du flux.

Une fois qu’un flux est créé et est à l’état « Actif », vous pouvez commencer à produire des messages. Vous pouvez produire un flux en utilisant la console ou via l’API.

Pour la console : Accédez à la section Service de streaming sur la console, située sous l’onglet Solutions et plateforme > Analytique. Si vous avez déjà créé des flux, sélectionnez un flux dans un compartiment et accédez à la page « Détails du flux ». Cliquez sur le bouton « Produire un message de test » sur la console. Cela attribuera au hasard une clé de partition au message et écrira sur une partition du flux. Vous pouvez afficher ce message dans la section Messages récents en cliquant sur le bouton Charger les messages.

Pour les API : Vous pouvez utiliser les API Oracle Cloud Infrastructure Streaming ou les API Kafka pour produire un flux. Le message sera publié dans une partition du flux. S’il y a plus d’une partition, vous spécifiez une clé pour choisir à quelle partition envoyer le message, et si vous ne spécifiez pas de clé, Streaming en attribue une pour vous en générant un UUID et envoie le message à une partition aléatoire. Cela garantit que les messages sans clé sont uniformément répartis sur toutes les partitions. Cependant, nous vous recommandons de toujours spécifier une clé de message afin de pouvoir contrôler explicitement la stratégie de partitionnement de vos données.

Des exemples de production de messages dans un flux à l’aide de SDK Streaming se trouvent dans la documentation.

Lors de l’utilisation des API Oracle Cloud Infrastructure pour produire un message, la logique de partitionnement est contrôlée par Streaming. C’est ce qu’on appelle le partitionnement côté serveur. En tant qu’utilisateur, vous choisissez la partition à envoyer en fonction de la clé. La clé est hachée et la valeur résultante est utilisée pour déterminer le numéro de partition à laquelle envoyer le message. Les messages avec la même clé vont dans la même partition. Les messages avec des clés différentes peuvent aller vers des partitions différentes ou vers la même partition.

Cependant, si vous utilisez des API Kafka pour produire un flux, le partitionnement est contrôlé par le client Kafka et le partitionneur dans le client Kafka est responsable de la logique de partitionnement. C’est ce qu’on appelle le partitionnement côté client.

Pour garantir une distribution uniforme des messages, vous avez besoin d’une valeur efficace pour vos clés de message. Pour en créer un, tenez compte de la sélectivité et de la cardinalité de vos données en streaming.

• Cardinalité : Tenez compte du nombre total de clés uniques susceptibles d’être générées en fonction du cas d’utilisation spécifique. Une cardinalité de clé plus élevée est généralement synonyme de meilleure distribution.
• Sélectivité : Considérez le nombre de messages avec chaque clé. Une sélectivité plus élevée signifie plus de messages par clé, ce qui peut conduire à des points d’accès.

Il faut toujours viser une haute cardinalité et une faible sélectivité.

Streaming garantit des lectures et des écritures linéaires à l’intérieur d’une partition. Si vous voulez vous assurer que les messages possédant la même valeur soient placés dans la même partition, vous devez utiliser la même clé pour ces messages.

Une partition fournit un débit d’entrée de données de 1 Mo/s et prend en charge jusqu’à 1000 messages PUT par seconde. Par conséquent, si la taille de l’enregistrement est inférieure à 1 Ko, le taux d’entrée de données réel d’une partition sera inférieur à 1 Mo/s, limité par le nombre maximal de messages PUT par seconde. Nous vous recommandons de produire des messages par lots pour les raisons suivantes :

• Cela réduit le nombre de demandes PUT envoyées au service, ce qui évite l’étranglement.
• Cela permet un meilleur débit.

La taille d’un lot de messages ne doit pas dépasser 1 Mo. Si cette limite est dépassée, le mécanisme de limitation est déclenché.

Vous pouvez utiliser la segmentation ou envoyer le message à l’aide d’Oracle Cloud Infrastructure Object Storage.

• Segmentation : Vous pouvez diviser les grandes charges utiles en plusieurs petits fragments que Streaming peut accepter. Les fragments sont stockés dans le service de la même manière que les messages ordinaires, non fragmentés, sont stockés. La seule différence est que le consommateur doit conserver les fragments et les combiner dans le message lorsque tous les fragments ont été collectés. Les fragments de la partition peuvent être entrelacés avec des messages ordinaires.
• Object Storage : Une grande charge utile est placée dans Object Storage et seul le pointeur vers ces données est transféré. Le récepteur reconnaît ce type de charge utile de pointeur, lit de manière transparente les données dans Object Storage et les fournit à l’utilisateur final.

Lorsqu’un producteur produit à un débit supérieur à 1 Mo par seconde, la demande est limitée et une erreur 429, trop de demandes est renvoyée au client indiquant que trop de demandes par seconde et par partition sont reçues.

Un consommateur est une entité qui lit les messages d’un ou plusieurs flux. Cette entité peut exister seule ou faire partie d’un groupe de consommateurs. Pour consommer des messages, vous devez créer un curseur, puis utiliser ce curseur pour lire les messages. Un curseur pointe vers un emplacement dans un flux. Cet emplacement peut être un décalage ou un moment précis dans une partition ou l’emplacement actuel d’un groupe. En fonction de l’emplacement à partir duquel vous souhaitez lire, différents types de curseurs sont disponibles : TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME et LATEST.

Pour plus d’informations, reportez-vous à la documentation sur la Consommation de messages.

La méthode getLimit( ) de la classe GetMessagesRequest renvoie le nombre maximum de messages. Vous pouvez spécifier n’importe quelle valeur jusqu’à 10 000. Par défaut, le service renvoie autant de messages que possible. Tenez compte de la taille moyenne de vos messages pour éviter de dépasser le débit sur le flux. Les tailles de lot GetMessages du service Streaming sont basées sur la taille moyenne des messages produits sur le flux particulier.

Streaming fournit une sémantique de diffusion « au moins une fois » aux consommateurs. Nous recommandons que les applications grand public prennent en charge les doublons. Par exemple, lorsqu’une instance précédemment inactive du groupe de consommateurs rejoint le groupe et commence à consommer des messages qui n’ont pas été validés par l’instance précédemment affectée, il y a une chance de traiter les doublons.

On dit qu’un consommateur prend du retard si vous produisez plus vite que vous ne pouvez consommer. Pour déterminer si votre consommateur prend du retard, vous pouvez utiliser l’horodatage du message. Si le consommateur prend du retard, envisagez de créer un nouveau consommateur pour reprendre certaines des partitions du premier consommateur. Si vous êtes en retard sur une seule partition, il n’y a aucun moyen de récupérer ce retard.

Considérez les options suivantes :

• Augmentez le nombre de partitions dans le flux.
• Si le problème est causé par un point d’accès, modifiez la stratégie de clé de message.
• Réduisez le temps de traitement des messages ou gérez les demandes en parallèle.

Si vous voulez savoir combien de messages il reste à consommer dans une partition donnée, utilisez un curseur de type LATEST, obtenez le décalage du message publié suivant et effectuez le delta avec le décalage que vous consommez actuellement. Comme nous n’avons pas de décalage dense, vous ne pouvez obtenir qu’une estimation approximative. Cependant, si votre producteur a cessé de produire, vous ne pouvez pas obtenir cette information car vous n’obtiendrez jamais la compensation du prochain message publié.

Il est possible de configurer des utilisateurs pour qu’ils utilisent des messages au sein d’un groupe. Les partitions de flux sont réparties entre les membres d’un groupe afin que les messages provenant d’une partition unique soient envoyés uniquement à un seul utilisateur. Les attributions de partition sont rééquilibrées lorsque les utilisateurs rejoignent ou quittent le groupe. Pour plus d’informations, reportez-vous à la documentation sur les Groupes de consommateurs.

Les groupes de consommateurs offrent les avantages suivants :

• Chaque instance d’un groupe de consommateurs reçoit des messages d’une ou plusieurs partitions qui lui sont « automatiquement » affectées, et les mêmes messages ne sont pas reçus par les autres instances (qui sont affectées à différentes partitions). De cette façon, nous pouvons augmenter le nombre d’instances jusqu’au nombre de partitions en faisant en sorte qu’une instance ne lise qu’une seule partition. Dans ce cas, une nouvelle instance qui rejoint le groupe se trouve dans un état de repos sans être affectée à une quelconque partition.
• Le fait d’avoir des instances faisant partie de différents groupes de consommateurs signifie fournir un modèle de publication-abonnementdans lesquels les messages des partitions sont envoyés à toutes les instances des différents groupes.
  À l’intérieur du même groupe de consommateurs, les règles sont présentées dans l’image suivante :
  
  
  Dans différents groupes, les instances reçoivent les mêmes messages, comme illustré dans l’image suivante :
  
  Ceci est utile lorsque les messages à l’intérieur d’une partition présentent un intérêt pour différentes applications qui les traiteront de différentes manières. Nous voulons que toutes les applications intéressées reçoivent les mêmes messages de la partition.
• Lorsqu’une instance rejoint un groupe, si suffisamment de partitions sont disponibles (c’est-à-dire que la limite d’une instance par partition n’a pas été atteinte), un rééquilibrage démarre. Les partitions sont réaffectées aux instances actuelles, plus la nouvelle. De la même manière, si une instance quitte un groupe, les partitions sont réaffectées aux instances restantes.
• Les validations de décalage sont gérées automatiquement.

Il y a une limite de 50 groupes de consommateurs par flux. Les groupes de consommateurs sont éphémères. Ils disparaissent lorsqu’ils ne sont pas utilisés pendant la période de rétention du flux.

Les composants suivants du service Streaming ont des délais d’expiration :

• Curseur : Tant que vous continuez à consommer des messages, il n’est pas nécessaire de créer un curseur. Si la consommation des messages s’arrête pendant plus de 5 minutes, le curseur doit être recréé.
• Instance : Si une instance cesse de consommer des messages pendant plus de 30 secondes, elle est supprimée du groupe de consommateurs et sa partition est réaffectée à une autre instance. C’est ce qu’on appelle le rééquilibrage.

Le rééquilibrage est le processus dans lequel un groupe d’instances, qui appartient au même groupe de consommateurs, se coordonne pour posséder un ensemble de partitions mutuellement exclusives qui appartient à un flux spécifique. À la fin d’une opération de rééquilibrage réussie pour un groupe de consommateurs, chaque partition du flux appartient à une ou plusieurs instances de consommateur au sein du groupe.

Lorsqu’une instance d’un groupe de consommateurs devient inactive parce qu’elle ne parvient pas à envoyer une pulsation pendant plus de 30 secondes ou parce que le processus est arrêté, une activité de rééquilibrage est déclenchée au sein du groupe de consommateurs. Cela permet de gérer les partitions précédemment consommées par l’instance inactive et de la réaffecter à une instance active. De même, lorsqu’une instance d’un groupe de consommateurs qui était auparavant inactive rejoint le groupe, un rééquilibrage est déclenché pour affecter une partition à partir de laquelle commencer à consommer. Le service Streaming n’offre aucune garantie de réaffecter l’instance à la même partition lorsqu’elle rejoint le groupe.

Pour récupérer après une défaillance, vous devez stocker le décalage du dernier message que vous avez traité pour chaque partition afin de pouvoir commencer à consommer à partir de ce message si vous devez redémarrer votre consommateur.

Remarque : Ne stockez pas le curseur ; il expire après 5 minutes.

Nous ne fournissons aucune indication pour stocker le décalage du dernier message que vous avez traité, vous pouvez donc utiliser la méthode de votre choix. Par exemple, vous pouvez stocker le curseur sur un autre flux, ou un fichier sur une machine virtuelle ou un compartiment Object Storage. Lorsque votre consommateur redémarre, lisez le décalage du dernier message que vous avez traité, puis créez un curseur de type AFTER_OFFSET et spécifiez le décalage que vous venez d’obtenir.

Le service Streaming fournit un point de terminaison Kafka qui peut être utilisé par vos applications basées sur Apache Kafka existantes. Un changement de configuration est tout ce qui est nécessaire pour avoir une expérience Kafka entièrement gérée. La compatibilité Kafka de Streaming offre une alternative à l’exécution de votre propre cluster Kafka. Streaming prend en charge Apache Kafka 1.0 et les versions plus récentes du client et fonctionne avec vos applications, outils et frameworks Kafka existants.

Les clients disposant d’applications Kafka existantes pourront migrer vers Streaming en modifiant simplement les paramètres suivants de leur fichier de configuration Kafka.

security.protocol : SASL_SSL

sasl.mechanism : PLAIN

sasl.jaas.config : org.apache.kafka.common.security.plain.PlainLoginModule required username="{username}" password="{pwd}";

bootstrap.servers : kafka.streaming.{region}.com:9092

# Application settings

topicName : [streamOcid]

Pour utiliser vos connecteurs Kafka avec Streaming, créez une configuration Kafka Connect à l’aide de la console ou de l’interface de ligne de commande (CLI). Le API Streaming appelle ces configurations harnesses. Les configurations Kafka Connect créées dans un compartiment donné ne fonctionnent que pour les flux dans le même compartiment. Vous pouvez utiliser plusieurs connecteurs Kafka avec la même configuration Kafka Connect. Dans les cas qui nécessitent la production ou la consommation de flux dans des compartiments séparés, ou lorsque plus de capacité est requise pour éviter d’atteindre les limites de régulation de la configuration Kafka Connect (par exemple, trop de connecteurs ou connecteurs avec trop de collaborateurs), vous pouvez créer plus de configurations de connecteurs Kafka.

La compatibilité Kafka Connect de Streaming signifie que vous pouvez tirer parti des nombreux connecteurs propriétaires et tiers existants pour déplacer les données de vos sources vers vos cibles. Les connecteurs Kafka pour les produits Oracle comprennent :

• Oracle Cloud Infrastructure Object Storage (à l’aide de Kafka Connect pour S3)
• Connecteur source Kafka Connect Amazon S3, pour les producteurs
• Connecteur de récepteur Kafka Connect Amazon S3, pour les consommateurs
• Oracle Integration Cloud
• Oracle Database (Utilisation de Kafka Connect JDBC)
• Oracle GoldenGate

Pour obtenir la liste complète des connecteurs source et récepteur Kafka tiers, reportez-vous au hub officiel de Confluent Kafka.

Streaming est entièrement intégré à Oracle Cloud Infrastructure Monitoring. Dans la console, sélectionnez le flux que vous souhaitez surveiller. Sous la page Détails du flux, accédez à la section Ressources et cliquez sur Produire des graphiques de surveillance pour suivre les demandes des producteurs, ou cliquez sur Consommer des graphiques de surveillance pour surveiller les indicateurs clés côté consommateur. Les indicateurs clés sont disponibles au niveau du flux et non au niveau de la partition. Pour obtenir une description des indicateurs clés Streaming pris en charge, consultez la documentation.

Chaque indicateur clé disponible dans la Console fournit les statistiques suivantes :.

• Taux, Somme et Moyenne
• Min, Max et Nombre
• P50, P90, P95, P99 et P99.9

Ces statistiques sont proposées pour les intervalles de temps suivants :.

• Auto
• 1 minute
• 5 minutes
• 1 heure

Pour les producteurs, envisagez de définir des alarmes sur les indicateurs clés suivants :

• Put Messages Latency : Une augmentation de la latence signifie que les messages prennent plus de temps à être publiés, ce qui pourrait indiquer des problèmes de réseau.
• Put Messages Total Throughput :
  • Une augmentation importante du débit total pourrait indiquer que la limite de 1 Mo/s par partition sera atteinte et que cet événement déclenchera le mécanisme de limitation.
  • Une diminution importante pourrait signifier que le producteur client a un problème ou est sur le point de s’arrêter.
• Put Messages Throttled Records : Il est important d’être averti lorsque les messages sont limités.
• Put Messages Failure : Il est important d’être averti si les messages PUT commencent à échouer afin que l’équipe Ops puisse commencer à enquêter sur les raisons.

Pour les consommateurs, envisagez de définir les mêmes alarmes en fonction des indicateurs clés suivant :

• Get Messages Latency
• Get Messages Total Throughput
• Get Messages Throttled Requests
• Get Messages Failure

Un flux est sain lorsqu’il est dans un état Actif. Si vous pouvez produire sur votre flux, et si vous obtenez une réponse positive, alors le flux est sain. Une fois les données produites dans le flux, elles sont accessibles aux consommateurs pendant la période de rétention configurée. Si les appels de l’API GetMessages renvoient des niveaux élevés d’erreurs internes du serveur, le service n’est pas sain.

Un flux sain a également des indicateurs clés sains :

• Put Messages Latency est faible.
• Put Messages Total Throughput est proche de 1 Mo par seconde par partition.
• Put Messages Throttled Records est proche de 0.
• Put Messages Failure est proche de 0.

• Get Messages Latency est faible.
• Get Messages Total Throughput est proche de 2 Mo par seconde par partition.
• Get Messages Throttled Requests est proche de 0.
• Get Messages Failure est proche de 0.

La limitation indique que le flux est incapable de gérer les nouvelles lectures ou écritures. Le mécanisme de limitation s’active lorsque les seuils suivants sont dépassés :

• GetMessages : Cinq appels par seconde ou 2 Mo par seconde par partition
• PutMessages : 1 Mo par seconde par partition
• Opérations de gestion et de plan de contrôle, telles que CreateCursor, ListStream, etc. : Cinq appels par seconde par flux

Les détails sur les erreurs API se trouvent dans la documentation.