ฐานข้อมูล “เซิร์ฟเวอร์เลส” ในปัจจุบันยังไม่ใช่เซิร์ฟเวอร์เลสที่แท้จริง

ภาพลวงตาของเซิร์ฟเวอร์เลส

• เซิร์ฟเวอร์เลส ได้กลายเป็นเทรนด์หลักของเทคโนโลยีคลาวด์
• แนวคิดนี้ช่วยให้ผู้พัฒนาเทคโนโลยีสามารถโฟกัส เฉพาะที่ตรรกะทางธุรกิจ โดยไม่ต้องแบกรับภาระในการจัดการเซิร์ฟเวอร์
• รูปแบบการชำระเงิน: จ่ายเฉพาะตามการใช้งาน และภาระด้านการดำเนินงานแทบเป็นศูนย์
• ฐานข้อมูล 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 และอื่นๆ

[davidshim]

แนวคิดนี้ดี แต่เพื่อให้เวลาแฝงของการคิวรีลดลง จำเป็นต้องมี state อยู่เสมอครับ เปรียบเทียบกับ MySQL, PostgreSQL และอื่นๆ แล้ว เวลาหน่วงของคิวรีดูเหมือนสูงถึงเกือบ 100 เท่า และรู้สึกว่าใกล้เคียงกับการเขียน-อ่านข้อมูลกับระบบไฟล์มาก

[stevenk]

ขอบคุณสำหรับความคิดเห็นที่ดีมากครับ/ค่ะ

เรื่องที่คุณกล่าวถึงว่า "จำเป็นต้องมี state เพื่อให้ latency ลดลง" เป็นการชี้ให้เห็น trade-off ที่สำคัญของสถาปัตยกรรมของเราได้อย่างแม่นยำมาก

ก่อนอื่นขอพูดถึง latency ของคิวรีก่อนนะครับ จาก benchmark ของเรา ค่า p99 (99th percentile) อยู่ที่ประมาณ 130-210ms

ส่วนที่คุณกล่าวถึงความต่างถึง 100 เท่านั้นน่าจะเป็นการอ้างอิงถึงกรณีแย่ที่สุดที่มีการระบุในเนื้อหาว่า "ในกรณี cold start อาจใช้เวลาหลายวินาที" ดังนั้นจึงดูเหมือนว่าต่างกันมาก

อย่างที่คุณชี้ไว้ จุดนี้เป็นจุดอ่อนที่ชัดเจนของสถาปัตยกรรมเรา และดังที่ระบุในบทความ สภาพแวดล้อมการใช้งานจริงมีโอกาสเกิดขึ้นน้อยกว่า 0.01% (P99.99) เท่านั้น ส่วนใหญ่คิวรีที่เหลือจะถูกออกแบบให้ใช้หน่วยความจำและดิสก์ local ของแต่ละ Lambda เป็นแคช เพื่อให้ได้ประสิทธิภาพที่เสถียร

ดังนั้นอย่างที่คุณกล่าว ระบบระบบการเทรดทางการเงินที่ต้องการความหน่วงต่ำมากและต้องรับประกันว่าแต่ละคิวรีจะต่ำกว่า 10ms อาจไม่เหมาะกับสถาปัตยกรรมประเภทนี้ แต่ในแอปพลิเคชันค้นหาและแนะนำบนพื้นฐาน AI ส่วนใหญ่ เวลาแฝงที่ระดับ P99 อยู่ที่ 100-200ms ถือว่าเป็นสมรรถนะที่ดี และเราคิดว่าข้อได้เปรียบในการลดต้นทุนโครงสร้างพื้นฐานและภาระการดำเนินงานได้มากกว่า 90% นั้นมากกว่ามาก

ขอบคุณอีกครั้งสำหรับความคิดเห็นเชิงลึกอีกครั้ง

[davidshim]

ดังที่คุณกล่าวมา มันน่าจะเป็นโซลูชันที่สามารถใช้เป็น "serverless" แบบแท้จริงได้เฉพาะในบางสถานการณ์ มากกว่าจะเป็นฐานข้อมูลแบบใช้งานได้ทั่วไป

[davidshim]

ไม่คิดว่าจะมีคนตอบเป็นภาษาเกาหลีนะ! (เขียนด้วยโทนค่อนข้างเสียดสีไปหน่อย...)

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

ผมก็คิดว่าลองทำดูดีไหม? แต่เหตุผลที่กังวลคือ ถ้าทำแบบนั้นเราต้องนำตรรกะไบนารีสำหรับ indexing, sorting ฯลฯ ที่ถูกสร้างไว้ใน MySQL, PostgreSQL มาทำใหม่บน Lambda ซึ่งไม่รู้เลยว่าจะยากแค่ไหนในการทำโปรเจกต์ฐานข้อมูล open-source ที่เชื่อถือได้อีกครั้งบน Lambda

แต่เนื่องจากเป็นผลิตภัณฑ์ที่คุณพัฒนาขึ้นเอง จึงหวังว่าจะก้าวหน้าไปได้มากกว่านี้นะครับ~!

[stevenk]

ขอบคุณสำหรับคำแนะนำที่ดีมากครับ ตามที่คุณกล่าวมา ใช้ได้ไม่เหมาะสำหรับ use case ของ RDB และคาดว่าควรมองว่าเป็นตำแหน่งของ Search Engine (Elasticsearch) และ Vector DB (Pinecone) ครับ ภายในองค์กรเรายังใช้ Lucene ซึ่งผ่านการรับรองความน่าเชื่อถือมานานแล้วเพื่อรองรับฟีเจอร์ เช่น indexing, sorting และ aggregation เป็นต้น ขอบคุณครับ :)