Kinesis partition avec de nombreux producteurs

Question

J'ai besoin de collecter des données à partir de nombreuses sources de données (par exemple, les téléphones mobiles). Par exemple, 1 000 téléphones, chacun téléchargeant un lot de 1 Mo toutes les 20 minutes. Je pense à utiliser un flux Kinesis avec un seul fragment pour ingérer les données (le débit total est d'environ 1 Mo/s). Est-il logique que les téléphones individuels accèdent directement à l'API Kinesis, ou dois-je mettre en avant ma propre interface (par exemple, serveur Web)? Quelles seraient les principales limites/considérations à garder à l'esprit lors de la prise de cette décision?

P.S. L'alternative à l'utilisation de l'infrastructure AWS IoT serait considérablement plus coûteuse.

Answer 1

Vous devriez avoir un service Web qui reçoit les données de vos clients et les envoie à Kinesis. Ce serveur Web peut utiliser la KPL (Kinesis Producer Library) qui offre les meilleures performances en termes de livraison de messages, de délai d'attente, de réécriture de règles et d'évolutivité. KPL peut créer de nombreux opérateurs et peut être réglé pour optimiser le débit des messages et ne pas dépasser la limite d'écriture imposée par Kinesys Shards. Avoir chaque client qui envoie des données à Kinesis pourrait être une surpuissance en termes de performance, d'entretien et de livraison. Que se passe-t-il si un client commence à envoyer des données à un débit élevé? Un fragment a une limite de débit pour l'opération d'écriture (jusqu'à 1 000 enregistrements/s, taux d'écriture des données jusqu'à 1 Mo/s). Un client "agressif" peut générer un trafic excessif et empêcher un fragment de répondre pendant un certain temps, et bloquer tous les autres clients qui envoient des enregistrements qui doivent être stockés dans le même fragment.

En outre, pensez aux coûts de livraison sur des milliers de clients. Que se passe-t-il si vous voulez changer le nom du flux? ou changer l'accessID/clé? Ou simplement passer du kinésis au kafka? Vous devez gérer la mise à jour de milliers de clients. Avec un serveur Web, vous pouvez masquer la complexité et rendre toute modification transparente pour le client. Vous pouvez penser à exécuter le service Web directement dans EC2. Avoir le producteur directement dans AWS devrait réduire la latence du réseau. De plus, vous pouvez tirer parti de toutes les fonctionnalités d'évolutivité/résilience/tolérance aux pannes offertes par AWS.