Un site web à fort trafic fonctionne sur EC2 et utilise Kinesis Data Streams pour collecter les journaux web. L'application consommateur Kinesis, également sur EC2, prend du retard lorsque les données augmentent et que des enregistrements sont perdus. Quelle solution améliore la gestion du flux avec le moins de frais opérationnels ?

La mise à l'échelle horizontale du consommateur Kinesis avec des instances EC2 et l'utilisation de la métrique GetRecords.IteratorAgeMilliseconds de CloudWatch permettent de s'assurer que le consommateur peut suivre le rythme de l'ingestion des données. Cette métrique indique le retard du consommateur par rapport à la tête du flux. L'augmentation de la période de rétention du flux Kinesis empêche la perte de données en cas de pics de trafic ou de retards prolongés du consommateur, car les données restent disponibles plus longtemps. Cette approche est opérationnellement efficace car elle automatise la mise à l'échelle et prévient la perte de données sans nécessiter de refonte majeure de l'architecture. Les autres options sont moins optimales. Stocker les journaux dans S3 puis utiliser EMR introduit une complexité et un coût supplémentaires pour le traitement en temps quasi réel. Migrer vers Lambda peut être une solution, mais les fonctions Lambda ont des limites de durée d'exécution et de mémoire qui pourraient ne pas être adaptées à un traitement intensif ou prolongé. Ajouter plus de shards augmente la capacité du flux, mais ne résout pas directement le problème du consommateur qui ne peut pas suivre le rythme, et peut entraîner des coûts inutiles si le problème est uniquement du côté du consommateur.