পাঠ্যক্রম খুলুন
প্রাথমিক পর্যায়

Health Check ও Draining: নিরাপদ routing ও shutdown

Health Checks, Sticky Sessions, and Draining

এই পাঠের কুইজ ↓৬ মিনিট পড়াPHP 8.3+ · Laravel 12
এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

  • Liveness ও readiness আলাদা করা
  • Sticky session-এর সীমা
  • Deployment-এ traffic draining

সমস্যা দিয়ে শুরু

Deployment-এ process বন্ধ করার সঙ্গে সঙ্গে চলমান checkout connection কেটে যায়। অন্যদিকে অসুস্থ server process চালু থাকায় balancer সেটিকে healthy মনে করছে। Health check এবং graceful shutdown দুটি ভিন্ন কাজ: নতুন request কে পাবে, আর পুরোনো request কীভাবে শেষ হবে।

সহজ করে বুঝি

Liveness বলে process restart করা দরকার কি না। Readiness বলে instance এখন traffic নিতে প্রস্তুত কি না। Database সাময়িক unavailable হলে liveness fail করে সব app restart করানো cascade বাড়াতে পারে। Readiness-এ mandatory dependency-এর cheap bounded check রাখা যায়; optional analytics outage-এ পুরো storefront unready করা দরকার নাও হতে পারে। Draining-এ আগে নতুন traffic বন্ধ, তারপর in-flight কাজ শেষের bounded সময়, শেষে process shutdown। Sticky session user-কে backend-এ আটকে রাখে, তবে সেই backend-এর failure সামলায় না।

পরিচিত একটি উপমা

দোকান বন্ধের আগে দরজায় নতুন customer ঢোকা বন্ধ হয়, ভেতরের customer-এর বিল শেষ হয়। দরজা খোলা আছে কি না আর cashier কাজ করতে প্রস্তুত কি না আলাদা প্রশ্ন। একজন নির্দিষ্ট cashier-এর কাছে সবসময় গেলে সুবিধা, কিন্তু তিনি চলে গেলে customer-এর cart হারানো উচিত নয়।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Readiness change balancer পর্যন্ত পৌঁছাতে কিছু delay থাকে।
Diagram-এর text flow দেখুন
flowchart TD
 D[Deployment starts] --> R[Mark instance not ready]
 R --> B[Balancer stops new traffic]
 B --> F[Finish active requests]
 F --> T[Bounded grace period]
 T --> S[Stop process]

Readiness change balancer পর্যন্ত পৌঁছাতে কিছু delay থাকে। সেই সময় termination grace-এ ধরতে হবে। Existing request finish করার পরে process stop হয়। Long-running export বা WebSocket grace period ছাড়িয়ে যেতে পারে; client reconnect ও background job recovery দরকার। Diagram restart loop দেখায় না, কারণ সেটি liveness policy-এর আলাদা বিষয়।

PHP ও Laravel-এ প্রয়োগ

নিচের routes/web.php fragment simple liveness ও database readiness দেখায়। Production readiness access internal network-এ সীমিত রাখুন। DB connection/read timeout bounded configure করুন; এই route নিজে query deadline enforce করে না। Response-এ exception বা credentials ফেরত দেওয়া হয়নি।

php
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Route;

Route::get('/live', fn () => response()->json(['alive' => true]));
Route::get('/ready', function () {
    try {
        DB::select('select 1');
        return response()->json(['ready' => true]);
    } catch (\Throwable $exception) {
        report($exception);
        return response()->json(['ready' => false], 503);
    }
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Strict readiness broken node সরায়, কিন্তু shared database outage-এ সব replica একসঙ্গে unready হতে পারে। Detection interval ছোট হলে response দ্রুত, probe traffic ও flapping বাড়তে পারে। Consecutive success/failure threshold noise কমায়, recovery দেরি করে। Grace period দীর্ঘ হলে deployment ধীর; ছোট হলে request abort বেশি। Business endpoint-এর latency distribution দেখে budget ঠিক করুন।

সাধারণ ভুল

  • Database outage-এ liveness fail করে সব container restart করা।
  • SIGKILL দিয়ে rolling deploy চালানো।
  • Sticky session থাকলে shared session store লাগবে না বলা।

আরও একটু গভীরে

Connection draining শুধু balancer setting নয়। Orchestrator termination signal, proxy upstream keep-alive, app worker lifecycle এবং queue worker shutdown একসঙ্গে কাজ করতে হয়। Laravel queue:restart long-lived workers-কে বর্তমান job শেষে বের হতে signal দেয়; supervisor আবার চালায়। Cached config ও app code deploy mismatch এড়াতে release ordering পরীক্ষা করুন। Probe failure-এর কারণ logs-এ রাখলেও প্রতি probe-তে verbose stack trace log flood হতে পারে।

মনে রাখুন

Liveness restart-এর প্রশ্ন, readiness routing-এর প্রশ্ন। নতুন traffic বন্ধ করে চলমান কাজ শেষের সুযোগ দিন। Affinity performance সুবিধা হতে পারে; state durability-এর guarantee নয়।

নিজে চেষ্টা করুন

Staging-এ একটি slow request চালিয়ে instance unready করুন। নতুন request অন্য instance পায় এবং চলমান request finish করে কি না দেখুন। Probe interval ও termination budget লিখুন; শুধু happy-path deployment পরীক্ষা যথেষ্ট নয়।

নিজের বোঝা যাচাই করুন

1. DB fail হলে restart করব?

সবসময় নয়। Shared dependency outage restart দিয়ে সারবে না; বরং reconnect storm হতে পারে। Liveness ও readiness আলাদা policy রাখুন।

2. Draining মানে কী?

নতুন assignment বন্ধ করে in-flight কাজ শেষ করার bounded সুযোগ। Grace period পেরোলে explicit termination policy দরকার।

3. Readiness দ্রুত fail করলেই ভালো?

False negative বা transient network issue-এ capacity অযথা কমতে পারে। Threshold ও detection delay requirement অনুযায়ী নির্ধারণ করুন।

4. Sticky session durable?

না। Backend হারালে local session হারায়। Shared store বা পুনরুদ্ধারযোগ্য state model দরকার।

5. Long-running job কী করবে?

Queue worker shutdown contract অনুযায়ী current job finish বা retry হতে পারে। Handler idempotent এবং timeout budget যথাযথ হতে হবে।

আরও পড়ুন

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।