Active-Active หลายไซต์ด้วย Global Tables และ Route 53
เรียกใช้กำลังการผลิตเต็มรูปแบบในสองรีเจียนขึ้นไปพร้อมกัน โดยใช้ DynamoDB Global Tables, Aurora Global Database และการกำหนดเส้นทางตามเวลาแฝงของ Route 53
Active-Active หลายไซต์ด้วย Global Tables และ Route 53 เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน
นิยามของ Multi-Site Active-Active
Multi-Site Active-Active คือระดับสูงสุดของการกู้คืนจากภัยพิบัติ โดยแอปพลิเคชันจะทำงานด้วยความสามารถรองรับการใช้งานจริงเต็มรูปแบบใน AWS regions ตั้งแต่สองแห่งขึ้นไปพร้อมกัน ต่างจาก active-passive ที่มีระบบสำรองรอเข้ารับช่วงต่อ ใน active-active ทั้งสอง Region จะให้บริการทราฟฟิกของผู้ใช้จริงตลอดเวลา เมื่อ Region หนึ่งล้มเหลว อีก Region จะรองรับทราฟฟิก 100% ได้ทันทีโดยไม่ต้องเสียเวลาสลับระบบ รูปแบบนี้ยังช่วยลดความหน่วงให้ผู้ใช้ทั่วโลกด้วยการให้บริการจาก Region ที่อยู่ใกล้ที่สุด
# Active-Active traffic split (normal operation):
# us-east-1: serving ~50% of users (North America)
# eu-west-1: serving ~50% of users (Europe)
# Active-Active traffic split (us-east-1 failure):
# us-east-1: 0% (health check failed)
# eu-west-1: 100% (ASG scales up automatically)
# RTO: near-zero (DNS TTL propagation only)
# RPO: near-zero (with DynamoDB Global Tables)สถาปัตยกรรม DynamoDB Global Tables
DynamoDB Global Tables เป็นโครงสร้างหลักด้านข้อมูลของสถาปัตยกรรม active-active Global Tables รองรับการจำลองแบบหลายมาสเตอร์ข้ามหลาย Region — แอปพลิเคชันในทุก Region สามารถอ่านและเขียนไปยังตาราง DynamoDB ในพื้นที่ของตน และการเปลี่ยนแปลงจะถูกจำลองไปยัง Region อื่นทั้งหมดภายในเวลาประมาณ 1 วินาที คุณเปิดใช้งาน Global Tables ได้โดยระบุว่าให้มีตารางอยู่ใน Region ใดบ้าง AWS จะจัดการการจำลองแบบ การแก้ไขข้อขัดแย้ง (ผู้เขียนล่าสุดมีสิทธิ์ชนะ) และการสลับระบบโดยอัตโนมัติ
# Create DynamoDB table and add global regions
aws dynamodb create-table \
--table-name UserSessions \
--attribute-definitions AttributeName=userId,AttributeType=S \
--key-schema AttributeName=userId,KeyType=HASH \
--billing-mode PAY_PER_REQUEST \
--region us-east-1
# Add replica regions for Global Table
aws dynamodb update-table \
--table-name UserSessions \
--replica-updates '[{"Create":{"RegionName":"eu-west-1"}},{"Create":{"RegionName":"ap-southeast-1"}}]' \
--region us-east-1Aurora Global Database สำหรับการอ่านแบบแอ็กทีฟและการเขียน
Aurora Global Database รองรับการอ่านแบบ active-active แต่การเขียนแบบ active-passive Region รองทั้งหมดให้บริการการอ่านโดยมีความล่าช้าจากการจำลองแบบต่ำกว่า 1 วินาที ขณะที่มีเพียง Region หลักเท่านั้นที่รับการเขียนได้ รูปแบบนี้เหมาะสำหรับแอปพลิเคชันที่เน้นการอ่านและต้องการการอ่านทั่วโลกที่มีความหน่วงต่ำ โดยมี Region หลักสำหรับการเขียนที่ชัดเจน หาก Region หลักล้มเหลว คุณสามารถเลื่อนระดับ Region รองให้เป็น Region หลักได้ภายในเวลาไม่ถึง 1 นาที ทำให้ RTO ของชั้นการเขียนต่ำ เปรียบเทียบกับ DynamoDB Global Tables ซึ่งรองรับการเขียนแบบ active-active ในทุก Region
# Aurora Global Database read configuration
# Primary region (us-east-1): reads + writes
# Secondary region (eu-west-1): reads only
# ~100ms replication lag, serves EU users low-latency reads
# Application reads from local Aurora endpoint
# Application writes to primary region Aurora endpoint
# Java connection string with region routing:
# readEndpoint=eu-west-1.cluster-ro-xxx.aurora.amazonaws.com
# writeEndpoint=us-east-1.cluster-xxx.aurora.amazonaws.comการกำหนดเส้นทางของ Route 53 สำหรับ Active-Active
Route 53 เป็นตัวจัดการทราฟฟิกสำหรับสถาปัตยกรรม active-active แบบหลายไซต์ ใช้การกำหนดเส้นทางตามความหน่วงเพื่อส่งผู้ใช้แต่ละรายไปยัง Region ที่มีความหน่วงเครือข่ายต่ำที่สุดจากตำแหน่งของผู้ใช้ แนบhealth checksไว้กับระเบียนของแต่ละ Region — เมื่อ Region ใดไม่ผ่าน health check, Route 53 จะนำ Region นั้นออกจากการตอบกลับ DNS โดยอัตโนมัติ และส่งทราฟฟิกทั้งหมดไปยัง Region อื่นที่ยังทำงานปกติ ตั้งค่า DNS TTL เป็น 60 วินาทีหรือน้อยกว่า เพื่อลดเวลาที่ผู้ใช้ต้องรอให้ระบบสลับไปยัง Region ที่ยังทำงานปกติ
# Route 53 latency routing with health checks
aws route53 change-resource-record-sets \
--hosted-zone-id ZXXX \
--change-batch '{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"Region": "us-east-1",
"SetIdentifier": "us-east-1",
"HealthCheckId": "hc-us-east-1",
"AliasTarget": {"DNSName": "alb-us-east-1.amazonaws.com", "EvaluateTargetHealth": false}
}
}
]
}'Auto Scaling สำหรับรองรับทราฟฟิกที่เพิ่มขึ้น
เมื่อ Region หนึ่งล้มเหลวในการตั้งค่า active-active, Region ที่ยังทำงานอยู่ต้องรองรับทราฟฟิกเพิ่มเป็น 2 เท่าหรือมากกว่าปริมาณปกติ Auto Scaling Group ของคุณต้องมีความจุสูงสุดเพียงพอและมีนโยบายเพิ่มขนาดที่ตอบสนองได้รวดเร็ว กำหนดค่าการปรับขนาดตามเป้าหมายโดยอิงจากจำนวนคำขอของ ALB ต่อตัวเป้าหมาย เพื่อให้ ASG เพิ่มอินสแตนซ์โดยอัตโนมัติเมื่อทราฟฟิกเพิ่มเป็นสองเท่า นอกจากนี้ควรพิจารณาการเตรียมความพร้อมล่วงหน้า: ระหว่างการซ้อมสลับระบบ ให้สังเกตว่า ASG เพิ่มขนาดได้เร็วเพียงใด และตรวจสอบว่าสามารถไปถึงความจุที่ต้องการได้ภายในเป้าหมาย RTO
# ASG target tracking for request count
aws autoscaling put-scaling-policy \
--auto-scaling-group-name app-asg-eu-west-1 \
--policy-name scale-on-requests \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 1000,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
},
"ScaleInCooldown": 60,
"ScaleOutCooldown": 30
}'การจัดการเซสชันใน Active-Active
ในสถาปัตยกรรมแบบ Region เดียว เซสชันของผู้ใช้สามารถจัดเก็บไว้ในเครื่องเซิร์ฟเวอร์แอปพลิเคชันได้ แต่ใน active-active แบบหลาย Region ผู้ใช้อาจถูกส่งสลับไปมาระหว่าง Region ในคำขอถัด ๆ ไป ทำให้เซสชันฝั่งเซิร์ฟเวอร์ใช้งานไม่ได้ แนวทางแก้ไขมีดังนี้: 1) เซสชันไร้สถานะ — จัดเก็บข้อมูลเซสชันไว้ใน JWT ที่มีลายเซ็นหรือคุกกี้ ซึ่งเซิร์ฟเวอร์ใด ๆ ใน Region ใด ๆ ก็ตรวจสอบได้ 2) DynamoDB Global Tables สำหรับเซสชัน — จัดเก็บเซสชันไว้ส่วนกลางและเข้าถึงได้ภายในระดับมิลลิวินาทีจากทุก Region 3) ElastiCache with Global Datastore — จำลองแบบ Redis ข้าม Region เพื่อจัดเก็บเซสชัน
# DynamoDB Global Table for session storage
# Session item structure:
{
'sessionId': 'sess-abc123',
'userId': 'usr-456',
'data': {'cart': [...], 'preferences': {}},
'expiresAt': 1750000000,
'lastUpdatedRegion': 'us-east-1'
}
# Application reads from local region DynamoDB
# Writes replicate to all regions within ~1 second
# No sticky sessions needed on the ALBข้อขัดแย้งในการเขียนและการแก้ไข
ความท้าทายที่ใหญ่ที่สุดของ active-active ที่รองรับการเขียนแบบหลายมาสเตอร์คือข้อขัดแย้งในการเขียน หากผู้ใช้สองรายในคนละ Region แก้ไขระเบียนเดียวกันพร้อมกัน การแก้ไขใดควรมีผล DynamoDB Global Tables ใช้หลักผู้เขียนล่าสุดมีสิทธิ์ชนะโดยอิงจากเวลาที่เขียน วิธีนี้เหมาะกับกรณีใช้งานส่วนใหญ่ แต่การแก้ไขที่แข่งขันกันอาจทำให้ข้อมูลสูญหายได้ (เช่น ผู้ใช้สองรายเพิ่มค่าตัวนับพร้อมกัน) ออกแบบโมเดลข้อมูลเพื่อหลีกเลี่ยงการเขียนรายการเดียวกันพร้อมกันจากคนละ Region โดยใช้การเขียนแบบมีเงื่อนไขหรือแบ่งความเป็นเจ้าของข้อมูลตาม Region
# Avoid conflicts with conditional writes
aws dynamodb update-item \
--table-name UserProfiles \
--key '{"userId":{"S":"usr-123"}}' \
--update-expression 'SET profileVersion = profileVersion + :inc, username = :name' \
--condition-expression 'profileVersion = :expectedVersion' \
--expression-attribute-values '{
":inc":{"N":"1"},
":name":{"S":"newname"},
":expectedVersion":{"N":"5"}
}'
# If another region already updated version, this fails gracefullyการจำลองแบบ S3 ใน Active-Active
สำหรับการจัดเก็บออบเจ็กต์ใน active-active ให้ใช้ S3 Cross-Region Replication with bidirectional replication (พร้อมใช้งานในบักเก็ตที่เปิดใช้การกำหนดเวอร์ชัน) ต่างจาก CRR แบบทางเดียว การจำลองแบบสองทิศทางจะทำให้บักเก็ตของทั้งสอง Region ซิงค์ข้อมูลกัน — ออบเจ็กต์ที่เขียนใน Region ใดก็ตามจะถูกจำลองไปยังอีก Region โดยอัตโนมัติ สิ่งนี้สำคัญสำหรับแอปพลิเคชันที่เขียนไฟล์ที่ผู้ใช้อัปโหลดไปยังบักเก็ต S3 ใน Region ของตน แต่ต้องการให้เข้าถึงไฟล์เหล่านั้นได้ทั่วโลก เปิดใช้ S3 Replication Time Control (RTC) เพื่อรับประกันว่าออบเจ็กต์ 99.99% จะถูกจำลองภายใน 15 นาที
# Bidirectional S3 replication
# Bucket A (us-east-1) replicates to Bucket B (eu-west-1)
# Bucket B (eu-west-1) replicates to Bucket A (us-east-1)
# Enable S3 RTC for guaranteed replication time
aws s3api put-bucket-replication \
--bucket us-east-1-uploads \
--replication-configuration '{
"Rules": [{
"Status": "Enabled",
"ReplicationTime": {"Status": "Enabled", "Time": {"Minutes": 15}},
"Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}},
"Destination": {"Bucket": "arn:aws:s3:::eu-west-1-uploads"}
}]
}'CloudFront กับ Origin หลาย Region
ใช้ CloudFront with origin groups เพื่อสร้าง CDN แบบ active-active ที่มีการสลับระบบโดยอัตโนมัติ กำหนด Origin หลัก (ALB ใน us-east-1) และ Origin รอง (ALB ใน eu-west-1) CloudFront จะสลับไปยัง Origin รองโดยอัตโนมัติเมื่อ Origin หลักส่งคืนข้อผิดพลาด 5xx สำหรับไฟล์สแตติกที่ให้บริการจาก S3 ให้กำหนดกลุ่ม Origin ที่ชี้ไปยังบักเก็ต S3 ในหลาย Region ซึ่งมีการจำลองแบบสองทิศทาง วิธีนี้จะเพิ่มชั้นความทนทานระดับ CDN เหนือการกำหนดเส้นทาง active-active ของ Route 53
# CloudFront origin group for multi-region failover
aws cloudfront create-distribution \
--distribution-config '{
"Origins": {
"Quantity": 2,
"Items": [
{"Id": "us-east-1", "DomainName": "alb-us-east-1.amazonaws.com"},
{"Id": "eu-west-1", "DomainName": "alb-eu-west-1.amazonaws.com"}
]
},
"OriginGroups": {
"Items": [{
"Id": "multi-region-group",
"FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
"Members": {"Items": [{"OriginId": "us-east-1"},{"OriginId": "eu-west-1"}]}
}]
}
}'การตรวจสอบสถานะของ Active-Active
สถาปัตยกรรม active-active จำเป็นต้องมีการตรวจสอบที่มีประสิทธิภาพ เพื่อให้มั่นใจว่าทั้งสอง Region ทำงานปกติและกระจายทราฟฟิกได้ตามที่คาดไว้ Metrics สำคัญ ได้แก่ Route 53 HealthCheckPercentageHealthy ของแต่ละ Region, DynamoDB ReplicationLatency สำหรับตรวจสอบความล่าช้าของ Global Tables, ALB RequestCount ของแต่ละ Region เพื่อยืนยันการกระจายทราฟฟิก และ CloudWatch cross-account/cross-region dashboards สำหรับมุมมองรวม ตั้งค่า alarms เมื่อความล่าช้าของการจำลองแบบเกินค่า RPO หรือเมื่อการกระจายทราฟฟิกไม่สมดุลอย่างมาก
# CloudWatch alarm for DynamoDB Global Table replication lag
aws cloudwatch put-metric-alarm \
--alarm-name 'GlobalTable-ReplicationLag-eu-west-1' \
--metric-name ReplicationLatency \
--namespace AWS/DynamoDB \
--dimensions Name=TableName,Value=UserSessions Name=ReceivingRegion,Value=eu-west-1 \
--period 60 \
--evaluation-periods 3 \
--threshold 5000 \
--comparison-operator GreaterThanThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-alertsเมื่อใด Active-Active จึงเป็นตัวเลือกที่เหมาะสม
Active-active เหมาะสมเมื่อ: ผู้ใช้กระจายอยู่ทั่วโลก และความหน่วงในการเข้าถึง Region เดียวไม่เป็นที่ยอมรับ RTO ต้องใกล้ศูนย์ — ธุรกิจไม่สามารถยอมรับการหยุดให้บริการแม้เพียงไม่กี่นาที ปริมาณการเขียนสูงจำเป็นต้องกระจายการเขียนไปยังหลาย Region ข้อกำหนดด้านกฎระเบียบกำหนดให้ประมวลผลข้อมูลภายในประเทศ ค่าใช้จ่ายสูงกว่าระดับ DR อื่นอย่างมาก ดังนั้นควรเลือก active-active เฉพาะเมื่อข้อกำหนดทางธุรกิจและความคุ้มค่าทางเศรษฐศาสตร์สนับสนุนอย่างชัดเจน สำหรับเวิร์กโหลดจำนวนมาก Warm Standby ก็เพียงพอและมีค่าใช้จ่ายถูกกว่ามาก
# Active-Active justification checklist:
# [ ] Users in 2+ continents with latency SLAs
# [ ] RTO requirement < 5 minutes
# [ ] Revenue impact of downtime justifies 2x+ cost
# [ ] Data must remain within specific regions (regulations)
# [ ] Write throughput exceeds single-region capacity
# If fewer than 2-3 boxes checked:
# Consider Warm Standby instead (lower cost, adequate RTO)ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า DynamoDB Global Tables รองรับการเขียนแบบหลายมาสเตอร์ข้าม Region เพื่อให้เกิด active-active อย่างแท้จริง การกำหนดเส้นทางตามความหน่วงของ Route 53 ร่วมกับ health checks จะนำผู้ใช้ไปยัง Region ที่ใกล้ที่สุดและยังทำงานปกติ และ การจัดการเซสชันต้องเป็นแบบไร้สถานะหรือใช้พื้นที่จัดเก็บที่จำลองแบบทั่วโลกในระบบ active-active Active-active ให้ RTO และ RPO ใกล้ศูนย์ แต่มีค่าใช้จ่ายสูงกว่ามาก บทถัดไปเราจะศึกษาเสาหลัก Operational Excellence และ Security ของ Well-Architected Framework
คำถามที่พบบ่อย
บทเรียน “Active-Active หลายไซต์ด้วย Global Tables และ Route 53” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “Active-Active หลายไซต์ด้วย Global Tables และ Route 53” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “Active-Active หลายไซต์ด้วย Global Tables และ Route 53”
เรียกใช้กำลังการผลิตเต็มรูปแบบในสองรีเจียนขึ้นไปพร้อมกัน โดยใช้ DynamoDB Global Tables, Aurora Global Database และการกำหนดเส้นทางตามเวลาแฝงของ Route 53 คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “Active-Active หลายไซต์ด้วย Global Tables และ Route 53” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม
ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- RTO, RPO และระดับ DR
- การสำรองและกู้คืน
- ไพล็อตไลต์และระบบสำรองพร้อมใช้งาน
- Active-Active หลายไซต์ด้วย Global Tables และ Route 53