ลดค่า Cloud แล้วธุรกิจเสียหาย!

คำสั่งจาก CFO: “ลด 30% ภายในเดือนนี้”

หลังจากประชุมในตอนที่แล้ว CTO พยายามอธิบายว่าค่า Cloud ที่เพิ่มขึ้น 40% ไม่ใช่ปัญหา เพราะ Cost per Booking ลดลง 16% และ Cloud as % of Revenue ก็ลดลงจาก 11.1% เหลือ 9.3%

แต่ CFO ไม่เชื่อ มองว่าตัวเลขบิลที่เพิ่มขึ้น 6 แสนบาทต่อเดือนคือเงินจริงที่ออกจากบัญชี จึงส่ง email ถึง CTO ตอนเย็นวันนั้นเลย

ลดค่า Cloud 30% ภายในสิ้นเดือนนี้โดยไม่มีข้อแม้

CTO ส่งต่อให้ DevOps Engineer พร้อมข้อความว่า

ผมกังวลว่ามันจะมีปัญหา แต่ไม่มี Data ไปเถียงเขาได้ ทำตามที่สั่งไปก่อน แต่เก็บ config เดิมไว้ด้วยเผื่อต้อง rollback กลับ

DevOps ลงมือปรับ 3 อย่าง

DevOps นั่งดูบิล AWS แล้วหาจุดที่ลดได้เร็วที่สุดได้ 3 อย่าง

รวมประหยัดได้ 6.3 แสนบาท/เดือน ตรงตามเป้า 30% ที่ CFO สั่งพอดี

ดูเผินๆ เหมือนสำเร็จ แต่ทุกอย่างมีราคาที่ต้องจ่าย

อธิบายสิ่งที่ DevOps Engineer ทำ

1. ลด Lambda memory = ลดพลังประมวลผล เพราะใน Lambda นั้น memory กับ CPU ผูกกัน
2. Downsize RDS = ลดขนาดฐานข้อมูล เหมือนย้ายจากออฟฟิศขนาดใหญ่ไปเล็ก
3. ปิด ElastiCache = ปิดระบบ Cache ที่ช่วยให้โหลดข้อมูลเร็ว

ทั้ง 3 อย่างนี้ลดค่าใช้จ่ายได้จริง แต่ก็ลดประสิทธิภาพระบบด้วย

สิ่งที่เกิดขึ้น: ระบบเริ่มพังทีละส่วน

สิ่งที่เกิดขึ้นไม่ได้พังทีเดียว แต่ค่อยๆ สะสมจนระเบิด

สัปดาห์ที่ 1: Lambda ช้าลง

AWS ออกแบบให้ Lambda จัดสรร CPU ตามสัดส่วนของ memory ที่เลือก:

• 128MB = CPU น้อยมาก
• 1024MB = CPU ปานกลาง
• 10240MB = CPU เต็มที่

ดังนั้นการลด memory จาก 1024MB เหลือ 512MB ไม่ใช่แค่ได้ RAM น้อยลง แต่ได้ CPU น้อยลงครึ่งหนึ่ง ด้วย

ทุก function จึงทำงานช้าลง และ duration เพิ่มขึ้นเกือบเท่าตัว ตอนนี้ยังพอรับได้ แต่เริ่มมี timeout ประปรายแล้ว

สัปดาห์ที่ 2: Database เริ่มทำงานหนักขึ้น

RDS ที่ downsize ลงครึ่งหนึ่งต้องรับ query เท่าเดิม ทำให้ CPU พุ่งขึ้น 90%+ ในช่วง peak

เปรียบเทียบ db.r6g.xlarge กับ db.r6g.large

Instance	vCPU	Memory
db.r6g.xlarge	4	32 GB
db.r6g.large	2	16 GB

ลดลงครึ่งหนึ่งทั้ง CPU และ Memory แต่ workload ยังเท่าเดิม

Query ที่เคยใช้เวลา 5ms กลายเป็น 50ms และมีบาง query เริ่ม timeout

สัปดาห์ที่ 3: ทุกอย่างมาถึงจุดจบ

และเมื่อปิด ElastiCache ปุ๊บ ทุก request ที่เคยถูก cache ดักไว้ก็วิ่งตรงไป RDS ทั้งหมด

ปกติเมื่อผู้ใช้ค้นหาโรงแรม ข้อมูลยอดนิยมจะถูกเก็บไว้ใน ElastiCache ซึ่งดึงได้ใน 1-2ms แต่พอไม่มี cache ทุก request ต้องไป query RDS โดยตรง ซึ่งใช้เวลา 50-100ms ต่อครั้ง จากที่ ElastiCache เคยช่วยลด load ของ RDS ได้ 60-80% พอปิดทิ้ง RDS ต้องรับ load เพิ่มขึ้น 3-5 เท่า

Database ที่กำลังหอบอยู่แล้วจากการ downsize โดนอัดซ้ำเข้าไปอีก ผลคือ P95 Response Time พุ่งจาก 200ms เป็น 1,200ms (ช้าลง 6 เท่า)

P95 Response Time คืออะไร?

Percentile 95 (P95) คือเวลาตอบสนองที่ 95% ของ request ทำได้

• P95 = 200ms หมายความว่า 95 ใน 100 requests ใช้เวลาไม่เกิน 200ms
• P95 = 1,200ms หมายความว่า 95 ใน 100 requests ใช้เวลาไม่เกิน 1.2 วินาที

ความแตกต่างที่ผู้ใช้รู้สึกได้

• 200ms: กดปุ๊บ มาปั๊บ รู้สึกลื่นไหล
• 1,200ms: กด… หมุนติ้วๆ… หมุนติ้วๆ… เริ่มหงุดหงิด

คนสมัยนี้รอไม่ได้ แค่หมุนเกิน 1 วินาที เขาก็สลับไปแอป Agoda หรือ Booking.com แล้ว

ทำไมถึงใช้ P95 แต่ไม่ใช้ค่าเฉลี่ย?

เพราะค่าเฉลี่ยซ่อนปัญหาไว้ ถ้า 99 requests ใช้เวลา 100ms แต่มี 1 request ใช้เวลา 10 วินาที ค่าเฉลี่ยจะเป็น 199ms ซึ่งดูดี แต่ P95 จะเป็น 100ms และ P99 จะเป็น 10 วินาที ซึ่งบอกความจริงได้ดีกว่า

ผู้ใช้เปิดหน้า Search แล้วรอ 2-3 วินาทีกว่าจะโหลดเสร็จ หลายคนกดปิดไปเลยแล้วไปใช้แอปคู่แข่งแทน

ผลทางธุรกิจ: Revenue หาย

Product Owner เปิด dashboard วันจันทร์ เห็นตัวเลขที่ทำให้หน้าซีด

Conversion Rate คือเปอร์เซ็นต์ของคนที่เข้ามาดูแล้วจองโรงแรมจริง จากผู้เข้าชม 142,857 คน เดิม จองจริง 50,000 คน (Conversion Rate = 35%) แต่หลังระบบช้าลง Conversion เหลือ 28% เท่ากับว่าจองจริงแค่ 40,000 คน หายไป 10,000 นั่นแปลว่า Revenue หายไปถึง 4.5 ล้านบาท

Metric	ก่อนลด	หลังลด	เปลี่ยนแปลง
Response Time (P95)	200ms	1,200ms	เพิ่มขึ้น 500%
Conversion Rate	35%	28%	ลดลง 7%
Bookings	50,000	40,000	ลดลง 20%
Revenue	22.5 ล้านบาท	18 ล้านบาท	ลดลง 20% (4.5 ล้านบาท)

ทำไม Conversion ถึงลด?

เพราะผู้ใช้ไม่รอ งานวิจัยหลายชิ้นชี้ตรงกันว่า:

• ทุกๆ 100ms ที่เว็บช้าลง → Conversion ลดลงราว 1%
• ถ้าเว็บโหลดนานกว่า 3 วินาที → 53% ของผู้ใช้จะปิดไปเลย

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

ประหยัด 6.3 แสนบาท แต่เสีย Revenue 4.5 ล้านบาท

มาดูภาพรวมผลกระทบทางการเงินทั้งหมด

ผลกระทบสุทธิต่อเดือน (บาท)

ดูจาก Waterfall Chart จะเห็นชัดว่าแท่งสีเขียว (ค่า Cloud ที่ประหยัดได้ 6.3 แสนบาท) เล็กจิ๋วเมื่อเทียบกับแท่งสีแดง (Revenue ที่หายไป 4.5 ล้านบาท) ผลลัพธ์สุทธิติดลบ 3.87 ล้านบาทต่อเดือน

ROI ของ Cost Optimization ครั้งนี้

CFO อยากประหยัดเงิน 6.3 แสนบาท แต่สิ่งที่แลกมาคือความเสียหายระดับ 4.5 ล้านบาท

• สิ่งที่ได้มา: เงินสด 630,000 บาท (ค่า Cloud ที่ลดได้)
• สิ่งที่เสียไป: โอกาสขาย 4,500,000 บาท (Revenue ที่หายไป)
• ผลขาดทุนสุทธิ: ขาดทุน 3,870,000 บาท

ROI (Return on Investment) = (ผลตอบแทน − ต้นทุน) ÷ ต้นทุน × 100%

ROI = (630,000 − 4,500,000) ÷ 630,000 × 100% = ROI ติดลบ 614%

แปลเป็นภาษาชาวบ้านคือ ทุก 1 บาทที่ประหยัดค่า Cloud ได้ ทำให้ HotelGO เสีย Revenue ไป 7.14 บาท

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

มองในมุม Unit Economics

จำตัวเลขจากตอนที่แล้วได้ไหม? HotelGO มีกำไรต่อ Booking อยู่ที่ 408 บาท (Revenue 450 บาท − Cloud Cost 42 บาท)

การ optimize ครั้งนี้ทำให้ Cost per Booking ลดจาก 42 บาท เหลือ ~36 บาท ประหยัดได้ 6 บาท ต่อ Booking ดูเหมือนดี แต่…

• ประหยัดได้: 6 บาท × 40,000 Bookings = 240,000 บาท
• ลูกค้าหายไป: 10,000 คน × กำไร 408 บาท = 4,080,000 บาท

เรากำลังก้มเก็บเหรียญสิบบาท (ค่า Cloud) จนทำแบงค์ห้าร้อยร่วงจากกระเป๋า (Revenue) โดยไม่รู้ตัว

สรุป: ลดค่า Cloud ≠ ดีเสมอไป

Product Owner พูดในที่ประชุมหลังเห็นตัวเลขว่า

เราประหยัดค่า Cloud ได้ 6.3 แสนบาท แต่ทำให้ลูกค้าหนีไป 4.5 ล้านบาท นี่ไม่ใช่ Optimization นี่คือการทำลายธุรกิจ

บทเรียนจากตอนนี้

บทเรียน	รายละเอียด
ลดค่า Cloud ≠ ดีเสมอไป	ต้องดูว่ากระทบ Performance และ Revenue หรือไม่
Performance → Conversion → Revenue	ระบบช้าลง = ลูกค้าหนี = รายได้หาย
ต้องมี Guardrails	กำหนดเส้นที่ห้ามข้ามไว้ก่อน แล้วค่อย optimize

Guardrails คือเส้นแบ่งที่กำหนดไว้ล่วงหน้าว่า “ห้ามข้าม” ใช้ป้องกันไม่ให้ optimization ไปทำลายสิ่งที่สำคัญกว่า ตัวอย่างเช่น:

• Response Time P95 ≤ 500ms
• Error Rate ≤ 0.1%
• Availability ≥ 99.9%

Optimize ได้เต็มที่ แต่ถ้าชน Guardrails ต้องหยุดทันที ไม่ว่าจะประหยัดได้เท่าไหร่ก็ตาม