Chick-Fil-As Edge-Computing-Technologiearchitektur: Enterprise Restaurant Compute

• Die Fast-Food-Kette Chick-Fil-A betreibt in jedem Restaurant einen Edge-Kubernetes-Cluster
• Alle Geräte in jeder Filiale (Fritteusen, Grills usw.) liefern kontinuierlich IoT-Telemetriedaten, sodass Zehntausende Geräte verbunden sind
• Auf Basis dieser Informationen werden in Echtzeit Nachfrageprognosen erstellt und an die Cloud gesendet, wo Analyseprozesse ausgeführt werden
• Alles ist integriert, von internen Kochprozessen bis hin zu mobilen Zahlungsterminals (Drive-through)

Restaurant Edge Compute Platform

• Viele heutige Systeme sind auf Cloud-/Rechenzentrumsumgebungen ausgerichtet
• Sie eignen sich nicht für ressourcenbeschränkte Umgebungen, unzuverlässige Internetverbindungen und Tausende Kubernetes-Cluster
• Deshalb entschied man sich, die Plattform selbst zu bauen. Man erstellte ein MVP und begann durch echte Installationen zu lernen

Hardware

• Man entschied sich für handelsübliche Intel NUCs
• Durch das Bündeln von NUC-Generationen zu 3-Node-Clustern blieb man flexibel genug, um Zuverlässigkeit, Kapazität und HA-Anforderungen abzudecken

OS

• Für das erste Release wurde Ubuntu als Basis-OS verwendet
• Das Designziel war, die NUCs einfach direkt an die Restaurants zu liefern, ohne manuelle Einrichtung pro Standort
• Das heißt, das gesamte Provisioning läuft dynamisch on-the-fly
• Natürlich verhindern einige Sicherheitsfunktionen, dass andere Geräte dem Cluster beitreten oder auf interne Cloud-Services zugreifen

Edge Commander

• Der Prozess für Cluster-Bootstrapping und -Management
• Jeder Edge-Cluster-Node wird mit demselben Image aufgebaut
• Enthält auch Tricks mit mehreren Festplattenpartitionen und OverlayFS
  • Zum Beispiel, um bestimmte Daten langfristig zu behalten oder andere Partitionen eines Nodes per Fernzugriff zu löschen ("Wipe")

Kubernetes

• Man entschied sich für die K3s-Implementierung
  • Sie ist mit der Kubernetes-Spezifikation kompatibel, entfernt aber einige Funktionen. Konfiguration und Support in großem Maßstab werden dadurch sehr einfach
• Da keine Cloud genutzt wird, werden nicht alle Kubernetes-Funktionen benötigt
• Man ist damit sehr zufrieden und plant keinen Wechsel

GitOps

• Als die erste Plattform-Release aufgebaut wurde, gab es keine GitOps-Agent-Lösung, die auf ressourcenbeschränkten Edge-Umgebungen laufen konnte
• Daher wurde ein eigener Agent namens Vessel entwickelt
• Er pollt Git-Repos (ein eigenes Repo pro Store) und verarbeitet Cluster-Änderungen
• In einem Kubernetes-Cluster in der Cloud wird eine Open-Source-GitLab-Instanz gehostet
• Man wollte eigentlich nicht die Last eines selbst betriebenen Git-Servers tragen, konnte aber kein kosteneffizientes Lizenzmodell für eine Hosting-Lösung finden

Deployments

• Für GitOps weist jede Filiale ihr eigenes Git-Repo zu (genannt Atlas)
• Neue Deployments für jedes Restaurant werden ermöglicht, indem neue Konfigurationen in den Master-Branch von Atlas gemergt werden
• Dieser Ansatz bringt zwar einige Trade-offs für das Enterprise-Management mit sich, vereinfachte aber das Management und Auditieren des Deployment-Status erheblich

Unterstützung eines unternehmensweiten Rollouts

• Die größte Herausforderung war, das MVP in eine skalierbare und supportbare Plattform zu überführen, die ein sehr kleines Team betreiben kann

API-First-Strategie

• Der erste Schritt bestand darin, alle manuellen Prozesse und Validierungsschritte in Restful APIs zu kapseln
• Nachdem eine umfassende API-Suite für jeden Schritt erstellt worden war, baute man darüber eine Orchestrierungsschicht, um die manuellen Prozesse zu automatisieren
• Durch die Erstellung eines umfassenden und gut dokumentierten PostMan-Projekts konnte man neue APIs schnell nutzbar machen und den Aufbau einer Web-UI für das Support-Team hinauszögern
• Mit OAuth wurde ein granularer, schrittweiser Zugriff auf die API-Suite bereitgestellt. So konnten bestimmte Funktionen leicht gesperrt oder für Kunden nicht-invasive Status- und Reporting-Endpunkte geöffnet werden

Dediziertes Rollout-Team

• Wie konnten in kurzer Zeit so viele Geräte in der gesamten Kette ausgerollt werden?
• Das Kernentwicklungsteam war sehr klein, daher war es schwierig, gleichzeitig Plattform-Support, Weiterentwicklung und den Rollout für die gesamte Kette zu stemmen
• Vor dem flächendeckenden Rollout wurden drei NUCs vorab verschickt und installiert; übrig blieben nur Konfigurations- und Validierungsschritte
• Da die API-Suite bereits lief, konnte schnell ein „halbtechnisches Support-Team“ aufgebaut werden, das sich ausschließlich um Plattform-Launches, Status-Monitoring und einfache Supportfälle kümmerte
• Mithilfe von Pair-Support, Playbooks und einer Feedback-Schleife für die Dokumentation wurde das Rollout-Team rasch gestärkt
• Innerhalb weniger Wochen war das Team autark und konnte den Rollout über die gesamte Kette abschließen
• Danach wurde durch eine organisierte Struktur sichergestellt, dass die Plattform auch bei neuen Funktionen und weiterer Expansion hervorragend unterstützt werden konnte
• Ziel war es, praktische Abläufe zu automatisieren und die übrige Support-Arbeit so weit wie möglich nach oben in der Support-Kette zu verlagern
• Erreicht wurde das durch eine Feedback-Schleife zwischen First-Tier-Support und dem Support-DevOps-Team
  • Alle Issues beginnen im First Tier
  • Wenn sie nicht lösbar sind oder neue, komplexe Probleme auftreten, werden sie an das Support-DevOps-Team eskaliert
  • Beide Teams arbeiten gemeinsam an der Lösung, und das First-Tier-Team aktualisiert Dokumentation und Playbooks, damit ähnliche Probleme künftig selbst bearbeitet werden können
  • In wöchentlichen Support-Retrospektiven werden Verbesserungen und Automatisierungsmöglichkeiten in den DevOps-Backlog aufgenommen
  • Außerdem beeinflusst das Support-DevOps-Team den Backlog neuer Entwicklungsteams, um Prioritäten für neue Tools oder bessere Support-Funktionen zu setzen

Monitoring und automatische Fehlerbehebung

• Es gibt mehr als 2500 K3-Cluster
• Der Monitoring-Prozess musste verbessert werden, um alle Cluster-Probleme proaktiv zu erkennen und zu beheben. Dafür wurde ein mehrschichtiger Ansatz entwickelt

Synthetic Client

• Es wurde ein Synthetic Client gebaut, der als Container im Cluster läuft, zentrale Plattformfunktionen testet und Probleme analysiert (Serviceprobleme, Datenlatenz usw.)
• Wenn ein Problem erkannt wird, meldet der Client es per API an die Cloud Control Plane. Das Support-Team wird benachrichtigt und ein automatisierter Remediation-Prozess startet

Node Heartbeats

• Kubernetes-Cluster verfügen über Selbstheilungsmechanismen, sodass Workloads bei Node-Ausfällen automatisch auf aktive Nodes umverteilt werden
• Um Node-Ausfälle zu erkennen, wurde ein einfacher Heartbeat Pod auf jedem Node des Clusters ausgerollt
• Dieser Pod meldet seinen Status periodisch an einen API-Endpunkt in der Cloud

Auto Remediation

• In den wöchentlichen Support-Retrospektiven wurden Muster zwischen Fehlern sowie Prüf- und Behebungsschritten erkannt
• Da alle Support-Tools API-basiert sind, konnten dafür Orchestrierungs-Workflows aufgebaut und Auto-Remediation für häufig auftretende Probleme implementiert werden

Neue Funktionen

• Während die Infrastruktur weiter verbessert wurde, entwickelte das Team fortlaufend neue Plattformfunktionen, um Self-Service und Support-Fähigkeit zu erhöhen

Deployment-Orchestrierung

• Das GitOps-Modell ist einfach
• Anfangs begann man mit manuellen Änderungen, baute aber bald ein Tool namens Fleet, das Cluster-Änderungen und Deployments über mehrere Restaurants hinweg ermöglicht
• Mit dem Wachstum der Plattform wurde eine Möglichkeit nötig, Deployments über die gesamte Kette hinweg auszurollen und Erfolge bzw. Fehlschläge zu verifizieren
• In einer zweiten Iteration wurde eine neue Deployment-Orchestration-API entwickelt
  • Zusammen mit der API wurden Feedback-Agenten in jedem Cluster ausgerollt, die Deployment- und Statusinformationen an die Cloud melden
• Dadurch konnten Releases für die gesamte Kette sowie selbst verwaltbare Canary-Deployment-Muster aufgebaut werden
• Diese Änderung erhöhte die Zuverlässigkeit der Deployments, weil das Team Rollouts feinjustieren und beobachten konnte

Log Exfiltration

• Anfangs hatte das interne DevOps-Team direkten Zugriff auf die K3s-Cluster in den Restaurants, um in Echtzeit Statusdaten abzurufen und Logs zu durchsuchen
• Es gab zwar grundlegende Log-Exfiltration-Funktionen, sie waren jedoch wegen Latenz- und Netzwerkproblemen sehr schwer nutzbar
• Da man den Fernzugriff auf die Cluster minimieren wollte, wurden zusätzliche API-Endpunkte ergänzt
• Inzwischen wurden leistungsfähigere Log-Exfiltration-Funktionen hinzugefügt
• Mithilfe des Open-Source-Tools Vector werden Daten in den Edge-Clustern gesammelt und an die Cloud weitergeleitet
  • Es bietet Filterung, Speicherung und Weiterleitung sowie automatische Log-Rotation
  • Auf der Cloud-Seite wurden weitere Vector-Services eingerichtet, die Logs von allen Edges einsammeln, Regeln anwenden und an verschiedene Tools weiterleiten (Data Dog, Grafana, CloudWatch usw.)

Metriken und Dashboards

• Mit Prometheus Remote Write wurde die Funktion ergänzt, Metriken aus allen Restaurants zu sammeln und an ein zentrales Grafana in der Cloud zu senden
• Jeder K3s-Cluster erfasst den Zustand von Nodes sowie die Workloads zentraler Services
• Zusätzlich wurde die Möglichkeit geschaffen, benutzerdefinierte Business-Metriken zu veröffentlichen

Fazit

• Unsere „Restaurant Compute Platform“ und die dazugehörigen Support-Prozesse sind mittlerweile so weit gereift, dass ein kleines Entwicklungsteam ein hohes Maß an Stabilität und Kundensupport liefern kann

Erkenntnisse

• Damit ein kleines Team eine geschäftskritische Edge-Compute-Plattform als MVP bauen kann, braucht es exzellentes Engineering und kluge Kompromisse
• Mehr als 2500 Kubernetes-Cluster mit einem kleinen Team zu betreiben, ist äußerst anspruchsvoll, aber ein API-first-Automatisierungsansatz war dabei eine große Hilfe
• Aus einer Cloud-first-Welt kommend war die größte Herausforderung, dass Edge mit Einschränkungen verbunden ist (Rechenkapazität, begrenzte Netzwerkbandbreite, Remote Access)
• Es lohnt sich, viel Zeit in das Verständnis dieser Einschränkungen zu investieren und abzuwägen, ob man sie beseitigen will (was viel Zeit und Geld kostet) oder sie stattdessen managen sollte

[ddwax89]

Wirklich beeindruckend haha

[ragingwind]

Wirklich von Grund auf aufgebaut. Auch der Einführungsprozess liefert viele Inspirationen.

[nicewook]

1. Ein wirklich großartiges und spannendes Beispiel. Ich würde auch gern einmal so etwas bauen.
2. Dass das Thema schon seit 2018 läuft, ist dann wohl immerhin beruhigend? Es wurde also nicht über Nacht aus dem Boden gestampft.
   Ich sollte es mir später noch einmal in Ruhe vollständig durchlesen.

[kbumsik]

Das Chick-fil-A-Hähnchenburger ist wirklich superlecker, haha.

Schon 2018 gab es einen Beitrag zum gleichen Thema; damals wirkte es noch etwas experimentell, aber offenbar wurde es bis heute beibehalten. Auch im Text sieht man, dass sich in der Zwischenzeit viel Know-how angesammelt hat.

https://medium.com/@cfatechblog/…

[xguru]

Die Kette ist in Deutschland kaum bekannt, da sie hier nicht vertreten ist, gehört aber in den zweimal jährlich veröffentlichten Umfragen von Piper Sandler zu den Unternehmenspräferenzen amerikanischer Teenager bei Restaurants stets zu den beliebtesten Marken und belegt dort regelmäßig Platz 1.