Ein zuverlässiger Systembetrieb ist eine Voraussetzung für jede ernstzunehmende Integrationsplattform als Dienst (iPaaS). Oft wird Zuverlässigkeit oder Fehlertoleranz als Merkmal aufgeführt, aber es ist schwer zu erkennen, was dies in der Praxis bedeutet. Für ein Datenintegrationsprojekt kann die Zuverlässigkeit eine Herausforderung sein, da es unterschiedliche externe Dienste verbinden muss, die von sich aus ausfallen. In einem früheren Blog-Beitrag haben wir erörtert, wie SnapLogic Integration Cloud-Pipelines aufgebaut werden können, um Endpunktausfälle mit unserem garantierten Bereitstellungsmechanismus zu verwalten. In diesem Beitrag werden wir uns einige der Techniken ansehen, die wir verwenden, um die zuverlässige Ausführung der von uns kontrollierten Services sicherzustellen.
Wir unterteilen die SnapLogic-Architektur grob in zwei Kategorien: die Datenebene und die Steuerungsebene. Die Datenebene ist in einem Snaplex gekapselt und die Steuerebene besteht aus einer Reihe replizierter verteilter Server. Diese Trennung ist sowohl für die Datenisolierung als auch für die Zuverlässigkeit nützlich, da wir in den beiden Ebenen problemlos verschiedene Ansätze zur Fehlertoleranz anwenden können.
Datenebene: Snaplex und Pipeline-Redundanz
Der Snaplex ist ein Cluster aus einem oder mehreren Pipeline-Ausführungsknoten. Ein Snaplex kann sich sowohl in der SnapLogic Integration Cloud als auch vor Ort befinden. Der Snaplex ist so konzipiert, dass er bei erhöhter Pipeline-Last eine automatische Skalierung unterstützt. Darüber hinaus überwacht das Monitoring Dashboard den Zustand aller Snaplex-Knoten. Auf diese Weise kann der Ausfall eines Snaplex-Knotens frühzeitig erkannt werden, so dass zukünftige Pipelines nicht auf dem fehlerhaften Knoten geplant werden. Bei Cloud-basierten Snaplexes, auch Cloudplexes genannt, werden Knotenausfälle automatisch erkannt und Ersatzknoten nahtlos zur Verfügung gestellt. Bei vor Ort installierten Snaplexes, auch Groundplexes genannt, werden die Verwaltungsbenutzer über den fehlerhaften Knoten benachrichtigt, damit ein Ersatzknoten bereitgestellt werden kann.
Wenn ein Snaplex-Knoten während der Ausführung einer Pipeline ausfällt, wird die Pipeline als fehlgeschlagen markiert. Entwickler haben die Möglichkeit, fehlgeschlagene Pipelines zu wiederholen, oder in einigen Fällen, z. B. bei wiederkehrenden geplanten Pipelines, kann der fehlgeschlagene Lauf ignoriert werden. Die Aufteilung lang laufender Pipelines in mehrere kürzere Pipelines kann das Risiko eines Knotenausfalls verringern. Für hochkritische Integrationen ist es möglich, replizierte Pipelines gleichzeitig zu erstellen und auszuführen. Auf diese Weise wird die Integration nicht durch einen einzigen ausgefallenen Replikator unterbrochen. Alternativ kann eine Pipeline erstellt werden, um Daten im SnapLogic File System (SLFS) oder in einem alternativen Datenspeicher wie AWS S3 bereitzustellen. Die Bereitstellung von Daten kann die Notwendigkeit verringern, Daten erneut von einer Datenquelle abzurufen, z. B. wenn eine Datenquelle wie AWS Glacier langsam ist. Außerdem haben einige Datenquellen höhere Übertragungskosten oder Übertragungslimits, die eine mehrfache Datenanforderung bei Ausfällen des vorgelagerten Endpunkts in einer Pipeline unrentabel machen würden.
Steuerungsebene: Service-Zuverlässigkeit
Die "Steuerungsebene" von SnapLogic befindet sich in der SnapLogic Integration Cloud, die in AWS gehostet wird. Durch die Entkopplung von Steuerung und Datenverarbeitung bieten wir differenzierte Ansätze für die Zuverlässigkeit. Alle Dienste der Steuerebene werden sowohl aus Gründen der Skalierbarkeit als auch der Zuverlässigkeit repliziert. Alle REST-basierten Front-End-Server befinden sich hinter dem AWS ELB-Service (Elastic Load Balancing). Wenn ein Service der Steuerungsebene ausfällt, steht immer ein Pool replizierter Services zur Verfügung, die Client- und interne Anfragen bedienen können. Hier ist ein Beispiel, bei dem Redundanz sowohl bei der Zuverlässigkeit als auch bei der Skalierbarkeit hilft.
Wir verwenden ZooKeeper, um unseren zuverlässigen Zeitplanungsdienst zu implementieren. Ein wichtiger Aspekt von SnapLogic iPaaS ist die Möglichkeit, geplante Integrationen zu erstellen. Es ist wichtig, dass diese geplanten Aufgaben zu einem bestimmten Zeitpunkt oder in den erforderlichen Intervallen gestartet werden. Wir implementieren den Scheduling Service als eine Sammlung von Servern. Alle Server können eingehende CRUD-Anfragen zu Aufgaben annehmen, aber nur ein Server wird zum Anführer gewählt. Zu diesem Zweck verwenden wir einen auf ZooKeeper basierenden Algorithmus zur Wahl des Anführers. Auf diese Weise wird bei einem Ausfall des Anführers sofort ein neuer Anführer gewählt, der die Planung der Aufgaben rechtzeitig wieder aufnimmt. Wir stellen sicher, dass keine geplante Aufgabe verpasst wird. Wir verwenden ZooKeeper nicht nur für die Wahl des Anführers, sondern auch, um den Follower-Schedulern die Möglichkeit zu geben, den Anführer über Aufgabenaktualisierungen zu informieren.
Außerdem verwenden wir eine Reihe von Technologien zur replizierten Datenspeicherung, um die Kontrolle zu gewährleisten und sicherzustellen, dass Metadaten auf zuverlässige Weise vorhanden sind. Wir verwenden derzeit MongoDB-Cluster für Metadaten und verschlüsselte AWS S3-Buckets für die Implementierung von SLFS. Wir stellen S3 nicht direkt zur Verfügung, sondern bieten eine virtuelle hierarchische Sicht auf die Daten. Dadurch können wir den Zugriff auf die SLFS-Daten verfolgen und ordnungsgemäß autorisieren.
Für MongoDB haben wir eine zuverlässige Lese-Änderungs-Schreib-Strategie entwickelt, um Metadaten-Updates mit findAndModfy nicht-blockierend zu verarbeiten. Unser Ansatz führt zu hocheffizienten, konfliktfreien Aktualisierungen, ist aber auch im Falle eines Schreibkonflikts sicher. In einem zukünftigen Beitrag werden wir eine technische Beschreibung der Funktionsweise geben.
Die Vorteile der Software-definierten Integration
Durch die Unterteilung der elastischen iPaaS-Architektur von SnapLogic in die Datenebene und die Steuerungsebene können wir effektive, aber unterschiedliche Zuverlässigkeitsstrategien zwischen diesen beiden Klassen einsetzen. Auf der Datenebene helfen wir bei der Erkennung und Behebung von Snaplex-Serverausfällen, ermöglichen den Anwendern aber auch die Implementierung hochzuverlässiger Pipelines nach Bedarf. Auf der Steuerungsebene verwenden wir eine Kombination aus Serverreplikation, Lastausgleich und ZooKeeper, um eine zuverlässige Systemausführung zu gewährleisten. Unser Ansatz, bei dem es keine Einheitsgröße gibt, ermöglicht es uns, die Zuverlässigkeit zu modularisieren und gezielte Teststrategien anzuwenden. Zuverlässigkeit ist kein Produktmerkmal, sondern ein inhärentes Designmerkmal in jedem Aspekt der SnapLogic Integration Cloud.
