XFaaS: แพลตฟอร์มเซิร์ฟเวอร์เลสของ Meta ที่รองรับการเรียกใช้งานระดับล้านล้านครั้งต่อวัน

• แพลตฟอร์ม FaaS ที่ Meta ใช้งานภายในองค์กร
• ประมวลผลการเรียกใช้ฟังก์ชันระดับล้านล้านครั้งต่อวันบนเซิร์ฟเวอร์มากกว่า 100,000 เครื่องที่กระจายอยู่ในหลายสิบดาต้าเซ็นเตอร์รีเจียน
• อ้างว่ามีประสิทธิภาพมากกว่า AWS Lambda และ Azure Functions และได้เผยแพร่ผ่านงานวิจัย "XFaaS: Hyperscale and Low Cost Serverless Functions"

สถิติและข้อสังเกตที่น่าสนใจ

• แก่นของงานวิจัยคือ การปรับการใช้ฮาร์ดแวร์ให้เหมาะสมด้วยซอฟต์แวร์สามารถช่วยเพิ่มประสิทธิภาพของเซิร์ฟเวอร์เลสได้
• Meta ตระหนักถึงความสูญเปล่าจาก startup overhead ของ Serverless Functions และตั้งเป้าจำลอง Universal Worker ที่ทำให้ worker ทุกตัวสามารถรันทุกฟังก์ชันได้ทันทีโดยไม่มีค่าเริ่มต้นการทำงาน
  • ในสเกลขนาดนี้ ต้นทุนฮาร์ดแวร์มหาศาลมาก และแม้จะเป็นสัดส่วนเล็กน้อยก็มีความสำคัญ
• XFaaS ใช้กับฟังก์ชันที่ไม่ได้เผชิญหน้ากับผู้ใช้เท่านั้น เพราะฟังก์ชันเซิร์ฟเวอร์เลสมีความหน่วงที่ผันแปรมากเกินไปสำหรับการใช้งานแบบเผชิญหน้าผู้ใช้อย่างสม่ำเสมอ
• ไคลเอนต์ของ XFaaS เรียกใช้ฟังก์ชันแบบพุ่งขึ้นอย่างรุนแรง โดยความต้องการสูงสุดมากกว่าช่วงนอกพีค 4.3 เท่า
  • ตัวอย่างหนึ่งคือ มีการส่งคำขอเรียกใช้ฟังก์ชัน 20 ล้านครั้งเข้า XFaaS ภายในเวลาไม่ถึง 15 นาที
  • Meta พบว่าแม้ฟังก์ชันที่พุ่งขึ้นจะมีรูปแบบอยู่ และได้นำสิ่งนี้มาใช้เพื่อทำให้ฟังก์ชันที่มีการพุ่งขึ้นในเวิร์กโหลดคาดการณ์ได้มากขึ้น

XFaaS มีประสิทธิภาพแค่ไหน?

• ทำค่าเฉลี่ยการใช้งาน CPU รายวันได้ถึง 66% ซึ่งสูงกว่าค่าเฉลี่ยของอุตสาหกรรมมาก
• กระจายโหลดอย่างมีประสิทธิภาพด้วยทั้งเวลา (ผ่านการหน่วงฟังก์ชัน) และพื้นที่ (โดยส่งไปยังดาต้าเซ็นเตอร์ที่มีโหลดต่ำกว่า)

  Meta กำลังทยอยย้ายงานจำนวนมากให้ไปตั้งเวลารันในช่วงการใช้งานต่ำ ซึ่งสามารถคาดการณ์ทั้งโหลดและต้นทุนได้

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

ปัญหาที่ XFaaS แก้ได้

• ปัญหา: cold start ใช้เวลานาน
  • ถ้าคอนเทนเนอร์ถูกปิดเร็วเกินไป ก็ต้อง initialize คอนเทนเนอร์ทั้งหมดใหม่สำหรับการเรียกใช้งานครั้งถัดไป
  • ถ้าคอนเทนเนอร์ถูกปิดช้าเกินไป ก็จะค้างอยู่ในสถานะว่างและสิ้นเปลืองทรัพยากรคอมพิวต์อันมีค่า
  • วิธีแก้: XFaaS ใช้วิธีอย่าง JIT compilation เพื่อ approximate ให้ worker ทุกตัวสามารถรันทุกฟังก์ชันได้ทันที
• ปัญหา: การกระจายโหลดที่รุนแรง
  • การ over-provision ทำให้ต้นทุนฮาร์ดแวร์เพิ่มขึ้น ขณะที่การจัดสรรไม่พอทำให้ระบบช้าลง
  • วิธีแก้: XFaaS เลื่อนการรันฟังก์ชันที่ delay-tolerant ไปยังช่วงที่มีการใช้งานต่ำ และกระจายการเรียกใช้ฟังก์ชันไปยังดาต้าเซ็นเตอร์รีเจียนทั่วโลก
• ปัญหา: บริการ downstream รับโหลดเกิน
  • ตัวอย่าง: เคยมีกรณีที่การเรียกใช้ฟังก์ชันแบบไม่เผชิญหน้าผู้ใช้พุ่งสูงจนทำให้บริการออนไลน์ที่เผชิญหน้าผู้ใช้ล่ม
  • วิธีแก้: XFaaS ใช้กลไกคล้าย TCP congestion control เพื่อควบคุมการรันฟังก์ชัน

เปรียบเทียบกับ FaaS ทั่วไป (AWS Lambda, Google Cloud Functions, Azure Functions)

• FaaS บน public cloud จำกัดการรันฟังก์ชันไว้ในดาต้าเซ็นเตอร์รีเจียนเดียว ขณะที่ XFaaS สามารถกระจายการเรียกใช้ฟังก์ชันไปทั่วโลกเพื่อปรับปรุง load balancing ได้
• แพลตฟอร์ม FaaS มักให้ความสำคัญกับการลด latency ก่อน โดยมองข้ามอัตราการใช้ฮาร์ดแวร์ ส่วน XFaaS เน้นการใช้ฮาร์ดแวร์ให้คุ้มและ throughput ของการเรียกใช้ฟังก์ชัน
• เทคโนโลยีของ XFaaS ที่อาจเป็นประโยชน์ต่อ public cloud
  • อนุญาตให้ผู้เรียกระบุเวลาเริ่มรันฟังก์ชันได้
  • ให้เจ้าของฟังก์ชันตั้ง service-level objective (SLO) เกี่ยวกับเส้นตายการทำงานเสร็จได้ (ถ้า SLO ต่ำ ก็สามารถหน่วงเพื่อให้ได้ runtime ที่ดีกว่า)
  • อนุญาตให้เจ้าของฟังก์ชันกำหนดระดับความสำคัญให้ฟังก์ชันได้
• public cloud ไม่สามารถรันฟังก์ชันของหลายผู้ใช้ในโปรเซสเดียวกันแบบ XFaaS ได้ แต่ลูกค้าคลาวด์รายใหญ่สามารถนำแนวทาง XFaaS ไปใช้ใน virtual private cloud ได้
• มีทีมของ Meta เพียงไม่กี่ทีมที่ใช้ความจุของ XFaaS ไปเป็นสัดส่วนมาก ลูกค้ารายใหญ่ใน public cloud ที่มีลักษณะคล้ายกันก็น่าจะได้ประโยชน์จากกลยุทธ์ของ XFaaS เช่นกัน

Background: สมมติฐานและข้อกำหนด

• สมมติฐาน
  • อินไซต์สำคัญคือ ฟังก์ชันส่วนใหญ่ของ XFaaS ถูกทริกเกอร์โดย automated workflow และสามารถยอมรับความหน่วงได้
  • สิ่งนี้ทำให้ XFaaS สามารถกระจายโหลดได้ทั้งตามเวลา (โดยการหน่วงฟังก์ชัน) และตามพื้นที่ (โดยส่งไปยังดาต้าเซ็นเตอร์ที่โหลดต่ำกว่า)
  • XFaaS รองรับ runtime ของ PHP, Python, Erlang, Haskell และรองรับ container-based runtime แบบทั่วไปสำหรับทุกภาษา
  • ฟังก์ชันมีคุณสมบัติหลายอย่างที่นักพัฒนากำหนดได้ เช่น ชื่อฟังก์ชัน, อาร์กิวเมนต์, runtime, ความสำคัญ, เวลาเริ่มรัน, เส้นตายการรันเสร็จ, โควต้าทรัพยากร, ขีดจำกัด concurrency, นโยบาย retry เป็นต้น โดยเส้นตายการรันเสร็จสามารถตั้งได้ตั้งแต่ระดับวินาทีจนถึง 24 ชั่วโมง
  • XFaaS มีความจุฮาร์ดแวร์ต่างกันในแต่ละภูมิภาค ดังนั้น load balancing ต้องคำนึงถึงเรื่องนี้ด้วย
• ประเภทเวิร์กโหลด
  • Meta รองรับเวิร์กโหลด 3 ประเภทบน XFaaS
    • ฟังก์ชันที่ถูกทริกเกอร์จากคิว
    • ฟังก์ชันที่ถูกทริกเกอร์จากอีเวนต์ (เหตุการณ์การเปลี่ยนแปลงข้อมูลจาก data warehouse และระบบ data stream)
    • ฟังก์ชันที่ถูกทริกเกอร์ด้วยตัวจับเวลา (รันอัตโนมัติตามเวลาที่ตั้งไว้ล่วงหน้า)
  • XFaaS ใช้กับฟังก์ชันแบบไม่เผชิญหน้าผู้ใช้ เช่น ระบบแนะนำแบบ asynchronous, logging, บอตเพิ่มประสิทธิภาพการทำงาน และการแจ้งเตือน

สถาปัตยกรรมโดยรวม

(ส่วนนี้ยาวเกินไปและแทบจะถอดความจากงานวิจัยโดยตรง จึงขอละไว้)