Arsitektur Teknologi Edge Computing Chick-fil-A: Enterprise Restaurant Compute

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

Jaringan restoran cepat saji ayam Chick-fil-A mengoperasikan klaster Kubernetes edge di setiap restoran Semua perangkat di tiap gerai (penggoreng, grill, dan lain-lain) terus-menerus menyediakan informasi telemetri IoT, sehingga puluhan ribu perangkat terhubung Dari informasi ini, prediksi permintaan dilakukan secara real-time lalu dikirim ke sisi cloud untuk menjalankan proses analisis Semuanya terintegrasi, mulai dari proses memasak internal hingga terminal pembayaran mobile (drive-thru) Platform Restaurant Edge Compute Banyak sistem saat ini dirancang untuk cloud/pusat data Sistem-sistem itu tidak cocok untuk lingkungan dengan sumber daya terbatas, koneksi internet yang kurang baik, dan ribuan klaster Kubernetes Karena itu, mereka memutuskan untuk membuatnya sendiri. Mereka membangun MVP dan mulai belajar sambil benar-benar memasangnya di lapangan Perangkat keras Diputuskan untuk menggunakan Intel NUC kelas konsumen biasa Generasi NUC digabungkan untuk membentuk klaster 3 node agar fleksibel dalam menangani keandalan, kapasitas, hingga konfigurasi HA OS Pada rilis pertama, Ubuntu digunakan sebagai OS dasar Tujuan desainnya adalah cukup melakukan dropship NUC ke restoran, tanpa perlu konfigurasi manual per restoran Artinya, semua provisioning berjalan secara dinamis on-the-fly Tentu saja, ada beberapa fitur keamanan untuk mencegah perangkat lain bergabung ke klaster atau mengakses layanan cloud internal Edge Commander Proses bootstrap dan manajemen klaster Setiap node klaster edge dibangun dengan image yang sama Termasuk juga trik menggunakan beberapa partisi disk dan OverlayFS Misalnya kemampuan mempertahankan data tertentu dalam jangka panjang, atau menghapus jarak jauh partisi lain pada node dengan fitur "Wipe" Kubernetes Diputuskan untuk menggunakan implementasi K3s Kompatibel dengan spesifikasi Kubernetes, tetapi beberapa fitur dihapus. Sangat mudah dikonfigurasi dan didukung dalam skala besar Karena tidak menggunakan cloud, mereka tidak memerlukan seluruh fitur Kubernetes Mereka sangat puas dan tidak berencana menggantinya ke depan GitOps Saat membangun rilis platform pertama, belum ada solusi agen GitOps yang bisa berjalan di edge dengan sumber daya terbatas Mereka mengembangkan agen sendiri yang disebut Vessel Agen ini melakukan polling Git Repo (repo unik untuk tiap toko) dan menangani perubahan pada klaster Mereka meng-host instance GitLab open source pada klaster Kubernetes di cloud Mereka tidak ingin menanggung beban mengoperasikan server Git sendiri, tetapi tidak bisa menemukan model lisensi solusi hosting yang efisien dari sisi biaya Deployment Untuk GitOps, tiap cabang menunjuk Git Repo miliknya sendiri (disebut Atlas) Deployment baru ke tiap restoran dapat dilakukan dengan me-merge konfigurasi baru ke branch master Atlas Pendekatan ini memiliki beberapa trade-off untuk manajemen enterprise, tetapi sangat menyederhanakan pengelolaan status deployment dan audit Mendukung Deployment di Seluruh Jaringan Tantangan terbesar adalah mengubah MVP menjadi platform yang skalabel, dapat didukung, dan tetap bisa dipelihara oleh tim yang sangat kecil Strategi API First Prioritas pertama bisnis adalah membungkus semua proses manual dan langkah validasi ke dalam Restful API Setelah membuat rangkaian API yang komprehensif untuk tiap langkah, mereka membangun lapisan orkestrasi di atasnya untuk mulai mengotomatisasi proses manual Dengan membuat proyek PostMan yang komprehensif dan terdokumentasi dengan baik, mereka bisa dengan cepat memanfaatkan API baru dan menunda pembuatan Web UI untuk tim support Dengan memanfaatkan OAuth, mereka menyediakan akses granular per langkah ke API Suite. Mereka bisa dengan mudah mengunci fungsi tertentu, atau membuka endpoint status dan pelaporan yang non-invasif bagi pelanggan Tim Rollout Khusus Bagaimana mereka bisa menyebarkan begitu banyak perangkat ke tiap jaringan dalam waktu singkat? Tim pengembang inti sangat kecil, sehingga sulit mendukung pengembangan dan support platform sekaligus rollout ke seluruh jaringan Mereka lebih dulu mengirim dan memasang 3 unit NUC sebelum rollout penuh, dan sisanya hanya tahap konfigurasi dan verifikasi Karena API Suite sudah berjalan, mereka dapat dengan cepat membentuk "tim support semi-teknis" yang khusus menangani peluncuran platform, pemantauan status, dan penyelesaian masalah support sederhana Dengan memanfaatkan pair-support, playbook, dan loop umpan balik dokumentasi, mereka memperkuat tim rollout dengan cepat Dalam beberapa minggu, tim tersebut menjadi mandiri dan berhasil menyelesaikan rollout ke seluruh jaringan Setelah itu, melalui struktur yang tertata, mereka bisa terus menambahkan fitur baru dan melakukan ekspansi sambil tetap memberikan support yang sangat baik untuk platform Tujuan mereka adalah mengotomatisasi bagian-bagian operasional, dan mendorong sisa pekerjaan support ke tingkat setinggi mungkin dalam rantai support Ini dicapai melalui loop umpan balik antara First Tier Support dan tim Support DevOps Semua isu dimulai melalui first tier Jika tidak bisa diselesaikan, atau muncul masalah baru dan kompleks, isu diteruskan ke tim Support DevOps Kedua tim bekerja sama menyelesaikan masalah, dan tim First Tier memperbarui dokumentasi serta playbook agar dapat menangani masalah serupa secara langsung di lain waktu Melalui retrospektif support mingguan, peluang peningkatan dan perbaikan otomatis ditambahkan ke backlog tim DevOps Selain itu, tim Support DevOps juga memengaruhi backlog tim pengembangan baru, mulai dari penentuan prioritas untuk alat baru hingga peningkatan support Monitoring dan Auto-Remediation Ada lebih dari 2500 klaster K3 Mereka perlu meningkatkan proses monitoring untuk mengidentifikasi dan memulihkan semua masalah klaster secara proaktif. Mereka mengembangkan pendekatan multi-sisi Synthetic Client Mereka membangun Synthetic Client yang berjalan sebagai container di dalam klaster untuk menguji fungsi platform inti dan menganalisis masalah (masalah layanan, latensi data, dll.) Jika masalah ditemukan, klien melaporkannya ke Cloud Control Plane melalui API. Tim support diberi notifikasi dan proses remediation otomatis dimulai Heartbeat Node Klaster Kubernetes memiliki kemampuan self-healing, sehingga walaupun terjadi kegagalan node, workload otomatis diseimbangkan ulang di antara node yang aktif Untuk mendeteksi kegagalan node, mereka men-deploy "Heartbeat Pod" sederhana ke setiap node dalam klaster Pod ini secara berkala melaporkan status ke endpoint API di cloud Auto Remediation Melalui retrospektif support mingguan, mereka menemukan pola antara error, validasi, dan langkah perbaikan Karena semua alat support berbasis API, mereka dapat membangun alur orkestrasi di atas API tersebut dan melakukan perbaikan otomatis untuk masalah yang umum terjadi Kapabilitas Baru Sambil terus menyempurnakan infrastruktur, tim pengembang juga terus mengembangkan fitur platform baru untuk meningkatkan self-service dan kemudahan support Orkestrasi Deployment Model GitOps mereka sederhana Awalnya dimulai dari perubahan manual, tetapi tak lama kemudian mereka membuat alat bernama "Fleet" yang dapat melakukan perubahan klaster dan deployment ke banyak restoran Seiring pertumbuhan platform, mereka membutuhkan cara untuk melakukan deployment ke seluruh jaringan serta memverifikasi kegagalan dan keberhasilan deployment Pada iterasi kedua, mereka mengembangkan API Deployment Orchestration baru Bersamaan dengan API tersebut, mereka men-deploy agen umpan balik ke tiap klaster agar melaporkan deployment dan informasi status ke cloud Ini memungkinkan mereka membuat pola rilis ke seluruh jaringan dan pola deployment canary yang dapat dikelola sendiri Dengan perubahan ini, tim dapat menyetel deployment secara rinci dan mengamatinya, sehingga keandalan deployment meningkat Log Exfiltration Pada awalnya, tim DevOps internal diizinkan mengakses langsung klaster K3s di restoran agar bisa mengambil status dan menelusuri log secara real-time Mereka memiliki kemampuan Log Exfiltration dasar, tetapi sangat sulit digunakan karena latensi dan masalah jaringan Karena mereka ingin meminimalkan akses jarak jauh ke klaster, mereka menambahkan endpoint API Saat ini mereka telah menambahkan kemampuan Log Exfiltration yang lebih kuat Mereka memanfaatkan open source bernama Vector untuk mengumpulkan dan meneruskan log dari klaster edge ke cloud Menyediakan kemampuan filtering, penyimpanan dan penerusan, serta rotasi log otomatis Setelah menyiapkan layanan Vector lain di sisi cloud, mereka mengumpulkan log dari seluruh edge, menerapkan aturan, dan meneruskannya ke berbagai alat (Data Dog, Grafana, CloudWatch, dll.) Metrik dan Dashboard Mereka menambahkan kemampuan untuk mengumpulkan metrik dari semua restoran menggunakan Prometheus Remote Write, lalu mengirimkannya ke Grafana terpusat di cloud Tiap klaster K3s menangkap status, node, dan workload layanan inti Mereka juga menambahkan kemampuan untuk memublikasikan metrik bisnis kustom Kesimpulan "Restaurant Compute Platform" mereka dan proses support-nya sudah cukup matang untuk memungkinkan tim pengembang kecil memberikan tingkat stabilitas dan dukungan pelanggan yang tinggi Hal-hal yang dipelajari Agar tim kecil dapat membangun platform Edge Compute MVP yang mission-critical bagi bisnis, dibutuhkan engineering yang sangat baik dan kompromi yang cerdas Mengoperasikan lebih dari 2500 klaster Kubernetes dengan tim kecil adalah pekerjaan yang sangat berat, tetapi pendekatan otomatisasi berbasis API-first sangat membantu Saat datang dari dunia cloud-first, tantangan terbesarnya adalah bahwa edge memiliki keterbatasan (kapasitas komputasi, bandwidth jaringan terbatas, akses jarak jauh) Sebaiknya luangkan banyak waktu untuk memahami kendala-kendala tersebut, lalu pertimbangkan apakah kendala itu perlu dihilangkan (yang memakan banyak waktu dan biaya) atau cukup dikelola

(medium.com)

36 poin oleh xguru 2023-01-23 | 5 komentar | Bagikan ke WhatsApp

Jaringan restoran cepat saji ayam Chick-fil-A mengoperasikan klaster Kubernetes edge di setiap restoran
Semua perangkat di tiap gerai (penggoreng, grill, dan lain-lain) terus-menerus menyediakan informasi telemetri IoT, sehingga puluhan ribu perangkat terhubung
Dari informasi ini, prediksi permintaan dilakukan secara real-time lalu dikirim ke sisi cloud untuk menjalankan proses analisis
Semuanya terintegrasi, mulai dari proses memasak internal hingga terminal pembayaran mobile (drive-thru)

Platform Restaurant Edge Compute

Banyak sistem saat ini dirancang untuk cloud/pusat data
Sistem-sistem itu tidak cocok untuk lingkungan dengan sumber daya terbatas, koneksi internet yang kurang baik, dan ribuan klaster Kubernetes
Karena itu, mereka memutuskan untuk membuatnya sendiri. Mereka membangun MVP dan mulai belajar sambil benar-benar memasangnya di lapangan

Perangkat keras

Diputuskan untuk menggunakan Intel NUC kelas konsumen biasa
Generasi NUC digabungkan untuk membentuk klaster 3 node agar fleksibel dalam menangani keandalan, kapasitas, hingga konfigurasi HA

OS

Pada rilis pertama, Ubuntu digunakan sebagai OS dasar
Tujuan desainnya adalah cukup melakukan dropship NUC ke restoran, tanpa perlu konfigurasi manual per restoran
Artinya, semua provisioning berjalan secara dinamis on-the-fly
Tentu saja, ada beberapa fitur keamanan untuk mencegah perangkat lain bergabung ke klaster atau mengakses layanan cloud internal

Edge Commander

Proses bootstrap dan manajemen klaster
Setiap node klaster edge dibangun dengan image yang sama
Termasuk juga trik menggunakan beberapa partisi disk dan OverlayFS
- Misalnya kemampuan mempertahankan data tertentu dalam jangka panjang, atau menghapus jarak jauh partisi lain pada node dengan fitur "Wipe"

Kubernetes

Diputuskan untuk menggunakan implementasi K3s
- Kompatibel dengan spesifikasi Kubernetes, tetapi beberapa fitur dihapus. Sangat mudah dikonfigurasi dan didukung dalam skala besar
Karena tidak menggunakan cloud, mereka tidak memerlukan seluruh fitur Kubernetes
Mereka sangat puas dan tidak berencana menggantinya ke depan

GitOps

Saat membangun rilis platform pertama, belum ada solusi agen GitOps yang bisa berjalan di edge dengan sumber daya terbatas
Mereka mengembangkan agen sendiri yang disebut Vessel
Agen ini melakukan polling Git Repo (repo unik untuk tiap toko) dan menangani perubahan pada klaster
Mereka meng-host instance GitLab open source pada klaster Kubernetes di cloud
Mereka tidak ingin menanggung beban mengoperasikan server Git sendiri, tetapi tidak bisa menemukan model lisensi solusi hosting yang efisien dari sisi biaya

Deployment

Untuk GitOps, tiap cabang menunjuk Git Repo miliknya sendiri (disebut Atlas)
Deployment baru ke tiap restoran dapat dilakukan dengan me-merge konfigurasi baru ke branch master Atlas
Pendekatan ini memiliki beberapa trade-off untuk manajemen enterprise, tetapi sangat menyederhanakan pengelolaan status deployment dan audit

Mendukung Deployment di Seluruh Jaringan

Tantangan terbesar adalah mengubah MVP menjadi platform yang skalabel, dapat didukung, dan tetap bisa dipelihara oleh tim yang sangat kecil

Strategi API First

Prioritas pertama bisnis adalah membungkus semua proses manual dan langkah validasi ke dalam Restful API
Setelah membuat rangkaian API yang komprehensif untuk tiap langkah, mereka membangun lapisan orkestrasi di atasnya untuk mulai mengotomatisasi proses manual
Dengan membuat proyek PostMan yang komprehensif dan terdokumentasi dengan baik, mereka bisa dengan cepat memanfaatkan API baru dan menunda pembuatan Web UI untuk tim support
Dengan memanfaatkan OAuth, mereka menyediakan akses granular per langkah ke API Suite. Mereka bisa dengan mudah mengunci fungsi tertentu, atau membuka endpoint status dan pelaporan yang non-invasif bagi pelanggan

Tim Rollout Khusus

Bagaimana mereka bisa menyebarkan begitu banyak perangkat ke tiap jaringan dalam waktu singkat?
Tim pengembang inti sangat kecil, sehingga sulit mendukung pengembangan dan support platform sekaligus rollout ke seluruh jaringan
Mereka lebih dulu mengirim dan memasang 3 unit NUC sebelum rollout penuh, dan sisanya hanya tahap konfigurasi dan verifikasi
Karena API Suite sudah berjalan, mereka dapat dengan cepat membentuk "tim support semi-teknis" yang khusus menangani peluncuran platform, pemantauan status, dan penyelesaian masalah support sederhana
Dengan memanfaatkan pair-support, playbook, dan loop umpan balik dokumentasi, mereka memperkuat tim rollout dengan cepat
Dalam beberapa minggu, tim tersebut menjadi mandiri dan berhasil menyelesaikan rollout ke seluruh jaringan
Setelah itu, melalui struktur yang tertata, mereka bisa terus menambahkan fitur baru dan melakukan ekspansi sambil tetap memberikan support yang sangat baik untuk platform
Tujuan mereka adalah mengotomatisasi bagian-bagian operasional, dan mendorong sisa pekerjaan support ke tingkat setinggi mungkin dalam rantai support
Ini dicapai melalui loop umpan balik antara First Tier Support dan tim Support DevOps
- Semua isu dimulai melalui first tier
- Jika tidak bisa diselesaikan, atau muncul masalah baru dan kompleks, isu diteruskan ke tim Support DevOps
- Kedua tim bekerja sama menyelesaikan masalah, dan tim First Tier memperbarui dokumentasi serta playbook agar dapat menangani masalah serupa secara langsung di lain waktu
- Melalui retrospektif support mingguan, peluang peningkatan dan perbaikan otomatis ditambahkan ke backlog tim DevOps
- Selain itu, tim Support DevOps juga memengaruhi backlog tim pengembangan baru, mulai dari penentuan prioritas untuk alat baru hingga peningkatan support

Monitoring dan Auto-Remediation

Ada lebih dari 2500 klaster K3
Mereka perlu meningkatkan proses monitoring untuk mengidentifikasi dan memulihkan semua masalah klaster secara proaktif. Mereka mengembangkan pendekatan multi-sisi

Synthetic Client

Mereka membangun Synthetic Client yang berjalan sebagai container di dalam klaster untuk menguji fungsi platform inti dan menganalisis masalah (masalah layanan, latensi data, dll.)
Jika masalah ditemukan, klien melaporkannya ke Cloud Control Plane melalui API. Tim support diberi notifikasi dan proses remediation otomatis dimulai

Heartbeat Node

Klaster Kubernetes memiliki kemampuan self-healing, sehingga walaupun terjadi kegagalan node, workload otomatis diseimbangkan ulang di antara node yang aktif
Untuk mendeteksi kegagalan node, mereka men-deploy "Heartbeat Pod" sederhana ke setiap node dalam klaster
Pod ini secara berkala melaporkan status ke endpoint API di cloud

Auto Remediation

Melalui retrospektif support mingguan, mereka menemukan pola antara error, validasi, dan langkah perbaikan
Karena semua alat support berbasis API, mereka dapat membangun alur orkestrasi di atas API tersebut dan melakukan perbaikan otomatis untuk masalah yang umum terjadi

Kapabilitas Baru

Sambil terus menyempurnakan infrastruktur, tim pengembang juga terus mengembangkan fitur platform baru untuk meningkatkan self-service dan kemudahan support

Orkestrasi Deployment

Model GitOps mereka sederhana
Awalnya dimulai dari perubahan manual, tetapi tak lama kemudian mereka membuat alat bernama "Fleet" yang dapat melakukan perubahan klaster dan deployment ke banyak restoran
Seiring pertumbuhan platform, mereka membutuhkan cara untuk melakukan deployment ke seluruh jaringan serta memverifikasi kegagalan dan keberhasilan deployment
Pada iterasi kedua, mereka mengembangkan API Deployment Orchestration baru
- Bersamaan dengan API tersebut, mereka men-deploy agen umpan balik ke tiap klaster agar melaporkan deployment dan informasi status ke cloud
Ini memungkinkan mereka membuat pola rilis ke seluruh jaringan dan pola deployment canary yang dapat dikelola sendiri
Dengan perubahan ini, tim dapat menyetel deployment secara rinci dan mengamatinya, sehingga keandalan deployment meningkat

Log Exfiltration

Pada awalnya, tim DevOps internal diizinkan mengakses langsung klaster K3s di restoran agar bisa mengambil status dan menelusuri log secara real-time
Mereka memiliki kemampuan Log Exfiltration dasar, tetapi sangat sulit digunakan karena latensi dan masalah jaringan
Karena mereka ingin meminimalkan akses jarak jauh ke klaster, mereka menambahkan endpoint API
Saat ini mereka telah menambahkan kemampuan Log Exfiltration yang lebih kuat
Mereka memanfaatkan open source bernama Vector untuk mengumpulkan dan meneruskan log dari klaster edge ke cloud
- Menyediakan kemampuan filtering, penyimpanan dan penerusan, serta rotasi log otomatis
- Setelah menyiapkan layanan Vector lain di sisi cloud, mereka mengumpulkan log dari seluruh edge, menerapkan aturan, dan meneruskannya ke berbagai alat (Data Dog, Grafana, CloudWatch, dll.)

Metrik dan Dashboard

Mereka menambahkan kemampuan untuk mengumpulkan metrik dari semua restoran menggunakan Prometheus Remote Write, lalu mengirimkannya ke Grafana terpusat di cloud
Tiap klaster K3s menangkap status, node, dan workload layanan inti
Mereka juga menambahkan kemampuan untuk memublikasikan metrik bisnis kustom

Kesimpulan

"Restaurant Compute Platform" mereka dan proses support-nya sudah cukup matang untuk memungkinkan tim pengembang kecil memberikan tingkat stabilitas dan dukungan pelanggan yang tinggi

Hal-hal yang dipelajari

Agar tim kecil dapat membangun platform Edge Compute MVP yang mission-critical bagi bisnis, dibutuhkan engineering yang sangat baik dan kompromi yang cerdas
Mengoperasikan lebih dari 2500 klaster Kubernetes dengan tim kecil adalah pekerjaan yang sangat berat, tetapi pendekatan otomatisasi berbasis API-first sangat membantu
Saat datang dari dunia cloud-first, tantangan terbesarnya adalah bahwa edge memiliki keterbatasan (kapasitas komputasi, bandwidth jaringan terbatas, akses jarak jauh)
Sebaiknya luangkan banyak waktu untuk memahami kendala-kendala tersebut, lalu pertimbangkan apakah kendala itu perlu dihilangkan (yang memakan banyak waktu dan biaya) atau cukup dikelola

5 komentar

ddwax89 2023-01-24

Luar biasa ya, hehe

ragingwind 2023-01-23

Benar-benar dibangun dari bawah. Ini juga memberi banyak inspirasi dalam proses penerapannya.

nicewook 2023-01-23

Ini contoh yang sangat keren dan menarik. Saya juga ingin mencoba membuat yang seperti ini.
Ternyata ini sudah menjadi topik sejak 2018, jadi setidaknya agak melegakan, ya? Rupanya ini bukan sesuatu yang dibuat dadakan dalam semalam.
Nanti saya harus membacanya lagi sekali dengan lebih saksama.

kbumsik 2023-01-23

Burger ayam Chick-fil-A memang enak sekali, ya haha

Bahkan pada 2018 sudah ada postingan tentang topik yang sama, waktu itu terasa agak eksperimental, tetapi ternyata terus dipertahankan sampai sekarang. Dari tulisannya juga terlihat bahwa selama ini pengetahuan dan pengalaman mereka terus terakumulasi.

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

xguru 2023-01-23

Meski gerai ini belum masuk ke Korea sehingga tingkat pengenalannya di dalam negeri hampir tidak ada, restoran ini juga merupakan salah satu restoran favorit remaja yang selalu menempati peringkat pertama dalam preferensi restoran pada survei preferensi merek perusahaan di kalangan remaja AS yang diterbitkan dua kali setahun oleh Piper Sandler.