33P by xguru 13일전 | 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 클러스터는 상태, 노드, 핵심 서비스의 워크로드를 캡쳐
  • 사용자 지정 비즈니스 메트릭을 퍼블리시 할수 있는 기능도 추가했음

결론

  • 우리의 "Restaurant Compute Platform"과 지원프로세스는 소규모 개발팀으로 높은 수준의 안정성과 고객지원을 할 수 있도록 충분히 성숙했음

배운 것들

  • 소규모 팀이 MVP 비즈니스 크리티컬 Edge Compute 플랫폼을 만들기 위해서는 훌륭한 엔지니어링 과 현명한 절충안이 필요 했음
  • 2500개가 넘는 쿠버네티스 클러스터를 (소규모 팀이) 운영하는 것은 매우 힘든 일이지만, API 우선의 자동화 접근 방식이 큰 도움이 되었음
  • Cloud-first 세계에서 왔을 때, 가장 큰 도전은 Edge가 제약이 있다는 것(컴퓨팅 용량, 제한된 네트워크 대역폭, 원격 억세스)
  • 제약 조건을 파악하는데 많은 시간을 투자하고, 해당 제약 조건을 제거할지(시간과 비용이 많이 소모), 아니면 관리할지 여부를 고려하는 게 좋음

대단하네요 ㅎ

정말 아래부터 만들었네요. 적용 과정에서 많은 영감도 주네요

  1. 너무나 멋지고 신나는 사례이네요. 저도 이렇게 하나 만들어보고 싶네요
  2. 2018년 부터의 주제였다니 그나마 안도랄까요? 하루 아침에 뚝딱 만든 것은 아니군요.
    나중에 한 번더 차근히 일독해야겠습니다.

칙필라 치킨버거 너무 맛있죠 ㅎㅎ

2018년에도 이미 같은 주제의 포스팅이 올라왔었는데요, 그때는 좀 실험적인 느낌이 들었는데 지금까지 유지해오고 있었네요. 글에서도 그동안의 노하우가 쌓인게 보이는군요.

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

국내에 들어오지 않은 매장이라 국내 인지도는 거의 없지만, Piper Sandler가 매년 두번씩 발표하는 미국 10대들의 기업 선호도 조사에서 항상 음식점 선호도 1위를 하고 있는 10대들의 인기 식당이기도 합니다 .