Le 7 octobre 2015, Amazon a annoncé un nouveau service appelé Amazon Kinesis Firehose. Kinesis Firehose est un service de suivi de Kinesis publié il y a deux ans. Afin d'éviter toute ambiguïté, le service Kinesis original a été renommé Amazon Kinesis Streams.
Amazon Kinesis Firehose est un service géré qui requiert peu d'administration et qui permet de diffuser des données applicatives, de télémétrie ou de log vers Amazon S3 (Simple Storage Service) ou Amazon Redshift sans nécessiter de code spécifique.
Source de l'image : Capture d'écran https://www.youtube.com/watch?v=YQR_5W4XC94
Roger Barga, Directeur Général pour Amazon Kinesis, décompose l'Amazonie Kinesis Firehose en trois concepts :
- Les flux de livraison sont configurés pour identifier la destination pour le flux de données qui doit être traité.
- Les enregistrements se réfèrent aux données qu'un éditeur mettra à disposition du flux de livraison sous la forme d'un blob de données. Les blobs de données peuvent aller jusqu'à 1000 Ko.
- Les producteurs de données, ou éditeurs, rendront les enregistrements disponibles pour le flux de livraison comme un serveur web envoyant des données de log.
Le service est prévu pour des scénarios orientés batch où les données sont persistées, ou concaténées, entre 60 secondes et 15 minutes avant d'être ingérées. Les administrateurs contrôlent la taille et l'intervalle du tampon qui détermine la fréquence à laquelle ces données se déplacent. L'image suivante décrit comment ces paramètres d'entrée peuvent être gérés.
Source de l'image : https://aws.amazon.com/blogs/aws/amazon-kinesis-firehose-simple-highly-scalable-data-ingestion/
La compression et le cryptage sont également des fonctionnalités du service prises en charge, en profitant de la compression gzip et du chiffrement via KMS d'Amazon (Service de Gestion de Clés). L'utilisation d'un service de sécurité centralisé signifie que d'autres services peuvent également décrypter ces données en utilisant les clés Amazon.
Tout comme les autres services Amazon, Kinesis Firehose fournit des capacités d'auto-scale qui nécessitent peu d'administration. Il fournit également des fonctionnalités avancées, y compris la rotation de fichiers, la vérification via l'Agent Kinesis et les tentatives qui permettent de persister des données jusqu'à 24 heures si un compartiment S3 est indisponible.
Le but de Kinesis Firehose est de permettre une expérience de configuration sans code pour les administrateurs. Mais, pour les scénarios les plus avancés, les développeurs sont en mesure de profiter de l'API Kinesis Firehose qui peut être intégrée dans leurs applications. L'API fournit des opérations telles que :
- CreateDeliveryStream - Création d'un flux de livraison en fournissant les informations concernant le compartiment S3 auquel les données seront livrées.
- DeleteDeliveryStream - Suppression d'un flux de livraison.
- DescribeDeliveryStream - Retour d'information de configuration sur un flux de livraison.
- ListDeliveryStreams - Enumération de tous les flux de livraison disponibles sur le compte AWS.
- UpdateDestination - Mise à jour de la configuration de compartiment S3 pour un flux de livraison.
- PutRecord - Placement d'un enregistrement de données unique jusqu'à 1 000 Ko dans un flux de livraison.
- PutRecord Batch - Placement d'un lot d'enregistrements (500 dossiers ou 5MBs) dans un flux de livraison.
Amazon a fourni à ses clients une console unifiée qui permet aux organisations de gérer à la fois Kinesis Firehose et des Flux dans le même outil. Pour les clients qui peuvent être déjà familiers avec Amazon Kinesis Streams, il existe quelques différences importantes entre les deux services. Amazon classifie les deux systèmes de la manière suivante :
- Amazon Kinesis Streams est un service pour les charges de travail qui nécessitent un traitement personnalisé, par enregistrement entrant, avec une latence de traitement sous la seconde et un choix de frameworks pour traiter les flux.
- Amazon Kinesis Firehose - un service pour les charges de travail qui ne nécessitent aucune administration, la capacité d'utiliser des outils d'analyse existants basés sur S3 ou Redshift et un temps de latence de données de 60 secondes ou plus.