Kiến trúc công nghệ Edge Computing của Chick-Fil-A: Enterprise Restaurant Compute

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

Chuỗi thức ăn nhanh gà rán Chick-Fil-A đang vận hành các cụm Kubernetes biên tại từng nhà hàng Mọi thiết bị tại mỗi cửa hàng (nồi chiên, bếp nướng, v.v.) liên tục cung cấp thông tin telemetry IoT, kết nối tới hàng chục nghìn thiết bị Từ các dữ liệu này, hệ thống dự báo nhu cầu theo thời gian thực và gửi lên phía cloud để chạy các quy trình phân tích Mọi thứ đều được tích hợp, từ quy trình nấu nướng nội bộ đến các terminal thanh toán di động (drive-thru) Nền tảng Restaurant Edge Compute Nhiều hệ thống hiện tại được thiết kế cho cloud/data center Chúng không phù hợp với môi trường tài nguyên hạn chế, kết nối Internet không ổn định và hàng nghìn cụm Kubernetes Vì vậy họ quyết định tự xây dựng. Họ tạo MVP và bắt đầu học hỏi bằng cách triển khai thực tế Phần cứng Họ quyết định sử dụng Intel NUC dành cho người tiêu dùng phổ thông Gom các thế hệ NUC để tạo cụm 3 node, đủ linh hoạt để đáp ứng độ an toàn, dung lượng và cấu hình HA OS Ở bản phát hành đầu tiên, Ubuntu được dùng làm OS mặc định Mục tiêu thiết kế là chỉ cần drop-ship NUC đến nhà hàng, không cần cấu hình thủ công cho từng địa điểm Tức là mọi provisioning đều vận hành động on-the-fly Dĩ nhiên, một số tính năng bảo mật được áp dụng để ngăn thiết bị khác tham gia cụm hoặc truy cập dịch vụ cloud nội bộ Edge Commander Quy trình bootstrap và quản lý cụm Mỗi node trong cụm biên được xây dựng từ cùng một image Cũng bao gồm một số kỹ thuật dùng nhiều phân vùng đĩa và OverlayFS Chẳng hạn như giữ lại một số dữ liệu dài hạn hoặc từ xa xóa "wipe" các phân vùng khác của node Kubernetes Họ quyết định dùng bản triển khai K3s Tương thích với đặc tả Kubernetes nhưng loại bỏ một số tính năng. Việc cấu hình và hỗ trợ ở quy mô lớn rất đơn giản Vì không dùng cloud nên họ không cần toàn bộ tính năng của Kubernetes Họ rất hài lòng và không có ý định thay đổi trong tương lai GitOps Khi xây dựng bản phát hành nền tảng đầu tiên, chưa có giải pháp agent GitOps nào có thể chạy trên edge bị giới hạn tài nguyên Họ phát triển agent riêng có tên là 'Vessel' Agent này poll Git Repo (mỗi cửa hàng có một repo riêng) và xử lý các thay đổi của cụm Họ đang host một instance GitLab mã nguồn mở trên cụm Kubernetes của cloud Họ không muốn mang gánh nặng tự vận hành Git server, nhưng cũng không tìm được mô hình giấy phép hosting nào hiệu quả về chi phí Deployments Để phục vụ GitOps, mỗi chi nhánh chỉ định Git Repo riêng của mình (được gọi là Atlas) Có thể triển khai mới cho từng nhà hàng bằng cách merge cấu hình mới vào nhánh master của Atlas Cách tiếp cận này có một số đánh đổi với quản trị enterprise, nhưng lại giúp việc quản lý trạng thái triển khai và audit trở nên rất đơn giản Hỗ trợ triển khai trên toàn chuỗi Thách thức lớn nhất là biến MVP thành một nền tảng vừa scalable vừa dễ hỗ trợ, đồng thời vẫn có thể được duy trì bởi một đội rất nhỏ Chiến lược API First Việc đầu tiên của họ là bọc toàn bộ quy trình thủ công và các bước kiểm tra hợp lệ bằng Restful API Sau khi tạo bộ API toàn diện cho từng bước, họ xây dựng một lớp orchestration ở phía trên để bắt đầu tự động hóa các quy trình thủ công Bằng cách tạo một dự án PostMan đầy đủ và được tài liệu hóa tốt, họ có thể nhanh chóng tận dụng các API mới và trì hoãn việc xây Web UI cho đội hỗ trợ Dùng OAuth để cung cấp quyền truy cập chi tiết theo từng bước vào bộ API. Nhờ đó họ có thể dễ dàng khóa một số tính năng hoặc mở các endpoint trạng thái và báo cáo không xâm lấn cho khách hàng Đội ngũ triển khai chuyên trách Làm thế nào họ có thể triển khai số lượng lớn thiết bị cho từng chuỗi trong thời gian ngắn? Đội phát triển cốt lõi quá nhỏ, nên khó vừa hỗ trợ và phát triển nền tảng, vừa phụ trách rollout toàn chuỗi Họ gửi trước 3 chiếc NUC để cài đặt trước toàn bộ rollout, phần còn lại chỉ là cấu hình và xác minh Vì bộ API Suite đã hoạt động, họ nhanh chóng lập một "đội hỗ trợ bán kỹ thuật" chuyên trách việc phát hành nền tảng, theo dõi trạng thái và xử lý các vấn đề hỗ trợ đơn giản Họ nhanh chóng tăng cường đội rollout bằng Pair-Support, playbook và vòng lặp phản hồi tài liệu Chỉ sau vài tuần, đội đã có thể tự vận hành và hoàn tất rollout toàn chuỗi Sau đó, thông qua một cấu trúc tổ chức bài bản, họ có thể tiếp tục mở rộng với các tính năng mới mà vẫn duy trì hỗ trợ nền tảng rất tốt Mục tiêu của họ là tự động hóa những phần mang tính tác nghiệp, và đẩy phần việc hỗ trợ còn lại lên mức cao nhất có thể trong chuỗi hỗ trợ Họ đạt được điều này thông qua vòng phản hồi giữa First Tier Support và đội Support DevOps Mọi issue đều bắt đầu từ tuyến hỗ trợ đầu tiên Nếu không thể giải quyết, hoặc phát sinh vấn đề mới và phức tạp, issue sẽ được chuyển cho đội Support DevOps Hai đội cùng phối hợp giải quyết, còn đội First Tier sẽ cập nhật tài liệu và playbook để lần sau có thể tự xử lý các vấn đề tương tự Qua các buổi retrospective hỗ trợ hàng tuần, họ thêm các cơ hội cải tiến và tự động hóa vào backlog của đội DevOps Đồng thời đội Support DevOps cũng tác động đến backlog của đội phát triển mới để ưu tiên những việc nhằm cải thiện công cụ hoặc nâng cao năng lực hỗ trợ Monitoring và Auto-Remediation Họ có hơn 2500 cụm K3 Họ phải cải thiện quy trình giám sát để chủ động nhận diện và khôi phục mọi vấn đề của cụm. Họ đã phát triển một cách tiếp cận đa chiều Synthetic Client Họ xây dựng một Synthetic Client chạy dưới dạng container trong cụm để kiểm tra các chức năng cốt lõi của nền tảng và phân tích sự cố (vấn đề dịch vụ, độ trễ dữ liệu, v.v.) Khi phát hiện vấn đề, client sẽ báo cáo lên Cloud Control Plane qua API. Đội hỗ trợ sẽ nhận cảnh báo và quy trình remediation tự động sẽ được khởi động Node Heartbeats Cụm Kubernetes có khả năng tự chữa lành, nên ngay cả khi node bị lỗi, workload vẫn tự động được tái cân bằng giữa các node còn hoạt động Để phát hiện lỗi node, họ triển khai một "Heartbeat Pod" đơn giản lên từng node trong cụm Pod này định kỳ báo cáo trạng thái lên API endpoint trên cloud Auto Remediation Thông qua các buổi retrospective hỗ trợ hàng tuần, họ phát hiện ra các mẫu lặp giữa lỗi, xác minh và bước sửa chữa Vì mọi công cụ hỗ trợ đều dựa trên API, họ có thể xây dựng các luồng orchestration cho các API này và thực hiện tự động khắc phục cho các vấn đề thường gặp Năng lực mới Trong khi tiếp tục cải thiện hạ tầng, đội phát triển cũng liên tục phát triển các tính năng nền tảng mới nhằm nâng cao self-service và khả năng hỗ trợ Deployment Orchestration Mô hình GitOps của họ rất đơn giản Ban đầu họ bắt đầu bằng thay đổi thủ công, nhưng sớm tạo ra công cụ tên là "Fleet" để thay đổi cụm và triển khai tới nhiều nhà hàng Khi nền tảng phát triển, họ cần một cách để triển khai trên toàn chuỗi và xác nhận các thất bại cũng như thành công của việc triển khai Ở vòng lặp thứ hai, họ phát triển một Deployment Orchestration API mới Cùng với API, họ triển khai agent phản hồi trên mỗi cụm để báo cáo thông tin triển khai và trạng thái lên cloud Nhờ đó họ có thể tạo các mẫu phát hành trên toàn chuỗi và canary deployment có thể tự quản lý Sự thay đổi này giúp đội có thể tinh chỉnh và quan sát quá trình triển khai ở mức chi tiết hơn, từ đó tăng độ tin cậy triển khai Log Exfiltration Ban đầu, đội DevOps nội bộ được phép truy cập trực tiếp vào các cụm K3s tại nhà hàng để lấy trạng thái thời gian thực và tìm kiếm log Họ có chức năng Log Exfiltration cơ bản, nhưng rất khó sử dụng do độ trễ và các vấn đề mạng Vì muốn giảm thiểu truy cập từ xa vào cụm, họ bổ sung API endpoint Hiện nay họ đã thêm khả năng Log Exfiltration mạnh hơn Họ dùng mã nguồn mở Vector để thu thập và chuyển tiếp log từ cụm biên lên cloud Cung cấp khả năng lọc, lưu trữ và chuyển tiếp, cùng tính năng tự động xoay log Sau khi thiết lập các dịch vụ Vector khác ở phía cloud, họ thu thập log từ mọi edge, áp dụng rule rồi forward sang nhiều công cụ khác nhau (Data Dog, Grafana, CloudWatch, v.v.) Metrics và Dashboards Họ bổ sung khả năng dùng Prometheus Remote Write để thu thập metric từ mọi nhà hàng và gửi tới Grafana trung tâm trên cloud Mỗi cụm K3s ghi nhận trạng thái, node và workload của các dịch vụ cốt lõi Họ cũng bổ sung khả năng publish các business metric tùy chỉnh Kết luận "Restaurant Compute Platform" và quy trình hỗ trợ của họ đã đủ trưởng thành để cho phép một đội phát triển nhỏ vẫn cung cấp mức ổn định cao và hỗ trợ khách hàng tốt Những điều rút ra Để một đội nhỏ xây dựng một nền tảng Edge Compute MVP mang tính business-critical, cần có kỹ thuật xuất sắc và những đánh đổi thông minh Vận hành hơn 2500 cụm Kubernetes với một đội nhỏ là việc rất khó, nhưng cách tiếp cận tự động hóa API-first đã giúp ích rất nhiều Khi xuất phát từ một thế giới cloud-first, thách thức lớn nhất là edge có nhiều ràng buộc (năng lực tính toán, băng thông mạng hạn chế, truy cập từ xa) Nên đầu tư nhiều thời gian để hiểu rõ các ràng buộc, rồi cân nhắc nên loại bỏ chúng hay quản lý chúng, vì việc loại bỏ thường tốn nhiều thời gian và chi phí

(medium.com)

36 điểm bởi xguru 2023-01-23 | 5 bình luận | Chia sẻ qua WhatsApp

Chuỗi thức ăn nhanh gà rán Chick-Fil-A đang vận hành các cụm Kubernetes biên tại từng nhà hàng
Mọi thiết bị tại mỗi cửa hàng (nồi chiên, bếp nướng, v.v.) liên tục cung cấp thông tin telemetry IoT, kết nối tới hàng chục nghìn thiết bị
Từ các dữ liệu này, hệ thống dự báo nhu cầu theo thời gian thực và gửi lên phía cloud để chạy các quy trình phân tích
Mọi thứ đều được tích hợp, từ quy trình nấu nướng nội bộ đến các terminal thanh toán di động (drive-thru)

Nền tảng Restaurant Edge Compute

Nhiều hệ thống hiện tại được thiết kế cho cloud/data center
Chúng không phù hợp với môi trường tài nguyên hạn chế, kết nối Internet không ổn định và hàng nghìn cụm Kubernetes
Vì vậy họ quyết định tự xây dựng. Họ tạo MVP và bắt đầu học hỏi bằng cách triển khai thực tế

Phần cứng

Họ quyết định sử dụng Intel NUC dành cho người tiêu dùng phổ thông
Gom các thế hệ NUC để tạo cụm 3 node, đủ linh hoạt để đáp ứng độ an toàn, dung lượng và cấu hình HA

OS

Ở bản phát hành đầu tiên, Ubuntu được dùng làm OS mặc định
Mục tiêu thiết kế là chỉ cần drop-ship NUC đến nhà hàng, không cần cấu hình thủ công cho từng địa điểm
Tức là mọi provisioning đều vận hành động on-the-fly
Dĩ nhiên, một số tính năng bảo mật được áp dụng để ngăn thiết bị khác tham gia cụm hoặc truy cập dịch vụ cloud nội bộ

Edge Commander

Quy trình bootstrap và quản lý cụm
Mỗi node trong cụm biên được xây dựng từ cùng một image
Cũng bao gồm một số kỹ thuật dùng nhiều phân vùng đĩa và OverlayFS
- Chẳng hạn như giữ lại một số dữ liệu dài hạn hoặc từ xa xóa "wipe" các phân vùng khác của node

Kubernetes

Họ quyết định dùng bản triển khai K3s
- Tương thích với đặc tả Kubernetes nhưng loại bỏ một số tính năng. Việc cấu hình và hỗ trợ ở quy mô lớn rất đơn giản
Vì không dùng cloud nên họ không cần toàn bộ tính năng của Kubernetes
Họ rất hài lòng và không có ý định thay đổi trong tương lai

GitOps

Khi xây dựng bản phát hành nền tảng đầu tiên, chưa có giải pháp agent GitOps nào có thể chạy trên edge bị giới hạn tài nguyên
Họ phát triển agent riêng có tên là 'Vessel'
Agent này poll Git Repo (mỗi cửa hàng có một repo riêng) và xử lý các thay đổi của cụm
Họ đang host một instance GitLab mã nguồn mở trên cụm Kubernetes của cloud
Họ không muốn mang gánh nặng tự vận hành Git server, nhưng cũng không tìm được mô hình giấy phép hosting nào hiệu quả về chi phí

Deployments

Để phục vụ GitOps, mỗi chi nhánh chỉ định Git Repo riêng của mình (được gọi là Atlas)
Có thể triển khai mới cho từng nhà hàng bằng cách merge cấu hình mới vào nhánh master của Atlas
Cách tiếp cận này có một số đánh đổi với quản trị enterprise, nhưng lại giúp việc quản lý trạng thái triển khai và audit trở nên rất đơn giản

Hỗ trợ triển khai trên toàn chuỗi

Thách thức lớn nhất là biến MVP thành một nền tảng vừa scalable vừa dễ hỗ trợ, đồng thời vẫn có thể được duy trì bởi một đội rất nhỏ

Chiến lược API First

Việc đầu tiên của họ là bọc toàn bộ quy trình thủ công và các bước kiểm tra hợp lệ bằng Restful API
Sau khi tạo bộ API toàn diện cho từng bước, họ xây dựng một lớp orchestration ở phía trên để bắt đầu tự động hóa các quy trình thủ công
Bằng cách tạo một dự án PostMan đầy đủ và được tài liệu hóa tốt, họ có thể nhanh chóng tận dụng các API mới và trì hoãn việc xây Web UI cho đội hỗ trợ
Dùng OAuth để cung cấp quyền truy cập chi tiết theo từng bước vào bộ API. Nhờ đó họ có thể dễ dàng khóa một số tính năng hoặc mở các endpoint trạng thái và báo cáo không xâm lấn cho khách hàng

Đội ngũ triển khai chuyên trách

Làm thế nào họ có thể triển khai số lượng lớn thiết bị cho từng chuỗi trong thời gian ngắn?
Đội phát triển cốt lõi quá nhỏ, nên khó vừa hỗ trợ và phát triển nền tảng, vừa phụ trách rollout toàn chuỗi
Họ gửi trước 3 chiếc NUC để cài đặt trước toàn bộ rollout, phần còn lại chỉ là cấu hình và xác minh
Vì bộ API Suite đã hoạt động, họ nhanh chóng lập một "đội hỗ trợ bán kỹ thuật" chuyên trách việc phát hành nền tảng, theo dõi trạng thái và xử lý các vấn đề hỗ trợ đơn giản
Họ nhanh chóng tăng cường đội rollout bằng Pair-Support, playbook và vòng lặp phản hồi tài liệu
Chỉ sau vài tuần, đội đã có thể tự vận hành và hoàn tất rollout toàn chuỗi
Sau đó, thông qua một cấu trúc tổ chức bài bản, họ có thể tiếp tục mở rộng với các tính năng mới mà vẫn duy trì hỗ trợ nền tảng rất tốt
Mục tiêu của họ là tự động hóa những phần mang tính tác nghiệp, và đẩy phần việc hỗ trợ còn lại lên mức cao nhất có thể trong chuỗi hỗ trợ
Họ đạt được điều này thông qua vòng phản hồi giữa First Tier Support và đội Support DevOps
- Mọi issue đều bắt đầu từ tuyến hỗ trợ đầu tiên
- Nếu không thể giải quyết, hoặc phát sinh vấn đề mới và phức tạp, issue sẽ được chuyển cho đội Support DevOps
- Hai đội cùng phối hợp giải quyết, còn đội First Tier sẽ cập nhật tài liệu và playbook để lần sau có thể tự xử lý các vấn đề tương tự
- Qua các buổi retrospective hỗ trợ hàng tuần, họ thêm các cơ hội cải tiến và tự động hóa vào backlog của đội DevOps
- Đồng thời đội Support DevOps cũng tác động đến backlog của đội phát triển mới để ưu tiên những việc nhằm cải thiện công cụ hoặc nâng cao năng lực hỗ trợ

Monitoring và Auto-Remediation

Họ có hơn 2500 cụm K3
Họ phải cải thiện quy trình giám sát để chủ động nhận diện và khôi phục mọi vấn đề của cụm. Họ đã phát triển một cách tiếp cận đa chiều

Synthetic Client

Họ xây dựng một Synthetic Client chạy dưới dạng container trong cụm để kiểm tra các chức năng cốt lõi của nền tảng và phân tích sự cố (vấn đề dịch vụ, độ trễ dữ liệu, v.v.)
Khi phát hiện vấn đề, client sẽ báo cáo lên Cloud Control Plane qua API. Đội hỗ trợ sẽ nhận cảnh báo và quy trình remediation tự động sẽ được khởi động

Node Heartbeats

Cụm Kubernetes có khả năng tự chữa lành, nên ngay cả khi node bị lỗi, workload vẫn tự động được tái cân bằng giữa các node còn hoạt động
Để phát hiện lỗi node, họ triển khai một "Heartbeat Pod" đơn giản lên từng node trong cụm
Pod này định kỳ báo cáo trạng thái lên API endpoint trên cloud

Auto Remediation

Thông qua các buổi retrospective hỗ trợ hàng tuần, họ phát hiện ra các mẫu lặp giữa lỗi, xác minh và bước sửa chữa
Vì mọi công cụ hỗ trợ đều dựa trên API, họ có thể xây dựng các luồng orchestration cho các API này và thực hiện tự động khắc phục cho các vấn đề thường gặp

Năng lực mới

Trong khi tiếp tục cải thiện hạ tầng, đội phát triển cũng liên tục phát triển các tính năng nền tảng mới nhằm nâng cao self-service và khả năng hỗ trợ

Deployment Orchestration

Mô hình GitOps của họ rất đơn giản
Ban đầu họ bắt đầu bằng thay đổi thủ công, nhưng sớm tạo ra công cụ tên là "Fleet" để thay đổi cụm và triển khai tới nhiều nhà hàng
Khi nền tảng phát triển, họ cần một cách để triển khai trên toàn chuỗi và xác nhận các thất bại cũng như thành công của việc triển khai
Ở vòng lặp thứ hai, họ phát triển một Deployment Orchestration API mới
- Cùng với API, họ triển khai agent phản hồi trên mỗi cụm để báo cáo thông tin triển khai và trạng thái lên cloud
Nhờ đó họ có thể tạo các mẫu phát hành trên toàn chuỗi và canary deployment có thể tự quản lý
Sự thay đổi này giúp đội có thể tinh chỉnh và quan sát quá trình triển khai ở mức chi tiết hơn, từ đó tăng độ tin cậy triển khai

Log Exfiltration

Ban đầu, đội DevOps nội bộ được phép truy cập trực tiếp vào các cụm K3s tại nhà hàng để lấy trạng thái thời gian thực và tìm kiếm log
Họ có chức năng Log Exfiltration cơ bản, nhưng rất khó sử dụng do độ trễ và các vấn đề mạng
Vì muốn giảm thiểu truy cập từ xa vào cụm, họ bổ sung API endpoint
Hiện nay họ đã thêm khả năng Log Exfiltration mạnh hơn
Họ dùng mã nguồn mở Vector để thu thập và chuyển tiếp log từ cụm biên lên cloud
- Cung cấp khả năng lọc, lưu trữ và chuyển tiếp, cùng tính năng tự động xoay log
- Sau khi thiết lập các dịch vụ Vector khác ở phía cloud, họ thu thập log từ mọi edge, áp dụng rule rồi forward sang nhiều công cụ khác nhau (Data Dog, Grafana, CloudWatch, v.v.)

Metrics và Dashboards

Họ bổ sung khả năng dùng Prometheus Remote Write để thu thập metric từ mọi nhà hàng và gửi tới Grafana trung tâm trên cloud
Mỗi cụm K3s ghi nhận trạng thái, node và workload của các dịch vụ cốt lõi
Họ cũng bổ sung khả năng publish các business metric tùy chỉnh

Kết luận

"Restaurant Compute Platform" và quy trình hỗ trợ của họ đã đủ trưởng thành để cho phép một đội phát triển nhỏ vẫn cung cấp mức ổn định cao và hỗ trợ khách hàng tốt

Những điều rút ra

Để một đội nhỏ xây dựng một nền tảng Edge Compute MVP mang tính business-critical, cần có kỹ thuật xuất sắc và những đánh đổi thông minh
Vận hành hơn 2500 cụm Kubernetes với một đội nhỏ là việc rất khó, nhưng cách tiếp cận tự động hóa API-first đã giúp ích rất nhiều
Khi xuất phát từ một thế giới cloud-first, thách thức lớn nhất là edge có nhiều ràng buộc (năng lực tính toán, băng thông mạng hạn chế, truy cập từ xa)
Nên đầu tư nhiều thời gian để hiểu rõ các ràng buộc, rồi cân nhắc nên loại bỏ chúng hay quản lý chúng, vì việc loại bỏ thường tốn nhiều thời gian và chi phí

5 bình luận

ddwax89 2023-01-24

Quá đỉnh luôn haha

ragingwind 2023-01-23

Đúng là họ đã xây dựng từ tầng nền tảng lên. Quá trình áp dụng cũng mang lại rất nhiều cảm hứng.

nicewook 2023-01-23

Đây đúng là một ví dụ quá tuyệt vời và đầy hứng khởi. Tôi cũng muốn thử tự làm một cái như thế này.
Hóa ra đây là một chủ đề đã có từ năm 2018, nên cũng phần nào yên tâm nhỉ? Không phải là thứ được làm ra trong một sớm một chiều.
Để sau này tôi sẽ đọc lại thật kỹ thêm một lần nữa.

kbumsik 2023-01-23

Burger gà của Chick-Fil-A ngon thật đấy haha

Ngay từ năm 2018 đã có một bài đăng về cùng chủ đề này rồi, khi đó nó mang cảm giác hơi thử nghiệm, nhưng có vẻ họ đã duy trì được cho tới bây giờ. Ngay trong bài viết cũng có thể thấy được lượng kinh nghiệm họ đã tích lũy trong thời gian qua.

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

xguru 2023-01-23

Đây là chuỗi cửa hàng chưa vào thị trường Hàn Quốc nên gần như không có độ nhận biết tại đây, nhưng cũng là nhà hàng rất được giới teen ưa chuộng khi luôn đứng số 1 trong hạng mục nhà hàng ở khảo sát mức độ yêu thích doanh nghiệp của thanh thiếu niên Mỹ do Piper Sandler công bố hai lần mỗi năm.