Amazon Aurora হাই-অভেইলেবিলিটি কৌশল: একটি সম्पূর্ণ গাইড

আপনি যদি এটি পড়ছেন, তবে আপনি সম্ভবত Amazon Aurora সম্পর্কে শুনেছেন। আপনি জানেন, Amazon Aurora AWS-এর RDS সেবার স্যুটের অংশ হিসাবে প্রদত্ত একটি PaaS সেবা। এটি একটি ফুলি ম্যানেজড রিলেশনাল ডেটাবেস ম্যানেজমেন্ট সিস্টেম (RDBMS) যা দুটি ফ্লেভারে আসে: MySQL এবং Postgres, এবং উভয়টির সাথে ওয়ায়ার কম্প্যাটিবিলিটি বজায় রাখে। কিন্তু এটি আপনার হাই-অভেইলেবিলিটি কৌশল এবং বিকল্পগুলিকে কীভাবে প্রভাবিত করে?

আপনি প্রশ্ন করতে পারেন Amazon Aurora, Amazon RDS-এ MySQL বা PostgreSQL থেকে কীভাবে ভিন্ন। এগুলোও ফুলি ম্যানেজড RDBMS সেবা, ঠিক না? হ্যাঁ, কিন্তু এগুলো মূলত סט্যান্ডার্ড ওপেন-সোর্স ইমপ্লিমেন্টেশন যা EC2 ইনস্ট্যান্সের একটি ফ্লিটে চলে এবং AWS দ্বারা ম্যানেজ করা হয়। Aurora-এর মূল পার্থক্য হলো AWS স্টোরেজ ইঞ্জিনকে ডেটাবেস ইঞ্জিন থেকে আলাদা করেছে। AWS ওপেন-সোর্স ডেটাবেসে কনসার্নস আলাদা করার নীতিটি প্রয়োগ করেছে।

কনসার্নস আলাদা করা

সাধারণত, একটি RDBMS সাধারণত উপলব্ধ হার্ডওয়্যারে চালাতে হয়। এর মানে হলো ইমপ্লিমেন্টেশন OS এবং হার্ডওয়্যারের सीমাবদ্ধতা 속에서 কাজ করতে হবে যাতে আমরা আধুনিক ডেটাবেস থেকে আশা করি এমন সকল ফিচার পেতে পারি, যেমন: DML এবং DDL প্রসেসিং, ACID কম্প্লায়েন্ট ট্রানজ্যাকশন, রেপ্লিকেশন, হাই-অভেইলেবিলিটি (HA), এবং ফল্ট টলারেন্স। যদি তবে, ইমপ্লিমেন্টেশনকে সাধারণ হার্ডওয়্যারে চালানোর প্রয়োজন না হতো বরং শুধু ডেটাবেসের জন্য নির্দিষ্টভাবে ডিজাইন করা একটি পরিবেশে চালাতে হতো, তবে বিভিন্ন দায়িত্ব লেয়ারে আলাদা করা যেতো, যা ডেটাবেস ইঞ্জিন এবং স্টোরেজ ইঞ্জিনকে ফোকাসড এবং স্পেশালাইজড করতে দিত। ফলস্বরূপ, হাই-অভেইলেবিলিটি এবং কর্মক্ষমতা উল্লেখযোগ্যভাবে বেড়ানো যায় – স্ট্যান্ডার্ড MySQL-এর চেয়ে ৫ গুণ বেশি কর্মক্ষমতা এবং স্ট্যান্ডার্ড PostgreSQL-এর চেয়ে ৩ গুণ বেশি।

ঠিক আছে, এটি দ্রুত, কিন্তু একটি স্পেশালাইজড ডেটাবেস এবং স্টোরেজ ইঞ্জিন কীভাবে HA-তে সাহায্য করে? এই আলাদা করার ফলে HA অর্জনে অনেক উপায়ে সাহায্য मिलে। এগিয়ে বড়তে ওর আগে, আসুন দ্রুত একটি নজর দিয়ে নিই Aurora স্টোরেজ ইঞ্জিন কীভাবে কাজ করে যাতে আমরা বুঝতে পারি HA কীভাবে এই আলাদা করার ফলাফল হিসেবে আসে।

যখন ডেটা Aurora স্টোরেজ ইঞ্জিনে লেখা হয়, তবে ইঞ্জিনটি নিশ্চিত করে যে ডেটা সামঞ্জস্যপূর্ণ, সঠিক এবং টেকসইভাবে লেখা হয়েছে। ডেটা তিনটি অভেইলেবিলিটি зোনের প্রত্যেকটিতে দুটি লোকেশনে লেখা হয়, মোট ছয়টি ভিন্ন জায়গায়। স্টোরেজ ইঞ্জিন সাবজটিলিটি পরিচালনা করে যাতে সব কিছু সঠিকভাবে ঘটে। একটু ওভারসিম্প্লিফিকেশন হলেও, মূলত ডেটাবেস ইঞ্জিন এখন "ফায়ার-এন্ড-ফরগেট" করতে পারে, আর ডেটা লেখা হয়েছে কিনা, ট্রানজ্যাকশন লগ, রিকভারির সম্ভাবনা ইত্যাদি নিয়ে চিন্তা করতে হয় না।

ডেটাবেস ইঞ্জিন থেকে স্টোরেজ চিন্তা সরিয়ে দিলে, অনেক HA কৌশল উপলব্ধ হয়ে ওঠে।

রিড রেপ্লিকা

রিড রেপ্লিকার ধারণা Aurora-এর আগে থেকেই রয়েছে, কিন্তু ওপেন-সোর্স সমাধানে ইমপ্লিমেন্টেশন লগ শিপিং বা কোয়েরি রিপ্লে জড়িত। Aurora-র সাথে, রিড রেপ্লিকাগুলো মাস্টারের সাথে একই স্টোরেজে রিড-অনলি অ্যাক্সেস পায়। এর মানে হলো ডেটা লেখার সময় থেকে রিড রেপ্লিকাতে দৃশ্যমান হওয়ার সময় পর্যন্ত খুব কম রেপ্লিকেশন ল্যাটেন্সি (এই পরিস্থিতিতে রেপ্লিকেশন ল্যাগ একটি ভুল নামকরণ হবে)। যখন একাধিক রিড রেপ্লিকা প্রয়োজন হয়, তবে সকল রিড রেপ্লিকা একই ডেটা দেখে, যা মাস্টারের ওপর ওভারহেড এবং জটিলতা দূর করে, যা স্ট্যান্ডার্ড MySQL এবং PostgreSQL ইমপ্লিমেন্টেশনে পাওয়া যায়। এই ফিচারগুলো একসাথে একটি রিড রেপ্লিকাকে মাস্টার ব্যর্থ হলে তাৎক্ষণিক টেকওভার করতে সক্ষম করে। উপরন্তু, AWS ব্যর্থ ইনস্ট্যান্সটি প্রতিস্থাপন করে প্রোভিশन्ड ক্যাপাসিটি মিট করতে এবং DNS আপডেট করে নতুন মাস্টারের দিকে পয়েন্ট করে।

এটি হাই রিড-টু-রাইট রেশিও ওয়ালা অ্যাপ্লিকেশনের জন্য একটি চমৎকার সমাধান। যাইহোক, মনে রাখবেন যে আপনার প্রাইমারি ইনস্ট্যান্স পুরো রাইট লোড হ্যান্ডেল করার জন্য যথেষ্ট বড় হতে হবে। এছাড়া, রাইট HA-এর জন্য, আপনাকে কমপক্ষে একটি রিড রেপ্লিকা প্রোভিশন করতে হবে যা আপনার মাস্টারের সাথে একই আকারের। তারপর এই রিড রেপ্লিকাকে প্রাইমারি ইনস্ট্যান্স হিসেবে প্রোমোট করার জন্য প্রায়োরিটি ইনস্ট্যান্স হিসেবে সেট করুন। ব্যর্থতার ক্ষেত্রে, আপনি রিড এবং রাইট উভয় ক্যাপাসিটির জন্য হাই-অভেইলেবিলিটি বজায় রাখবেন।

অটোস্কেলিং

অটোস্কেলিং হলো আপনার উপলব্ধ সার্ভার সেট থেকে হরিজন্টালি স্কেল আউট (ইনস্ট্যান্স যোগ করা) বা স্কেল ইন (ইনস্ট্যান্স সরানো) করার ক্ষমতা। আপনি EC2 ইনস্ট্যান্সের জন্য অটোস্কেলিং শুনে থাকতে পারেন, কিন্তু কি আপনি জানেন Aurora রিড রেপ্লিকাগুলোতে ইলাস্টিসিটি থাকতে পারে? সাধারণত, আপনি বেস লোড হ্যান্ডেল করার জন্য একটি ন্যূনতম সংখ্যক রিড রেপ্লিকা কনফিগার করবেন এবং ডিমান্ড পরিবর্তন 따라 ইনস্ট্যান্স যোগ বা বাদ দেওয়ার জন্য অটোস্কেলিং পলিসি থাকবে। ইলাস্টিসিটি লেভারেজ করার ক্ষমতা ডেটাবেস ইঞ্জিন থেকে স্টোরেজ ইঞ্জিন আলাদা থাকার অন্য একটি ফলাফল।

একটি উদাহরণ পরিস্থিতি যেখানে এটি উপযোগী হবে সেটি হলো একটি B2B ইকমার্স সাইট। এটি সপ্তাহের দিনে বিজনেস আওয়ার време ভারী ট্রাফিক অনুভব করবে কিন্তু রাতে এবং সপ্তাহান্তে খুব কম। ছবি এবং কন্টেন্ট বর্ণনার হাই রিড-টু-রাইট রেশিও থাকে এবং রিড রেপ্লিকা এবং অটোস্কেলিং উভয়ই থেকে সুবিধা পায়। আপনার রিড রেপ্লিকা অটোস্কেলিং করলে পিক আওয়ারে ডিমান্ড মিট করতে এবং অফ আওয়ারে খরচ কমাতে পারবেন।

ক্রস-রিজন রেপ্লিকেশন

যদি আপনি অভেইলেবিলিটি পরবর্তী লেভেলে নিয়ে যেতে চান, তবে অন্য একটি রিজনে রেপ্লিকেট করুন। ডেটাবেস ইঞ্জিন দ্বারা ডেটা অন্য একটি রিজনে রেপ্লিকেট করলে, এটি স্থানীয়ভাবে পড়া যায় বা প্রাইমারি রিজন ব্যর্থ হলে ব্যবহার করা যায়। সেকেন্ডারি রিজনের ইনস্ট্যান্সটি একটি রিড রেপ্লিকা হিসেবে বিবেচিত হয় (এটি মাল্টি-মাস্টার নয়), কিন্তু এর নিজস্ব রিড রেপ্লিকা থাকতে পারে বা প্রাইমারি রিজন ব্যর্থ হলে মাস্টার হতে পারে।

ক্রস-রিজন রেপ্লিকেশনের প্রয়োজন হয় অনেক কারণেই। কখনো কখনো ডেটা অত্যন্ত গুরুত্বপূর্ণ হয় যাতে এটি একটি একক জিওগ্রাফিক রিজনে স্টোর করা যায় না। এটি ব্যবসায়িক নির্বাহিতার, রেগুলেটরি, বা আর্থিক কারণের কারণে হতে পারে। অন্য একটি কারণ হলো ব্যবহারকারীদের এবং ডেটাবেস ব্যাকএন্ডের মধ্যে ল্যাটেন্সি কমানো। আবার ইকমার্স কে উদাহরণ হিসেবে নিলে, ছবি এবং বর্ণনার পরিবর্তনগুলো একটি একক রিজনের মাস্টারে প্রয়োগ করা যায় কিন্তু গ্লোবালি বিতরণ করা যায় যাতে স্থানীয়ভাবে পড়া যায়।

বহিঃস্থ রেপ্লিকেশন

उन পরিস্থিতিয়ের কী যেখানে আপনার ডেটা Aurora ক্লাস্টারের বাইরে প্রয়োজন? এমন পরিস্থিতি রয়েছে যেখানে কর্পোরেট পলিসি বা রেগুলেটরি পরিবেশ দাবি করে, অথবা আপনার ডেটা প্রসেস করতে বা Aurora বাইরে রিপোর্ট চালাতে হয়। এই সব কেস এক্সটার্ন্যাল রেপ্লিকেশন ব্যবহার করে হ্যান্ডেল করা যায়।

Aurora-র ডেটা একটি Amazon EC2 MySQL ইনস্ট্যান্সে, একটি MySQL চালিত Amazon EC2 ইনস্ট্যান্সে, অথবা আপনার কর্পোরেট ডেটা সেন্টারে চলমান একটি MySQL ইনস্ট্যান্সে রেপ্লিকেট করা খুব সহজ। এই একমুখী রেপ্লিকেশন ব্যবহার করে, আপনার ডেটা সবসময় আপনার Aurora ক্লাস্টারের সাথে সিঙ্কড থাকে এবং Aurora বাইরে ব্যবহারের জন্য উপলব্ধ থাকে।

সার্ভারলেস

শেষে, কিন্তু সবচেয়ে কম না, সার্ভারলেস। আভেইলেবিলিটি এবং স্কেলেবিলিটির জন্য সবচেয়ে গুরুত্বপূর্ণ উন্নতিগুলোর একটি হলো সার্ভারলেস যোগ করা। očিতভাবে সার্ভারলেস মানে সার্ভার নেই এমন নয়। এর মানে হলো আপনাকে সার্ভার কোনো প্রোভিশনিং, কনফিগারেশন, স্কেলিং, বা মেইনটেন্যান্স নিয়ে চিন্তা করতে হয় না।

Aurora সার্ভারলেস কনফিগার করতে, আপনি আপনার অ্যাপ্লিকেশনের জন্য উপলব্ধ ক্যাপাসিটি নির্দিষ্ট করেন এবং AWS ডিটেইলগুলো হ্যান্ডেল করে যাতে ক্যাপাসিটি ডিমান্ড অনুযায়ী উপলব্ধ থাকে, যখন আপনার ক্লায়েন্টদের প্রয়োজন। সার্ভারলেসের জন্য, বিদ্যমান দুটি লেয়ারের পাশাপাশি – ডেটাবেস ইঞ্জিন এবং স্টোরেজ ইঞ্জিন – একটি অতিরিক্ত লেয়ার, একটি প্রক্সি লেয়ার যোগ করা হয়েছে।

AWS একটি প্রক্সি সার্ভার ফ্লিট রক্ষা করে যা ইনকামিং রিকোয়েস্ট শোনে। 더불어, একটি ওয়ার্ম পুল DB ক্যাপাসিটি রিকোয়েস্ট সার্ভ করতে অপেক্ষা করে। আপনার প্রথম কোয়েরি আসলে, প্রক্সি ফ্লিট এটি পায়, ওয়ার্ম পুল থেকে একটি ইনস্ট্যান্স অনুরোধ করে, এবং রিকোয়েস্টটি সেটাতে ফরওয়ার্ড করে, আপনার ব্যবহারের জন্য alok করার পরে। আরও ভালো, আপনার ব্যবহারের জন্য alok করা ইনস্ট্যান্সের সংখ্যা ইলাস্টিক এবং আপনার Aurora সার্ভারলেস কনফিগারেশনে নির্দিষ্ট ডিমান্ড এবং লিমিট অনুযায়ী স্কেল ইন এবং আউট করে। পূর্বের কৌশলগুলোর মতো, ডেটাবেস এবং স্টোরেজ আলাদা থাকার কারনে ডাইনামিক্যালি একটি ডেটাবেস ইঞ্জিন আপনাকে alok করা সম্ভব হয়। আপনার কনফিগারেশন অনুযায়ী, ডেটাবেস ইনস্ট্যান্স আপনাকে অ্যাসাইন করা থাকে এবং তাৎক্ষণিক ব্যবহারের জন্য উপলব্ধ থাকে। টাইমআউট পিরিয়ড বড় হলে, ইনস্ট্যান্সটি ওয়ার্ম পুলে ফেরত যাওয়া। আপনি শুধু ব্যবহার করা রিসোর্সের জন্য চার্জ করা হয়। যখন একটি ইনস্ট্যান্স আপনার ব্যবহারের জন্য alok করা হয়, তখন আপনি সেটি প্লাস কোনো কনসামড স্টোরেজের জন্য চার্জ করা হয়। যখন alok করা নয়, তখন আপনি শুধু কনসামড স্টোরেজের জন্য চার্জ করা হয়।

স্পাইকি ওয়ার্কলোডের জন্য, যেমন ডেভেলপমেন্ট এবং টেস্ট এনভায়রনমেন্ট, বা নতুন অ্যাপ্লিকেশন যারা ইউজেজ প্যাটার্ন প্রেডিক্ট করার জন্য পর্যাপ্ত ইতিহাস নেই, সার্ভারলেস পথটি সেরা। আপনি আর যেসব রিসোর্স ব্যবহার করছেন না তার জন্য পে করবেন না, ডেভেলপমেন্ট টিম উইকেন্ডের আগে লাইট বন্ধ করেছে কিনা তা নিশ্চিত করতে হবে না, এবং আপনার ইউজারদের টাইমজোন আপনার স্লিপ জোনের সাথে মিলে থাকায় আপনি রাতের মাঝপথে ক্যাপাসিটি অ্যাডজাস্ট করতে জেগে থাকবেন না।

শেষ কথা

Amazon Aurora অভেইলেবিলিটি, ড্যুরাবিলিটি, এবং স্কেলেবিলিটি ধরে রেখে তৈরি। যদি স্ট্যান্ডার্ড ওপেন-সোর্স ইমপ্লিমেন্টেশন মতো ব্যবহার করা হয়, তবে আপনার কাছে একটি ठोस, विश्वস্ত, এবং পারফরম্যান্ট ডেটাবেস থাকে। Aurora-এর ক্ষমতা এবং সেগুলো লেভারেজ করার প্যাটার্নগুলোর গভীরভাবে দেখলে, আপনি আপনার প্রয়োজন মিট করার জন্য একটি সমাধান ইমপ্লিমেন্ট করতে পারবেন, স্থানীয় রিড অফলোডিং থেকে গ্লোবালি বিতরণ করা অভেইলেবিলিটি পর্যন্ত।

ফিডব্যাক ট্যাব ব্যবহার করে যেকোনো মন্তব্য করুন বা প্রশ্ন জিজ্ঞাসা করুন।