THAI DATA CLOUD
Manual THAI DATA CLOUD Platform

Right-sizing: ลดค่าเซิร์ฟเวอร์คลาวด์โดยระบบไม่ช้าลง

ทำ Right-sizing ลดค่าเซิร์ฟเวอร์คลาวด์จากข้อมูลจริง 2–4 สัปดาห์ หาเครื่องและดิสก์ที่ไม่ได้ใช้ วิเคราะห์ด้วย p95 ลดสเปกอย่างปลอดภัย และทบทวนทุกไตรมาส

โดย ทีมงาน THAI DATA CLOUD อ่าน 12 นาที

แชร์FacebookXLINELinkedIn
Right-sizing — Right-sizing: ลดค่าเซิร์ฟเวอร์คลาวด์โดยระบบไม่ช้าลง
Right-sizing: ลดค่าเซิร์ฟเวอร์คลาวด์โดยระบบไม่ช้าลง

คำตอบสั้น ๆ: ทำ Right-sizing ลดค่าเซิร์ฟเวอร์คลาวด์จากข้อมูลจริง 2–4 สัปดาห์ หาเครื่องและดิสก์ที่ไม่ได้ใช้ วิเคราะห์ด้วย p95 ลดสเปกอย่างปลอดภัย และทบทวนทุกไตรมาส

คู่มือนี้อธิบาย Right-sizing ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

Right-sizing คือการปรับขนาดเซิร์ฟเวอร์ ดิสก์ และทรัพยากรอื่นบนคลาวด์ให้ตรงกับการใช้งานจริง ทั้งลดเครื่องที่ใหญ่เกินงาน ปิดเครื่องที่ไม่มีใครใช้ และล้าง Volume หรือ Snapshot ที่ค้างอยู่ จุดสำคัญคือทำจากข้อมูลการใช้งานหลายสัปดาห์ ไม่ใช่จากความรู้สึกว่าเครื่องว่าง เพราะการลดสเปกผิดจังหวะทำให้ระบบช้าลงตอนสิ้นเดือนพอดี

คู่มือนี้เหมาะกับผู้ดูแลระบบและผู้รับผิดชอบงบไอทีที่ดูแลเซิร์ฟเวอร์คลาวด์หลายเครื่อง เมื่อทำครบ คุณจะมีรายการทรัพยากรพร้อมเจ้าของ ข้อมูลการใช้งานย้อนหลัง 2–4 สัปดาห์ รายชื่อเครื่องที่ลดได้พร้อมตัวเลขรองรับ ขั้นตอนลดสเปกที่ปลอดภัยและถอยกลับได้ และรอบทบทวน Right-sizing ที่ทำซ้ำได้ทุกไตรมาส

สิ่งที่ต้องเตรียม

  • รายการเซิร์ฟเวอร์ ดิสก์ และบริการเสริมทั้งหมดจากพอร์ทัลของผู้ให้บริการ พร้อมค่าใช้จ่ายรายเดือนจากใบแจ้งหนี้ล่าสุด
  • ข้อมูลการใช้ CPU, RAM, ดิสก์ และเครือข่ายย้อนหลังสำหรับ Right-sizing อย่างน้อย 2 สัปดาห์ ดีที่สุดคือ 4 สัปดาห์ที่มีวันสิ้นเดือนรวมอยู่
  • เจ้าของระบบของแต่ละเครื่อง ผู้ที่ยืนยันได้ว่าเครื่องนั้นยังใช้อยู่หรือไม่ และช่วงไหนเป็นช่วงงานหนัก
  • Backup ที่ทดลองกู้ได้ของทุกเครื่องที่จะลดสเปก และช่วงเวลาหยุดระบบที่ตกลงกับผู้ใช้แล้ว
ลำดับงาน Right-sizing ตั้งแต่ทำรายการทรัพยากร เก็บข้อมูลการใช้งาน ล้างทรัพยากรที่ว่าง วิเคราะห์ p95 ลดสเปก จนถึงทบทวนรอบถัดไป
ล้างของที่ไม่ใช้ก่อน แล้วค่อยลดสเปกเครื่องที่ใช้งานจริงจากตัวเลขหลายสัปดาห์

ขั้นตอนที่ 1: ทำรายการทรัพยากรและเจ้าของก่อน Right-sizing

ทำตารางหนึ่งแถวต่อหนึ่งทรัพยากร คอลัมน์ที่ควรมีคือ ชื่อ ประเภท (เซิร์ฟเวอร์ ดิสก์เสริม Backup IP) สเปก ค่าใช้จ่ายต่อเดือน ระบบที่ใช้ เจ้าของ และวันที่สร้าง แถวที่ไม่มีใครรับเป็นเจ้าของคือเป้าหมายแรกของ Right-sizing เพราะมักเป็นเครื่องทดสอบหรือดิสก์ที่ถูกลืมหลังโครงการจบ

ตารางนี้คือฐานของ Right-sizing ทุกรอบ ตั้งชื่อเครื่องให้บอกระบบและสภาพแวดล้อม เช่น erp-prod-01 หรือ web-dev-02 จะช่วยให้แยกเครื่องจริงกับเครื่องทดสอบได้ทันทีในรอบถัดไป ดิสก์เสริมที่ไม่ได้ต่อกับเครื่องใดแต่ยังคิดค่าบริการอยู่ ให้ตรวจตามคู่มือ Volume Disk บน Cloud ของ TDC

ขั้นตอนที่ 2: เก็บข้อมูลสำหรับ Right-sizing 2–4 สัปดาห์

กราฟใน Cloud Server Monitoring ของ THAI DATA CLOUD ใช้ดูภาพรวมได้ทันที เครื่องโซน Zenith เลือก Period เป็น Monthly ได้ ส่วนเครื่องโซนอื่นย้อนหลังได้สูงสุด Last 7 days ถ้าต้องการข้อมูลยาวกว่านั้นสำหรับ Right-sizing ให้เก็บในเครื่องเองด้วย sysstat บน Linux

sudo apt install -y sysstat                                   # Ubuntu / Debian
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo sed -i 's/^HISTORY=.*/HISTORY=28/' /etc/sysstat/sysstat   # เก็บย้อนหลัง 28 วัน
sudo systemctl enable --now sysstat
# ผ่านไปหลายวันแล้วอ่านผล
ls /var/log/sysstat/
sar -u -f /var/log/sysstat/sa12      # CPU ของวันที่ 12
sar -r -f /var/log/sysstat/sa12      # หน่วยความจำ
ผลคำสั่ง sar -u ของเครื่อง 8 vCPU ที่ใช้ CPU ไม่ถึง 30 เปอร์เซ็นต์แม้ช่วงพีก เป็นข้อมูลประกอบการทำ Right-sizing
ดูช่วงเวลาทำงานหลายวัน ไม่ใช่แค่บรรทัด Average ก่อนตัดสินใจลดสเปก

บน Windows Server สร้างตัวเก็บข้อมูลด้วย logman ให้บันทึกทุก 5 นาทีลงไฟล์ CSV แล้วเปิดดูใน Excel ได้ ตัวเก็บข้อมูลไม่เริ่มเองหลังรีสตาร์ต ต้องสั่ง logman start ใหม่ทุกครั้งที่รีบูต

mkdir C:\perf
logman create counter RightSizing -c "\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" -si 00:05:00 -f csv -o C:\perf\rightsizing
logman start RightSizing

ถ้ามี Prometheus กับ Node Exporter อยู่แล้ว ให้ใช้ค่าเปอร์เซ็นไทล์ที่ 95 (p95) แทนค่าเฉลี่ย เพราะค่าเฉลี่ยของ 4 สัปดาห์กลบช่วงพีกจนดูเหมือนเครื่องว่างเสมอ ฟังก์ชัน quantile_over_time อธิบายไว้ใน เอกสาร Prometheus query functions

# p95 ของ CPU ที่ใช้ (%) ย้อนหลัง 28 วัน
quantile_over_time(0.95, (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))[28d:5m]) * 100
# p95 ของ RAM ที่ใช้ (%) ย้อนหลัง 28 วัน
quantile_over_time(0.95, (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)[28d:5m]) * 100

ขั้นตอนที่ 3: หาทรัพยากรที่ไม่ได้ใช้งาน

ใน Right-sizing ทรัพยากรที่ไม่มีใครใช้ประหยัดได้มากที่สุดและเสี่ยงต่ำที่สุดเมื่อจัดการถูกวิธี สัญญาณที่ควรตรวจ

  • เซิร์ฟเวอร์ที่ CPU ต่ำกว่า 5% ตลอดหลายสัปดาห์ ทราฟฟิกเครือข่ายแทบเป็นศูนย์ และไม่มีใครล็อกอิน ดูได้จาก last -n 20 บน Linux หรือ Event Viewer บน Windows
  • ดิสก์เสริมที่ไม่ได้ต่อกับเครื่องใด หรือต่ออยู่แต่ไม่ได้ Mount (ตรวจด้วย lsblk -f)
  • Snapshot หรือ Backup แบบเก็บด้วยมือที่เก่ากว่าระยะที่ Backup Plan กำหนด
  • เครื่องทดสอบของโครงการที่จบไปแล้ว และเครื่องเก่าที่เก็บไว้หลังย้ายระบบเกินช่วงรอถอยกลับ

คำเตือน: ก่อนลบทรัพยากรใด ให้เจ้าของยืนยันเป็นลายลักษณ์อักษร และสำรองข้อมูลชุดสุดท้ายไปเก็บแยกไว้ เครื่องที่ไม่แน่ใจให้ปิดไว้ก่อน 2–4 สัปดาห์เพื่อดูว่ามีใครแจ้งปัญหาหรือไม่ แล้วจึงลบ การลบเครื่องหรือดิสก์บนคลาวด์โดยทั่วไปกู้คืนไม่ได้

ขั้นตอนที่ 4: วิเคราะห์ Right-sizing ด้วย p95 แล้วเลือกขนาดใหม่

Right-sizing ที่ดีใช้ค่า p95 ของช่วงเวลาทำงานเป็นหลัก แล้วประเมินว่าถ้าลดสเปก ค่านั้นจะขึ้นไปเท่าไร หลักการที่ใช้ได้กับงานส่วนใหญ่

  • CPU: ถ้า p95 ต่ำกว่าราว 30–35% ตลอด 4 สัปดาห์ การลด vCPU ลงครึ่งหนึ่งจะทำให้ค่าเดียวกันขึ้นไปราว 60–70% ซึ่งยังรับงานได้ เป็นการประมาณแบบเส้นตรง งานที่ไม่ได้กระจายทุกคอร์อาจไม่เป็นแบบนั้น จึงต้องตรวจหลังลดเสมอ
  • RAM: ดูค่าต่ำสุดของ available ไม่ใช่ค่าเฉลี่ย ถ้า RAM ที่จะลดลงมากกว่าค่า available ต่ำสุด เครื่องจะเริ่มใช้ Swap หรือปิดโปรเซสเอง ฐานข้อมูลที่ CPU ต่ำแต่ใช้ RAM เป็นแคชไม่ควรลด RAM เพียงเพราะ CPU ว่าง
  • ดิสก์: บนคลาวด์ส่วนใหญ่ขยายดิสก์ได้แต่ลดขนาดลงไม่ได้ ดิสก์ที่ใหญ่เกินมากต้องสร้างดิสก์ใหม่ที่เล็กกว่าแล้วย้ายข้อมูล ซึ่งคุ้มเฉพาะดิสก์ขนาดใหญ่

ตัวอย่าง: erp-prod-01 ขนาด 8 vCPU / 32 GB มี p95 ของ CPU 24% และ available ต่ำสุด 19 GB ลดเป็น 4 vCPU ได้ (คาดว่า p95 ราว 48%) และลด RAM เป็น 16 GB ได้โดยยังเหลือส่วนเผื่อราว 3 GB หลักการคำนวณขนาดตั้งต้นอยู่ใน คู่มือเลือก vCPU และ RAM

เช็กลิสต์ก่อนลดสเปกในงาน Right-sizing เช่น ข้อมูลครอบคลุมวันพีก ปรับค่าฐานข้อมูลแล้ว และมี Backup ที่กู้ได้
ข้อสีแดงคือสาเหตุที่พบบ่อยที่สุดของระบบล่มหลังลดสเปก

ขั้นตอนที่ 5: ลดสเปกอย่างปลอดภัยและถอยกลับได้

  1. ปรับค่าแอปก่อน: ก่อน Right-sizing ลดค่าที่ผูกกับขนาด RAM ให้พอดีกับขนาดใหม่ เช่น innodb_buffer_pool_size ของ MySQL/MariaDB, shared_buffers ของ PostgreSQL และ pm.max_children ของ PHP-FPM ถ้าลืมข้อนี้ ฐานข้อมูลอาจเปิดไม่ขึ้นหลังลด RAM
  2. สำรองข้อมูล: สั่ง Backup รอบล่าสุดและตรวจว่าสำเร็จ
  3. ลดสเปก: ทำในช่วงเวลาที่แจ้งผู้ใช้ไว้ เพราะการเปลี่ยนสเปกมักต้องหยุดและเปิดเครื่องใหม่ สำหรับ THAI DATA CLOUD ทำตาม คู่มือการ Upgrade/Downgrade สเปค Cloud Server และดูยอดที่ระบบแสดงก่อนยืนยัน
  4. ตรวจทันที: nproc, free -h, systemctl --failed และเปิดแอปจริงหนึ่งรอบ
  5. เฝ้าดูหนึ่งสัปดาห์: หลัง Right-sizing ถ้า p95 ใหม่เกิน 80% หรือผู้ใช้แจ้งว่าช้าในช่วงพีก ให้ขยายกลับขึ้นหนึ่งขนาด การถอยกลับของ Right-sizing คือการ Upgrade ซึ่งทำได้ด้วยขั้นตอนเดิม

ขั้นตอนที่ 6: ทำ Right-sizing เป็นรอบ ไม่ใช่ครั้งเดียว

การใช้งานเปลี่ยนตลอด Right-sizing ครั้งเดียวจึงไม่พอ เครื่องที่พอดีวันนี้อาจใหญ่เกินหลังย้ายบางระบบออก หรือเล็กไปเมื่อธุรกิจโต ให้ทบทวนทุกไตรมาสด้วยตารางเดิม และทุกครั้งที่โครงการจบ

  • เครื่อง Dev และ Test: การปิดเครื่องนอกเวลางานช่วยลดค่าใช้จ่ายได้เฉพาะบริการที่คิดตามเวลาที่เปิดเครื่อง ถ้าเครื่องคิดค่าบริการเป็นรอบเดือนหรือรอบปี การปิดเครื่องอย่างเดียวมักไม่ลดค่าใช้จ่าย เพราะทรัพยากรยังถูกจองไว้ ให้ตรวจเงื่อนไขกับผู้ให้บริการ แล้วพิจารณารวมเครื่องทดสอบหลายเครื่องไว้ในเครื่องเดียวแทน
  • Snapshot และ Backup: ตั้งระยะเก็บให้ชัดใน Backup Plan แล้วให้ลบอัตโนมัติตามรอบ แทนการเก็บไว้ตลอดไป
  • Log และไฟล์ชั่วคราว: ตั้ง logrotate และลบไฟล์ Dump เก่า เพื่อไม่ต้องขยายดิสก์เกินจำเป็น
ตารางทรัพยากรคลาวด์ที่มักถูกลืมในการทำ Right-sizing พร้อมสัญญาณที่ตรวจพบและวิธีจัดการอย่างปลอดภัย
ของที่ไม่มีใครใช้ประหยัดได้มากและเสี่ยงต่ำ ถ้าเจ้าของยืนยันและสำรองข้อมูลก่อน

ปัญหาที่พบบ่อยเกี่ยวกับ Right-sizing

ควรใช้ค่าเฉลี่ยหรือค่าสูงสุดในการทำ Right-sizing?

ไม่ใช่ทั้งคู่ ค่าเฉลี่ยกลบช่วงพีก ส่วนค่าสูงสุดมักเป็นยอดพุ่งไม่กี่วินาทีจากงานสำรองข้อมูล ค่า p95 ของช่วงเวลาทำงานสะท้อนภาระที่ผู้ใช้เจอจริงได้ดีกว่า และควรดูคู่กับเหตุการณ์ที่รู้ล่วงหน้า เช่น วันปิดงบ

Right-sizing แล้วฐานข้อมูลเปิดไม่ขึ้น ทำอย่างไร?

มักเกิดจากค่าหน่วยความจำของฐานข้อมูลยังเท่าเดิมและใหญ่เกิน RAM ใหม่ ให้ดู Log ของฐานข้อมูลด้วย journalctl -u mariadb -n 50 (หรือชื่อบริการที่ใช้) ลดค่า buffer ให้พอดีแล้วสั่งเปิดใหม่ ถ้าแก้ไม่ได้ในเวลาที่กำหนด ให้ขยายกลับขึ้นก่อน

ทำ Right-sizing ด้วยการปิดเครื่องแล้ว ทำไมใบแจ้งหนี้ยังเท่าเดิม?

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

Right-sizing ทำให้เครื่องเสี่ยงล่มมากขึ้นหรือไม่?

ถ้าทำจากข้อมูล 2–4 สัปดาห์ เหลือส่วนเผื่อ และมีขั้นตอนถอยกลับ ความเสี่ยงต่ำ ความเสี่ยงจริงอยู่ที่การลดจากข้อมูลช่วงสั้นที่ไม่มีวันพีก หรือลด RAM ของฐานข้อมูลโดยไม่ปรับค่า ซึ่งขั้นตอนที่ 4 และ 5 กันไว้แล้ว

ถ้าต้องการให้ทีมช่วยวิเคราะห์การใช้งานและวางแผน Right-sizing ของเซิร์ฟเวอร์ทั้งหมด ติดต่อทีมงาน THAI DATA CLOUD หรือดูสเปกและแพ็กเกจของบริการ Cloud Server

อ่านเพิ่มเติมเกี่ยวกับ Right-sizing

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน