High availability মানে পরিকল্পিতভাবে এমন সিস্টেম বানানো, যা উপাদানগুলোর ব্যর্থতা সত্ত্বেও সম্মত সময়সীমার মধ্যে সেবা দিয়ে যায় — সাধারণত ৯৯.৯% বা তার বেশি। এর মূল কথা redundancy ও swift failure detection, কিন্তু সেই সাথে চাপের মুখে নিয়ন্ত্রিতভাবে অবনমিত হওয়ার (graceful degradation) ক্ষমতাও।
আগের অধ্যায়ের Deployment Stamps, Geodes ও Health Endpoint Monitoring এখানেও সমানভাবে প্রযোজ্য (Availability)। এই অধ্যায়ে তার সাথে যুক্ত হচ্ছে দুটো গুরুত্বপূর্ণ প্রতিরক্ষা — Circuit Breaker ও Throttling।
Deployment Stamps
স্বাধীন ও সম্পূর্ণ stack-এর একাধিক কপি চালানো, যাতে একটার ব্যর্থতা বাকিদের স্পর্শ না করে এবং blast radius ছোট থাকে। HA-র দৃষ্টিকোণে এর সবচেয়ে বড় অবদান — একটা সমস্যা কখনোই ১০০% গ্রাহককে প্রভাবিত করতে পারে না। বিস্তারিত: Availability।
Geodes
একাধিক অঞ্চলে সমপর্যায়ের deployment, যেখানে যেকোনো node যেকোনো request সামলাতে পারে। এটাই সর্বোচ্চ স্তরের HA — একটা সম্পূর্ণ region হারিয়ে গেলেও সেবা চলে। তবে ডেটার global consistency-র মূল্য দিতে হয়। বিস্তারিত: Availability।
Health Endpoint Monitoring
দ্রুত ব্যর্থতা শনাক্ত করার ভিত্তি। HA-তে শনাক্তকরণের গতি সরাসরি downtime-এ রূপান্তরিত হয় — যদি একটা মৃত instance শনাক্ত করতে ৫ মিনিট লাগে, তাহলে ওই ৫ মিনিট user-রা ব্যর্থতা দেখবে। তাই health check-এর ব্যবধান ও ব্যর্থতার সীমা (threshold) সাবধানে ঠিক করুন: খুব সংবেদনশীল হলে সুস্থ instance-ও বাদ পড়বে (flapping), খুব শিথিল হলে ব্যর্থতা ধরতে দেরি হবে।
Circuit Breaker
বৈদ্যুতিক ফিউজের মতো — কোনো downstream service বারবার ব্যর্থ হলে circuit breaker সেই দিকের call গুলো সাময়িকভাবে সম্পূর্ণ বন্ধ করে দেয় এবং সাথে সাথে ব্যর্থতা ফেরত দেয়, প্রতিবার timeout-এর জন্য অপেক্ষা না করে।
তিনটা অবস্থা:
- Closed (স্বাভাবিক) — সব call যাচ্ছে, ব্যর্থতা গোনা হচ্ছে। ব্যর্থতার হার সীমা ছাড়ালে → Open।
- Open — কোনো call যাচ্ছে না, সাথে সাথে ব্যর্থতা বা fallback ফেরত। নির্দিষ্ট সময় পর → Half-Open।
- Half-Open — অল্প কিছু পরীক্ষামূলক call পাঠানো হয়। সফল হলে → Closed; ব্যর্থ হলে আবার → Open।
কেন এটা এত গুরুত্বপূর্ণ: এটা cascading failure ঠেকায়। একটা ধীর downstream service যদি আপনার সব thread আটকে রাখে, তাহলে আপনার service-ও মরে যাবে, তারপর আপনার caller-ও — এভাবে একটা ছোট সমস্যা পুরো সিস্টেম ধসিয়ে দেয়। Circuit breaker এই শৃঙ্খল ভেঙে দেয়, এবং একই সাথে কষ্টে থাকা service-কে সেরে ওঠার অবকাশ দেয় (Retry Storm দেখুন)।
সাথে যা থাকা উচিত: একটা অর্থবহ fallback — cache থেকে পুরনো ডেটা, একটা ডিফল্ট মান, বা feature-টা সাময়িকভাবে লুকিয়ে ফেলা। Circuit breaker-এর প্রকৃত সুফল তখনই আসে যখন খোলা অবস্থায় user সম্পূর্ণ ব্যর্থতা না দেখে আংশিক সেবা পায়।
সতর্কতা: প্রতিটা downstream-এর জন্য আলাদা breaker রাখুন (একটা সাধারণ breaker সব কিছু বন্ধ করে দেবে), এবং breaker-এর অবস্থা পরিবর্তন সবসময় নিরীক্ষণ ও alert-এ রাখুন — এটা একটা চমৎকার আগাম সতর্কতা সংকেত।
Throttling
নির্দিষ্ট সময়ে একটা client, tenant বা পুরো সিস্টেম কতটা resource ব্যবহার করতে পারবে তার সীমা বেঁধে দেওয়া। সীমা ছাড়ালে request প্রত্যাখ্যান করা হয় (429 Too Many Requests + Retry-After) বা ধীর করে দেওয়া হয়।
কেন: এটা আপনার সিস্টেমের আত্মরক্ষার শেষ রেখা। এটা ছাড়া একজন আক্রমণকারী, একটা buggy client, বা কেবল একজন অতি-উৎসাহী গ্রাহকই পুরো সেবাকে অচল করে দিতে পারে (Noisy Neighbor)। Autoscaling সহায়ক, কিন্তু তা তাৎক্ষণিক নয় এবং তারও একটা সীমা আছে — তাই throttling অপরিহার্য।
প্রচলিত অ্যালগরিদম:
- Token Bucket — নির্দিষ্ট হারে token জমা হয়, প্রতিটা request একটা token খরচ করে। জমানো token-এর কারণে সাময়িক burst অনুমোদন করে — সবচেয়ে ব্যবহারিক ও প্রচলিত।
- Leaky Bucket — নির্গমনের হার সম্পূর্ণ স্থির, তাই আউটপুট মসৃণ; burst শোষিত হয় না।
- Fixed Window — সরল ("প্রতি মিনিটে ১০০"), কিন্তু window-র সীমানায় দ্বিগুণ ট্রাফিক ঢুকে যেতে পারে।
- Sliding Window — fixed window-র সীমানা সমস্যা দূর করে, তবে হিসাব কিছুটা ব্যয়বহুল।
ভালো বাস্তবায়নের নিয়ম:
- সীমা কী ভিত্তিতে — API key, user, IP, নাকি tenant? সাধারণত একাধিক স্তরে একসাথে।
- স্বচ্ছ থাকুন —
X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-Resetheader পাঠান, যাতে ভালো client নিজেকে সংযত করতে পারে। - গুরুত্বপূর্ণ ও কম গুরুত্বপূর্ণ endpoint-এ ভিন্ন সীমা দিন।
- চরম চাপে load shedding বিবেচনা করুন — কম গুরুত্বপূর্ণ কাজ (recommendation, analytics) ফেলে দিয়ে মূল কাজটা (checkout) বাঁচান। ভদ্রভাবে অবনমিত হওয়া সম্পূর্ণ ব্যর্থতার চেয়ে সবসময়ই ভালো।
পূর্ববর্তী: Availability · পরবর্তী: Resiliency