เว็บเร็วขึ้น โตได้โดยไม่จ่ายเกินจำเป็น ตอนที่ 6: Edge กับ serverless ควรวางงานไว้ตรงไหน

ภาพปกสร้างด้วย AI เพื่ออธิบายร้านสมมติ ไม่ใช่ภาพระบบที่ติดตั้งหรือผลทดสอบจริง

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

Edge กับ serverless ช่วยจัดวางและให้บริการงานบางชนิดได้สะดวกขึ้น แต่ตอบคนละคำถาม Edge พูดถึงตำแหน่งที่ทำงานใกล้ผู้ใช้หรือเครือข่าย ส่วน serverless เป็นรูปแบบที่ผู้ให้บริการรับภาระจัดสรรทรัพยากรบางส่วน เราควรเลือกจากเส้นทางงาน ความถูกต้อง ขีดจำกัด และต้นทุน ไม่ใช้ชื่อเรียกเป็นหลักฐานว่าขยายได้ไม่จำกัด

วางงานใกล้สิ่งที่มันต้องคุยด้วย

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

ถ้าระบบใหม่เพิ่ม edge gateway แล้ว gateway ยังเรียกแอปเดิมซึ่งเรียกฐานข้อมูลเดิมตามลำดับเดิม ต้องวัดว่าชั้นใหม่ลดงานหรือแค่เพิ่มอีกช่วงเครือข่าย การตรวจสิทธิซ้ำอาจมีเหตุผล แต่ต้องออกแบบขอบเขตและการส่งต่อข้อมูลไม่ให้เปิดช่องเลี่ยงตรวจเมื่อเรียกต้นทางตรง

Serverless ลดงานดูแลบางส่วน ไม่ได้ลบเพดานระบบ

ผู้ให้บริการอาจดูแลเครื่อง การแยกสภาพแวดล้อม และการขยายหน่วยทำงานให้ แต่ผู้พัฒนายังต้องดูแลโค้ด การพึ่งบริการอื่น สิทธิ ข้อมูล และผลเมื่อเกินขีดจำกัด รูปแบบคิดเงินอาจสัมพันธ์กับจำนวนคำขอ เวลา CPU ระยะเวลาทำงาน หรือทรัพยากรอื่นตามผลิตภัณฑ์ ต้องอ่านฐานเรียกเก็บจริงก่อนคำนวณ

ตัวอย่างเอกสาร Cloudflare Workers แยกเวลา CPU ออกจากเวลารอ I/O และกำหนดขอบเขตของหน่วยความจำกับการเรียกต่อไว้ ข้อมูลนี้ช่วยให้เรารู้ว่าคำว่า duration ต้องอ่านในบริบทผลิตภัณฑ์ ไม่ควรยกเกณฑ์ของบริการหนึ่งไปใช้กับอีกบริการหนึ่ง หรือถือว่าเวลารอเครือข่ายไม่มีต้นทุนทุกชนิด

แม้แพลตฟอร์มขยายหน่วยรันให้ได้ บริการที่ถูกเรียกต่อยังอาจเต็ม เช่น ฐานข้อมูล pool เล็ก API คู่ค้ามี quota หรือบริการ AI รับงานไม่ทัน ต้องจำกัดจำนวนพร้อมกันและมีเวลารอรวม ไม่เปิดให้จำนวนครั้งเรียกใช้งานที่เพิ่มตามโหลดกระแทกปลายทางโดยไม่มีเพดาน

เรื่องการเริ่มงานก็ต้องตรวจตาม runtime และผลิตภัณฑ์ ไม่รับรองว่า serverless ทุกแบบไม่มี cold start และไม่ถือว่าการเก็บข้อมูลไว้ในหน่วยความจำจะอยู่ถาวร งานที่ต้องคงอยู่ต้องบันทึกในที่เหมาะสม พร้อมพิจารณาการติดตั้งเวอร์ชันใหม่และการย้ายงานของแพลตฟอร์ม

Durable Objects เหมาะกับการประสานสถานะตามขอบเขต

Cloudflare Durable Objects เป็นตัวอย่างการรวมโค้ดกับสถานะของ object ที่ระบุได้ แต่ละ object มีขอบเขตข้อมูลและที่เก็บของตนซึ่งรองรับความสอดคล้องตามเอกสาร เหมาะจะพิจารณาเมื่องานมีจุดที่ต้องประสาน เช่น ห้องสนทนาหนึ่งห้อง หรือสถานะเฉพาะหน่วยธุรกิจที่แบ่งกันได้จริง ไม่ใช่เพราะอยากเปลี่ยนฐานข้อมูลทุกชนิดให้เป็น object

หลาย object สามารถกระจายงานที่เป็นอิสระกัน แต่หากทุกคำขอของร้านวิ่งไป object เดียว งานร้อนยังรวมอยู่จุดเดียว คำว่า scale out จึงไม่ได้แปลว่า key เดียวรับงานได้ไม่จำกัด เอกสารมีข้อจำกัดต่อ object และ throughput ยังขึ้นกับงานที่ทำ บทความนี้ไม่ใช้ soft limit ของผู้ให้บริการเป็นคำรับรองกำลังร้าน

Single-threaded ไม่ได้แปลว่าไม่มีปัญหาตรรกะจากงานที่คั่นกันระหว่างรอ asynchronous I/O และความสอดคล้องในที่เก็บของ object หนึ่งไม่ได้สร้างธุรกรรมอะตอมครอบทุก object และฐานข้อมูลภายนอก การจองสินค้าหลายรายการจึงต้องพิจารณา invariant หรือเงื่อนไขที่ต้องจริงร่วมกันก่อนแยก key

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

ใช้ AI ตรงที่ช่วยงาน โดยไม่วางไว้ขวางการซื้อทุกครั้ง

ร้านสมมติอาจมีผู้ช่วยค้นคู่มืออะไหล่ แต่การดูหน้าสินค้าไม่จำเป็นต้องเรียกโมเดลทุกครั้ง แยกการใช้ AI ช่วยเขียนโค้ดหรือเตรียมเนื้อหาล่วงหน้าออกจาก inference ที่ต้องรันขณะลูกค้ารอ แบบหลังเพิ่ม dependency เวลาแฝง quota และค่าใช้จ่ายต่อการใช้งาน ต้องมีเหตุผลว่าผู้ใช้ได้ประโยชน์อะไรที่การค้นธรรมดาทำไม่ได้เพียงพอ

การนำ gateway ไป edge ไม่ได้ทำให้โมเดลภายนอกอยู่ข้างผู้ใช้ทุกคน ถ้าต้องส่งข้อมูลไป inference หรือค้นเอกสารอีกภูมิภาค ระยะและจำนวนรอบยังอยู่ วัดเวลาตั้งแต่ผู้ใช้เริ่มงานจนได้รับคำตอบที่ใช้ได้ รวมงานค้นบริบท กรองสิทธิ และตรวจผล ไม่วัดเฉพาะเวลาได้ token แรกแล้วถือว่างานเสร็จ

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

คุมงบและสิทธิของงาน AI เหมือนบริการที่ใช้ทรัพยากร

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

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

วัดทางเลือกก่อนผูกระบบทั้งชุด

เริ่มทดลองกับเส้นทางที่แยกได้และย้อนกลับได้ เก็บทั้ง latency ที่ผู้ใช้เห็น ค่าเรียกต่อ ข้อผิดพลาด และภาระผู้ดูแล ทดสอบเมื่อบริการปลายทางไม่พร้อม เมื่อ key เดียวร้อนมาก และเมื่อ quota หมด การทดลองกับงานกระจายสวยงามอย่างเดียวจะไม่ตอบคำถามที่ยากที่สุดของร้าน

ตรวจวิธีนำข้อมูลออก รูปแบบ API และเวลาที่ทีมต้องใช้หากเปลี่ยนแพลตฟอร์ม บริการจัดการให้มีคุณค่าจากงานที่ทีมไม่ต้องทำ แต่มีต้นทุนการเรียนรู้และการผูกกับความสามารถเฉพาะเช่นกัน ความย้อนกลับได้ไม่จำเป็นต้องแปลว่าเปลี่ยนผู้ให้บริการได้ในวันเดียว แต่ควรมีแผนที่เป็นจริงและเห็นค่าใช้จ่าย

ตำแหน่งข้อมูลและการสังเกตระบบต้องอยู่ในแบบด้วย

การวางจุดประมวลผลหลายพื้นที่ไม่ได้ตอบเองว่าข้อมูลส่วนตัวถูกเก็บ ส่งต่อ หรือบันทึก log ที่ใด ตรวจเส้นทางตั้งแต่ browser ผ่าน gateway ไปฐานข้อมูล โมเดล และระบบเฝ้าดู ให้ตรงเงื่อนไขสัญญาและข้อกำหนดที่กิจการต้องปฏิบัติ ไม่ใช้คำว่า edge เป็นคำรับรองเรื่องถิ่นที่อยู่ของข้อมูล

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

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

เอกสารผู้ให้บริการที่อ้างอิงตรวจเมื่อ 18 ตุลาคม 2569 ขีดจำกัด แผน และรูปแบบคิดเงินเปลี่ยนได้ ก่อนลงมือทีมต้องตรวจรุ่นและเงื่อนไขที่ใช้จริงอีกครั้ง ตอนต่อไปจะนำจำนวนคำขอ เวลาเครื่อง งานดูแล และการทำซ้ำทั้งหมดมาวางในต้นทุนต่อรายการ เพื่อดูว่าการโตของร้านช่วยให้คุ้มขึ้นหรือเพียงทำให้บิลโตตาม

อ่านต้นทางและขอบเขตของตัวอย่าง

เอกสารต่อไปนี้เป็นแหล่งอธิบายแนวคิดและข้อจำกัด ตรวจเมื่อ 18 ตุลาคม 2569 ตัวเลขร้านสมมติและข้อเสนอการเลือกทางเป็นการเรียบเรียงของผู้เขียน ไม่ใช่ราคา ผลทดสอบ หรือคำรับรองของแหล่งอ้างอิง ก่อนนำไปตั้งค่าจริงต้องตรวจรุ่น แผน และเงื่อนไขที่ใช้อยู่

• Cloudflare: What are Durable Objects?
• Cloudflare: Durable Objects limits
• Cloudflare: Workers limits
• Cloudflare: Workers AI limits