Strategiewetten in Phase 1

Wette 1: Das MVP-Produkt wird anfangs nur für wenige Kunden entwickelt. Beim Untersuchen der anfänglichen Eignung des Produkts für einen Markt wird man leicht abgelenkt. Wir beschlossen, einigen wenigen internen Kunden mit hoher Priorität und großem Umfang zu helfen und uns später um die Skalierung der Kundenbasis zu kümmern.

Durch diese Entscheidung waren wir zum einen in der Lage, uns auf den Kern des Produkts zu konzentrieren. Zum anderen waren wir uns bewusst, worin wir nicht investieren mussten. Beispielsweise nutzten wir eine einfache Tabelle anstelle einer vollwertigen Plattform für die Pflege von Kundennamen, E-Mail-Adressen und Metadaten pro Pipeline, um die Bereitstellung beim Kunden in der MVP-Phase zu vereinfachen.

Wette 2: Gemeinsame Entwicklung mit Technologiepartnern, auch wenn noch kein idealer Reifegrad erreicht ist, anstatt das Rad nochmal neu zu erfinden. Auf diese Weise konnten wir die Umgebungen gemeinsam entwickeln. Wir haben uns früh für Partnerschaften entschieden.

• Streamingpartner: Extern haben wir mit Partnern zusammengearbeitet, die branchenweit bei der Streamverarbeitung führend sind. Dazu gehören Linkedin (Kafka- und Samza-Team), Confluent, Data Artisan (Entwickler hinter Apache Flink, später umbenannt in Veverica). So konnten entsprechend unserer Bedürfnisse zum Betriebsunterstützungssystem (OSS) beitragen und gleichzeitig die gemeinschaftliche Arbeit nutzen.
• Partner bei der Containerisierung: 2015 befand sich die Virtualisierungstechnologie mit Containern noch in einer frühen Phase. Wir brauchten schnell eine Strategie für die Bereitstellung. Intern gingen wir eine Partnerschaft mit der neu geschaffenen Containerinfrastruktur, dem Titus-Team, ein. Titus baute auf Apache Mesos auf und stellte Funktionen für die Verwaltung, Planung und isolierte Bereitstellung von Rechenressourcen über eine abstrahierte API bereit. Titus wurde später so weiterentwickelt, dass es Anfang der 2020er Jahre K8S nutzte. Das zugehörige Team schaffte es, alle Workloads transparent zu migrieren. Dank dieser Partnerschaft mussten wir uns keine Gedanken über die zugrundeliegende Recheninfrastruktur machen, während wir die Datenplattform aufbauten.

Im Verlauf dieser Zusammenarbeit blieben wir in ständigem Kontakt, um Erfahrungen auszutauschen und Feedback zu geben. Alle zwei Wochen fanden Meetings mit engen Partnern statt, um Zielsetzungen abzustimmen und Probleme und Lösungen zu besprechen. Wenn Hindernisse auftraten, kümmerten sich sofort die richtigen Menschen darum.

Wette 3: Bedenken trennen, anstatt sie zu ignorieren. Wir haben die Bedenken in Bezug auf operative und analytische Anwendungsfälle voneinander getrennt. Wir haben Mantis (mit Fokus auf operativem Geschäft) und Keystone (mit Fokus auf Analysen) separat entwickelt, dabei allerdings Raum für eine Schnittstelle zwischen beiden Systemen geschaffen.

• 

Trennung der Bedenken für unterschiedliche Szenarien bei der Streamverarbeitung (Bild: Zhenzhong Xu)

Die Bedenken zwischen Herstellern und Verbrauchern haben wir voneinander getrennt. Wir haben Hersteller- und Verbraucher-Clients eingeführt, die mit standardisierten Netzwerkprotokollen und einer einfachen Schemaverwaltung ausgestattet wurden, um den Entwicklungsworkflow zwischen Herstellern und Verbrauchern leichter zu entkoppeln. Das stellte sich später als grundlegender Aspekt bei der Data Governance und der Datenqualitätskontrolle heraus.

Auch die Zuständigkeiten für Komponenten haben wir voneinander getrennt. Anfangs nutzten wir ein an Mikroservices ausgerichtetes Prinzip mit Einzelverantwortung, bei dem die gesamte Infrastruktur aufgeteilt wurde in die Bereiche Messaging (Streamingtransport), Verarbeitung (Streamverarbeitung) und Steuerungsplattform (in dieser Phase war die Plattform nur ein Skript, das später zu einem kompletten System ausgebaut wurde).

Die Trennung der Zuständigkeit für die Komponenten ermöglichte es dem Team, frühzeitig Schnittstellen aufeinander abzustimmen und gleichzeitig die Produktivität des Teams durch den parallelen Schwerpunkt auf verschiedene Bestandteile zu steigern.

Wette 4: Investition in den Aufbau eines Systems, bei dem Ausfälle erwartet und alle Abläufe überwacht werden, anstelle von verzögerten Investitionen. Aufgrund der elastischen, sich konstant ändernden Merkmale der Cloud mit höherer Ausfallwahrscheinlichkeit müssen wir das System so aufbauen, dass alle Arten von Ausfällen überwacht, erkannt und verkraftet werden können.

Die Ausfälle können beispielsweise von Netzwerkaussetzern über den Ausfall von Instanzen, Zonen und Clustern bis hin zu Überlastung und Gegendruck zwischen Services sowie Ausfällen bei örtlichen Katastrophen reichen.

Wir haben in den Ausbau der Systeme in der Annahme investiert, dass konstant Ausfälle auftreten. Wir haben uns ganz früh Devops-Praktiken verschrieben: Szenarien, die für Ausfälle entwickelt wurden, rigorose Automatisierung, kontinuierliches Deployment, Schattentests, automatisierte Überwachung und Warnungen und vieles mehr. Dank dieser Devops-Grundlage gelang uns eine herausragende technische Agilität mit mehreren Bereitstellungen pro Tag.

Veränderungen sind nur möglich, wenn Fehler gemacht werden dürfen

Wir haben viele Fehler gemacht. Am Tag des Produktstarts ist eigentlich alles schief gegangen und wir hatten einen unternehmensweiten Vorfall mit massiven Datenverlusten. Nach der Untersuchung des Vorfalls stellte sich heraus, dass trotz einer korrekten Schätzung des Wachstums beim Datenverkehr der monströse Kafka-Cluster (mit mehr als 200 Brokern), den wir aufgebaut hatten, zu groß war und schließlich an seine Skalierungsgrenze kam.

Als ein Broker ausfiel, konnte der Cluster die Wiederherstellung aufgrund der (damaligen) Beschränkungen in Kafka in Bezug auf die Anzahl an Brokern und Partitionen nicht selbst durchführen. Das gesamte System verschlechterte sich so lange, bis keine Wiederherstellung mehr möglich war.

Ein Ausfall in diesem Maßstab war eine schreckliche Erfahrung. Aber dank unserer psychologisch sicheren Teamumgebung haben wir mit allen Beteiligten transparent kommuniziert und die Erfahrungen schnell in dauerhafte Lösungen umgesetzt. Für diesen besonderen Fall entwickelten wir Möglichkeiten mit einer feingranulareren Cluster-Isolierung (kleinere Kafka-Cluster und isolierter Zookeeper), um den Auswirkungsradius einzudämmen.

Aber es gab noch viele weitere Ausfälle. Als wir durch die Ursachen pflügten, mussten wir feststellen, dass wir auf keinen Fall alle noch so abseitigen Szenarien durchspielen konnten, besonders bei unserem Aufbau auf einer verwalteten Cloud, bei der Änderungen häufig außerhalb unserer Kontrolle passieren, wie die Beendigung von Instanzen oder die Mandanten-Colocation.

Gleichzeitig wird unser Produkt von sehr vielen Menschen genutzt und ist eigentlich zu wichtig, um auszufallen. Es wurde zu unserem Arbeitsprinzip, unsere Abläufe immer auf das Worst-Case-Szenario vorzubereiten.

Nach dem Vorfall führten wir eine wöchentliche Ausfallübung für den Kafka-Cluster ein. Jede Woche musste die zuständige Person einen Ausfall des Kafka-Clusters simulieren. Das Team musste sicherstellen, dass die automatisierte Ausfallsicherung funktionierte und den gesamten Datenverkehr mit minimalen Auswirkungen auf die Nutzer auf einen stabilen Cluster migrieren. Mehr über dieses Vorgehen bietet dieses ausführliche Video zu diesem Thema.