Sellerie in geschäftigen Projekten: ein wenig Übung

Am Vorabend unseres Moscow Python Conf ++ sprachen wir kurz mit Oleg Churkin, einem Techniker des Fintech-Startups, über seine umfangreichen Erfahrungen mit Sellerie: eine halbe Million Hintergrundaufgaben, Fehler und Tests.



- Erzählen Sie mir ein paar Details zu dem Projekt, an dem Sie gerade arbeiten?

Im Moment bin ich an einem Fintech-Startup namens Statusmoney beteiligt , das Finanzdaten von Benutzern analysiert und es Kunden ermöglicht, ihre Einnahmen und Ausgaben mit anderen Personengruppen zu vergleichen, Ausgabenlimits festzulegen und zu beobachten, wie der Wohlstand in den Charts wächst oder fällt. Bisher konzentriert sich das Projekt nur auf den nordamerikanischen Markt.

Um Finanzinformationen zu analysieren, laden wir alle Benutzertransaktionen herunter, speichern sie und integrieren sie in Kreditbüros, um zusätzliche Daten zur Bonitätshistorie zu erhalten.

Jetzt haben wir ungefähr 200.000 Benutzer und 1,5 Terabyte verschiedener Finanzdaten von unseren Lieferanten. Über eine Million Transaktionen

- Was ist der technologische Stack?

Der Stack des aktuellen Projekts ist Python 3.6, Django / Celery und Amazon Web Services. Wir verwenden RDS und Aurora aktiv zum Speichern relationaler Daten, ElasticCache für den Cache und für Nachrichtenwarteschlangen, CloudWatch, Prometheus und Grafana für die Alarmierung und Überwachung. Nun und natürlich S3 für die Dateispeicherung.

Wir setzen Sellerie auch sehr aktiv für verschiedene Geschäftsaufgaben ein: Versenden von Benachrichtigungen und Massenversand von Briefen, Massenaktualisierung verschiedener Daten von externen Diensten, asynchrone API und dergleichen.

Am Frontend haben wir React, Redux und TypeScript.

- Was ist die Hauptnatur der Lasten in Ihrem Projekt und wie gehen Sie damit um?
kommst du zurecht

Die Hauptlast des Projekts liegt in den Hintergrundaufgaben, die Sellerie ausführt. Jeden Tag starten wir ungefähr eine halbe Million verschiedene Aufgaben, zum Beispiel die Aktualisierung und Verarbeitung (ETL) von Finanzdaten von Benutzern verschiedener Banken, Kreditbüros und Investmentinstitutionen. Zusätzlich senden wir viele Benachrichtigungen und berechnen viele Parameter für jeden Benutzer.

Wir haben auch eine asynchrone API implementiert, die die Ergebnisse von externen Quellen „pulsiert“ und auch viele Aufgaben generiert.

Im Moment, nachdem wir die Infrastruktur und den Sellerie optimiert haben, können wir problemlos damit umgehen, aber bevor es passiert ist, werde ich Ihnen dies in meinem Bericht mitteilen.

- Wie skalieren Sie alles und sorgen für Fehlertoleranz?

Für die Skalierung verwenden wir Auto Scaling Groups, eine Toolbox, die von unserer AWS Cloud-Plattform bereitgestellt wird. Django und Sellerie lassen sich horizontal gut skalieren. Wir setzen die Grenzwerte für die maximale Speichermenge, die von uWSGI / Sellerie-Mitarbeitern verwendet wird, nur ein wenig.

- Und womit überwachen?

Um die CPU- / Speichernutzung und die Verfügbarkeit der Systeme selbst zu überwachen, verwenden wir Cloud Watch in AWS, aggregieren verschiedene Metriken aus der Anwendung und von Sellerie-Mitarbeitern mithilfe von Prometheus, erstellen Diagramme und senden Warnungen an Grafana. Für einige Daten in Grafana verwenden wir ELK als Quelle.

- Sie haben die asynchrone API erwähnt. Erzählen Sie etwas mehr darüber, wie Sie es haben.
arrangiert.

Unsere Benutzer haben die Möglichkeit, ihr Bankkonto (oder ein anderes Finanzkonto) zu "verknüpfen" und uns Zugriff auf alle ihre Transaktionen zu gewähren. Wir zeigen den Prozess des „Verknüpfens“ und dynamischen Verarbeitens von Transaktionen auf der Site an. Dazu verwenden wir die übliche Zusammenfassung der aktuellen Ergebnisse aus dem Backend. Das Backend nimmt Daten auf und startet die ETL-Pipeline mit mehreren sich wiederholenden Aufgaben.

- Sellerie ist ein umstrittenes Produkt. Wie lebst du mit ihm?

Meiner Meinung nach befindet sich unsere Beziehung zu Sellerie jetzt in der Phase „Akzeptanz“. Wir haben herausgefunden, wie das Framework im Inneren funktioniert, Einstellungen für uns selbst vorgenommen, die Bereitstellung sortiert, die Überwachung „überlagert“ und mehrere Bibliotheken geschrieben, um Routineaufgaben zu automatisieren. Einige Funktionen reichten uns nicht "out of the box", und wir haben sie selbst hinzugefügt. Leider hatte Sellerie zum Zeitpunkt der Auswahl des Technologie-Stacks für das Projekt nicht viele Konkurrenten, und wenn wir einfachere Lösungen verwenden würden, müssten wir viel mehr hinzufügen.

In der vierten Version von Sellerie sind wir noch nie auf Fehler gestoßen. Die meisten Probleme waren entweder auf unser Unverständnis darüber zurückzuführen, wie dies alles funktioniert, oder auf Faktoren von Drittanbietern.

Ich werde in meiner Präsentation über einige Bibliotheken sprechen, die in unserem Projekt geschrieben wurden.

- Meine Lieblingsfrage. Wie testest du all diese Musik?

Sellerie-Aufgaben werden durch Funktionstests gut getestet. Wir testen die Integration mit Hilfe von automatischen Tests und manuellen Tests an QS-Ständen und Staging. Im Moment haben wir noch einige Probleme beim Testen von regelmäßigen Aufgaben nicht gelöst: Wie lassen Sie Tester sie ausführen und wie überprüfen Sie, ob der Zeitplan für diese Aufgaben korrekt ist (die Anforderungen erfüllt)?

- Und die Tests für Frontend und Layout? Wie ist das Verhältnis von manuell zu
automatisiertes Testen?

Im Vordergrund verwenden wir Jest und schreiben nur Unit-Tests für die Geschäftslogik. 55% unserer geschäftskritischen Fälle werden derzeit durch Selenium-Selbsttests abgedeckt. Derzeit haben wir etwa 600 Tests in TestRail und 3.000 Tests im Backend.



- Worum geht es in Ihrem Bericht über Moscow Python Conf ++?

Im Bericht werde ich Ihnen detailliert erläutern, welche Aufgaben und wie Sie Sellerie verwenden können, und es mit bestehenden Wettbewerbern vergleichen. Ich werde beschreiben, wie Sie beim Entwerfen eines komplexen Systems mit einer großen Anzahl von Aufgaben verschiedene Rechen vermeiden können: Welche Einstellungen sollten sofort festgelegt werden und welche können später beibehalten werden, wie eine neue Version des Codes bereitgestellt wird, um beim Wechseln des Datenverkehrs keine Aufgaben zu verlieren. Ich werde schriftliche Bibliotheken für Überwachungsaufgaben freigeben und platzt.

Ich werde auch auf das Thema der Implementierung von ETL-Pipelines auf Sellerie eingehen und beantworten, wie diese schön beschrieben werden können, welche Wiederholungsrichtlinie verwendet werden soll und wie die Anzahl der unter Bedingungen begrenzter Ressourcen ausgeführten Aufgaben genau begrenzt werden kann. Außerdem beschreibe ich, mit welchen Tools wir die Stapelverarbeitung von Aufgaben implementieren, wodurch der verfügbare Speicher wirtschaftlich verbraucht wird.

Wenn Sie sich nach Details für alle oben genannten Punkte sehnen, kommen Sie im Allgemeinen. Ich hoffe, Sie finden meinen Bericht nützlich und interessant.