สวัสดีครับผู้อ่านทุกท่าน วันนี้ผมอยากมาแชร์ประสบการณ์การปรับจูนเซิร์ฟเวอร์เพื่อลดค่าใช้จ่ายให้กับองค์กร โดยผมได้มีโอกาสพัฒนาและดูแลระบบของบริษัทหนึ่งเกี่ยวกับน้ำแข็ง ซึ่งระบบค่อนข้างใหญ่ มีผู้ใช้งานช่วงพีคเกือบ 3,000 คน
จุดเริ่มต้นของการย้ายก็เพื่อลดค่าใช้จ่าย ปัจจุบันธุรกิจคลาวด์เข้ามามีบทบาทค่อนข้างเยอะ บวกกับเอไอที่เข้ามาช่วยเราได้มากขึ้น ผมเลยลองปรึกษากับเอไอว่าจะลดค่าใช้จ่ายยังไงได้บ้าง พร้อมวางแผนการทำงาน โดยตั้งโจทย์หลักไว้สองข้อ คือ ต้องปิดระบบให้น้อยที่สุด และ ข้อมูลต้องอยู่ครบถ้วน
แบ็คอัพ แล้วเช็กว่าระบบต้องการทรัพยากรจริงๆ แค่ไหน
สิ่งแรกที่ผมเลือกทำเลยคือการแบ็คอัพข้อมูล จากนั้นเช็กว่าความต้องการทรัพยากรของระบบจริงๆ แล้วต้องการอะไรบ้าง ผลที่ได้คือ CPU แทบไม่กระดิก วิ่งอยู่ 20–30% แต่ RAM วิ่งแบบแทบทะลุกราฟ บนเซิร์ฟเวอร์ใหม่ผมจึงเลือกสเป็คที่มี RAM เท่าเดิม แต่ลดจำนวน CPU ลง
ลอง Plesk Migration แต่ไม่รอด
หลังจากได้สเป็คที่ต้องการ ตอนแรกผมลองหา Tools ต่างๆ เข้ามาช่วยให้ย้ายง่ายๆ ด้วยความที่เซิร์ฟเวอร์ติดตั้ง Plesk ไว้จัดการ ผมเลยลองใช้ Plesk Migration ก็ได้ผลลัพธ์ที่เกือบจะดี มัน Migrate ทุกอย่างมาจริงๆ แต่ดันมาติดปัญหาตรงที่ดาต้าเบสระบบนี้มันใหญ่ถึง 300 กว่า GB เลยทำไม่สำเร็จ มีเออเร่อซะก่อน
กลับมาใช้วิธีพื้นฐาน แบ็คอัพแล้วรีสโตร์ (พร้อมจับเวลา)
ผมลองหาท่าใหม่ โดยยังใช้ Plesk Migration อยู่ เพื่อให้ได้ค่า Config, Cron และอื่นๆ ติดมาด้วย แต่ในเมื่อมันเอาดาต้าเบสมาไม่สำเร็จ ผมเลยกลับไปใช้การทำงานพื้นฐานอย่างการแบ็คอัพแล้วรีสโตร์ ซึ่งได้ประโยชน์สองต่อ คือเป็นการรีเช็คระบบแบ็คอัพของเราไปในตัว
ผมเอาข้อมูลที่แบ็คอัพไว้มาทดสอบรีสโตร์กลับและจับเวลา ผลที่ได้คือ 6 ชั่วโมง สำหรับการรีสโตร์ดาต้าเบส 300 กว่า GB ระหว่างรีสโตร์ก็เจอปัญหาดิสก์เต็มด้วย จะเช่าดิสก์เพิ่มก็มีค่าใช้จ่าย เลยใช้แผนเช่าดิสก์แยกออกมาเป็นอีกไดร์ต่างหาก พอใช้เสร็จก็เลิกเช่า จะได้ไม่โดนค่าใช้จ่ายระยะยาว
วันจริง วางแผนปิดระบบ 6 ชั่วโมง
จากนั้นผมแจ้งลูกค้าว่าขอปิดระบบ 6 ชั่วโมง เลือกช่วง 21:00–03:00 เพราะจากที่ดู Log ช่วงเวลานี้คนใช้งานน้อยที่สุด แต่ก็แอบกังวลเรื่อง Cron ที่ตั้งให้ทำงานช่วงนี้เหมือนกัน
ทำไม Cron ถึงพลาดไม่ได้: ผมใช้ Cron ในการเคลียร์บิล เคลียร์ข้อมูลการขายของลูกค้า และเตรียมข้อมูลสำหรับออกรายงาน ถ้ามันทำงานผิดจังหวะระหว่างย้าย ก็ต้องมาตามแก้กันปวดหัวแน่ๆ
ค่อยๆ สลับผู้ใช้ ไม่รวบทีเดียว
หลังจากปิดระบบเก่า แบ็คอัพข้อมูลใหม่ และรีสโตร์เข้าเซิร์ฟเวอร์ใหม่ ผมรีเช็คข้อมูลอีกรอบ แล้วเอาโค้ดของระบบเก่าชี้มาที่ดาต้าเบสตัวใหม่ ตอนนั้นในใจคือยังไม่กล้าให้ทุกคนสลับมาใช้พร้อมกันหมด
ผมเลยเซ็ตซับโดเมนผ่าน Cloudflare เพื่อแบ่งผู้ใช้งานเป็นสองชุด คือชุดที่ยังอยู่เซิร์ฟเวอร์เก่า กับชุดที่ย้ายมาเซิร์ฟเวอร์ใหม่ และด้วยความที่ผมออกแบบให้ไฟล์ทั้งหมดเก็บอยู่บน S3 ผมจึงไม่ค่อยกังวลเรื่องการอัพโหลดแก้ไขไฟล์เท่าไหร่
มอนิเตอร์ แล้วปิดเครื่องเก่า
ช่วงตีสามกว่าๆ ผมเปิดระบบกลับให้คนใช้งาน ระหว่างนั้นก็เฝ้ามอนิเตอร์ว่ามีอะไรผิดปกติไหม Cron job ทำงานได้ไหม ทุกอย่างโอเคไหม มีปรับเล็กๆ น้อยๆ ตามเพิ่ม พอผ่านไป 1–2 วัน ผมก็ยุบผู้ใช้งานให้อยู่ที่เซิร์ฟเวอร์ใหม่อย่างเดียว แล้วมอนิเตอร์ต่อจนทุกอย่างดูนิ่ง จึงเลิกเช่าเซิร์ฟเวอร์เก่า และดิสก์ที่เอาไว้เก็บแบ็คอัพตอนรีสโตร์
มันทำให้ผมมั่นใจได้อย่างหนึ่งเลย คือ แบ็คอัพเราใช้งานได้จริง เพราะจากที่ไปทำงานมาหลายที่ มีแต่แบ็คอัพ แต่ไม่เคยทดสอบรีสโตร์
บทเรียนจากงานจริง
สิ่งที่ได้เรียนรู้
เรียกได้ว่าเป็นประสบการณ์การย้ายเซิร์ฟเวอร์ที่ค่อนข้างโหดและหินสำหรับผมเลย ปกติไม่เคยย้ายดาต้าเบสขนาดนี้มาก่อน กังวลมากๆ ใช้เวลาทำไปประมาณ 15 วัน แต่หลังจากนี้ก็น่าจะประหยัดค่าใช้จ่ายลงได้เยอะ
สำหรับผู้อ่านที่เข้ามาแล้วอยากคอมเมนต์แนะนำเพิ่มเติม ยินดีมากๆ เลยนะครับ ไว้พบกันใหม่บทความหน้า 🙌