ข้ามไปยังเนื้อหาหลัก

เว็บล่มตอนแคมเปญ วิธีเตรียมระบบรับทราฟฟิกพุ่ง 10 เท่า

2 กรกฎาคม 2026 อ่าน 4 นาที
แชร์
LINEFacebookXLinkedInTelegramอีเมล
วิศวกรมองกราฟทราฟฟิกที่พุ่งสูงบนจอ ประกอบบทความเตรียมระบบรับทราฟฟิกช่วงแคมเปญ
DEVOPS

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

สัปดาห์ที่ 1: หาว่าระบบตายที่ตรงไหน (Load Test)

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

สัปดาห์ที่ 2: แก้คอขวดที่คุ้มที่สุดก่อน

  • Cache หน้าที่คนเข้าเยอะ หน้าสินค้า/แคมเปญที่เนื้อหาเหมือนกันทุกคน ไม่ควรถึง database เลย
  • CDN สำหรับรูปและไฟล์ ทราฟฟิกส่วนใหญ่คือรูป ให้ CDN รับแทนเซิร์ฟเวอร์
  • แก้ query ช้า จาก load test จะเห็นชัดว่าตัวไหน ใส่ index หรือ cache ผลลัพธ์
  • แยกงานหนักออกจากเส้นทางหลัก ส่งอีเมล ออกใบเสร็จ ให้ไปทำใน queue หลังบ้าน

สัปดาห์ที่ 3: Auto-scaling และแผนสำรอง

ตั้งระบบเพิ่มเครื่องอัตโนมัติเมื่อโหลดถึงเกณฑ์ แต่อย่าพึ่งอย่างเดียว เพราะ scaling ใช้เวลา 2–5 นาที ซึ่งนานพอให้ล่มได้ วันแคมเปญจริงควร "อุ่นเครื่อง" เพิ่ม capacity ล่วงหน้าก่อนเวลาเริ่ม และเตรียม fallback เผื่อไว้ ถ้าระบบแนะนำสินค้าล่ม หน้าขายหลักต้องยังทำงานต่อได้

"ระบบที่รอด 11.11 ไม่ใช่ระบบที่ไม่มีอะไรพัง แต่คือระบบที่พังทีละชิ้นโดยลูกค้าไม่รู้สึก"

สัปดาห์ที่ 4: ซ้อมวันจริง

  • รัน load test รอบสุดท้ายที่ 2 เท่าของทราฟฟิกที่คาด เผื่อไว้เสมอ
  • ตั้ง dashboard เดียวที่ทุกคนดู ทั้ง response time, error rate และออเดอร์/นาที
  • กำหนดคนเวร ช่องทางสื่อสาร และเกณฑ์ตัดสินใจล่วงหน้า (เช่น error เกิน 1% = เปิดโหมดลดฟีเจอร์)
  • ซ้อม rollback ถ้า deploy อะไรพลาดวันนั้น ต้องย้อนกลับได้ใน 5 นาที

ถ้ามีเวลาแค่ 1 สัปดาห์

ตัดเหลือ 3 อย่างที่ผลต่อความรอดสูงสุด คือเปิด CDN รับรูปและไฟล์ static, cache หน้าแคมเปญที่เนื้อหาเหมือนกันทุกคน, และอุ่นเครื่องเพิ่ม capacity ล่วงหน้าก่อนเวลาเริ่มแทนการรอ auto-scale ทำสามอย่างนี้ไม่ทำให้ระบบสมบูรณ์ แต่ยกโอกาสรอดขึ้นมากที่สุดต่อชั่วโมงที่ลงแรง

หลังแคมเปญ: อย่าลืมลดขนาดลง

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

อยากให้มีทีมช่วย load test และเตรียมระบบก่อนแคมเปญ ดูรายละเอียดที่ Infrastructure & DevOps

แท็กScalabilityPerformanceDevOps
ทีม CODENIVERSE
Digital Tech Agency ที่แชร์สิ่งที่เรียนรู้จากงานจริงด้าน AI, DevOps, SEO และการเปลี่ยนผ่านดิจิทัล
คุยกับเรา →

บทความที่เกี่ยวข้อง

ดูบทความทั้งหมด →

ระบบช้า ค่า Cloud บานปลาย?

เล่าปัญหา infra ที่เจอมาได้เลย เราช่วยหาจุดที่กินเงินเกินจำเป็นและวิธีลด พร้อมประเมินแนวทางกับงบคร่าวๆ ฟรี ไม่มีข้อผูกมัด