เมื่อการใช้งาน Redis เพิ่มขึ้นในระบบ Production ทีมพัฒนาจะต้องเผชิญกับการตัดสินใจทางสถาปัตยกรรมที่สำคัญ: ควร Scale Redis ด้วย Redis Sentinel หรือ Redis Cluster?
การตัดสินใจนี้มักทำช้ากว่าที่ควร และอยู่ภายใต้ความกดดัน มักหลังจากปัญหา Performance, Memory Exhaustion หรือ Availability Incidents เกิดขึ้น น่าเสียดายที่ Redis Sentinel และ Redis Cluster แก้ปัญหาที่ต่างกันอย่างสิ้นเชิง และการเลือกผิดจะนำไปสู่การออกแบบใหม่ที่เจ็บปวด
Redis Sentinel เน้นที่ Availability (ความพร้อมใช้งาน) Redis Cluster เน้นที่ Scalability (ความสามารถในการขยาย) การสับสนระหว่างสองอย่างนี้เป็นข้อผิดพลาดที่พบบ่อยที่สุดในสถาปัตยกรรม Redis
ปัญหาหลักที่ Redis Sentinel แก้
Redis Sentinel ออกแบบมาเพื่อให้ High Availability สำหรับ Dataset เดียวของ Redis
หน้าที่หลักคือ:
- Monitor (เฝ้าระวัง) Redis Master และ Replica Nodes
- Detect Failures (ตรวจจับความล้มเหลว)
- ทำ Automatic Failover อัตโนมัติ
- แจ้งเตือน Clients เกี่ยวกับ Master ใหม่
Redis Sentinel ไม่ได้ Shard Data (แบ่งข้อมูล) ยังคงมี Redis Instance เดียวในเชิงตรรกะที่เก็บ Key ทั้งหมด
ถ้า Master ล้มเหลว Sentinel จะ Promote Replica ให้กลายเป็น Master จากมุมมองของแอปพลิเคชัน Redis ยังคงทำงานต่อได้ด้วยการขัดขวางน้อยที่สุด
Redis Sentinel ทำงานภายในอย่างไร
Setup Redis Sentinel ทั่วไปประกอบด้วย:
- Redis Master หนึ่งตัว
- Redis Replicas หนึ่งหรือหลายตัว
- Sentinel Processes หลายตัวที่ Monitor พวกเขา
Sentinels ตรวจสอบสุขภาพของ Master ตลอดเวลา เมื่อ Quorum ของ Sentinels ตกลงกันว่ Master Down แล้ว Failover จะถูก Trigger
Replica หนึ่งตัวถูก Promote ให้เป็น Master ใหม่ และ Replicas ที่เหลือถูก Reconfigure ให้ Follow Master ใหม่
จุดสำคัญคือ ข้อมูลยังคงมีขนาดและรูปแบบเดิม ไม่มีการกระจาย Key ใหม่ (Redistribution)
สิ่งที่ Redis Sentinel ไม่ทำ
Redis Sentinel ไม่:
- เพิ่ม Memory Capacity เกินกว่า Single Node
- เพิ่ม Write Throughput เกินกว่า Single Core
- Shard หรือกระจายข้อมูล (Distribute Data)
ถ้า Redis Instance ของคุณหมด Memory หรือ CPU การเพิ่ม Sentinel ไม่ช่วย Sentinel ทำให้ Redis Available (พร้อมใช้งาน) ไม่ใช่ทำให้ใหญ่ขึ้น (Bigger)
ปัญหาหลักที่ Redis Cluster แก้
Redis Cluster จัดการ Scalability มากกว่าแค่ Availability
มันแก้:
- Memory Limits ของเครื่องเดียว (Single Machine)
- Throughput Limits ที่เกิดจาก Single-threaded Execution
Redis Cluster Shard (แบ่ง) ข้อมูลข้าม Master Nodes หลายตัว แต่ละ Master เป็นเจ้าของ Subset ของ Keyspace
Replication ใช้สำหรับ Availability แต่ Sharding คือคุณสมบัติที่กำหนดตัวตน
Redis Cluster ทำงานระดับสูงอย่างไร
Redis Cluster แบ่ง Keyspace ออกเป็น 16,384 Hash Slots
แต่ละ Master Node เป็นเจ้าของส่วนหนึ่งของ Slots นี้ Keys ถูก Assign ให้ Slots ตาม Hash Function
เมื่อ Client ส่ง Command มันจะถูก Route ไปยัง Node ที่รับผิดชอบ Slot นั้น
ถ้า Master ล้มเหลว Replica หนึ่งของมันจะถูก Promote อัตโนมัติ คล้าย Sentinel แต่เฉพาะสำหรับ Shard นั้นๆ
การเปรียบเทียบโมเดล Availability
Redis Sentinel ให้:
- Master ที่ Active อยู่เพียงตัวเดียวในเวลาเดียวกัน
- Full Dataset บน Node เดียว
- Automatic Failover
Redis Cluster ให้:
- Multiple Masters
- Data แบ่งกระจายข้าม Nodes
- Failover ระดับ Shard
Sentinel ป้องกัน Node Failure Cluster ป้องกันทั้ง Node Failure และ Capacity Limits
ลักษณะการ Scale (Scaling Characteristics)
Redis Scale แบบ Vertical (Scale Up)
คุณสามารถย้าย Redis ไปเครื่องใหญ่กว่า เพิ่ม Memory หรือใช้ CPU เร็วกว่า แต่ยังคงมีเพดานจำกัด (Ceiling)
Redis Cluster Scale แบบ Horizontal (Scale Out)
คุณเพิ่ม Nodes เพื่อเพิ่ม Memory และ Throughput แต่ละ Node จัดการแค่ส่วนหนึ่งของ Dataset
เมื่อ Single Redis Node ไม่พอแล้ว Sentinel เพียงอย่างเดียวก็ไม่เพียงพอ
ผลกระทบต่อการออกแบบ Application (Application Design Impact)
Redis Sentinel เป็น Transparent (โปร่งใส) ต่อ Application ส่วนใหญ่
Application ยังคิดว่ากำลังคุยกับ Redis Instance เดียว Clients Reconnect ไป Master ใหม่หลัง Failover
Redis Cluster ต้องการ Cluster-aware Clients
Application ต้อง:
- จัดการ Redirections
- เคารพ Hash Slot Boundaries
- หลีกเลี่ยง Multi-key Operations ที่ไม่รองรับ
การใช้ Cluster ส่งผลต่อ Key Design และ Data Modeling อย่างมาก
Multi-key Operations และ Transactions
กับ Redis Sentinel:
- Key ทั้งหมดอยู่บน Master เดียว
- Multi-key Operations ทำงานปกติ
- Transactions และ Lua Scripts พฤติกรรมตามคาด
กับ Redis Cluster:
- Keys อาจอยู่บน Nodes ต่างกัน
- Multi-key Operations ทำงานได้เฉพาะใน Hash Slot เดียวกัน
- Cross-slot Operations จะ Fail
ความแตกต่างเพียงอย่างเดียวนี้ มักเป็น Shock ใหญ่ที่สุดสำหรับทีมที่ย้ายไป Redis Cluster
ความซับซ้อนทาง Operation (Operational Complexity)
Redis Sentinel เพิ่ม Operational Complexity ระดับปานกลาง
คุณจัดการ:
- Master และ Replicas
- Sentinel Quorum
- Failover Behavior
Redis Cluster เพิ่ม Complexity อย่างมีนัยสำคัญ
คุณจัดการ:
- Multiple Masters และ Replicas
- Slot Allocation และ Balancing
- Resharding Operations
- Client Compatibility
Cluster ต้องการ Operational Discipline ที่เข้มงวดกว่า
เมื่อไหร่ที่ Redis Sentinel เป็นตัวเลือกที่ถูกต้อง
Redis Sentinel เหมาะสมเมื่อ:
- Dataset ใส่เครื่องเดียวได้สบาย
- Write Throughput ใส่ Single Core ได้
- ต้องการ High Availability
- Application Logic ขึ้นอยู่กับ Multi-key Operations
ระบบหลายระบบรันสำเร็จมา שנים กับ Sentinel เพียงอย่างเดียว
เมื่อไหร่ที่ Redis Cluster เป็นตัวเลือกที่ถูกต้อง
Redis Cluster เหมาะสมเมื่อ:
- Memory Requirements เกิน Single Node
- Throughput Needs ต่อเนื่องเพิ่มขึ้น
- ต้องการ Horizontal Scaling
- Application สามารถออกแบบสำหรับ Sharding ได้
Cluster เป็น Scaling Strategy ไม่ใช่แค่ Failover Mechanism
ข้อผิดพลาดการย้าย (Migration) ที่พบบ่อย
ทีมมัก:
- Adopt Redis Cluster เร็วเกินไป
- สมมติว่า Sentinel และ Cluster สลับกันได้
- ละเลย Key Design Implications
- ค้นพบ Multi-key Limitations ช้เกินไป
ข้อผิดพลาดเหล่านี้มักนำไปสู่ Refactoring ที่倉促
กฎการตัดสินใจง่ายๆ (A Simple Decision Rule)
ใช้ Redis Sentinel เมื่อ:
- คุณต้องการ High Availability โดยไม่ต้องเปลี่ยน Data Model
ใช้ Redis Cluster เมื่อ:
- คุณ ต้อง Scale Redis เกินเครื่องเดียว
ถ้าคุณเลือก Cluster ให้ออกแบบสำหรับมันตั้งแต่ต้น แม้คุณยังไม่ Enable มันก็ตาม
สรุป
Redis Sentinel และ Redis Cluster เป็นเทคโนโลยีที่เสริมกัน (Complementary) จัดการแรงกดดันระบบที่ต่างกัน Sentinel ให้ Service Continuity สำหรับ Dataset เดียว Cluster ให้ Redis Scale ข้ามเครื่อง การเลือกวิธีที่ถูกต้อง ขึ้นอยู่กับว่า Availability หรือ Scalability เป็น Driver หลักของสถาปัตยกรรม
