Zettify

บทความ

  • คลาวด์และ AWS
  • วิศวกรรมซอฟต์แวร์

ย้ายระบบอายุสิบปีขึ้น AWS โดยไม่ต้องปิดระบบทั้งสุดสัปดาห์

เราวางแผนย้ายระบบงานที่หยุดรับออเดอร์ไม่ได้แม้แต่นาทีเดียวอย่างไร ให้ระบบทำงานต่อ ย้ายทีละส่วน และปิดระบบเก่าเมื่อตัวเลขยืนยันแล้วเท่านั้น

Zettify Engineering · · อ่าน 2 นาที

การย้ายระบบส่วนใหญ่ล้มเหลวตั้งแต่ก่อนวัน cut-over เสียอีก มันล้มตั้งแต่ใน spreadsheet ที่มีคนตัดสินใจว่าจะ “copy database ช่วงสุดสัปดาห์” แล้วให้ธุรกิจรอไปก่อน

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

เริ่มจากสิ่งที่ห้ามหยุด

ก่อนวาด architecture diagram สักรูป เราไล่ทุก flow ที่ สร้างรายได้ หรือ ดูแลความปลอดภัยของคน เช่น รับออเดอร์ ยืนยันการชำระเงิน พิมพ์ใบส่งของ แล้วออกแบบการย้ายให้ flow เหล่านั้นทำงานต่อได้ ไม่ใช่ออกแบบตาม server ที่มันบังเอิญรันอยู่

  • สำรวจทุก integration ทั้งขาเข้าและขาออก รวมถึงงานที่รันแค่สิ้นเดือน
  • จดไว้ว่าใครจะรู้ตัวก่อนเมื่อแต่ละ flow พัง และรู้ได้อย่างไร
  • ตกลงกันเป็นตัวเลขว่า “ทำงานปกติ” หมายถึงอะไร ก่อนจะย้ายอะไรสักอย่าง

รันระบบเก่าและใหม่คู่กัน

ขั้นแรกเราวาง routing layer บางๆ ไว้หน้าระบบเก่า วันแรกมันส่งทุก request ไประบบเก่าและไม่เปลี่ยนอะไรเลย นั่นคือประเด็น เพราะเมื่อมันอยู่ตรงนั้นแล้ว ทุกขั้นตอนหลังจากนี้คือการตัดสินใจเรื่อง routing ที่ย้อนกลับได้ในไม่กี่วินาที

Service ใหม่บน AWS ขึ้นมาอยู่หลัง layer เดียวกัน แต่ละตัวรับงานแค่ feature เดียว และรับ traffic เพียงบางส่วนในช่วงแรก

การย้ายระบบที่ดีที่สุด คือการย้ายที่ลูกค้าไม่รู้สึกเลย

Replicate ข้อมูลต่อเนื่อง ไม่ใช่ copy ครั้งเดียว

Copy ครั้งเดียวจะล้าสมัยทันทีที่ copy เสร็จ เราจึง replicate database แบบต่อเนื่องด้วย AWS DMS ฝั่งใหม่จึงตามหลังฝั่งเก่าแค่ไม่กี่วินาที และเราเทียบข้อมูลทั้งสองฝั่งได้ก่อนจะเชื่อฝั่งใดฝั่งหนึ่ง

aws dms start-replication-task \
  --replication-task-arn "$TASK_ARN" \
  --start-replication-task-type resume-processing

สลับ traffic ทีละก้าวเล็กๆ

  1. ห้าเปอร์เซ็นต์ของ feature เดียว เป็นเวลาหนึ่งวัน
  2. ทั้งหมดของ feature นั้น เป็นเวลาหนึ่งสัปดาห์
  3. Feature ถัดไป ขณะที่ feature แรกรันบนฝั่งใหม่ต่อไป

Latency, error rate และ queue depth บอกเราได้มากกว่า diagram ใดๆ พอตัวเลขทั้งสามนิ่งครบหนึ่งสัปดาห์ เราก็ปิดระบบเก่า และไม่มีใครนอกทีมสังเกตเห็น ถ้าคุณกำลังวางแผนย้ายระบบแบบนี้ เล่าเรื่องระบบของคุณให้เราฟัง