L’architecture technique d’edge computing de Chick-fil-A : Enterprise Restaurant Compute

xguru · 2023-01-23T11:11:02+09:00

La chaîne de restauration rapide au poulet Chick-fil-A exploite un cluster Kubernetes en edge dans chaque restaurant Tous les équipements de chaque site (friteuses, grills, etc.) fournissent en continu des informations de télémétrie IoT, ce qui représente des dizaines de milliers d’appareils connectés À partir de ces données, l’entreprise effectue des prévisions de demande en temps réel, puis les envoie vers le cloud où s’exécutent les processus d’analyse Tout est intégré, des processus de cuisson internes aux terminaux de paiement mobile (drive-thru) Plateforme Restaurant Edge Compute Beaucoup de systèmes actuels sont conçus pour le cloud et les datacenters Ils ne sont pas adaptés à des environnements aux ressources limitées, avec une connexion Internet médiocre, ni à des milliers de clusters Kubernetes L’entreprise a donc décidé de construire sa propre solution. Elle a créé un MVP et a commencé à apprendre en le déployant réellement Matériel Il a été décidé d’utiliser des Intel NUC grand public En regroupant des générations de NUC pour former des clusters à 3 nœuds, l’architecture reste flexible afin de couvrir la fiabilité, la capacité et la haute disponibilité OS La première version utilisait Ubuntu comme OS de base L’objectif de conception était simplement d’expédier les NUC directement aux restaurants, sans configuration manuelle spécifique à chaque site En d’autres termes, tout le provisioning fonctionne dynamiquement, à la volée Bien sûr, certaines fonctions de sécurité empêchent d’autres appareils de rejoindre le cluster ou d’accéder aux services cloud internes Edge Commander Processus de bootstrap et de gestion du cluster Chaque nœud du cluster edge est construit à partir de la même image Il comprend aussi des astuces s’appuyant sur plusieurs partitions de disque et sur OverlayFS Par exemple, pour conserver certaines données à long terme ou effacer à distance d’autres partitions d’un nœud avec une fonction de type « Wipe » Kubernetes L’équipe a choisi l’implémentation K3s Compatible avec la spécification Kubernetes, mais avec certaines fonctions retirées. Elle est très simple à configurer et à supporter à grande échelle Comme il ne s’agit pas d’un usage cloud, toutes les fonctions de Kubernetes ne sont pas nécessaires L’équipe en est très satisfaite et ne prévoit pas de changer GitOps Lors de la création de la première release de la plateforme, il n’existait pas de solution d’agent GitOps capable de fonctionner sur un edge aux ressources limitées L’équipe a donc développé son propre agent, appelé Vessel Il interroge un dépôt Git (un dépôt unique pour chaque magasin) et traite les changements du cluster Une instance open source de GitLab est hébergée sur un cluster Kubernetes dans le cloud L’équipe ne voulait pas porter la charge d’exploiter elle-même un serveur Git, mais n’a pas trouvé de modèle de licence économiquement efficace pour une solution d’hébergement Déploiements Pour GitOps, chaque site pointe vers son propre dépôt Git (appelé Atlas) Un nouveau déploiement dans un restaurant est possible en fusionnant une nouvelle configuration dans la branche master d’Atlas Cette approche implique quelques compromis pour l’administration d’entreprise, mais elle a grandement simplifié la gestion de l’état des déploiements et leur audit Supporter un déploiement à l’échelle de toute la chaîne Le plus grand défi a été de passer du MVP à une plateforme scalable, maintenable et supportable par une très petite équipe Stratégie API First La première priorité métier a été d’encapsuler tous les processus manuels et toutes les étapes de validation dans des API RESTful Après avoir créé une suite d’API complète pour chaque étape, l’équipe a commencé à construire une couche d’orchestration par-dessus afin d’automatiser les processus manuels En créant un projet Postman complet et bien documenté, elle a pu exploiter rapidement les nouvelles API et repousser la création d’une Web UI pour les équipes de support Grâce à OAuth, la suite d’API proposait un accès granulaire étape par étape. Il était facile de verrouiller certaines fonctions ou d’ouvrir aux clients des endpoints d’état et de reporting non invasifs Équipe dédiée au déploiement Comment tant d’équipements ont-ils pu être déployés dans toute la chaîne en peu de temps ? L’équipe cœur de développement étant très réduite, il était difficile de couvrir à la fois le support et le développement de la plateforme, ainsi que le rollout à l’échelle de la chaîne Trois NUC étaient expédiés et installés à l’avance avant le rollout complet ; il ne restait ensuite que les étapes de configuration et de validation Comme la suite d’API était déjà opérationnelle, il a été possible de constituer rapidement une « équipe de support semi-technique » dédiée au lancement de la plateforme, au monitoring de son état et à la résolution de problèmes simples En s’appuyant sur le pair-support, des playbooks et une boucle de feedback documentaire, l’équipe de rollout a pu monter rapidement en compétence En quelques semaines, l’équipe est devenue autonome et a permis le déploiement sur l’ensemble de la chaîne Ensuite, une structure plus organisée a permis de continuer à ajouter de nouvelles fonctions et à s’étendre, tout en maintenant un excellent niveau de support de la plateforme L’objectif était d’automatiser les aspects opérationnels et de pousser les tâches de support restantes au niveau le plus élevé possible dans la chaîne de support Cela a été obtenu grâce à une boucle de feedback entre la First Tier Support et l’équipe Support DevOps Tous les incidents commencent au niveau du premier niveau de support Les problèmes non résolus, ou les cas nouveaux et complexes, sont transmis à l’équipe Support DevOps Les deux équipes collaborent pour résoudre le problème, tandis que l’équipe First Tier met à jour la documentation et les playbooks afin de pouvoir traiter directement les cas similaires à l’avenir Les rétrospectives hebdomadaires de support ajoutent au backlog de l’équipe DevOps des pistes d’amélioration et d’automatisation L’équipe Support DevOps influe aussi sur le backlog des nouvelles équipes de développement afin de prioriser les nouveaux outils ou les améliorations du support Monitoring et auto-remédiation Il existe plus de 2 500 clusters K3s Il a fallu améliorer les processus de monitoring afin d’identifier et de corriger de manière proactive tous les problèmes des clusters. Une approche multidimensionnelle a été développée Client synthétique Un client synthétique, exécuté sous forme de conteneur dans le cluster, a été construit pour tester les fonctions clés de la plateforme et analyser les problèmes (incidents de service, latence des données, etc.) Lorsqu’un problème est détecté, le client le signale au cloud control plane via une API. Une alerte est envoyée à l’équipe de support et un processus automatisé de remédiation est lancé Heartbeats des nœuds Les clusters Kubernetes ayant des fonctions d’auto-réparation, les workloads sont automatiquement rééquilibrés entre les nœuds actifs même en cas de panne d’un nœud Pour détecter les pannes de nœud, un simple « Heartbeat Pod » a été déployé sur chaque nœud du cluster Ce pod remonte périodiquement son état vers un endpoint d’API dans le cloud Auto-remédiation Grâce aux rétrospectives hebdomadaires de support, des motifs récurrents ont été repérés entre les erreurs, leur validation et les étapes de correction Comme tous les outils de support sont basés sur des API, il a été possible de construire des flux d’orchestration autour de ces API et de mettre en place des corrections automatiques pour les problèmes fréquents Nouvelles capacités Tout en poursuivant l’amélioration de l’infrastructure, l’équipe de développement a continué à concevoir de nouvelles fonctions de plateforme pour améliorer le self-service et la facilité de support Orchestration des déploiements Le modèle GitOps utilisé est simple Au départ, les changements étaient manuels, mais un outil appelé « Fleet » a rapidement été créé pour permettre des changements de cluster et des déploiements sur plusieurs restaurants À mesure que la plateforme grandissait, il est devenu nécessaire de disposer d’un moyen de déployer à l’échelle de toute la chaîne et de vérifier les succès comme les échecs des déploiements Dans une deuxième itération, une nouvelle API d’orchestration des déploiements a été développée Avec cette API, un agent de feedback a été déployé sur chaque cluster afin de remonter vers le cloud les informations de déploiement et d’état Cela a permis de créer des releases à l’échelle de toute la chaîne ainsi que des patterns de déploiement canary autogérés Grâce à ce changement, l’équipe a pu ajuster finement et observer les déploiements, ce qui a renforcé leur fiabilité Exfiltration des logs Au départ, l’équipe DevOps interne était autorisée à accéder directement aux clusters K3s des restaurants pour récupérer l’état en temps réel et consulter les logs Une fonction basique d’exfiltration des logs existait, mais elle était très difficile à utiliser à cause de la latence et des problèmes réseau Comme l’objectif était de minimiser l’accès distant aux clusters, des endpoints d’API ont été ajoutés Une fonction d’exfiltration des logs plus robuste a désormais été mise en place L’open source Vector est utilisé pour collecter et transférer les logs depuis les clusters edge vers le cloud Il fournit des fonctions de filtrage, de stockage et transfert, ainsi que de rotation automatique des logs Côté cloud, d’autres services Vector sont configurés pour collecter les logs de tous les sites edge, appliquer des règles et les transférer vers divers outils (Data Dog, Grafana, CloudWatch, etc.) Métriques et tableaux de bord En utilisant Prometheus Remote Write, une fonction a été ajoutée pour collecter les métriques de tous les restaurants et les envoyer vers un Grafana centralisé dans le cloud Chaque cluster K3s capture l’état, les nœuds et les workloads des services essentiels Une fonction permettant de publier des métriques métier personnalisées a aussi été ajoutée Conclusion La « Restaurant Compute Platform » et ses processus de support ont atteint un niveau de maturité suffisant pour offrir une forte stabilité et un haut niveau de support client avec une petite équipe de développement Enseignements Pour qu’une petite équipe construise une plateforme d’edge computing critique pour le métier sous forme de MVP, il a fallu une excellente ingénierie et des compromis judicieux Exploiter plus de 2 500 clusters Kubernetes avec une petite équipe est extrêmement difficile, mais une approche d’automatisation API-first a beaucoup aidé Quand on vient d’un monde cloud-first, le plus grand défi est que l’edge impose des contraintes (capacité de calcul, bande passante réseau limitée, accès distant) Il est utile d’investir beaucoup de temps pour comprendre ces contraintes, puis de réfléchir à la possibilité de les éliminer — ce qui coûte du temps et de l’argent — ou de les gérer

(medium.com)

36 points par xguru 2023-01-23 | 5 commentaires | Partager sur WhatsApp

La chaîne de restauration rapide au poulet Chick-fil-A exploite un cluster Kubernetes en edge dans chaque restaurant
Tous les équipements de chaque site (friteuses, grills, etc.) fournissent en continu des informations de télémétrie IoT, ce qui représente des dizaines de milliers d’appareils connectés
À partir de ces données, l’entreprise effectue des prévisions de demande en temps réel, puis les envoie vers le cloud où s’exécutent les processus d’analyse
Tout est intégré, des processus de cuisson internes aux terminaux de paiement mobile (drive-thru)

Plateforme Restaurant Edge Compute

Beaucoup de systèmes actuels sont conçus pour le cloud et les datacenters
Ils ne sont pas adaptés à des environnements aux ressources limitées, avec une connexion Internet médiocre, ni à des milliers de clusters Kubernetes
L’entreprise a donc décidé de construire sa propre solution. Elle a créé un MVP et a commencé à apprendre en le déployant réellement

Matériel

Il a été décidé d’utiliser des Intel NUC grand public
En regroupant des générations de NUC pour former des clusters à 3 nœuds, l’architecture reste flexible afin de couvrir la fiabilité, la capacité et la haute disponibilité

OS

La première version utilisait Ubuntu comme OS de base
L’objectif de conception était simplement d’expédier les NUC directement aux restaurants, sans configuration manuelle spécifique à chaque site
En d’autres termes, tout le provisioning fonctionne dynamiquement, à la volée
Bien sûr, certaines fonctions de sécurité empêchent d’autres appareils de rejoindre le cluster ou d’accéder aux services cloud internes

Edge Commander

Processus de bootstrap et de gestion du cluster
Chaque nœud du cluster edge est construit à partir de la même image
Il comprend aussi des astuces s’appuyant sur plusieurs partitions de disque et sur OverlayFS
- Par exemple, pour conserver certaines données à long terme ou effacer à distance d’autres partitions d’un nœud avec une fonction de type « Wipe »

Kubernetes

L’équipe a choisi l’implémentation K3s
- Compatible avec la spécification Kubernetes, mais avec certaines fonctions retirées. Elle est très simple à configurer et à supporter à grande échelle
Comme il ne s’agit pas d’un usage cloud, toutes les fonctions de Kubernetes ne sont pas nécessaires
L’équipe en est très satisfaite et ne prévoit pas de changer

GitOps

Lors de la création de la première release de la plateforme, il n’existait pas de solution d’agent GitOps capable de fonctionner sur un edge aux ressources limitées
L’équipe a donc développé son propre agent, appelé Vessel
Il interroge un dépôt Git (un dépôt unique pour chaque magasin) et traite les changements du cluster
Une instance open source de GitLab est hébergée sur un cluster Kubernetes dans le cloud
L’équipe ne voulait pas porter la charge d’exploiter elle-même un serveur Git, mais n’a pas trouvé de modèle de licence économiquement efficace pour une solution d’hébergement

Déploiements

Pour GitOps, chaque site pointe vers son propre dépôt Git (appelé Atlas)
Un nouveau déploiement dans un restaurant est possible en fusionnant une nouvelle configuration dans la branche master d’Atlas
Cette approche implique quelques compromis pour l’administration d’entreprise, mais elle a grandement simplifié la gestion de l’état des déploiements et leur audit

Supporter un déploiement à l’échelle de toute la chaîne

Le plus grand défi a été de passer du MVP à une plateforme scalable, maintenable et supportable par une très petite équipe

Stratégie API First

La première priorité métier a été d’encapsuler tous les processus manuels et toutes les étapes de validation dans des API RESTful
Après avoir créé une suite d’API complète pour chaque étape, l’équipe a commencé à construire une couche d’orchestration par-dessus afin d’automatiser les processus manuels
En créant un projet Postman complet et bien documenté, elle a pu exploiter rapidement les nouvelles API et repousser la création d’une Web UI pour les équipes de support
Grâce à OAuth, la suite d’API proposait un accès granulaire étape par étape. Il était facile de verrouiller certaines fonctions ou d’ouvrir aux clients des endpoints d’état et de reporting non invasifs

Équipe dédiée au déploiement

Comment tant d’équipements ont-ils pu être déployés dans toute la chaîne en peu de temps ?
L’équipe cœur de développement étant très réduite, il était difficile de couvrir à la fois le support et le développement de la plateforme, ainsi que le rollout à l’échelle de la chaîne
Trois NUC étaient expédiés et installés à l’avance avant le rollout complet ; il ne restait ensuite que les étapes de configuration et de validation
Comme la suite d’API était déjà opérationnelle, il a été possible de constituer rapidement une « équipe de support semi-technique » dédiée au lancement de la plateforme, au monitoring de son état et à la résolution de problèmes simples
En s’appuyant sur le pair-support, des playbooks et une boucle de feedback documentaire, l’équipe de rollout a pu monter rapidement en compétence
En quelques semaines, l’équipe est devenue autonome et a permis le déploiement sur l’ensemble de la chaîne
Ensuite, une structure plus organisée a permis de continuer à ajouter de nouvelles fonctions et à s’étendre, tout en maintenant un excellent niveau de support de la plateforme
L’objectif était d’automatiser les aspects opérationnels et de pousser les tâches de support restantes au niveau le plus élevé possible dans la chaîne de support
Cela a été obtenu grâce à une boucle de feedback entre la First Tier Support et l’équipe Support DevOps
- Tous les incidents commencent au niveau du premier niveau de support
- Les problèmes non résolus, ou les cas nouveaux et complexes, sont transmis à l’équipe Support DevOps
- Les deux équipes collaborent pour résoudre le problème, tandis que l’équipe First Tier met à jour la documentation et les playbooks afin de pouvoir traiter directement les cas similaires à l’avenir
- Les rétrospectives hebdomadaires de support ajoutent au backlog de l’équipe DevOps des pistes d’amélioration et d’automatisation
- L’équipe Support DevOps influe aussi sur le backlog des nouvelles équipes de développement afin de prioriser les nouveaux outils ou les améliorations du support

Monitoring et auto-remédiation

Il existe plus de 2 500 clusters K3s
Il a fallu améliorer les processus de monitoring afin d’identifier et de corriger de manière proactive tous les problèmes des clusters. Une approche multidimensionnelle a été développée

Client synthétique

Un client synthétique, exécuté sous forme de conteneur dans le cluster, a été construit pour tester les fonctions clés de la plateforme et analyser les problèmes (incidents de service, latence des données, etc.)
Lorsqu’un problème est détecté, le client le signale au cloud control plane via une API. Une alerte est envoyée à l’équipe de support et un processus automatisé de remédiation est lancé

Heartbeats des nœuds

Les clusters Kubernetes ayant des fonctions d’auto-réparation, les workloads sont automatiquement rééquilibrés entre les nœuds actifs même en cas de panne d’un nœud
Pour détecter les pannes de nœud, un simple « Heartbeat Pod » a été déployé sur chaque nœud du cluster
Ce pod remonte périodiquement son état vers un endpoint d’API dans le cloud

Auto-remédiation

Grâce aux rétrospectives hebdomadaires de support, des motifs récurrents ont été repérés entre les erreurs, leur validation et les étapes de correction
Comme tous les outils de support sont basés sur des API, il a été possible de construire des flux d’orchestration autour de ces API et de mettre en place des corrections automatiques pour les problèmes fréquents

Nouvelles capacités

Tout en poursuivant l’amélioration de l’infrastructure, l’équipe de développement a continué à concevoir de nouvelles fonctions de plateforme pour améliorer le self-service et la facilité de support

Orchestration des déploiements

Le modèle GitOps utilisé est simple
Au départ, les changements étaient manuels, mais un outil appelé « Fleet » a rapidement été créé pour permettre des changements de cluster et des déploiements sur plusieurs restaurants
À mesure que la plateforme grandissait, il est devenu nécessaire de disposer d’un moyen de déployer à l’échelle de toute la chaîne et de vérifier les succès comme les échecs des déploiements
Dans une deuxième itération, une nouvelle API d’orchestration des déploiements a été développée
- Avec cette API, un agent de feedback a été déployé sur chaque cluster afin de remonter vers le cloud les informations de déploiement et d’état
Cela a permis de créer des releases à l’échelle de toute la chaîne ainsi que des patterns de déploiement canary autogérés
Grâce à ce changement, l’équipe a pu ajuster finement et observer les déploiements, ce qui a renforcé leur fiabilité

Exfiltration des logs

Au départ, l’équipe DevOps interne était autorisée à accéder directement aux clusters K3s des restaurants pour récupérer l’état en temps réel et consulter les logs
Une fonction basique d’exfiltration des logs existait, mais elle était très difficile à utiliser à cause de la latence et des problèmes réseau
Comme l’objectif était de minimiser l’accès distant aux clusters, des endpoints d’API ont été ajoutés
Une fonction d’exfiltration des logs plus robuste a désormais été mise en place
L’open source Vector est utilisé pour collecter et transférer les logs depuis les clusters edge vers le cloud
- Il fournit des fonctions de filtrage, de stockage et transfert, ainsi que de rotation automatique des logs
- Côté cloud, d’autres services Vector sont configurés pour collecter les logs de tous les sites edge, appliquer des règles et les transférer vers divers outils (Data Dog, Grafana, CloudWatch, etc.)

Métriques et tableaux de bord

En utilisant Prometheus Remote Write, une fonction a été ajoutée pour collecter les métriques de tous les restaurants et les envoyer vers un Grafana centralisé dans le cloud
Chaque cluster K3s capture l’état, les nœuds et les workloads des services essentiels
Une fonction permettant de publier des métriques métier personnalisées a aussi été ajoutée

Conclusion

La « Restaurant Compute Platform » et ses processus de support ont atteint un niveau de maturité suffisant pour offrir une forte stabilité et un haut niveau de support client avec une petite équipe de développement

Enseignements

Pour qu’une petite équipe construise une plateforme d’edge computing critique pour le métier sous forme de MVP, il a fallu une excellente ingénierie et des compromis judicieux
Exploiter plus de 2 500 clusters Kubernetes avec une petite équipe est extrêmement difficile, mais une approche d’automatisation API-first a beaucoup aidé
Quand on vient d’un monde cloud-first, le plus grand défi est que l’edge impose des contraintes (capacité de calcul, bande passante réseau limitée, accès distant)
Il est utile d’investir beaucoup de temps pour comprendre ces contraintes, puis de réfléchir à la possibilité de les éliminer — ce qui coûte du temps et de l’argent — ou de les gérer

5 commentaires

ddwax89 2023-01-24

C’est impressionnant haha

ragingwind 2023-01-23

Ils l’ont vraiment construit de A à Z. Cela donne aussi beaucoup d’inspiration sur le processus de mise en œuvre.

nicewook 2023-01-23

C’est un cas vraiment formidable et enthousiasmant. J’aimerais bien en construire un comme ça moi aussi.
Le fait que le sujet remonte à 2018 est plutôt rassurant, non ? Ce n’est donc pas quelque chose qui a été bricolé du jour au lendemain.
Je devrai le relire tranquillement une fois de plus plus tard.

kbumsik 2023-01-23

Le chicken burger de Chick-fil-A est vraiment délicieux haha

Un billet sur le même sujet avait déjà été publié en 2018 ; à l’époque, cela donnait une impression assez expérimentale, mais visiblement ils l’ont maintenu jusqu’à aujourd’hui. On voit aussi dans l’article que tout le savoir-faire accumulé entre-temps s’y reflète.

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

xguru 2023-01-23

L’enseigne n’est pas présente en France et y est donc quasiment inconnue, mais c’est aussi un restaurant très populaire auprès des adolescents, arrivant toujours en tête de leurs préférences parmi les chaînes de restauration dans l’enquête sur les entreprises préférées des adolescents américains, publiée deux fois par an par Piper Sandler.