ประหยัดค่า Cloud 2 หมื่น เสียรายได้ 1.2 แสน

สมมุติว่ามีบริษัท FreshCart ที่ทำธุรกิจ e-commerce ขายของสดและอาหารแช่แข็ง เป็น SME ที่กำลังเติบโตอย่างรวดเร็ว มีทีมงานประมาณ 40 คน

วันหนึ่ง CFO เปิดประชุมด้วยกราฟที่ทำให้ทุกคนในห้องเงียบกริบ

ห้องประชุม FreshCart — “ค่าใช้จ่ายพุ่ง 40%!”

CFO ของ FreshCart ยืนอยู่หน้าจอโปรเจคเตอร์ ชี้ไปที่กราฟเส้นที่พุ่งขึ้นอย่างน่ากังวล

และพูดว่า

ดูตัวเลขนี้สิ จาก 50,000 บาทในเดือนมกราคม พุ่งมาเป็น 70,000 บาทในเดือนมีนาคม — เพิ่มขึ้นเดือนละหมื่น! ถ้าปล่อยให้โตแบบนี้ต่อไป สิ้นปีเราจ่าย cloud เป็นล้านแน่!

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

หลังจากนั้น CFO หันมามองทีม IT แล้วพูดประโยคที่เปลี่ยนชะตากรรมของบริษัทว่า

ผมต้องการให้ลดค่า Cloud ลง 30% ภายใน 2 เดือน!

CTO รับคำสั่ง “ลด 30%”

CTO กลับไปนั่งทำงานกับทีม และวิเคราะห์ว่าจะลดค่าใช้จ่ายจากส่วนไหนได้บ้าง หลังจากประชุมกับทีม infrastructure หลายรอบก็ได้รายการที่จะลด:

มาดูกันว่าแต่ละ action ส่งผลกระทบอย่างไร:

ขั้นตอนที่ 1: Downsize ระบบ Cache

ลดขนาด ElastiCache (Redis) จาก cache.r6g.large เป็น cache.t3.micro ประหยัดได้ 4,000 บาท/เดือน

ผลกระทบ: Memory ลดจาก 13 GB เหลือ 0.5 GB ทำให้ cache eviction เกิดบ่อยขึ้นมาก cache hit rate ลดจาก 85% เหลือประมาณ 40% ส่งผลให้ database load เพิ่มขึ้นประมาณ 4 เท่า

ขั้นตอนที่ 2: Downsize Database

ลดขนาด database จาก db.r6g.large เป็น db.t3.medium ประหยัดได้ 6,000 บาท/เดือน

ผลกระทบ: Memory ลดจาก 16 GB เหลือ 4 GB ทำให้ buffer pool เล็กลง 4 เท่า และ CPU เป็นแบบ burstable ที่จะ throttle เมื่อใช้เกิน credit รวมกับ load ที่เพิ่มขึ้นจากการ downsize cache ทำให้ query ที่เคยใช้เวลา 50 ms กลายเป็น 150-200 ms ในช่วง peak

ขั้นตอนที่ 3: ลด Server จาก 3 เป็น 2 เครื่อง

ลด server จาก 3 เป็น 2 เครื่อง (ใช้ m5.xlarge) ประหยัดได้ 6,000 บาท/เดือน

ผลกระทบ: Capacity ลดลง 33% ในขณะที่แต่ละ Pod ต้องรอ database นานขึ้น ทำให้ใช้ memory และ connection มากขึ้น ช่วง traffic สูง response time พุ่งสูงขึ้นไปอีก

ขั้นตอนที่ 4: ลด CDN Coverage

ลด CloudFront price class จาก All Edge Locations เป็น Price Class 200 ประหยัดได้ 2,500 บาท/เดือน

ผลกระทบ: ลูกค้าบางพื้นที่ต้อง route ไปยัง edge location ที่ไกลขึ้น เพิ่ม latency ประมาณ 80-120 ms

ขั้นตอนที่ 5: ลด Memory ของ Serverless Functions

ลด Lambda memory จาก 512 MB เป็น 256 MB ประหยัดได้ 1,500 บาท/เดือน

ผลกระทบ: CPU ลดลงตามสัดส่วนไปด้วย ทำให้ function ที่ต้อง process ข้อมูลช้าลง และ timeout บ่อยขึ้นเมื่อต้องรอ database ที่ช้าอยู่แล้ว

Downsize Redis → Cache hit ลดจาก 85% เหลือ 40% → DB load เพิ่ม 4 เท่า
      ↓
RDS Downsize → DB รับ load ไม่ไหว → Query ช้า 3-4 เท่า
      ↓
Server รอ DB นาน → ใช้ memory/connection มากขึ้น → response ช้าลงอีก
      ↓
Page load เพิ่มขึ้นเป็น 2 วินาที → Conversion ลด 5%

สองเดือนต่อมา CTO เดินเข้าห้องประชุมด้วยความสีหน้ายิ้มแย้ม:

ผมลดได้ 29% ตามเป้า — จากเดือนละ 70,000 บาท เหลือ 50,000 บาท ประหยัดได้ 20,000 บาทต่อเดือน

CFO ยิ้มพอใจ ทุกคนปรบมือให้ CTO

แต่ 3 เดือนต่อมา…

3 เดือนต่อมา — CEO เรียกประชุมฉุกเฉิน

CEO ของ FreshCart เรียกประชุมด่วน หน้าตาเครียดมาก

ใครช่วยอธิบายได้ไหมว่าทำไม revenue เราถึงหายไป 5%?

ห้องประชุมเงียบกริบ ทุกคนมองหน้ากัน

CFO พูดขึ้นมาด้วยความงุนงง

แต่เราประหยัดค่า cloud ได้ตั้ง 20,000 บาทต่อเดือนนะ

CEO หันมามอง

แล้ว revenue ที่หายไปล่ะ?

มาดูกันว่าเกิดอะไรขึ้นบ้าง

ก่อนอื่นต้องเข้าใจตัวเลขพื้นฐานของ FreshCart ก่อน:

Average Order Value (AOV) คือยอดซื้อเฉลี่ยต่อ 1 คำสั่งซื้อ สำหรับ e-commerce ของสดและอาหารแช่แข็งในไทย AOV อยู่ที่ประมาณ 400-600 บาท

FreshCart มี AOV ประมาณ 450 บาท ซึ่งเป็นตะกร้าทั่วไป เช่น ผักรวม 80 บาท + ผลไม้ 100 บาท + เนื้อสัตว์ 150 บาท + อาหารแช่แข็ง 120 บาท

วิธีคำนวณ revenue:

Revenue = จำนวน Order × AOV

ก่อนลด Cost (มีนาคม)

หลังลด Cost (3 เดือนต่อมา)

สรุปผลลัพธ์

ตัวเลขบนจอทำให้ทุกคนตกใจ:

• ประหยัดได้: 20,000 บาท/เดือน
• Revenue ที่หายไป: 2,250,000 − 2,128,500 = 121,500 บาท/เดือน
• ผลลัพธ์สุทธิ: ขาดทุน 101,500 บาท/เดือน
• ROI ของการประหยัดติดลบ 507% หรือ เสียมากกว่าที่ประหยัดได้ถึง 6 เท่า

ทำไม Revenue ถึงหาย?

CTO เปิดข้อมูลจาก analytics ขึ้นมาดู แล้วก็เข้าใจทุกอย่าง

Page load time ที่เพิ่มจาก 1.2 วินาที เป็น 2.0 วินาที ทำให้ลูกค้าบางส่วนหนีไป

จากเดิมที่มี order 5,000 รายการต่อเดือน ตอนนี้เหลือ 4,730 รายการ

ทำไม Page Load ถึงส่งผลกระทบ?

มีงานวิจัยจาก Google ที่บอกว่า ทุก 1 วินาทีที่ page load ช้าลง จะทำให้ conversion rate ลดลงประมาณ 7%

FreshCart ช้าลงไปประมาณ 0.8 วินาที (จาก 1.2 เป็น 2.0 วินาที) ซึ่งแม้จะยังไม่เกิน 3 วินาที แต่ก็ส่งผลกระทบต่อ conversion ได้ โดยเฉพาะในธุรกิจ e-commerce ของสดที่ลูกค้ามีทางเลือกเยอะ

ลำดับเหตุการณ์:

1. Downsize cache → cache hit rate ลดจาก 85% เหลือ 40% → database load เพิ่มขึ้น 4 เท่า
2. Database ถูก downsize → รับ load ไม่ไหว query ช้าลง 3-4 เท่า
3. Server ไม่พอ → Service รอ DB นาน ใช้ resource มากขึ้น response ช้าลงอีก
4. CDN ช้าลง → ลูกค้าบางพื้นที่รอนานขึ้น 80-120ms
5. Lambda ทำงานช้าลง → บาง request ช้าลงเพราะต้องรอ DB

ผลรวมคือ page load time จาก 1.2 วินาที กลายเป็น 2.0 วินาที และ conversion rate ลดลง 5%

สาเหตุหลักที่ทำให้ conversion ลดลง ~5%:

1. Page load ช้าลง 67% — จาก 1.2 เป็น 2.0 วินาที ตาม Google research ทุก 1 วินาทีที่ช้าลง conversion ลดประมาณ 7% ดังนั้น 0.8 วินาที ≈ 5-6% ซึ่งตรงกับที่เกิดขึ้น
2. E-commerce ของสดมีคู่แข่งเยอะ — ลูกค้าที่เจอประสบการณ์แย่ลงอาจลองเปลี่ยนไปใช้เจ้าอื่น

สรุป 3 กับดักความผิดพลาดของ FreshCart

เรื่องของ FreshCart ไม่ใช่เรื่องแปลก หลายองค์กรกำลังเดินซ้ำรอยเดียวกัน มาดูกันว่า FreshCart ติดกับดักอะไรบ้าง

กับดัก 1: มองแค่ตัวเลขของค่าใช้จ่าย Cloud

CFO ดูแค่ตัวเลขบนใบแจ้งหนี้ เห็นจาก 50,000 บาท กลายเป็น 70,000 บาท

แต่ถ้าดูให้ลึกกว่านั้น จะเห็นว่า:

ค่าใช้จ่ายเพิ่มขึ้น 40% ดูน่ากังวล แต่พอดูให้ลึกจะเห็นว่า revenue เพิ่มขึ้น 67% และ cost per order ลดลง 16% ซึ่งเป็นสัญญาณที่บอกว่า “ธุรกิจโตเร็วกว่าค่าใช้จ่าย”

วิธีคิด:

• มกราคม: cost per order = 50,000 ÷ 3,000 = 16.7 บาท
• มีนาคม: cost per order = 70,000 ÷ 5,000 = 14 บาท

นี่คือสิ่งที่เรียกว่า good spend — จ่ายเพิ่มแต่ได้คืนมากกว่า และต้นทุนต่อหน่วยลดลงด้วย

กับดัก 2: ไม่เชื่อมโยง Cost กับ Business Outcome

CTO ลด cost โดยไม่รู้ว่าจะกระทบ conversion, revenue, หรือ customer experience อย่างไร อาจเป็นเพราะไม่เข้าใจ business มากพอ

ปัญหาคือ tech และ business ไม่มีภาษากลางในการคุยกัน:

• CFO พูดภาษา “บาท” และ “เปอร์เซ็นต์”
• CTO พูดภาษา “instance type” และ “latency”

ไม่มีใครเชื่อมโยงว่า “ลดจำนวน server” จะกระทบกับ “revenue” อย่างไร

สิ่งที่ควรถามก่อนลด cost:

1. การลดนี้จะกระทบ user experience อย่างไร?
2. ถ้า page load ช้าลง จะกระทบ conversion เท่าไร?
3. ถ้า conversion ลด จะกระทบ revenue เท่าไร?
4. Revenue ที่หายไปเทียบกับ cost ที่ประหยัดได้ คุ้มไหม?

กับดัก 3: ตั้งเป้าลด % แบบไม่ดูบริบท

“ลด 30%” ฟังดูดี แต่ไม่ได้ถามว่า:

• ลดจากส่วนไหน?
• ผลกระทบคืออะไร?
• มีทางเลือกอื่นไหม?

เป้าหมายที่ดีกว่า:

แทนที่จะบอกว่า “ลดค่า cloud 30%” ควรบอกว่า “ลด cost per order ลง 10% โดยไม่กระทบ user experience”

แบบนี้ธุรกิจยังโตได้โดยไม่ถูกจำกัดด้วยงบ IT และทีมมีทิศทางที่ชัดเจนว่าจะ optimize อย่างไร