เว็บเร็วขึ้น โตได้โดยไม่จ่ายเกินจำเป็น ตอนที่ 5: งานไหนให้รอคิว และทำอย่างไรไม่ให้งานหาย

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

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

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

งานใดควรอยู่หน้าจอ งานใดยอมให้ตามมา

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

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

ปิดช่องว่างระหว่างบันทึกธุรกรรมกับส่งงานเข้าคิว

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

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

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

งานส่งซ้ำต้องไม่สร้างผลทางธุรกิจซ้ำ

คิวบางชนิด เช่น SQS แบบ standard มีการส่งอย่างน้อยหนึ่งครั้ง จึงอาจส่งรายการเดิมซ้ำ การลองใหม่หลัง timeout ก็อาจเกิดขณะที่ครั้งแรกทำสำเร็จแล้ว เราจึงต้องแยก “ไม่เห็นคำตอบ” ออกจาก “ไม่ได้ทำงาน” โดยเฉพาะการเก็บเงิน จองสินค้า หรือออกเอกสารที่มีเลขไม่ควรซ้ำ

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

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

คิวจะระบายทันเมื่อไร

สมมติงานเอกสารเข้า 120 งานต่อวินาที ตัวประมวลผลงานหรือ worker ทำจบ 100 งานต่อวินาทีตลอด 60 วินาที งานค้างเพิ่ม 1,200 งาน โดยไม่มี retry หรืองานถูกทิ้ง จากนั้นงานเข้าเหลือ 80 งานต่อวินาทีและทำได้ 100 เท่าเดิม คิวจะลดสุทธิ 20 งานต่อวินาที จึงใช้เวลาอีก 60 วินาทีเพื่อล้างงานค้างส่วนนี้

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

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

จำกัดงานเข้าและจำนวนงานพร้อมกันให้ปลายทางรับไหว

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

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

ลองใหม่อย่างมีงบ ไม่ให้กลายเป็นพายุงาน

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

ถ้าสามชั้นต่างอนุญาตให้ลองรวมชั้นละ 3 ครั้ง ในกรณีที่ทุกชั้นลองซ้ำเต็มจำนวน คำขอเดียวอาจกระตุ้นปลายทางถึง 27 ครั้ง ตัวเลขนี้เป็นกรณีคำนวณเลวร้าย ไม่ใช่ผลที่เกิดทุกครั้ง และคำว่า 3 ครั้งต้องชัดว่ารวมครั้งแรกแล้ว ไม่ใช่ลองใหม่อีก 3 ครั้งซึ่งจะกลายเป็นฐาน 4

งานที่เกินเกณฑ์อาจแยกไปคิวสำหรับตรวจหรือ dead-letter queue ต้องมีเจ้าของ อายุเก็บ และวิธีนำกลับที่ไม่ข้ามการป้องกันซ้ำ การย้ายออกจากคิวหลักทำให้กราฟหลักสวยขึ้นได้ แต่ลูกค้ายังไม่ได้งาน จึงต้องนับความล้มเหลวนี้ในผลบริการและต้นทุนด้วย

สั่งหยุดและกู้กลับต้องลองก่อนวันที่จำเป็น

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

งานที่หมดประโยชน์กับงานที่ห้ามหายต้องมีกติกาต่างกัน

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

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

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

เมื่อแยกงานได้ชัดแล้ว เราจึงคุยเรื่องตำแหน่งที่ให้มันทำงานได้ดีขึ้น บางส่วนเหมาะอยู่ใกล้ผู้ใช้ บางส่วนต้องอยู่ใกล้ข้อมูล และบางงานควรหลีกเลี่ยงการเรียก AI ทุกครั้ง ตอนถัดไปจะใช้ขอบเขตเหล่านี้เลือก edge และ serverless โดยไม่ฝากความถูกต้องไว้กับชื่อเทคโนโลยี

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

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

• AWS Well-Architected: Fail fast and limit queues
• AWS Prescriptive Guidance: Transactional outbox pattern
• AWS SQS: At-least-once delivery
• AWS Builders’ Library: Making retries safe with idempotent APIs
• AWS Well-Architected: Control and limit retry calls