ตั้งแต่สร้างในปี 2009 Redis OSS มีชุมชน open source ที่มีชีวิตชีวา มากมาย tools และ utilities พัฒนารอบตัว Dynomite, a peer-to-peer geo-distribution layer for non-distributed datastores เป็นหนึ่งในนั้น
Dynomite พัฒนาโดยทีมวิศวกรที่ Netflix และ release เป็น open source 雖然มันให้ good solutions สำหรับความต้องการเฉพาะ แต่ไม่ได้ได้รับการ maintain อย่างมีประสิทธิภาพในหลายปีที่ผ่านมา อีกทั้ง บาง functionalities, commands, และ data types ของ Redis OSS (เช่น Pub/Sub หรือ Streams) ถูกทำให้ unavailable หรือ limited โดย distribution model ของ Dynomite สำหรับ Redis OSS instances
ด้วยเหตุนี้ เราช่วยองค์กรย้าย Dynomite databases ไป Redis Enterprise cluster
การเปรียบเทียบสถาปัตยกรรม Dynomite และ Redis Enterprise
เริ่มเปรียบเทียบด้วยคำอธิบายสั้นๆ ของสถาปัตยกรรมทั้งสอง
Dynomite
Typical Dynomite cluster อธิบายได้ดังนี้:
- ครอบคลุมข้าม multiple data centers
- Single datacenter คือ group ของ racks
- Rack คือ group ของ nodes: แต่ละ rack เก็บ entire dataset ซึ่ง partitioned ข้าม multiple nodes ใน rack นั้น
Dynomite เป็น peer-to-peer distribution layer ดังนั้น client สามารถส่ง write traffic ไป node ใดก็ได้ใน Dynomite cluster หาก node นั้นเป็นผู้รับผิดชอบข้อมูล ข้อมูลจะเขียนไป local Redis OSS server process แล้ว asynchronous replicate ไป racks อื่นใน cluster ข้าม all data centers หาก node ไม่ได้ own data มันทำหน้าที่ coordinator ส่ง write ไป node ที่ own data ใน rack เดียวกัน และ replicate writes ไป corresponding nodes ใน racks และ DCs อื่นๆ
Redis Enterprise
Redis Enterprise cluster ก็ distribute data ข้าม Redis instances หรือ shards ต่างๆ แต่มี 2 ความแตกต่างหลัก:
- อาจมี more than one shard บน node – แต่ primary และ replica ไม่สามารถอยู่บน node เดียวกันได้ เพื่อ high availability
- มี replica เพียงหนึ่งต่อ primary shard เดียว Clients ทำ data operations บน primary shards Replicas ของแต่ละ primary มีไว้สำหรับ high availability กรณี primary shards fail
ส่วนสำคัญอีกส่วนของ Redis Enterprise cluster คือ "management path" ประกอบด้วย Cluster Manager, Proxy, และ REST API/UI Cluster Manager รับผิดชอบ orchestrate cluster, วาง database shards บน highly-available nodes, และ detect failures Proxy ซ่อน cluster topology ของ Redis Enterprise จาก applications โดยให้ single, never-changing endpoint สำหรับแต่ละ database ภายใน cluster มันยังช่วย scale client connections โดย multiplexing และ pipelining commands ไป shards
นี่คือ illustration ของ typical Redis Enterprise Cluster:
ด้วยฟีเจอร์ Active-Active ของ Redis Enterprise คุณสร้าง global database ครอบหลาย clusters ได้ Clusters เหล่านั้น typically อยู่ใน data centers ต่างๆ รอบโลก Application ที่เขียนไป Active-Active database เชื่อมต่อ local instance endpoint ทุก writes ของ application ไป local instance จะ replicated ไป all other instances ด้วย strong eventual consistency
Active-Active replication ให้ advantages มากมายเป็น geo-distributed solution หนึ่งในนั้นคือ seamless conflict resolution สำหรับ simple และ complex Redis Enterprise data types ซึ่งเราจะพูดถึงด้านล่าง
ตอนนี้เข้าใจ topologies ของ Dynomite และ Redis Enterprise แล้ว มาดูว่ามันหมายความว่าอะไรต่อ developers และ DevOps ในองค์กร
Dynomite หรือ Redis Enterprise: ต่างกันอย่างไรสำหรับ Developers?
นอกจาก Dynomite ไม่ได้ actively maintained แล้ว มี 3 เหตุผลหลักที่องค์กรต้องการ migrate ไป Redis Enterprise จากมุมมอง developer:
- Redis functionalities ถูก limited และ complex เมื่อใช้ Dynomite
- Dynomite ไม่มี effective way จัดการ geo-distributed write conflicts
- Support ที่ได้จาก Redis
มาดู 2 ข้อแรกละเอียด
Redis OSS ที่ Limited และ Complex
เช่นคุณรู้ Redis OSS ไม่ใช่ plain key-value store ในความหมายที่แค่ associate string keys กับ string values Redis OSS เป็น data structures server รองรับค่าประเภทต่างๆ เช่น lists, sets, hashes, หรือ streams เราเรียกว่า "core data types" ของ Redis OSS
Redis OSS ยัง extensible ผ่าน dynamic libraries เรียกว่า "modules" Modules ให้ implement Redis commands ใหม่ได้รวดเร็ว ด้วย features เหมือนที่ทำได้ใน core เอง ใน modules ยอดนิยม มี RediSearch (querying, secondary indexing, full-text search) และ RedisJSON (ทำให้ Redis OSS เป็น powerful document store)
ตามที่อภิปรายใน introduction บาง Redis OSS commands และ data types ถูกทำให้ unavailable หรือ limited โดย Dynomite นี่คือการเปรียบเทียบไม่ครบ:
ดู complete list ของ supported และ unsupported commands กับ Dynomite ที่นี่
ด้านอื่น Redis Enterprise ซึ่ง maintained alongside Redis OSS อนุญาต multi-model operations ใช้ modules และ core Redis OSS data structures execute ได้ใน fully programmable และ distributed manner
ขาด Conflict Resolution
Dynomite เป็น AP system ให้ 3 ตัวเลือก consistency ไม่ว่าจะเลือกอันไหน สำคัญคือ Dynomite resolve asynchronous write conflicts ด้วย Last Write Wins strategy นี่อาจทำให้ lost updates เนื่องจาก irrelevant timestamps โดยเฉพาะใน context ของ geo-distributed writes
ขณะเดียวกัน Redis Enterprise's Active-Active architecture 基于 alternative implementation ของ Redis OSS commands และ data types เรียกว่า Conflict-Free-Replicated-Data-Types (CRDTs) CRDTs ใช้ vector clocks สำหรับ event ordering พวกมันรับรองว่าเมื่อ any two replicas ได้รับ same set of updates พวกเขาจะ reach same state, deterministically โดย adopting mathematically sound rules เพื่อ guarantee state convergence นอกจากนี้ ยัง enable causal consistency ได้อีก
ดังนั้นกับ Redis Enterprise:
- Outcome ของ concurrent writes เป็น predictable และ based on set of rules
- Applications ไม่ต้องกังวล concurrent writes และ resolution ของ write conflicts
- Dataset จะ eventually converge ไป single, consistent state
หากสนใจ หา rules ที่ implement และตัวอย่าง conflict resolution ได้ที่ link นี้
Dynomite หรือ Redis Enterprise: ต่างกันอย่างไรสำหรับ DevOps?
ตอนนี้เปรียบเทียบ Dynomite และ Redis Enterprise จากมุมมอง DevOps โดยอภิปราย topics:
- High Availability
- Scalability
- Deployability
High Availability
เมื่อ node fail ภายใน Dynomite rack การเขียนและอ่าน rack นั้นกลายเป็น impossible หมายถึง application ที่เขียน locally ต้อง handle failover ไป rack อื่นเอง โปรดทราบ หาก application พัฒนาด้วย Java Netflix's Dyno client สามารถ handle failovers ไป remote racks เมื่อ local Dynomite node fail
เพิ่มเติม เมื่อ node กลับมาขึ้น ข้อมูลที่เขียนบน remote racks ระหว่าง failure จะ missing จาก failed node หาก deploy ใน AWS autoscaling groups สามารถใช้ Netflix's Dynomite Manager ซึ่งทำ node replacement และ node warm-up ใน AWS auto-scaling group
Redis Enterprise high availability เป็นอย่างไร?
เมื่อ node fail single-digit-seconds failover เกิดขึ้นสำหรับ all primary shards บน node นั้น และ replicas ของพวกเขาถูก promote เป็น primaries Auto-failover mechanism นี้ guarantee ว่าข้อมูล served ด้วย minimal interruption
จากนี้:
- Redis Enterprise Proxy ทำให้ single-endpoint ของ database ไม่เปลี่ยนกรณี failover ไม่ต้อง reconfigure application
- มี "replica_ha" option รับรองว่าเมื่อ replica promoted เป็น primary new synced replica shard จะถูกสร้างอัตโนมัติบน any ของ other nodes ที่ available
Mechanisms นี้ทำให้ Redis Enterprise guarantee 99.99% uptime และ 99.999% uptime สำหรับ Active-Active deployments
Scalability
Dynomite อนุญาต scale Redis OSS พร้อม maintain good performance ด้าน latency เช็ค benchmarks ได้ แต่ถ้าใช้ Dynomite คุณคงรู้อยู่แล้ว
เรื่อง scalability ความแตกต่างหลักระหว่าง Dynomite และ Redis Enterprise:
- Manageability
- Out-of-the box connection management
- Resource optimization
Manageability
หากไม่ใช้ Dynomite Manager ใน AWS autoscaling group การเพิ่ม hosts ไป running Dynomite rack typically requires:
- Leverage "dual writes" technique ด้วย Java Dyno client; application เขียนไป old/small cluster และ new/scaled cluster พร้อมกัน หลัง幾天 route traffic เฉพาะ new cluster ทำให้มันเป็น active
- Migrate database จาก old/small cluster ไป new/scaled cluster
ขณะเดียวกัน Redis Enterprise อนุญาตให้:
- Scale up โดยเพิ่ม shards ไป database โดยไม่ต้องเพิ่ม nodes ไป cluster: scenario นี้ useful เมื่อมี under-utilized capacity พอใน cluster จำไว้: one node ไม่เท่ากับ one Redis instance Resharding database ทำได้ใน few clicks ผ่าน Redis Enterprise UI หรือใช้ Redis Enterprise's REST API ทำได้โดยไม่มี downtime หรือ service interruption โปร่งใสต่อ application เพราะ database endpoint ไม่เปลี่ยน
- Scale out โดยเพิ่ม node(s) ไป cluster Scenario นี้ useful หากต้องการ physical resources มากขึ้นเพื่อเพิ่ม shards ไป database โปรดทราบกับ Redis Enterprise Cloud (fully-managed DBaaS) องค์กรไม่ต้องกังวลขั้นตอนนี้ Redis จะ provision และ manage infrastructure และ resources ให้ ดูรายละเอียดใน Deployment section
นี่คือ benchmark ที่ Redis ทำเมื่อหลายปีก่อน Redis Enterprise deliver over 200 million ops/sec, sub-millisecond latency, บน 40 AWS instances
Connection management
พูดถึง connection management กับ Redis สิ่งแรกคือ Redis clients เช่น Jedis หรือ Lettuce handle connection pooling และ pipelining อย่างไร Netflix ไม่ใช่ exception และ implement features เหล่านี้สำหรับ Dyno client
Redis Enterprise ให้ features เหล่านี้ out-of-the-box Proxy เองสร้าง persistent connections ไป shards ใน cluster และ connections เหล่านี้ shared by clients มันยัง apply performance optimizations โดย scheduling requests บนจำนวน persistent connections ไป shards, multiplexing, และ pipelining ฝั่ง Redis
เพิ่มเติม proxy เป็น multi-threaded และจะ automatically scale เพื่อ handle bursts ใน client connections
Resource optimization
ก่อนอื่น จำไว้ว่าใน Redis Enterprise cluster one machine ไม่เท่ากับ one Redis instance และแต่ละ primary shard มี replica ได้สูงสุดหนึ่ง
สอง Redis Enterprise เป็น multi-tenant หมายถึง single Redis Enterprise cluster serve hundreds ของ completely isolated databases ได้ นี่ far from trivial ถ้าใช้ Dynomite คุ้มค่าที่จะ note ว่า Redis Enterprise's multi-tenancy fits well กับ multi-model capabilities ใน context ของ microservices สามารถ imagine รัน different fit-for-purpose databases ใน single set of nodes แต่ละอันมี replication, scaling, persistence, และ module configuration ของตัวเอง
สุดท้าย Redis Enterprise มี feature เรียกว่า Redis On Flash (RoF) RoF ให้ databases ใช้ both RAM และ dedicated flash memory (SSD/NVMe) handle larger datasets ด้วย RAM-like latency และ performance แต่ cost ต่ำกว่า >70% เทียบ all-RAM database
Deployment options
Dynomite deploy ได้ใน containers หรือ machines รัน Ubuntu, RHEL, CentOS Deployments เสมอ self-managed คือคุณต้อง provide infrastructure และ resources manage cluster เอง เพิ่มเติม ตามที่อภิปรายก่อน หากอยากใช้ features ของ Dynomite Manager ต้อง deploy Dynomite ภายใน AWS autoscaling group
ขณะเดียวกัน Redis Enterprise มี deployment options หลายอย่าง แบ่ง 2 groups:
- Self-managed solutions: download, install, deploy Redis Enterprise Software เอง Options มากมาย รวม Linux installers (multiple distributions), Amazon Machine Image (AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS)
- Managed solutions: Redis Enterprise Cloud เป็น fully managed cloud service (DBaaS) บน 3 major public clouds (Google Cloud, AWS, Azure) Redis จะ host dedicated environment ให้พร้อม resources ที่จำเป็น สร้าง databases ด้วย private และ public endpoints สำหรับ applications consume
