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

กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์

สร้างกลุ่มการจำลองข้อมูล Redis เพื่อเพิ่มความสามารถในการอ่าน และเปิดใช้โหมดคลัสเตอร์เพื่อแบ่งข้อมูลข้ามกลุ่มโหนดหลายกลุ่ม

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

ภาพรวมกลุ่มการจำลองข้อมูลของ Redis

กลุ่มการจำลองข้อมูลของ ElastiCache คือการจัดกลุ่มเชิงตรรกะของโหนด Redis หลักหนึ่งโหนดและ แบบจำลองสำหรับอ่านสูงสุด 5 โหนด โหนดหลักจัดการการดำเนินการเขียนทั้งหมด ส่วนแบบจำลองจะรับการจำลองข้อมูลแบบอะซิงโครนัสจากโหนดหลักและให้บริการทราฟฟิกการอ่าน กลุ่มการจำลองข้อมูลเปิดใช้ความสามารถสำคัญสองประการ ได้แก่ การขยายการอ่าน (กระจายคำขออ่านไปยังแบบจำลองหลายโหนด) และ ความพร้อมใช้งานสูงพร้อมการสลับระบบอัตโนมัติ (เลื่อนแบบจำลองขึ้นเป็นโหนดหลักหากโหนดหลักขัดข้อง) โหนดทั้งหมดในกลุ่มการจำลองข้อมูลใช้ชุดข้อมูลเดียวกัน

# Create a replication group with 1 primary and 2 read replicas
aws elasticache create-replication-group \
  --replication-group-id web-cache \
  --replication-group-description 'Web application cache' \
  --num-cache-clusters 3 \
  --cache-node-type cache.r7g.large \
  --engine redis \
  --engine-version '7.0' \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --cache-subnet-group-name my-multi-az-subnet-group

Primary Endpoint เทียบกับ Reader Endpoint

ElastiCache มี DNS Endpoint สองรายการสำหรับกลุ่มการจำลองข้อมูล: Primary Endpoint จะชี้ไปยังโหนดหลักปัจจุบันเสมอ (อัปเดตโดยอัตโนมัติระหว่างการสลับระบบ) — ใช้รายการนี้สำหรับการดำเนินการเขียนทั้งหมด ส่วน Reader Endpoint จะกระจายโหลดคำขออ่านไปยังแบบจำลองทั้งหมดที่พร้อมใช้งาน — ใช้รายการนี้สำหรับการดำเนินการอ่านเพื่อกระจายภาระ แอปพลิเคชันของคุณควรรักษากลุ่มการเชื่อมต่อไว้สองกลุ่ม ได้แก่ กลุ่มหนึ่งสำหรับ Primary Endpoint เพื่อการเขียน และอีกกลุ่มสำหรับ Reader Endpoint เพื่อการอ่าน นี่คือรูปแบบการเชื่อมต่อที่แนะนำสำหรับกลุ่มการจำลองข้อมูล Redis ของ ElastiCache

# Get primary and reader endpoints
aws elasticache describe-replication-groups \
  --replication-group-id web-cache \
  --query 'ReplicationGroups[].{
    Primary:NodeGroups[].PrimaryEndpoint.Address,
    Reader:ReaderEndpoint.Address
  }'

# Application connection pattern:
# write_client = redis.Redis(host='primary-endpoint', port=6379)
# read_client = redis.Redis(host='reader-endpoint', port=6379)

กระบวนการสลับระบบอัตโนมัติ

เมื่อโหนดหลักขัดข้อง (ElastiCache ตรวจพบภายในไม่กี่วินาทีผ่านการตรวจสอบสถานะ) การสลับระบบอัตโนมัติจะเลือกแบบจำลองสำหรับอ่านหนึ่งโหนดเพื่อเลื่อนขึ้นเป็นโหนดหลัก กระบวนการเลื่อนตำแหน่งมีดังนี้: (1) แบบจำลองที่เลือกจะถูกเลื่อนขึ้นเป็นโหนดหลัก, (2) ระเบียน DNS ของ Primary Endpoint จะได้รับการอัปเดตให้ชี้ไปยังโหนดหลักใหม่ (TTL ประมาณ 1 วินาที) และ (3) โหนดหลักเดิมจะถูกแทนที่ด้วยแบบจำลองใหม่ เวลาสลับระบบทั้งหมดโดยทั่วไปอยู่ที่ 30–60 วินาที แอปพลิเคชันที่ใช้ DNS ของ Primary Endpoint จะเชื่อมต่อใหม่โดยอัตโนมัติเมื่อ DNS แพร่กระจาย — ไม่จำเป็นต้องฮาร์ดโค้ดที่อยู่ IP

# Test failover manually (triggers primary failover)
aws elasticache test-failover \
  --replication-group-id web-cache \
  --node-group-id 0001

# Monitor failover events
aws elasticache describe-events \
  --source-identifier web-cache \
  --source-type replication-group \
  --duration 60 \
  --query 'Events[].{Time:Date,Message:Message}'

การวางตำแหน่งแบบจำลองข้าม Multi-AZ

เพื่อความทนทานสูงสุด ให้กระจายแบบจำลองไปยัง Availability Zones หลายแห่ง เมื่อคุณเปิดใช้ Multi-AZ กับกลุ่มการจำลองข้อมูล ElastiCache จะวางโหนดหลักและแบบจำลองไว้ใน AZ ที่แตกต่างกันโดยอัตโนมัติ หาก AZ ทั้งหมดหยุดทำงาน การสลับระบบจะเลื่อนแบบจำลองจาก AZ ที่ยังทำงานอยู่ขึ้นเป็นโหนดหลัก คุณยังสามารถระบุ AZ ที่ต้องการสำหรับแต่ละโหนดได้อย่างชัดเจนขณะสร้างกลุ่มการจำลองข้อมูล โดยใช้ตัวเลือก --preferred-cache-cluster-a-zs

# Create replication group with explicit AZ placement
aws elasticache create-replication-group \
  --replication-group-id ha-redis \
  --replication-group-description 'Multi-AZ Redis' \
  --num-cache-clusters 3 \
  --cache-node-type cache.r7g.xlarge \
  --engine redis \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --preferred-cache-cluster-a-zs us-east-1a us-east-1b us-east-1c \
  --cache-subnet-group-name multi-az-subnets

Redis Cluster Mode คืออะไร

Redis Cluster Mode Enabled (CME) จะแบ่งชุดข้อมูลออกเป็นหลาย กลุ่มโหนด (ส่วนแบ่ง) โดยแต่ละกลุ่มประกอบด้วยโหนดหลักหนึ่งโหนดและแบบจำลองสูงสุด 5 โหนด นี่คือโซลูชันการแบ่งส่วนในแนวนอนของ Redis Cluster Mode ช่วยให้คุณใช้หน่วยความจำได้เกินขีดจำกัดของโหนดเดียว โดยสามารถมีกลุ่มโหนดได้สูงสุด 500 กลุ่ม แต่ละกลุ่มมีขนาด 500 GB ทำให้คลัสเตอร์ Redis เดียวจัดเก็บข้อมูลได้สูงสุด 500 × 500 GB = 250 TB นอกจากนี้ Cluster Mode ยังเพิ่มปริมาณงานเขียนได้หลายเท่า เนื่องจากแต่ละกลุ่มโหนดประมวลผลการเขียนสำหรับช่วงคีย์ของตนเองอย่างอิสระ

# Create a Redis Cluster Mode Enabled replication group
# with 3 shards, each with 1 primary and 2 replicas
aws elasticache create-replication-group \
  --replication-group-id clustered-redis \
  --replication-group-description 'Cluster mode: 3 shards x 3 nodes' \
  --num-node-groups 3 \
  --replicas-per-node-group 2 \
  --cache-node-type cache.r7g.large \
  --engine redis \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --cache-subnet-group-name multi-az-subnets

ช่องแฮชและการกระจายคีย์

Redis Cluster Mode แบ่งพื้นที่คีย์ออกเป็น ช่องแฮช 16,384 ช่อง แต่ละกลุ่มโหนดเป็นเจ้าของช่วงช่องแฮชที่ต่อเนื่องกัน เมื่อมีการเขียนคีย์ Redis จะคำนวณ CRC16(key) % 16384 เพื่อระบุช่องแฮชและกลุ่มโหนดที่รับผิดชอบ ดังนั้นแอปพลิเคชันของคุณต้องใช้ ไคลเอ็นต์ Redis ที่รองรับคลัสเตอร์ (เช่น redis-py-cluster หรือ Jedis ในโหมดคลัสเตอร์) ซึ่งรู้จักแผนผังช่องและส่งแต่ละคำสั่งไปยังโหนดที่ถูกต้อง ไคลเอ็นต์มาตรฐานจะส่งคืนข้อผิดพลาดการเปลี่ยนเส้นทาง MOVED หากส่งคีย์ไปยังส่วนที่ไม่ถูกต้อง

# Python cluster-aware client example
# pip install redis[hiredis]

# from redis.cluster import RedisCluster
# cluster_client = RedisCluster(
#   host='clustered-redis.abc123.clustercfg.use1.cache.amazonaws.com',
#   port=6379,
#   decode_responses=True
# )

# The client automatically resolves slot-to-node mapping
# cluster_client.set('user:1', 'Alice')   # routes to correct shard
# cluster_client.get('user:1')            # routes to correct shard

โหมดคลัสเตอร์เทียบกับโหมดที่ไม่ใช่คลัสเตอร์

สำหรับการสอบ SAA-C03 ให้เลือก โหมดที่ไม่ใช่คลัสเตอร์ เมื่อ: ข้อมูลของคุณพอดีกับโหนดเดียว (< ประมาณ 400 GB หลังกันพื้นที่สำรอง), คุณต้องการการตั้งค่าโหนดหลัก/แบบจำลองที่เรียบง่าย หรือแอปพลิเคชันใช้การดำเนินการหลายคีย์ที่ซับซ้อน (ธุรกรรมที่ครอบคลุมหลายคีย์กำหนดให้คีย์ทั้งหมดอยู่ในช่องเดียวกัน) ให้เลือก โหมดคลัสเตอร์ เมื่อ: ชุดข้อมูลมีขนาดเกินหน่วยความจำของโหนดเดียว, คุณต้องการเพิ่มปริมาณงานเขียนในแนวนอน หรือคาดว่าจะเติบโตในอนาคตจนต้องแบ่งส่วนข้อมูลใหม่ขณะระบบออนไลน์ โหมดคลัสเตอร์รองรับการเพิ่มส่วนแบ่งโดยไม่หยุดทำงาน (การแบ่งส่วนข้อมูลใหม่ขณะระบบออนไลน์)

# Scale out a cluster-mode Redis by adding shards
aws elasticache modify-replication-group-shard-configuration \
  --replication-group-id clustered-redis \
  --node-group-count 5 \
  --apply-immediately \
  --resharding-configuration \
    NodeGroupId=0004,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
    NodeGroupId=0005,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c

# No downtime — slots are migrated incrementally

Global Datastore สำหรับการจำลองข้อมูลข้ามภูมิภาค

ElastiCache Global Datastore ขยายการจำลองข้อมูลของ Redis ไปยังหลายภูมิภาคของ AWS โดยกำหนดให้ภูมิภาคหนึ่งเป็นคลัสเตอร์หลัก และเพิ่มคลัสเตอร์รองในภูมิภาคอื่น ๆ การเขียนข้อมูลจะส่งไปยังคลัสเตอร์หลัก ส่วนคลัสเตอร์รองจะได้รับการจำลองข้อมูลแบบไม่พร้อมกัน โดยทั่วไปมีความล่าช้าต่ำกว่า 1 วินาที คลัสเตอร์รองสามารถให้บริการการอ่านข้อมูลในภูมิภาคของตนเองได้ด้วยความหน่วงต่ำมาก Global Datastore รองรับแอปพลิเคชันระดับโลก ซึ่งผู้ใช้ในทวีปต่าง ๆ อ่านข้อมูลจากภูมิภาคที่ใกล้ที่สุด และรองรับ DR ข้ามภูมิภาค ซึ่งคุณสามารถเลื่อนระดับคลัสเตอร์รองให้เป็นคลัสเตอร์หลักได้หากภูมิภาคหลักล้มเหลว

# Create a Global Datastore (adds a secondary region to an existing cluster)
aws elasticache create-global-replication-group \
  --global-replication-group-id-suffix my-global-cache \
  --primary-replication-group-id prod-redis

# Add a secondary cluster in another region
aws elasticache create-replication-group \
  --replication-group-id prod-redis-eu \
  --replication-group-description 'EU secondary' \
  --global-replication-group-id ldgnf-my-global-cache \
  --region eu-west-1

Redis Pub/Sub ในระดับขนาดใหญ่

ในกลุ่มการจำลองข้อมูลของ Redis ที่ไม่ได้ใช้คลัสเตอร์ ข้อความ pub/sub จะถูกกระจายไปยังแบบจำลองทั้งหมด — ผู้สมัครรับข้อมูลบนโหนดใด ๆ ก็จะได้รับข้อความที่เผยแพร่ไปยังช่องนั้น อย่างไรก็ตาม ในโหมดคลัสเตอร์ pub/sub จะจำกัดอยู่ที่การแจ้งเตือนคีย์สเปซ และ pub/sub ตามช่องจะทำงานได้เฉพาะภายในชาร์ดเดียว เว้นแต่คุณจะใช้ Redis 7+ ที่รองรับการแบ่งชาร์ดสำหรับ Pub/Sub (SSUBSCRIBE / SPUBLISH สำหรับ pub/sub ที่รับรู้ชาร์ด) ข้อจำกัดนี้สำคัญเมื่อออกแบบ pub/sub ในระดับขนาดใหญ่โดยใช้โหมดคลัสเตอร์

# Keyspace notification (fires when a key expires)
# Enable in parameter group: notify-keyspace-events Ex

# Subscriber in Python:
# pubsub = redis_client.pubsub()
# pubsub.psubscribe('__keyevent@0__:expired')
# for message in pubsub.listen():
#     if message['type'] == 'pmessage':
#         expired_key = message['data']
#         print(f'Key expired: {expired_key}')

การตรวจสอบความล่าช้าของการจำลองข้อมูล

ตรวจสอบเมตริก ReplicationLag ของ CloudWatch บนแบบจำลองสำหรับการอ่าน เพื่อให้แน่ใจว่าแบบจำลองทำงานตามคลัสเตอร์หลักได้ทัน ความล่าช้าที่มากกว่าสองสามวินาทีบ่งชี้ว่ามีคอขวดที่แบบจำลอง เช่น โหนดทำงานหนักเกินไป ปัญหาเครือข่าย หรือมีการเขียนข้อมูลมากเกินกว่าที่แบบจำลองจะประมวลผลได้ ในสถานการณ์ที่ใช้ Global Datastore ให้ตรวจสอบ GlobalDatastoreReplicationLag ด้วย ความล่าช้าของการจำลองข้อมูลที่สูงหมายความว่าแบบจำลองสำหรับการอ่านอาจส่งคืนข้อมูลที่ล้าสมัย ซึ่งเป็นประเด็นสำคัญสำหรับแอปพลิเคชันที่คาดหวังความสอดคล้องในท้ายที่สุดภายในขอบเขตเวลาที่เข้มงวด

# Monitor replication lag for all replicas
aws cloudwatch get-metric-statistics \
  --namespace AWS/ElastiCache \
  --metric-name ReplicationLag \
  --dimensions Name=ReplicationGroupId,Value=web-cache \
  --statistic Maximum \
  --period 60 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

# Alert if ReplicationLag > 10 seconds

การปรับขนาดกลุ่มการจำลองข้อมูล

คุณสามารถปรับขนาดในแนวตั้ง (เปลี่ยนประเภทโหนด) หรือปรับขนาดในแนวนอน (เพิ่มหรือนำแบบจำลองออก) การเปลี่ยนประเภทโหนดต้องเรียกใช้ modify-replication-group และจะทำให้เกิดการสลับการทำงานชั่วครู่เมื่อมีผลทันที — คลัสเตอร์หลักจะถูกแทนที่ด้วยโหนดใหม่ที่เป็นประเภทใหม่ การเพิ่มแบบจำลองทำได้ขณะระบบออนไลน์โดยไม่มีช่วงหยุดทำงาน เมื่อปรับขนาดจากโหมดที่ไม่ใช้คลัสเตอร์เป็นโหมดคลัสเตอร์ คุณต้องสร้างกลุ่มที่ใช้โหมดคลัสเตอร์ใหม่แล้วจึงย้ายข้อมูล — ไม่สามารถแปลงระหว่างโหมดคลัสเตอร์กับโหมดที่ไม่ใช้คลัสเตอร์ภายในกลุ่มเดิมได้

# Scale up node type with maintenance window
aws elasticache modify-replication-group \
  --replication-group-id web-cache \
  --cache-node-type cache.r7g.xlarge \
  --apply-immediately false

# Add a read replica
aws elasticache increase-replica-count \
  --replication-group-id web-cache \
  --new-replica-count 4 \
  --apply-immediately

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

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

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า กลุ่มการจำลองข้อมูล รองรับการปรับขนาดการอ่านผ่านแบบจำลอง และรองรับความพร้อมใช้งานสูงผ่านการสลับการทำงานอัตโนมัติด้วยปลายทางสำหรับคลัสเตอร์หลักและผู้อ่าน โหมดคลัสเตอร์ แบ่งชาร์ดข้อมูลไปยังกลุ่มโหนดได้สูงสุด 500 กลุ่ม โดยใช้ช่องแฮช 16,384 ช่อง เพื่อปรับขนาดในแนวนอนให้เกินขีดจำกัดหน่วยความจำของโหนดเดียว และ Global Datastore จำลองข้อมูลข้ามภูมิภาคเพื่อรองรับการอ่านที่มีความหน่วงต่ำทั่วโลกและ DR ข้ามภูมิภาค บทถัดไปเราจะสำรวจกลยุทธ์การแคช ได้แก่ การโหลดแบบขี้เกียจและการเขียนผ่าน

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

บทเรียน “กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์”

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

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

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

บทเรียน “กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์” ใช้เวลานานแค่ไหน

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

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

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

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

  1. Redis เทียบกับ Memcached: การเลือกกลไกที่เหมาะสม
  2. กลุ่มการจำลองข้อมูล Redis ของ ElastiCache และโหมดคลัสเตอร์
  3. กลยุทธ์การแคช: การโหลดแบบขี้เกียจและการเขียนผ่าน
  4. การจัดเก็บเซสชันและรูปแบบกระดานผู้นำ
← กลับไปที่ AWS Solutions Architect