เหตุใดจึงต้องย้ายฐานข้อมูล Dynomite ไปยังฐานข้อมูล Redis Enterprise Active-Active

นับตั้งแต่ก่อตั้งในปี 2552 Redis OSS มีชุมชนโอเพ่นซอร์สที่มีชีวิตชีวามาก เครื่องมือและยูทิลิตี้มากมายได้รับการพัฒนา และ Dynomite ซึ่งเป็นเลเยอร์การกระจายทางภูมิศาสตร์แบบเพียร์ทูเพียร์สำหรับพื้นที่เก็บข้อมูลที่ไม่กระจาย เป็นหนึ่งในนั้น

Dynomite ได้รับการพัฒนาโดยทีมวิศวกรของ Netflix และเผยแพร่เป็นโอเพ่นซอร์ส แม้ว่าจะให้แนวทางแก้ไขที่ดีสำหรับความต้องการเฉพาะ แต่ก็ยังไม่ได้รับการดูแลอย่างมีประสิทธิภาพในช่วงไม่กี่ปีที่ผ่านมา นอกจากนี้ ฟังก์ชัน คำสั่ง และประเภทข้อมูลบางอย่างของ Redis OSS (เช่น Pub/Sub หรือ Streams) จะไม่พร้อมใช้งานหรือถูกจำกัดโดยโมเดลการแจกจ่ายอินสแตนซ์ Redis OSS ของ Dynomite

ด้วยเหตุนี้ เราจึงได้ช่วยเหลือองค์กรในการย้ายฐานข้อมูล Dynomite ไปยังคลัสเตอร์ Redis Enterprise

การเปรียบเทียบสถาปัตยกรรม Dynomite และ Redis Enterprise

มาเริ่มการเปรียบเทียบกันด้วยคำอธิบายสั้นๆ เกี่ยวกับสถาปัตยกรรมของทั้ง Dynomite และ Redis Enterprise

ไดโนไมต์

คลัสเตอร์ไดโนไมต์ทั่วไปสามารถอธิบายได้ดังนี้:

• ครอบคลุมศูนย์ข้อมูลหลายแห่ง

• ดาต้าเซ็นเตอร์เดียวคือกลุ่มของแร็ค

• ชั้นวางคือกลุ่มของโหนด:แต่ละชั้นวางเก็บชุดข้อมูลทั้งหมด ซึ่งถูกแบ่งพาร์ติชันตามโหนดหลายโหนดในชั้นวางนั้น

Dynomite เป็นเลเยอร์การกระจายแบบเพียร์ทูเพียร์ ดังนั้นไคลเอนต์สามารถส่งทราฟฟิกการเขียนไปยังโหนดใดก็ได้ในคลัสเตอร์ Dynomite หากโหนดเป็นผู้รับผิดชอบข้อมูล ข้อมูลจะถูกเขียนไปยังกระบวนการเซิร์ฟเวอร์ Redis OSS ในพื้นที่ จากนั้นจึงจำลองแบบอะซิงโครนัสไปยังแร็คอื่นๆ ในคลัสเตอร์ทั่วทั้งศูนย์ข้อมูลทั้งหมด หากโหนดไม่ได้เป็นเจ้าของข้อมูล จะทำหน้าที่เป็นผู้ประสานงานและส่งการเขียนไปยังโหนดที่เป็นเจ้าของข้อมูลในชั้นวางเดียวกัน นอกจากนี้ยังจำลองการเขียนไปยังโหนดที่เกี่ยวข้องในชั้นวางและ DC อื่นๆ

เรดิส เอ็นเตอร์ไพรส์

คลัสเตอร์ Redis Enterprise ยังแจกจ่ายข้อมูลข้ามอินสแตนซ์หรือชาร์ดของ Redis ที่แตกต่างกันด้วย แต่มีความแตกต่างหลักสองประการ:

• สามารถมีชาร์ดได้มากกว่าหนึ่งชาร์ดบนโหนด – แต่โหนดหลักและตัวจำลองไม่สามารถอยู่บนโหนดเดียวกันได้เพื่อความพร้อมใช้งานสูง

• มีตัวจำลองเพียงตัวเดียวสำหรับชาร์ดหลักแต่ละชาร์ด ลูกค้าดำเนินการข้อมูลบนชาร์ดหลัก มีแบบจำลองที่เกี่ยวข้องเพื่อความพร้อมใช้งานสูงในกรณีที่ชาร์ดหลักล้มเหลว

ส่วนสำคัญอีกส่วนหนึ่งของคลัสเตอร์ Redis Enterprise คือสิ่งที่เรียกว่า “เส้นทางการจัดการ” ประกอบด้วย Cluster Manager, Proxy และ REST API/UI Cluster Manager มีหน้าที่รับผิดชอบในการจัดคลัสเตอร์ วางชาร์ดฐานข้อมูลในโหนดที่มีความพร้อมใช้งานสูง และตรวจจับความล้มเหลว พร็อกซีจะซ่อนโทโพโลยีคลัสเตอร์ของ Redis Enterprise จากแอปพลิเคชันโดยจัดเตรียมปลายทางเดียวที่ไม่มีวันเปลี่ยนแปลง สำหรับแต่ละฐานข้อมูลภายในคลัสเตอร์ นอกจากนี้ยังช่วยปรับขนาดการเชื่อมต่อไคลเอ็นต์ด้วยคำสั่งมัลติเพล็กซ์และไพพ์ไลน์ไปยังชาร์ด

นี่คือภาพประกอบของ Redis Enterprise Cluster ทั่วไป:

ด้วยคุณสมบัติ Active-Active ของ Redis Enterprise คุณสามารถสร้างฐานข้อมูลส่วนกลางที่ครอบคลุมหลายคลัสเตอร์ โดยทั่วไปแล้วคลัสเตอร์เหล่านี้จะอยู่ในศูนย์ข้อมูลต่างๆ ทั่วโลก แอปพลิเคชันที่เขียนไปยังฐานข้อมูล Active-Active เชื่อมต่อกับปลายทางอินสแตนซ์ในเครื่อง การเขียนทั้งหมดโดยแอปพลิเคชันไปยังอินสแตนซ์ในเครื่องจะถูกจำลองไปยังอินสแตนซ์อื่นๆ ทั้งหมดที่มีความสอดคล้องกันในที่สุด

การจำลองแบบ Active-Active มีข้อดีหลายประการในฐานะโซลูชันแบบกระจายตามพื้นที่ ซึ่งหนึ่งในนั้นคือการแก้ไขข้อขัดแย้งที่ราบรื่นสำหรับประเภทข้อมูล Redis Enterprise ที่เรียบง่ายและซับซ้อน ซึ่งเราจะพูดถึงด้านล่าง

ตอนนี้เรามีแนวคิดเกี่ยวกับโทโพโลยีของ Dynomite และ Redis Enterprise แล้ว มาดูกันว่าสิ่งเหล่านี้เกี่ยวข้องกับนักพัฒนาและ DevOps ภายในองค์กรอย่างไรบ้าง

Dynomite หรือ Redis Enterprise:นักพัฒนาสร้างความแตกต่างอย่างไร

นอกจาก Dynomite ไม่ได้รับการดูแลอย่างจริงจังแล้ว ยังมีสาเหตุหลักสามประการที่องค์กรต้องการย้ายไปยัง Redis Enterprise จากมุมมองของนักพัฒนา:

• ฟังก์ชันของ Redis มีข้อจำกัดและซับซ้อนมากขึ้นเมื่อใช้ Dynomite

• ไดโนไมต์ไม่มีวิธีที่มีประสิทธิภาพในการจัดการกับข้อขัดแย้งในการเขียนแบบกระจายตามพื้นที่

• การสนับสนุนที่คุณจะได้รับจาก Redis 

เรามาดูรายละเอียดสองข้อแรกกันดีกว่า

Redis OSS ที่จำกัดและซับซ้อน

อย่างที่คุณอาจทราบอยู่แล้วว่า Redis OSS ไม่ใช่ที่เก็บคีย์-ค่าธรรมดา ในแง่ที่ว่าไม่เพียงแต่ช่วยให้คุณเชื่อมโยงคีย์สตริงกับค่าสตริงเท่านั้น Redis OSS เป็นเซิร์ฟเวอร์โครงสร้างข้อมูลที่สนับสนุนค่าประเภทต่างๆ เช่น รายการ ชุด แฮช หรือสตรีม เราเรียกสิ่งเหล่านี้ว่า “ประเภทข้อมูลหลัก” ของ Redis OSS

Redis OSS ยังขยายได้ผ่านไลบรารีไดนามิกที่เรียกว่า “โมดูล” โมดูลช่วยให้คุณสามารถใช้คำสั่ง Redis ใหม่ได้อย่างรวดเร็วด้วยคุณลักษณะที่คล้ายกับสิ่งที่สามารถทำได้ภายในแกนหลัก โมดูลยอดนิยม ได้แก่ RediSearch ซึ่งให้การสืบค้น การจัดทำดัชนีรอง และการค้นหาข้อความแบบเต็ม และ RedisJSON ซึ่งเปลี่ยน Redis OSS ให้เป็นที่เก็บเอกสารที่มีประสิทธิภาพ

ตามที่กล่าวไว้ในบทนำ คำสั่ง Redis OSS และประเภทข้อมูลบางประเภทจะแสดงผลไม่พร้อมใช้งานหรือถูกจำกัดโดย Dynomite นี่คือการเปรียบเทียบโดยสังเขป:

คุณสามารถค้นหารายการคำสั่งที่รองรับและไม่รองรับทั้งหมดกับ Dynomite ได้ที่นี่

ในทางกลับกัน Redis Enterprise ซึ่งได้รับการบำรุงรักษาควบคู่ไปกับ Redis OSS ช่วยให้สามารถดำเนินการหลายรุ่นโดยใช้โมดูล และสำหรับโครงสร้างข้อมูล Redis OSS หลักที่สามารถดำเนินการในลักษณะที่ตั้งโปรแกรมได้และกระจายอย่างเต็มรูปแบบ

ไม่มีการแก้ไขข้อขัดแย้ง

Dynomite เป็นระบบ AP และให้คุณสามตัวเลือกเพื่อความสอดคล้อง ไม่ว่าคุณจะเลือกตัวเลือกใด สิ่งสำคัญที่ควรทราบคือ Dynomite แก้ไขข้อขัดแย้งในการเขียนแบบอะซิงโครนัสโดยใช้กลยุทธ์ Last Write Wins ซึ่งอาจนำไปสู่การอัปเดตที่สูญหายเนื่องจากการประทับเวลาที่ไม่เกี่ยวข้อง โดยเฉพาะอย่างยิ่งในบริบทของการเขียนแบบกระจายตามภูมิศาสตร์

ในทางกลับกัน สถาปัตยกรรม Active-Active ของ Redis Enterprise อิงจากการใช้งานทางเลือกของคำสั่ง Redis OSS และประเภทข้อมูลที่เรียกว่า Conflict-Free-Replicated-Data-Types หรือ CRDTs CRDTs ใช้นาฬิกาเวกเตอร์สำหรับการสั่งซื้อเหตุการณ์ พวกเขาทำให้แน่ใจว่าเมื่อแบบจำลองใดๆ สองชุดได้รับการอัปเดตชุดเดียวกัน พวกเขาจะไปถึงสถานะเดียวกันโดยกำหนดโดยการใช้กฎที่มีเหตุผลทางคณิตศาสตร์เพื่อรับประกันการบรรจบกันของสถานะ นอกจากนี้ ยังสามารถทำให้เกิดความสอดคล้องเชิงสาเหตุได้เช่นกัน

ดังนั้นกับ Redis Enterprise:

• ผลลัพธ์ของการเขียนพร้อมกันสามารถคาดเดาได้และขึ้นอยู่กับชุดของกฎ

• แอปพลิเคชันไม่จำเป็นต้องกังวลกับการเขียนพร้อมกันและการแก้ปัญหาข้อขัดแย้งในการเขียน

• ในที่สุดชุดข้อมูลจะรวมเป็นสถานะเดียวที่สม่ำเสมอในที่สุด

หากพร้อมแล้ว คุณสามารถค้นหากฎที่นำไปใช้ รวมถึงตัวอย่างการแก้ไขข้อขัดแย้งได้โดยไปที่ลิงก์นี้

Dynomite หรือ Redis Enterprise:DevOps มีความแตกต่างกันอย่างไร

ตอนนี้ เรามาเปรียบเทียบ Dynomite และ Redis Enterprise จากมุมมองของ DevOps โดยพูดคุยกันในหัวข้อต่อไปนี้:

• ความพร้อมใช้งานสูง

• ความสามารถในการปรับขนาด

• ความสามารถในการปรับใช้

ความพร้อมใช้งานสูง

เมื่อโหนดล้มเหลวภายในแร็ค Dynomite การเขียนและการอ่านไปยังแร็คจะเป็นไปไม่ได้ ซึ่งหมายความว่าแอปพลิเคชันที่เขียนในเครื่องจำเป็นต้องจัดการกับการเฟลโอเวอร์ไปยังแร็คอื่นด้วยตัวมันเอง โปรดทราบว่าหากแอปพลิเคชันของคุณพัฒนาขึ้นใน Java ไคลเอ็นต์ Dyno ของ Netflix จะจัดการกับการเฟลโอเวอร์ไปยังแร็คระยะไกลได้เมื่อโหนด Dynomite ในพื้นที่ทำงานล้มเหลว

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

ความพร้อมใช้งานสูงของ Redis Enterprise เป็นอย่างไร

เมื่อโหนดล้มเหลว จะเกิดข้อผิดพลาดเพียงหลักเดียวในวินาทีสำหรับชาร์ดหลักทั้งหมดที่อาศัยอยู่บนโหนดนั้น และการจำลองของพวกมันจะถูกเลื่อนระดับเป็นไพรมารี กลไกการเฟลโอเวอร์อัตโนมัตินี้รับประกันว่าข้อมูลจะได้รับบริการโดยมีการหยุดชะงักน้อยที่สุด

ตามนี้ :

• พร็อกซี Redis Enterprise ทำให้แน่ใจว่าจุดปลายเดียวของฐานข้อมูลของคุณ ซึ่งจะไม่เปลี่ยนแปลงในกรณีที่เกิดเฟลโอเวอร์ ดังนั้นจึงไม่จำเป็นต้องกำหนดค่าแอปพลิเคชันของคุณใหม่

• มีตัวเลือก “replica_ha” ที่ช่วยให้แน่ใจว่าเมื่อมีการเลื่อนระดับแบบจำลองเป็นแบบจำลองหลัก ส่วนแบ่งข้อมูลจำลองที่ซิงค์ใหม่จะถูกสร้างขึ้นโดยอัตโนมัติบนโหนดอื่นๆ ที่มีอยู่

กลไกเหล่านี้ช่วยให้ Redis Enterprise รับประกันความพร้อมในการทำงาน 99.99% และความพร้อมในการทำงาน 99.999% สำหรับการปรับใช้ Active-Active

ความสามารถในการปรับขนาด

Dynomite ช่วยให้คุณปรับขนาด Redis OSS ในขณะที่ยังคงประสิทธิภาพที่ดีในแง่ของเวลาแฝง คุณสามารถตรวจสอบการวัดประสิทธิภาพได้ แต่ถ้าคุณใช้ Dynomite คุณคงรู้อยู่แล้ว

เมื่อพูดถึงความสามารถในการปรับขนาด ความแตกต่างหลักระหว่าง Dynomite และ Redis Enterprise คือ:

• ความสามารถในการจัดการ

• การจัดการการเชื่อมต่อแบบสำเร็จรูป

• การเพิ่มประสิทธิภาพทรัพยากร

ความสามารถในการจัดการ

หากคุณไม่ได้ใช้ Dynomite Manager ภายในกลุ่มการปรับขนาดอัตโนมัติของ AWS การเพิ่มโฮสต์ไปยังแร็ค Dynomite ที่ทำงานอยู่มักจะต้องการ:

• ใช้ประโยชน์จากเทคนิค "การเขียนแบบคู่" โดยใช้ไคลเอ็นต์ Java Dyno แอปพลิเคชันของคุณเขียนลงในคลัสเตอร์เก่า/เล็กรวมถึงคลัสเตอร์ใหม่/ปรับขนาด หลังจากผ่านไปสองสามวัน คุณจะกำหนดเส้นทางการรับส่งข้อมูลไปยังคลัสเตอร์ใหม่เท่านั้นและทำให้เป็นคลัสเตอร์ที่ใช้งานอยู่

• การย้ายฐานข้อมูลของคุณจากคลัสเตอร์เก่า/เล็กไปยังคลัสเตอร์ใหม่/ปรับขนาด

ในทางกลับกัน Redis Enterprise ช่วยให้คุณ:

• ขยายขนาดโดยการเพิ่มชาร์ดลงในฐานข้อมูลของคุณโดยไม่ต้องเพิ่มโหนดในคลัสเตอร์ของคุณ:สถานการณ์นี้มีประโยชน์เมื่อมีความจุไม่เพียงพอในคลัสเตอร์ ข้อควรจำ:หนึ่งโหนดไม่เท่ากับหนึ่งอินสแตนซ์ Redis การแบ่งส่วนฐานข้อมูลของคุณใหม่สามารถทำได้ในไม่กี่คลิกผ่าน Redis Enterprise UI หรือโดยการใช้ประโยชน์จาก REST API ของ Redis Enterprise ทำได้โดยไม่มีการหยุดทำงานหรือการหยุดชะงักของบริการ นอกจากนี้ยังโปร่งใสต่อแอปพลิเคชันเนื่องจากปลายทางของฐานข้อมูลไม่เปลี่ยนแปลง

• ขยายขนาดโดยการเพิ่มโหนดไปยังคลัสเตอร์ ภาพจำลองนี้มีประโยชน์หากต้องการทรัพยากรทางกายภาพเพิ่มเติมเพื่อเพิ่มชาร์ดลงในฐานข้อมูลของคุณ โปรดทราบว่าด้วย Redis Enterprise Cloud ซึ่งเป็นข้อเสนอ DBaaS ที่มีการจัดการเต็มรูปแบบของเรา องค์กรไม่จำเป็นต้องกังวลเกี่ยวกับขั้นตอนนี้ Redis จะจัดเตรียมและจัดการโครงสร้างพื้นฐานและทรัพยากรสำหรับพวกเขา ดูข้อมูลเพิ่มเติมในส่วนการทำให้ใช้งานได้ของบทความนี้

นี่คือเกณฑ์มาตรฐานที่ Redis ทำเมื่อไม่กี่ปีก่อน ซึ่ง Redis Enterprise ส่งมอบมากกว่า 200 ล้าน ops/วินาที ด้วยเวลาแฝงที่ต่ำกว่ามิลลิวินาทีบนอินสแตนซ์ AWS 40 รายการ

การจัดการการเชื่อมต่อ

เมื่อเราพูดถึงการจัดการการเชื่อมต่อกับ Redis สิ่งแรกที่นึกถึงคือวิธีที่ไคลเอ็นต์ Redis เช่น Jedis หรือ Lettuce จัดการกับการรวมการเชื่อมต่อและการวางท่อ Netflix ก็ไม่มีข้อยกเว้นในเรื่องนี้และใช้คุณลักษณะเหล่านี้กับไคลเอ็นต์ Dyno ของตน

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

นอกจากนี้ พร็อกซียังเป็นแบบมัลติเธรด และจะปรับขนาดโดยอัตโนมัติเพื่อจัดการกับการแตกในการเชื่อมต่อไคลเอ็นต์

การเพิ่มประสิทธิภาพทรัพยากร

ประการแรก จำไว้ว่าภายในคลัสเตอร์ Redis Enterprise เครื่องหนึ่งเครื่องไม่เท่ากับอินสแตนซ์ Redis หนึ่งอินสแตนซ์ และชาร์ดหลักแต่ละเครื่องสามารถมีแบบจำลองได้ไม่เกิน 1 รายการเท่านั้น

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

สุดท้าย Redis Enterprise มีคุณลักษณะที่เรียกว่า Redis On Flash (RoF) RoF ช่วยให้ฐานข้อมูลของคุณใช้ทั้ง RAM และหน่วยความจำแฟลชเฉพาะ (SSD/NVMe) เพื่อจัดการชุดข้อมูลที่มีขนาดใหญ่กว่ามากด้วยเวลาแฝงและประสิทธิภาพเหมือน RAM แต่มีค่าใช้จ่ายต่ำกว่า>70% เมื่อเทียบกับฐานข้อมูล RAM ทั้งหมด

ตัวเลือกการทำให้ใช้งานได้

สามารถปรับใช้ Dynomite ในคอนเทนเนอร์หรือเครื่องที่ใช้ Ubuntu, RHEL และ CentOS การปรับใช้จะได้รับการจัดการด้วยตนเองเสมอ ในแง่ที่ว่าคุณจำเป็นต้องจัดเตรียมโครงสร้างพื้นฐานและทรัพยากรเพื่อจัดการคลัสเตอร์ของคุณ ตามที่กล่าวไว้ก่อนหน้านี้ หากคุณต้องการใช้ประโยชน์จากคุณสมบัติของ Dynomite Manager คุณต้องปรับใช้ Dynomite ภายในกลุ่มการปรับขนาดอัตโนมัติของ AWS

ในทางกลับกัน Redis Enterprise มีตัวเลือกการปรับใช้มากมาย ซึ่งสามารถแบ่งออกเป็นสองกลุ่ม:

• โซลูชันที่จัดการด้วยตนเอง ซึ่งคุณดาวน์โหลด ติดตั้ง และปรับใช้ซอฟต์แวร์ Redis Enterprise ด้วยตนเอง มีตัวเลือกมากมายซึ่งรวมถึงตัวติดตั้ง Linux (การกระจายหลายตัว), Amazon Machine Image (AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) หรือ Amazon Elastic Kubernetes Service (EKS) )

• โซลูชันที่มีการจัดการ:Redis Enterprise Cloud นำเสนอเป็นบริการคลาวด์ที่มีการจัดการเต็มรูปแบบ (DBaaS) บนแพลตฟอร์มคลาวด์สาธารณะหลักทั้งสาม (Google Cloud, AWS และ Azure) Redis จะโฮสต์สภาพแวดล้อมเฉพาะสำหรับคุณ พร้อมด้วยทรัพยากรที่จำเป็น ซึ่งคุณสามารถสร้างฐานข้อมูลที่มีปลายทางส่วนตัวและสาธารณะเพื่อให้แอปพลิเคชันของคุณใช้งานได้