ทำไมการใช้ Postgres ทำ Message Queue ถึงเป็นกับดักที่ทำให้นอนไม่หลับตอนตี 3

ทำไมการใช้ Postgres เป็นคิวงานถึงเป็นกับดักที่น่ากลัวตอนตี 3

เมื่อคุณเริ่มต้นเขียนโปรแกรมใหม่ๆ คำแนะนำยอดฮิตที่คุณมักจะได้ยินคือ "แค่ใช้ Postgres ก็พอแล้ว" เพราะมันเป็นฐานข้อมูลที่ครอบจักรวาลและใช้งานง่าย แต่คุณรู้ไหมว่าการนำ Postgres (ระบบจัดการฐานข้อมูลแบบเชิงสัมพันธ์) มาทำหน้าที่เป็น Message Queue (ระบบจัดคิวงานเพื่อให้โปรแกรมทยอยทำตามลำดับ) อาจกลายเป็นระเบิดเวลาที่รอวันทำงานตอนตี 3 ได้

ลองจินตนาการว่าคุณมีร้านอาหารที่เชฟทำหน้าที่ทั้งปรุงอาหารและจดออเดอร์ลงสมุดเล่มเดียวกัน หากลูกค้าสั่งอาหารเข้ามาพร้อมกัน 1,000 รายการ เชฟที่มัวแต่ก้มหน้าก้มตาเขียนสมุดจนไม่มีเวลาปรุงอาหารจะเกิดอะไรขึ้น? ระบบของคุณก็เช่นกัน เมื่อฐานข้อมูลต้องรับภาระทั้งงานหลักและงานคิวพร้อมกัน มันจะเริ่มช้าลงจนสุดท้ายระบบทั้งหมดก็หยุดทำงาน

นี่คือ SPOF หรือ Single Point of Failure (จุดที่หากพังจุดเดียว ระบบทั้งหมดจะพังตาม) ที่คุณสร้างขึ้นมาโดยไม่รู้ตัว ในฐานะมือใหม่ คุณอาจมองว่ามันสะดวกเพราะไม่ต้องติดตั้งเครื่องมือเพิ่ม แต่เมื่อโปรเจกต์ของคุณเติบโตขึ้น ความสะดวกนี้จะกลายเป็นหนี้ทางเทคนิคที่คุณต้องชดใช้ด้วยการตื่นมาแก้บั๊กในยามวิกาล

ทำความเข้าใจกลไกภายใน: ทำไม Postgres ถึงไม่ใช่คิวงานที่ดี

หลายคนเลือกใช้คำสั่ง SELECT ... FOR UPDATE SKIP LOCKED เพื่อจองงานในคิว วิธีนี้ดูเหมือนจะฉลาดและเรียบง่ายมากในตอนแรก แต่มันเป็นการฝืนธรรมชาติของ MVCC (Multi-Version Concurrency Control หรือระบบจัดการข้อมูลหลายเวอร์ชันใน Postgres) ซึ่งออกแบบมาเพื่อจัดการข้อมูลที่นิ่ง ไม่ใช่ข้อมูลที่ถูกเขียนทับไปมาอย่างรวดเร็วเหมือนคิวงาน

เมื่อคุณจัดการคิวในฐานข้อมูล คุณจะเกิดการ Update ข้อมูลซ้ำๆ ทุกครั้งที่มีการดึงงาน ทำงานเสร็จ หรือแม้แต่การลองใหม่หากงานล้มเหลว การกระทำเหล่านี้ทำให้ฐานข้อมูลต้องสร้างแถวข้อมูลใหม่ขึ้นมาตลอดเวลา ส่งผลให้เกิดสิ่งที่เรียกว่า Table Bloat (ตารางบวม) และ Index Fragmentation (ดัชนีแตกกระจาย) จนระบบทำงานหนักขึ้นเรื่อยๆ

ลองดูตัวอย่างการทำงานของคิวในฐานข้อมูลที่อาจทำให้ฐานข้อมูลคุณ "หายใจไม่ออก" ดังนี้:

-- ตัวอย่างการดึงงานในคิวแบบที่คนนิยมใช้
-- แต่ละครั้งที่รัน คำสั่งนี้จะสร้าง Transaction ใหม่
-- และทำให้ Postgres ต้องจัดการกับไฟล์ข้อมูลมหาศาล
SELECT * FROM jobs 
WHERE status = 'pending' 
ORDER BY created_at 
FOR UPDATE SKIP LOCKED LIMIT 1;

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

เมื่อตัวเลขไม่โกหก: ความต่างของประสิทธิภาพ

หากเราพูดถึงเรื่อง Throughput (ปริมาณงานที่ระบบทำได้ในหนึ่งหน่วยเวลา) ความแตกต่างระหว่างการใช้ฐานข้อมูลทำคิวงานกับระบบที่เป็น Message Broker โดยเฉพาะนั้นห่างกันราวฟ้ากับเหว จากผลการทดสอบพบว่า Postgres ทำงานได้สูงสุดที่ประมาณ 660 ข้อความต่อวินาที ในขณะที่ระบบอย่าง RabbitMQ สามารถทำได้ถึง 25,000 ข้อความต่อวินาที

นี่ไม่ใช่แค่เรื่องของความเร็วเพียงอย่างเดียว แต่มันคือเรื่องของความสามารถในการรองรับโหลดที่เพิ่มขึ้น (Scalability) หากคุณใช้ฐานข้อมูลเป็นคิว คุณกำลังจำกัดศักยภาพของโปรเจกต์ตัวเองไว้ที่เพดานต่ำๆ ตั้งแต่วันแรก ในขณะที่บริการอย่าง Amazon SQS (Simple Queue Service) สามารถขยายตัวได้แทบไม่มีขีดจำกัดโดยไม่ต้องให้คุณไปยุ่งกับการตั้งค่าโครงสร้างพื้นฐานเลย

ลองเปรียบเทียบการเลือกเครื่องมือในการทำงานดูครับ:

• การใช้ Postgres: เหมือนพยายามขนของด้วยรถมอเตอร์ไซค์คันเดียว ทั้งขนของหลักและของฝาก สุดท้ายรถก็พังและขนของไม่ได้ทั้งคู่
• การใช้ Message Broker (เช่น SQS/RabbitMQ): เหมือนการมีบริษัทขนส่งแยกต่างหากที่จัดการเรื่องคิวงานโดยเฉพาะ ทำให้รถหลักของคุณวิ่งส่งของได้อย่างเต็มที่

การเลือกใช้เครื่องมือที่ถูกออกแบบมาเพื่อหน้าที่นั้นๆ โดยเฉพาะ คือหัวใจสำคัญของการเป็นโปรแกรมเมอร์ที่เก่ง คุณไม่จำเป็นต้องสร้างทุกอย่างเอง แต่ต้องรู้จักเลือกใช้ Managed Services (บริการที่มีผู้ดูแลให้) เพื่อลดภาระงานดูแลรักษา (Ops) ของตัวคุณเองลง

วงจรหายนะ: เมื่อคิวพัง ฐานข้อมูลก็พังตาม

จุดที่น่ากลัวที่สุดคือ Feedback Loop (วงจรป้อนกลับ) ที่จะเกิดขึ้นตอนตี 3 เมื่อกระบวนการทำงานในคิวของคุณมีปัญหา มันจะส่งผลกระทบย้อนกลับไปที่ฐานข้อมูลทันที เพราะทั้งสองอย่างคือ "สิ่งเดียวกัน" เมื่อฐานข้อมูลเริ่มช้า คิวงานก็จะค้าง เมื่อคิวค้าง ระบบงานเบื้องหลังก็หยุดทำงาน และเมื่อระบบงานหยุดทำงาน ผู้ใช้ก็จะแห่กันมากดรีเฟรชหน้าเว็บ ทำให้ฐานข้อมูลรับภาระหนักขึ้นไปอีก

นอกจากนี้ยังมี Silent Killer (เพชฌฆาตเงียบ) อย่างเรื่องของการเชื่อมต่อ (Connection) ทุกครั้งที่มีการดึงงานจากคิว Postgres จะต้องสร้าง Process ใหม่ขึ้นมาเพื่อจัดการ connection นั้น หากคุณมี Worker หลายตัวที่คอย polling งานอยู่ตลอดเวลา คุณอาจจะพบว่า Connection Pool ของคุณเต็ม จนผู้ใช้งานจริงไม่สามารถเข้าถึงฐานข้อมูลได้

สถานการณ์ที่มักเกิดขึ้นตอนตี 3 คือ:

1. คิวงานเริ่มค้างเพราะงานประมวลผลไม่ทัน
2. Worker พยายามดึงงานซ้ำๆ จนฐานข้อมูลหน่วง
3. ฐานข้อมูลช้าจน User เข้าใช้งานไม่ได้
4. คุณได้รับแจ้งเตือนจากระบบ Monitor ว่าแอปล่ม ทั้งที่จริงๆ คือฐานข้อมูลติดคอขวด

ทางเลือกที่ชาญฉลาดกว่าสำหรับโปรแกรมเมอร์มือใหม่

สำหรับคนที่กำลังฝึกเขียนโค้ดและสร้างโปรเจกต์แรกๆ ผมไม่ได้บอกว่าห้ามใช้ Postgres แต่ผมอยากให้คุณแยก "หน้าที่" ออกจากกันให้ชัดเจน หากโปรเจกต์ของคุณเริ่มมีงานเบื้องหลัง (Background Jobs) เยอะขึ้น ให้ลองมองหาเครื่องมือที่เหมาะสมแทนการยัดทุกอย่างลงในตารางเดียว เช่น Redis หรือบริการ Queue บนคลาวด์

การฝึกเขียนโปรแกรมที่ดีไม่ใช่การทำทุกอย่างให้จบในที่เดียว แต่คือการรู้จัก Architecture (สถาปัตยกรรมระบบ) ที่ดี การแยกส่วนประกอบ (Decoupling) ออกจากกันจะช่วยให้คุณสามารถอัปเกรดหรือแก้ไขปัญหาได้ง่ายขึ้นโดยไม่กระทบกับส่วนอื่นๆ ของระบบ นี่คือทักษะที่จะแยกโปรแกรมเมอร์มือสมัครเล่นออกจากมืออาชีพ

หากคุณต้องการเริ่มต้นสร้างระบบงานเบื้องหลัง ลองทำตามขั้นตอนเหล่านี้:

1. เริ่มจากงานที่ง่ายและไม่ต้องใช้คิวงานก่อน เพื่อให้เข้าใจ Logic การเขียนโปรแกรม
2. เมื่อเริ่มมีงานที่ต้องใช้เวลานาน ให้ลองศึกษาการใช้ Background Worker (เช่น BullMQ ใน Node.js)
3. ทดสอบระบบด้วยการจำลองข้อมูลจำนวนมาก เพื่อดูว่าระบบของคุณรับมือได้แค่ไหน

สรุป: อย่าสร้างปัญหาที่คุณต้องมานั่งแก้ตอนตี 3

การใช้ Postgres เป็น Message Queue อาจจะดูเหมือนทางลัดที่น่าสนใจในตอนที่คุณทำ MVP (Minimum Viable Product หรือผลิตภัณฑ์เวอร์ชันที่เล็กที่สุดที่ใช้งานได้จริง) แต่ในระยะยาว มันคือระเบิดเวลาที่พร้อมจะทำงานทันทีที่ระบบของคุณได้รับความนิยมจริงๆ การเป็นโปรแกรมเมอร์ที่ดีคือการวางแผนเผื่ออนาคตและเลือกเครื่องมือที่เหมาะสมกับงาน

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

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

ที่มา: Postgres as your message queue is a SPOF you'll regret at 3am — DEV Community