Cloud-native Lastverteilung in mandantenfähigen Umgebungen
Einführung
Im Laufe der Jahre hat sich die Anwendungsarchitektur vom Client-Server-Modell über serviceorientierte Architekturen hin zu cloud-nativen, auf Microservices basierenden Architekturen weiterentwickelt. Diese Entwicklung hat erhebliche Auswirkungen auf die Methoden der Anwendungsentwicklung sowie auf die Herangehensweisen in Bezug auf Skalierbarkeit, Sicherheit und vor allem die Bereitstellung von Anwendungen.
Leider lässt der aktuelle Stand der Technik bei Application Delivery Controllern (ADCs), auch als Load Balancer bekannt, zu wünschen übrig. Die Nachfrage nach Diensten hat sich weiterentwickelt, und was früher nur einen einzigen Dienst erforderte, erfordert heute mehrere unterschiedliche Dienste. In dieser neuen Ära der Dienstexplosion wird es für IT-Teams eine Herausforderung sein, das Lebenszyklusmanagement von Anwendungen effektiv zu bewältigen, es sei denn, der moderne ADC ist „mikroservicefähig“ und verfügt über die entsprechende Automatisierung – ermöglicht durch APIs, Automatisierungs- und Orchestrierungs-Frameworks –, um jeden Mikroservice bereitzustellen, zu konfigurieren und zu verwalten.
In diesem Artikel wird beschrieben, wie sich Anwendungsarchitekturen weiterentwickelt haben und wie der verteilte Microservices-Ansatz von KubeLB die betrieblichen Auswirkungen einer auf Microservices basierenden Anwendungsarchitektur drastisch reduzieren kann.
Die monolithische Architektur
Zu Beginn der Entwicklung von Webanwendungen bestand die vorherrschende Architektur für Unternehmensanwendungen darin, alle serverseitigen Komponenten der Anwendung in einer einzigen Einheit zu bündeln. So bestehen beispielsweise zahlreiche Unternehmensanwendungen oft aus einzelnen WAR- oder EAR-Dateien.
Stellen Sie sich die Entwicklung eines Online-Shops vor, der Bestellungen entgegennimmt, Lagerbestände und verfügbare Guthaben überprüft und den Versand abwickelt. Diese Anwendung umfasst verschiedene Komponenten, darunter die Frontend-Benutzeroberfläche sowie Dienste zur Verwaltung des Produktkatalogs, zur Bearbeitung von Bestellungen und zur Abwicklung von Konten. Die Dienste nutzen ein gemeinsames Domänenmodell, das die Entitäten „Produkt“, „Bestellung“ und „Kunde“ umfasst. Trotz ihres logisch modularen Aufbaus wird die Anwendung als Monolith bereitgestellt – als einzelne WAR-Datei, die auf einem Web-Container wie Tomcat läuft.
Einfach zu entwickeln
IDEs und Entwicklungstools sind auf die Erstellung einer einzelnen Anwendung ausgerichtet. Das Testen und Bereitstellen dieser Anwendungen ist unkompliziert, da sich alles innerhalb einer einzigen Anwendung befindet.
Geeignet für kleine Apps
Der monolithische Ansatz eignet sich gut für relativ kleine Anwendungen mit begrenzter Teamgröße und geringen Skalierungsanforderungen.
wird mühsam
Bei komplexen Anwendungen erweist sich die monolithische Architektur als schwerfällig und stellt die Skalierung, das Experimentieren und die technologische Weiterentwicklung vor große Herausforderungen.
Der Versuch, ein neues Infrastruktur-Framework einzuführen, erfordert oft eine Neuprogrammierung der gesamten Anwendung, was riskant und unpraktisch ist. Um neue Änderungen an einer Anwendungskomponente zu implementieren, muss man den gesamten Monolithen neu erstellen und bereitstellen – ein komplexer, riskanter und zeitaufwändiger Vorgang. In Fällen, in denen ein Dienst erhebliche Speicherressourcen beansprucht und ein anderer rechenintensiv ist, erfordert die Serverbereitstellung die Zuweisung ausreichender Kapazitäten, um die Grundlast jedes Dienstes abzudecken, was einen Kostenanstieg unvermeidlich macht.
Die Cloud-native Microservices-Architektur
Die cloudnative, auf Microservices basierende Architektur wurde entwickelt, um die Probleme zu lösen, die bei monolithischen Architekturen auftreten. Anwendungen werden in einzelne Dienste zerlegt und unabhängig voneinander auf separaten Hosts bereitgestellt. Jeder Microservice ist auf eine bestimmte Geschäftsfunktion ausgerichtet und umfasst ausschließlich die für diese Geschäftsfunktion wesentlichen Vorgänge. Diese Architektur nutzt Tools wie Kubernetes, ArgoCD, Flux und andere cloudnative Projekte.
Höhere Produktivität der Entwickler
Jeder Dienst ist relativ klein und verfügt über einen für Entwickler besser nachvollziehbaren Code. Dies steigert die Produktivität der Entwickler, da sich die Teams nun nur noch auf einen Teilbereich der Anwendung konzentrieren müssen; die IDE arbeitet effizienter, und das Ausführen und Testen der Anwendung nimmt weniger Zeit in Anspruch.
Unabhängige Bereitstellung
Da jeder Dienst isoliert betrieben werden kann und nicht von anderen Diensten abhängig ist, können Entwickler an bestimmten Diensten isoliert arbeiten, ohne auf andere Teams oder Silos innerhalb einer Organisation angewiesen zu sein. Dies macht die kontinuierliche Entwicklung, das Testen und die Bereitstellung einfach und äußerst effektiv.
Granulare Skalierung
Der größte Vorteil dieser Architektur besteht darin, dass Skalierung, die zugrunde liegende Hardware und die Ressourcenanforderungen (CPU-, GPU- oder speicherintensiv) für jeden einzelnen Dienst individuell konfiguriert werden können. Dies kann den Durchsatz von Anwendungen erheblich steigern und gleichzeitig die anfallenden Kosten senken.
Skalierung von Microservices entlang der X-, Y- und Z-Achse
Skalierung der X-Achse
Bei der horizontalen Skalierung werden mehrere Instanzen der gesamten Anwendung hinter einem Load Balancer ausgeführt. Jede Instanz der Anwendung wird als „horizontaler Slice“ bezeichnet. Dies ist die gängigste Form der Skalierung für Webanwendungen.
Skalierung der Y-Achse
Bei der vertikalen Skalierung wird die Anwendung in verschiedene Teile aufgeteilt, die jeweils auf einem eigenen Rechner laufen – dies ist die gängigste Form der Skalierung bei Microservices und ermöglicht eine unabhängige Ressourcenzuweisung für jeden einzelnen Dienst.
Skalierung der Z-Achse
Die Z-Achsen-Skalierung, auch als funktionale Zerlegung bekannt, beinhaltet die Aufteilung der Anwendung in verschiedene Teile auf der Grundlage einer Datenpartitionierung, wobei jeder Teil auf einem separaten Rechner ausgeführt wird. Die bekannteste Darstellung hierfür ist der „Scale Cube“, ein dreidimensionales Skalierbarkeitsmodell, das durch das Buch „The Art of Scalability“ bekannt wurde.
Der Aufstieg von Containerisierungs- und Orchestrierungstools
Mit der zunehmenden Verbreitung von Microservices entstanden Tools wie Docker, Docker Swarm und Kubernetes, um die Bereitstellung und Skalierung zu vereinfachen. Docker revolutionierte die Containerisierung und ermöglichte einheitliche Umgebungen in Entwicklung und Produktion. Kubernetes erweiterte diese Funktionen und bot robuste Orchestrierung, Verwaltung und Skalierbarkeit für komplexe, verteilte Microservices-Architekturen. Seine leistungsstarken Funktionen – wie automatische Skalierung, Selbstheilung und rollierende Updates – lösten viele Herausforderungen im Zusammenhang mit der Bereitstellung und Verwaltung von Microservices in großem Maßstab und machten es zur De-facto-Plattform für Microservices in der Branche.
Herausforderungen bei Kubernetes
Kubernetes vereinfacht zwar die Orchestrierung und Verwaltung containerisierter Anwendungen erheblich, bringt jedoch auch Herausforderungen mit sich – insbesondere in Umgebungen mit mehreren Clustern und Mandanten.
Eingeschränkter nativer Lastausgleich
Kubernetes bietet Schnittstellen für den Lastausgleich auf Layer 4 und Layer 7 in Form von Services und Ingresses. Diese bieten jedoch nur begrenzte Funktionen und sind hinsichtlich ihrer Implementierung vom jeweiligen Cloud- oder Ingress-Anbieter abhängig. Dies führt zu einer Abhängigkeit vom Anbieter bei erweiterten Funktionen wie Traffic-Splitting, Traffic-Shaping und Observability.
Komplexität bei mehreren Clustern
Die Steuerung des Netzwerkverkehrs, die Gewährleistung der Anwendungssicherheit und die Aufrechterhaltung einer hohen Leistung über verschiedene Cluster und Clouds hinweg können komplex und ressourcenintensiv sein. Herkömmliche Load Balancer haben oft Schwierigkeiten, mit der Dynamik von Microservices Schritt zu halten, was zu Ineffizienzen und erhöhtem Betriebsaufwand führt.
Lücken bei mandantenfähigen Lösungen
Da Anwendungen immer komplexer und umfangreicher werden, erfordern geschäftskritische Workloads den Einsatz mehrerer Cluster. Unternehmen, die mehrere Kubernetes-Cluster über Regionen, Verfügbarkeitszonen und Cloud-Anbieter hinweg bereitstellen, stehen vor neuen Herausforderungen: der Verwaltung verschiedener Cluster, der Gewährleistung einheitlicher Richtlinien und der Sicherstellung einer nahtlosen Kommunikation zwischen den Anwendungen. Kubernetes verfügt von Haus aus nicht über diese Funktionen und erfordert daher zusätzliche Tools.
Wir stellen vor: KubeLB
KubeLB ist eine softwarebasierte Anwendungsbereitstellungsplattform der nächsten Generation mit integrierten Analysefunktionen, die sichere, zuverlässige und skalierbare Netzwerkdienste für Cloud-native Anwendungen bereitstellt.
Das Herzstück von KubeLB bildet eine revolutionäre Architektur, die auf SDN-Prinzipien basiert und die Datenebene von der Steuerungsebene trennt – eine Branchenneuheit bei Application Delivery Controllern und Load Balancern.
KubeLB ermöglicht die nahtlose Skalierung von Anwendungsbereitstellungsdiensten innerhalb und über Rechenzentren und Cloud-Standorte hinweg, wobei eine zentrale Verwaltungs- und Kontrollstelle beibehalten wird. Der Load Balancer wird als Dienst bereitgestellt, sodass mehrere Mandanten dieselbe Software nutzen können. Er erkennt die Umgebung des jeweiligen Mandanten und passt sich entsprechend an.
Verteilte Architektur
Die verteilten Load Balancer, die auf Basis der leistungsstarken Komponenten Cilium und Envoy implementiert sind, Envoy umfassende Dienste für die Anwendungsbereitstellung, darunter Lastenausgleich, Anwendungsbeschleunigung und Anwendungssicherheit. Cilium und Envoy gemeinsam mit Anwendungen innerhalb und über verschiedene Cloud-Standorte hinweg bereitgestellt und auf höhere Leistung optimiert werden.
Platzierungsintelligenz
Mithilfe der umfangreichen Dienste von KubeLB in den Bereichen Datenverarbeitung, Steuerung und Verwaltung Envoy sich Cilium und Envoy in unmittelbarer Nähe zu den Microservices der Anwendung platzieren und so auf höhere Leistung und schnellere Client-Antworten optimieren.
End-to-End-Analytik
Die integrierten Datenerfassungsmodule erfassen durchgängige Zeitdaten, Kennzahlen und Protokolle für jede Transaktion zwischen Benutzer und Anwendung und liefern so verwertbare Erkenntnisse über die Endbenutzererfahrung, die Anwendungsleistung, die Infrastrukturauslastung und auffälliges Verhalten.
Elastische Datenebene
Die einzigartige verteilte Architektur von KubeLB ermöglicht es den Service-Engines, sich ohne menschliches Eingreifen automatisch zu skalieren und so die Echtzeitanforderungen von Microservice-basierten Anwendungen über Hunderte von Mandanten und Tausende von Anwendungen hinweg zu erfüllen.
Kernkompetenzen
Analytikgesteuerte Anwendungsbereitstellung
Die KubeLB-Engines überwachen kontinuierlich die Datenverkehrsmuster jeder Microservice-Anwendung. Sobald ein individuell festlegbarer Schwellenwert erreicht wird, Envoy die neu skalierten Cilium- und Envoy nahtlos die steigende Datenverkehrslast. Darüber hinaus kann die Inline-Analytics-Engine auf Grundlage der aktuellen Auslastung einen Trigger senden, um die Backend-Microservice-Anwendungen hoch- oder herunterzuskalieren.
Elastische Skala
Die elastische Datenebene von KubeLB lässt sich dynamisch skalieren, um den Echtzeitanforderungen von Microservice-basierten Anwendungen über Hunderte von Mandanten und Tausende von Anwendungen hinweg gerecht zu werden. Cilium und Envoy , die Netzwerkdienste für jeden einzelnen Microservice individuell zu skalieren. Unabhängig davon, ob sich die Microservices auf einem einzelnen physischen Server, auf verschiedenen Servern in einem einzigen Rechenzentrum oder sogar über verschiedene Rechenzentren verteilt befinden, erkennen Cilium und Envoy und positionieren sich so nah wie möglich an jedem Microservice.
Datenebenen-Isolierung für Mandanten und Anwendungen
Um zu vermeiden, dass sich kritische Anwendungen die Infrastruktur teilen, wird jedem Mandanten und jeder Anwendung zur Isolierung der Datenebene eine eigene Service Engine zugewiesen. Dadurch wird das Problem des „Noisy Neighbor“ beseitigt, bei dem ein fehlerhafter Microservice-Mandant möglicherweise die Leistung einer benachbarten Anwendung beeinträchtigen könnte. Die mandantenbezogenen, dedizierten Mikro-Load-Balancer von KubeLB bieten echte Multi-Tenant-Anwendungsdienste.
Programmierbarkeit
Die gesamte Kommunikation mit dem KubeLB-Controller erfolgt über native Kubernetes-APIs, was eine native Integration mit kubectl ermöglicht. DevOps-Automatisierungstools wie Crossplane, Terraform oder Ansible werden ebenfalls nativ unterstützt.
N-Wege-Aktivredundanz
KubeLB nutzt Redundanzprinzipien aus Rechenzentren im Web-Scale-Maßstab und bietet N-Way-Active-Active-Redundanz sowie Active-Active- und Active-Standby-Verfügbarkeitsoptionen, wodurch sichergestellt wird, dass Ihre Anwendungen in jedem Ausfallszenario verfügbar bleiben.
Wie sich Lastverteiler weiterentwickeln müssen
Jede Gruppe aus Cilium und Envoy einem bestimmten Mandanten zugeordnet werden. In einer mandantenfähigen Umgebung wird der Datenverkehr für eine bestimmte Anwendung auf die Gruppe dieses Mandanten beschränkt. KubeLB kann mehrere Gruppen aus Cilium und Envoy verwalten, wobei der rollenbasierte Zugriffskontrollmechanismus von Kubernetes sicherstellt, dass Benutzer, die bei einem bestimmten Mandanten angemeldet sind, nur die Details dieses bestimmten Mandanten einsehen können.
Echte Trennung von Steuerungs- und Datenebene
Innerhalb des ADC muss eine vollständige und echte Trennung von Steuerungs- und Datenebene bestehen, mit der Möglichkeit, Ressourcen der Datenebene dynamisch auf verschiedene Hardwareplattformen sowie öffentliche und private Clouds zu verteilen – genau so, wie auch Anwendungs-Mikroservices verteilt werden können.
Unabhängigkeit der Datenebene bei Multi-Tenancy
Die Erreichung der Unabhängigkeit (Isolation) der Datenebene, um Multi-Tenancy zu ermöglichen, insbesondere in Cloud-Umgebungen. Dies entspricht der Funktionsweise von Microservices, die unabhängig voneinander betrieben und geändert werden können, ohne andere Microservices zu beeinträchtigen – der „No Noisy Neighbor“-Effekt.
Anwendungsaffinität
ADCs müssen das Konzept der „Anwendungsaffinität“ umsetzen – bei dem Ressourcen auf bestimmte Funktionen abgestimmt werden. Dieser Ansatz bietet zwei wesentliche Vorteile: Der Microservice verbessert die Reaktionszeit der Anwendung, indem die ADC-Ressource direkt daneben platziert wird, und diese enge Abstimmung ermöglicht es den ADC-Ressourcen, das Lebenszyklusmanagement von Microservices automatisch und ohne manuellen Eingriff durchzuführen, was die Komplexität der Verwaltung erheblich reduziert.
Selbstbedienung bei der SDN-Programmierbarkeit
Das Versprechen von SDN hinsichtlich Selbstkonfigurierbarkeit und Effizienz wird erfüllt. Nur durch eine echte Trennung von Steuerungs- und Datenebene sowie die vollständige Zentralisierung der Steuerungsfunktionen kann der ADC das eigentliche Versprechen von SDN einlösen – nämlich die Eins-zu-Eins-Kommunikation zwischen seinem Controller und den Steuerungselementen der Anwendung über RESTful-APIs zu ermöglichen.
Zusammenfassung
Die Architektur der heutigen Anwendungsentwicklung hat sich von speziell entwickeltem monolithischem Code zu einer eng vernetzten Sammlung modularer und wiederverwendbarer Microservices weiterentwickelt. Der Übergang zur Entwicklung von Microservice-Anwendungen bedeutet, dass bisherige Annahmen hinsichtlich Datenverkehrsmustern, der Skalierbarkeit des Lastausgleichs und der Serviceanforderungen nicht mehr gültig sind.
KubeLB ist ein elastisch skalierbarer Load Balancer mit einer verteilten Datenebene, der sich über verschiedene Standorte vor Ort und in der Cloud erstrecken, diese bedienen und gemeinsam mit den Anwendungen skalieren kann. Die verteilte Datenebene ermöglicht es Mandanten, eine Anwendungsaffinität auf Microservice-Ebene zu erreichen, wodurch die Gesamtleistung der Anwendungen erheblich gesteigert wird. Die klare Trennung der Ebenen ermöglicht zudem die Schaffung einer einheitlichen, zentralisierten Steuerungsebene, die die betriebliche Komplexität erheblich verringert, die mit der Integration, dem Betrieb und der Verwaltung jeder einzelnen ADC-Appliance an den verschiedenen Standorten verbunden ist.
Zusammenfassend lässt sich sagen, dass KubeLB ein äußerst flexibler, kostengünstiger, skalierbarer und effizienter Load Balancer ist – der sich besonders für Multi-Tenant-Dienstleister eignet.
Fallstudie: Mit der Anwendungsarchitektur wachsen
In der Anfangsphase konzentrierte sich das Unternehmen vor allem auf geringe Komplexität und geringen Aufwand, was zu einer schnellen Softwareentwicklung führte. Da die Anwendung schnell auf den Markt gebracht werden muss, haben Entwickler in der Regel nicht den Luxus, die Anwendung auf Skalierbarkeit, Hochverfügbarkeit und Redundanz auszulegen. Mit KubeLB ADC lassen sich Hochverfügbarkeit und Skalierbarkeit schnell erreichen, indem die Anwendung auf einem Paar von Webservern hinter einem Paar von Load Balancern ausgeführt wird – wodurch die Betriebskosten auf ein Minimum reduziert werden.
Phase 1: Start
Bereitstellung auf einem Paar aus Web- und Datenbankservern hinter einem KubeLB-ADC. Sofortige Hochverfügbarkeit und Skalierbarkeit bei minimalen Betriebskosten.
Phase 2: Wachstum
Wenn die Nachfrage nach den Dienstleistungen steigt, können Sie die Kapazität schnell erweitern, indem Sie dem KubeLB ADC zusätzliche Ressourcen (Skalierung auf der X-Achse) zuweisen. Herausforderungen bei der Verwaltung statischer Inhalte werden durch den Einsatz von Caching-Engines auf dem KubeLB ADC gemildert.
Phase 3: Skalierung
Mit steigender Beliebtheit sollte die Anwendung in kleinere Dienste/Funktionen umgestaltet werden. Die Datenbankpartitionen entwickeln sich entsprechend den geografischen Standorten weiter. Dank des zukunftssicheren, sicherheitsorientierten Designs von KubeLB kann der vom ersten Tag an eingesetzte ADC auch bei steigendem Datenverkehr weiterhin genutzt werden. Eine einzige Instanz von KubeLB kann Anwendungen, die sich sowohl in einem Rechenzentrum als auch in der Cloud befinden, gleichzeitig bedienen, wobei die zentrale Steuerungs- und Verwaltungsschnittstelle die gesamte Verwaltung ermöglicht.
Über Kubermatic
Kubermatic ist ein führender Anbieter von Kubernetes- und Cloud-nativen Technologien und hat es sich zur Aufgabe gemacht, Unternehmen mit fortschrittlichen Lösungen zu unterstützen, die das IT-Management vereinfachen und optimieren. Unsere Produkte sind auf die Anforderungen moderner Unternehmen zugeschnitten und bieten die notwendigen Tools und den nötigen Support, um Innovationen voranzutreiben und geschäftlichen Erfolg zu erzielen. Weitere Informationen zu KubeLB und anderen Lösungen von Kubermatic finden Sie auf unserer Website oder wenden Sie sich an unser Vertriebsteam.