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

প্রাথমিক পর্যায়

Autoscaling: load অনুযায়ী capacity ও resource limit

Autoscaling and Resource Limits

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

আগে পড়ে নিনVertical ও Horizontal Scaling: সার্ভার বড় করব, না বাড়াব ↗

এই পাঠের সূচিপত্র

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

Horizontal autoscaling signal ও delay
Resource requests, limits ও headroom
Laravel worker workload-এর saturation মাপা

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

বিক্রির campaign শুরু হলে traffic হঠাৎ দশগুণ। CPU threshold পার হওয়ার পরে নতুন instance চালু হতে সময় লাগে, ততক্ষণ queue জমে যায়। Autoscaling reactive capacity management; আগে থেকে buffer না রাখলে spike-এর প্রথম মিনিটে user timeout হতে পারে। Resource limit না বুঝলে replica বাড়িয়েও database overload হয়।

সহজ করে বুঝি

Autoscaler metric দেখে desired replica count নির্ধারণ করে। CPU useful signal, কিন্তু database wait-এ আটকে থাকা PHP request-এর CPU কম হলেও user latency বেশি হতে পারে। Queue worker-এর জন্য queue age, backlog ও processing rate গুরুত্বপূর্ণ। Resource request scheduler-এর placement input; limit runtime enforcement boundary। Kubernetes CPU limit throttling ও memory limit breach termination আলাদা behavior। Scaling decision-এ min/max replicas, cooldown এবং downscale stability রাখতে হয়।

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

দোকানে line বড় হলে extra cashier ডাকেন। নতুন cashier পোশাক পরে counter প্রস্তুত করতে সময় নেন। সব cashier-এর সামনে একটিমাত্র payment machine থাকলে মানুষ বাড়িয়ে লাভ কম। দুপুরের rush জানা থাকলে আগে staff রাখা reactive call-এর চেয়ে ভালো হতে পারে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Metric থেকে decision, তারপর boot, warm-up ও readiness শেষে capacity কাজে আসে।

Diagram-এর text flow দেখুন

flowchart TD
 R[Requests or queued jobs] --> A[Laravel replicas]
 A --> M[Latency CPU queue age metrics]
 M --> S[Autoscaler decision]
 S --> W[Boot and warm new replica]
 W --> H[Readiness passes]
 H --> A
 A --> D[(Shared database capacity)]

Metric থেকে decision, তারপর boot, warm-up ও readiness শেষে capacity কাজে আসে। Delay-এর প্রতিটি ধাপে backlog বাড়তে পারে। Database arrow reminder: downstream capacity shared। Scale-in-এ active request/job drain করতে হবে; শুধু replica সংখ্যা কমালেই correctness বজায় থাকে না। Minimum warm replicas critical response time-এর সঙ্গে মিলিয়ে রাখুন।

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

নিচের Laravel logging fragment queue job handler-এর ভিতরের instrumentation pattern। $jobStartedAt ও $queuedAt immutable timestamps হিসেবে application payload/metadata থেকে এসেছে ধরে নেওয়া হয়েছে। Client-supplied timestamp trust করবেন না। Central metric pipeline-এ histogram/queue age পাঠানো production implementation-এর আলাদা কাজ।

use Illuminate\Support\Facades\Log;

$waitingSeconds = max(0, $jobStartedAt->getTimestamp() - $queuedAt->getTimestamp());
$started = hrtime(true);

try {
    $processor->handle($orderId);
} finally {
    Log::info('order_job.finished', [
        'queue_wait_seconds' => $waitingSeconds,
        'run_ms' => (hrtime(true) - $started) / 1_000_000,
    ]);
}

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

Autoscaling idle cost কমাতে ও sustained growth সামলাতে সাহায্য করে। কিন্তু instance startup, quota, image pull, cache warm-up ও connection storm বাস্তব delay। Overly sensitive metric scale oscillation তৈরি করে। Conservative downscale cost বাড়ায়, কিন্তু thrashing কমায়। Predictable campaign-এ scheduled scaling এবং bounded queue প্রায়ই reactive scaling-এর পাশে দরকার হয়।

সাধারণ ভুল

Database saturated হলেও শুধু web replica বাড়ানো।
Memory leak-কে autoscaling দিয়ে স্থায়ীভাবে ঢেকে রাখা।
Maximum replicas ছাড়া downstream connection বাড়তে দেওয়া।

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

Queue age service objective-এর সঙ্গে backlog count-এর চেয়ে সরাসরি মেলাতে পারে। দশটি পাঁচ মিনিটের job আর দশটি এক millisecond-এর job সমান backlog নয়। Scale-out efficiency load test করুন: throughput linear নাকি shared lock-এ plateau হচ্ছে। Resource requests কম দিলে scheduler oversubscribe করতে পারে; limits খুব ছোট হলে throttling/OOM বাড়তে পারে। Liveness failure আর resource saturation আলাদা dashboard-এ দেখা উপকারী।

মনে রাখুন

Autoscaling metric, delay ও downstream budget নিয়ে কাজ করে। Resource limit এবং replica max একসঙ্গে ঠিক করুন। Warm capacity ও graceful scale-in beginner design-এই উল্লেখ করুন।

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

একটি queue-এর average job time এবং arrival rate ধরে baseline worker demand হিসাব করুন। দুই মিনিট startup delay-এ backlog কত বাড়ে দেখান। Staging-এ database connection limit, scale max ও delayed readiness দিয়ে failure behavior পরীক্ষা করুন।

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

1. CPU কম মানেই capacity আছে?

না। Worker I/O, lock বা pool wait-এ আটকে থাকতে পারে। Latency, active work ও downstream saturation দেখতে হবে।

2. Backlog count যথেষ্ট?

না। Job cost ও queue age দরকার। সমান count ভিন্ন waiting time ও completion objective তৈরি করতে পারে।

3. Request ও limit একই?

না। Kubernetes request scheduling-এর resource expectation, limit runtime boundary। CPU ও memory enforcement-ও একরকম নয়।

4. Scale-out instant?

না। Detection, provisioning, boot ও readiness delay আছে। Spike-এর শুরুতে buffer বা load shedding প্রয়োজন হতে পারে।

5. Scale-in-এ কী দেখব?

In-flight request/job, draining ও recovery। Terminated job পুনরায় চলতে পারে, তাই idempotency অপরিহার্য।

এই পাঠের কুইজ

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

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

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

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

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