La arquitectura tecnológica de edge computing de Chick-fil-A: Enterprise Restaurant Compute

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

La cadena de comida rápida de pollo Chick-fil-A opera un clúster de Kubernetes en el edge en cada restaurante Todos los dispositivos de cada sucursal (freidoras, parrillas, etc.) envían continuamente información de telemetría IoT, por lo que hay decenas de miles de dispositivos conectados A partir de esta información se realizan pronósticos de demanda en tiempo real y se envían a la nube para ejecutar procesos de análisis Todo está integrado, desde los procesos internos de cocina hasta las terminales de pago móvil (drive-thru) Plataforma Restaurant Edge Compute Muchos de los sistemas actuales están pensados para la nube o el centro de datos No son adecuados para entornos con recursos limitados, mala conexión a internet y miles de clústeres de Kubernetes Por eso decidieron construirla ellos mismos. Crearon un MVP y comenzaron a aprender desplegándolo en entornos reales Hardware Decidieron usar Intel NUC de consumo general Agrupando generaciones de NUC, crearon clústeres de 3 nodos para responder con flexibilidad a confiabilidad, capacidad y configuraciones de HA SO En la primera versión usaron Ubuntu como sistema operativo base El objetivo de diseño era simplemente enviar los NUC directamente al restaurante, sin requerir configuración manual por local Es decir, todo el aprovisionamiento funciona de forma dinámica, on-the-fly Por supuesto, incluyeron algunas funciones de seguridad para impedir que otros dispositivos se unan al clúster o accedan a servicios internos en la nube Edge Commander Proceso de bootstrap y administración del clúster Cada nodo del clúster edge se construye con la misma imagen También incluye trucos usando múltiples particiones de disco y OverlayFS Como conservar ciertos datos a largo plazo o borrar de forma remota otras particiones del nodo con una función de "wipe" Kubernetes Decidieron usar la implementación K3s Es compatible con la especificación de Kubernetes, pero elimina algunas funciones. Es muy simple de configurar y dar soporte a gran escala Como no usan la nube, no necesitan todas las capacidades completas de Kubernetes Están muy satisfechos y no planean cambiarlo GitOps Cuando construyeron la primera versión de la plataforma, no existía una solución de agente GitOps que pudiera ejecutarse en el edge con recursos limitados Desarrollaron su propio agente, al que llaman Vessel Hace polling de un repositorio Git (uno único por tienda) y procesa los cambios del clúster Hospedan una instancia open source de GitLab en un clúster de Kubernetes en la nube No querían asumir la carga de operar directamente un servidor Git, pero no pudieron encontrar un modelo de licencias rentable para una solución de hosting Deployments Para GitOps, cada sucursal apunta a su propio repositorio Git, llamado Atlas Un nuevo despliegue en cada restaurante se realiza haciendo merge de una nueva configuración en la rama master de Atlas Este enfoque tiene algunos trade-offs para la gestión empresarial, pero simplificó muchísimo la administración del estado de despliegue y la auditoría Soporte para un despliegue en toda la cadena El mayor reto fue pasar de un MVP a una plataforma escalable, soportable y mantenible por un equipo muy pequeño Estrategia API First La primera prioridad del negocio fue envolver todos los procesos manuales y pasos de validación en APIs RESTful Después de crear una suite completa de APIs para cada etapa, comenzaron a construir una capa de orquestación encima para automatizar los procesos manuales Al crear un proyecto de Postman completo y bien documentado, pudieron aprovechar rápidamente las nuevas APIs y posponer la creación de una Web UI para el equipo de soporte Aprovechando OAuth, ofrecieron acceso granular paso a paso a la suite de APIs. Pudieron bloquear fácilmente funciones específicas o abrir endpoints de estado y reportes no invasivos para clientes Equipo dedicado de rollout ¿Cómo pudieron desplegar tantos dispositivos en toda la cadena en tan poco tiempo? El equipo principal de desarrollo era muy pequeño, así que era difícil encargarse a la vez del soporte y desarrollo de la plataforma y del rollout para toda la cadena Antes del rollout completo, enviaron por adelantado 3 NUC e hicieron la instalación; lo que quedaba eran solo las etapas de configuración y validación Como la suite de APIs ya estaba operando, pudieron formar rápidamente un "equipo de soporte semitécnico" dedicado al lanzamiento de la plataforma, monitoreo de estado y resolución de problemas simples de soporte Fortalecieron rápidamente al equipo de rollout usando pair-support, playbooks y un ciclo de retroalimentación sobre la documentación En pocas semanas, el equipo se volvió autosuficiente y logró el rollout en toda la cadena Después de eso, mediante una estructura organizada, pudieron seguir ampliando la plataforma con nuevas funciones y al mismo tiempo brindar un gran nivel de soporte Su objetivo era automatizar las partes operativas y empujar el resto del trabajo de soporte al nivel más alto posible dentro de la cadena de soporte Lo lograron a través de un ciclo de retroalimentación entre First Tier Support y el equipo Support DevOps Todos los incidentes comienzan en first tier Si no pueden resolverse, o aparece un problema nuevo y complejo, se escalan al equipo Support DevOps Ambos equipos colaboran para resolver el problema, y el equipo de first tier actualiza la documentación y los playbooks para poder manejar directamente casos similares en el futuro Mediante retrospectivas semanales de soporte, agregan mejoras y oportunidades de automatización al backlog del equipo DevOps Además, el equipo Support DevOps influye en el backlog del nuevo equipo de desarrollo para priorizar desde nuevas herramientas hasta mejoras de soporte Monitoreo y autorremediación Tienen más de 2500 clústeres K3 Necesitaban mejorar el proceso de monitoreo para identificar y recuperar proactivamente todos los problemas de los clústeres. Desarrollaron un enfoque multifacético Synthetic Client Construyeron un Synthetic Client que se ejecuta como contenedor dentro del clúster para probar funciones clave de la plataforma y analizar problemas (fallas de servicio, latencia de datos, etc.) Cuando detecta un problema, el cliente lo reporta al plano de control en la nube a través de una API. Se notifica al equipo de soporte y se inicia un proceso automatizado de remediación Heartbeats de nodos Como los clústeres de Kubernetes tienen capacidades de self-healing, aunque falle un nodo las cargas de trabajo se redistribuyen automáticamente entre los nodos activos Para detectar fallas de nodos, desplegaron un simple "Heartbeat Pod" en cada nodo del clúster Este pod reporta periódicamente su estado a un endpoint de API en la nube Autorremediación A través de las retrospectivas semanales de soporte, detectaron patrones entre errores, validaciones y pasos de corrección Como todas las herramientas de soporte se basan en APIs, pudieron construir flujos de orquestación sobre esas APIs y habilitar correcciones automáticas para problemas comunes Nuevas capacidades Mientras seguían mejorando la infraestructura, el equipo de desarrollo continuó creando nuevas funciones de la plataforma para mejorar el autoservicio y la facilidad de soporte Orquestación de despliegues Su modelo GitOps es simple Al principio comenzaron con cambios manuales, pero pronto crearon una herramienta llamada Fleet que permite cambios de clúster y despliegues a múltiples restaurantes A medida que la plataforma creció, necesitaban una forma de desplegar en toda la cadena y confirmar éxitos y fallas de despliegue En una segunda iteración, desarrollaron una nueva API de Deployment Orchestration Junto con la API, desplegaron un agente de retroalimentación en cada clúster para reportar a la nube información sobre despliegues y estado Esto les permitió crear patrones de release para toda la cadena y despliegues canary autoadministrables Con estos cambios, el equipo pudo ajustar y observar mejor los despliegues, aumentando su confiabilidad Exfiltración de logs Al principio, permitían que el equipo interno de DevOps accediera directamente a los clústeres K3s de los restaurantes para obtener el estado en tiempo real y buscar logs Tenían una capacidad básica de exfiltración de logs, pero era muy difícil de usar debido a la latencia y los problemas de red Como querían minimizar el acceso remoto a los clústeres, agregaron endpoints de API Actualmente añadieron una capacidad de exfiltración de logs más robusta Aprovechan un proyecto open source llamado Vector para recopilar y enviar logs desde los clústeres edge hacia la nube Ofrece filtrado, almacenamiento y reenvío, y rotación automática de logs Del lado de la nube configuraron otros servicios de Vector para recopilar todos los logs provenientes del edge, aplicar reglas y reenviarlos a varias herramientas (Data Dog, Grafana, CloudWatch, etc.) Métricas y dashboards Añadieron la capacidad de recopilar métricas de todos los restaurantes usando Prometheus Remote Write y enviarlas a un Grafana centralizado en la nube Cada clúster K3s captura el estado, los nodos y las cargas de trabajo de los servicios clave También añadieron la capacidad de publicar métricas de negocio personalizadas Conclusión Su "Restaurant Compute Platform" y sus procesos de soporte ya maduraron lo suficiente como para permitir que un pequeño equipo de desarrollo ofrezca alta estabilidad y soporte al cliente de gran nivel Lo aprendido Para que un equipo pequeño construya una plataforma Edge Compute MVP crítica para el negocio, se necesitaron gran ingeniería y compromisos inteligentes Operar más de 2500 clústeres de Kubernetes con un equipo pequeño es algo muy difícil, pero un enfoque de automatización API-first fue de gran ayuda Al venir de un mundo cloud-first, el mayor desafío fue que el edge tiene restricciones: capacidad de cómputo, ancho de banda de red limitado y acceso remoto Vale la pena invertir mucho tiempo en entender las restricciones y considerar si conviene eliminarlas (con alto costo de tiempo y dinero) o administrarlas

(medium.com)

36 puntos por xguru 2023-01-23 | 5 comentarios | Compartir por WhatsApp

La cadena de comida rápida de pollo Chick-fil-A opera un clúster de Kubernetes en el edge en cada restaurante
Todos los dispositivos de cada sucursal (freidoras, parrillas, etc.) envían continuamente información de telemetría IoT, por lo que hay decenas de miles de dispositivos conectados
A partir de esta información se realizan pronósticos de demanda en tiempo real y se envían a la nube para ejecutar procesos de análisis
Todo está integrado, desde los procesos internos de cocina hasta las terminales de pago móvil (drive-thru)

Plataforma Restaurant Edge Compute

Muchos de los sistemas actuales están pensados para la nube o el centro de datos
No son adecuados para entornos con recursos limitados, mala conexión a internet y miles de clústeres de Kubernetes
Por eso decidieron construirla ellos mismos. Crearon un MVP y comenzaron a aprender desplegándolo en entornos reales

Hardware

Decidieron usar Intel NUC de consumo general
Agrupando generaciones de NUC, crearon clústeres de 3 nodos para responder con flexibilidad a confiabilidad, capacidad y configuraciones de HA

SO

En la primera versión usaron Ubuntu como sistema operativo base
El objetivo de diseño era simplemente enviar los NUC directamente al restaurante, sin requerir configuración manual por local
Es decir, todo el aprovisionamiento funciona de forma dinámica, on-the-fly
Por supuesto, incluyeron algunas funciones de seguridad para impedir que otros dispositivos se unan al clúster o accedan a servicios internos en la nube

Edge Commander

Proceso de bootstrap y administración del clúster
Cada nodo del clúster edge se construye con la misma imagen
También incluye trucos usando múltiples particiones de disco y OverlayFS
- Como conservar ciertos datos a largo plazo o borrar de forma remota otras particiones del nodo con una función de "wipe"

Kubernetes

Decidieron usar la implementación K3s
- Es compatible con la especificación de Kubernetes, pero elimina algunas funciones. Es muy simple de configurar y dar soporte a gran escala
Como no usan la nube, no necesitan todas las capacidades completas de Kubernetes
Están muy satisfechos y no planean cambiarlo

GitOps

Cuando construyeron la primera versión de la plataforma, no existía una solución de agente GitOps que pudiera ejecutarse en el edge con recursos limitados
Desarrollaron su propio agente, al que llaman Vessel
Hace polling de un repositorio Git (uno único por tienda) y procesa los cambios del clúster
Hospedan una instancia open source de GitLab en un clúster de Kubernetes en la nube
No querían asumir la carga de operar directamente un servidor Git, pero no pudieron encontrar un modelo de licencias rentable para una solución de hosting

Deployments

Para GitOps, cada sucursal apunta a su propio repositorio Git, llamado Atlas
Un nuevo despliegue en cada restaurante se realiza haciendo merge de una nueva configuración en la rama master de Atlas
Este enfoque tiene algunos trade-offs para la gestión empresarial, pero simplificó muchísimo la administración del estado de despliegue y la auditoría

Soporte para un despliegue en toda la cadena

El mayor reto fue pasar de un MVP a una plataforma escalable, soportable y mantenible por un equipo muy pequeño

Estrategia API First

La primera prioridad del negocio fue envolver todos los procesos manuales y pasos de validación en APIs RESTful
Después de crear una suite completa de APIs para cada etapa, comenzaron a construir una capa de orquestación encima para automatizar los procesos manuales
Al crear un proyecto de Postman completo y bien documentado, pudieron aprovechar rápidamente las nuevas APIs y posponer la creación de una Web UI para el equipo de soporte
Aprovechando OAuth, ofrecieron acceso granular paso a paso a la suite de APIs. Pudieron bloquear fácilmente funciones específicas o abrir endpoints de estado y reportes no invasivos para clientes

Equipo dedicado de rollout

¿Cómo pudieron desplegar tantos dispositivos en toda la cadena en tan poco tiempo?
El equipo principal de desarrollo era muy pequeño, así que era difícil encargarse a la vez del soporte y desarrollo de la plataforma y del rollout para toda la cadena
Antes del rollout completo, enviaron por adelantado 3 NUC e hicieron la instalación; lo que quedaba eran solo las etapas de configuración y validación
Como la suite de APIs ya estaba operando, pudieron formar rápidamente un "equipo de soporte semitécnico" dedicado al lanzamiento de la plataforma, monitoreo de estado y resolución de problemas simples de soporte
Fortalecieron rápidamente al equipo de rollout usando pair-support, playbooks y un ciclo de retroalimentación sobre la documentación
En pocas semanas, el equipo se volvió autosuficiente y logró el rollout en toda la cadena
Después de eso, mediante una estructura organizada, pudieron seguir ampliando la plataforma con nuevas funciones y al mismo tiempo brindar un gran nivel de soporte
Su objetivo era automatizar las partes operativas y empujar el resto del trabajo de soporte al nivel más alto posible dentro de la cadena de soporte
Lo lograron a través de un ciclo de retroalimentación entre First Tier Support y el equipo Support DevOps
- Todos los incidentes comienzan en first tier
- Si no pueden resolverse, o aparece un problema nuevo y complejo, se escalan al equipo Support DevOps
- Ambos equipos colaboran para resolver el problema, y el equipo de first tier actualiza la documentación y los playbooks para poder manejar directamente casos similares en el futuro
- Mediante retrospectivas semanales de soporte, agregan mejoras y oportunidades de automatización al backlog del equipo DevOps
- Además, el equipo Support DevOps influye en el backlog del nuevo equipo de desarrollo para priorizar desde nuevas herramientas hasta mejoras de soporte

Monitoreo y autorremediación

Tienen más de 2500 clústeres K3
Necesitaban mejorar el proceso de monitoreo para identificar y recuperar proactivamente todos los problemas de los clústeres. Desarrollaron un enfoque multifacético

Synthetic Client

Construyeron un Synthetic Client que se ejecuta como contenedor dentro del clúster para probar funciones clave de la plataforma y analizar problemas (fallas de servicio, latencia de datos, etc.)
Cuando detecta un problema, el cliente lo reporta al plano de control en la nube a través de una API. Se notifica al equipo de soporte y se inicia un proceso automatizado de remediación

Heartbeats de nodos

Como los clústeres de Kubernetes tienen capacidades de self-healing, aunque falle un nodo las cargas de trabajo se redistribuyen automáticamente entre los nodos activos
Para detectar fallas de nodos, desplegaron un simple "Heartbeat Pod" en cada nodo del clúster
Este pod reporta periódicamente su estado a un endpoint de API en la nube

Autorremediación

A través de las retrospectivas semanales de soporte, detectaron patrones entre errores, validaciones y pasos de corrección
Como todas las herramientas de soporte se basan en APIs, pudieron construir flujos de orquestación sobre esas APIs y habilitar correcciones automáticas para problemas comunes

Nuevas capacidades

Mientras seguían mejorando la infraestructura, el equipo de desarrollo continuó creando nuevas funciones de la plataforma para mejorar el autoservicio y la facilidad de soporte

Orquestación de despliegues

Su modelo GitOps es simple
Al principio comenzaron con cambios manuales, pero pronto crearon una herramienta llamada Fleet que permite cambios de clúster y despliegues a múltiples restaurantes
A medida que la plataforma creció, necesitaban una forma de desplegar en toda la cadena y confirmar éxitos y fallas de despliegue
En una segunda iteración, desarrollaron una nueva API de Deployment Orchestration
- Junto con la API, desplegaron un agente de retroalimentación en cada clúster para reportar a la nube información sobre despliegues y estado
Esto les permitió crear patrones de release para toda la cadena y despliegues canary autoadministrables
Con estos cambios, el equipo pudo ajustar y observar mejor los despliegues, aumentando su confiabilidad

Exfiltración de logs

Al principio, permitían que el equipo interno de DevOps accediera directamente a los clústeres K3s de los restaurantes para obtener el estado en tiempo real y buscar logs
Tenían una capacidad básica de exfiltración de logs, pero era muy difícil de usar debido a la latencia y los problemas de red
Como querían minimizar el acceso remoto a los clústeres, agregaron endpoints de API
Actualmente añadieron una capacidad de exfiltración de logs más robusta
Aprovechan un proyecto open source llamado Vector para recopilar y enviar logs desde los clústeres edge hacia la nube
- Ofrece filtrado, almacenamiento y reenvío, y rotación automática de logs
- Del lado de la nube configuraron otros servicios de Vector para recopilar todos los logs provenientes del edge, aplicar reglas y reenviarlos a varias herramientas (Data Dog, Grafana, CloudWatch, etc.)

Métricas y dashboards

Añadieron la capacidad de recopilar métricas de todos los restaurantes usando Prometheus Remote Write y enviarlas a un Grafana centralizado en la nube
Cada clúster K3s captura el estado, los nodos y las cargas de trabajo de los servicios clave
También añadieron la capacidad de publicar métricas de negocio personalizadas

Conclusión

Su "Restaurant Compute Platform" y sus procesos de soporte ya maduraron lo suficiente como para permitir que un pequeño equipo de desarrollo ofrezca alta estabilidad y soporte al cliente de gran nivel

Lo aprendido

Para que un equipo pequeño construya una plataforma Edge Compute MVP crítica para el negocio, se necesitaron gran ingeniería y compromisos inteligentes
Operar más de 2500 clústeres de Kubernetes con un equipo pequeño es algo muy difícil, pero un enfoque de automatización API-first fue de gran ayuda
Al venir de un mundo cloud-first, el mayor desafío fue que el edge tiene restricciones: capacidad de cómputo, ancho de banda de red limitado y acceso remoto
Vale la pena invertir mucho tiempo en entender las restricciones y considerar si conviene eliminarlas (con alto costo de tiempo y dinero) o administrarlas

5 comentarios

ddwax89 2023-01-24

Impresionante jaja

ragingwind 2023-01-23

De verdad lo construyeron desde abajo. También da mucha inspiración en el proceso de implementación.

nicewook 2023-01-23

Qué caso tan genial y emocionante. Yo también quisiera intentar construir algo así.
¿Da algo de alivio saber que es un tema desde 2018? Al menos no fue algo hecho de la noche a la mañana.
Más adelante tendré que leerlo de nuevo con calma.

kbumsik 2023-01-23

La hamburguesa de pollo de Chick-fil-A está buenísima jaja

Ya en 2018 había salido una publicación sobre el mismo tema; en ese entonces se sentía algo experimental, pero al parecer lo han mantenido hasta ahora. En el artículo también se nota toda la experiencia que han acumulado durante ese tiempo.

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

xguru 2023-01-23

Es una cadena que no ha llegado al mercado local, así que casi no tiene reconocimiento en el país, pero también es uno de los restaurantes favoritos entre los adolescentes, ya que siempre ocupa el primer lugar en preferencia de restaurantes en la encuesta de marcas preferidas por los adolescentes en EE. UU. que Piper Sandler publica dos veces al año.