Timeout, retry ও backoff: retry storm কীভাবে এড়াবেন
Retry ছোট ব্যর্থতা সারায়, আবার বড় ব্যর্থতাও বানায়। Timeout, jitter-সহ exponential backoff, retry budget এবং retry কেন idempotent হতে হবে, জানুন।
প্রতিটি network call ধীর হতে বা ব্যর্থ হতে পারে। আপনি সেটি কীভাবে সামলান, তা ঠিক করে ছোট সমস্যা ছোট থাকবে কি না।
সবসময় timeout দিন
Timeout ছাড়া call চিরকাল ঝুলে থাকতে পারে এবং thread, connection ও memory আটকে রাখে। প্রতিটি বাইরের call-এ timeout দিন: connect, read ও মোট। আসল latency সংখ্যা দেখে বাছুন: p99-এর সামান্য ওপরে, "নিরাপদ থাকতে" ৬০ সেকেন্ড নয়।
শুধু নিরাপদ হলে retry করুন
Failure অস্থায়ী হলে retry কাজে লাগে: timeout, ছিঁড়ে যাওয়া connection, 503। ৪০০ বা ৪০৪-এ লাভ নেই। আর শুধু idempotent কাজ retry করা যায় (idempotency পর্ব দেখুন), নইলে retry গ্রাহককে দুবার চার্জ করতে পারে।
Jitter-সহ exponential backoff
কোনো service কষ্টে থাকলে সব client একসাথে retry করলে retry-ই আক্রমণ হয়ে যায়। প্রতি ব্যর্থতার পর বেশি অপেক্ষা করুন, সাথে randomness যোগ করুন:
wait = random(0, min(cap, base * 2^attempt))
- Exponential: ১০০ ms, ২০০ ms, ৪০০ ms, ৮০০ ms এভাবে একটি সীমা পর্যন্ত।
- Jitter: random অংশ, যাতে হাজারো client একই মুহূর্তে retry না করে ("thundering herd")।
- সর্বোচ্চ চেষ্টার সংখ্যা (প্রায়ই ২ থেকে ৪)।
গুণ হওয়ার সমস্যা
ধরুন service A, B-কে ডাকে, B ডাকে C-কে, আর প্রতি স্তর ৩ বার retry করে। ব্যর্থ C প্রতিটি user request-এর জন্য ৩ x ৩ = ৯টি call পেতে পারে, আর প্রতি স্তরে load বাড়ে। এটিই retry storm, যা ধীর dependency-কে পূর্ণ outage বানাতে পারে।
প্রতিরোধ:
- শুধু একটি স্তরে retry করুন, সাধারণত user-এর সবচেয়ে কাছেরটিতে।
- Retry budget: স্বাভাবিক traffic-এর একটি শতাংশ (যেমন ১০%) পর্যন্তই retry অনুমোদন করুন।
- Call শৃঙ্খলে একটি deadline পাঠান, যাতে নিচের স্তর এমন request-এ কাজ বন্ধ করে, যা caller আগেই ছেড়ে দিয়েছে।
আরও কাজের ধারণা
- দ্রুত ব্যর্থ হোন: dependency স্পষ্টই বন্ধ হলে ডাকা থামান (circuit breaker পর্ব দেখুন)।
- Hedged request: বিরল ধীর call-এ অল্প অপেক্ষার পর দ্বিতীয় request পাঠিয়ে প্রথম উত্তর নিন। শুধু নিরাপদ read-এ।
- প্রতিটি retry log করুন, যাতে monitoring-এ দেখা যায়।
মূল কথা: সবকিছুতে timeout দিন, শুধু অস্থায়ী ও idempotent ব্যর্থতায় retry করুন, jitter-সহ backoff দিন, এবং স্তর জুড়ে মোট retry সীমিত রাখুন।
System Design সিরিজ, পর্ব ৫ (failure ও security): 1 নম্বর (মোট 6)।
