En prévision de notre Moscou Python Conf ++, nous avons brièvement discuté avec Oleg Churkin, un technicien de la startup fintech, de sa vaste expérience avec le céleri: un demi-million de tâches en arrière-plan, des bugs et des tests.
- Dites-moi quelques détails sur le projet sur lequel vous travaillez actuellement?En ce moment, je suis engagé dans une startup
fintech Statusmoney , qui analyse les données financières des utilisateurs et permet aux clients de comparer leurs revenus et leurs dépenses avec d'autres groupes de personnes, de fixer des limites de dépenses, de voir comment la richesse augmente ou diminue sur les graphiques. Jusqu'à présent, le projet se concentre uniquement sur le marché nord-américain.
Pour analyser les informations financières, nous téléchargeons et stockons toutes les transactions des utilisateurs et les intégrons aux bureaux de crédit pour obtenir des données supplémentaires sur l'historique de crédit.
Nous avons maintenant environ 200 000 utilisateurs et 1,5 téraoctets de diverses données financières de nos fournisseurs. Environ un million de transactions
- Quelle est la pile technologique?La pile du projet en cours est Python 3.6, Django / Celery et Amazon Web Services. Nous utilisons activement RDS et Aurora pour stocker des données relationnelles, ElasticCache pour le cache et pour les files d'attente de messages, CloudWatch, Prometheus et Grafana pour les alertes et la surveillance. Eh bien et, bien sûr, S3 pour le stockage de fichiers.
Nous sommes également très actifs dans l'utilisation de Celery pour diverses tâches commerciales: envoi de notifications et envoi massif de lettres, mise à jour en masse de diverses données de services externes, API asynchrone et similaires.
À l'avant, nous avons React, Redux et TypeScript.
- Quelle est la nature principale des charges dans votre projet et comment les traitez-vous
vous débrouillez-vous?Le principal fardeau du projet réside dans les tâches d'arrière-plan effectuées par Celery. Chaque jour, nous lançons environ un demi-million de tâches différentes, par exemple, la mise à jour et le traitement (ETL) des données financières des utilisateurs de diverses banques, agences de crédit et institutions d'investissement. De plus, nous envoyons de nombreuses notifications et calculons de nombreux paramètres pour chaque utilisateur.
Nous avons également implémenté une API asynchrone, qui «impulse» les résultats de sources externes et génère également de nombreuses tâches.
Pour le moment, après avoir réglé l'infrastructure et le céleri, nous pouvons faire face sans problème, mais avant que cela ne se produise, je vous en parlerai certainement dans mon rapport.
- Comment dimensionnez-vous tout cela et offrez-vous une tolérance aux pannes?Pour la mise à l'échelle, nous utilisons les groupes de mise à l'échelle automatique, une boîte à outils fournie par notre plateforme cloud AWS. Django et Celery évoluent bien horizontalement, nous ne fixons qu'un peu les limites sur la quantité maximale de mémoire utilisée par les travailleurs uWSGI / Celery.
- Et surveiller avec quoi?Pour surveiller l'utilisation du processeur / de la mémoire et la disponibilité des systèmes eux-mêmes, nous utilisons Cloud Watch dans AWS, nous agrégons diverses mesures de l'application et des travailleurs de Celery utilisant Prometheus, et nous créons des graphiques et envoyons des alertes à Grafana. Pour certaines données de Grafana, nous utilisons ELK comme source.
- Vous avez mentionné l'API asynchrone. Dites-en un peu plus sur la façon dont vous l'avez.
arrangé.Nos utilisateurs ont la possibilité de «lier» leur compte bancaire (ou tout autre compte financier) et de nous donner accès à toutes leurs transactions. Nous affichons le processus de «liaison» et de traitement dynamique des transactions sur le site, pour cela nous utilisons la mise en commun habituelle des résultats actuels du backend, et le backend prend les données, démarrant le pipeline ETL à partir de plusieurs tâches répétitives.
- Le céleri est un produit controversé. Comment vivez-vous avec lui?Selon mes sentiments, notre relation avec Celery est maintenant au stade «Acceptation» - nous avons compris comment le cadre fonctionne à l'intérieur, choisi les paramètres pour nous-mêmes, trié le déploiement, «superposé» à la surveillance et écrit plusieurs bibliothèques pour automatiser les tâches de routine. Certaines fonctionnalités n'étaient pas suffisantes pour nous «prêtes à l'emploi», et nous les avons ajoutées par nous-mêmes. Malheureusement, au moment de choisir la pile technologique pour le projet, Celery n'avait pas beaucoup de concurrents, et si nous utilisions des solutions plus simples, nous devions en ajouter beaucoup plus.
Nous n'avons jamais rencontré de bugs dans la quatrième version de Celery. La plupart des problèmes étaient liés soit à notre manque de compréhension du fonctionnement de tout cela, soit à des facteurs tiers.
Je parlerai de quelques bibliothèques écrites dans notre projet dans ma présentation.
- Ma question préférée. Comment testez-vous toute cette musique?Les tâches de céleri sont bien testées par des tests fonctionnels. Nous testons l'intégration à l'aide de tests automatiques et de tests manuels sur des supports d'assurance qualité et de la mise en scène. Pour le moment, nous n'avons pas encore résolu quelques problèmes avec les tests de tâches périodiques: comment laisser les testeurs les exécuter et comment vérifier que le calendrier de ces tâches est correct (répond aux exigences)?
- Et les tests pour le frontend et la mise en page? Quel est le rapport du manuel au
tests automatisés?À l'avant, nous utilisons Jest et écrivons uniquement des tests unitaires pour la logique métier. 55% de nos cas critiques sont désormais couverts par des auto-tests Selenium, actuellement nous avons environ 600 tests dans TestRail et 3 000 tests sur le backend.
- Quel sera votre rapport sur Moscow Python Conf ++?Dans le
rapport, je vais vous dire en détail quelles tâches et comment vous pouvez utiliser le céleri, et le comparer avec les concurrents existants. Je décrirai comment éviter divers râteaux lors de la conception d'un système complexe avec un grand nombre de tâches: quels paramètres doivent être spécifiés immédiatement et qui peuvent être laissés pour plus tard, comment déployer une nouvelle version du code afin de ne pas perdre de tâches lors du changement de trafic, je partagerai des bibliothèques écrites pour les tâches de surveillance et éclate.
J'aborderai également le sujet de la mise en œuvre des pipelines ETL sur Celery et répondrai comment les décrire magnifiquement, quelle politique de nouvelle tentative utiliser, comment limiter de manière granulaire le nombre de tâches effectuées dans des conditions de ressources limitées. De plus, je vais décrire les outils que nous utilisons pour implémenter le traitement par lots des tâches, ce qui consomme économiquement de la mémoire disponible.
En général, si vous avez envie de détails pour tous les points ci-dessus, venez. J'espère que vous trouverez mon rapport utile et intéressant.