Le service géré Amazon pour Apache Flink était auparavant connu sous le nom d’Amazon Kinesis Data Analytics pour Apache Flink.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Préparez la production de votre service géré pour les applications Apache Flink
Il s’agit d’un ensemble d’aspects importants de l’exécution d’applications de production sur le service géré pour Apache Flink. Il ne s’agit pas d’une liste exhaustive, mais du strict minimum de ce à quoi vous devez faire attention avant de mettre une application en production.
Testez la charge de vos applications
Certains problèmes liés aux applications ne se manifestent que sous une charge importante. Nous avons vu des cas où des applications semblaient saines, mais un événement opérationnel a considérablement amplifié la charge sur l'application. Cela peut se produire de manière totalement indépendante de l'application elle-même. Si la source de données ou le récepteur de données n'est pas disponible pendant quelques heures, l'application Flink ne peut pas progresser. Lorsque ce problème est résolu, un arriéré de données non traitées s'accumule, ce qui peut épuiser complètement les ressources disponibles. La charge peut alors amplifier les bogues ou les problèmes de performance qui n'étaient pas apparus auparavant.
Il est donc essentiel que vous exécutiez des tests de charge appropriés pour les applications de production. Les questions auxquelles il convient de répondre lors de ces tests de charge sont les suivantes :
L’application est-elle stable sous une charge élevée prolongée ?
L’application peut-elle toujours prendre un point de sauvegarde en cas de charge maximale ?
Combien de temps faut-il pour traiter une file d’attente d’une heure ? Et pendant combien de temps pour 24 heures (en fonction de la rétention maximale des données dans le flux) ?
Le débit de l’application augmente-t-il lorsque l’application est mise à l’échelle ?
Lors de la consommation à partir d’un flux de données, ces scénarios peuvent être simulés en les intégrant au flux pendant un certain temps. Lancez ensuite l'application et faites-lui consommer les données depuis le début des temps. Par exemple, utilisez une position de départ égale TRIM_HORIZON à dans le cas d'un flux de données Kinesis.
Définir le parallélisme maximal
Le parallélisme max définit le parallélisme maximal qu’une application avec état peut atteindre. Ceci est défini lorsque l’état est créé pour la première fois et il n’existe aucun moyen de mettre à l’échelle l’opérateur au-delà de ce maximum sans supprimer l’état.
Le parallélisme maximal est défini lorsque l'état est créé pour la première fois.
Par défaut, le parallélisme maximal est défini sur :
128, si le parallélisme est <= 128
MIN(nextPowerOfTwo(parallelism + (parallelism / 2)), 2^15): si le parallélisme est > 128
Si vous prévoyez de dimensionner votre application à une échelle supérieure à 128 parallélisme, vous devez définir explicitement le parallélisme maximal.
Vous pouvez définir le parallélisme maximal au niveau de l'application, avec env.setMaxParallelism(x) ou avec un seul opérateur. Sauf indication contraire, tous les opérateurs héritent du parallélisme maximal de l'application.
Pour plus d'informations, consultez la section Définition du parallélisme maximal
Définissez un UUID pour tous les opérateurs
A UUID est utilisé dans l'opération au cours de laquelle Flink mappe un point de sauvegarde à un opérateur individuel. La définition d'un paramètre spécifique UUID pour chaque opérateur fournit un mappage stable pour le processus de restauration du point de sauvegarde.
.map(...).uid("my-map-function")
Pour plus d’informations, consultez Production Readiness Checklist
