Tech-Talk-Serie: Architekturen für Skalierbarkeit in Ihrer mandantenfähigen Cloud

Bei Jitterbit ist es unsere Mission, selbst die komplexesten Herausforderungen im Bereich der Konnektivität zu vereinfachen und es jedem zu ermöglichen, in der digitalen Welt von heute eine Verbindung herzustellen. Auch wenn wir betonen, dass man kein Entwickler sein muss, um die Produkte von Jitterbit zu nutzen – hinter jeder großartigen Softwarelösung steht ein Team fantastischer Entwickler.   In der Jitterbit Tech Talk-Reihe blog geben Mitglieder des Jitterbit-Entwicklungsteams Einblicke in den Aufbau einer Cloud-Plattform der Enterprise-Klasse und die Herausforderungen, die sie in Bezug auf Mandantenfähigkeit, Skalierbarkeit und Sicherheit bewältigen mussten.

Diese Woche betrachtet Pankaj Arora, unser Sr. Director of Technology, wie man eine hochskalierbare Enterprise-Cloud-Plattform entwirft und architektonisch gestaltet.

Die Cloud bietet Unternehmen eine leistungsstarke Möglichkeit, ihre Produkte und Dienste so anzubieten, dass sie von überall und auf jedem Gerät leicht zugänglich sind. Sie bietet zudem enorme Vorteile für den Anbieter, darunter Einblicke in die Nutzung ihres Angebots, eine schnelle Entwicklung und Bereitstellung sowie allgemeine Einsparungen bei den IT- und Wartungskosten. Aus diesem Grund versucht heute fast jedes Unternehmen, seine Lösungen in der Cloud verfügbar zu machen.

Aber zu einem echten Cloud-Unternehmen zu werden, gehört weit mehr, als nur Software auf einem gehosteten Server zu installieren und “Cloud” auf die Marketingmaterialien zu schreiben.

Ich habe mich kürzlich mit einem Technologiestrategen unterhalten, der darauf hinwies, dass etwa 75% der Unternehmen ihre alten Unternehmensanwendungen in die Cloud migrieren möchten. Überraschenderweise entwerfen 90% von ihnen einen ersten Plan, der auf einer Architektur basiert, bei der ihre Altsysteme einfach auf einem öffentlich zugänglichen Cloud-Server bereitgestellt würden. Dieser Ansatz macht alle Vorteile zunichte, die die Cloud zu bieten hat.

Der Aufbau einer echten mandantenfähigen Cloud-Plattform erfordert die Bewältigung einer Reihe verschiedener Herausforderungen wie Sicherheit, Zuverlässigkeit, Skalierbarkeit, hohe Verfügbarkeit, Fehlertoleranz, Protokollierung, Überwachung, Benachrichtigungssysteme, Fähigkeit zur kontinuierlichen Bereitstellung und vieles mehr.

Im heutigen Beitrag werden wir uns genauer ansehen, wie wir die Herausforderung der ‘Skalierbarkeit’ bei der Entwicklung unserer mandantenfähigen Cloud-Integrationsplattform gemeistert haben.

Das Ausmaß der Skalierbarkeit einer Anwendung ist an ihre Fähigkeit gebunden, vertikal und horizontal zu skalieren. In einer Cloud-Umgebung bedeutet dies, Dienste zu entwerfen, die externe Anfragen bedienen und so skalieren, dass sie interne Backend-Systeme wie Datenbanken, Caches, Vermittlungsschichten, Batch-Prozesse (analytische Engine, Empfehlungs-Engine) usw. nutzen können, um praktisch unendlich viele Anfragen in kürzester Zeit zu bewältigen. Es ist nicht immer möglich, die Anzahl der Nutzer vorherzusagen, die auf Ihre Plattform zugreifen. Der Entwurf einer Architektur, die dies im Mandantenfähigkeitsmodell berücksichtigt, trägt dazu bei, diese Ungewissheit zu einem generellen Skalierbarkeitsproblem zu machen.

Vertikale Skalierung

Die vertikale Skalierbarkeit beinhaltet das Hinzufügen von Ressourcen wie zusätzlichen CPUs oder Arbeitsspeicher zu einem einzelnen Knoten in einem System, und dies sollte das Erste sein, worüber Sie nachdenken, wenn Sie Ihre Dienste skalieren. Es ist sehr wichtig, Ihre Anwendungen so zu entwerfen, dass sie diese Ressourcen optimal nutzen. Betrachten Sie den gängigen Anwendungsfall für unsere hybride Integrations-Cloud-Plattform, bei dem Integrationsvorgänge von lokalen oder Cloud-Serverknoten bedient werden. Hier sollten die Dienste eine Anfrage zur Ausführung von Integrationen entgegennehmen, die Anfrage an Serverknoten weiterleiten und weiterhin weitere Anfragen bedienen. Die Diensteschicht sollte weder von den Prozessen abhängig sein, die auf verschiedenen Ebenen des Systems ablaufen, noch durch diese blockiert werden. Daher ist es sehr wichtig, über eine asynchrone, ereignisgesteuerte Architektur zu verfügen.

Ein einfacher Weg, eine asynchrone Architektur zu verstehen, besteht darin, sich Ihre Architektur wie ein Restaurant vorzustellen. Ein Kellner nimmt Bestellungen von einem Tisch entgegen und gibt sie an den Koch weiter. Während der Koch, der Essensläufer und der Abräumer sich um Aktivitäten wie Kochen, Servieren und Reinigen kümmern, bedient der Kellner weiterhin neue Kunden und führt am Ende des Service die Abrechnung durch.

Die Aufrechterhaltung der Asynchronität, während das System mit allen Komponenten wie Datenbank, Cache und Mediatorschicht arbeitet, ist von großer Bedeutung. Die Übertragung der Last auf geclusterte, hochverfügbare Serverknoten, die Integrationen ausführen, setzt Ressourcen für die Dienstschicht frei, um mehr Anfragen anzunehmen und zu antworten, wenn Prozesse abgeschlossen sind.

Horizontale Skalierung

Der nächste wichtige Aspekt sollte sein, dass die Dienste so geschrieben sind, dass es keine Rolle spielen darf, wie viele Instanzen dieser Dienste ausgeführt werden und welches gemeinsam genutzte System zu einem bestimmten Zeitpunkt Transaktionen durchführt. Dies gibt unserer Cloud-Plattform die Flexibilität, die Diensteschicht automatisch zu skalieren. Jeder Teil des Backends ist hochverfügbar und automatisch skalierbar, um mit der Nachfrage wachsender Dienst-Container Schritt zu halten.

Wir können jedoch nicht unendlich viele Container mit Service-Ebenen betreiben, die gemeinsame Komponenten nutzen. Das ist kein optimales Design. Kehren wir zu unserem Restaurantbeispiel zurück. Bei vertikaler Skkalierung könnte ein einzelnes Restaurant durch die Einstellung von mehr Personal hochgradig skalierbar werden, aber ab einem bestimmten Punkt erreicht die Anzahl der Ressourcen (Köche, Läufer, Abräumer) einen Sättigungspunkt. Um weiter zu skalieren, müsste dieses Geschäft zusätzliche Standorte eröffnen, die dabei helfen, die Kunden zu verteilen und die Last auszugleichen.

Es ist besser, die gesamte Plattform in mehrere Zonen aufzuteilen, wobei sich jede Zone wie eine Replik der ursprünglichen Zone verhält. Dies ermöglicht es uns, mehrere Zonen zu nutzen, um zukünftige Anforderungen auszugleichen.

Dieses Modell hat mehrere Vorteile:

1. Mögliche unendliche horizontale Skalierung, da wir eine beliebige Anzahl von Zonen einbinden können

2. Fehlertoleranz für den Fall, dass die gesamte Zone aufgrund einer Naturkatastrophe ausfällt

3. Datentrennung im Falle einer SaaS-Plattform, die sogar eine standortbasierte Metadatentrennung erfordert, wie zum Beispiel für US-, EMEA-Zonen usw.

Das angestrebte Ergebnis hierbei ist, dass die Erfahrung eines Benutzers unabhängig von seinem Standort und der genutzten Zone immer dieselbe sein sollte. Es sollte kein manuelles Eingreifen des Benutzers erforderlich sein, um die Arbeit zu erledigen.

In unserem Hybrid-Integrations-Cloud blog, wir haben darüber gesprochen, wie wir auf die Herausforderung gestoßen sind, eine Vermittlerschicht so zu nutzen, dass sie nur eine begrenzte vertikale Skalierung unterstützte. Durch das Schreiben einer eigenen, maßgeschneiderten, nicht-blockierenden Verbindungsschicht auf Basis eines sicheren HTTPS-Transports ist es uns gelungen, die Architektur so zu erweitern, dass sie eine 50-fache vertikale Skalierung ermöglicht. Natürlich ist sie auch horizontal skalierbar. Diese Kombination aus vertikaler und horizontaler Skalierung ergab eine kostengünstigere und leicht erweiterbare Schicht, um unseren wachsenden Anforderungen gerecht zu werden.

Optimierung der Nutzung gemeinsam genutzter Komponenten:

Gemeinsam genutzte Komponenten sollten selbst skalierbar und hochverfügbar sein, um die Cloud-Plattform zu unterstützen. Da gemeinsam genutzte Komponenten jedoch von mehreren Instanzen genutzt werden, sind sie nicht so skalierbar wie die Diensteebene. Es ist sehr wichtig, besonders auf bestimmte Komponenten zu achten, die empfindlich auf hohe Auslastung reagieren können, beispielsweise Datenbanken. Ein Ansatz könnte darin bestehen, die usage gemeinsam genutzter Komponenten zu priorisieren und in eine Warteschlange zu stellen, wenn mehrere gleichzeitige Anfragen mit hohem Datenaufkommen zu Problemen führen können. Durch die Priorisierung lässt sich die Auslastung senken und das Fehlerrisiko bei geschäftskritischen Anfragen verringern.   Zurück in unserem Restaurant: Die Küche ist eine gemeinsam genutzte Komponente, und während der Kellner die Bestellung eines Gastes für Vorspeise, Hauptgericht und Dessert entgegennimmt, priorisiert die Küche die Zubereitung dieser Gerichte und gleicht die Auslastung aus.

Eine weitere Möglichkeit, die Auslastung zu bewältigen, besteht darin, Daten, die sich nur selten ändern, zwischenzuspeichern, um einen hohen usage dieser Komponenten zu vermeiden. Wenn Pommes frites ein beliebtes Gericht auf der Speisekarte sind, könnte das Restaurant beschließen, eine fortlaufende Charge “zwischenzuspeichern”, anstatt sie erst auf Bestellung zu frittieren.

Überwachung von Komponenten:

Schließlich ist es sehr wichtig, jede Komponente zu überwachen und ihre Grenzen zu kennen. Das System sollte in der Lage sein, die Bandbreite automatisch und zum richtigen Zeitpunkt zu erhöhen, um die Systeme gemäß den Anforderungen der Cloud-Plattform betriebsbereit zu halten. Die Überwachung kann extern oder anwendungsinitiiert erfolgen, aber in jedem Fall ist das最终 Ziel, das System basierend auf der Last automatisch zu skalieren.

Im nächsten blog-Beitrag werden wir uns mit Überwachung, Protokollierung und weiteren Elementen der Architektur befassen.