สถาปัตยกรรมเทคโนโลยี Edge Computing ของ Chick-Fil-A : Enterprise Restaurant Compute

• เครือร้านฟาสต์ฟู้ดไก่ Chick-Fil-A กำลังรันคลัสเตอร์ Kubernetes แบบเอดจ์ในแต่ละร้าน
• อุปกรณ์ทั้งหมดในแต่ละสาขา (เช่น หม้อทอด, เตาย่าง ฯลฯ) ส่งข้อมูล IoT telemetry อย่างต่อเนื่อง ทำให้มีอุปกรณ์หลายหมื่นเครื่องเชื่อมต่ออยู่
• จากข้อมูลเหล่านี้มีการคาดการณ์ความต้องการแบบเรียลไทม์ และส่งไปยังฝั่งคลาวด์เพื่อรันกระบวนการวิเคราะห์
• ทุกอย่างถูกผสานรวมตั้งแต่กระบวนการปรุงอาหารภายในไปจนถึง mobile payment terminal (drive-thru)

Restaurant Edge Compute platform

• ปัจจุบันหลายระบบถูกออกแบบมาสำหรับคลาวด์/ดาต้าเซ็นเตอร์
• ซึ่งไม่เหมาะกับสภาพแวดล้อมที่ทรัพยากรจำกัด การเชื่อมต่ออินเทอร์เน็ตไม่ดี และต้องดูแลคลัสเตอร์ Kubernetes หลายพันชุด
• จึงตัดสินใจสร้างขึ้นเอง โดยเริ่มจากทำ MVP และเรียนรู้ผ่านการติดตั้งใช้งานจริง

ฮาร์ดแวร์

• ตัดสินใจใช้ Intel NUC สำหรับผู้บริโภคทั่วไป
• จับคู่ NUC หลายเจเนอเรชันเพื่อสร้างคลัสเตอร์ 3 โหนด ให้ยืดหยุ่นพอสำหรับความเสถียร ความจุ และการตั้งค่า HA

OS

• รีลีสแรกใช้ Ubuntu เป็น OS หลัก
• เป้าหมายของการออกแบบคือแค่ dropship NUC ไปที่ร้าน โดยไม่ต้องมีการตั้งค่าด้วยมือแยกตามแต่ละร้าน
• กล่าวคือ provisioning ทั้งหมดต้องทำงานแบบไดนามิก on-the-fly
• แน่นอนว่ามีฟีเจอร์ความปลอดภัยบางอย่างเพื่อป้องกันไม่ให้อุปกรณ์อื่น join เข้าคลัสเตอร์หรือเข้าถึงบริการคลาวด์ภายใน

Edge Commander

• กระบวนการ bootstrap และบริหารจัดการคลัสเตอร์
• โหนดทุกตัวในเอดจ์คลัสเตอร์ถูกสร้างจากอิมเมจเดียวกัน
• รวมถึงเทคนิคต่าง ๆ ที่ใช้หลาย disk partition และ OverlayFS
  • เช่น ฟังก์ชันเก็บข้อมูลบางส่วนไว้ระยะยาว หรือสั่งลบ "Wipe" partition อื่น ๆ ของโหนดจากระยะไกล

Kubernetes

• ตัดสินใจใช้ K3s implementation
  • รองรับ Kubernetes spec แต่ตัดบางฟีเจอร์ออก ทำให้ตั้งค่าและซัพพอร์ตในระดับใหญ่ได้ง่ายมาก
• เนื่องจากไม่ได้ใช้คลาวด์ จึงไม่จำเป็นต้องใช้ความสามารถทั้งหมดของ Kubernetes
• พึงพอใจมากและไม่มีแผนจะเปลี่ยนในอนาคต

GitOps

• ตอนสร้างแพลตฟอร์มรีลีสแรก ยังไม่มีโซลูชัน GitOps agent ที่รันได้บนเอดจ์ซึ่งมีทรัพยากรจำกัด
• จึงพัฒนา agent ของตัวเองที่เรียกว่า 'Vessel'
• มันจะ poll Git repo (repo เฉพาะของแต่ละสโตร์) และจัดการการเปลี่ยนแปลงของคลัสเตอร์
• ปัจจุบันโฮสต์ GitLab instance แบบโอเพ่นซอร์สไว้บน Kubernetes cluster ในคลาวด์
• ไม่ได้อยากแบกรับภาระในการดูแล Git server เอง แต่ก็หาโมเดลไลเซนส์ของโฮสติ้งที่คุ้มค่าไม่ได้

Deployments

• สำหรับ GitOps แต่ละสาขาจะชี้ไปยัง Git repo ของตัวเอง (เรียกว่า Atlas)
• การ deploy ใหม่ไปยังแต่ละร้านทำได้ด้วยการ merge การตั้งค่าใหม่เข้า master branch ของ Atlas
• วิธีนี้มี trade-off บางอย่างในเชิงการจัดการระดับองค์กร แต่ช่วยให้การจัดการสถานะ deployment และการ audit ง่ายมาก

Supporting a Chain-Wide Deployment

• ความท้าทายใหญ่ที่สุดคือการเปลี่ยนจาก MVP ไปเป็นแพลตฟอร์มที่ทีมเล็กมากสามารถดูแลได้ แต่ยัง scale และซัพพอร์ตได้

กลยุทธ์ API First

• ลำดับแรกของงานฝั่งธุรกิจคือห่อทุกกระบวนการแบบ manual และขั้นตอน validation ทั้งหมดด้วย Restful API
• จากนั้นสร้าง API suite ที่ครอบคลุมสำหรับแต่ละขั้นตอน แล้วค่อยสร้าง orchestration layer ด้านบนเพื่อเริ่มทำกระบวนการ manual ให้เป็นอัตโนมัติ
• การสร้างโปรเจกต์ PostMan ที่ครอบคลุมและมีเอกสารดี ช่วยให้สามารถนำ API ใหม่ไปใช้ได้อย่างรวดเร็ว และเลื่อนการทำ Web UI สำหรับทีมซัพพอร์ตออกไปได้
• ใช้ OAuth เพื่อให้สิทธิ์เข้าถึง API suite แบบละเอียดเป็นรายขั้นตอน ทำให้สามารถล็อกบางฟังก์ชันได้ง่าย หรือเปิด endpoint สำหรับสถานะและรายงานแบบ non-invasive ให้ลูกค้าได้

Dedicated Roll Out Team

• ทำอย่างไรจึงสามารถ deploy อุปกรณ์จำนวนมากไปยังทั้งเครือได้ในเวลาสั้น ๆ?
• ทีมพัฒนาหลักมีขนาดเล็กมาก จึงยากที่จะรองรับทั้งการซัพพอร์ตและพัฒนาแพลตฟอร์ม ไปจนถึงการ deploy rollout ทั้งเครือ
• ทีมได้จัดส่ง NUC 3 เครื่องล่วงหน้าเพื่อติดตั้งไว้ก่อน rollout ทั้งหมด และที่เหลือก็เป็นเพียงขั้นตอนการตั้งค่าและตรวจสอบ
• เนื่องจาก API suite พร้อมใช้งานแล้ว จึงสามารถตั้ง "ทีมซัพพอร์ตกึ่งเทคนิค (semi-technical support team)" ขึ้นอย่างรวดเร็วเพื่อรับผิดชอบการเปิดตัวแพลตฟอร์ม การมอนิเตอร์สถานะ และการแก้ปัญหาซัพพอร์ตแบบง่าย
• ใช้ Pair-Support รวมถึง playbook และวงจร feedback ของเอกสาร เพื่อเพิ่มขีดความสามารถของทีม rollout อย่างรวดเร็ว
• ภายในไม่กี่สัปดาห์ ทีมก็สามารถพึ่งพาตัวเองได้และทำ rollout ครอบคลุมทั้งเครือสำเร็จ
• หลังจากนั้นก็สร้างโครงสร้างการทำงานที่เป็นระบบเพื่อให้สามารถขยายฟีเจอร์ใหม่ ๆ พร้อมกับซัพพอร์ตแพลตฟอร์มได้อย่างยอดเยี่ยม
• เป้าหมายคือทำให้ส่วนที่เป็นงานปฏิบัติการเป็นอัตโนมัติ และผลักงานซัพพอร์ตที่เหลือไปยังระดับที่สูงที่สุดเท่าที่จะทำได้ในห่วงโซ่การซัพพอร์ต
• ทำสิ่งนี้ผ่าน feedback loop ระหว่าง First Tier Support และทีม Support DevOps
  • ทุก issue เริ่มต้นผ่าน first tier ก่อน
  • หากแก้ไม่ได้ หรือเกิดปัญหาใหม่ที่ซับซ้อน จะส่งต่อไปยังทีม Support DevOps
  • ทั้งสองทีมร่วมมือกันแก้ปัญหา และทีม First Tier จะอัปเดตเอกสารกับ playbook เพื่อให้ครั้งหน้าหากเกิดปัญหาคล้ายกันจะจัดการเองได้
  • ใช้การทบทวนงานซัพพอร์ตรายสัปดาห์เพื่อเพิ่มโอกาสในการปรับปรุงและทำ automation ลงใน backlog ของทีม DevOps
  • นอกจากนี้ทีม Support DevOps ยังมีอิทธิพลต่อ backlog ของทีมพัฒนาใหม่ เพื่อกำหนดลำดับความสำคัญของสิ่งต่าง ๆ ตั้งแต่เครื่องมือใหม่ไปจนถึงการปรับปรุงงานซัพพอร์ต

Monitoring and Auto-Remediation

• มี K3 คลัสเตอร์มากกว่า 2500 ชุด
• จำเป็นต้องปรับปรุงกระบวนการมอนิเตอร์เพื่อระบุและกู้คืนปัญหาทั้งหมดของคลัสเตอร์เชิงรุก จึงพัฒนาแนวทางแบบหลายมิติขึ้นมา

Synthetic Client

• สร้าง Synthetic Client ที่รันเป็นคอนเทนเนอร์ภายในคลัสเตอร์ เพื่อทดสอบความสามารถหลักของแพลตฟอร์มและวิเคราะห์ปัญหา (เช่น ปัญหาบริการ, latency ของข้อมูล ฯลฯ)
• หากพบปัญหา client จะรายงานไปยัง Cloud Control Plane ผ่าน API ส่งการแจ้งเตือนไปยังทีมซัพพอร์ต และเริ่มกระบวนการ remediation อัตโนมัติ

Node Hearbeats

• Kubernetes cluster มีความสามารถ self-healing ดังนั้นแม้โหนดจะล้ม workload ก็จะถูกปรับสมดุลใหม่อัตโนมัติระหว่างโหนดที่ยังทำงานอยู่
• เพื่อจับการล้มของโหนด จึง deploy "Heartbeat Pod" แบบง่ายไปยังทุกโหนดในคลัสเตอร์
• Pod นี้จะรายงานสถานะไปยัง API endpoint บนคลาวด์เป็นระยะ

Auto Remediation

• ผ่านการทบทวนงานซัพพอร์ตรายสัปดาห์ ทีมพบ pattern ระหว่างข้อผิดพลาด การตรวจสอบ และขั้นตอนการแก้ไข
• เนื่องจากเครื่องมือซัพพอร์ตทั้งหมดเป็น API-based จึงสามารถสร้าง orchestration flow สำหรับ API เหล่านี้ และทำการแก้ไขอัตโนมัติ (Auto Remediation) สำหรับปัญหาที่เกิดขึ้นบ่อยได้

New Capabilities

• ขณะพัฒนาโครงสร้างพื้นฐานอย่างต่อเนื่อง ทีมพัฒนายังได้สร้างความสามารถใหม่ของแพลตฟอร์มเพื่อเพิ่ม self-service และความง่ายในการซัพพอร์ตต่อไป

Deployment Orchestration

• GitOps model ของเรานั้นเรียบง่าย
• ตอนแรกเริ่มจากการเปลี่ยนแปลงแบบ manual แต่ไม่นานก็สร้างเครื่องมือชื่อ "Fleet" สำหรับเปลี่ยนแปลงคลัสเตอร์และ deploy ไปยังหลายร้านได้
• เมื่อแพลตฟอร์มเติบโตขึ้น ก็จำเป็นต้องมีวิธี deploy ไปทั้งเครือ และตรวจสอบความสำเร็จหรือความล้มเหลวของ deployment
• ใน iteration ที่สอง จึงพัฒนา Deployment Orchestration API ใหม่
  • พร้อม deploy feedback agent ไปยังแต่ละคลัสเตอร์ เพื่อรายงานข้อมูล deployment และสถานะกลับขึ้นคลาวด์
• สิ่งนี้ทำให้สามารถสร้างรูปแบบการปล่อยรีลีสทั้งเครือและ canary deployment pattern ที่จัดการได้ด้วยตัวเอง
• การเปลี่ยนแปลงนี้ช่วยให้ทีมปรับ deployment ได้ละเอียดและสังเกตการณ์ได้ดีขึ้น จึงเพิ่มความน่าเชื่อถือของการ deploy

Log Exfiltration

• ในช่วงแรก ทีม DevOps ภายในสามารถเข้าถึง K3s cluster ของร้านโดยตรง เพื่อดึงสถานะแบบเรียลไทม์และค้นหา log ได้
• แม้จะมีความสามารถด้าน Log Exfiltration พื้นฐานอยู่แล้ว แต่ใช้งานยากมากเพราะปัญหา latency และเครือข่าย
• เนื่องจากต้องการลดการเข้าถึงคลัสเตอร์จากระยะไกลให้น้อยที่สุด จึงเพิ่ม API endpoint เข้ามา
• ปัจจุบันยังได้เพิ่มความสามารถของ Log Exfiltration ที่แข็งแกร่งยิ่งขึ้น
• ใช้โอเพ่นซอร์สชื่อ Vector เพื่อรวบรวมและส่งต่อ log จากเอดจ์คลัสเตอร์ไปยังคลาวด์
  • มีความสามารถในการกรอง การจัดเก็บและส่งต่อ และการหมุนเวียน log อัตโนมัติ
  • จากนั้นตั้งค่า Vector service อีกชุดที่ฝั่งคลาวด์เพื่อรวบรวม log จากทุกเอดจ์ ใช้กฎต่าง ๆ และส่งต่อไปยังหลายเครื่องมือ (Data Dog, Grafana, CloudWatch ฯลฯ)

Metrics and Dashboards

• เพิ่มความสามารถในการใช้ Prometheus Remote Write เพื่อรวบรวม metrics จากทุกร้าน แล้วส่งไปยัง Grafana ส่วนกลางบนคลาวด์
• แต่ละ K3s cluster จะเก็บข้อมูลสถานะของ workload ของโหนดและบริการหลัก
• ยังเพิ่มความสามารถในการ publish business metrics แบบกำหนดเองได้ด้วย

บทสรุป

• "Restaurant Compute Platform" และกระบวนการซัพพอร์ตของเรามีความพร้อมมากพอแล้วที่จะทำให้ทีมพัฒนาขนาดเล็กสามารถส่งมอบความเสถียรและการซัพพอร์ตลูกค้าในระดับสูงได้

สิ่งที่ได้เรียนรู้

• การที่ทีมขนาดเล็กจะสร้างแพลตฟอร์ม Edge Compute ระดับ MVP ที่มีความสำคัญต่อธุรกิจได้นั้น ต้องอาศัยทั้งวิศวกรรมที่ยอดเยี่ยมและการประนีประนอมอย่างชาญฉลาด
• การดูแล Kubernetes cluster มากกว่า 2500 ชุดด้วยทีมเล็กเป็นงานที่หนักมาก แต่แนวทาง automation แบบ API-first ช่วยได้มาก
• เมื่อมาจากโลกแบบ cloud-first ความท้าทายที่ใหญ่ที่สุดคือ Edge มีข้อจำกัดอยู่จริง (กำลังประมวลผล, แบนด์วิดท์เครือข่ายที่จำกัด, การเข้าถึงจากระยะไกล)
• ควรใช้เวลาอย่างมากเพื่อทำความเข้าใจข้อจำกัดเหล่านี้ และพิจารณาว่าควรกำจัดข้อจำกัดนั้นออกไป (ซึ่งใช้เวลาและต้นทุนสูง) หรือควรบริหารจัดการมันแทน

[ddwax89]

สุดยอดมากเลย ฮ่าๆ

[ragingwind]

สร้างขึ้นมาตั้งแต่ระดับล่างสุดจริง ๆ นะครับ และยังให้แรงบันดาลใจอย่างมากในกระบวนการนำไปใช้อีกด้วย

[nicewook]

1. เป็นกรณีศึกษาที่เจ๋งและน่าตื่นเต้นมากเลยครับ/ค่ะ ผม/ฉันเองก็อยากลองสร้างอะไรแบบนี้ดูเหมือนกัน
2. กลายเป็นว่าหัวข้อนี้เริ่มมาตั้งแต่ปี 2018 ก็เลยค่อยโล่งใจขึ้นมาหน่อยใช่ไหมครับ/คะ? ไม่ได้เป็นสิ่งที่ทำเสร็จแบบฉับพลันในชั่วข้ามคืนสินะ
   ไว้คราวหน้าคงต้องหาเวลาอ่านทบทวนอย่างละเอียดอีกสักรอบครับ/ค่ะ

[kbumsik]

แซนด์วิชไก่ของ Chick-fil-A อร่อยมากเลย ฮ่าๆ

จริง ๆ แล้วในปี 2018 ก็เคยมีโพสต์ในหัวข้อเดียวกันนี้ขึ้นมาแล้ว ตอนนั้นยังให้ความรู้สึกค่อนข้างเป็นการทดลองอยู่เลย แต่ดูเหมือนว่าพวกเขาจะรักษามันไว้ได้จนถึงตอนนี้นะครับ ในบทความนี้ก็เห็นได้ชัดว่ามีการสั่งสมความรู้และประสบการณ์ตลอดช่วงเวลาที่ผ่านมา

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

[xguru]

แม้จะยังไม่มีสาขาเข้ามาในเกาหลีใต้จนแทบไม่มีการรับรู้แบรนด์ในประเทศ แต่ก็เป็นร้านอาหารยอดนิยมในหมู่วัยรุ่น โดยครองอันดับ 1 ร้านอาหารที่วัยรุ่นอเมริกันชื่นชอบอยู่เสมอในการสำรวจความนิยมต่อแบรนด์ของบริษัทในหมู่วัยรุ่นอเมริกันที่ Piper Sandler เผยแพร่ปีละสองครั้ง