สิ่งที่ได้เรียนรู้: การเรียกใช้ Presto ในสเกลของ Meta

Presto คือกลไกการสืบค้น SQL แบบโอเพนซอร์สที่เปิดให้บริการฟรี เราได้นำมาใช้ที่ Meta ตลอด 10 ปีที่ผ่านมา และขณะที่ใช้งานก็ได้เรียนรู้สิ่งต่างๆ มากมาย การเรียกใช้ในวงกว้าง ไม่ว่าจะเป็นเครื่องมือ กระบวนการ หรือบริการ ย่อมต้องอาศัยการแก้ไขปัญหาเพื่อก้าวข้ามความท้าทายที่เกิดขึ้นโดยไม่คาดคิด ต่อไปนี้เป็น 4 เรื่องที่เราได้เรียนรู้ขณะปรับขนาด Presto ตามสเกลของ Meta รวมถึงคำแนะนำบางส่วนหากคุณสนใจจะเรียกใช้การสืบค้นในวงกว้าง

การปรับขนาด Presto อย่างรวดเร็วให้สอดรับกับความต้องการที่เพิ่มขึ้น: เราพบกับความท้าทายใดบ้าง

การปรับใช้ Presto รุ่นใหม่ๆ

รูปภาพที่ 1: ขั้นตอนการทำงานของกระบวนการในการนำ Presto เวอร์ชั่นใหม่ๆ เข้ามาใช้ (แผนภาพโดยคุณ Philip S. Bell)

Meta เรียกใช้คลัสเตอร์ Presto จำนวนมาก ซึ่งครอบคลุมศูนย์ข้อมูลในหลายตำแหน่งที่ตั้งทั่วโลก โดย Presto มีการพัฒนาเวอร์ชั่นใหม่พร้อมใช้งานอย่างน้อย 1 ครั้งต่อเดือนและบางครั้งก็ 2 ครั้งต่อเดือนโดยประมาณ ความท้าทายแรกๆ อย่างหนึ่งที่เราพบขณะที่ฟุตปรินต์ของ Presto ใน Meta ขยายเพิ่มขึ้นอย่างรวดเร็วก็คือ การปรับใช้กลไกการสืบค้นกับคลัสเตอร์ปริมาณมากไปพร้อมๆ กับรับรองว่าจะมีความพร้อมใช้งานและความน่าเชื่อถืออย่างสม่ำเสมอ เหตุการณ์เช่นนี้เกิดขึ้นอย่างต่อเนื่องโดยเฉพาะอย่างยิ่งกับกรณีการใช้งาน Presto แบบอินเทอร์แอคทีฟ กล่าวคือ เวลาที่ผู้ใช้เริ่มสืบค้นและตั้งตารอผลลัพธ์ ส่วนกรณีการใช้งานแบบ "แบตช์" อัตโนมัติ การสืบค้นไม่สำเร็จเป็นเรื่องที่ไม่ค่อยน่ากังวลนักเนื่องจากมีการลองอีกครั้งโดยอัตโนมัติซึ่งทำให้มั่นใจว่าการสืบค้นจะสำเร็จในที่สุด

แนวทางแก้ไขปัญหานี้ก็ง่ายดาย คลัสเตอร์ Presto ทั้งหมดจะอยู่หลังโหลดบาลานเซอร์ที่เรียกว่า "เกตเวย์" ซึ่งมีหน้าที่รับผิดชอบ (ร่วมกับระบบอื่นๆ ที่ Meta) ในการกำหนดเส้นทางการสืบค้น Presto ไปยังคลัสเตอร์ที่เหมาะสม เมื่อจำเป็นต้องอัพเดตคลัสเตอร์ Presto ระบบจะระบุว่าคลัสเตอร์ดังกล่าวมีการถ่ายออกจากเกตเวย์ก่อน กล่าวคือ เกตเวย์หยุดกำหนดเส้นทางการสืบค้นใหม่ๆ ทั้งหมดไปยังคลัสเตอร์นั้น จากนั้น ระบบอัตโนมัติจะรอตามเวลาที่กำหนดไว้ก่อนแล้ว เพื่อให้การสืบค้นที่กำลังดำเนินอยู่กับคลัสเตอร์นั้นๆ เสร็จสิ้น ระบบจะอัพเดตคลัสเตอร์หลังจากนั้น และเมื่อมีสถานะออนไลน์ ระบบก็จะทำให้คลัสเตอร์นั้นแสดงต่อเกตเวย์ซึ่งสามารถเริ่มกำหนดเส้นทางการสืบค้นใหม่ๆ ไปยังคลัสเตอร์นั้นได้

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

การปรับการเริ่มใช้งานและการเลิกใช้คลัสเตอร์ Presto ให้เป็นแบบอัตโนมัติ

รูปภาพที่ 2: ขั้นตอนการทำงานแบบอัตโนมัติสำหรับการเพิ่มฮาร์ดแวร์ลงในคลัสเตอร์ (แผนภาพโดยคุณ Philip S. Bell)

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

ก่อนอื่น เราจำเป็นต้องปรับการกำหนดค่าคลัสเตอร์ให้เป็นมาตรฐาน กล่าวคือ เราจำเป็นต้องสร้างการกำหนดค่าพื้นฐานสำหรับกรณีการใช้งาน Presto แบบต่างๆ ที่ Meta จากนั้น แต่ละคลัสเตอร์จะมีข้อมูลจำเพาะเพิ่มเติมหรือถูกแทนที่สำหรับการกำหนดค่าพื้นฐานตามจำนวนขั้นต่ำ เมื่อเสร็จสิ้นแล้ว ระบบจะสามารถเปิดคลัสเตอร์ใหม่ทั้งหมดได้โดยสร้างการกำหนดค่าจากเทมเพลตพื้นฐานโดยอัตโนมัติ นอกจากนี้ การเปิดคลัสเตอร์ยังจำเป็นต้องมีการผสานการทำงานกับฮุคระบบอัตโนมัติ เพื่อผสานการทำงานกับบริการโครงสร้างพื้นฐานทั่วทั้งบริษัทต่างๆ เช่น Tupperware และบริการแบบเฉพาะคลังข้อมูล เมื่อคลัสเตอร์มีสถานะออนไลน์ ระบบจะส่งการสืบค้นทดสอบ 2-3 รายการไปยังคลัสเตอร์นั้น และระบบอัตโนมัติจะตรวจสอบยืนยันว่าคลัสเตอร์ดำเนินการสืบค้นดังกล่าวสำเร็จ จากนั้น ระบบจะลงทะเบียนคลัสเตอร์กับเกตเวย์และเริ่มส่งการสืบค้น

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

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

การแก้ไขจุดบกพร่องและการแก้ไขปัญหาแบบอัตโนมัติ

รูปภาพที่ 3: การตรวจจับโฮสต์ที่ไม่ดี (แผนภาพโดยคุณ Philip S. Bell)

เมื่อนำ Presto เข้ามาปรับใช้ที่ Meta เป็นวงกว้าง เราจำเป็นต้องมีเครื่องมือและระบบอัตโนมัติที่ช่วยให้ Oncall (บุคคลสำหรับติดต่อของ Presto) ทำงานได้ง่าย

ตลอดหลายปีที่ผ่านมา เราได้สร้าง "ตัววิเคราะห์" ขึ้นมามากมาย ซึ่งช่วยให้ Oncall แก้ไขจุดบกพร่องและประเมินต้นเหตุของปัญหาที่เกิดขึ้นได้อย่างมีประสิทธิภาพ ระบบเฝ้าสังเกตจะส่งการแจ้งเตือนเมื่อมีการละเมิด SLA ที่แสดงต่อลูกค้า จากนั้น ระบบจะเปิดใช้ตัววิเคราะห์ โดยตัววิเคราะห์จะหาข้อมูลจากระบบเฝ้าสังเกตต่างๆ มากมาย (Operational Data Store หรือ ODS) เหตุการณ์ที่เผยแพร่ไปยัง Scuba หรือแม้แต่บันทึกระดับโฮสต์ จากนั้น ตรรกะแบบกำหนดเองในตัววิเคราะห์จะเชื่อมโยงข้อมูลทั้งหมดนี้เข้าด้วยกันเพื่อสรุปหาต้นเหตุที่พอจะเป็นไปได้ ซึ่งเป็นประโยชน์อย่างยิ่งต่อ Oncall โดยจะนำเสนอการวิเคราะห์หาต้นเหตุ และช่วยให้สามารถเข้าไปดูตัวเลือกการบรรเทาปัญหาที่เป็นไปได้ต่างๆ ได้โดยตรง โดยในบางกรณี เราได้ปรับให้การแก้ไขจุดบกพร่องและการแก้ไขปัญหาเป็นไปโดยอัตโนมัติแบบสมบูรณ์เพื่อให้ Oncall ไม่ต้องเข้ามาช่วยเลยด้วย ทั้งนี้ เราได้อธิบายตัวอย่าง 2 รายการไว้ที่ด้านล่างนี้

การตรวจจับโฮสต์ที่ไม่ดี

เมื่อเรียกใช้ Presto เป็นวงกว้างกับเครื่องต่างๆ จำนวนมาก เราพบว่าโฮสต์ที่ "ไม่ดี" บางรายการอาจทำให้การสืบค้นไม่สำเร็จเป็นจำนวนมากได้ หลังจากตรวจสอบดูแล้ว เราพบว่ามีต้นเหตุอยู่ไม่กี่ประการที่ทำให้โฮสต์กลายเป็นโฮสต์ที่ "ไม่ดี" ดังนี้

• ปัญหาระดับฮาร์ดแวร์ซึ่งระบบเฝ้าสังเกตแบบทั่วทั้งระบบยังตรวจไม่พบเนื่องจากครอบคลุมไม่ถึง
• จุดบกพร่อง JVM ที่ไม่แน่ชัด ซึ่งในบางครั้งทำให้เกิดการสืบค้นไม่สำเร็จเป็นพักๆ อยู่เรื่อยๆ

ตอนนี้เราได้เฝ้าสังเกตการสืบค้นที่ไม่สำเร็จในคลัสเตอร์ Presto แล้วเพื่อรับมือกับปัญหานี้ โดยหากทำได้ เราจะระบุการสืบค้นที่ไม่สำเร็จแต่ละครั้งว่ามาจากโฮสต์ที่เป็นต้นเหตุเป็นการเฉพาะเจาะจง นอกจากนี้ เรายังตั้งค่าการแจ้งเตือน ซึ่งจะส่งออกไปเมื่อมีการระบุว่าโฮสต์หนึ่งๆ เป็นที่มาของการสืบค้นที่ไม่สำเร็จจำนวนมากผิดปกติ จากนั้น ระบบอัตโนมัติจะเริ่มทำงานเพื่อถ่ายโฮสต์จากระบบ Presto และหยุดการทำงานไม่สำเร็จ

การแก้ไขจุดบกพร่องเกี่ยวกับปัญหาในการจัดคิว

คลัสเตอร์ Presto แต่ละรายการรองรับการจัดคิวการสืบค้นในคลัสเตอร์เมื่อมีการเรียกใช้การสืบค้นพร้อมกันครบตามขีดจำกัดสูงสุดโดยอิงตามกรณีการใช้งาน การกำหนดค่าฮาร์ดแวร์ และขนาดการสืบค้น Meta ได้จัดให้มีกลไกการกำหนดเส้นทางที่ซับซ้อน เพื่อให้ระบบส่งการสืบค้น Presto ไปยังคลัสเตอร์ที่ "เหมาะสม" ซึ่งสามารถดำเนินการกับการสืบค้นนั้นๆ ได้โดยใช้ทรัพยากรต่างๆ ให้เกิดประโยชน์สูงสุด หลายๆ ระบบนอกเหนือจาก Presto มีส่วนช่วยในการตัดสินใจกำหนดเส้นทาง และมีการคำนึงถึงปัจจัยต่างๆ มากมายดังนี้

• สถานะปัจจุบันของการจัดคิวคลัสเตอร์ Presto
• การกระจายฮาร์ดแวร์ในศูนย์ข้อมูลต่างๆ
• ตำแหน่งของข้อมูล (Data locality) ของตารางต่างๆ ที่การสืบค้นใช้

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

ประสิทธิภาพของโหลดบาลานเซอร์

รูปภาพที่ 4: ประสิทธิภาพของโหลดบาลานเซอร์ (แผนภาพโดยคุณ Philip S. Bell)

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

ทั้งนี้ เพื่อป้องกันไม่ให้เกิดเหตุการณ์เช่นนั้น เราเริ่มทำให้เกตเวย์มีประสิทธิภาพมากขึ้นและพร้อมรองรับปริมาณการใช้งานแบบ DDoS ที่ไม่พึงประสงค์ดังกล่าว เราได้ใช้ฟีเจอร์การจำกัดผลลัพธ์ ซึ่งจะปฏิเสธการสืบค้นต่างๆ เมื่ออยู่ในสภาวะที่รับภาระงานหนัก คุณสามารถเปิดใช้งานการจำกัดผลลัพธ์ได้ตามจำนวนการสืบค้นต่อวินาทีในมิติต่างๆ เช่น ต่อผู้ใช้, ต่อแหล่งที่มา, ต่อ IP รวมถึงในระดับแบบทั่วระบบสำหรับทุกการสืบค้น การเพิ่มประสิทธิภาพอีกอย่างหนึ่งที่เราใช้ก็คือการปรับขนาดอัตโนมัติ เมื่อใช้บริการแบบทั่วทั้ง Meta ที่รองรับการปรับขนาดงานเพิ่มขึ้นและลดลง จำนวนอินสแตนซ์ของเกตเวย์ในตอนนี้จึงปรับเปลี่ยนได้อยู่ตลอด ทำให้แม้จะอยู่ในสภาวะที่รับภาระงานหนัก เกตเวย์ก็สามารถปรับขนาดขึ้นเพื่อรองรับปริมาณงานเพิ่มเติมได้และไม่เกินขีดจำกัดของ CPU/หน่วยความจำ ซึ่งช่วยป้องกันไม่ให้เกิดการบกพร่องดังที่อธิบายไว้ข้างต้น เมื่อใช้วิธีนี้ร่วมกับฟีเจอร์การจำกัดผลลัพธ์ คุณก็จะมั่นใจได้ว่าเกตเวย์จะมีประสิทธิภาพและสามารถรองรับปริมาณงานจำนวนมากในรูปแบบต่างๆ ที่คาดไม่ถึงได้

เราจะให้คำแนะนำอะไรกับทีมที่ปรับเพิ่มขนาด Data Lakehouse ของตนโดยใช้ Presto

รูปภาพที่ 5: การปรับขนาดสถาปัตยกรรม Presto (แผนภาพโดยคุณ Philip S. Bell)

แง่มุมที่สำคัญบางประการที่ควรคำนึงถึงเมื่อปรับเพิ่มขนาด Presto มีดังนี้

1. การจัดให้มี SLA ที่แสดงต่อลูกค้าแบบเข้าใจง่ายและกำหนดมาเป็นอย่างดี การกำหนด SLA เกี่ยวกับเกณฑ์ชี้วัดที่สำคัญต่างๆ เช่น เวลาในการจัดคิวและอัตราการสืบค้นไม่สำเร็จ ในลักษณะที่ติดตามปัญหาต่างๆ ของลูกค้า จะกลายเป็นเรื่องสำคัญอย่างยิ่งเมื่อมีการปรับเพิ่มขนาด Presto เมื่อมีผู้ใช้จำนวนมาก หากไม่มี SLA ที่เหมาะสม ก็อาจเป็นอุปสรรคอย่างมากต่อการลดปัญหาในการใช้งานจริง เนื่องจากจะเกิดความสับสนในการระบุผลลัพธ์จากเหตุการณ์ที่เกิดขึ้น
2. การเฝ้าติดตามและการแก้ไขจุดบกพร่องแบบอัตโนมัติ เนื่องจาก Presto มีการปรับเพิ่มขนาดและคลัสเตอร์ก็มีจำนวนมากขึ้น การเฝ้าติดตามและการแก้ไขจุดบกพร่องแบบอัตโนมัติจึงมีความสำคัญมาก
   • การจัดให้มีการเฝ้าติดตามอย่างถี่ถ้วนสามารถช่วยให้พบปัญหาในการใช้งานจริงได้ก่อนที่ปัญหาจะลุกลามเกินแก้ไข การพบปัญหาตั้งแต่เนิ่นๆ จะช่วยให้แน่ใจว่าเราจะลดผลกระทบต่อผู้ใช้ให้เหลือน้อยที่สุดเท่าที่เราจะทำได้
   • การตรวจสอบด้วยตนเองเมื่อพบปัญหาในการใช้งานจริงที่ส่งผลกระทบต่อลูกค้านั้นไม่สามารถปรับขนาดได้ โดยคุณจำเป็นต้องจัดให้มีการแก้ไขจุดบกพร่องแบบอัตโนมัติเพื่อช่วยให้พบต้นเหตุได้อย่างรวดเร็ว
3. การปรับสมดุลโหลดที่ดี ในขณะที่ระบบ Presto เติบโตขึ้น การมีโซลูชั่นในการปรับสมดุลโหลดที่ดีไว้หน้าคลัสเตอร์ Presto นั้นเป็นเรื่องสำคัญ เมื่อมีการใช้งานมาก การปรับสมดุลโหลดที่ไร้ประสิทธิภาพแม้เพียงเล็กน้อยก็อาจส่งผลเสียอย่างมากได้เนื่องจากมีปริมาณงานมหาศาล
4. การจัดการการกำหนดค่า การจัดการการกำหนดค่าสำหรับระบบคลัสเตอร์ Presto ขนาดใหญ่อาจเป็นเรื่องยากหากขาดการวางแผนเป็นอย่างดี ทั้งนี้ การกำหนดค่าควรรองรับ Hot Reload หากทำได้ เพื่อให้อินสแตนซ์ Presto ไม่จำเป็นต้องมีการเริ่มใหม่หรืออัพเดตในลักษณะที่ต้องหยุดการทำงาน ซึ่งจะส่งผลให้การสืบค้นไม่สำเร็จและลูกค้าไม่พึงพอใจ

บทความนี้เขียนขึ้นร่วมกับคุณ Neerad Somanchi ซึ่งดำรงตำแหน่งวิศวกรการผลิตจาก Meta และคุณ Philip Bell ซึ่งดำรงตำแหน่งนักพัฒนาผู้มีส่วนร่วมจาก Meta

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ Presto โปรดไปที่ prestodb.io รับชมคำอธิบายคร่าวๆ เกี่ยวกับ Presto ของคุณ Philip Bell บน YouTube หรือติดตาม Presto บน Twitter, Facebook และ LinkedIn

เรียนรู้เพิ่มเติมเกี่ยวกับโอเพนซอร์สของ Meta ได้ที่เว็บไซต์โอเพนซอร์สของเรา, ติดตามช่อง YouTube ของเรา หรือติดตามเราบน Twitter, Facebook และ LinkedIn