Multi-region และ migration เบื้องต้น
ออกแบบหลายภูมิภาคและย้ายระบบด้วย DMS, Snow family
ถ้าคุณมีเฟอร์นิเจอร์ (ข้อมูล) ในบ้านเต็มไปหมด การทยอยส่งไปรษณีย์ (อินเทอร์เน็ต) อาจใช้เวลาเป็นปี สู้จ้างรถบรรทุก (Snowball) มาขนรวดเดียวแล้วขับไปส่งที่บ้านใหม่ (AWS) จะไวกว่ามาก
พื้นฐานที่ควรรู้: การวางระบบไว้ในภูมิภาค (Region) เดียวอาจไม่ตอบโจทย์ถ้าลูกค้าเราอยู่ทั่วโลก (ข้อมูลเดินทางไกลจะช้า) หรือเมื่อต้องเตรียมแผนเผื่อภูมิภาคหลุดพังไป (Disaster) และเวลาที่เราจะย้ายบ้าน (Migrate) ระบบเก่าขึ้น AWS ก็มีตัวช่วยเฉพาะทางหลายตัว
- Multi-Region (หลายภูมิภาค) — วางระบบกระจายหลายโซนโลก เพื่อให้คนใช้รู้สึกว่าแอปตอบสนองไว (Low Latency) และเพิ่มความทนทาน เครื่องมือยอดฮิตคือ Route 53 (ตัวนำทาง), DynamoDB Global Tables, และ Aurora Global DB
- AWS DMS (Database Migration Service) — บริการช่วยย้ายข้อมูลในฐานข้อมูลขึ้น AWS แบบอัตโนมัติ โดยที่ระบบเก่ายังทำงานได้ตามปกติ (Minimal Downtime) รองรับการย้ายข้ามสายพันธุ์ (เช่น ย้ายจาก Oracle ไป MySQL)
- AWS Snow Family (Snowcone / Snowball / Snowmobile) — บริการส่งอุปกรณ์รับฝากข้อมูลทางกายภาพ เพื่อใช้ขนถ่ายข้อมูลมหาศาล (Offline Migration) แบบไม่ต้องง้ออินเทอร์เน็ต
สรุป Key Takeaways
- Multi-Region เพื่อ latency ต่ำและทน disaster ระดับ Region
- DMS ย้าย DB downtime น้อย; Snow Family ขนข้อมูลใหญ่แบบ offline
คำถามที่พบบ่อย
เมื่อไหร่ถึงควรทำ multi-region จริงๆ
สามเหตุผลที่ฟังขึ้น: (1) DR ที่ RTO/RPO เข้มมากระดับ region ล่มก็ต้องรอด (2) latency ผู้ใช้ต่างทวีป (3) data residency ตามกฎหมาย — นอกนั้น Multi-AZ ใน region เดียวมักพอและถูกกว่ามาก ข้อสอบชอบหลอกให้เลือก multi-region ทั้งที่โจทย์แค่ต้องการ HA ธรรมดา
เครื่องมือ migration ตระกูล 7R ต้องรู้แค่ไหน
รู้จักกลยุทธ์หลัก: Rehost (lift-and-shift ด้วย MGN — เร็วสุด), Replatform (ขยับนิดหน่อย เช่น DB ไป RDS), Refactor (เขียนใหม่เป็น cloud-native — แพงแต่คุ้มระยะยาว), Retire/Retain — โจทย์ "ย้ายเร็วที่สุดโดยแก้น้อยที่สุด" = Rehost
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที