Slack migriert zu einer zellulären Architektur

• Slack hat in den vergangenen 1,5 Jahren von einer monolithischen Struktur auf eine zellbasierte Struktur (Cellular Architecture) umgestellt, um die Redundanz zu erhöhen und die Auswirkungen von Site-Ausfällen zu begrenzen
• Auslöser war die Notwendigkeit, die Resilienz des Slack-Dienstes nach dem Netzwerkausfall im Juni 2021 zu verbessern, durch den es bei Slack-Kunden zu Servicebeeinträchtigungen kam
• In der zellulären Struktur arbeitet jeder Dienst pro Availability Zone (AZ) als ein virtueller Dienst, sodass ein Ausfall in einer AZ keine Auswirkungen auf andere AZs hat
• Enthalten ist auch eine Funktion zum Drainen des Traffics aus einer problematischen AZ, um sie effektiv vom Rest des Systems zu isolieren
• Der Drain-Mechanismus wurde so konzipiert, dass er schnell, fehlerfrei, schrittweise und unabhängig von den Ressourcen der gerade entleerten AZ funktioniert
• Die Umstellung auf die zelluläre Struktur umfasst auch eine Strategie namens Siloing, bei der Dienste nur innerhalb ihrer eigenen AZ Traffic empfangen und senden. Das hilft dabei, sämtliche Ausfälle innerhalb einer einzelnen AZ einzudämmen
• Die Implementierung des Traffic-Shifting-Mechanismus konzentrierte sich auf das System, das Benutzeranfragen an Kerndienste weiterleitet
• Die neue Struktur unterstützt das Drainen von AZs mithilfe von Envoy-Features wie Weighted Clusters und dynamischer Gewichtungszuweisung über RTDS
• Diese Umstellung hat sowohl die Betriebsweise von Slack als auch die Art und Weise verändert, wie Dienste aufgebaut werden, und liefert leistungsfähige neue Werkzeuge für Traffic-Management und Failure Mitigation
• In künftigen Blogbeiträgen sollen technische Implementierungsdetails tiefer behandelt und die Auswirkungen der neuen Struktur auf den Slack-Betrieb diskutiert werden

[GN⁺]

Hacker-News-Kommentare

• Slacks Umstellung auf eine zellulare Architektur hat aufgrund ihres einzigartigen Ansatzes bei Betrieb und Monitoring Interesse geweckt.
• Die Strategie des Unternehmens besteht darin, Anfragen innerhalb einer einzelnen AWS Availability Zone (AZ) zu bedienen, den Betrieb zu vereinfachen und das Monitoring zu erleichtern.
• Dieser Ansatz ermöglicht es, Vorfälle in einem einzelnen Cluster leicht zu erkennen und abzumildern, indem Metriken zwischen Clustern verglichen werden.
• Diese Strategie führt jedoch zu Redundanzen bei Compute, Cache und anderem, da die meisten Services über mehrere Cluster hinweg laufen müssen.
• Einige Nutzer stellen die Effizienz von Slacks API-Request-System infrage, das sich zu Hunderten von RPCs auf Service-Backends auffächern kann.
• Es gibt eine Debatte über den Unterschied zwischen der Nutzung von AWS-Availability-Zone-Affinität und dem einfachen Ausblenden einer ausgefallenen AZ an einem übergeordneten Routing-Punkt.
• Es wurden Bedenken hinsichtlich der Redundanz geäußert, wenn alles in AWS USE1 betrieben wird, da Probleme im Zusammenhang mit USE1 mehrere Services beeinträchtigen könnten.
• Es wurden Fragen dazu aufgeworfen, wie Nutzerdaten in dieser Architektur behandelt werden, insbesondere bei der Vervielfachung über AZs hinweg.
• Einige Nutzer erinnern sich an ähnliche Architekturen, an denen sie in der Vergangenheit gearbeitet haben, etwa an ein verteiltes Betriebssystem namens Metal Cell.
• Diskutiert wird auch die Möglichkeit, dass ressourcenintensive Jobs in einer isolierten AZ unbegrenzt weiterlaufen, selbst wenn keine neuen Nutzeranfragen mehr eintreffen.
• Nutzer fragen sich, in welcher Programmiersprache Slack derzeit geschrieben ist, und ob es immer noch Hack/PHP ist.
• Einige Nutzer äußern Enttäuschung über Slacks Performance und vergleichen sie nachteilig mit anderen Chat-Apps wie Discord.