ভূমিকা
সবকিছু হেলথি থাকলে Redis রক স olid লাগে। আসল টেস্ট শুরু হয় যখন কিছু ভেঙে যায়। একটি নোড ক্র্যাশ করে, একটি ভার্চুয়াল মেশিন রিবুট হয়, একটি কন্টেইনার গায়েব হয়, বা একটি নেটওয়ার্ক ইস্যু সিস্টেমের এক অংশকে আইসোলেট করে।
এরপর কী হবে সেটি সম্পূর্ণভাবে নির্ভর করে রেপ্লিকেশন এবং হাই আভেইলেবিলিটি কীভাবে ডিজাইন করা হয়েছিল। অনেক টিম অনুমান করে Redis অটোমেটিক্যালি ফেইলিউর হ্যান্ডেল করে, কিন্তু সেটি সত্য নয়। Redis বিল্ডিং ব্লকস দেয়, ফিনিশড সলিউশন দেয় না।
রেপ্লিকেশন এবং হাই আভেইলেবিলিটি ভিন্ন সমস্যা সমাধান করে। Redis দুটোই সাপোর্ট করে, কিন্তু পার্থক্য বোঝা প্রোডাকশন-রেডি রেজিলিয়েন্ট সিস্টেম বিল্ড করার জন্য ক্রিটিক্যাল।
Redis রেপ্লিকেশন আসলে কী করে
এর কোরে, Redis রেপ্লিকেশন হলো একটি নোড থেকে অন্যগুলোতে ডেটা কপি করা। একটি প্রাইমারি নোড, जिसे সাধারণত মাস্টার বলা হয়, সকল রাইট অপারেশন হ্যান্ডেল করে। এক বা একাধিক রেপ্লিকা নোড একটি কন্টিনিউয়াস স্ট্রিমে চেঞ্জেস রিসিভ করে এবং তাদের ডেটা সিঙ্কে রাখে।
রেপ্লিকেশন তিনটি মূল কারণেই অস্তিত্বে আছে: রিড স্কেলিং, ফেইলোভার রেডিনেস, এবং ডেটা রिडান্ডেন্সি। তবে রেপ্লিকেশন একা হাই আভেইলেবিলিটি গ্যারান্টি দেয় না। এটি শুধু তার জন্য 잉্রেডিয়েন্টস প্রোভাইড করে।
রেপ্লিকেশন কীভাবে হুডের নিচে কাজ করে
যখন একটি রেপ্লিকা মাস্টারের সাথে কানেক্ট হয়, এটি একটি ইনিশিয়াল সিঙ্ক্রোনাইজেশন প্রসেস দিয়ে শুরু করে। মাস্টার তার কারেন্ট ডেটার একটি স্ন্যাপশট তৈরি করে এবং রেপ্লিকাকে পাঠায়। রেপ্লিকা এই স্ন্যাপশট মেমরিতে লোড করে।
ইনিশিয়াল সিঙ্কর পর, মাস্টার সকল সাবসিকোয়েন্ট রাইট কমান্ড রেপ্লিকাতে স্ট্রিম করে। রেপ্লিকা এই কমান্ডগুলো একই অর্ডারে অ্যাপ্লাই করে কনসিস্টেন্ট থাকার জন্য।
এই পদ্ধতি ইফিশিয়েন্ট এবং সিম্পল, কিন্তু এটি গুরুত্বপূর্ণ ট্রেডঅফ আনে। রেপ্লিকেশন ডিফল্টলি অ্যাসিনক্রোনাস, যার মানে সবসময় একটি ছোট উইন্ডো থাকে যেখানে ডেটা মাস্টারে এক্সিস্ট করে কিন্তু রেপ্লিকাগুলোতে এখনও নেই।
অ্যাসিনক্রোনাস রেপ্লিকেশন এবং ডেটা লস রিস্ক
অ্যাসিনক্রোনাস রেপ্লিকেশন Redis-কে ফাস্ট এবং রেসপনসিভ রাখে, কিন্তু এটিও মানে কিছু ডেটা লস সম্ভব যদি মাস্টার ফেইল করে।
যদি মাস্টার ক্র্যাশ করে রেপ্লিকাগুলো লেটেস্ট রাইটস রিসিভ করার আগে, সেই রাইটস লস হয়ে যায়। Redis এই রিয়ালিটি লুকাতে চায় না। ক্যাশ ডেটার জন্য, এটি সাধারণত এক্সেপটেবল। ক্রিটিক্যাল স্টেটের জন্য, এটি নাও হতে পারে।
Redis অপশন দেয় রেপ্লিকেশন স্ট্রিক্টার করার জন্য, কিন্তু স্ট্রিক্টার গ্যারান্টি লেটেন্সি বাড়ায় এবং অভেইলেবিলিটি কমায়। কতটুকু ডেটা লস এক্সেপটেবল সেটি একটি কী আর্কিটেকচারাল সিদ্ধান্ত।
রেপ্লিকাস ব্যবহার করে রিড স্কেল করা
Redis রেপ্লিকেশন ব্যবহার করার একটি সাধারণ কারণ হলো রিড ট্রাফিক স্কেল করা। অ্যাপ্লিকেশনগুলো রাইট অপারেশন মাস্টারের দিকে এবং রিড অপারেশন রেপ্লিকাগুলোর জুড়ে ডিস্ট্রিবিউট করতে পারে।
এটি মাস্টারের ওপর লোড কমায় এবং ওভারঅল থ্রুপুট উন্নত করে। কিন্তু যেহেতু রেপ্লিকেশন অ্যাসিনক্রোনাস, রেপ্লিকাগুলো স্লাইটলি স্টেল ডেটা রিটার্ন করতে পারে।
ক্যাশিং প্রোফাইল বা কনফিগারেশন এর মত ইউজ কেসের জন্য, এটি সাধারণত ফাইন। স্ট্রং কনসিস্টেন্সি রিকোয়ার্ড করা সিনেরিওর জন্য, এটি এক্সেপটেবল নাও হতে পারে। টিমরা এই ট্রেডঅফ ইণ্টেনশনালি নিতে হবে।
যখন মাস্টার ফেইল করে তখন কী হয়
রেপ্লিকেশন একা মাস্টার ফেইলিউর হ্যান্ডেল করে না। যখন মাস্টার ডাউন হয়, রেপ্লিকাগুলো সিঙ্কড থাকে কিন্তু কোনো এক্সটার্নাল ফেইলোভার মেকানিজম ছাড়া অটোমেটিক্যালি প্রোমোট হয় না।
হাই আভেইলেবিলিটি কোয়াইচকস কিছু দরকার যা ফেইলিউর ডিটেক্ট করবে, ডিসিশন কোঅর্ডিনেট করবে, এবং একটি নতুন মাস্টার প্রোমোট করবে। এখানেই ফেইলোভার সিস্টেমস আসে।
Redis Sentinel এবং হাই আভেইলেবিলিটি
Redis Sentinel Redis-এ হাই আভেইলেবিলিটি যোগ করার ট্রেডিশনাল সমাধান। Sentinel প্রসেসগুলো Redis ইনস্ট্যান্স মনিটর করে, ফেইলিউর ডিটেক্ট করে, এবং একে অপরের সাথে কমিউনিকেট করে কনসেনসাস পাওয়ার জন্য।
যখন Sentinel-রা সম্মত হয় যে মাস্টার ডাউন, রেপ্লিকাগুলোর একটি নতুন মাস্টার হিসেবে প্রোমোট হয়। Sentinel-রা ক্লায়েন্টদেরও নোটিফাই করে যাতে সেগুলো সঠিক নোডের সাথে রিকানেক্ট করতে পারে।
Sentinel অ্যাডিশনাল কম্পোনেন্ট এবং কমপ্লেক্সিটি আনে। কার্যকর হতে, একাধিক Sentinel নোড রান করতে হবে। একটি সিঙ্গেল Sentinel সত্যিকার হাই আভেইলেবিলিটির জন্য পর্যাপ্ত নয়।
Sentinel কীভাবে ফেইলোভার ডিসাইড করে
Sentinel টাইমআউট এবং কোরম ব্যবহার করে ফালস ফেইলোভার এড়াতে। একাধিক Sentinel সম্মত হতে হবে যে মাস্টার অনরিচেয়েবল প্রোমোশনের আগে।
এই ডিজাইন রিলায়েবিলিটি উন্নত করে কিন্তু মানে ফেইলোভার ইনস্ট্যান্টেনিয়াস নয়। সবসময় একটি ছোট পিরিয়ড থাকে যখন মাস্টার অনভেইলেবল এবং কোনো রিপ্লেসমেন্ট এক্টিভ নয়।
অ্যাপ্লিকেশনগুলো এই উইন্ডো গ্রেসফুলি হ্যান্ডেল করার জন্য ডিজাইন করা উচিত। রিট্রাই, টাইমআউট, এবং ফলব্যাক বিহেভিয়র এসেনশিয়াল।
Redis Cluster এবং বিল্ট-ইন হাই আভেইলেবিলিটি
Redis Cluster রেপ্লিকেশন এবং ফেইলোভার সরাসরি সিস্টেমে ইন্টিগ্রেট করে। প্রতিটি শার্ডের একটি মাস্টার এবং রেপ্লিকা থাকে, এবং মাস্টার ফেইল করলে ফেইলোভার অটোমেটিক্যালি হয়।
এটি Sentinel-এর প্রয়োজন নেই করে দেয় কিন্তু অন্যান্য কনস্ট্রেইন্ট আনে। কী ডিস্ট্রিবিউশন, ক্লায়েন্ট বিহেভিয়র, এবং ক্রস-শার্ড অপারেশন কেয়ারফুল ডিজাইন দরকার।
Redis Cluster হাই আভেইলেবিলিটি সিম্পলিফাই করে কিন্তু স্ট্রিক্টার আর্কিটেকচারাল বাউন্ডারি আরোপ করে।
ফেইলোভার মানে জিরো ডাউনটাইম নয়
একটি সাধারণ মিসকনসেপশন হলো Redis ফেইলোভার জিরো ডাউনটাইম গ্যারান্টি দেয়। বাস্তবে, ফেইলোভার ফাস্ট কিন্তু ইনস্ট্যান্টেনিয়াস নয়।
ফেইলোভারের সময়, কিছু রিকোয়েস্ট ফেইল করবে বা রিট্রাই দরকার হবে। ভালো ডিজাইন করা সিস্টেম এই বিহেভিয়র এক্সপেক্ট করে এবং গ্রেসফুলি রিকভার করে। খারাপ ডিজাইন করা সিস্টেম ক্র্যাশ করতে পারে বা ক্যাসকেডিং ফেইলিউর ট্রিগার করতে পারে।
হাই আভেইলেবিলিটি রেজিলিয়েন্স উন্নত করে, পারফেকশন নয়।
স্প্লিট ব্রেন এবং এর রিস্ক
স্প্লিট ব্রেন হয় যখন একাধিক নোড মনে করে সেটিই মাস্টার। Redis এবং Sentinel এই প্রতিবন্ধক করার জন্য ডিজাইন করা, কিন্তু নেটওয়ার্ক পার্টিশন এবং মিসকনফিগারেশন এখনও এটিকে করতে পারে।
স্প্লিট ব্রেন কনফ্লিক্টিং রাইটস এবং ডেটা করপশনে ফলাফল দিতে পারে। এই রিস্ক কমাতে প্রপার Sentinel কোরম, সঠিক নেটওয়ার্ক সেটআপ, এবং সেন্সিবল টাইমআউট দরকার।
এই ডিটেইলস উপেক্ষা করা রেয়ার কিন্তু সিভিয়ার ইনসিডেন্টের সাধারণ কারণ।
রেপ্লিকেশন ল্যাগ এবং পারফরম্যান্স ইমপ্যাক্ট
রেপ্লিকেশন ল্যাগ সাধারণত ছোট কিন্তু কখনো শূন্য নয়। হেভি রাইট লোড আন্ডারে, রেপ্লিকাগুলো মাস্টার পিছিয়ে পড়তে পারে।
যদি হাই ল্যাগের পিরিয়ডে ফেইলোভার হয়, ডেটা লস বাড়ে। রেপ্লিকেশন ল্যাগ মনিটর করা এসেনশিয়াল সিস্টেমগুলোর জন্য যেগুলো ডেটা ইন্টégrিটি কেয়ার করে।
ল্যাগে হঠাৎ বৃদ্ধি প্রায়শই আন্ডারলায়িং পারফরম্যান্স বা রিসোর্স ইস্যু সিগন্যাল করে।
কেন রেপ্লিকেশন ব্যাকআপ নয়
রেপ্লিকেশনকে ব্যাকআপের সাথে গুলিয়ে ফেলা উচিত নয়। যদি মাস্টারে ডেটা ডিলিট হয়, সেটি অবিলম্বে রেপ্লিকেট হয়।
ব্যাকআপ হিউম্যান এরর এবং লজিক্যাল করপশন থেকে রক্ষা করে। রেপ্লিকেশন হার্ডওয়্যার বা প্রসেস ফেইলিউর থেকে রক্ষা করে। উভয়ই দরকার যদি Redis ভ্যালুয়েবল ডেটা স্টোর করে।
সাধারণ Redis HA মিস্টেক
টিমরা প্রায়শই একই মিস্টেকগুলো করে Redis হাই আভেইলেবিলিটি ডিজাইন করার সময়। এগুলো شامل: অনুমান করা রেপ্লিকেশন ইকুয়াল্স হাই আভেইলেবিলিটি, শুধু একটা Sentinel রান করা, রেপ্লিকেশন ল্যাগ উপেক্ষা করা, ফেইলোভার টেস্ট না করা, এবং অ্যাপ্লিকেশনকে Redis এরররে ক্র্যাশ হওয়া দেয়া।
এই মিস্টেকগুলো রিয়েল-ওয়ার্ল্ড আউটেজ রিপোর্টে বারবার দেখা যায়।
ফেইলিউর টেস্টিং ডিজাইনের অংশ হিসেবে
হাই আভেইলেবিলিটি যেটি কখনো টেস্ট করা হয়নি সেটি কাগজে মাত্র এক্সিস্ট করে। টিমরা রেগুলারলি ফেইলিউর সিমুলেট করা উচিত মাস্টার কন্ট্রোলড এনভায়রনমেন্টে স্টপ করলেও।
ফেইলোভার বিহেভিয়র পর্যবেক্ষণ, রিকভারি টাইম মাপ, এবং অ্যাপ্লিকেশন রেসপন্স বোঝা अमূল্য ইনসাইট দেয় যেটি কোনো ডকুমেন্টেশন দিতে পারে না।
Redis HA-এর জন্য একটি প্র্যাক্টিক্যাল মেন্টাল মডেল
Redis হাই আভেইলেবিলিটি হলো গ্রেসফুল ডিগ্রেডেশন। যখন Redis হেলথি, সিস্টেম ভালো পারফর্ম করে। যখন Redis আনহেলথি, পারফরম্যান্স ডিগ্রেড হতে পারে। যখন Redis অনুপলব্ধ, সিস্টেমকে সারভাইভ করতে হবে।
যদি Redis ডাউন হওয়া টোটাল সিস্টেম আউটেজ করে, হাই আভেইলেবিলিটি ইনকমপ্লিট।
সারসংক্ষেপ
Redis রেপ্লিকেশন এবং হাই আভেইলেবিলিটি আকৃতি দেয় সিস্টেম স্ট্রেস আন্ডারে কীভাবে behave করবে। রেপ্লিকেশন ডেটার কপি দেয়, হাই আভেইলেবিলিটি সার্ভিস কন্টিনিউইটি দেয়।
দুটোই কেয়ারফুল ডিজাইন, রিয়েলিস্টিক এক্সপেক্টেশন, এবং কন্টিনিউઅস টেস্টিং দরকার। সঠিকভাবে ইমপ্লিমেন্ট করা হলে, Redis ফেইলিউরগুলো রুটিন ইভেন্ট হয়ে যায় মেজর ইনসিডেন্টের বদলে। এটিই Redis হাই আভেইলেবিলিটির গোল।
