ภาพรวมและข้อมูลเชิงลึกเกี่ยวกับโครงสร้างพื้นฐาน Hyperscale ของ Meta

(cacm.acm.org)

22 คะแนน โดย GN⁺ 2025-02-12 | 3 ความคิดเห็น | แชร์ทาง WhatsApp

วัฒนธรรมวิศวกรรมของ Meta เน้นการลงมือทำอย่างรวดเร็ว การเปิดกว้างทางเทคโนโลยี การทำวิจัยในสภาพแวดล้อมโปรดักชัน และโครงสร้างพื้นฐานที่ใช้ร่วมกัน
เพื่อนำไปสู่การเพิ่มผลิตภาพของนักพัฒนา บริษัทได้นำการปรับใช้แบบต่อเนื่องมาใช้ และเปิดทางให้นักพัฒนาจำนวนมากขึ้นเขียนฟังก์ชันเซิร์ฟเวอร์เลสแทนโค้ดบริการแบบดั้งเดิม
เพื่อลดต้นทุนฮาร์ดแวร์ บริษัทใช้การออกแบบฮาร์ดแวร์-ซอฟต์แวร์ร่วมกันในระดับดาต้าเซ็นเตอร์ และปรับทรัพยากรให้เหมาะสมแบบอัตโนมัติข้ามดาต้าเซ็นเตอร์ทั่วโลก แทนการจำกัดไว้ที่แต่ละคลัสเตอร์
กลยุทธ์ AI ของ Meta คือการออกแบบร่วมกันทั้งสแตก ตั้งแต่ PyTorch ไปจนถึง AI accelerator เครือข่าย และโมเดล ML อย่าง Llama

# [วัฒนธรรมวิศวกรรม]

ลงมือทำอย่างรวดเร็ว (Move Fast)

Meta ยังคงรักษาวัฒนธรรม "ลงมือทำอย่างรวดเร็ว" ที่เน้น ความคล่องตัวและการทำซ้ำอย่างรวดเร็ว
สนับสนุนอย่างมากต่อ การปรับใช้แบบต่อเนื่อง (Continuous Deployment) เพื่อปล่อยโค้ดล่าสุดขึ้นโปรดักชันให้เร็วที่สุดเท่าที่ทำได้
วิศวกรผลิตภัณฑ์เขียน ฟังก์ชันเซิร์ฟเวอร์เลสแบบ stateless โดยใช้ภาษาอย่าง PHP, Python, Erlang
สามารถเปลี่ยนลำดับความสำคัญได้โดยไม่ต้องผ่านกระบวนการวางแผนที่ยาวนาน และแก้ปัญหาที่ไม่แน่นอนได้ผ่านการลงมือทำแบบวนซ้ำ
แนวทางนี้ทำให้ ตอบสนองต่อตลาดได้รวดเร็ว และเปิดตัวผลิตภัณฑ์ได้อย่างฉับไว

การเปิดกว้างทางเทคโนโลยี (Technology Openness)

ความเปิดกว้างภายใน: ใช้แนวทาง Monorepo โดยเก็บโค้ดของทุกโปรเจกต์ไว้ในรีโพซิทอรีเดียว
- ค้นหาโค้ด นำกลับมาใช้ซ้ำ และทำงานร่วมกันระหว่างทีมได้ง่าย
- ในโปรเจกต์ส่วนใหญ่ ไม่มีข้อจำกัดด้านความเป็นเจ้าของโค้ดที่เข้มงวด ทำให้นักพัฒนาสามารถมีส่วนร่วมได้อย่างอิสระ
ความเปิดกว้างภายนอก: แบ่งปันโปรเจกต์ ฮาร์ดแวร์และซอฟต์แวร์โอเพนซอร์ส อย่างแข็งขัน
- เปิดเผยดีไซน์ฮาร์ดแวร์ผ่าน Open Compute Project
- ดูแลโปรเจกต์ซอฟต์แวร์โอเพนซอร์สหลากหลาย เช่น PyTorch, Llama, Presto, RocksDB, Cassandra
- แบ่งปันเทคโนโลยีโครงสร้างพื้นฐานผ่าน งานวิจัยตีพิมพ์

การทำวิจัยในโปรดักชัน (Research in Production)

Meta ทำวิจัยในสภาพแวดล้อมการปฏิบัติการจริง โดยไม่มีห้องปฏิบัติการวิจัยระบบเฉพาะทาง
ทีมที่พัฒนาระบบโปรดักชันเป็นผู้เขียนงานวิจัยด้วยตนเอง เพื่อ แก้ปัญหาจริงและนำเสนอโซลูชันที่ผ่านการพิสูจน์ในสภาพแวดล้อมการปฏิบัติการขนาดใหญ่
แนวทางนี้มี ความเป็นภาคปฏิบัติ และ ตอบโจทย์เกณฑ์สำคัญของงานวิจัยระบบที่ประสบความสำเร็จ

โครงสร้างพื้นฐานร่วม (Common Infrastructure)

แทนที่จะให้แต่ละทีม เลือกเทคโนโลยีสแตกได้อย่างอิสระ Meta ให้ความสำคัญกับ มาตรฐานร่วมและการปรับให้เหมาะสมในระดับโลก
ฮาร์ดแวร์:
- เซิร์ฟเวอร์ทั้งหมดถูกจัดสรรมาจาก พูลเซิร์ฟเวอร์ส่วนกลาง
- สำหรับ เวิร์กโหลดประมวลผลที่ไม่ใช่ AI บริษัทมีเซิร์ฟเวอร์เพียงประเภทเดียว (โดยพื้นฐานคือ 1 CPU, 256GB DRAM) เพื่อลดความซับซ้อนของประเภทเซิร์ฟเวอร์
ซอฟต์แวร์:
- เดิมใช้คีย์-แวลูสโตร์หลายแบบ เช่น Cassandra, HBase, ZippyDB แต่ปัจจุบัน รวมศูนย์เป็น ZippyDB
- การปรับใช้ซอฟต์แวร์ การจัดการคอนฟิก service mesh การทดสอบประสิทธิภาพ ฯลฯ ถูก รวมเข้ากับเครื่องมือส่วนกลาง
นิยมใช้คอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้:
- สร้าง ห่วงโซ่การนำคอมโพเนนต์กลับมาใช้ซ้ำ ที่ประกอบด้วย Tectonic file system → ZippyDB (จัดเก็บเมทาดาทา) → Shard Manager (จัดการ data sharding) → ServiceRouter (ค้นหา shard และกำหนดเส้นทางคำขอ) → Delos (ระบบจัดเก็บข้อมูลความเชื่อถือสูง)
- ใช้ คอมโพเนนต์แบบโมดูลาร์ที่นำกลับมาใช้ซ้ำได้ แทน ระบบแบบ monolithic อย่าง HDFS เพื่อเพิ่มความสามารถในการขยายสูงสุด

กรณีศึกษาทางวัฒนธรรม: การพัฒนาแอป Threads (Culture Case Study: The Threads App)

กรณีการพัฒนาแอป Threads แสดงให้เห็นวัฒนธรรมวิศวกรรมของ Meta ได้อย่างชัดเจน
ทำงานด้านเทคนิคเสร็จภายในเวลาเพียง 5 เดือน และหลังจาก แจ้งล่วงหน้า 2 วัน ทีมโครงสร้างพื้นฐานก็เตรียมพร้อมสำหรับการปรับใช้ในโปรดักชันเสร็จสิ้น
ในบริษัทขนาดใหญ่ส่วนมาก แค่เขียนเอกสารแผนโครงการภายในสองวันก็ยังยาก แต่ Meta สร้าง war room เพื่อแก้ปัญหาแบบเรียลไทม์และตอบสนองอย่างรวดเร็ว
ผลลัพธ์คือ ทะลุผู้ใช้ 100 ล้านคนภายใน 5 วันหลังเปิดตัว กลายเป็นแอปที่เติบโตเร็วที่สุดในประวัติศาสตร์
Threads สามารถขยายตัวได้อย่างรวดเร็วด้วยการนำโครงสร้างพื้นฐานเดิมมาใช้ซ้ำ:
- Python backend ของ Instagram
- โครงสร้างพื้นฐานร่วมของ Meta (ฐานข้อมูล social graph, คีย์-แวลูสโตร์, แพลตฟอร์มเซิร์ฟเวอร์เลส, แพลตฟอร์ม ML, การจัดการคอนฟิกแอปมือถือ ฯลฯ)
ความเปิดกว้างภายใน: ใช้ monorepo เพื่อนำบางส่วนของโค้ด Instagram มาใช้ซ้ำและเร่งความเร็วการพัฒนา
ความเปิดกว้างภายนอก: ตั้งเป้าความสามารถในการทำงานร่วมกับแอปอื่นผ่าน ActivityPub
การแบ่งปันประสบการณ์การพัฒนา: เปิดเผยประสบการณ์การพัฒนาและการปรับใช้อย่างรวดเร็วต่อสาธารณะ

# [โฟลว์คำขอของผู้ใช้แบบ end-to-end (End-to-End User Request Flow)]

เพื่อดูเทคโนโลยีโครงสร้างพื้นฐานของ Meta ในเชิงลึก จึงอธิบาย กระบวนการทั้งหมดที่คำขอของผู้ใช้ถูกประมวลผล
ผลิตภัณฑ์ของ Meta ได้รับการรองรับโดย โครงสร้างพื้นฐานบริการที่ใช้ร่วมกัน ซึ่งรวมถึงคอมโพเนนต์หลักหลากหลายส่วน

การกำหนดเส้นทางคำขอ (Request Routing)

การแมป DNS แบบไดนามิก (Dynamic DNS Mapping)
- เมื่อผู้ใช้เข้าถึง facebook.com เซิร์ฟเวอร์ DNS ของ Meta จะส่งคืนที่อยู่ IP ของ PoP (Point of Presence) ที่ใกล้ที่สุด แบบไดนามิก
- PoP คือเอดจ์ดาต้าเซ็นเตอร์ขนาดเล็ก ที่ช่วยกระจายโหลดเครือข่ายจากตำแหน่งที่ใกล้ผู้ใช้
- PoP รักษา การเชื่อมต่อ TCP ระยะยาวกับดาต้าเซ็นเตอร์ของ Meta เพื่อลดเวลาในการตั้งค่าการเชื่อมต่อ TCP และเพิ่มประสิทธิภาพเครือข่าย
- มี PoP หลายร้อยแห่งกระจายอยู่ทั่วโลก จึงมอบ เวลาแฝงเครือข่ายที่สั้น ให้กับผู้ใช้ส่วนใหญ่ได้
การแคชคอนเทนต์แบบสแตติก (Static-Content Caching)
- คอนเทนต์แบบสแตติก เช่น รูปภาพและวิดีโอ สามารถแคชไว้ที่ PoP และให้บริการได้โดยตรง
- นอกจากนี้ Meta ยังดำเนินการ CDN (Content Delivery Network) และร่วมมือกับ ISP (ผู้ให้บริการอินเทอร์เน็ต) เพื่อสร้างไซต์ CDN
- หากคำขอของผู้ใช้คือ facebook.com/image.jpg Meta จะเขียนใหม่เป็น CDN109.meta.com/image.jpg เพื่อให้คอนเทนต์จากไซต์ CDN ที่อยู่ใกล้
- หาก CDN ไม่มีคอนเทนต์ดังกล่าว คำขอจะถูกส่งต่อไปยัง PoP → load balancer ของดาต้าเซ็นเตอร์ → ระบบจัดเก็บข้อมูล
การกำหนดเส้นทางคำขอคอนเทนต์แบบไดนามิก (Dynamic-Content Request Routing)
- คำขอคอนเทนต์แบบไดนามิก เช่น News Feed จะถูก ส่งต่อจาก PoP ไปยังดาต้าเซ็นเตอร์
- เครื่องมือวิศวกรรมทราฟฟิก จะเลือกดาต้าเซ็นเตอร์ที่เหมาะสมที่สุดโดยพิจารณาจากความจุของดาต้าเซ็นเตอร์และเวลาแฝงของเครือข่าย
- ทราฟฟิกจาก PoP ไปยังดาต้าเซ็นเตอร์จะถูกส่งผ่าน WAN ส่วนตัว (private WAN) ของ Meta
- ทราฟฟิกระหว่างดาต้าเซ็นเตอร์ มีมากกว่าทราฟฟิกระหว่างผู้ใช้กับ PoP อย่างมาก เนื่องจากการทำสำเนาข้อมูลและการโต้ตอบระหว่างไมโครเซอร์วิส

โทโพโลยีของโครงสร้างพื้นฐาน (Infrastructure Topology)

โครงสร้างพื้นฐานระดับโลกของ Meta ประกอบด้วย องค์ประกอบโครงสร้างพื้นฐานหลายชั้น
องค์ประกอบแต่ละส่วนทำหน้าที่เฉพาะ และดำเนินงานในขนาดดังนี้:
- ภูมิภาคดาต้าเซ็นเตอร์ (Region): มีภูมิภาคดาต้าเซ็นเตอร์ทั่วโลก ราว 10 แห่ง และแต่ละภูมิภาคสามารถรองรับเซิร์ฟเวอร์ได้สูงสุด 1 ล้านเครื่อง
- PoP (Point of Presence, ดาต้าเซ็นเตอร์ฝั่งเอดจ์): มี PoP มากกว่า 100 แห่ง โดยแต่ละ PoP โดยทั่วไปมี เซิร์ฟเวอร์ 100~1,000 เครื่อง ทำหน้าที่ประมวลผลทราฟฟิกใกล้กับผู้ใช้เพื่อลดเวลาแฝง
- ไซต์ CDN: มี ไซต์ CDN มากกว่า 1,000 แห่ง โดยทั่วไปมี เซิร์ฟเวอร์มากกว่า 10 เครื่อง และบางไซต์ขนาดใหญ่มี เซิร์ฟเวอร์มากกว่า 100 เครื่อง ทำหน้าที่แคชคอนเทนต์แบบคงที่ (เช่น รูปภาพ วิดีโอ ฯลฯ) เพื่อให้ส่งมอบได้รวดเร็ว
- ดาต้าเซ็นเตอร์ (Datacenter): ในแต่ละภูมิภาคดาต้าเซ็นเตอร์มี ดาต้าเซ็นเตอร์หลายแห่ง และ แต่ละดาต้าเซ็นเตอร์สามารถรองรับเซิร์ฟเวอร์ได้มากกว่า 100,000 เครื่อง
- MSB (เมนสวิตช์บอร์ด, Main Switchboard): ภายในดาต้าเซ็นเตอร์มี MSB ได้สูงสุด 12 ชุด และ แต่ละ MSB รับผิดชอบเซิร์ฟเวอร์ 10,000~20,000 เครื่อง ทำหน้าที่กระจายพลังงานไฟฟ้า และเป็นโดเมนความขัดข้องหลักภายในดาต้าเซ็นเตอร์ หาก MSB ขัดข้อง เซิร์ฟเวอร์ได้สูงสุด 20,000 เครื่องอาจดับลง
เครือข่ายเอดจ์:
- PoP เชื่อมต่อกับระบบอัตโนมัติบนอินเทอร์เน็ต (AS) หลายแห่ง และใช้ BGP (Border Gateway Protocol) เพื่อเลือกเส้นทางที่เหมาะสมที่สุด
เครือข่ายดาต้าเซ็นเตอร์:
- เซิร์ฟเวอร์เชื่อมต่อกันด้วย โทโพโลยี Clos แบบ 3 ชั้น
- ออกแบบมาเพื่อป้องกันความแออัดของเครือข่าย และมอบ แบนด์วิดท์สูงสุดระหว่างเซิร์ฟเวอร์
เครือข่ายระดับภูมิภาค:
- ดาต้าเซ็นเตอร์เชื่อมต่อกันผ่าน fabric aggregator เพื่อให้สื่อสารกับ WAN ได้
- ใช้ โทโพโลยี Fat-Tree เพื่อให้ขยายระบบได้แบบค่อยเป็นค่อยไป

การประมวลผลคำขอ (Request Processing)

การประมวลผลออนไลน์ (Online Processing)
- คำขอของผู้ใช้จะถูกกระจายผ่าน load balancer ไปยัง ฟังก์ชันฟรอนต์เอนด์แบบ serverless (FrontFaaS) หลายหมื่นตัว
- ฟังก์ชันฟรอนต์เอนด์สามารถเรียกใช้ บริการแบ็กเอนด์ หลายตัว และอาจเรียกใช้ บริการ ML inference (เช่น การแนะนำโฆษณา การแนะนำคอนเทนต์ในนิวส์ฟีด) ได้ด้วย
- ระหว่างการทำงาน ฟังก์ชันฟรอนต์เอนด์จะเพิ่มอีเวนต์ลงใน event queue เพื่อให้ ฟังก์ชัน serverless แบบอิงเหตุการณ์ (XFaaS) ทำงานแบบอะซิงโครนัส
- อัตราส่วนเซิร์ฟเวอร์ของฟังก์ชันฟรอนต์เอนด์ต่อฟังก์ชันแบบอิงเหตุการณ์อยู่ที่ประมาณ 5:1
การประมวลผลออฟไลน์ (Offline Processing)
- ระบบประมวลผลออฟไลน์ทำหน้าที่ สนับสนุนระบบออนไลน์ และดำเนินการวิเคราะห์ข้อมูลกับการฝึกแมชชีนเลิร์นนิง
- ฟังก์ชันฟรอนต์เอนด์และบริการแบ็กเอนด์จะจัดเก็บข้อมูลล็อกหลากหลายประเภทไว้ใน data warehouse
  - การฝึก ML: ใช้ข้อมูลล็อกเพื่ออัปเดตโมเดลแมชชีนเลิร์นนิง
  - stream processing: อัปเดตหัวข้อที่ถูกพูดถึงมากที่สุดในเว็บไซต์แล้วบันทึกลงฐานข้อมูลและแคช
  - batch analytics: ใช้ Spark และ Presto เพื่ออัปเดตระบบแนะนำเพื่อน
  - การรันฟังก์ชัน serverless แบบอิงเหตุการณ์: การอัปเดตข้อมูลทำหน้าที่เป็น event trigger เพื่อรันฟังก์ชัน serverless โดยอัตโนมัติ

# [การเพิ่มประสิทธิภาพการทำงานของนักพัฒนา (Boosting Developer Productivity)]

โครงสร้างพื้นฐานแบบใช้ร่วมกันของ Meta มีเป้าหมายเพื่อ เพิ่มประสิทธิภาพการทำงานของนักพัฒนาให้สูงสุด
เพื่อการนี้ Meta จึง ใช้การปรับใช้อย่างต่อเนื่อง (Continuous Deployment) และฟังก์ชัน serverless อย่างเต็มขีดสุด

การปรับใช้อย่างต่อเนื่อง (Continuous Deployment)

Meta ได้รับการปรับให้เหมาะสมเพื่อให้ สามารถ deploy การเปลี่ยนแปลงของโค้ดและคอนฟิกูเรชัน (Configuration) ได้อย่างรวดเร็ว
สามารถ deploy ฟีเจอร์ใหม่และการแก้บั๊กได้ทันที ทำให้รับฟีดแบ็กได้รวดเร็วและปรับปรุงซ้ำได้อย่างต่อเนื่อง
การเปลี่ยนแปลงคอนฟิกูเรชัน (Configuration Changes)
- เครื่องมือจัดการคอนฟิกูเรชัน ของ Meta ทำการ deploy การเปลี่ยนแปลงแบบเรียลไทม์มากกว่า 100,000 รายการเข้าสู่ production ทุกวัน
- มีการอัปเดตคอนฟิกโดยอัตโนมัติใน บริการมากกว่า 10,000 รายการและเซิร์ฟเวอร์หลายล้านเครื่อง
- งานหลากหลาย เช่น load balancing, การ rollout ฟีเจอร์, A/B testing และการป้องกันโอเวอร์โหลด ถูกดำเนินการโดยอัตโนมัติ
- การเปลี่ยนแปลงคอนฟิกจะ ผ่านการรีวิวและ commit ลง code repository เช่นเดียวกับการเปลี่ยนแปลงโค้ด และการเปลี่ยนแปลงจะ กระจายไปทั่วทั้งระบบภายในไม่กี่วินาที
การเปลี่ยนแปลงโค้ด (Code Changes)
- เครื่องมือ deploy ของ Meta ดูแล deployment pipeline มากกว่า 30,000 รายการ เพื่อ จัดการการอัปเดตซอฟต์แวร์
- 97% ของบริการใช้การ deploy แบบอัตโนมัติเต็มรูปแบบ ทำให้อัปเดตได้โดยไม่ต้องมีการแทรกแซงด้วยมือ:
  - 55% ใช้ การปรับใช้อย่างต่อเนื่องเต็มรูปแบบ (CD) ทำให้การเปลี่ยนแปลงโค้ดถูกนำขึ้น production โดยอัตโนมัติ
  - 42% ถูก deploy อัตโนมัติตามตารางเวลาคงที่ (รายวันหรือรายสัปดาห์)
- ฟังก์ชัน serverless ฝั่งฟรอนต์เอนด์ (FrontFaaS) ทำงานอยู่บนเซิร์ฟเวอร์มากกว่า 500,000 เครื่อง และนักพัฒนามากกว่า 10,000 คนทำ code commit หลายพันครั้งต่อวัน
- แม้อยู่ในสภาพแวดล้อมที่มีความเปลี่ยนแปลงสูงเช่นนี้ ฟังก์ชัน serverless ทั้งหมดก็ยังมีเวอร์ชันใหม่ถูก deploy ขึ้น production ทุก 3 ชั่วโมง
การอัปเดตซอฟต์แวร์เครือข่ายและโครงสร้างพื้นฐาน
- Private WAN ของ Meta รักษา network plane แบบขนานหลายชุดไว้ ทำให้ สามารถทดสอบอัลกอริทึมเครือข่ายใหม่ได้อย่างอิสระ
- ซอฟต์แวร์ของ network switch ก็ได้รับการอัปเดตบ่อยครั้งเช่นกัน และใช้ฟีเจอร์ "Warm Boot" ของสวิตช์ เพื่อ อัปเดตซอฟต์แวร์ได้โดยไม่ต้องหยุดทราฟฟิกเครือข่าย
- เนื่องจาก โค้ดที่อัปเดตบ่อยและการเปลี่ยนแปลงคอนฟิกเพิ่มความเสี่ยงของการหยุดชะงักระดับไซต์ Meta จึงลงทุนอย่างมากในด้านการทดสอบ การ deploy แบบค่อยเป็นค่อยไป และ health check
  - มีการรณรงค์ภายในองค์กรเพื่อเพิ่มระบบอัตโนมัติของการ deploy โค้ดจาก 12% เป็น 97%
  - ทำ การทดสอบ Canary แบบอัตโนมัติ สำหรับการเปลี่ยนแปลงคอนฟิกทั้งหมดเพื่อรับประกันความเสถียร

ฟังก์ชัน Serverless (Serverless Functions)

ฟังก์ชัน Serverless (หรือ FaaS, Function-as-a-Service) เป็นอีกหนึ่งองค์ประกอบสำคัญที่ช่วยเพิ่มผลิตภาพของนักพัฒนา
ต่างจากบริการแบ็กเอนด์แบบดั้งเดิม ฟังก์ชัน Serverless จะไม่เก็บสถานะและใช้งานผ่านอินเทอร์เฟซของฟังก์ชันแบบเรียบง่าย
การเรียกใช้ฟังก์ชันแต่ละครั้งจะทำงานอย่างอิสระ และจัดการสถานะผ่านฐานข้อมูลภายนอกหรือระบบแคช
ข้อดีของฟังก์ชัน Serverless
- นักพัฒนาเพียงแค่ เขียนตรรกะของผลิตภัณฑ์โดยไม่ต้องจัดการโครงสร้างพื้นฐาน
- มีการ ดีพลอยโค้ดและปรับขยายอัตโนมัติตามการเปลี่ยนแปลงของโหลด (Auto-Scaling) โดยอัตโนมัติ
- ป้องกันการสิ้นเปลืองฮาร์ดแวร์ และไม่จำเป็นให้นักพัฒนาจัดสรรทรัพยากรเกินความจำเป็น
แพลตฟอร์ม Serverless ของ Meta
- ในบรรดา นักพัฒนามากกว่า 10,000 คนของ Meta จำนวนนักพัฒนาที่เขียนฟังก์ชัน Serverless มีมากกว่านักพัฒนาที่เขียนโค้ดบริการแบบดั้งเดิมอยู่ 50%
- IDE สำหรับการพัฒนา Serverless ของ Meta รองรับการเข้าถึงฐานข้อมูลโซเชียลกราฟและระบบแบ็กเอนด์หลากหลายแบบได้อย่างง่ายดาย และ มีการทดสอบการรวมต่อเนื่อง (CI) เพื่อให้รับฟีดแบ็กได้อย่างรวดเร็ว
แพลตฟอร์ม Serverless ของ Meta: FrontFaaS และ XFaaS
- FrontFaaS: ฟังก์ชัน Serverless ฝั่งฟรอนต์เอนด์ที่พัฒนาด้วย PHP ทำงานอยู่บนเซิร์ฟเวอร์มากกว่า 500,000 เครื่อง
  - คงรันไทม์ PHP ไว้ตลอดเวลา จึง รองรับคำขอได้ทันทีโดยไม่มีปัญหา cold start
  - เมื่อโหลดของเซิร์ฟเวอร์ตํ่า จะใช้ การปรับขยายอัตโนมัติ เพื่อปลดบางเซิร์ฟเวอร์ออกและนำไปใช้งานอื่น
- XFaaS: ฟังก์ชัน Serverless แบบ event-driven ที่ทำงานแบบอะซิงโครนัส
  - ใช้สำหรับ จัดการงานเบื้องหลัง ที่ไม่จำเป็นต้องตอบสนองทันที
  - เพื่อหลีกเลี่ยงงานที่มีโหลดสูง ระบบจะหน่วงเวลาการทำงาน ใช้ global load balancing และใช้ quota-based throttling
นวัตกรรม Serverless ของ Meta
- ใช้แนวทาง Serverless เป็นกระบวนทัศน์การพัฒนาหลักมาตั้งแต่ช่วงปลายทศวรรษ 2000
- ความแตกต่างจากแพลตฟอร์ม Serverless บน public cloud:
  - public cloud ใช้ virtual machine หนึ่งเครื่องต่อหนึ่งฟังก์ชันเพื่อการแยกส่วนที่เข้มงวด
  - ขณะที่ Meta ออกแบบให้หลายฟังก์ชันสามารถรันพร้อมกันได้ภายใน Linux process เดียว เพื่อเพิ่มประสิทธิภาพการใช้ฮาร์ดแวร์ให้สูงสุด

# [การลดต้นทุนฮาร์ดแวร์ (Reducing Hardware Costs)]

โครงสร้างพื้นฐานแบบใช้ร่วมกันของ Meta ไม่ได้มีบทบาทสำคัญแค่ในการเพิ่มผลิตภาพของนักพัฒนาเท่านั้น แต่ยังช่วย ลดต้นทุนฮาร์ดแวร์ ด้วย
เพื่อให้ทำเช่นนั้นได้ Meta ใช้ กลยุทธ์เพิ่มประสิทธิภาพการใช้ฮาร์ดแวร์ให้สูงสุดผ่านการปรับซอฟต์แวร์ให้เหมาะสม

การดำเนินงานดาต้าเซ็นเตอร์ทั่วโลกเสมือนเป็นคอมพิวเตอร์เครื่องเดียว (All Global Datacenters as a Computer)

ในสภาพแวดล้อมคลาวด์แบบเดิม ผู้ใช้ต้องกำหนดจำนวน replica ของบริการ ภูมิภาคที่ดีพลอย และรายละเอียดอื่น ๆ ด้วยตนเอง
วิธีการจัดการแบบแมนนวลเช่นนี้ก่อให้เกิดปัญหาอย่าง การสิ้นเปลืองทรัพยากร โหลดไม่สมดุล และการย้ายงานระหว่างดาต้าเซ็นเตอร์ที่ไม่เพียงพอ
Meta พัฒนาจากแนวทางเดิมอย่าง "ดาต้าเซ็นเตอร์เป็นคอมพิวเตอร์เครื่องหนึ่ง" (DaaC, Datacenter as a Computer) ไปสู่การทำ Global-DaaC ที่ "ทำให้ดาต้าเซ็นเตอร์ทั่วโลกทำงานเสมือนเป็นคอมพิวเตอร์เครื่องเดียว"
คุณลักษณะหลักของ Global-DaaC:
- ผู้ใช้เพียงแค่ส่งคำขอสำหรับการดีพลอยระดับโลก จากนั้นโครงสร้างพื้นฐานจะ ตัดสินใจจำนวน replica ที่เหมาะสม พื้นที่ดีพลอย ประเภทฮาร์ดแวร์ และการกำหนดเส้นทางทราฟฟิกโดยอัตโนมัติ
- สามารถเปลี่ยนตำแหน่งของบริการตามความจำเป็น และ ปรับตัวตามการเปลี่ยนแปลงของอุปทานและโหลดได้
- ต่างจาก public cloud ตรงที่ Meta รันแอปพลิเคชันทั้งหมดด้วยตนเอง จึง ย้ายเวิร์กโหลดได้ยืดหยุ่นกว่า
วิธีการนำ Global-DaaC ไปใช้
- ทำให้การจัดสรรทรัพยากรเป็นอัตโนมัติในระดับโลก ระดับภูมิภาค และระดับเซิร์ฟเวอร์รายเครื่อง:
  - เครื่องมือจัดการความจุระดับโลก: ใช้ RPC tracing วิเคราะห์การพึ่งพาระหว่างบริการ และกำหนดการจัดสรรความจุที่เหมาะสมที่สุดด้วย mixed-integer programming (MIP)
  - เครื่องมือจัดการความจุระดับภูมิภาค: จัดสรรทรัพยากรเซิร์ฟเวอร์รายดาต้าเซ็นเตอร์เพื่อสร้าง virtual cluster
  - เครื่องมือจัดการคอนเทนเนอร์: จัดวางคอนเทนเนอร์ภายใน virtual cluster และ กระจายการวางข้ามหลายดาต้าเซ็นเตอร์เพื่อให้ได้มาซึ่ง fault tolerance
  - เทคนิคการจัดการเคอร์เนล: แชร์และแยกทรัพยากรหน่วยความจำและ I/O ระหว่างคอนเทนเนอร์อย่างเหมาะสม
กรณีการใช้งานของ Global-DaaC
- ฐานข้อมูลและบริการแบบมีสถานะ:
  - แต่ละคอนเทนเนอร์โฮสต์ data shard หลายตัวเพื่อเพิ่มประสิทธิภาพให้สูงสุด
  - Global Service Placer(GSP) จะกำหนดจำนวน replica ของ shard และภูมิภาคสำหรับการจัดวางที่เหมาะสมที่สุด
  - จากนั้นเฟรมเวิร์กการทำ sharding จะ จัดสรร shard ให้กับคอนเทนเนอร์และย้ายแบบไดนามิก ตามข้อมูลดังกล่าว
- เวิร์กโหลดแมชชีนเลิร์นนิง (ML):
  - งาน ML inference จัดการ model replica ในลักษณะเดียวกับ data shard
  - การฝึก ML (training) จำเป็นต้องวางข้อมูลและ GPU ไว้ในดาต้าเซ็นเตอร์เดียวกัน
  - ระบบจะรับการจัดสรรความจุ GPU ระดับโลก และ ตัวจัดตารางการฝึก ML จะทำการจำลองข้อมูลและการจัดวาง GPU ที่เหมาะสมที่สุด

การออกแบบฮาร์ดแวร์-ซอฟต์แวร์ร่วมกัน (Hardware and Software Co-Design)

การนำการออกแบบฮาร์ดแวร์-ซอฟต์แวร์ร่วมกัน (Co-Design) มาใช้ในระดับเซิร์ฟเวอร์เดี่ยวนั้นเป็นเรื่องปกติ แต่ Meta ได้ ขยายแนวทางนี้ไปสู่ระดับโลก และ เอาชนะข้อจำกัดของฮาร์ดแวร์ต้นทุนต่ำด้วยการปรับแต่งซอฟต์แวร์
ความทนทานต่อความขัดข้องต้นทุนต่ำ (Low-Cost Fault Tolerance)
- Public cloud มอบฮาร์ดแวร์ที่มีความพร้อมใช้งานสูง แต่ Meta เลือกใช้ แนวทางแก้ไขความขัดข้องด้วยซอฟต์แวร์ เพื่อให้ สามารถใช้ฮาร์ดแวร์ที่มีต้นทุนต่ำกว่าได้
- ความแตกต่างหลัก:
  - แร็กเซิร์ฟเวอร์ (Rack) ของ public cloud ใช้แหล่งจ่ายไฟคู่และสวิตช์ ToR (Top-of-Rack) แบบคู่ แต่ Meta ใช้ แหล่งจ่ายไฟเดี่ยวและสวิตช์ ToR เดี่ยว
  - เครื่องเสมือน (VM) ของ public cloud ใช้ block storage ที่เชื่อมต่อผ่านเครือข่าย จึงทำ live migration ได้ ขณะที่ คอนเทนเนอร์ของ Meta ใช้ local SSD ต้นทุนต่ำ
- กลยุทธ์รับมือความขัดข้องด้วยซอฟต์แวร์:
  - เครื่องมือจัดสรรทรัพยากร: กระจายคอนเทนเนอร์ของบริการและ data shard ไปยัง fault domain อื่นภายในดาต้าเซ็นเตอร์
  - โปรโตคอลการทำงานร่วมกัน: เปิดให้แอปพลิเคชันเข้ามามีส่วนร่วมในการจัดการ lifecycle ของคอนเทนเนอร์ เพื่อ ป้องกันไม่ให้ replica ของ data shard หยุดพร้อมกัน
  - การรับประกันความทนทานข้ามหลายดาต้าเซ็นเตอร์: ออกแบบให้บริการยังคงทำงานได้แม้ทั้งภูมิภาคจะหยุดทำงาน และมีการทดสอบใช้งานจริงเป็นประจำเพื่อตรวจสอบความน่าเชื่อถือ
การลดต้นทุนของ routing proxy (Eliminating Routing Proxy Costs)
- Service mesh แบบเดิมใช้ sidecar proxy ในการกำหนดเส้นทางคำขอ RPC แต่ Meta จัดการคำขอ RPC 99% ด้วยการกำหนดเส้นทางแบบ client-server โดยตรง
- แนวทางนี้ช่วยประหยัด proxy server ได้ราว 100,000 เครื่อง
- อย่างไรก็ตาม มีความท้าทายที่ต้อง คอมไพล์และแจกจ่ายไลบรารี routing ไปยังบริการมากกว่า 10,000 รายการ แต่ Meta แก้ปัญหานี้ได้ด้วย เครื่องมือ deploy ซอฟต์แวร์และจัดการการตั้งค่า
การใช้ tiered storage และ local SSD (Tiered Storage and Local SSDs)
- แยกประเภทสตอเรจตามความถี่ในการเข้าถึงข้อมูลและข้อกำหนดด้าน latency เพื่อเพิ่มประสิทธิภาพด้านต้นทุนสูงสุด:
  - Hot Data: จัดเก็บในหน่วยความจำและ SSD (เช่น ฐานข้อมูล social graph)
  - Warm Data: จัดเก็บใน distributed file system ที่ใช้ HDD เป็นฐาน (เช่น วิดีโอ รูปภาพ และข้อมูลล็อก)
  - Cold Data: จัดเก็บในเซิร์ฟเวอร์ HDD ความจุสูง (เช่น วิดีโอความละเอียดสูงรุ่นเก่า)
    - คงไว้ในโหมดพลังงานต่ำเพื่อ ลดต้นทุน
- การใช้ local SSD:
  - เวิร์กโหลดบางประเภท ให้ประสิทธิภาพดีกว่า remote storage แบบใช้ร่วมกัน เมื่อใช้ local SSD
  - แต่ก็มี ความเสี่ยงที่การใช้งาน SSD จะต่ำลงจากการกระจายโหลดที่ไม่สมดุล
  - Meta ใช้ common sharding framework เพื่อ แก้ปัญหาความไม่สมดุลและเพิ่มประสิทธิภาพการใช้ SSD สูงสุด

การออกแบบฮาร์ดแวร์ภายในองค์กร (In-House Hardware Design)

Meta ออกแบบดาต้าเซ็นเตอร์ เซิร์ฟเวอร์ สวิตช์เครือข่าย และชิป AI เอง เพื่อประสิทธิภาพด้านต้นทุนและพลังงาน
เนื่องจาก พลังงานเป็นทรัพยากรที่จำกัดที่สุดในดาต้าเซ็นเตอร์ จึงมีการใช้เครื่องมืออัตโนมัติเพื่อปรับการใช้พลังงานให้เหมาะสม
ลดต้นทุนและการใช้พลังงานผ่านการออกแบบฮาร์ดแวร์-ซอฟต์แวร์ร่วมกัน:
- ปรับการใช้ SRAM ของชิป AI ให้เหมาะสม
- ถอดอุปกรณ์ทำความเย็นแบบอัดอากาศออกจากดาต้าเซ็นเตอร์
พัฒนาทั้งสวิตช์เครือข่ายและซอฟต์แวร์เอง ทำให้ อัปเดตได้อย่างสม่ำเสมอ และเผยแพร่ดีไซน์ฮาร์ดแวร์ส่วนใหญ่แบบโอเพนซอร์สผ่าน Open Compute Project

# [การออกแบบระบบที่ขยายได้ (Designing Scalable Systems)]

ในโครงสร้างพื้นฐานแบบ hyperscale การออกแบบระบบที่ขยายได้ เป็นองค์ประกอบสำคัญ
distributed system (BGP, BitTorrent, DHT เป็นต้น) ที่ออกแบบมาสำหรับสภาพแวดล้อมอินเทอร์เน็ตมีความสามารถในการขยายสูง แต่ ในสภาพแวดล้อมดาต้าเซ็นเตอร์ คอนโทรลเลอร์แบบรวมศูนย์อาจให้ทั้ง scalability และประสิทธิภาพที่สูงกว่า

การเลิกใช้คอนโทรลเลอร์แบบกระจายศูนย์ (Deprecating Decentralized Controllers)

Meta เลือกเปลี่ยนจาก คอนโทรลเลอร์แบบกระจายศูนย์เดิมไปเป็นคอนโทรลเลอร์แบบรวมศูนย์
ยกเว้น สวิตช์เครือข่ายที่ยังคงใช้ BGP แต่ถูกออกแบบให้ คอนโทรลเลอร์กลางสามารถรีเซ็ตเส้นทางได้เมื่อเกิดความแออัดของทราฟฟิกหรือ link failure
คอนโทรลเลอร์แบบรวมศูนย์ ให้การกระจายโหลดที่ดีกว่าและตอบสนองต่อความขัดข้องได้เร็วกว่า จึงเหมาะกับสภาพแวดล้อมดาต้าเซ็นเตอร์มากกว่า

ตัวอย่างการเปลี่ยนระบบกระจายศูนย์เดิมให้เป็นแบบรวมศูนย์

Private WAN
- เดิมใช้ RSVP-TE (การตั้งค่าเส้นทางแบบกระจายศูนย์) แต่เปลี่ยนเป็นระบบที่อิงคอนโทรลเลอร์กลาง
- คำนวณเส้นทางทราฟฟิกที่เหมาะสมที่สุดโดยอัตโนมัติ และ กำหนดเส้นทางสำรองล่วงหน้าเมื่อเกิดความขัดข้อง เพื่อให้กู้คืนได้รวดเร็ว
Key-Value Store
- เปลี่ยนจากแนวทางเดิมที่ใช้ multihop routing บน DHT (distributed hash table) ไปเป็น sharding framework ที่ใช้คอนโทรลเลอร์กลาง
- คอนโทรลเลอร์กลาง ปรับการย้าย shard แบบไดนามิกเพื่อเพิ่มสมดุลโหลดให้เหมาะสมที่สุด
การกระจายข้อมูลขนาดใหญ่
- เดิมใช้ BitTorrent (การดาวน์โหลด P2P แบบกระจายศูนย์) แต่เปลี่ยนเป็นระบบกระจายแบบรวมศูนย์ของ Meta ที่ชื่อ Owl
- กำหนดเส้นทางดาวน์โหลดข้อมูลจากศูนย์กลาง จึงให้ความเร็วดาวน์โหลดสูงกว่ามาก
การกระจายเมทาดาทาขนาดเล็ก
- ในช่วงแรกใช้ โครงสร้างต้นไม้แบบกระจาย 3 ชั้น (พัฒนาด้วย Java) แต่เพราะปัญหาด้าน scalability จึงเปลี่ยนเป็นโครงสร้างต้นไม้แบบ P2P
- อย่างไรก็ตาม ประสิทธิภาพที่ไม่เสถียรของบางโหนดกลับลดประสิทธิภาพโดยรวมลง สุดท้ายจึง ย้อนกลับไปใช้สถาปัตยกรรม proxy server แบบรวมศูนย์ประสิทธิภาพสูงที่พัฒนาด้วย C++

กรณีศึกษา: service mesh ที่ขยายได้ (Scalable Service Mesh)

Meta ดำเนินการ service mesh ภายในของตนเองชื่อ ServiceRouter และ
ผ่านระบบนี้จึง พิสูจน์ให้เห็นถึงประสิทธิผลของสถาปัตยกรรมแบบรวมศูนย์ที่ขยายได้

ปัญหาของสถาปัตยกรรม service mesh แบบเดิม
- service mesh ทั่วไปใช้ sidecar proxy L7 ให้แต่ละ service process กำหนดเส้นทางคำขอ RPC
- แต่ ในสภาพแวดล้อม hyperscale การให้คอนโทรลเลอร์กลางจัดการ sidecar proxy หลายล้านตัวโดยตรงนั้นไม่มีประสิทธิภาพ
- Meta จึงเปลี่ยนจากแนวทาง sidecar proxy ไปเป็นโครงสร้างที่ตัวบริการจัดการ routing เอง
สถาปัตยกรรม ServiceRouter ของ Meta
- เมทาดาทา routing ถูกสร้างจากคอนโทรลเลอร์กลาง แต่ L7 router แต่ละตัวจะประกอบตาราง routing ขึ้นเอง
- ใช้ฐานข้อมูลที่อิง Paxos (RIB, Routing Information Base) เพื่อรองรับ scalability
  - ทำ sharding ให้คอนโทรลเลอร์เพื่อกระจายโหลด และเปิดให้หลายคอนโทรลเลอร์คำนวณตาราง routing สำหรับบริการเฉพาะแบบขนานได้
- ชั้น distribution ใช้ RIB replica หลายพันชุด เพื่อรองรับคำขออ่านจาก L7 router หลายล้านตัว
- สุดท้าย L7 router แต่ละตัวสามารถกำหนดค่าได้อย่างอิสระโดยไม่ต้องให้คอนโทรลเลอร์กลางเข้ามาแทรกแซงโดยตรง
วิธีที่ ServiceRouter ทำให้รองรับการขยายตัวได้
1. ใช้คอนโทรลเลอร์แบบ stateless: คอนโทรลเลอร์ไม่จัดการ router ใดโดยตรง แต่เพียงเก็บรักษาข้อมูล routing ระดับ global
2. ทำ sharding ให้คอนโทรลเลอร์: คอนโทรลเลอร์หลายตัวทำงานแยกจากกันและประมวลผลข้อมูล routing ของบริการต่างกันแบบขนานได้
3. ตัดฟีเจอร์ที่ไม่จำเป็นออก: ตัดความสามารถในการจัดการ L7 router รายตัวออกจากคอนโทรลเลอร์ และออกแบบให้ router แต่ละตัวดูแลตัวเอง
ผลลัพธ์และบทเรียน
- สถาปัตยกรรมที่ผสานคอนโทรลเลอร์แบบรวมศูนย์เข้ากับ data plane แบบกระจายศูนย์ ให้ scalability ที่ดีที่สุด
- เพิ่มประสิทธิภาพด้านต้นทุนการดำเนินงานและประสิทธิภาพระบบ ด้วยการตัด sidecar proxy ที่ไม่จำเป็นออก
- ด้วยการทำ sharding อย่างมีกลยุทธ์และการออกแบบแบบ stateless ทำให้สามารถจัดการ service routing หลายล้านรายการได้อย่างมีประสิทธิภาพ

# [แนวโน้มในอนาคต (Future Directions)]

โครงสร้างพื้นฐาน hyperscale ของ Meta มีความซับซ้อนมาก แต่เอกสารนี้ได้ สรุปอินไซต์ทางเทคนิคที่สำคัญ ไว้ให้
สุดท้ายนี้ จะแชร์มุมมองเกี่ยวกับ เทรนด์ในอนาคตของโครงสร้างพื้นฐาน hyperscale

AI (ปัญญาประดิษฐ์)

เวิร์กโหลด AI ได้กลายเป็น เวิร์กโหลดที่มีสัดส่วนมากที่สุดในดาต้าเซ็นเตอร์ ไปแล้วในปัจจุบัน
คาดว่าก่อนปี 2030 มากกว่าครึ่งของการใช้พลังงานในดาต้าเซ็นเตอร์จะถูกใช้กับเวิร์กโหลด AI
AI มีแนวโน้มสูงที่จะเปลี่ยนโครงสร้างพื้นฐานแบบเดิมอย่างรากฐาน เนื่องจาก ต้องการเครือข่ายประสิทธิภาพสูงและใช้ทรัพยากรสูง
ในอดีต โครงสร้างพื้นฐาน hyperscale พัฒนามาด้วยแนวทาง scale-out (การติดตั้งเซิร์ฟเวอร์ต้นทุนต่ำจำนวนมาก) แต่
คลัสเตอร์ AI ในอนาคตมีแนวโน้มจะเปลี่ยนไปสู่แนวทาง scale-up (สถาปัตยกรรมแบบซูเปอร์คอมพิวเตอร์)
- ตัวอย่าง: ใช้ เครือข่ายอีเธอร์เน็ตที่ใช้ RDMA (Remote Direct Memory Access) เพื่อเพิ่มประสิทธิภาพสำหรับ การฝึกแมชชีนเลิร์นนิง (ML) ขนาดใหญ่
Meta กำลังดำเนินการ co-design แบบ full-stack ที่ครอบคลุมตั้งแต่ PyTorch → โมเดล ML → ชิป AI → เครือข่าย → ดาต้าเซ็นเตอร์ → เซิร์ฟเวอร์ → สตอเรจ → พลังงานและระบบระบายความร้อน

ฮาร์ดแวร์เฉพาะโดเมน (Domain-Specific Hardware)

ในช่วงทศวรรษ 2000 ฮาร์ดแวร์มีความเป็นมาตรฐานมากขึ้นเรื่อย ๆ แต่
ต่อจากนี้คาดว่าจะมีฮาร์ดแวร์เฉพาะทางเพิ่มขึ้นหลากหลายประเภท เช่น AI training/inference, virtualization, video encoding, encryption, compression และ hierarchical memory
บริษัท hyperscale สามารถออกแบบและกระจายฮาร์ดแวร์แบบปรับแต่งเฉพาะได้อย่างคุ้มค่าทางเศรษฐกิจผ่านการผลิตในปริมาณมาก
อย่างไรก็ตาม ความหลากหลายของฮาร์ดแวร์ที่เพิ่มขึ้นนี้จะทำให้ software stack ซับซ้อนมากขึ้น และก่อให้เกิดความท้าทายในการจัดการสภาพแวดล้อมที่แตกต่างกัน

เอดจ์ดาต้าเซ็นเตอร์ (Edge Datacenters)

จากการเพิ่มขึ้นของแอปพลิเคชัน Metaverse และ IoT จึง คาดว่าจะมีการขยายตัวของเอดจ์ดาต้าเซ็นเตอร์
Cloud Gaming ประมวลผลกราฟิกเรนเดอร์บน เซิร์ฟเวอร์ GPU ในเอดจ์ดาต้าเซ็นเตอร์ แทนอุปกรณ์ของผู้ใช้ และ
จำเป็นต้องมีความหน่วงเครือข่ายต่ำกว่า 25ms
จากการเพิ่มขึ้นของแอปพลิเคชันที่ต้องการการตอบสนองแบบเรียลไทม์ มีความเป็นไปได้สูงที่ทั้งจำนวนและขนาดของเอดจ์ดาต้าเซ็นเตอร์จะเพิ่มขึ้นอย่างมาก
เพื่อให้ดำเนินงานได้อย่างมีประสิทธิภาพ จำเป็นต้องขยาย Global-DaaC (แนวคิดการดำเนินงานดาต้าเซ็นเตอร์ทั่วโลกเสมือนเป็นคอมพิวเตอร์เครื่องเดียว) และปรับให้เหมาะสมเพื่อให้นักพัฒนาไม่ต้องกังวลกับการจัดการโครงสร้างพื้นฐานที่ซับซ้อน

การเพิ่มผลิตภาพของนักพัฒนา (Developer Productivity)

ตลอด 20 ปีที่ผ่านมา เครื่องมืออัตโนมัติได้เพิ่มผลิตภาพของผู้ดูแลระบบอย่างมาก จน อัตราส่วนจำนวนเซิร์ฟเวอร์ต่อผู้ดูแลเพิ่มขึ้นอย่างรวดเร็ว
แต่ การพัฒนาซอฟต์แวร์ยังคงใช้แรงงานเข้มข้น และการเพิ่มผลิตภาพยังค่อนข้างช้า
ต่อจากนี้ คาดว่าผลิตภาพของนักพัฒนาจะเพิ่มขึ้นอย่างรวดเร็วจาก 2 ปัจจัย:
1. การพัฒนาของเครื่องมือ สร้างโค้ดและดีบักด้วย AI
2. การเกิดขึ้นของ serverless programming paradigm แบบบูรณาการเต็มรูปแบบที่เฉพาะโดเมน
FrontFaaS ของ Meta เป็นตัวอย่างของการเขียนโปรแกรมแบบ serverless ลักษณะนี้ และ
คาดว่าในอนาคตจะเกิด programming paradigm ใหม่ที่ปรับให้เหมาะกับอุตสาหกรรมเฉพาะ เช่น การเงิน การแพทย์ เป็นต้น

บทสรุป

นวัตกรรมโครงสร้างพื้นฐานที่มี AI เป็นศูนย์กลางจะเดินหน้าอย่างรวดเร็วในอีก 10 ปีข้างหน้า
บริษัท hyperscale ควร แบ่งปันอินไซต์ของตน เพื่อช่วยให้ทั้งชุมชนพัฒนาได้เร็วขึ้นร่วมกัน

3 ความคิดเห็น

secret3056 2025-02-13

PoP นั้นคือ BGP4 หรือไม่ก็ TCP anycast แล้วคงไม่มีทางที่คนทั่วไปจะใช้งานมันได้ใช่ไหมครับ..? T_T

pribess 2025-02-13

ผม/ฉันไม่ค่อยเข้าใจว่าคำอธิบายที่ว่า PoP คือ BGP4 หรือ TCP anycast นั้นหมายถึงอะไรกันแน่ แต่ถ้าหมายถึงว่ามีการดำเนินการ AS ของตัวเองหรือไม่ ก็ใช่ครับ/ค่ะ
โดยปกติบริการแบบ multi-region ทั่วไปมักจะใช้ anycast DNS ร่วมกับ geolocation-based balancing มากกว่า
ใช่ครับ/ค่ะ ตอนนี้ยังไม่มี หากคุณต้องการ PoP แบบ multi-region ก็สามารถใช้ผู้ให้บริการรายอื่นได้

GN⁺ 2025-02-12

ความคิดเห็นใน Hacker News

หลังพัฒนา Threads เสร็จ ทีมโครงสร้างพื้นฐานได้รับแจ้งล่วงหน้าเพียงสองวันเพื่อเตรียมพร้อมสำหรับการเปิดตัว องค์กรขนาดใหญ่ส่วนใหญ่มักใช้เวลามากกว่าสองวันแค่ในการจัดทำแผนโครงการที่เกี่ยวข้องกับหลายสิบทีมที่พึ่งพากัน แต่ที่ Meta พวกเขาตั้ง war room ข้ามหลายไซต์ได้อย่างรวดเร็วเพื่อให้ทีมอินฟรากับทีมผลิตภัณฑ์ช่วยกันแก้ปัญหาแบบเรียลไทม์ แอปนี้มีผู้ใช้ถึง 100 ล้านคนภายใน 5 วันหลังเปิดตัว กลายเป็นแอปที่เติบโตเร็วที่สุดในประวัติศาสตร์
ความสามารถในการคงความเร็วในการปล่อยผลิตภัณฑ์ได้นั้นน่าประทับใจ ต้องใช้ความพยายามมากเพื่อไม่ให้ระบบราชการเพิ่มขึ้น และไม่ให้ฝ่ายกฎหมายหรือแผนกอื่น ๆ สร้างขั้นตอนอนุมัติที่เป็นคอขวด หรือไม่ก็ต้องมีความสามารถในการใช้ war room เพื่อเร่งงานให้เสร็จอย่างรวดเร็ว
ตอนอยู่ที่ FB ผมได้สัมผัสว่าอินฟรานั้นแข็งแกร่งแค่ไหน วิศวกรผลิตภัณฑ์สร้างโปรเจ็กต์ขนาดใหญ่ได้ภายในไม่กี่วัน ผมเคยเป็น tech lead ให้หลายทีม และบางทีมที่พูดถึงที่นี่คือทีม HBase และ ZippyDB
เจ๋งมากที่มีการพูดถึง ZippyDB ต่อสาธารณะเป็นครั้งแรก และก็ดีมากที่มีการพูดถึงการเพิ่มประสิทธิภาพของนักพัฒนา มีการ push บริการ 10,000 รายการหรือทำทุกคอมมิตกันทุกวัน
หลังออกจาก FB ผมหาอะไรที่คล้ายกันไม่ได้เลย เลยกำลังสร้างอินฟราที่ตัวเองต้องการขึ้นมาในรูปแบบสตาร์ตอัป Batteries Included
เสียดายที่คอมเมนต์เหล่านี้เต็มไปด้วยความประชดประชันและปฏิกิริยาเชิงลบ หลายคนเกลียด Meta แต่บทความจริงสำหรับผมนั้นชวนทึ่งมาก ผมไม่เคยรู้เลยว่าโครงสร้างพื้นฐานที่ค้ำจุนโลกดิจิทัลสมัยใหม่นั้นกว้างใหญ่และซับซ้อนเพียงใด การได้อ่านบทความนี้และเห็นสเกลของมันน่าทึ่งมาก
บริษัทอาจแย่ในหลายด้าน แต่ทุกอย่างที่อยู่ในบทความสำหรับผมนั้นน่าทึ่ง
ผมไม่ใช่วิศวกรแบบพวกคุณ ดังนั้นบทความนี้อาจเป็นข่าวเก่าสำหรับพวกคุณ แต่ผมอดไม่ได้ที่จะพูดว่า "ว้าว"
ถ้าเอาบทความนี้ไปให้คนเขียนนิยายวิทยาศาสตร์ในอดีตดู พวกเขาก็คงรู้สึกทึ่งเหมือนกัน
น่าทึ่งจริง ๆ เทคโนโลยีอันยอดเยี่ยมและน่าประทับใจทั้งหมดนี้ รวมถึงวิศวกรที่เก่งที่สุดในโลก ถูกใช้เพียงเพื่อยัดโฆษณาให้เข้าตาผู้คนมากขึ้นเท่านั้น เฮ้อ
น่าสนใจที่มีการอธิบาย PHP เว็บฟรอนต์เอนด์ว่าเป็นสถาปัตยกรรม "serverless" หรือ "function as a service" ดูเหมือนจะเป็นเรื่องของมุมมอง มันคือบริการที่มีโค้ดเบสเดียวซึ่งมีหลายเอนด์พอยต์ถูก deploy อยู่ จากมุมมองของผู้ดูแลเอนด์พอยต์มันอาจเป็น "serverless" แต่เหมือน abstraction ทั้งหลาย มันมีจุดที่รายละเอียดภายในรั่วออกมา
ในสภาพแวดล้อมของดาต้าเซ็นเตอร์ ผมชอบคอนโทรลเลอร์แบบรวมศูนย์เพราะความเรียบง่ายและความสามารถในการตัดสินใจคุณภาพสูง ในหลายกรณี แนวทางแบบไฮบริดที่รวม control plane แบบรวมศูนย์เข้ากับ data plane แบบกระจาย ดูจะเหมาะสมที่สุด
แนวทางนี้ดูเหมือนเป็นหนึ่งในดีไซน์ที่เหมาะสมที่สุดสำหรับ software networking (service mesh) และ storage (การดำเนินงานฐานข้อมูล) ขององค์กรที่มีจำนวนเซิร์ฟเวอร์มหาศาล สิ่งที่น่าทึ่งคือเครือข่าย IP ไม่ได้พึ่งพา BGP เป็นหลักแต่กลับใช้โมเดลเดียวกัน
คาดว่าจะใช้ local caching เพื่อลดภาระของ L7 router และปรับปรุง latency ของการ query ฐานข้อมูล ไคลเอนต์สามารถทำ cache invalidation และ query กลับไปที่ service mesh ได้อีกครั้งหลังหมดเวลา timeout ที่สมเหตุสมผล
ฟังก์ชัน serverless ที่พัฒนาอย่างรวดเร็วรวมกับ continuous deployment และการที่ใครก็ได้แก้ไขได้ทั้งโค้ดเบส ฟังดูเหมือนฝันร้ายแบบดิสโทเปีย ปริมาณ logging ที่ต้องใช้เพื่อดีบักและตามหาบั๊กคงมหาศาลสุด ๆ
การใช้ Erlang เพื่อเขียนฟังก์ชัน serverless ดูเหมือนจะหลีกเลี่ยงข้อดีสำคัญทั้งหมดที่ BEAM มอบให้ได้
วิศวกรผลิตภัณฑ์ส่วนใหญ่เขียนโค้ดเป็นฟังก์ชัน serverless แบบ stateless โดยใช้ PHP, Python และ Erlang ซึ่งมีข้อดีด้านความเรียบง่าย ประสิทธิภาพการทำงาน และความเร็วในการทำซ้ำ
เพื่อเพิ่มผลิตภาพของนักพัฒนา Meta นำ continuous deployment มาใช้แบบทั่วทั้งองค์กร และทำให้นักพัฒนาจำนวนมากขึ้นสามารถเขียนฟังก์ชัน serverless ได้ แทนที่จะเขียนโค้ดบริการแบบดั้งเดิม
สำหรับงานคอมพิวต์ที่ไม่ใช่ AI พวกเขามีเซิร์ฟเวอร์ให้เพียงชนิดเดียว ติดตั้ง CPU แบบเดียวและ DRAM ปริมาณเท่ากันเสมอ (เดิม 64GB ตอนนี้ 256GB) ผมสงสัยว่านี่เป็นเรื่องปกติทั้งอุตสาหกรรมหรือเป็นเรื่องปกติเฉพาะที่ Meta
เมื่อรูปภาพไม่ได้ถูกแคชไว้ที่ CDN109 หากผู้ใช้ร้องขอ CDN109 จะส่งคำขอไปยัง PoP ที่อยู่ใกล้เคียง จากนั้น PoP จะส่งคำขอไปยัง load balancer ในภูมิภาคดาต้าเซ็นเตอร์ และ load balancer จะไปดึงรูปจากระบบจัดเก็บข้อมูล
เวลาร้องขอรูปขนาด 1MB บนการเชื่อมต่อที่ช้า การส่งรูป 1MB ด้วย latency 100ms จะไม่เร็วกว่าการผ่านหลายรอบของการรับส่งข้อมูลและ latency ที่เพิ่มขึ้นเรื่อย ๆ หรือ?
ถ้าสมมติว่าคำขอวิ่งผ่านระบบของ Meta สุดท้ายมันก็จะไปถึงดาต้าเซ็นเตอร์เดียวกันอยู่ดี และสมมติว่าไม่มีเทคโนโลยี FTL
การเปรียบเทียบกับ hyperscaler แบบตรงไปตรงมานั้นน่าสนใจเป็นพิเศษ ผมสงสัยว่านี่คือการเตรียมพร้อมเพื่อเปิดตัว public cloud ของตัวเองหรือไม่ อยากให้ใครสักคนจาก Meta มาแสดงความเห็น