A arquitetura técnica de Edge Computing do Chick-fil-A: Enterprise Restaurant Compute

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

A rede de fast-food de frango Chick-fil-A opera um cluster Kubernetes de edge em cada restaurante Todos os dispositivos de cada loja (fritadeiras, grelhas etc.) fornecem continuamente informações de telemetria IoT, conectando dezenas de milhares de dispositivos A partir dessas informações, a previsão de demanda é feita em tempo real e enviada para a nuvem, onde os processos de análise são executados Tudo é integrado, dos processos internos de preparo aos terminais de pagamento móvel (drive-thru) Plataforma de Restaurant Edge Compute Muitos sistemas atuais são projetados para nuvem/data center Eles não são adequados para ambientes com recursos limitados, conexão de internet ruim e milhares de clusters Kubernetes Por isso, decidiram construir a própria solução. Criaram um MVP e começaram a aprender instalando-o de fato Hardware Decidiram usar Intel NUCs comuns de consumo Agruparam gerações de NUC para criar clusters de 3 nós, com flexibilidade para atender segurança, capacidade e configuração de HA SO Na primeira release, usaram Ubuntu como sistema operacional base O objetivo de design era simplesmente fazer dropshipping do NUC para o restaurante, sem necessidade de configuração manual por restaurante Ou seja, todo o provisionamento funciona dinamicamente, on-the-fly Claro, com alguns recursos de segurança para impedir que outros dispositivos entrem no cluster ou acessem serviços internos na nuvem Edge Commander Processo de bootstrap e gerenciamento do cluster Cada nó do cluster de edge é construído com a mesma imagem Inclui também truques com múltiplas partições de disco e OverlayFS Como manter certos dados por longo prazo ou apagar remotamente outras partições do nó, com recurso de "wipe" Kubernetes Decidiram usar a implementação K3s Compatível com a especificação do Kubernetes, mas com alguns recursos removidos. É muito simples de configurar e oferecer suporte em grande escala Como não usam cloud, não precisam de todos os recursos completos do Kubernetes Estão muito satisfeitos e não pretendem trocar GitOps Quando construíram a primeira release da plataforma, não existia uma solução de agente GitOps que pudesse rodar no edge com recursos limitados Desenvolveram um agente próprio chamado Vessel Ele faz polling do repositório Git (um repositório único por loja) e processa as mudanças do cluster Hospedam uma instância open source do GitLab em um cluster Kubernetes na nuvem Não queriam o peso de operar diretamente um servidor Git, mas não conseguiam encontrar um modelo de licenciamento de hospedagem com bom custo-benefício Deployments Para GitOps, cada unidade aponta para seu próprio repositório Git, chamado Atlas Um novo deployment para cada restaurante pode ser feito mesclando uma nova configuração na branch master do Atlas Essa abordagem tem alguns trade-offs para gestão enterprise, mas simplificou muito o gerenciamento do estado do deployment e a auditoria Dando suporte a um deployment em toda a rede O maior desafio foi transformar o MVP em uma plataforma escalável, sustentável e com suporte, que pudesse ser mantida por uma equipe muito pequena Estratégia API First A primeira prioridade do negócio foi encapsular todos os processos manuais e etapas de validação em APIs RESTful Criaram uma suíte abrangente de APIs para cada etapa e depois construíram uma camada de orquestração por cima para começar a automatizar os processos manuais Ao criar um projeto Postman abrangente e bem documentado, conseguiram aproveitar rapidamente as novas APIs e adiar a criação de uma Web UI para a equipe de suporte Com OAuth, ofereceram acesso granular por etapa à suíte de APIs. Ficou fácil bloquear funções específicas ou abrir endpoints não invasivos de status e relatórios para os clientes Equipe dedicada de rollout Como conseguiram implantar tantos dispositivos em toda a rede em pouco tempo? A equipe principal de desenvolvimento era muito pequena, então era difícil dar conta ao mesmo tempo do suporte e desenvolvimento da plataforma e do rollout para toda a rede Antes do rollout completo, enviaram antecipadamente 3 NUCs para instalação, e o restante ficou restrito às etapas de configuração e validação Como a suíte de APIs já estava funcionando, conseguiram montar rapidamente uma "equipe de suporte semitécnica" dedicada ao lançamento da plataforma, monitoramento de status e solução de problemas simples Usaram pair-support, playbooks e um loop de feedback da documentação para fortalecer rapidamente a equipe de rollout Em poucas semanas, a equipe se tornou autossuficiente e concluiu o rollout em toda a rede Depois disso, criaram uma estrutura organizada que permitiu expandir com novos recursos e continuar oferecendo excelente suporte à plataforma O objetivo deles é automatizar os aspectos operacionais e empurrar o restante do trabalho de suporte para o nível mais alto possível dentro da cadeia de suporte Isso foi alcançado por meio de um loop de feedback entre a equipe de suporte de primeiro nível e a equipe de Support DevOps Todos os problemas começam pelo primeiro nível Se não puderem ser resolvidos ou se surgir um problema novo e complexo, são encaminhados para a equipe de Support DevOps As duas equipes colaboram para resolver o problema, e a equipe de primeiro nível atualiza a documentação e os playbooks para conseguir tratar casos semelhantes diretamente no futuro Retrospectivas semanais de suporte adicionam melhorias e oportunidades de automação ao backlog da equipe de DevOps A equipe de Support DevOps também influencia o backlog da equipe de desenvolvimento, ajudando a priorizar desde novas ferramentas até melhorias de suporte Monitoramento e auto-remediação Existem mais de 2.500 clusters K3s Foi preciso melhorar o processo de monitoramento para identificar e recuperar proativamente todos os problemas dos clusters. Para isso, desenvolveram uma abordagem multifacetada Synthetic Client Construíram um Synthetic Client executado como contêiner dentro do cluster para testar funções centrais da plataforma e analisar problemas (falhas de serviço, latência de dados etc.) Quando encontra um problema, o cliente o reporta ao Cloud Control Plane via API. A equipe de suporte é alertada e um processo automatizado de remediação é iniciado Heartbeats de nó Como o cluster Kubernetes tem recursos de self-healing, mesmo com falha de um nó as workloads são automaticamente redistribuídas entre os nós ativos Para detectar falhas de nó, implantaram um "Heartbeat Pod" simples em cada nó do cluster Esse pod reporta periodicamente seu status para um endpoint de API na nuvem Auto-remediação Por meio das retrospectivas semanais de suporte, identificaram padrões entre erros, validação e etapas de correção Como todas as ferramentas de suporte são baseadas em API, conseguiram criar fluxos de orquestração sobre essas APIs e fazer auto-remediação para problemas recorrentes Novas capacidades À medida que continuavam aprimorando a infraestrutura, a equipe de desenvolvimento também seguia criando novos recursos de plataforma para melhorar self-service e facilidade de suporte Orquestração de deployment O modelo GitOps deles é simples No início começaram com mudanças manuais, mas logo criaram uma ferramenta chamada Fleet, capaz de alterar clusters e distribuir deployments para vários restaurantes Com o crescimento da plataforma, surgiu a necessidade de implantar em toda a rede e verificar falhas e sucessos de deployment Na segunda iteração, desenvolveram uma nova API de Deployment Orchestration Junto com a API, implantaram um agente de feedback em cada cluster para reportar deployment e informações de status para a nuvem Isso permitiu criar releases para toda a rede e padrões de deployment canário autogerenciáveis Com essa mudança, a equipe passou a conseguir ajustar finamente e observar os deployments, aumentando a confiabilidade Exfiltração de logs No início, a equipe interna de DevOps podia acessar diretamente os clusters K3s dos restaurantes para coletar status em tempo real e pesquisar logs Havia uma funcionalidade básica de exfiltração de logs, mas ela era muito difícil de usar por causa de latência e problemas de rede Como queriam minimizar o acesso remoto aos clusters, adicionaram endpoints de API Hoje já contam com uma funcionalidade de exfiltração de logs mais robusta Usam o open source Vector para coletar e encaminhar logs dos clusters de edge para a nuvem Ele fornece filtragem, armazenamento e encaminhamento, além de rotação automática de logs No lado da nuvem, configuraram outro serviço Vector para coletar logs de todos os edges, aplicar regras e encaminhar para várias ferramentas (Datadog, Grafana, CloudWatch etc.) Métricas e dashboards Adicionaram a capacidade de coletar métricas de todos os restaurantes usando Prometheus Remote Write e enviá-las para um Grafana central na nuvem Cada cluster K3s captura estado, nós e workloads dos serviços centrais Também adicionaram a capacidade de publicar métricas de negócio personalizadas Conclusão A "Restaurant Compute Platform" e seus processos de suporte amadureceram o suficiente para permitir alta confiabilidade e suporte ao cliente com uma equipe pequena de desenvolvimento Lições aprendidas Para uma equipe pequena construir uma plataforma de Edge Compute MVP crítica para o negócio, foram necessários excelente engenharia e compromissos inteligentes Operar mais de 2.500 clusters Kubernetes com uma equipe pequena é extremamente difícil, mas uma abordagem de automação API-first ajudou bastante Para quem vem de um mundo cloud-first, o maior desafio é que o edge tem restrições (capacidade computacional, largura de banda de rede limitada, acesso remoto) Vale a pena investir bastante tempo entendendo essas restrições e considerar se é melhor eliminá-las (com alto custo de tempo e dinheiro) ou gerenciá-las

(medium.com)

36 pontos por xguru 2023-01-23 | 5 comentários | Compartilhar no WhatsApp

A rede de fast-food de frango Chick-fil-A opera um cluster Kubernetes de edge em cada restaurante
Todos os dispositivos de cada loja (fritadeiras, grelhas etc.) fornecem continuamente informações de telemetria IoT, conectando dezenas de milhares de dispositivos
A partir dessas informações, a previsão de demanda é feita em tempo real e enviada para a nuvem, onde os processos de análise são executados
Tudo é integrado, dos processos internos de preparo aos terminais de pagamento móvel (drive-thru)

Plataforma de Restaurant Edge Compute

Muitos sistemas atuais são projetados para nuvem/data center
Eles não são adequados para ambientes com recursos limitados, conexão de internet ruim e milhares de clusters Kubernetes
Por isso, decidiram construir a própria solução. Criaram um MVP e começaram a aprender instalando-o de fato

Hardware

Decidiram usar Intel NUCs comuns de consumo
Agruparam gerações de NUC para criar clusters de 3 nós, com flexibilidade para atender segurança, capacidade e configuração de HA

SO

Na primeira release, usaram Ubuntu como sistema operacional base
O objetivo de design era simplesmente fazer dropshipping do NUC para o restaurante, sem necessidade de configuração manual por restaurante
Ou seja, todo o provisionamento funciona dinamicamente, on-the-fly
Claro, com alguns recursos de segurança para impedir que outros dispositivos entrem no cluster ou acessem serviços internos na nuvem

Edge Commander

Processo de bootstrap e gerenciamento do cluster
Cada nó do cluster de edge é construído com a mesma imagem
Inclui também truques com múltiplas partições de disco e OverlayFS
- Como manter certos dados por longo prazo ou apagar remotamente outras partições do nó, com recurso de "wipe"

Kubernetes

Decidiram usar a implementação K3s
- Compatível com a especificação do Kubernetes, mas com alguns recursos removidos. É muito simples de configurar e oferecer suporte em grande escala
Como não usam cloud, não precisam de todos os recursos completos do Kubernetes
Estão muito satisfeitos e não pretendem trocar

GitOps

Quando construíram a primeira release da plataforma, não existia uma solução de agente GitOps que pudesse rodar no edge com recursos limitados
Desenvolveram um agente próprio chamado Vessel
Ele faz polling do repositório Git (um repositório único por loja) e processa as mudanças do cluster
Hospedam uma instância open source do GitLab em um cluster Kubernetes na nuvem
Não queriam o peso de operar diretamente um servidor Git, mas não conseguiam encontrar um modelo de licenciamento de hospedagem com bom custo-benefício

Deployments

Para GitOps, cada unidade aponta para seu próprio repositório Git, chamado Atlas
Um novo deployment para cada restaurante pode ser feito mesclando uma nova configuração na branch master do Atlas
Essa abordagem tem alguns trade-offs para gestão enterprise, mas simplificou muito o gerenciamento do estado do deployment e a auditoria

Dando suporte a um deployment em toda a rede

O maior desafio foi transformar o MVP em uma plataforma escalável, sustentável e com suporte, que pudesse ser mantida por uma equipe muito pequena

Estratégia API First

A primeira prioridade do negócio foi encapsular todos os processos manuais e etapas de validação em APIs RESTful
Criaram uma suíte abrangente de APIs para cada etapa e depois construíram uma camada de orquestração por cima para começar a automatizar os processos manuais
Ao criar um projeto Postman abrangente e bem documentado, conseguiram aproveitar rapidamente as novas APIs e adiar a criação de uma Web UI para a equipe de suporte
Com OAuth, ofereceram acesso granular por etapa à suíte de APIs. Ficou fácil bloquear funções específicas ou abrir endpoints não invasivos de status e relatórios para os clientes

Equipe dedicada de rollout

Como conseguiram implantar tantos dispositivos em toda a rede em pouco tempo?
A equipe principal de desenvolvimento era muito pequena, então era difícil dar conta ao mesmo tempo do suporte e desenvolvimento da plataforma e do rollout para toda a rede
Antes do rollout completo, enviaram antecipadamente 3 NUCs para instalação, e o restante ficou restrito às etapas de configuração e validação
Como a suíte de APIs já estava funcionando, conseguiram montar rapidamente uma "equipe de suporte semitécnica" dedicada ao lançamento da plataforma, monitoramento de status e solução de problemas simples
Usaram pair-support, playbooks e um loop de feedback da documentação para fortalecer rapidamente a equipe de rollout
Em poucas semanas, a equipe se tornou autossuficiente e concluiu o rollout em toda a rede
Depois disso, criaram uma estrutura organizada que permitiu expandir com novos recursos e continuar oferecendo excelente suporte à plataforma
O objetivo deles é automatizar os aspectos operacionais e empurrar o restante do trabalho de suporte para o nível mais alto possível dentro da cadeia de suporte
Isso foi alcançado por meio de um loop de feedback entre a equipe de suporte de primeiro nível e a equipe de Support DevOps
- Todos os problemas começam pelo primeiro nível
- Se não puderem ser resolvidos ou se surgir um problema novo e complexo, são encaminhados para a equipe de Support DevOps
- As duas equipes colaboram para resolver o problema, e a equipe de primeiro nível atualiza a documentação e os playbooks para conseguir tratar casos semelhantes diretamente no futuro
- Retrospectivas semanais de suporte adicionam melhorias e oportunidades de automação ao backlog da equipe de DevOps
- A equipe de Support DevOps também influencia o backlog da equipe de desenvolvimento, ajudando a priorizar desde novas ferramentas até melhorias de suporte

Monitoramento e auto-remediação

Existem mais de 2.500 clusters K3s
Foi preciso melhorar o processo de monitoramento para identificar e recuperar proativamente todos os problemas dos clusters. Para isso, desenvolveram uma abordagem multifacetada

Synthetic Client

Construíram um Synthetic Client executado como contêiner dentro do cluster para testar funções centrais da plataforma e analisar problemas (falhas de serviço, latência de dados etc.)
Quando encontra um problema, o cliente o reporta ao Cloud Control Plane via API. A equipe de suporte é alertada e um processo automatizado de remediação é iniciado

Heartbeats de nó

Como o cluster Kubernetes tem recursos de self-healing, mesmo com falha de um nó as workloads são automaticamente redistribuídas entre os nós ativos
Para detectar falhas de nó, implantaram um "Heartbeat Pod" simples em cada nó do cluster
Esse pod reporta periodicamente seu status para um endpoint de API na nuvem

Auto-remediação

Por meio das retrospectivas semanais de suporte, identificaram padrões entre erros, validação e etapas de correção
Como todas as ferramentas de suporte são baseadas em API, conseguiram criar fluxos de orquestração sobre essas APIs e fazer auto-remediação para problemas recorrentes

Novas capacidades

À medida que continuavam aprimorando a infraestrutura, a equipe de desenvolvimento também seguia criando novos recursos de plataforma para melhorar self-service e facilidade de suporte

Orquestração de deployment

O modelo GitOps deles é simples
No início começaram com mudanças manuais, mas logo criaram uma ferramenta chamada Fleet, capaz de alterar clusters e distribuir deployments para vários restaurantes
Com o crescimento da plataforma, surgiu a necessidade de implantar em toda a rede e verificar falhas e sucessos de deployment
Na segunda iteração, desenvolveram uma nova API de Deployment Orchestration
- Junto com a API, implantaram um agente de feedback em cada cluster para reportar deployment e informações de status para a nuvem
Isso permitiu criar releases para toda a rede e padrões de deployment canário autogerenciáveis
Com essa mudança, a equipe passou a conseguir ajustar finamente e observar os deployments, aumentando a confiabilidade

Exfiltração de logs

No início, a equipe interna de DevOps podia acessar diretamente os clusters K3s dos restaurantes para coletar status em tempo real e pesquisar logs
Havia uma funcionalidade básica de exfiltração de logs, mas ela era muito difícil de usar por causa de latência e problemas de rede
Como queriam minimizar o acesso remoto aos clusters, adicionaram endpoints de API
Hoje já contam com uma funcionalidade de exfiltração de logs mais robusta
Usam o open source Vector para coletar e encaminhar logs dos clusters de edge para a nuvem
- Ele fornece filtragem, armazenamento e encaminhamento, além de rotação automática de logs
- No lado da nuvem, configuraram outro serviço Vector para coletar logs de todos os edges, aplicar regras e encaminhar para várias ferramentas (Datadog, Grafana, CloudWatch etc.)

Métricas e dashboards

Adicionaram a capacidade de coletar métricas de todos os restaurantes usando Prometheus Remote Write e enviá-las para um Grafana central na nuvem
Cada cluster K3s captura estado, nós e workloads dos serviços centrais
Também adicionaram a capacidade de publicar métricas de negócio personalizadas

Conclusão

A "Restaurant Compute Platform" e seus processos de suporte amadureceram o suficiente para permitir alta confiabilidade e suporte ao cliente com uma equipe pequena de desenvolvimento

Lições aprendidas

Para uma equipe pequena construir uma plataforma de Edge Compute MVP crítica para o negócio, foram necessários excelente engenharia e compromissos inteligentes
Operar mais de 2.500 clusters Kubernetes com uma equipe pequena é extremamente difícil, mas uma abordagem de automação API-first ajudou bastante
Para quem vem de um mundo cloud-first, o maior desafio é que o edge tem restrições (capacidade computacional, largura de banda de rede limitada, acesso remoto)
Vale a pena investir bastante tempo entendendo essas restrições e considerar se é melhor eliminá-las (com alto custo de tempo e dinheiro) ou gerenciá-las

5 comentários

ddwax89 2023-01-24

Impressionante haha

ragingwind 2023-01-23

Realmente construíram isso do zero. Também traz muita inspiração no processo de aplicação.

nicewook 2023-01-23

Que caso incrivelmente legal e empolgante. Eu também queria tentar criar algo assim.
Então era um tema desde 2018? Isso até dá certo alívio, né? Não foi algo feito às pressas, da noite para o dia.
Depois, vou ler com calma mais uma vez.

kbumsik 2023-01-23

O sanduíche de frango do Chick-fil-A é muito gostoso haha

Já tinha saído um post sobre o mesmo tema em 2018, mas naquela época parecia algo mais experimental; interessante ver que eles mantiveram isso até agora. Dá para perceber no texto que o know-how acumulado ao longo desse tempo aparece bem.

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

xguru 2023-01-23

É uma rede que ainda não chegou ao país e, por isso, tem pouquíssimo reconhecimento por aqui, mas também é um restaurante muito popular entre os adolescentes, ficando sempre em 1º lugar na preferência por restaurantes na pesquisa de afinidade com marcas entre adolescentes dos EUA, divulgada duas vezes por ano pela Piper Sandler.