วิธีรันแอปพลิเคชันแบบเรียลไทม์ด้วยต้นทุน 0 ดอลลาร์ต่อเดือน
นักพัฒนาแชร์สถาปัตยกรรมสร้างแอปแชทกลุ่ม BatchUp ใน 5 วัน ด้วย Cloudflare Durable Objects และการกระจายบัญชีเพื่อเลี่ยงค่าใช้จ่าย

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- แอปแชทเรียลไทม์ BatchUp ทำงานด้วยต้นทุน 0 ดอลลาร์ต่อเดือน
- ใช้ Cloudflare Durable Objects เพื่อแยกการทำงานแต่ละห้องแชท
- กระจายโหลดงานข้าม 8 บัญชี และ Worker 7 ชุดเพื่อไม่ให้เกินขีดจำกัด
- ออกแบบมาเพื่อเป้าหมายส่งข้อความความหน่วงต่ำกว่า 100 มิลลิวินาที
การส่งข้อมูลแบบเรียลไทม์มักเป็นจุดที่โครงสร้างพื้นฐานแบบฟรีแวร์ทั่วไปไปต่อไม่ไหว เมื่อระบบต้องการส่งข้อมูลรวดเร็วระดับเสี้ยววินาทีท่ามกลางการสนทนาจำนวนมาก นักพัฒนาส่วนใหญ่จึงมักหันไปพึ่งพาเซิร์ฟเวอร์ WebSocket แบบเฉพาะกิจซึ่งมาพร้อมกับค่าใช้จ่ายรายเดือนที่ตามมา
บทความจาก Dev.to ได้เผยแพร่แนวทางที่แตกต่าง โดยนำมาใช้สร้างและรันแอปพลิเคชันแชทกลุ่มแบบเรียลไทม์ในชื่อ BatchUp ภายในเวลาเพียง 5 วัน บนโครงสร้างพื้นฐานที่มีต้นทุน 0 ดอลลาร์ต่อเดือน ณ สเกลปัจจุบันสำหรับชุมชนนักศึกษา
แอปพลิเคชันแชทเรียลไทม์ต้องการองค์ประกอบหลัก 2 ประการที่ไม่ค่อยอยู่ร่วมกันบนเซิร์ฟเวอร์เดี่ยวแบบ Single-tenant ได้แก่ การแยกการทำงานออกจากกันเพื่อไม่ให้ห้องแชทที่ใช้งานหนักฉุดให้ห้องอื่นช้าลง และความหน่วงต่ำที่คาดเดาได้ซึ่งอยู่ใกล้ชิดกับผู้ใช้งาน

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สถาปัตยกรรมนี้แก้ปัญหาดังกล่าวด้วยการให้แต่ละบทสนทนารันอยู่ใน Cloudflare Durable Object ของตัวเอง ซึ่งเป็นสภาพแวดล้อมประมวลผลแบบแยกส่วนที่จำกัดขอบเขตไว้สำหรับหนึ่งบทสนทนาโดยเฉพาะ ช่วยแก้ปัญหาเพื่อนบ้านส่งเสียงดังหรือ Noisy Neighbor ได้โดยโครงสร้าง เพราะไม่มี Event Loop ร่วมกันให้ห้องแชทอื่นมาแย่งทรัพยากร
การใช้ Cloudflare Durable Objects ร่วมกับสถาปัตยกรรมแบบแยกส่วน (Isolation) ช่วยลดความซับซ้อนในการจัดการทรัพยากรระดับจุลภาค แต่ความท้าทายที่แท้จริงคือการออกแบบระบบ routing เพื่อส่งต่อคำขอไปยัง Durable Object ที่ถูกต้องในแต่ละ shard ซึ่งนักพัฒนาต้องชั่งน้ำหนักระหว่างความคุ้มค่าด้านต้นทุนและความซับซ้อนในการดูแลรักษาโครงสร้างพื้นฐาน
องค์ประกอบชิ้นที่สองคือการแบ่งระบบทั้งหมดออกเป็นหลายบัญชี Cloudflare ได้แก่ 8 บัญชี และใช้งาน Shard Workers จำนวน 7 ตัวในระบบปัจจุบัน แทนที่จะพยายามรันทุกอย่างให้อยู่ภายใต้ขีดจำกัดฟรีแวร์ของบัญชีเดียว โดย Shard Worker แต่ละตัวจะดูแลรับผิดชอบปริมาณการใช้งานในส่วนของตนเอง
เมื่อนำแนวทางทั้งสองมารวมกัน เป้าหมายของระบบคือการส่งข้อความด้วยความหน่วงต่ำกว่า 100 มิลลิวินาที ซึ่งเป็นเป้าหมายที่สถาปัตยกรรมนี้ถูกออกแบบมารองรับ แม้จะไม่ใช่ตัวเลขที่รับประกันได้ภายใต้ทุกระดับภาระงานก็ตาม รูปแบบนี้ยังสามารถนำไปประยุกต์ใช้กับระบบอื่นที่มีสถานะเรียลไทม์ขนาดเล็กอิสระจำนวนมากได้ เช่น ระบบแสดงสถานะออนไลน์ ระบบแก้ไขเอกสารร่วมกัน การประมูลสด หรือห้องเล่นเกมหลายคน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น