0Pricing
AWS Solutions Architect · บทเรียน

รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ

ใช้ Multi-AZ กับ RDS, ElastiCache, EFS และ ELB เพื่อกำจัดจุดล้มเหลวเพียงจุดเดียวภายในรีเจียน

รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดบริการแบบมีสถานะจึงต้องใช้หลาย AZ

บริการแบบมีสถานะ — ฐานข้อมูล แคช และระบบไฟล์ — เป็นส่วนประกอบที่ทำให้มีความพร้อมใช้งานสูงได้ยากที่สุด เพราะเก็บข้อมูลที่ต้องคงอยู่แม้เกิดความขัดข้อง หากฐานข้อมูลใน AZ เดียวขัดข้อง แอปพลิเคชันทั้งหมดจะสูญเสียแหล่งจัดเก็บข้อมูล AWS แก้ปัญหานี้ด้วย การติดตั้งแบบหลาย AZ ซึ่งบริการจะรักษาแบบจำลองข้อมูลแบบซิงโครนัสหรือเกือบซิงโครนัสไว้ใน Availability Zone ที่สอง เพื่อให้เข้ารับช่วงต่อได้อย่างรวดเร็วเมื่อระบบหลักขัดข้อง

RDS Multi-AZ: สแตนด์บายแบบซิงโครนัส

RDS Multi-AZ รักษาแบบจำลองสแตนด์บายแบบซิงโครนัสไว้ใน AZ อื่น การเขียนทุกครั้งไปยังระบบหลักจะถูกจำลองแบบซิงโครนัสก่อนยืนยันความสำเร็จ ซึ่งหมายความว่าจะไม่มีข้อมูลสูญหาย (RPO=0) แต่เวลาแฝงในการเขียนจะเพิ่มขึ้นเล็กน้อย เมื่อระบบหลักขัดข้อง RDS จะอัปเดตปลายทาง DNS โดยอัตโนมัติให้ชี้ไปยังสแตนด์บายภายใน 60-120 วินาที แอปพลิเคชันเพียงเชื่อมต่อใหม่ไปยังปลายทางเดิม โดยไม่ต้องแก้ไขโค้ด

# Enable Multi-AZ on existing RDS instance
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --multi-az \
  --apply-immediately

# RDS endpoint stays the same after failover
# Application reconnects to same DNS name

สถาปัตยกรรม Aurora Multi-AZ

Amazon Aurora ยกระดับ Multi-AZ ด้วย ชั้นจัดเก็บข้อมูลแบบกระจายที่ใช้ร่วมกัน ซึ่งจำลองข้อมูลโดยอัตโนมัติข้ามสาม AZ เป็นหกชุด อินสแตนซ์ของ Aurora ไม่มีสถานะ — อ่านและเขียนข้อมูลไปยังพื้นที่จัดเก็บร่วมนี้ เมื่อ Aurora writer หลักล้มเหลว read replica ใน AZ อื่นจะได้รับการเลื่อนบทบาทเป็น writer ภายในเวลาไม่ถึง 30 วินาที ซึ่งเร็วกว่าการสลับการทำงานของ RDS Multi-AZ และข้อมูลจะสอดคล้องกันเสมอในทุก AZ โดยไม่ต้องตั้งค่าการจำลอง Standby อย่างชัดเจน

# Aurora cluster endpoint automatically handles failover
# Writer endpoint: mydb.cluster-xxx.us-east-1.rds.amazonaws.com
# Reader endpoint: mydb.cluster-ro-xxx.us-east-1.rds.amazonaws.com

# Failover time: typically under 30 seconds

การจำลองแบบ Multi-AZ ของ ElastiCache

ElastiCache for Redis รองรับ Multi-AZ ผ่าน กลุ่มการจำลอง โหนดหลักรับการเขียนและจำลองข้อมูลแบบ Asynchronous ไปยัง read replicas ใน AZ อื่น เมื่อโหนดหลักล้มเหลว ElastiCache จะเลื่อน replica ขึ้นเป็นโหนดหลักโดยอัตโนมัติ สำหรับ Redis ที่เปิดใช้ โหมดคลัสเตอร์ ข้อมูลจะถูกแบ่งออกเป็นกลุ่มโหนดหลายกลุ่ม โดยแต่ละกลุ่มมีโหนดหลักและ replicas ของตนเองกระจายอยู่ใน AZ ต่าง ๆ ซึ่งให้ทั้ง HA และการขยายระบบในแนวนอน

# Create Redis replication group with Multi-AZ
aws elasticache create-replication-group \
  --replication-group-id my-redis \
  --replication-group-description 'Multi-AZ Redis' \
  --num-cache-clusters 3 \
  --cache-node-type cache.r6g.large \
  --multi-az-enabled \
  --automatic-failover-enabled

EFS: เป็น Multi-AZ โดยธรรมชาติ

Amazon Elastic File System (EFS) เป็น Multi-AZ โดยธรรมชาติ เนื่องจากเป็นบริการระดับภูมิภาคที่จัดเก็บข้อมูลแบบซ้ำซ้อนในหลาย AZ ภายในภูมิภาคเดียวกัน คุณสร้าง เป้าหมายการเมานต์ ในซับเน็ตของแต่ละ AZ และอินสแตนซ์ EC2 ใน AZ ใดก็สามารถเมานต์ระบบไฟล์ผ่านเป้าหมายการเมานต์ภายใน AZ ของตนได้ โดยไม่จำเป็นต้องตั้งค่า Multi-AZ ด้วยตนเอง EFS ให้บริการพื้นที่จัดเก็บไฟล์แบบ POSIX ที่ใช้ร่วมกัน ซึ่งหลายอินสแตนซ์ใน AZ ต่าง ๆ สามารถเข้าถึงได้พร้อมกัน

# Mount EFS from EC2 in any AZ
# Mount target is created per AZ automatically
sudo mount -t efs -o tls fs-12345678:/ /mnt/efs

# Or use EFS mount helper
sudo mount -t efs fs-12345678 /mnt/efs

Elastic Load Balancer แบบข้ามโซน

Elastic Load Balancers เป็น Multi-AZ ในตัว โดย ALB และ NLB จะติดตั้งโหนดตัวจัดสรรโหลดในแต่ละ AZ ที่คุณระบุ เมื่อ เปิดใช้การจัดสรรโหลดข้ามโซน (เป็นค่าเริ่มต้นสำหรับ ALB) โหนดตัวจัดสรรโหลดแต่ละโหนดจะแบ่งทราฟฟิกอย่างเท่าเทียมไปยังเป้าหมายที่ลงทะเบียนไว้ทั้งหมดในทุก AZ ไม่ใช่เฉพาะ AZ ของตนเอง วิธีนี้ช่วยให้แม้ว่าอินสแตนซ์ทั้งหมดใน AZ หนึ่งจะล้มเหลว ตัวจัดสรรโหลดก็ยังคงให้บริการทราฟฟิกผ่านอินสแตนซ์ใน AZ ที่เหลือได้

# ALB automatically created in multiple AZs
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-AZ1 subnet-AZ2 subnet-AZ3 \
  --security-groups sg-12345

# Cross-zone load balancing is ON by default for ALB

รูปแบบ NAT Gateway แบบ Multi-AZ

ข้อผิดพลาดที่พบบ่อยคือการติดตั้ง NAT Gateway เพียงรายการเดียวใน AZ หนึ่ง ขณะที่ซับเน็ตส่วนตัวใน AZ อื่นกำหนดเส้นทางผ่าน Gateway นั้น หาก AZ ดังกล่าวล้มเหลว อินสแตนซ์ส่วนตัวทั้งหมดจะสูญเสียการเข้าถึงอินเทอร์เน็ต รูปแบบ Multi-AZ ที่ถูกต้องคือการติดตั้ง NAT Gateway หนึ่งรายการต่อ AZ และกำหนดตารางเส้นทางส่วนตัวของแต่ละ AZ ให้ส่งเส้นทาง 0.0.0.0/0 ผ่าน NAT Gateway ของตนเอง วิธีนี้กำจัด NAT Gateway ไม่ให้เป็น SPOF ระหว่าง AZ และลดค่าใช้จ่ายการถ่ายโอนข้อมูลระหว่าง AZ

# Create NAT Gateway in each AZ
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ1 \
  --allocation-id eipalloc-AZ1

aws ec2 create-nat-gateway \
  --subnet-id subnet-public-AZ2 \
  --allocation-id eipalloc-AZ2

# Each AZ's private route table points to its own NAT GW

DynamoDB เป็น Multi-AZ โดยค่าเริ่มต้น

DynamoDB เป็นบริการที่จัดการให้ทั้งหมด และจำลองข้อมูลโดยอัตโนมัติข้าม สาม AZ ภายในภูมิภาคเดียวกัน คุณจึงไม่ต้องตั้งค่า Multi-AZ ด้วยตนเอง การเขียนทุกครั้งจะถูกจัดเก็บอย่างคงทนในทั้งสาม AZ ก่อนส่งคืนผลสำเร็จ DynamoDB จึงทนต่อความขัดข้องในระดับ AZ ได้โดยพื้นฐาน นี่เป็นเหตุผลที่มักแนะนำให้เลือก DynamoDB เป็น Database เมื่อข้อสอบเน้นความพร้อมใช้งานสูงโดยมีภาระการดำเนินงานน้อยที่สุด

RDS Proxy เพื่อจัดการการเชื่อมต่อได้เร็วขึ้น

ระหว่างการสลับการทำงานของ RDS Multi-AZ แอปพลิเคชันที่รักษาการเชื่อมต่อ Database แบบต่อเนื่องอาจพบความล้มเหลวเมื่อ Endpoint เปลี่ยนแปลง RDS Proxy ทำหน้าที่อยู่ระหว่างแอปพลิเคชันกับ RDS และรักษากลุ่มการเชื่อมต่อไปยัง Database ระหว่างการสลับการทำงาน RDS Proxy จะกำหนดเส้นทางใหม่ไปยัง Primary ใหม่โดยอัตโนมัติ ซึ่งลดผลกระทบจากการสลับการทำงานจาก 60–120 วินาทีเหลือ ไม่ถึง 30 วินาที สำหรับแอปพลิเคชันที่ใช้ Endpoint ของ Proxy นอกจากนี้ RDS Proxy ยังช่วยจัดการฟังก์ชัน Lambda ที่สร้างการเชื่อมต่ออายุสั้นจำนวนมาก

# Application connects to RDS Proxy endpoint
# Proxy endpoint: myproxy.proxy-xxx.us-east-1.rds.amazonaws.com

# RDS Proxy handles:
# - Connection pooling
# - Failover routing
# - IAM authentication
# - Secrets Manager integration

โหมดการจำลองข้อมูล: แบบ Synchronous กับ Asynchronous

การทำความเข้าใจโหมดการจำลองข้อมูลมีความสำคัญอย่างยิ่งต่อการเลือกรูปแบบ Multi-AZ การจำลองแบบ Synchronous (RDS Multi-AZ, EFS) รับประกัน RPO=0 เนื่องจากการเขียนทุกครั้งจะได้รับการยืนยันในทั้งสอง AZ ก่อนส่งคืนผลสำเร็จ ข้อแลกเปลี่ยนคือเวลาแฝงในการเขียนที่สูงขึ้นเล็กน้อย การจำลองแบบ Asynchronous (replicas ของ ElastiCache Redis, RDS Read Replicas) ให้เวลาแฝงในการเขียนต่ำกว่า แต่ยอมรับความล่าช้าในการจำลองข้อมูลเล็กน้อย ซึ่งหมายความว่าข้อมูลบางส่วนอาจสูญหายได้ หากโหนดหลักล้มเหลวก่อนที่การจำลองจะเสร็จสมบูรณ์

# Synchronous replication: RPO = 0, higher write latency
# Used by: RDS Multi-AZ, Aurora storage layer

# Asynchronous replication: RPO > 0 (replication lag)
# Used by: RDS Read Replicas, ElastiCache Redis replicas
# Replication lag can be monitored:
# aws cloudwatch get-metric-statistics \
#   --namespace AWS/RDS --metric-name ReplicaLag

การทดสอบการสลับการทำงานของ Multi-AZ

คุณควรทดสอบการสลับการทำงานของ Multi-AZ เป็นประจำ เพื่อตรวจสอบสมมติฐานเกี่ยวกับ RTO สำหรับ RDS คุณสามารถเรียกใช้การสลับการทำงานโดยใช้ตัวเลือก Reboot with failover ในคอนโซลหรือใช้ CLI ตรวจสอบ CloudWatch สำหรับเมตริก FailedSQLServerAgentJobsCount และตรวจดูบันทึกของแอปพลิเคชันเพื่อยืนยันว่าแอปพลิเคชันเชื่อมต่อใหม่สำเร็จ จัดทำเอกสารระยะเวลาการสลับการทำงานที่เกิดขึ้นจริง เนื่องจากอาจแตกต่างจากเอกสารของ AWS ตามคลาสของอินสแตนซ์และภาระงานของคุณ

# Trigger RDS Multi-AZ failover test
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

# Monitor failover in CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=mydb

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า RDS Multi-AZ ใช้การจำลองแบบ Synchronous พร้อมการสลับ DNS โดยอัตโนมัติ Aurora ใช้ชั้นจัดเก็บข้อมูลร่วมกันในสาม AZ เพื่อการสลับการทำงานที่เร็วขึ้น และ EFS กับ DynamoDB เป็น Multi-AZ โดยธรรมชาติโดยไม่ต้องตั้งค่าด้วยตนเอง ติดตั้ง NAT Gateway หนึ่งรายการต่อ AZ เพื่อหลีกเลี่ยง SPOF ระหว่าง AZ บทถัดไป เราจะสำรวจรูปแบบ Active-Active และ Active-Passive แบบหลายภูมิภาค

คำถามที่พบบ่อย

บทเรียน “รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ”

ใช้ Multi-AZ กับ RDS, ElastiCache, EFS และ ELB เพื่อกำจัดจุดล้มเหลวเพียงจุดเดียวภายในรีเจียน คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. HA เทียบกับความทนทานต่อข้อขัดข้อง: นิยามและข้อแลกเปลี่ยน
  2. รูปแบบ Multi-AZ สำหรับบริการที่มีสถานะ
  3. Active-Active และ Active-Passive แบบหลายรีเจียน
  4. การตรวจสอบสุขภาพ เซอร์กิตเบรกเกอร์ และตรรกะการลองใหม่
← กลับไปที่ AWS Solutions Architect