Le Blog Amazon Web Services
Dimensionnez vos flux Amazon Kinesis Data Streams
La capture et l’analyse en temps réel des données vous permet de réagir rapidement à des changements de la demande, de l’engagement client, des événements d’infrastructure, ou tout autre indicateur. Amazon Kinesis est un service entièrement géré par AWS qui vous permet de vous concentrer sur le développement de vos applications, plutôt que sur la gestion de l’infrastructure sous-jacente. La scalabilité est une fonction native du service Amazon Kinesis, qui permet d’ingérer et de traiter des gigaoctets de données par seconde. La réplication automatique des données sur trois zones de disponibilité offre une grande disponibilité et durabilité. Le modèle de facturation est basé sur l’usage et ne nécessite aucun investissement initial, permettant d’optimiser les coûts de vos applications.
Amazon Kinesis Data Streams propose deux modes pour la gestion de la capacité. Avec le mode à la demande, le service gère automatiquement la capacité du flux de données et vous êtes facturé à l’usage réel que vous en faites. Ce mode est préférable pour les traffics fortement variables ou non prédictibles. Avec le mode provisionné, vous indiquez la capacité que vous souhaitez associer au flux de données et vous êtes facturé sur la base de cette capacité. Ce mode est adapté aux applications dont le traffic peut être anticipé.
Avec le mode provisionné, chaque flux de données est composé d’une ou plusieurs partitions (ou “shards” en anglais). Les partitions vous permettent de concevoir et dimensionner vos pipelines de données en fournissant une capacité d’écriture et de lecture prédéfinie. Lorsque l’usage du flux grandit, une application peut lire ou écrire sur une partition à un débit qui dépasse sa capacité, créant une partition chaude et nécessitant que vous ajoutiez de la capacité. Les partitions vous permettent également de traiter en parallèle de grands volumes de données et calculer vos résultats rapidement.
Cet article présente comment dimensionner vos flux de données en mode provisionné et éviter les partitions chaudes. Il présente comment estimer le nombre de partitions nécessaires dans votre flux de données lorsque vous concevez un pipeline. Il détaille ensuite les causes potentielles de partitions chaudes et comment les éviter grâce aux fonctionnalités de redimensionnement d’Amazon Kinesis Data Streams. Il documente enfin les métriques importantes pour la supervision.
Estimer la capacité de votre flux de données
Le schéma ci-dessous présente un pipeline de diffusion de données lié à un jeu vidéo multi-utilisateurs. Amazon Kinesis Data Streams ingère le score des joueurs et d’autres statistiques de jeu en quasi temps réel. Une application permet de filtrer et enrichir les données, et de les écrire dans des tables Amazon DynamoDB qui alimentent les différents tableaux de classement des joueurs du jeu.
Quand vous concevez votre pipeline de diffusion de données, il est important de configurer le flux de données avec assez de capacité pour permettre aux producteurs de données d’ingérer des données et aux consommateurs de les consulter. Vous pouvez ingérer jusque 1Mo par seconde et par partition ou 1000 enregistrements par seconde par partition pour les écritures. La capacité de lecture est de jusque 2Mo par seconde par partition ou cinq transactions de lecture par seconde. Toutes les applications lisant le flux partagent la même capacité de lecture. Vous pouvez utiliser le mode de répartition amélioré (ou “enhanced fan out”) pour augmenter le nombre d’applications consommatrices et vous assurer que chacune dispose d’une connexion dédiée à 2Mo par seconde.
Cet article prend l’application précédente comme exemple. On considère que les producteurs de données créent des enregistrements à un débit de 20Mo par seconde, et que les consommateurs de données doivent traiter ce même volume de données en sortie de flux. En plus de ces débits, c’est une bonne idée d’ajouter une capacité supplémentaire pour offrir une marge de croissance au flux. Cette marge aide aussi votre application à rattraper son retard dans des scénarios qui peuvent retarder ou suspendre le traitement des données, comme :
- le déploiement d’une nouvelle version de l’application ;
- des problèmes réseau ponctuels.
Comme votre application doit rattraper un retard après relance, elle produit ou consomme à un débit plus important, qui nécessite plus de capacité. Pour notre exemple, vous pouvez ajouter 25%, ou 5 partitions, comme marge. Faire varier le nombre de partitions permet d’optimiser vos coûts, mais c’est à vous de décider combien vous voulez en ajouter.
Scenario de redimensionnement
A la sortie du jeu, cette capacité est considérée suffisante pour l’application. L’ingestion et le traitement de données fonctionnent de façon fluide, et les classements de joueurs sont publiés avec des données à jour. Cela fait maintenant quelques semaines que le jeu est sorti : il gagne en popularité et le nombre de joueurs simultanés est en augmentation. Dans un tel scénario, il est important d’avoir une supervision suffisamment complète pour augmenter le débit en redimensionnant le flux.
Le schéma ci-dessous fournit une vue simplifiée de l’usage de métriques Amazon CloudWatch pour superviser vos flux de données et déclencher des opérations de redimensionnement, avec deux options disponibles.
Dans notre exemple, les problèmes de dimensionnement peuvent se manifester lorsque les classements sont mis à jour. Puisque les partitions sont les unités de capacité d’un flux de données, la capacité de chaque partition est indépendante des autres. Si les producteurs de données écrivent sur une seule partition à un débit supérieur à 1Mo par seconde ou 1000 enregistrements par seconde, cette partition devient une partition chaude et les requêtes qui dépassent cette capacité sont rejetées, induisant un délai dans la mise à jour des classements de joueurs. Cette situation peut se produire alors que d’autres partitions du flux sont sous-utilisées et, si vous supervisez la capacité uniquement au niveau du flux de données, vous pouvez ne pas identifier la source du problème, puisque le débit global du flux reste inférieur à sa capacité globale de 25Mo par seconde. Amazon Kinesis vous permet de redimensionner votre flux sans impact et sans interrompre votre pipeline de traitement.
Les concepts principaux autour du dimensionnement
Vous pouvez écrire des enregistrements vers un flux de données en utilisant les APIs de type Put. Pour un seul enregistrement, utilisez PutRecord ; pour plusieurs enregistrements, utilisez PutRecords. Que vous utilisiez l’un ou l’autre, l’appel d’API Kinesis doit inclure les 3 composantes suivantes :
- le nom du flux de données ;
- l’enregistrement à écrire dans le flux. Pour cet article, il s’agit du score d’une partie particulière du jeu ;
- une clé de partitionnement (par exemple l’identifiant de session de jeu).
Le schéma suivant montre plusieurs producteurs de données écrivant vers un flux Kinesis data stream. La clé de partitionnement est utilisée avec une fonction de hachage pour déterminer dans quelle partition un enregistrement sera écrit.
La clé de partitionnement détermine dans quelle partition un enregistrement est écrit. Il s’agit d’une chaîne de caractères Unicode d’une taille maximale de 256 octets. Kinesis passe la clé de partitionnement que vous fournissez dans une fonction de hachage MD5. Le résultat assigne votre enregistrement à une partition spécifique sur le flux, et Kinesis écrit l’enregistrement dans cette partition. Les clés de partitionnement imposent la façon de distribuer les données dans le flux et entre les partitions.
Certains cas d’usage nécessitent de partitionner les données sur un critère spécifique pour un traitement efficace par les applications consommatrices. Par exemple, si vous utilisez l’identifiant joueur pk1234 comme clé de partitionnement, tous les scores associés à ce joueur seront envoyés vers partition 1. L’application consommatrice peut utiliser le fait que les données stockées dans partition 1 ont une affinité avec l’identifiant de joueur et peut calculer le total de points des joueurs efficacement. Une augmentation du trafic liée aux joueurs associés à partition 1 peut conduire à une partition chaude. Kinesis Data streams vous permet de gérer de tels scénarios en découpant ou en regroupant des partitions, sans interrompre votre pipeline de données.
Si vos cas d’usage ne nécessitent pas d’affinité particulière entre les données d’une partition, vous pouvez atteindre un débit global élevé en générant une clé de partitionnement aléatoire dans votre application pour distribuer les données. Les clés de partitionnement aléatoires aident à distribuer les données entrantes équitablement entre toutes les partitions du flux et réduisent le risque qu’une ou plusieurs partitions reçoivent une part disproportionnée des enregistrements du flux. Cette stratégie peut en revanche augmenter la latence du traitement si l’application consommatrice doit traiter des données de plusieurs partitions.
Les mécanismes de redimensionnement d’Amazon Kinesis Data Streams
Le flux reste totalement fonctionnel pendant ces actions. Producteurs et consommateurs peuvent continuer à écrire et à lire dans le flux pendant le processus de redimensionnement.
A la réception d’une requête de redimensionnement, Kinesis positionne le status du flux à Updating . Vous pouvez utiliser l’API DescribeStreams pour vérifier le statut du flux. Quand l’opération est terminée, le statut du flux passe au statut Active.
L’action SplitShard découpe une partition active en deux partitions, augmentant la capacité de lecture et d’écriture du flux. Cela peut être utile si une augmentation du nombre d’enregistrements traités est attendue, ou si plus d’applications consommatrices doivent simultanément traiter la donnée en temps réel.
SplitShard facilite ce processus. L’espace de clés de hachage de la partition parente est aussi découpé. Les deux nouvelles partitions commencent à accepter de nouveaux enregistrements et la partition parente cesse d’en recevoir. Les enregistrements dans la partition parente sont conservés pendant la durée de rétention du flux de données (la configuration par défaut est de 24h, ajustable jusque 365 jours). Vous devez fournir une valeur new-starting-hash-key lorsque vous appelez l’API : cette valeur détermine le point de découpe dans l’espace de clés de hachage de la partition parente. Dans la plupart des cas, vous souhaiterez faire une découpe en parts égales. Néanmoins, vous pouvez avoir besoin de faire une découpe en parts non égales si vous avez des partitions déséquilibrées que vous souhaitez rééquilibrer. Le schéma suivant présente le processus SplitShard en action :
Beaucoup d’applications en streaming de données ont des débits qui varient dans le temps, parfois en suivant une variation quotidienne, hebdomadaire, ou saisonnière. Lorsque vous supervisez le débit de données, vous pouvez identifier des partitions sous-utilisées, qui, si elles étaient regroupées, auraient un débit inférieur aux limites d’une partition, et seraient l’opportunité de réduire les coûts du flux.
L’action MergeShards regroupe deux partitions adjacentes en une seule partition. Deux partitions sont considérées adjacentes si leurs espaces de clés de hachage forment un espace continu. Quand deux partitions sont regroupées, leurs espaces de clés de hachage se regroupent aussi. La nouvelle partition commence à accepter de nouvelles données. Les deux partitions parentes arrêtent d’accepter des enregistrements et conservent les enregistrements existants pendant la période de rétention du flux. Le schéma ci-dessous présente le processus MergeShards en action :
L’action UpdateShardCount est utile lorsque vous devez redimensionner votre flux, à la hausse ou à la baisse, à un nombre spécifique de partitions, et vous fournissez ce nombre à l’appel de l’API. Redimensionner par incréments de 25% de la capacité courante (25%, 50%, 75%, 100%) aide à ce que l’opération soit plus rapide, mais ce n’est pas obligatoire. Cette commande génère la série d’actions SplitShard et MergeShards nécessaire pour atteindre le nombre de partitions que vous avez spécifié. Cette commande découpe les partitions en part équitables, créant des partitions de même taille, et il n’y pas d’option pour choisir un comportement différent.
En plus de cela, l’utilitaire Kinesis Scaling Utility disponible sur GitHub fournit un redimensionnement automatique pour Kinesis Data Streams en supervisant les métriques Amazon CloudWatch du flux et en le redimensionnant à la hausse ou à la baisse en fonction des cas. Il peut ajuster la taille d’un flux par un incrément fixe de partitions ou par un pourcentage total du flux.
Rééquilibrer les partitions
A la fin d’une opération de redimensionnement, vérifiez la distribution de l’espace de clés de hachage de votre flux. Dans la plupart des cas, cet espace de clés doit être équitablement réparti entre les partitions du flux. Les erreurs en calculant ou en saisissant les espaces de clés des partitions peuvent induire des partitions de tailles inhabituelles (très grandes ou très petites). Les plus grandes recevront un nombre trop important de requêtes en lecture et écriture, induisant des requêtes rejetées. Les plus petites seront sous-utilisées.
La sortie de l’API ListShards liste le début et la fin la valeur de clé de hachage pour chaque partition dans le flux. Vous pouvez utiliser ces valeurs pour identifier les partitions déséquilibrées et effectuer les découpes et regroupements nécessaires pour les rééquilibrer. L’outil Kinesis Scaling Utility peut aussi générer un rapport sur l’espace de clés de hachage pour faire ces opérations. Voyez l’example ci-dessous :
Superviser vos flux pour anticiper les partitions chaudes
Comme nous l’avons vu dans le scénario de partition chaude, superviser les flux de données au niveau du flux uniquement ne vous prépare pas aux problèmes au niveau de la partition. Kinesis fournit plusieurs métriques au niveaux flux et partition. Au niveau partition, les métriques IncomingBytes et IncomingRecords vous présentent le débit dans la partition.
Les métriques WriteProvisionedThroughputExceeded et ReadProvisionedThroughputExceeded indiquent respectivement les requêtes Put et Get rejetées. Au niveau flux, gardez un oeil sur PutRecord.Success, qui en moyenne reflète le pourcentage d’appels PutRecord en succès dans le temps. Avec des seuils d’alerte judicieux, ils devraient vous permettre de conduire vos actions de redimensionnement proactivement, en réponse à des changements sur les entrées et sorties de vos flux, et de réduire le risque de partitions chaudes.
L’image ci-dessous présente une capture d’un tableau de bord CloudWatch avec plusieurs métriques sur un flux Kinesis Data Streams :
Conclusion
Cet article vous a présenté comment simplifier le redimensionnement et la supervision de vos flux Amazon Kinesis Data Streams en mode provisionné. Il est important d’analyser les débits attendus pour vos flux et en déduire la capacité appropriée. Choisir une bonne clé de partitionnement vous permet de tirer profit de la capacité que vous provisionnez et d’éviter les partitions chaudes. Superviser les métriques de vos flux et configurer des seuils d’alerte vous donneront la visibilité nécessaire pour faire les meilleurs choix de dimensionnement.
Pour plus d’information, consultez Qu’est-ce que Amazon Kinesis Data Streams ? Pour plus d’information à propos de l’API Kinesis, consultez les actions de l’API.
A propos de l’auteur
Article original d’Ahmed Gaafar, senior technical account manager chez AWS, traduit en français par Nicolas Duriez, Solutions Architect dans les équipes AWS France.