Questions fréquentes (FAQ) sur Amazon Kinesis Data Streams

Une partition est une séquence d'enregistrements de données au sein d'un flux. Il s'agit de l'unité de débit de base d'un flux de données Kinesis. Une partition prend en charge 1 Mo/seconde et 1 000 enregistrements par seconde pour les écritures et 2 Mo/seconde pour les lectures. Les limites de partition garantissent des performances prévisibles, ce qui facilite la conception et l'exploitation d'un flux de streaming de données très fiable. Un producteur place des enregistrements de données dans les partitions ; un consommateur les en extrait. Les consommateurs se servent des partitions à des fins de traitement de données parallèle et pour consommer les données dans l'ordre exact où elles sont stockées. Si les écritures et les lectures dépassent les limites de partition, les applications producteur et consommateur reçoivent des limitations, qui peuvent être gérées par le biais de nouvelles tentatives.

L'enregistrement est l'unité utilisée pour les données stockées dans un flux de données Amazon Kinesis. Un enregistrement se compose d'un numéro de séquence, d'une clé de partition et d'un blob de données. Le blob de données correspond aux données utiles que le producteur ajoute au flux de données. La taille maximale d'un blob de données (charge de données utiles avant l'encodage en base64) est de 1 méga-octet (Mo).

Une clé de partition sert à isoler et acheminer les enregistrements vers les différentes partitions d'un flux de données. La clé de partition est spécifiée par votre producteur de données au moment d'ajouter les données à un flux de données Kinesis. Par exemple, supposons que vous disposez d'un flux de données à deux partitions (partition 1 et partition 2). Vous pouvez configurer votre producteur de données pour qu'il utilise les deux clés de partition (clé A et clé B) et pour que tous les enregistrements associés à la clé A soient ajoutés à la partition 1 et tous les enregistrements associés à la clé B soient ajoutés à la partition 2.

Un numéro de séquence est un identifiant unique associé à un enregistrement. Le numéro de séquence est attribué par Amazon Kinesis lorsqu'un producteur de données appelle l'opération PutRecord ou PutRecords afin d'ajouter des données à un flux de données Amazon Kinesis. En règle générale, les numéros de séquence d’une même clé de partition croissent au fil du temps ; plus l’intervalle de temps entre les demandes PutRecord ou PutRecords est long, plus les numéros de séquence sont élevés.

Le mode de capacité de Kinesis Data Streams détermine la façon dont la capacité est gérée et l'utilisation facturée pour un flux de données. Vous avez le choix entre le mode alloué et le mode à la demande. Dans le mode alloué, c'est vous qui spécifiez le nombre de partitions pour le flux de données. La capacité totale d'un flux de données correspond à la somme des capacités de ses partitions. Vous pouvez augmenter ou diminuer le nombre de partitions dans un flux de données selon les besoins, et le nombre de partitions vous est facturé à l'heure. Dans le mode à la demande, c'est AWS qui gère les partitions pour fournir le débit nécessaire. Seul le débit réellement utilisé vous est facturé, et Kinesis Data Streams ajuste automatiquement les besoins en débit de votre charge de travail à mesure qu'ils évoluent à la hausse ou à la baisse. Toutes les API d'écriture et de lecture Kinesis Data Streams, ainsi que les fonctions optionnelles telles que la rétention prolongée et la distribution améliorée, sont prises en charge dans les deux modes de capacité.

Le mode à la demande est plus adapté aux charges de travail dont les modèles de trafic sont imprévisibles et très variables. Utilisez ce mode si vous préférez qu'AWS gère la capacité à votre place ou si vous préférez une tarification au débit. Le mode alloué convient mieux pour un trafic dont les besoins en capacité sont facilement prévisibles. Envisagez le mode alloué si vous souhaitez contrôler avec précision la façon dont les données sont distribuées entre les partitions. Le mode alloué est également indiqué si vous souhaitez allouer des partitions supplémentaires afin de doter l'application consommatrice d'un plus gros débit de lecture et d'accélérer le traitement global.

Oui. Vous pouvez basculer entre le mode à la demande et le mode alloué à raison de deux fois par jour. Lorsque vous passez du mode alloué au mode à la demande ou inversement, le nombre de partitions contenues dans votre flux de données reste identique. En passant du mode de capacité alloué au mode de capacité à la demande, votre flux de données retient le nombre de partitions dont il disposait avant la transition. Mais à partir de cet instant, Kinesis Data Streams contrôle votre trafic de données et adapte à la hausse ou à la baisse le nombre de partitions de ce flux de données à la demande selon que le trafic augmente ou diminue.

Vous pouvez ajouter des données à un flux de données Kinesis via les opérations PutRecord et PutRecords, KPL ou Amazon Kinesis Agent.

L'opération PutRecord autorise un seul enregistrement de données dans le cadre d'un appel d'API. L'opération PutRecords, elle, en autorise plusieurs. Pour en savoir plus, consultez PutRecord et PutRecords.

KPL est une bibliothèque facile à utiliser et hautement configurable qui vous permet d'ajouter des données à un flux Amazon Kinesis. Elle est dotée d'une interface simple, asynchrone et fiable qui vous aide à atteindre rapidement un débit producteur élevé avec un minimum de ressources client.

Amazon Kinesis Agent est une application Java prédéfinie qui offre un moyen simple de collecter des données et de les envoyer vers votre flux de données Amazon Kinesis. Vous pouvez installer cet agent dans des environnements serveur basés sur Linux tels que des serveurs web, des serveurs de journaux et des serveurs de base de données. L'agent surveille certains fichiers et envoie en continu des données sur votre flux de données. Pour en savoir plus, consultez Writing with Agents.

Pour exécuter un appel PutRecord ou PutRecords, les paramètres requis sont le blob de données, la clé de partition et le nom du flux de données. La taille de votre blob de données (avant encodage en base64) et celle de la clé de partition sont prises en compte dans le débit de données de votre flux de données Amazon Kinesis, lequel est déterminé par le nombre de partitions présentes dans le flux de données.

Un consommateur est une application qui traite toutes les données en provenance d'un flux de données Kinesis. Pour la lecture des données en provenance d'un flux de données Kinesis, vous avez le choix entre les types de consommateur à distribution partagée et à distribution améliorée. Les consommateurs à distribution partagée partagent tous les limites d'une partition, à savoir un débit de lecture de 2 Mo/seconde et cinq transactions par seconde, et exigent l'utilisation de l'API GetRecords. Un consommateur à distribution améliorée bénéficie de son propre quota de débit de lecture de 2 Mo/seconde, ce qui permet à plusieurs consommateurs de lire les données d'un même flux en parallèle, sans avoir à se disputer le débit de lecture avec les autres consommateurs. Avec les consommateurs à distribution améliorée, vous devez utiliser l'API SubscribeToShard. Si vous avez l'intention d'ajouter plusieurs consommateurs à un flux de données, nous vous recommandons d'utiliser des consommateurs à distribution améliorée.

Vous pouvez utiliser des services managés comme AWS Lambda, le service géré Amazon pour Apache Flink et AWS Glue pour traiter les données stockées dans Kinesis Data Streams. Ils se chargent de l'approvisionnement et de la gestion de l'infrastructure sous-jacente, ce qui vous permet de vous concentrer sur l'écriture de votre logique métier. Vous pouvez également distribuer les données stockées dans Kinesis Data Streams à Amazon S3, Amazon OpenSearch Service, Amazon Redshift et à des points de terminaison HTTP personnalisés en profitant de son intégration prédéfinie à Kinesis Data Firehose. Vous pouvez également créer des applications personnalisées à l'aide de la bibliothèque prédéfinie Amazon Kinesis Client Library ou de l'API Amazon Kinesis Data Streams.

KCL pour Java, Python, Ruby, Node.js et .NET est une bibliothèque prédéfinie qui vous permet de créer facilement des applications Amazon Kinesis pour la lecture et le traitement des données issues d'un flux de données Amazon Kinesis.

La bibliothèque KCL gère les problèmes complexes, tels que l'adaptation à un volume de flux de données changeant, l'équilibrage de la charge pour les données de streaming, la coordination des services distribués et le traitement des données avec une tolérance aux pannes. Elle vous permet ainsi de vous concentrer sur la logique métier lors de la création des applications. Pour en savoir plus sur KCL, consultez la documentation Kinesis Data Streams ici.

L'API SubscribeToShard est une API de streaming hautement performante qui envoie les données en mode push des partitions vers les consommateurs via une connexion persistante sans cycle de demande de la part du client. L'API SubscribeToShard utilise le protocole HTTP/2 pour distribuer les données aux consommateurs enregistrés chaque fois que de nouvelles données arrivent sur la partition, en général en 70 millisecondes, assurant ainsi une diffusion environ 65 % plus rapide que l'API GetRecords. Les consommateurs peuvent bénéficier d'une diffusion rapide même si plusieurs consommateurs enregistrés lisent la même partition.

La distribution améliorée est une fonction optionnelle pour les consommateurs Kinesis Data Streams qui fournit des canaux de débit logiques de 2 Mo/s entre les consommateurs et les partitions. Cela vous permet de mettre à l'échelle le nombre de consommateurs lisant un flux de données en parallèle, tout en maintenant un haute niveau de performances.

Vous devez utiliser la distribution améliorée si plusieurs consommateurs extraient ou sont appelés à extraire les données d'un flux en parallèle, ou si au moins un consommateur exige l'utilisation de l'API SubscribeToShard pour fournir des débit de données de moins de 200 millisecondes entre les producteurs et les consommateurs.

Les consommateurs utilisent la distribution améliorée en extrayant les données à l'aide de l'API SubscribeToShard. Le nom du consommateur enregistré est utilisé dans l'API SubscribeToShard, ce qui conduit à l'utilisation de l'avantage de la distribution améliorée offert au consommateur enregistré.

Oui. Oui, vous pouvez faire en sorte que la distribution améliorée soit utilisée par plusieurs consommateurs, mais pas par d'autres. L'utilisation de la distribution améliorée n'a pas d'impact sur les limites des partitions dans le cadre d'une utilisation classique de GetRecords.

Oui. Pour utiliser SubscribeToShard, vous devez enregistrer vos consommateurs, ce qui a pour effet d'activer la distribution améliorée. Par défaut, votre consommateur utilise automatiquement la distribution améliorée lorsque les données sont extraites via SubscribeToShard.

Un flux de données créé en mode à la demande dispose d'un quota de 4 Mo/seconde et de 4 000 enregistrements/seconde pour les écritures. Par défaut, ces flux passent automatiquement à 200 Mo/seconde et à 200 000 enregistrements/seconde pour les écritures.

Un flux de données en mode à la demande peut s'adapter au point de doubler son débit d'écriture maximal observé au cours des 30 derniers jours. Dès que le débit d'écriture de votre flux de données atteint un nouveau pic, Kinesis Data Streams adapte automatiquement la capacité du flux. Par exemple, si le débit d'écriture de votre flux de données oscille entre 10 Mo/seconde et 40 Mo/seconde, Kinesis Data Streams fait en sorte que vous puissiez facilement doubler le débit maximal de 80 Mo/seconde. Par la suite, si le nouveau débit maximal de ce même flux de données se maintient à 50 Mo/seconde, Data Streams s'assure que la capacité est suffisante pour intégrer 100 Mo/seconde de débit d'écriture. Cependant, si votre trafic dépasse le pic précédent de plus du double pendant 15 minutes, vous obtenez des exceptions « ProvisionedThroughputExceeded ». Vous devez relancer les demandes limitées.

La capacité de lecture cumulée du mode à la demande augmente proportionnellement au débit d'écriture. Les applications consommatrices sont ainsi toujours assurées de bénéficier d'un débit de lecture adéquat pour traiter les données entrantes en temps réel. En utilisant l'API GetRecords, vous obtenez au moins deux fois le débit d'écriture pour lire les données. Nous vous recommandons d'utiliser un consommateur avec l'API GetRecord pour permettre un rattrapage lorsque l'application doit récupérer à la suite d'un temps d'arrêt. Pour ajouter plusieurs applications consommatrices, vous devez utiliser la distribution améliorée. Celle-ci permet d'ajouter jusqu'à 20 consommateurs à un flux de données via l'API SubscribeToShard, avec pour chacun un débit dédié.

Le débit d'un flux de données Kinesis en mode alloué est conçu pour une mise à l'échelle illimitée avec la possibilité d'augmenter le nombre de partitions en son sein.

Vous pouvez augmenter la capacité d'un flux de données Kinesis en mode alloué en scindant les partitions existantes à l'aide de l'API SplitShard. Vous pouvez en réduire la capacité en fusionnant deux partitions à l'aide de l'API MergeShard. Une autre solution consiste à utiliser l'API UpdateShardCount pour augmenter (ou réduire) la capacité d'un flux en fonction d'un nombre de partitions spécifique.

Le débit d'un flux de données Kinesis est déterminé par le nombre de partitions qu'il contient. Suivez la procédure ci-dessous pour estimer le nombre initial de partitions dont a besoin votre flux de données en mode alloué. Notez que vous pouvez ajuster de manière dynamique le nombre de partitions au sein de votre flux de données par le biais du repartitionnement.

Estimez la taille moyenne de l'enregistrement écrit dans le flux de données en kilo-octets (Ko), en arrondissant au kilo-octet le plus proche (taille_moyenne_des_données_en_ko)

Estimez le nombre d'enregistrements devant être écrits dans le flux à de données à chaque seconde. (nombre_d_enregistrements_par_seconde)

Déterminez le nombre d'applications Amazon Kinesis consommant de manière simultanée et indépendante les données en provenance du flux de données. (nombre_de_consommateurs)

Calculez le débit d'écriture des données entrantes en Ko (débit_écriture_données_entrantes_en_Ko), qui est égal à la taille_moyenne_des_données_en_Ko multipliée par le nombre_enregistrements_par_seconde.

Calculez le débit de lecture des données sortantes en Ko (débit_lecture_données_sortantes_en_Ko), qui est égal au débit_écriture_données_entrantes_en_Ko multiplié par le nombre_de_consommateurs.

Vous pouvez alors calculer le nombre initial de partitions (nombre_de_partitions) dont a besoin votre flux de données à l'aide de la formule suivante : nombre_de_partitions = max (débit_écriture_données_entrantes_en_Ko/1000, débit_lecture_données_sortantes_en_Ko/2000)

Le débit d'un flux de données Kinesis est conçu pour une mise à l'échelle illimitée. Le quota de partitions par défaut est de 500 partitions par flux pour les régions AWS suivantes : USA Est (Virginie du Nord), USA Ouest (Oregon) et Europe (Irlande). Pour toutes les autres régions, le quota de partitions par défaut est de 200 partitions par flux. Vous pouvez demander une augmentation du quota de partitions à l'aide de la console AWS Service Quotas.

En mode alloué, les limites de capacité d'un flux de données Kinesis sont définies en fonction du nombre de partitions présentes dans le flux de données. Ces limites peuvent être dépassées par le débit de données ou par le nombre d'enregistrements PUT. Lorsque les limites de capacité sont dépassées, l'appel d'ajout de données est rejeté et une exception ProvisionedThroughputExceeded est renvoyée. Si cette situation est liée à une hausse temporaire du débit de données en entrée du flux de données, une nouvelle tentative de la part du producteur de données finira par aboutir à la réalisation des demandes. Si cela est dû à une hausse durable du débit de données en entrée du flux de données, nous vous conseillons d'augmenter le nombre de partitions au sein du flux de données. Vous disposerez ainsi d'une capacité suffisante pour toujours faire aboutir les appels d'ajout de données. Dans les deux cas, vous pouvez examiner les métriques Amazon CloudWatch pour en savoir plus sur la variation du débit de données en entrée du flux de données et sur l'occurrence d'exceptions ProvisionedThroughputExceeded.

En mode alloué, les limites de capacité d'un flux de données Kinesis sont définies en fonction du nombre de partitions présentes dans le flux de données. Les limites peuvent être dépassées par le débit de données ou par le nombre d'appels de lecture de données. Tant que les limites de capacité sont dépassées, les appels de lecture de données sont rejetés avec une exception ProvisionedThroughputExceeded. Si cette situation est liée à une hausse temporaire du débit de données en sortie du flux de données, une nouvelle tentative de la part de l'application Amazon Kinesis finira par aboutir à la réalisation des demandes. Si cela est dû à une hausse durable du débit de données en sortie du flux de données, nous vous conseillons d'augmenter le nombre de partitions. Vous disposerez ainsi d'une capacité suffisante pour toujours faire aboutir les appels de lecture de données. Dans les deux cas, vous pouvez examiner les métriques Amazon CloudWatch pour en savoir plus sur la variation du débit de données en sortie du flux de données et sur l'occurrence d'exceptions ProvisionedThroughputExceeded.

La période de rétention par défaut de 24 heures couvre les scénarios où des retards de traitement intermittents nécessitent un rattrapage par rapport aux données en temps réel. Une rétention de sept jours vous permet de retraiter les données pendant un maximum de sept jours afin de résoudre les éventuelles pertes de données en aval. Une période de conservation des données à long terme de plus de sept jours et jusqu'à 365 jours vous permet de retraiter d'anciennes données pour des cas d'utilisation tels que les tests à rebours d'algorithmes, les remplissages de magasins de données et les audits.

Oui. Vous pouvez utiliser les mêmes API getShardIterator, GetRecords et SubscribeToShard pour lire les données retenues pendant plus de sept jours. Les consommateurs peuvent déplacer l'itérateur à l'emplacement souhaité dans le flux, récupérer la carte des partitions (ouvertes et fermées) et lire les enregistrements.

Oui. Des améliorations ont été apportées aux API ListShards, GetRecords et SubscribeToShard. Vous pouvez utiliser la nouvelle option de filtrage avec le paramètre TimeStamp disponible dans les API ListShards pour extraire efficacement la carte des partitions et améliorer les performances de lecture des données anciennes. Le filtre TimeStamp permet aux applications de découvrir et d'énumérer les partitions à partir du moment où vous souhaitez retraiter les données et éliminer la nécessité de commencer à l'horizon Trim. GetRecords et SubscribeToShards comportent un nouveau champ (ChildShards) qui vous permet de découvrir rapidement les partitions enfant lorsqu'une application termine la lecture des données d'une partition fermée, au lieu de devoir parcourir à nouveau la carte des partitions. La découverte rapide des partitions permet une utilisation efficace des ressources de calcul de l'application consommatrice pour n'importe quelle taille de flux, indépendamment de la période de conservation des données.

Envisagez les améliorations d'API si vous prévoyez de retenir les données plus longtemps et d'adapter régulièrement la capacité de votre flux. Les opérations de mise à l'échelle de flux ferment les partitions existantes et ouvrent de nouvelles partitions enfant. Les données de toutes les partitions ouvertes et fermées sont retenues jusqu'à la fin de la période de rétention. Le nombre total de partitions augmente donc de façon linéaire avec l'allongement de la période de rétention et la multiplication des opérations de mise à l'échelle. Cette augmentation dans la carte de partitions vous oblige à utiliser ListShards avec le filtre TimeStamp et le champ ChildShards dans GetRecords ainsi que l'API SubscribeToShard pour une découverte efficace des partitions en vue de l'extraction de données. Vous allez devoir mettre à niveau votre KCL vers la dernière version (1.x pour les consommateurs standard et 2.x pour les consommateurs en distribution améliorée) pour ces fonctions.

Oui. Les clients de Kinesis Data Streams peuvent utiliser AWS Glue Schema Registry, fonction sans serveur d'AWS Glue, soit via KPL et KCL, soit via les API AWS Glue Schema Registry du kit SDK Java d'AWS. Schema Registry est disponible sans frais supplémentaires. 

Consultez la documentation utilisateur de Schema Registry pour démarrer et pour en savoir plus.

Vous pouvez modifier le débit de votre flux de données de deux façons différentes. Vous pouvez utiliser l'API UpdateShardCount ou la Console de gestion AWS pour mettre à l'échelle le nombre de partitions dans un flux de données. Vous pouvez également modifier le débit d'un flux de données Amazon Kinesis en ajustant le nombre de partitions au sein du flux (repartitionnement).

Le traitement des demandes de mise à l'échelle types prend quelques minutes. Les demandes de dimensionnement plus importantes prennent plus de temps.

Oui. Vous pouvez continuer d'ajouter ou de lire des données au niveau de votre flux de données Kinesis pendant que vous utilisez UpdateShardCount ou que vous procédez à un repartitionnement afin de modifier le débit du flux de données ou lorsque Kinesis Data Streams le fait automatiquement en mode à la demande.

La console de gestion Amazon Kinesis Data Streams affiche les principales métriques opérationnelles et de performances telles que le débit en entrée et en sortie des données de vos flux de données Amazon Kinesis. Kinesis Data Streams s'intègre également à Amazon CloudWatch, ce qui vous permet de récupérer, de consulter et d'analyser les métriques CloudWatch pour vos flux de données et leurs partitions. Pour en savoir plus sur les métriques Kinesis Data Streams, consultez Monitoring Amazon Kinesis Data Streams with Amazon CloudWatch.

Notez que toutes les métriques au niveau des flux sont gratuites. Toutes les métriques activées au niveau des partitions sont facturées selon la tarification Amazon CloudWatch.

Kinesis Data Streams s'intègre à AWS Identity and Access Management (IAM), service qui vous permet de contrôler l'accès des utilisateurs à vos ressources et services AWS de manière sécurisée. Par exemple, vous pouvez créer une politique qui n'autorise qu'un utilisateur ou un groupe spécifique à ajouter des données à votre flux de données. Vous pouvez également associer une politique basée sur les ressources à votre flux de données ou à votre consommateur enregistré afin de contrôler l'accès au niveau des ressources. Pour en savoir plus sur la gestion et le contrôle des accès à votre flux de données, consultez Controlling Access to Amazon Kinesis Data Streams Resources using IAM.

Vous pouvez utiliser la politique IAM basée sur les rôles ou les ressources pour partager l'accès avec un autre compte. Pour partager l'accès avec une fonction AWS Lambda multicompte, associez une politique basée sur les ressources à votre flux de données ou à votre client afin d'autoriser l'accès au rôle d'exécution de la fonction Lambda. Pour en savoir plus, consultez la section Utilisation d'AWS Lambda avec Amazon Kinesis.

Kinesis Data Streams s’intègre à Amazon CloudTrail, un service qui enregistre les appels d’API AWS pour votre compte et vous remet des fichiers journaux. Pour en savoir plus sur la journalisation des appels d’API et pour obtenir la liste des opérations d’API Amazon Kinesis prises en charge, consultez Logging Amazon Kinesis API calls Using Amazon CloudTrail.

Kinesis Data Streams vous permet d'étiqueter vos flux de données Kinesis pour faciliter la gestion des coûts et des ressources. Une étiquette est un libellé défini par l'utilisateur sous forme de paire clé-valeur, destiné à faciliter l'organisation des ressources AWS. Par exemple, vous pouvez étiqueter vos flux de données par centre de coûts, ce qui vous permet de catégoriser et de suivre vos coûts Kinesis Data Streams en fonction des centres de coûts. Pour en savoir plus sur les étiquettes Amazon Kinesis Data Streams, consultez Tagging Your Amazon Kinesis Data Streams.

Amazon Kinesis est sécurisé par défaut. Seuls les propriétaires de comptes et de flux de données ont accès aux ressources Kinesis qu'ils créent. Kinesis prend en charge l'authentification utilisateur pour contrôler l'accès aux données. Vous pouvez utiliser des stratégies IAM pour accorder de façon sélective des autorisations à des utilisateurs et groupes d'utilisateurs. Vous pouvez placer vos données dans Kinesis et les en extraire de manière sécurisée via des points de terminaison SSL en utilisant le protocole HTTPS. Si vous avez besoin d'une sécurité supplémentaire, vous pouvez utiliser le chiffrement côté serveur avec des clés AWS Key Management Service (AWS KMS) pour chiffrer les données stockées dans votre flux de données. AWS KMS vous permet d'utiliser les clés KMS générées par AWS à des fins de chiffrement, ou si vous préférez, vous pouvez utiliser votre propre clé KMS dans AWS KMS. Enfin, vous pouvez utiliser vos propres bibliothèques de chiffrement pour chiffrer les données du côté client avant de les placer dans Kinesis.

Oui. Vous pouvez bénéficier d'un accès privé aux API Kinesis Data Streams à partir de votre Amazon VPC en créant des points de terminaison de VPC. Avec des points de terminaison de VPC, le routage entre le VPC et Kinesis Data Streams est géré par le réseau AWS, sans besoin de passerelle Internet, de passerelle NAT ou de connexion VPN. La dernière génération de points de terminaison de VPC utilisée par Kinesis Data Streams repose sur AWS PrivateLink, technologie qui permet une connectivité privée entre les services AWS utilisant des interfaces réseau Elastic (ENI) avec les adresses IP privées de vos VPC. Pour en savoir plus sur PrivateLink, consultez la documentation sur PrivateLink.

Oui, et cela peut se faire de deux façons différentes. Vous pouvez utiliser le chiffrement côté serveur, qui est une fonction entièrement gérée qui chiffre et déchiffre automatiquement les données à mesure que vous les placez dans un flux de données et que vous les en extrayez. Vous pouvez également écrire vos données chiffrées dans un flux de données en chiffrant et déchiffrant les données côté client.

Vous pouvez préférer le chiffrement côté serveur au chiffrement côté client pour l'une des raisons suivantes :

• Il est difficile d'appliquer le chiffrement côté client.
• Une deuxième couche de sécurité est souhaitée, en plus du chiffrement côté client.
• Il est difficile d'implémenter des programmes de gestion de clés côté client.

Le chiffrement côté serveur pour Kinesis Data Streams chiffre automatiquement les données à l'aide d'une clé AWS KMS spécifiée par l'utilisateur avant de les écrire sur la couche de stockage du flux de données, et les déchiffre après leur extraction du stockage. Le chiffrement rend toute écriture impossible et rend la charge utile et la clé de partition illisibles, sauf si l'utilisateur écrivant ou lisant depuis le flux de données a l'autorisation d'utiliser la clé sélectionnée pour le chiffrement sur le flux de données. Le chiffrement côté serveur peut donc permettre de répondre plus facilement aux exigences internes de sécurité et de conformité qui régissent vos données.

Grâce au chiffrement côté serveur, vos applications côté client (producteurs et consommateurs) n'ont pas besoin d'être conscientes du chiffrement ni de gérer vos clés KMS ou opérations de chiffrement, et vos données sont chiffrées lorsqu'elles sont au repos et en mouvement dans le service Kinesis Data Streams. Toutes les clés KMS utilisées par la fonction de chiffrement côté serveur sont fournies par AWS KMS. AWS KMS permet d'utiliser facilement une clé KMS gérée par AWS pour Kinesis (une méthode de chiffrement « en un clic »), votre propre clé gérée par le client AWS KMS ou une clé KMS que vous avez importée pour le chiffrement.

Oui, vous en trouverez un dans la documentation utilisateur.

C'est probable. Cela dépend de la clé que vous utilisez pour le chiffrement et des autorisations régissant l'accès à la clé.

• Si vous utilisez la clé KMS gérée par AWS pour Kinesis (alias de la clé = aws/kinesis), vos applications ne seront pas impactées par l'activation ou la désactivation du chiffrement avec cette clé.
• Si vous utilisez une clé KMS différente, telle qu'une clé AWS KMS personnalisée ou une clé que vous avez importée dans le service AWS KMS, et si les producteurs et consommateurs d'un flux de données n'ont pas l'autorisation d'utiliser la clé KMS utilisée pour le chiffrement, alors vos requêtes PUT et GET échoueront. Avant de pouvoir utiliser le chiffrement côté serveur, vous devez configurer les stratégies de clé AWS KMS afin d'autoriser le chiffrement et le déchiffrement des messages. Pour consulter des exemples et obtenir des informations complémentaires sur les autorisations AWS KMS, consultez Autorisations d’API AWS KMS : référence des actions et ressources dans le Guide du développeur AWS Key Management Service ou les instructions sur la gestion des autorisations dans la documentation utilisateur sur le chiffrement côté serveur de Kinesis Data Streams.

Oui, mais si vous utilisez la clé KMS gérée par AWS pour Kinesis et que vous ne dépassez pas les coûts d'utilisation d'API KMS de l'offre gratuite d'AWS, l'utilisation du chiffrement côté serveur est gratuite. Voici une description des coûts par ressource :

Clés :

La clé KMS gérée par AWS pour Kinesis (alias = « aws/kinesis ») est gratuite.
Les clés KMS gérées par le client sont soumises aux coûts applicables aux clés KMS. En savoir plus.

Utilisation des API KMS :

Les coûts d'utilisation d'API valent pour chaque clé KMS, y compris celles personnalisées. Kinesis Data Streams appelle KMS environ toutes les cinq minutes lorsqu'il effectue la rotation de la clé de données. Pour un mois de 30 jours, le coût total des appels d'API KMS initiés par un flux de données Kinesis se limite à quelques euros. N'oubliez pas que ces coûts sont fonction du nombre d'informations d'identification utilisateur que vous utilisez au niveau de vos producteurs et consommateurs de données, car chaque information d'identification utilisateur nécessite un appel d'API unique à AWS KMS. Lorsque vous utilisez le rôle IAM pour l'authentification, chaque appel assume-role produit des informations d'identification utilisateur uniques, et vous avez tout intérêt à mettre en cache les informations d'identification utilisateur renvoyées par l'appel assume-role pour limiter les coûts KMS.

Le chiffrement côté serveur Kinesis Data Streams est disponible dans la région AWS GovCloud et dans toutes les régions publiques, à l'exception de la région Chine (Beijing).

Toutes ces opérations peuvent être réalisées à l'aide de la Console de gestion AWS ou du kit SDK AWS. Pour en savoir plus, consultez le Guide de démarrage pour le chiffrement côté serveur Kinesis Data Streams.

Kinesis Data Streams utilise un algorithme AES-GCM 256 pour le chiffrement.

Non. Seules les nouvelles données écrites dans le flux sont chiffrées (ou restent déchiffrées) par la nouvelle application de chiffrement.

Le chiffrement côté serveur chiffre la charge utile du message ainsi que la clé de partition, qui est spécifiée par les applications producteur du flux de données.

Le chiffrement côté serveur est une fonction spécifique à un flux.

Oui, en utilisant la Console de gestion AWS ou le kit SDK AWS, vous pouvez choisir une nouvelle clé KMS et l'appliquer à un flux de données spécifique.

Non. Kinesis Data Streams n'est actuellement pas disponible dans l'offre gratuite d'AWS. L'offre gratuite d'AWS est un programme qui permet d'essayer gratuitement un certain nombre de services AWS. Pour en savoir plus sur l’offre gratuite d’AWS, consultez la page Offre gratuite d’AWS.

Notre SLA Kinesis Data Streams garantit un pourcentage de temps de fonctionnement mensuel d'au moins 99,9 % pour Kinesis Data Streams.

Vous pouvez bénéficier d'un crédit SLA pour Kinesis Data Streams en vertu du SLA Kinesis Data Streams si plusieurs zones de disponibilité dans lesquelles vous exécutez une tâche au sein d'une même région ont un pourcentage de temps de fonctionnement mensuel de moins de 99,9 % au cours d'un cycle de facturation mensuel.

Pour consulter l’intégralité des conditions générales du contrat SLA et pour en savoir plus sur la marche à suivre pour soumettre une demande, consultez Amazon Kinesis Data Streams SLA.

Kinesis Data Streams propose un système simple de paiement à l'utilisation. Vous n'avez rien à payer à l'avance et aucun forfait minimum n'est appliqué ; vous payez uniquement à hauteur des ressources que vous utilisez. Kinesis Data Streams propose deux modes de capacité : à la demande et alloué. Ces deux modes s'accompagnent d'options de facturation spécifiques.

Avec le mode de capacité à la demande, vous n'avez pas besoin de préciser la valeur du débit de lecture et d'écriture que vous attendez pour votre application. Dans ce mode, la tarification est basée sur le volume des données intégrées et extraites et sur des frais horaires pour chaque flux de données présent dans votre compte. Il existe des frais supplémentaires pour les fonctions optionnelles, à savoir la conservation prolongée des données (au-delà des premières 24 heures et dans les limites des sept premiers jours), conservation à long terme des données (au-delà de sept jours et dans les limites d'une année) et la distribution améliorée. Pour en savoir plus sur les coûts liés à Kinesis Data Streams, consultez Tarification d’Amazon Kinesis Data Streams.

Avec le mode de capacité alloué, c'est vous qui précisez le nombre de partitions nécessaires à votre application en fonction de son débit de demandes d'écriture et de lecture. Une partition est une unité de capacité qui offre 1 Mo/seconde de débit d'écriture et 2 Mo/seconde de débit de lecture. Chaque partition vous est facturée à l'heure. Vous êtes également facturé sur les enregistrements qui sont écrits dans votre flux de données Kinesis. Vous vous exposez à des frais supplémentaires si vous utilisez des fonctions optionnelles telles que la rétention prolongée et la distribution améliorée s.

Voici les deux dimensions de base et les trois dimensions optionnelles du mode alloué de Kinesis Data Streams :

• Coût horaire des partitions déterminé par le nombre de partitions incluses dans votre flux de données Amazon Kinesis.
• Des frais correspondant aux unités de charge PUT, dépendant du nombre d'unités de charge de 25 Ko que vos producteurs de données ajoutent à votre flux de données.

Facultatif :

• La rétention de données étendue génère des frais facultatifs déterminés par le nombre d'heures de partition s'appliquant à votre flux de données. Lorsque la rétention prolongée des données est activée, vous payez le taux de rétention prolongée pour chaque partition dans votre flux.
• La conservation à long terme des données est un coût optionnel qui comporte deux dimensions : le stockage des données à long terme et l'extraction des données à long terme. Le stockage des données à long terme reflète le nombre de Go/mois pendant lesquels les données sont stockées sur une période allant de sept jours à 365 jours. L'extraction de données à long terme reflète le nombre de Go de données extraites qui ont été stockées pendant plus de sept jours.
• La distribution améliorée génère des coûts optionnels avec deux dimensions : les heures de partition consommateur et les extractions de données. Les heures de partition consommateur représentent le nombre de partitions dans un flux multiplié par le nombre de consommateurs utilisant la distribution améliorée. Les extractions de données sont déterminées par le nombre de Go fournis aux consommateurs utilisant la distribution améliorée.

Pour en savoir plus sur les coûts liés à Kinesis Data Streams, consultez Tarification d’Amazon Kinesis Data Streams.

Une heure de partition consommateur se calcule en multipliant le nombre de consommateurs de flux enregistrés par le nombre de partitions incluses dans le flux. Vous paierez uniquement en proportion de la durée d'enregistrement du consommateur à la distribution améliorée. Par exemple, si une heure de partition consommateur coûte 0,015 USD pour un flux de données de 10 partitions, le consommateur aura la possibilité de lire les 10 partitions, ce qui représentera des frais horaires de partition consommateur de 0,15 USD par heure (1 consommateur x 10 partitions x 0,015 USD par heure de partition consommateur). Si deux consommateurs sont enregistrés simultanément à la distribution améliorée, le montant facturé pour l'heure de partition consommateur sera de 0,30 USD de l'heure (2 consommateurs x 10 partitions x 0,015 USD).

Kinesis Data Streams et Amazon MSK sont deux plateformes de diffusion de données populaires qui vous aident à créer vos propres charges de travail de streaming qui traitent des données pour des besoins spécifiques. Les deux services sont évolutifs, sécurisés et hautement disponibles. Ils peuvent tous deux être déployés pour exécuter des cas d'utilisation du streaming tels que l'analyse du Web et des journaux en temps réel, la personnalisation de l'expérience client, les architectures pilotées par les événements, l'analyse de l'IoT et la détection des fraudes en temps réel. Lorsque vous choisissez entre les deux, il est important de prendre en compte votre cas d'utilisation et vos exigences spécifiques. Voici quelques facteurs à prendre en compte :

Familiarité

•  Si vous êtes novice en matière de technologies de streaming, utilisez Kinesis Data Streams.
• Si vous avez déjà des applications qui s'exécutent sur Apache Kafka, utilisez MSK. MSK dispose déjà d'un programme de migration Kafka (KMP) et d'un guide de migration pour faciliter l'expérience de migration.

Préférence pour l'open source

• Si vous préférez utiliser les technologies open source, nous vous recommandons d'utiliser MSK. MSK et MSK Connect sont entièrement compatibles avec Apache Kafka et Kafka Connect open source, respectivement.

Kinesis Data Streams permet de traiter en temps réel des données de type Big Data diffusées en streaming. Le service se charge de classer les enregistrements, qui peuvent ensuite être lus et/ou consultés en différé dans l'ordre spécifié à partir de plusieurs applications Amazon Kinesis. La bibliothèque Amazon Kinesis Client Library (KCL) envoie tous les enregistrements associés à une clé de partition donnée vers un même processeur d'enregistrements. Il est ainsi plus simple de créer plusieurs applications ayant accès au même flux de données Kinesis, ce qui peut s'avérer utile pour combiner des tâches de décompte, d'agrégation et de filtrage. Amazon Simple Queue Service (Amazon SQS) propose une file d'attente hébergée, fiable et hautement évolutive pour stocker les messages alors qu'ils se déplacent entre les ordinateurs. Amazon SQS vous permet de déplacer facilement des données entre des composants d'applications distribuées et de développer des applications dans lesquelles les messages sont traités de façon distincte (avec une sémantique de type accusé de réception/échec pour chaque message), notamment grâce à des processus automatisés.

Nous vous recommandons d'utiliser Kinesis Data Streams pour les cas d'utilisation suivants (ou présentant des caractéristiques similaires) :

• Routage d'enregistrements liés vers un même processeur d'enregistrements (comme pour le streaming MapReduce). Acheminer tous les enregistrements correspondant à une clé vers le même processeur d'enregistrements permet notamment de simplifier le décompte et l'agrégation.
• Classement d'enregistrements. Cette fonctionnalité est particulièrement utile si vous souhaitez transférer des données de journaux depuis un hôte d'application vers un hôte de traitement/d'archivage tout en conservant l'ordre des événements des journaux.
• Possibilité d'avoir plusieurs applications utilisant simultanément le même flux. Cela vous permet, par exemple, d'utiliser une application pour mettre à jour un tableau de bord en temps réel, tandis qu'une autre archive les données dans Amazon Redshift. Dans ce cas, les deux applications doivent pouvoir utiliser des données provenant du même flux de manière simultanée et indépendante.
• Possibilité d'utiliser des enregistrements dans le même ordre avec plusieurs heures de décalage. Par exemple, vous disposez d'une application de facturation et d'une application d'audit dont l'exécution est décalée de quelques heures par rapport à celle de l'application de facturation. Dans la mesure où Kinesis Data Streams peut stocker les données pendant un maximum de 365 jours, vous pouvez exécuter l'application d'audit avec un décalage maximum de 365 jours par rapport à l'application de facturation.

Nous recommandons d'utiliser Amazon SQS pour les cas d'utilisation suivants (ou présentant des caractéristiques similaires) :

• Sémantique de messagerie (de type accusé de réception/échec pour chaque message) et délai de visibilité. Par exemple, vous disposez d'une file d'attente d'éléments de travail et souhaitez suivre de manière indépendante l'exécution de chaque élément. Amazon SQS suit les échecs et accusés de réception, si bien que l'application n'a pas à maintenir de point de contrôle/curseur en permanence. Amazon SQS supprime les messages ayant fait l'objet d'un accusé de réception et renvoie les messages non remis au terme d'un délai de visibilité que vous pouvez configurer.
• Envoi à retardement de messages spécifiques. Par exemple, vous disposez d'une file d'attente de tâches et devez lancer certaines tâches en différé. Grâce à Amazon SQS, vous pouvez différer de 15 minutes maximum l'envoi de messages spécifiques.
• Augmentation dynamique de la concurrence/du débit pendant la lecture. Par exemple, vous disposez d'une file d'attente de travail et souhaitez ajouter des lecteurs supplémentaires, le temps que toutes les tâches en attente soient exécutées. Avec Kinesis Data Streams, vous pouvez augmenter le nombre de partitions jusqu'à atteindre un niveau suffisant (notez cependant que vous devrez allouer le nombre de partitions nécessaire à l'avance).
• Utilisation de l'aptitude d'Amazon SQS à effectuer des mises à l'échelle transparentes. Par exemple, vous mettez les demandes en mémoire tampon et la charge évolue par suite de pics de charge occasionnels ou du fait de la croissance naturelle de votre activité. Dans la mesure où chaque requête mise en mémoire tampon peut être traitée séparément, Amazon SQS est en mesure de mettre à l'échelle les capacités de manière transparente afin de faire face à cette charge, sans qu'aucune instruction de votre part ne soit nécessaire.