etcd3 ist für Microservices optimiert

Inhaltsverzeichnis

CoreOS hat die stabile Version von etcd 3.0.0 veröffentlicht. Der in Googles Programmiersprache Go geschriebene, verteilte Key-Value-Store dient der Speicherung von Daten innerhalb eines Clusters. Ursprünglich hatten die Macher ihn entwickelt, um Updates der CoreOS-Linux-Distribution zu managen. Inzwischen kommt er in vielen Clustern zur Verwaltung verteilter Anwendungen zum Einsatz. Administratoren verwenden ihn zur Datenkonfiguration, zum Load-Balancing und für das Scheduling. Durch den breiten Ansatz haben sich laut dem CoreOS-Blog die Anforderungen im Lauf der Zeit verändert.

So seien die JSON-Endpoints, die Überwachungsfunktionen für Schlüssel-Updates und TTL-Schlüssel (Time-to-live) zwar äußerst nützlich, führten aber zu einer "geschwätzigen" Netzwerkkommunikation und unvorhersehbaren Garbage-Collector-Durchläufen für veraltete Schlüssel. Daher hat das Team die API und das Datenmodell für Version 3 komplett überarbeitet.

Weniger geschwätzig dank gRPC

Das Interface nutzt in Version 3 gRPC zur Kommunikation statt wie bisher JSON. Google hatte das RPC-System (Remote Procedure Call) im Herbst 2015 explizit mit Blick auf Microservices veröffentlicht. Aus Kompatibilitätsgründen unterstützt etcd weiterhin JSON-Endpunkte über ein Gateway, das die RESTful JSON-API nach gRPC übersetzt. Das neue Kommunikationsmodell soll Nachrichten etwa doppelt so schnell verarbeiten wie ein (bereits optimierter) etcd2-Datenaustausch.

Bereits etcd2 nutzte TTL (Time-to-live) für Schlüssel mit einer begrenzten Lebensdauer. Häufig kam es aber wohl vor, dass Clients die Lebenszeit der Schlüssel verlängerten, was zusätzlichen Netzwerkverkehr und Rechenlast zur Folge hatte. etcd3 erweitert das Prinzip nun um sogenannte Leases, zu Deutsch quasi Miete, die es auch schon in anderen Systemen gibt. Statt jedem Schlüssel eine Haltbarkeit zuzuweisen, speichert das System die Lebensdauer in Leases, die wiederum an mehrere Schlüssel angehängt werden. Sobald der Lease das vorgegebene Haltbarkeitsdatum überschreitet, löscht das System alle verbundenen Schlüssel.

Multiplexing zur Schlüsselüberwachung

Die nächste große Änderung betrifft die Überwachungsfunktion der Schlüssel, mit der etcd mitbekommt, wenn sich ein Schlüssel ändert. etcd2 muss für jede Überwachung eine TCP/IP-Verbindung offen halten. Bei Anwendungen, in denen tausende Clients tausende Schlüssel überwachen, stößt das System hinsichtlich der Speicherressourcen und Netzwerk-Sockets irgendwann an seine Grenzen. Die etcd3-API verwendet TCP/IP-Multiplexing, kombiniert also mehrere Überwachungen auf einer Verbindung. Der Client registriert einen sogenannten Watcher auf einem bidirektionalen gRPC-Stream. Letztere verwaltet mehrere Watcher, und eine TCP-Verbindung kann mehrere Streams zusammenfassen.

Trendthema Microservices

Mit den Optimierungen trägt etcd3 unter anderem der Tatsache Rechnung, dass es immer häufiger in Microservices zum Einsatz kommt, die jeweils nur einen kleinen, in sich geschlossenen Teil der Anwendung abbilden. Das erleichtert den Austausch einzelner Komponenten und beschleunigt in der Regel die Entwicklung, da das Team jeweils nur einen überschaubarer Part aktualisiert. Bei einer entsprechenden Infrastruktur funktioniert die Anwendung auch dann weitgehend, wenn einzelne Komponenten ausfallen. Damit das Zusammenspiel funktioniert, benötigt das System eine gute Verwaltungsinfrastruktur, deren Basis mit etcd gegeben ist. Je kleiner und damit zahlreicher die einzelnen Komponenten werden, umso größer wird gleichzeitig der Verwaltungsaufwand, und auch der Netzwerkverkehr nimmt zu.

Weitere Details zu etcd3 stehen im Blog-Beitrag. Die Software selbst liegt auf GitHub. Dort sind sowohl der unter Apache-2-Lizenz stehende Sourcecode als auch etcd-v3.0.0-Binaries für Linux, Windows und OS X zu finden. In Kubernetes ist die die aktuelle Version bereits integriert.

Siehe dazu auf heise Developer:

• Verteilte Systeme mit Etcd in der Praxis

(rme)