Resiliente und fehlertolerante Software-Architektur: Goodbye Sidecars – welcome to cell-based architecture

Diese haben auch im Cloud-Zeitalter ihre Gültigkeit behalten. Es ist gut, sie zu kennen und Vorsichtsmaßnahmen zu ergreifen, denn Ausfälle sind teuer geworden und die Suche nach Fehlern in verteilten Systemen ist aufwendig. Eine gute Überwachbarkeit (Observability) und die Verwendung von Chaos-Engineering-Praktiken helfen, Fehler frühzeitig zu erkennen und zu reagieren.

Software-Architektur: Stabilität und Resilienz

Für eine höhere Resilienz sollte man sowohl in der Anwendung als auch in deren Architektur Stabilitätsmuster verwenden. Solche Stabilitätsmuster, wie Schutzschalter, Schottwand oder Zeitbegrenzung, beschreibt Michael Nygard in seinem Buch "Release IT". Das Prinzip Schottwand kommt aus dem Schiffsbau. Selbst wenn Teile eines Schiffs lecken, ist das gesamte Schiff immer noch voll funktionsfähig. Durch eine Microsegmentierung eines Systems gibt es verschiedene Möglichkeiten, um auf Ausfälle oder Fehler zu reagieren. Die bekannteste Variante der Mikrosegmentierung findet man auf Netzwerkebene, um die Türen (Ports) über Firewalls für bestimmte Dienste zu schließen.

Microservices sind aktuell der vorherrschende Architekturansatz. Je umfangreicher solche Microservices-Netze werden, umso öfter kommen Service-Mesh-Produkte im Kubernetes-Cluster zum Einsatz. Service Meshes machen dasselbe auf Netzwerkebene 4 und 7 möglich. Dazu wird ein Service Proxy als Beiwagen (Sidecar) zu einem Service deployt, um so den Netzverkehr kontrollieren zu können. Die Gesamtheit aller Service Proxys wird in einem Service Mesh als Data Plane bezeichnet. Gesteuert werden diese über eine Control Plane, die Metrikdaten von den Service Proxys erhält und Änderungen an der Konfiguration bei ihnen bekannt macht. Das führt bei vielen hundert oder tausend Services oft zu einem hohen Aufwand, wenn sich eine Konfiguration ändert und diese Änderungen an allen anderen Proxys bekannt gemacht werden müssen. Damit kann das Muster für Schutzschalter und Zeitbegrenzung einfach umgesetzt und verwaltet werden. Bei einem großen Service-Mesh-Netzwerk summiert sich jedoch der Verwaltungsaufwand bei Konfigurationsänderungen, aber auch der Ressourcenverbrauch in jedem Service Proxy.

Eine Möglichkeit, den Ressourcenverbrauch zu reduzieren, ist direkt über den eBPF-Paketfilter des Linux-Kernels zu gehen oder den Ambient-Modus des Service Mesh zu verwenden. Dieser kann in den neuen Versionen des Service-Mesh-Produktes Istio verwendet werden, um die Data Plane in eine Schicht für die Netzwerkebene 7 und eine für die Absicherung aufzuteilen.

Bei Service-Mesh-Produkten gibt es einige Funktionalitäten, die bisher nur von anderen Produkten, wie API-Gateway oder Load Balancer, zur Verfügung gestellt wurden. Das kann dazu führen, dass einige Dinge doppelt erledigt werden. Eine Fehlerdiagnose in verteilten Systemen wird dadurch erschwert, da jetzt noch mehr Komponenten beteiligt sind, die eine potenzielle Fehlerquelle sind. Um die Nachteile des Beiwagen-Musters zu vermeiden, verabschieden sich zellbasierte Architekturen komplett davon. Dadurch wird der Verwaltungsaufwand reduziert und die Architektur vereinfacht. Zellbasierte Architekturen sind auch an keine Technologie oder Produkte gebunden wie Service Meshes.

Die Steuerung erfolgt jetzt nicht mehr dezentral in jedem Proxy eines Services, sondern zentral in einem Zellenrouter (Control Plane). So können zusammengehörige Dienste in einer Zelle (Data Plane) zusammengefasst werden. Eine zellübergreifende Kommunikation der Dienste wird unterbunden, um eine bessere Performance mit weniger Kommunikationsfehlern zu erreichen. Insgesamt wird eine verteilte Architektur klarer strukturiert und ist damit besser handhabbar. Die Zelle kann jetzt auf eine Availability Zone oder mehrere Zonen aufgeteilt werden. Die Skalierung der Dienste innerhalb einer Zelle kann unabhängig von den anderen Zellen erfolgen. Ausfälle einer Zelle wirken sich nicht auf die anderen Zellen aus, da diese autark und von den anderen isoliert ("self-contained") sind. Was bei einem Sidecar über Produkte geregelt wurde, wird jetzt auf die Infrastrukturebene verlagert. Im Gegensatz zu Service Mesh, was meistens mit Kubernetes eingesetzt wird, sind zellbasierte Architekturen erst einmal technologieunabhängig. Mit den Möglichkeiten und Fähigkeiten der Public Cloud zu nutzen, lassen sie sich einfach umsetzen. Zellbasierte Architekturen sind ein mächtiger und flexibler Ansatz für mehr Resilienz in der Cloud und wurden als Innovator im InfoQ Software Architecture and Design Trends Report aufgenommen [1]. Sie ermöglichen einen einfachen Scaling-up-Ansatz, indem bei Bedarf einfach eine weitere Zelle erstellt und im Router registriert wird. Sie ermöglichen damit eine höhere "mean time between failure" (MTBF) und niedrigere "mean time to recovery" (MTTR), um so eine höhere Verfügbarkeit und Wiederherstellbarkeit zu realisieren. Dieser Architekturansatz erleichtert auch den Test, Deployment und Rollback neuer Zellen und reduziert den Blast-Radius von Fehlern. Tumblr, Flickr, Doordash, Salesforce, Slack und Facebook sind nur einige prominente Beispiele, die auf zellbasierte Architekturen umgestellt haben.