สรุปเรื่อง Disaster Recovery (DR) บน AWS

Summary of Disaster Recovery (DR) on AWS

— — — — — — — — — — — — — — —
สารบัญเนื้อหาทั้งหมด (My Contents)
— — — — — — — — — — — — — — —

เรื่อง disaster recovery (DR) หรือการกู้คืนข้อมูลเมื่อเกิดภัยพิบัติ เป็นเรื่องที่สำคัญมากในการวาง workload บน AWS และยังเป็นหัวข้อสำหรับการสอบ AWS Certified Solution Architect Professional ด้วย ลองมาดูกันครับ…

สิ่งที่ต้องคำนึงถึง

Recovery Point Objective (RPO)

คือระยะเวลาสูงสุดที่ยอมรับได้นับจาก restore point ล่าสุด หรือก็คือเมื่อเกิด failure ขึ้นและ restore กลับมา เรายอมให้ข้อมูลสูญหายสูงสุดได้นานแค่ไหน

จากรูปด้านบน สมมุติผมต้องการ RPO เท่ากับ 2 ชั่วโมง ดังนั้นผมจึงต้อง backup หรือสร้าง restore point เอาไว้ทุก ๆ 2 ชั่วโมง ตั้งแต่ 00:00, 02:00, 04:00, …

เมื่อเกิด failure ขึ้นที่เวลา 07:00 AM ผมก็ทำการ restore ข้อมูลกลับมา ข้อมูลที่ได้จะเป็นข้อมูลในเวลา 06:00 AM เท่ากับว่าข้อมูลผมหายไปราว 1 ชั่วโมง และไม่ว่า failure จะเกิดที่เวลาไหน ก็จะไม่มีทางเกิด 2 ชั่วโมง เป็นต้น

Recovery Time Objective (RTO)

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

โดย RPO และ RTO จะมากหรือน้อยขึ้นอยู่กับ business, SLA หรือ cost สำหรับ service นั้น ๆ ครับ ซึ่งตัวเลขดังกล่าวเป็นค่าเฉพาะสำหรับแต่ละ wordload เท่านั้น

Disaster Recovery (DR) Strategy บน AWS

รูปจาก docs.aws.amazon.com

RPO, RTO รวมถึง cost ก็จะไปเกี่ยวเนื่องกับ strategy ที่เราเลือกใช้ในการทำ DR ด้วย ลองดูตามด้านล่างนี้ครับ

1. Backup & Restore

รูปจาก docs.aws.amazon.com

• สร้าง backup ขึ้นมาใน region เดียวกับ source (backup เฉพาะข้อมูล)
• เมื่อเกิด failure ก็ทำการ recover ขึ้นมาจากข้อมูลที่ backup ไว้
• ใช้ Infrastructre as Code ช่วยในการ deploy infrastructure ขึ้นใหม่
• สามารถ copy backup ข้าม region ได้ (Cross-region backup)
• แผนนี้จะประหยัดที่สุด แต่แลกมาด้วย RTO สูงที่สุด (ใช้เวลา recovery นาน)
• Service ที่ใช้ (ขึ้นอยู่กับ data store) เช่น Amazon EBS snapshot, DynamoDB backup, RDS snapshot, Aurora DB snapshot, EFS backup เป็นต้น
• AWS Backup เป็น service อีกตัวที่ช่วยในการทำ backup ให้กับ AWS service ต่าง ๆ ได้ง่ายขึ้น

2. Pilot light

รูปจาก docs.aws.amazon.com

• Deploy infrastructure ลงบนทั้งสอง region พร้อมกัน แต่ turn off infrastructure บนฝั่ง DR region เอาไว้
• ทำการ replicate ข้อมูลไปยัง DR region อยู่ตลอดเวลา
• เมื่อเกิดเหตุเราจะต้องสั่ง turn on ฝั่ง DR region ก่อนจึงจะสามารถ handle workload ได้
• Service ที่ใช้(ขึ้นอยู่กับ data store) เช่น Amazon S3 replication, Amazon RDS read replicas, Amazon Aurora global databases และ Amazon DynamoDB global tables

3. Warm standby

รูปจาก docs.aws.amazon.com

• ฝั่ง DR region พร้อมทำงานหรือ handle workload ทันทีเมื่อเกิด failure เพราะเรา turn on infrastructure เอาไว้แล้วส่วนหนึ่ง
• เพียงแค่ scale up ส่วนที่เหลือให้พร้อมรับ production capacity
• Service ที่ใช้ เช่น Auto Scaling group หรือ Amazon ECS tasks เพื่อเพิ่ม workload capacity ให้รองรับ production ได้
• สามารถใช้ AWS SDK, CloudFormation หรือ tool อื่น ๆ ช่วยในการปรับ desired capacity เพื่อ scale up ด้วย automation ได้

4. Multi-site active/active

รูปจาก docs.aws.amazon.com

• สามารถ handle workload ได้ทั้งสองฝั่งพร้อมกัน (เป็น active/active) ควบคุมปริมาณ traffic ด้วย Amazon Route 53 (DNS) เช่น 70:30 หรือ 50:50
• หรือจะทำเป็น hot standby ก็ได้ (active แค่ region เดียว ส่วนฝั่ง DR region พร้อมทำงานแทนทุกเมื่อ) แต่ไม่นิยมใช้กัน
• ไม่จำเป็นต้องทำ failover แต่ต้องมีการทดสอบเพื่อให้แน่ใจว่าถ้าหาก region ฝั่งใดฝั่งหนึ่งเกิด failure ขึ้น อีกฝั่งจะสามารถ handle workload ได้
• ยังจำเป็นต้องทำ backup อยู่ เพราะอาจเกิด data corruption ได้อยู่ดี
• หากใช้งานแบบ active/active จะต้องมีการจัดการที่ดีเพื่อป้องกันเรื่อง write conflict ใน database ด้วย เช่น write global, write local และ write partitioned strategy
• ใช้ทุก service จากทุกแผนที่กล่าวมา เพิ่มในส่วนที่ช่วยสำหรับการ route traffic เช่น AWS Global Accelerator และ Amazon Route 53
• Route 53 สามารถใช้ทำ geoproximity หรือ latency based routing ได้ เช่น user ใกล้ region ไหนให้ route ไปยัง region นั้น หรือสามารถ route จาก latency ก็ได้
• ใช้ cost มากที่สุด ซับซ้อนที่สุด แต่ก็แทบจะไม่มี RTO (near zero)

ที่จริงยังอยากแนะนำ AWS service หรือ solution ที่สามารถนำมาช่วยในการทำ fully automated สำหรับ DR strategy ด้วย หากมีเวลาจะมาเขียนต่อครับ

ถ้าคิดว่าบทความนี้มีประโยชน์ ฝากกด clap, follow และ share บทความนี้ให้ผมด้วยนะครับ ขอบคุณมากครับ