Mit Lilt Connectors können unsere Kunden Inhalte auf ihren bevorzugten Systemen wie WordPress Blog-Posts oder Zendesk Support Wikis behalten und Lilt hinter den Kulissen für die Übersetzung verwenden. Inhalte werden nach Lilt importiert und nach Abschluss der Übersetzung wieder in das ursprüngliche System exportiert. Import und Export erfolgen nahtlos. Und diese Effizienz spielt eine wichtige Rolle dabei, Lilt zu helfen, Informationen weltweit zugänglicher zu machen.
Lilt bietet derzeit Connectors für mehr als 15 verschiedene Systeme an. Unsere Kunden setzen für ihren Lokalisierungs-Workflow stark auf Lilt Connectors. Im Jahr 2021 wurden fast 90 % aller auf der Lilt-Plattform übersetzten Inhalte per Connector erstellt!
Unsere Connector-Architektur war aber nicht immer so konzipiert, dass sie das wahnsinnig große Volumen, das sie zurzeit bewältigt, unterstützen konnte. Dieser Artikel enthält eine Beschreibung, wie Lilt mit Argo Workflows das Connector-Framework skaliert, sodass es zum größten Unternehmensangebot von heute werden konnte.
Als Lilt noch in den Kinderschuhen steckte, wurde jeder Connector in seinem eigenen Github-Repository implementiert, von verschiedenen Ingenieuren entwickelt und wirkte mit Lilt über separate Datenbanken und Schemata auf nuancierte Art und Weise zusammen. Mit allen Änderungen an unserer API gingen Aktualisierungen der Codebase an mehreren Stellen einher. Darüber hinaus gehörte zu jedem Connector ein besonderes Bug-Set, das schwierig zu verfolgen und zu reparieren war. Stellen Sie sich vor, der Ingenieur zu sein, der mehrere Connectors warten muss. Oje!
💡 Nebenbei bemerkt: Zendesk war unser allererster Connector und wurde Anfang 2019 freigegeben.
Als Lilt sein Connectors-Angebot ausbaute, wurde des offensichtlich, dass dieses Modell nicht skaliert werden könnte. Daher haben wir unser Connectors Framework über einen zentralen Code vereinheitlicht und so konfiguriert, dass es unabhängig von dem System, an das es angeschlossen war, auf dieselbe Art und Weise ausgeführt werden konnte. Sobald sich der Code in einem Repository befand, fingen wir damit an, native Kubernetes-Aufträge zu verwalten und alle Connector-Aufträge auszuführen.
Das war ein enormer Schritt nach vorn im Vergleich zu unserer vorherigen Implementierung. Und viel effizienter. Und dann gab es ein neues Skalierungsproblem. Obwohl Kubernetes selbst zuverlässig war, hatten wir Ressourcenbeschränkungen, die zu Zuverlässigkeitsproblemen führten.
- Dokumente werden nach einem bestimmten Zeitplan importiert und aus Lilt exportiert. Wir haben den Management-Server mit einem Zeitplan konfiguriert, aber Kubernetes plante häufig zu viele Aufträge auf einmal ein (d. h. 50 in einer Millisekunde), was den Clusterspeicher erschöpfte und dazu führte, dass Aufträge regelrecht fallengelassen wurden und verloren gingen.
- Neue Aufträge wurden verzögert und konnten aufgrund mangelnder Speicherkapazität nicht eingereicht werden.
- Wir führen Kubernetes auf der Google Kubernetes Engine (GKE) aus. Die Konfiguration sah die Ausgabe von Anwendungsprotokollen in Stackdriver vor, aber die Protokolle waren ohne Plan und verwirrend.
- Die manuelle Filterung von Protokollen in Stackdriver war zeitaufwändig und umständlich. Aber wenn wir die Ursache für die ausgefallenen Aufträge ermitteln wollten, mussten wir so vorgehen.
- Kubernetes war keine optimale Lösung fürs Aussortieren. Wir waren für die Löschung abgeschlossener Aufträge und Pods verantwortlich und mussten zudem einen separaten Code für diese Schritte implementieren.
Angesichts dieser Probleme befanden wir uns in derselben Zwickmühle wie früher: Wir brauchten eine bessere Lösung oder eine Skalierung war nicht möglich!
Während wir Lösungen für eine Neugestaltung unserer Connectors-Architektur bewerteten, kamen auch Airflow und Prefect in Betracht, aber weder das eine noch das andere System konnte eine native Kubernetes-Unterstützung bieten. Letztendlich wollten wir etwas auf Kubernetes aufbauen und Argo Workflows übernimmt hier die Container-basierte Auftragsverwaltung für Kubernetes. Zudem half es uns, dank dieser Funktionen unsere Probleme mit der Skalierung zu lösen:
- Argo erfasst mehr Informationen zu jeder Ausführung als Stackdriver, sodass wir Fehler bei Aufträgen schneller debuggen können.
- Von Anfang an unterstützt Argo das Speichern von Protokollen. Wir mussten nur noch festlegen, wo sie gespeichert werden sollten.
- Argo zeichnet unsere Workflows auf, sodass wir noch mehr Protokolle und Transparenz haben.
- Mit Argot können wir Parallelismen definieren. Wenn wir 100 Aufträge haben, führt Argo 5 auf einmal aus und jeden Auftrag erst dann, wenn der vorherige abgeschlossen ist. So lässt sich die Zuverlässigkeit erheblich verbessern und die Probleme mit der Zeitplanung, die mit Kubernetes Jobs alleine entstanden, entfallen.
- Argo verwendet cron-Workflows in Verbindung mit Kubernetes, um Aufträge entsprechend den erforderlichen Ressourcen zu planen und auszuführen. Unser Scheduler läuft direkt über Argo.
- Die Skalierung erfolgt mühelos. Wenn das Volumen zunimmt, steigern wir einfach die Kubernetes-Ressourcen in der Google Cloud Platform (GCP) für Argo, um diese zu nutzen.
- Argo verfügt über Möglichkeiten, alte oder ungenutzte Daten aufzuräumen, damit wir abgeschlossene Aufträge besser verwalten können.
- Argo ist die „Workflow-Engine für Kubernetes“. Das heißt, wir müssen die Container-Orchestrierungstools nicht umstellen.
- Die Integration in unsere Architektur erforderte keine Codeänderungen, sodass wir den Code aus unserem zentralen Repository weiterhin ausführen können.
- Die Einrichtung musste minimal vorbereitet werden. Wir mussten nur die Workflow-Konfiguration von Argo in einer YAML-Datei angeben.
Mit der Einführung von Argo umfassen unsere Connector-Services jetzt drei Hauptkomponenten:
Das Connectors-Admin-Panel ist die Benutzeroberfläche für den Management-Server. Sie liefert die Schnittstelle für Benutzer zur Erfüllung der Aufgaben. Der Management-Server ist mit unserer Datenbank verbunden und unterstützt CRUD-Operationen für Konfigurationen und Aufträge, wie das Erstellen und Aktualisieren von Connector-Konfigurationen und die Überwachung der Abläufe sowie die Protokollierung der laufenden Aufträge. All diese Vorgänge und Informationen können vom Benutzer über das Connectors-Admin-Panel abgerufen werden.
Argo ist der Ausführungsserver, der mit einem lokalen Kubernetes verbunden ist. Mit unserer modernisierten Architektur werden Aufträge jetzt vom Management-Server direkt an Argo und nicht (erst) an Kubernetes übermittelt. Alle Interaktionen mit Argo vom Management-Server erfolgen über die REST-API von Argo.
Obwohl jeder Connector anders ist, werden sie alle auf die gleiche Weise ausgeführt. Für Kunden mit besonderen Anforderungen hinsichtlich ihrer Lokalisierungs-Workflows können wir unseren Connector-Admin-Panel verwenden, um angeben zu können, wie die jeweiligen Inhalte verarbeitet werden sollen, wenn Aufträge ausgeführt werden und Inhalte auf oder von der Lilt-Plattform übertragen werden.
Wir haben Argo Workflows Anfang 2021 implementiert. Mit der Einführung konnten wir unsere Software dahingehend skalieren, dass sie das hohe Volumen unterstützt, das wir heute verarbeiten. Seit Argo ist die Anzahl der Dokumente, die wir in Lilt über einen Connector importieren um mehr als 870 % gestiegen. Wir gehen davon aus, dass diese Zahl weiter steigt, während wir die Integration von Argo in unser Connectors Framework fortsetzen.