Chick-Fil-A 의 Edge Computing 기술 아키텍처 : Enterprise Restaurant Compute

(medium.com)

36P by xguru 2023-01-23 | favorite | 댓글 5개

치킨 패스트푸드 체인 Chick-Fil-A는 각 레스토랑에 엣지 쿠버네티스 클러스터를 운영중
각 매장의 모든 기기들(튀김기, 그릴 등) 들은 IoT 텔레메트리 정보를 지속적으로 제공하여, 수만대의 기기들이 연결되어 있음
이런 정보들로 부터 실시간으로 수요 예측을 하고 클라우드 쪽으로 보내서 분석 프로세스가 실행됨
내부 조리 과정부터 모바일 페이먼트 터미널(드라이브 쓰루) 등까지 모든게 다 통합

Restaurant Edge Compute platform

현재의 많은 시스템들은 클라우드/데이터센터에 맞춰져 있음
리소스 제한적이고 인터넷 커넥션도 좋지 않은 환경 그리고 수천개의 쿠버네티스 클러스터에는 적합하지 않음
그래서 직접 만들기로 결정. MVP를 만들어서 실제 설치해보면서 배우기 시작

하드웨어

일반 소비자용 Intel NUC를 사용하기로 결정
NUC 세대를 묶어서 3노드 클러스터를 생성하여 안전성, 용량, HA 설정까지 대응하도록 유연하게

OS

첫번째 릴리즈에는 Ubuntu를 기본 OS로 사용
디자인 목표는 그냥 NUC를 레스토랑에 드랍쉬핑만 하는 것. 레스토랑별 수작업 설정이 필요없도록
즉, 모든 프로비져닝은 동적으로 on-the-fly로 동작
물론 몇개의 보안 기능으로 다른 기기들이 클러스터에 조인하거나, 내부 클라우드 서비스에 접근하는 것은 막음

Edge Commander

클러스터 부트스트래핑 및 관리 프로세스
각 엣지 클러스터 노드는 동일한 이미지로 구축
여러개의 디스크 파티션 및 OverlayFS 를 이용한 트릭도 포함
- 특정 데이터를 롱텀 유지하거나, 노드의 다른 파티션들을 원격으로 삭제 "Wipe" 하는 기능 등

Kubernetes

K3s 구현체를 사용하기로 결정
- 쿠버네티스 스펙과 호환하지만 일부 기능을 제거. 대규모로 설정 및 지원하는 것이 매우 간단함
클라우드를 사용하는게 아니므로, 쿠버네티스 전체 기능을 필요로 하지 않음
매우 만족하고 앞으로도 바꿀 일 없음

GitOps

첫번째 플랫폼 릴리스 구축할때는 리소스 제한적인 엣지에서 실행가능한 GitOps 에이전트 솔루션이 없었음
'Vessel' 이라 부르는 자체 에이전트를 개발
Git Repo(각 스토어당 유니크한 Repo)를 폴링하고 클러스터 변경 사항을 처리
클라우드의 쿠버네티스 클러스터에 오픈소스 GitLab 인스턴스를 호스팅 중
직접 Git 서버를 운영하는 부담은 가지고 싶지 않았지만, 비용 효율적인 호스팅 솔루션 라이센스 모델을 찾을 수 없었음

Deployments

GitOps를 위해서 각 지점이 자신의 Git Repo를 지정 (Atlas라고 부름)
각 레스토랑에 새로운 배포는 Atlas의 마스터 브랜치에 새로운 설정을 머지 하는 것으로 가능
이 접근법은 엔터프라이즈 관리에는 약간의 트레이드 오프가 있지만, 배포 상태 관리 및 감사를 매우 간단하게 만들어 줬음

Supporting a Chain-Wide Deployment

가장 큰 도전은 MVP 에서 매우 작은팀이 유지 가능하면서도 스케일러블하고 지원이 가능한 플랫폼으로 바꾼 것

API First 전략

비즈니스의 첫번째 순서는 모든 수동 프로세스 및 유효성 검사 단계를 Restful API로 래핑 하는 것
각 단계에 대한 포괄적인 API Suite를 만든 다음, 맨 위에 오케스트레이션 계층을 구축해서 수동 프로세스들을 자동화 하기 시작
포괄적이고 잘 문서화된 PostMan 프로젝트를 생성함으로써, 새로운 API를 신속하게 활용하고 지원팀용 Web UI 만드는 것을 지연 시킬 수 있었음
OAuth를 활용해서 API Suite에 대한 세분화된 단계별 접근을 제공. 특정 기능를 쉽게 잠그거나, 고객들에게 non-invasive 한 상태 및 보고 엔드포인트를 열어줄 수 있었음

Dedicated Roll Out Team

어떻게 짧은 시간에 수많은 기기들을 각 체인에 배포할수 있었을까?
핵심 개발팀은 매우 작아서, 플랫폼 지원 및 개발부터 체인전체 롤아웃을 배포까지 지원하기는 어려웠음
우린 전체 롤아웃 전에 3대의 NUC를 미리 배송해서 설치해뒀고, 남은 것은 설정과 검증 단계 뿐
API Suite가 동작중이었기 때문에, 플랫폼 출시/상태 모니터링/간단한 지원문제 해결을 전담하는 "준 기술 지원팀(semi-technical support team)"을 신속하게 구성
Pair-Support 및 플레이북, 문서 피드백 루프를 활용해서 롤아웃 팀을 빠르게 강화해 나갔음
몇주 안에 팀은 자급자족 가능해졌고, 체인 전체에 대한 롤아웃을 달성
그 이후 조직화된 구조를 통해서 새로운 기능과 확장하면서도, 플랫폼에 대한 훌륭한 지원을 할 수 있도록 만들었음
우리의 목표는 실무적인 부분들을 자동화 하고, 나머지 지원 작업들을 서포트 체인에서 가능한 높은 단계로 밀어 붙이는 것
First Tier Support 와 Support DevOps 팀 간의 피드백 루프틀 통해서 이를 달성
- 모든 이슈는 퍼스트 티어를 통해서 시작
- 해결할 수 없거나, 새롭고 복잡한 문제가 발생하면 Support DevOps 팀으로 전달
- 두 팀이 함께 문제를 해결하기위해 협력하고, First Tier팀은 문서와 플레이북을 업데이트하여 다음에 유사한 문제 발생시 직접 처리할 수 있도록 함
- 주간 지원 회고를 통해서 DevOps 팀 백로그에 향상 및 자동 개선 기회를 추가
- 또한 Support DevOps팀은 신규 개발팀의 백로그에 영향을 주어서, 새로운 도구 또는 지원을 향상하기 위한 것들 부터 우선순위 결정

Monitoring and Auto-Remediation

2500개가 넘는 K3 클러스터가 있음
모니터링 프로세스를 개선해서 클러스트의 모든 문제를 사전에 식별하고 복구해야 했음. 다각적인 접근 방식을 개발

Synthetic Client

핵심 플랫폼 기능을 테스트하고, 문제(서비스 문제, 데이터 지연시간 등)를 분석하기 위해 클러스터내에서 컨테이너로 실행되는 Synthetic Client를 구축
문제가 발견되면 클라이언트는 API를 통해서 CLoud Control Plane에 보고. 지원팀에 알림이 가고 자동화된 Remediation 프로세스를 시작

Node Hearbeats

쿠버네티스 클러스터는 자가 치유 기능이 있으므로, 노드의 장애가 있어도 활성 노드간 워크로드가 자동으로 재조정됨
노드 장애를 감지하기 위해서 간단한 "Heartbeat Pod"를 클러스터의 각 노드에 배포
이 Pod는 주기적으로 클라우드의 API 엔드포인트에 상태를 보고

Auto Remediation

주간 지원 회고를 통해서, 오류와 검증, 수정 단계사이의 패턴을 발견 했음
모든 지원 도구들이 API 기반이기 때문에 이런 API 위해 오케스트레이션 흐름을 구축하고, 일반적으로 발생하는 문제에 대한 자동 수정(Auto Remediation)을 할 수 있었음

New Capabilities

인프라에 대한 개선을 계속하면서, 개발팀은 셀프 서비스 및 지원 용이성을 향상시키기 위한 새로운 플랫폼 기능을 계속 개발 했음

Deployment Orchestration

우리의 GitOps 모델은 간단함
처음에는 수동 변경으로 시작했지만, 곧 클러스터 변경 및 여러 레스토랑에 배포 가능한 "Fleet" 이라는 도구를 만들었음
플랫폼이 성장함에 따라 전체 체인에 배포하고, 배포 실패와 성공을 확인하는 방법이 필요해졌음
2차 이터레이션에서는 새로운 Deplyment Orchestration API를 개발
- API와 함께 각 클러스터에 피드백 에이전트를 배포해서, 배포 및 상태정보를 클라우드에 보고하도록 함
이를 통해서 체인 전체에 대한 릴리즈 및 자체 관리 가능한 카나리 배포 배턴을 만들수 있게 되었음
이런 변화로, 팀이 배포를 미세하게 조정하고 관찰할 수 있어서 배포 신뢰도가 높아짐

Log Exfiltration

초기에는 내부 DevOps 팀이 레스토랑의 K3s 클러스터에 직접 액세스해서 실시간으로 상태를 가져오고 로그를 검색가능하도록 허용
기본적인 Log Exfiltration 기능이 있었지만, 지연시간 및 네트워크 문제로 인해서 사용하기가 매루 어려웠음
클러스터에 대한 원격 접근을 최소화하기 원했기 때문에, API 엔드포인트를 추가했고
현재는 더 강력한 Log Exfiltration 기능을 추가 했음
Vector라는 오픈소스를 활용해서 엣지 클러스터에서 칼라우드를 수집하고 전달
- 필터링, 저장 및 전달, 로그 자동 회전 기능을 제공
- 클라우드 단에서 다른 Vector 서비스를 셋업한뒤 모든 엣지로 부터 오는 로그를 수집, 룰 적용하고 여러 도구로 포워딩 (Data Dog, Grafana, CloudWatch 등)

Metrics and Dashboards

Prometheus Remote Write를 활용해서 모든 레스토랑에서 메트릭을 수집하고, 클라우드의 중앙 Grafana로 전달하는 기능을 추가
각 K3s 클러스터는 상태, 노드, 핵심 서비스의 워크로드를 캡쳐
사용자 지정 비즈니스 메트릭을 퍼블리시 할수 있는 기능도 추가했음