Contexte de l’adoption de Flink SQL
- Parmi les applications basées sur Flink gérées par l’Azar Matching Dev Team, il existait une application legacy lourde utilisant 96 CPU
- Cette application implémentait plusieurs fonctionnalités dans une architecture monolithique, ce qui rendait la maintenance difficile
- Lors d’un travail d’infrastructure, un changement de nœuds d’exécution a provoqué un problème empêchant l’application de fonctionner normalement
- Il a fallu décider s’il fallait continuer à la maintenir au prix d’une forte fatigue opérationnelle, ou la remplacer par une autre approche
Les options possibles
- Les fonctionnalités importantes de l’application existante avaient déjà été implémentées dans une nouvelle application Flink
- La réflexion portait sur la manière de remplacer la partie émission conditionnelle d’événements et exécution de logique
- Implémentation dans une seule application Flink
- Avantage : exploitation simple
- Inconvénient : risque élevé de grossissement de l’application, et en cas d’échec d’une partie, les autres fonctionnalités sont facilement affectées
- Implémentation dans plusieurs applications Flink
- Avantage : gestion indépendante possible
- Inconvénient : la charge augmente avec le nombre d’applications
- Utilisation de Flink SQL
- Avantage : possibilité de définir la logique par des requêtes, avec un seul cluster à gérer
- Inconvénient : expression difficile des logiques complexes, et gestion du cluster délicate si l’on n’y est pas habitué
Pourquoi Flink SQL a été choisi, et comparaison avec les technologies alternatives
- Avant d’adopter Flink SQL, ksqlDB et Spark Structured Streaming ont été évalués
- Raisons du choix de Flink SQL :
- High Availability
- Grâce à Checkpoint et Savepoint, l’état de l’application peut être sauvegardé et restauré de manière fiable
- JobManager peut être configuré en mode HA
- Prise en charge de fonctionnalités de streaming avancées
- De nombreuses fonctionnalités de traitement de streaming sont disponibles via la syntaxe SQL
- Prise en charge des fenêtres, jointures, traitement en event time, watermark, etc.
- Extensibilité via UDF et Custom Connector
- Possibilité d’utiliser des fonctions définies par l’utilisateur et de connecter diverses sources de données et sinks
vs ksqlDB
- Bien qu’inclus dans la plateforme Confluent, son fonctionnement HA est inefficace pour le traitement de streaming stateful
vs Spark Structured Streaming
- Implémenté sur la base du moteur Spark SQL, avec possibilité d’écrire des UDF et des Custom Sink
- Fonctionne en micro-batch, ce qui peut être défavorable au traitement en temps réel
Mise en place de l’environnement de cluster et méthode de déploiement des requêtes
Tester simplement en local
- Présentation d’une méthode pour lancer un Flink Cluster en local et soumettre des requêtes SQL
Architecture du cluster en environnement de production
- Mise en place d’un cluster Flink SQL sur Kubernetes
- Comparaison entre le mode Application et le mode Session
Déploiement des requêtes avec une approche GitOps
- Utilisation de GitHub Actions pour déployer des requêtes et interrompre des jobs
Principaux cas d’exploitation et retours d’expérience en troubleshooting
En cas de défaillance du JobManager ou du TaskManager
- Grâce au paramétrage HA, le JobManager permet de poursuivre le traitement même en cas de fail
- En cas de fail du TaskManager, le travail est redistribué et se poursuit
En cas de fail d’une requête
- Cela peut se produire en cas d’arrivée de données anormales ou de ressources de calcul insuffisantes
- Il est possible d’ignorer les erreurs de format JSON et de définir des valeurs par défaut
Lorsque certains jobs échouent au redémarrage du cluster
- Il faut modifier les paramètres de timeout et de retry
Lorsque l’on souhaite modifier une condition de la requête puis redéployer
- Une restauration de l’état via savepoint n’est possible que pour des modifications simples
Principaux points de monitoring
- Vérification de métriques telles que
numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used
Conclusion
- L’adoption de Flink SQL a amélioré la productivité et l’efficacité opérationnelle
- Excellente stabilité, avec un projet de mise en œuvre du pattern GitOps Controller
1 commentaires
Les systèmes distribués comme Flink doivent maintenir la HA en conservant 2 à 3 racks, et j’ai l’impression que cela a été garanti en l’intégrant à Kubernetes. Mais au final, il faut aussi réfléchir aux ressources des nœuds workers kube, donc je me demande s’ils ont constitué des nœuds dédiés à Flink uniquement (en cas de forte charge Flink, il semble qu’il puisse y avoir des problèmes de panne des nœuds workers).
Dans cette optique, y a-t-il vraiment un avantage à utiliser Kubernetes ?
De plus, quand on utilise des fonctions de fenêtre dans Flink, les données intermédiaires sont conservées en mémoire pour faire fonctionner les jointures SQL ; du point de vue des compromis, je me demande si Flink est vraiment un bon choix. Le problème énorme qui survient si un SQL + job qui grossit avec le temps finit par tomber...
Moi aussi, dans les cas où une jointure est nécessaire tout en haut de la data source, je me demande comment on pourrait traiter cela au niveau applicatif sans utiliser Flink, en le faisant descendre à l’application.