ภาพลวงตาของเซิร์ฟเวอร์เลส
- เซิร์ฟเวอร์เลส ได้กลายเป็นเทรนด์หลักของเทคโนโลยีคลาวด์
- แนวคิดนี้ช่วยให้ผู้พัฒนาเทคโนโลยีสามารถโฟกัส เฉพาะที่ตรรกะทางธุรกิจ โดยไม่ต้องแบกรับภาระในการจัดการเซิร์ฟเวอร์
- รูปแบบการชำระเงิน: จ่ายเฉพาะตามการใช้งาน และภาระด้านการดำเนินงานแทบเป็นศูนย์
- ฐานข้อมูล serverless หลายตัวได้เข้ามาในตลาด โดยมีผู้เล่นเดิมอย่าง Elastic, Confluent และ Pinecone เหนือกว่าสู้กับผู้ท้าชิงรายใหม่อย่าง Neon, WarpStream, Upstash และ Turbopuffer
ปัญหาของฐานข้อมูล serverless แบบเดิม
- ฐานข้อมูล serverless จำนวนมาก ไม่ใช่เซิร์ฟเวอร์เลสที่แท้จริง
- บริการส่วนใหญ่สร้างบนพื้นฐาน สถาปัตยกรรม cloud-native ซึ่งเป็นการออกแบบที่สร้างสรรค์สำหรับยุคระบบเซิร์ฟเวอร์พูล
- เดินเครื่อง คลัสเตอร์เซิร์ฟเวอร์ และใช้ซอฟต์แวร์ที่ซับซ้อนร่วมกับการแทรกแซงของมนุษย์ในการพยากรณ์โหลดและจัดการความจุ
- ภาพลวงตา นี้ก่อให้เกิดปัญหาจริงแก่ผู้ใช้
ผลกระทบของสถาปัตยกรรมที่ไม่คุ้มค่า
- ความไม่สอดคล้องด้านสถาปัตยกรรม ไม่ใช่แค่อนุมานเฉพาะเชิงเทคนิค แต่เป็น ปัญหาจริง ที่ผู้ใช้ต้องเจอ
- ผู้ใช้ต้องจ่ายค่าบริการสำหรับ เซิร์ฟเวอร์ที่ว่างอยู่ โดยที่คลัสเตอร์เซิร์ฟเวอร์ถูกรันอยู่เสมอเพื่อรองรับภารกิจหลากหลาย
- ปัญหาความสามารถในการขยาย: การเพิ่มเซิร์ฟเวอร์ใหม่เข้าคลัสเตอร์ต้องใช้เวลา หลายนาที และไม่สามารถรับมือกับอาการพุ่งของทราฟฟิกได้ทันที
- ทางเลือกจำกัด: ต้องจัดการโครงสร้างพื้นฐานตามแต่ละภูมิภาคคลาวด์ ทำให้พื้นที่ให้เลือกใช้งานสำหรับผู้ใช้ถูกจำกัด
โมเดลที่ไม่ยั่งยืน
- ฐานข้อมูล “เซิร์ฟเวอร์เลส” ที่ยึดโครงสร้างสถาปัตยกรรมแบบเซิร์ฟเวอร์พูล ไม่ยั่งยืน
- ผู้ให้บริการจำเป็นต้องลงทุนจำนวนมากเพื่อ ดำเนินงานคลัสเตอร์เซิร์ฟเวอร์ ซึ่งนำไปสู่การปรับราคาได้
- ผู้ใช้ระดับเบา ต้องจ่ายค่าธรรมเนียมสูงเกินความจำเป็นเพื่อช่วยสนับสนุนระบบ และผู้ใช้ที่ประสบความสำเร็จจะเผชิญกับ การขึ้นราคาที่ไม่คาดคิด
ความจำเป็นของสถาปัตยกรรม serverless-native
- ในยุคเริ่มต้นของ cloud computing ส่วนใหญ่ของ ฐานข้อมูล “คลาวด์” ล้วนเป็นฐานข้อมูลดั้งเดิม
- สถาปัตยกรรม serverless-native โยนภาระทั้งหมดในการจัดการโครงสร้างพื้นฐานให้ผู้ให้บริการคลาวด์ และใช้ ฟังก์ชันไร้สถานะ และบริการ serverless แทนการใช้คลัสเตอร์เซิร์ฟเวอร์
- แนวทางนี้มองโครงสร้างพื้นฐานคลาวด์เป็น ซูเปอร์คอมพิวเตอร์ก้อนใหญ่หนึ่งก้อน ซึ่งทำให้เกิดการขยายตัวได้ทันที และโมเดล จ่ายเฉพาะตามคำขอ อย่างแท้จริง
- การทดสอบลิตมาส: เพื่อพิสูจน์ว่าฐานข้อมูลนั้น serverless-native จริง ต้องเช็กได้ว่าสามารถ deploy ได้ในบัญชีคลาวด์โดยไม่ต้อง provision Kubernetes cluster หรือ VM
แนะนำ LambdaDB
- LambdaDB เป็น search engine ใหม่ที่ออกแบบมาแบบ serverless-native
- ระบบนี้ทำงานผ่านชุด ฟังก์ชันและทรัพยากร serverless และแยกตรรกะฐานข้อมูลออกจากโครงสร้างพื้นฐานโดยสมบูรณ์
- คำขอจากผู้ใช้ ไหลผ่าน regional gateway และถูก route ไปยัง Control Functions หรือ Data Functions ตามประเภทคำขอ
- ฟีเจอร์องค์กร: LambdaDB ให้ฟังก์ชันเช่น point-in-time restore และ zero-copy cloning โดยไม่ต้องจัดการโครงสร้างพื้นฐาน
วิธีทำงานของ LambdaDB
- สถาปัตยกรรม LambdaDB: ทุกส่วนประกอบสร้างด้วยบริการ cloud serverless
- เกตเวย์ ตรวจสอบ API key ของคำขอผู้ใช้ และ route ไปยังฟังก์ชันควบคุมหรือฟังก์ชันข้อมูล
- ฟังก์ชันควบคุม จัดการคำขอ CRUD และคำขอการจัดการข้อมูล ขณะที่ ฟังก์ชันข้อมูล ทำการเขียนและอ่านข้อมูลจริง
- เส้นทางการเขียน: Writer Function บันทึกคำขอ ลงใน serverless write buffer ที่ทนทาน จากนั้นส่งคำตอบกลับไคลเอนต์
ความย้อนแย้งด้านประสิทธิภาพต้นทุน
- LambdaDB ลดต้นทุนคอมพิวติงเมื่อเทียบกับฐานข้อมูลเซิร์ฟเวอร์พูล
- แม้ว่าราคาต่อหน่วยของ Lambda จะสูงกว่าอินสแตนซ์ EC2 แต่ด้วย ความซ้ำซ้อนที่จำเป็นเพื่อรับประกันความพร้อมใช้งานสูงและความทนต่อความผิดพลาด จึงช่วยลดต้นทุนได้
- ความสิ้นเปลืองจากความจุคงที่: โดยเฉลี่ยองค์กรมีการใช้ compute ราว 10-20% เท่านั้น จึงทำให้ serverless computing ลดต้นทุนได้ 50-90%
ประสิทธิภาพและความสามารถในการขยาย
- ประสิทธิภาพและการขยายตัว: LambdaDB แสดงผลในงานทดสอบที่เพิ่มเวกเตอร์หลายล้านรายการด้วยความหนาแน่น 960 มิติ
- Latency การเขียน: ที่อัตราอัพเซิร์ต 10 ครั้งต่อวินาที ความหน่วงแบบกลาง (median) อยู่ที่ 43ms และแม้ทราฟฟิกเพิ่มขึ้น 100 เท่า Latency ก็ยังค่อนข้างคงที่
- Latency การคิวรี: ความหน่วงในการคิวรีค่อนข้างเสถียรทุกระดับโหลด และ p99 อยู่ระหว่าง 172ms ถึง 210ms
- ความพยายามในการปรับแต่ง: กำลังเพิ่มการ optimize latency ของ query function อย่างต่อเนื่อง และโครงสร้างพื้นฐาน serverless ก็ได้รับการปรับปรุงเช่นกัน
ประโยชน์ที่ลูกค้าได้รับ
- ประหยัดต้นทุน: LambdaDB ถูกกว่ามากกว่า 10 เท่าเพราะไม่มีเซิร์ฟเวอร์ที่อยู่นิ่ง
- การขยายตัวแบบรวดเร็วและไร้ขีดจำกัด: LambdaDB สามารถขยายเป็นฟังก์ชันขนานนับพันภายในมิลลิวินาที
- เริ่มใช้งานและขยายได้ง่าย: สามารถสร้างแอปพลิเคชัน AI ที่ทรงพลังได้ และเมื่อเติบโตขึ้น สถาปัตยกรรมยังคงเรียบง่ายและคุ้มค่า
- ฟีเจอร์องค์กร: ให้ฟีเจอร์เช่น point-in-time restore และ zero-copy cloning และช่วยให้ใช้งานได้โดยไม่เพิ่มความซับซ้อนหรือค่าใช้จ่าย
แผนอนาคตและวิสัยทัศน์
- LambdaDB กำลังจัดการคำขอหลายล้านรายการต่อวันสำหรับเอกสารนับร้อยล้านรายการแล้ว
- แผนระยะยาว: มีแผนจะรองรับโมเดลข้อมูลประเภทอื่น ๆ เพิ่มเติม เช่น relational, stream, key-value, graph และอื่นๆ
ยังไม่มีความคิดเห็น