Operations & Scaling

จาก “ทำงานได้” ไปสู่ “อยู่รอดได้จริง”

ทุกอย่างก่อนหน้านี้สมมติว่ามี broker ตัวเดียวที่แข็งแรง แต่ production ต่างออกไป: node ล่มได้, queue กลายเป็น bottleneck ได้, connection churn ได้ และ message ที่หลั่งไหลเข้ามาอาจดัน broker จนชน memory limit โมดูลนี้พูดถึงการทำให้ RabbitMQ available, observable และ stable ภายใต้ load จริง

โมดูลนี้ครอบคลุมอะไรบ้าง

บทเรียน	สิ่งที่คุณจะได้เรียน
Clustering & quorum queues	node รวมกันเป็น cluster อย่างไร และทำไม quorum queue คือ HA default ยุคใหม่
Connections & channels	การจัดการ connection บน production, heartbeat และ automatic recovery
Monitoring & management	management UI, metric ที่สำคัญจริง และ memory/disk alarm
Flow control & alarms	เกิดอะไรขึ้นเมื่อ broker โดน overload และออกแบบเลี่ยงอย่างไร

สามคำถามที่ production ถามเสมอ

flowchart TB
  avail["Availability
node ล่ม → message รอดไหม?"] --> hero["RabbitMQ
ที่แข็งแรง"]
  obs["Observability
เห็น queue depth
ก่อนจะเจ็บไหม?"] --> hero
  stab["Stability
เกิดอะไรขึ้นเมื่อ
broker เต็ม?"] --> hero

การ operate RabbitMQ จริง ๆ แล้วคือเรื่องอะไร

Availability — ถ้า node ล่ม queue กับ message ของตัวเองรอดไหม? (Clustering + quorum queue)
Observability — เห็น backlog ที่กำลังโต หรือ consumer ที่ค้าง ก่อน user จะรู้สึกไหม? (Monitoring)
Stability — เมื่อ producer วิ่งเร็วกว่า consumer, broker ปกป้องตัวเองอย่างนุ่มนวลไหม? (Flow control + alarm)