ทำไมเราย้ายเซิร์ฟเวอร์ของ Mythex ไปใช้ ARM

เมื่อวันที่ 19 กันยายน เราย้ายแบ็กเอนด์โปรดักชันของ Mythex จากเซิร์ฟเวอร์ x86 ไปยังเซิร์ฟเวอร์ AWS Graviton ที่ใช้ ARM และเล็กกว่า และย้ายฐานข้อมูลแพลตฟอร์มไปยังอินสแตนซ์ Graviton ด้วย สาเหตุเรียบง่าย: หลังจากเราย้ายงานหนัก ซึ่งคือการรันและ build แอปของผู้ใช้แต่ละราย ไปอยู่ใน sandbox แยกของแต่ละโปรเจกต์ เซิร์ฟเวอร์หลักของเราใช้หน่วยความจำสูงสุดราวหนึ่งในสามเท่านั้น เครื่อง ARM ที่เล็กกว่าพอดีกับโหลดจริง และลดบิลเซิร์ฟเวอร์รายเดือนลงราว 30%

เซิร์ฟเวอร์ของเราทำอะไรตอนนี้

ก่อนหน้านี้ เซิร์ฟเวอร์แบ็กเอนด์ทำงานหนักโดยตรง ราวกลางเดือนกันยายนเราทำงานย้ายส่วนที่มีค่าใช้จ่ายสูงเสร็จ ได้แก่การรันโค้ดของแต่ละโปรเจกต์ การติดตั้งแพ็กเกจ และการ build แอป ไปอยู่ใน sandbox บน cloud ส่วนตัว หนึ่งอันต่อโปรเจกต์ ซึ่งเป็นสิ่งที่ให้แต่ละโปรเจกต์มีสภาพแวดล้อมแยกและพรีวิวสดของตัวเอง

สิ่งที่ยังอยู่บนเซิร์ฟเวอร์ของเราคือการประสานงาน: API, orchestrator ที่จัดการ sandbox และการเผยแพร่, การยืนยันตัวตน, การเรียกเก็บเงิน และ gateway งานเหล่านั้นสม่ำเสมอและเบา หลังการย้าย เซิร์ฟเวอร์ใช้หน่วยความจำสูงสุดราว 1.3 GB บนเครื่องที่มีประมาณสามเท่าของนั้น

ทำไมต้อง ARM

โปรเซสเซอร์ Graviton ของ AWS คือชิป ARM ที่ AWS ออกแบบเอง ในราคาเดียวกัน โดยทั่วไปคุณได้ความสามารถมากกว่าอินสแตนซ์ x86 ที่เทียบเคียงได้ หรือความสามารถเท่าเดิมในราคาที่ถูกกว่า และสำหรับงานแบบของเรา (Node.js, Docker, Postgres) ไม่มีอะไรผูกเรากับ x86

เราย้าย:

• เซิร์ฟเวอร์แอปสองเครื่อง จากอินสแตนซ์ x86 ขนาดกลาง ไปเป็นอินสแตนซ์ Graviton ขนาดเล็กที่มี RAM 2 GB ต่อเครื่อง
• ฐานข้อมูลแพลตฟอร์ม จากอินสแตนซ์ฐานข้อมูล x86 ขนาดเล็ก ไปเป็นรุ่นเทียบเท่า Graviton

ความซับซ้อนจริงอย่างเดียว: อิมเมจสำหรับสองสถาปัตยกรรม

เซิร์ฟเวอร์ staging ของเรายังรันบนเซิร์ฟเวอร์ x86 ขนาดเล็ก ส่วน production รันบน ARM ตอนนี้ container image ที่ build สำหรับอันหนึ่งจะไม่รันบนอีกอันหนึ่ง

ดังนั้นทุกอิมเมจจึงถูก build สำหรับ ทั้งสองสถาปัตยกรรมภายใต้แท็กเดียว คืออิมเมจแบบ multi-arch Docker เลือกเวอร์ชันที่ถูกต้องบนแต่ละเครื่องโดยอัตโนมัติ และ pipeline ของ deploy ไม่จำเป็นต้องรู้ว่ากำลังส่งไปยังสภาพแวดล้อมใด ต้นทุนคือ CI build นานขึ้น ประโยชน์คือ staging และ production รันโค้ดเดียวกันจากแท็กเดียวกันทุกประการ

วางแผนการย้อนกลับก่อนการย้าย

การเปลี่ยนสถาปัตยกรรม CPU ใต้บริการที่ใช้งานอยู่เป็นสิ่งที่คุณอยากย้อนกลับได้ในไม่กี่นาที ก่อนสลับ เราได้:

• เก็บเวอร์ชันของ server template ก่อนหน้าไว้เป็นเป้าหมายการย้อนกลับที่ตั้งชื่อไว้
• ถ่าย snapshot ฐานข้อมูลทันทีก่อนปรับขนาดฐานข้อมูล และ
• เขียน runbook ครอบคลุมการย้ายและทางกลับ

เราไม่ได้ต้องใช้การย้อนกลับ แต่เราจะทำแบบเดิมอีกครั้งอยู่ดี

สิ่งที่เราจะระวัง

เซิร์ฟเวอร์ที่เล็กกว่ามี headroom น้อยกว่า และมีสองเรื่องที่ตามมา:

1. หากงานหนักกลับไปอยู่บนเซิร์ฟเวอร์เหล่านี้ 2 GB จะไม่พอ วิธีแก้ตอนนั้นคือขนาด Graviton ที่ใหญ่ขึ้น ไม่ใช่การกลับไป x86
2. เครื่องเล็กต้องมี swap หนึ่งสัปดาห์ต่อมาเซิร์ฟเวอร์หนึ่งในนี้ค้างเพราะแรงกดดันของหน่วยความจำ โดยไม่ได้หมดหน่วยความจำจริงๆเรื่องราวของไฟล์ swap ที่หายไป

สิ่งที่เราเรียนรู้

• วัดใหม่หลังการเปลี่ยนสถาปัตยกรรม การย้ายงานไปยัง sandbox เปลี่ยนสิ่งที่เซิร์ฟเวอร์ของเราต้องการ แต่ขนาดอินสแตนซ์ยังไม่ตามทัน
• ARM เป็นชัยชนะที่มีความเสี่ยงต่ำสำหรับสแตกเว็บทั่วไป เมื่ออิมเมจของคุณเป็น multi-arch แล้ว
• เขียนแผนย้อนกลับก่อน มันทำให้การเปลี่ยนแปลงสงบขึ้นแม้คุณไม่เคยใช้มัน