ทำความรู้จักกับ Redis Sentinel และ Redis Cluster

Original image: https://unsplash.com/@scottwebb

Redis Sentinel

Redis Sentinel Architecture ถ้าหากพูดถึงความเป็นมาคงต้องย้อนกลับไปปี 2012 ที่ Redis sentinel ได้ถือกำเนิดขึ้น ด้วยแนวคิดการทำ Automatic failover capabilities, Distributed monitoring และ Notification สำหรับ Redis

https://www.notion.so/iamgoangle/Redis-Sentinel-vs-Cluster-3b7aa0bf545d441da96b17d74a0d4cc5#185a5d0a012b40e8abde83049d23cec6

สถาปัตยกรรม Sentinel

แนวคิดของการทำ Sentinel ขึ้นมาก็เพื่อมี Sentinel Instance ที่ทำหน้าที่เหมือนยาม คอยจับตาดูความเคลื่อนไหวแต่ละโหนดการทำงาน ว่ายังอยู่ในสภาวะการทำงานที่ปกติหรือไม่ ซึ่งความสามารถของ Sentinel มีหน้าที่ ดังต่อไปนี้

1. Monitoring ทำหน้าที่ตรวจสอบสถานะ health ของ Master และ Slave โหนด
2. Notification ทำหน้าที่ส่งต่อสถานะการทำงานไปยัง Integration program เช่น ระบบ Monitoring และ System Alert ที่เราเตรียมไว้ เช่น Grafana, Newrelic เป็นต้น
3. Automatic Failover ด้วยคุณสมบัติของ Resilency Pattern หาก Master พัง จะต้องมีการโปรโมท Slave ขึ้นมาทำหน้าที่แทนชั่วครู่ ก่อนที่ Master จะ Recovery ตัวเองให้กลับมาอีกครั้ง
4. Configuration Provider ทำหน้าที่เป็น Service Discovery ให้กับ Client ที่ร้องขอเข้ามา โดยจะจัดหาเส้นทางที่เชื่อมต่อให้

แนวคิดการทำงานภายใน Sentinel

Sentinel จะคอยเชคความพร้อมการใช้งานระหว่าง Master และ Slave เสมอว่าทำงานได้ตามที่ต้องการหรือไม่ หากเกิด failure เหตุการณ์ที่จะเกิดขึ้น คือ Sentinel จะโปรโมต Slave มาทำหน้าที่เป็น Master ทันที และจะทำการ Re-configuration อย่างรวดเร็ว on-the-fly ว่างั้นเถอะ!!! ส่วน Master ที่พังอยู่ก็ให้ Recovery ตัวเองต่อไป

Service Discovery ทำหน้าที่หา Route ของ connection ที่มาจาก Client และส่ง traffic ไปยัง Master สำหรับงาน Write และ Slave สำหรับงานที่ Read ข้อมูล

ในระบบ Sentinel ควรมีอย่างน้อย 3 instances สำหรับการทำ Master และ Slave

แนวคิดการทำ Sentinel ผู้ที่ดูแลระบบควรใช้หลักการของ Quorum >= 2 สำหรับ Slave เพราะ อย่างน้อยในระบบต้องเหลือ Slave 1 ตัวไว้เสมอ สำหรับการทำ Data Replication

N/2 + 1 ในขณะที่ N คือ จำนวนอย่างน้อยที่ควรมีของ Quorum ที่ช่วยในการตัดสินใจของ Active node ว่ายังสามารถให้บริการอยู่ได้ตามปกติ

ข้อเด่น

• Stability ค่อนข้างมีความสเถียรในเรื่อง Available และ ความคงอยู่ของข้อมูล
• Automatic resilience
• กิน CPU และ RAM ไม่เยอะมาก

ข้อด้อย

• Step การติดตั้งค่อนข้างเยอะ
• Client ต้อง Support การเชื่อมต่อแบบนี้
• ในเรื่องการ Horizontal Scaling ทำได้ไม่ค่อยดี เมื่อใช้ไปสักระยะแล้วถ้ามี Data จำนวนมากๆ การขยายตัวอนาคตอาจทำลำบาก
• Latency ในการเชื่อมต่อแต่ละ Sentinel

Redis Cluster

ถูกออกแบบมาเพื่อเพิ่มศักยภาพในการทำ Horizontal scaling เกิดก่อน Sentinel ด้วยนะ ถ้าอ้างอิงตาม Commit History

https://github.com/antirez/redis/commit/ecc9109434002d4667cd01a3b7c067a508c876eb

Redis cluster มีแนวคิดการทำ Data Sharding รวมกับ Automatic management / Handling failover และ Replication

นี่มัน คือ การรวมร่างกับ Cluster + Sentinel ชัดๆ

สถาปัตยกรรมของ Redis Cluster

multi-master architecture สถาปัตยกรรมแบบนี้ข้อมูลของเราจะถูก shard ไป multiple-node ซึ่งมีพื้นที่เตรียมไว้ 16384 buckets หรือ Hash Slot แต่ละ hash slot จะมี key ซึ่งใช้ CRC16 ในการประมวลผล

การทำงานเมื่อมี SET/DEL Operation ลง Redis-Cluster

+-----------+ +-----------+ +-----------+
+  A 0-10   + +  B 11-20  + +  C 21-30  +
+-----------+ +-----------+ +-----------+
      M             M             M
SL1 ----- SL2 SL1 ----- SL2 SL1 ----- SL2

• mykey และ myvalue ถูกประมวลผล และได้รับ bucketID สมมุติว่า Node C
• Hash slot A-B จะถูกจัดสรรให้ C
• รอสักครู่ Redis-Cluster จะตอบกลับมาว่า OK

เช่นเดียวกับ Operation DEL จะทำแบบเดียวกัน

[Master A] 
- Write Keys A-C
[Slave A]
- Read Keys A-C
[Master B]
- Write Keys D-E-F
[Slave B]
- Read Keys D-E-F
...

ซึ่งการทำแต่ละ Cluster จะมี Master/Slave เช่นเดียวกับกับ Sentinel และ การทำ Failover เหมือนกันทุกประการ

ในการเรียกใช้ Cluster เราจำเป็นต้องกำหนด Cluster Server ที่ Client Library สำหรับกรณี Cluster พังชั่วคราว ช่วยให้ Client วิ่งไปหา Cluster Server ถัดไปได้เลยในการเข้าถึงข้อมูล

Cluster Architecuture เรามักพิจารณาใช้มันเมื่อเจอ Usecase ประเภท

amount of data > memory per single server

ข้อดี

• การกระจายการอ่าน เขียน ทำได้ดีขึ้น [1]
• การขยายตัวของระบบทำได้ง่ายขึ้น และมีประสิทธิภาพที่ดีกว่าเดิม

ข้อด้อย

• ค่าใช้จ่ายสูงขึ้น เพราะ คุณต้อง มีอย่างน้อย 6 nodes
• Redis-client ต้องซัพพอร์ต และ กำหนด ลิสต์ของ cluster ในโค๊ด

สรุป

1. Single Redis Insance เหมาะสมกับกรณีที่เราไม่แคร์เรื่องข้อมูลสูญหาย และ High Availability
2. Sentinel ต้องการอย่างน้อย 3 nodes (Master 1 / Slave 2) และเหมาะกับงาน data < memory
3. Cluster ต้องการอย่างน้อย 6 nodes (Master 3 / Slave 3) และเหมาะกับงาน data > memory

References

Redis Cluster vs Redis Replication

Redis Sentinel Documentation - Redis

What Redis deployment do you need ?

Redis cluster tutorial - Redis

Redis high availability | There is no magic here