บทนำ
Redis รู้สึก Rock Solid (แข็งแกร็ง) เมื่อทุกอย่าง Healthy การทดสอบจริงเริ่มเมื่อบางอย่างพัง Node Crash, VM Reboot, Container หาย หรือ Network Issue แยกส่วนของระบบ
สิ่งที่เกิดขึ้นต่อไป ขึ้นอยู่กับว่าการ Replication และ High Availability ถูกออกแบบอย่างไร ทีมหลายทีมสมมติว่า Redis จัดการ Failure อัตโนมัติ แต่ไม่ใช่ Redis ให้ Building Blocks ไม่ใช่ Finished Solution
Replication และ High Availability แก้ปัญหาที่ต่างกัน Redis รองรับทั้งสอง แต่เข้าใจความแตกต่างเป็น Critical สำหรับการสร้าง Production Systems ที่ Resilient
Redis Replication ทำอะไรจริงๆ
ที่แก่น Replication คือการ Copy Data จาก Node หนึ่งไปยังอีก Node Primary Node (มักเรียก Master) จัดการ Write Operations ทั้งหมด Replica Nodes หนึ่งหรือหลายตัว รับ Stream ของ Changes ต่อเนื่อง และเก็บ Data ให้ In-sync
Replication มีอยู่ 3 เหตุผลหลัก: Read Scaling, Failover Readiness, Data Redundancy แต่ Replication เพียงอย่างเดียว ไม่รับประกัน High Availability มันแค่ให้ Ingredients (ส่วนผสม) ที่จำเป็นในการสร้างมัน
Replication ทำงานภายใต้ฝาผังอย่างไร
เมื่อ Replica เชื่อมต่อกับ Master มันเริ่มด้วย Initial Synchronization Process Master สร้าง Snapshot ของ Data ปัจจุบันและส่งให้ Replica Replica โหลด Snapshot นี้เข้า Memory
หลัง Initial Sync Master Stream Write Commands ทั้งหมดไปยัง Replica Replica Apply Commands เหล่านี้ในลำดับเดียวกันเพื่อให้ Consistent
Approach นี้ Efficient และ Simple แต่มี Tradeoffs สำคัญ Replication เป็น Asynchronous โดย Default หมายความว่ามี Window เล็กๆ ที่ Data อยู่บน Master แต่อยู่บน Replicas ยังไม่ได้
Asynchronous Replication และความเสี่ยง Data Loss
Asynchronous Replication ให้ Redis เร็วและ Responsive แต่หมายความว่า Data Loss บ้างเป็นไปได้ถ้า Master Fail
ถ้า Master Crash ก่อน Replicas รับ Writes ล่าสุด Writes นั้นจะ Lost Redis ไม่พยายามซ่อนความเป็นจริงนี้ สำหรับ Cache Data มันมักยอมรับได้ สำหรับ Critical State อาจไม่ยอมรับได้
Redis ให้ Options ทำ Replication Stricter แต่ Stricter Guarantees เพิ่ม Latency และลด Availability การตัดสินใจว่า Data Loss เท่าไหร่ Acceptable เป็น Architectural Decision สำคัญ
ใช้ Replicas เพื่อ Scale Reads
เหตุผลทั่วไปในการใช้ Redis Replication คือ Scale Read Traffic Application ส่ง Write Operations ไป Master และกระจาย Read Operations ไป Replicas
สิ่งนี้ลด Load บน Master และปรับปรุง Throughput รวม แต่เพราะ Replication เป็น Asynchronous Replicas อาจ Return Stale Data เล็กน้อย
สำหรับ Use Cases เช่น Caching Profiles หรือ Configuration นี่มักโอเค สำหรับ Scenarios ที่ต้องการ Strong Consistency อาจไม่ยอมรับได้ ทีมต้องทำ Trade-off นี้อย่าง Intentional (ตั้งใจ)
เกิดอะไรขึ้นเมื่อ Master Fail
Replication เพียงอย่างเดียวไม่จัดการ Master Failure เมื่อ Master Down Replicas ยัง In-sync แต่ไม่ Promote อัตโนมัติโดยไม่มี External Failover Mechanism
High Availability ต้องการสิ่งที่ Detect Failures, Coordinate Decisions และ Promote Master ใหม่ นี่คือที่ที่ Failover Systems เข้ามา
Redis Sentinel และ High Availability
Redis Sentinel เป็น Traditional Solution สำหรับเพิ่ม High Availability ให้ Redis Sentinel Processes Monitor Redis Instances, Detect Failures และ Communicate ระหว่างกันเพื่อ Consensus
เมื่อ Sentinels ตกลงกันว่า Master Down Replica หนึ่งจะ Promote ให้เป็น Master ใหม่ Sentinels ยัง Notify Clients ให้ Reconnect ไป Node ที่ถูกต้อง
Sentinel เพิ่ม Components และ Complexity เพื่อให้ Effective ต้องมี Multiple Sentinel Nodes รันอยู่ Single Sentinel ไม่พอสำหรับ True High Availability
Sentinel ตัดสินใจ Failover อย่างไร
Sentinel ใช้ Timeouts และ Quorum เพื่อหลีกเลี่ยง False Failovers Multiple Sentinels ต้องตกลงกันว่า Master Unreachable ก่อนจะ Promote
Design นี้เพิ่ม Reliability แต่หมายความว่า Failover ไม่ Instantaneous มีช่วงเวลาสั้นที่ Master Unavailable และไม่มี Replacement Active
Applications ต้องออกแบบให้ Handle Window นี้อย่าง Graceful Retries, Timeouts และ Fallback Behavior จำเป็น
Redis Cluster และ Built-in High Availability
Redis Cluster รวม Replication และ Failover เข้าใน System โดยตรง แต่ละ Shard มี Master และ Replicas Failover เกิดขึ้นอัตโนมัติเมื่อ Master Fail
สิ่งนี้ลบความจำเป็นของ Sentinel แต่เพิ่ม Constraints อื่นๆ Key Distribution, Client Behavior และ Cross-shard Operations ต้องออกแบบอย่างระมัดระวัง
Redis Cluster ทำให้ High Availability เรียบง่าย แต่บังคับ Architectural Boundaries ที่เข้มงวดกว่า
Failover ไม่หมายถึง Zero Downtime
Common Misconception คือ Redis Failover รับประกัน Zero Downtime ในความเป็นจริง Failover เร็วแต่ไม่ Instantaneous
ระหว่าง Failover Requests บางส่วนจะ Fail หรือต้อง Retry Well-designed Systems คาดหวัง Behavior นี้และ Recover Gracefully Poorly Designed Systems อาจ Crash หรือ Trigger Cascading Failures
High Availability ปรับปรุง Resilience ไม่ใช่ Perfection
Split Brain และความเสี่ยง
Split Brain เกิดเมื่อ Node มากกว่าหนึ่งเชื่อว่ามันคือ Master Redis และ Sentinel ออกแบบมา Prevent นี้ แต่ Network Partitions และ Misconfigurations ยังทำให้เกิดได้
Split Brain อาจทำให้ Conflicting Writes และ Data Corruption ลดความเสี่ยงนี้ต้องการ Sentinel Quorum ที่ถูกต้อง Network Setup ที่ถูกต้อง และ Timeouts ที่สมเหตุสมผล
การละเลยรายละเอียดเหล่านี้เป็น Cause พบบ่อยของ Incidents ที่ Rare แต่ Severe
Replication Lag และผลกระทบ Performance
Replication Lag ปกติเล็กแต่ไม่เป็นศูนย์ ภายใต้ Heavy Write Load Replicas อาจ Lag หลัง Master
ถ้า Failover เกิดขึ้นระหว่าง High Lag Data Loss เพิ่มขึ้น Monitoring Replication Lag Essential สำหรับ Systems ที่ Data Integrity Matter
Sudden Increases ใน Lag บ่งชี้ Underlying Performance หรือ Resource Issues
ทำไม Replication ไม่ใช่ Backup
Replication ไม่ควรสับสนกับ Backup ถ้า Data ถูกลบบน Master การลบนั้น Replicated ทันที
Backups ป้องกัน Human Error และ Logical Corruption Replication ป้องกัน Hardware หรือ Process Failure ทั้งสองจำเป็นถ้า Redis เก็บข้อมูลที่มีค่า
Redis HA Mistakes ที่พบบ่อย
ทีมบ่อยครั้งทำ Mistakes เดียวกันเมื่อออกแบบ Redis HA ได้แก่ สมมติ Replication = HA, รัน Single Sentinel เท่านั้น, ละเลย Replication Lag, ไม่ Test Failover, และปล่อยให้ Application Crash เมื่อ Redis Error
Mistakes เหล่านี้ปรากฏซ้ำใน Real-world Outage Reports
Testing Failure เป็นส่วนหนึ่งของ Design
High Availability ที่ไม่ทดสอบ มีอยู่แค่บนกระดาษ ทีมควร Simulate Failures เป็นประจำโดยหยุด Master ใน Controlled Environment
สังเกต Failover Behavior, วัด Recovery Time และเข้าใจ Application Response ให้ Insights ที่มีค่า ไม่มี Documentation ตัวไหนแทนที่ได้
A Practical Mental Model สำหรับ Redis HA
Redis High Availability คือเรื่อง Graceful Degradation (การเสื่อมสภาพอย่างมีศีลธรรม) เมื่อ Redis Healthy System Perform ดี เมื่อ Redis Unhealthy Performance อาจ Degrade เมื่อ Redis Unavailable System ควร Survive (รอด)
ถ้า Redis Down ทำให้ System Outage ทั้งระบบ High Availability ยัง Incomplete
สรุป
Redis Replication และ High Availability กำหนดว่า Systems พฤติกรรมอย่างไรภายใต้ Stress Replication ให้ Copies ของ Data ในขณะที่ High Availability ให้ Continuity of Service
ทั้งสองต้องการ Careful Design, Realistic Expectations และ Continuous Testing เมื่อ Implement ถูกต้อง Redis Failures จะกลายเป็น Routine Events แทนที่จะเป็น Major Incidents นั่นคือเป้าหมายของ Redis High Availability
