মোবাইল ডেভেলপমেন্টে স্ট্রেস টেস্ট: এটি কী, উদ্দেশ্য এবং কীভাবে পরিচালিত হয়

Stress Test কী?

Stress Test (স্ট্রেস-টেস্টিং) — এটি একটি প্রক্রিয়া যা নির্ধারিত সীমার চেয়ে বেশি পরিস্থিতিতে সিস্টেমের কাজ করার ক্ষমতা মূল্যায়ন করে। মোবাইল অ্যাপ্লিকেশনের জন্য এটি ১০০০০টি একযোগে push-বিজ্ঞপ্তি হতে পারে যেখানে স্বাভাবিক সংখ্যা ১০০০, ব্যাকএন্ডের জন্য — ৫০০০০ RPS যেখানে প্রত্যাশিত ৫০০০। Load Test থেকে Stress Test-এর প্রধান পার্থক্য — লক্ষ্য পারফরম্যান্স নিশ্চিত করা নয়, বরং সিস্টেমের আচরণ তার ডিজাইন ক্ষমতার বাইরে অধ্যয়ন করা। Netflix Engineering (2024) Stress Test-কে সংজ্ঞায়িত করে “সিস্টেম ভবিষ্যদ্বাণীযোগ্যভাবে ভেঙে পড়বে এই হাইপোথিসিস পরীক্ষা করা” হিসাবে।

স্ট্রেস-টেস্টিং দুটি বাধ্যতামূলক ধাপ অন্তর্ভুক্ত করে: ব্যর্থতা পর্যন্ত লোড এবং পুনরুদ্ধার পর্যবেক্ষণ। পুনরুদ্ধার (recovery) — ওভারলোড সরানোর পরে সিস্টেমের স্বাভাবিক কাজে ফিরে আসার ক্ষমতা। যে সিস্টেম রিস্টার্ট ছাড়া পুনরুদ্ধার করতে পারে না, তাকে ভঙ্গুর বলে গণ্য করা হয়, এমনকি যদি এটি স্বল্পমেয়াদী ওভারলোড সহ্য করে। AWS Well-Architected Framework (2024) অনুযায়ী, Stress Test-এর পরে পুনরুদ্ধারের সময় ৫ মিনিটের বেশি হওয়া উচিত নয়।

মোবাইল ক্লায়েন্টদের জন্য Stress Test অন্তর্ভুক্ত করে: প্রক্রিয়া জোর করে বন্ধ করা, নেটওয়ার্ক বিচ্ছিন্ন করা এবং RAM শেষ হওয়ার পরিস্থিতি পরীক্ষা করা। Android Low Memory Killer RAM-এর অভাবে ব্যাকগ্রাউন্ড প্রক্রিয়া বন্ধ করতে পারে — স্ট্রেস-টেস্ট নিশ্চিত করতে হবে যে অ্যাপ্লিকেশন এই ধরনের বন্ধের পরে সঠিকভাবে অবস্থা পুনরুদ্ধার করে। Apple UIKit (2024) অ্যাপ্লিকেশনের প্রতিটি স্ক্রিনে memory warning পরিস্থিতি পরীক্ষা করার পরামর্শ দেয়।

স্ট্রেস-টেস্টিংয়ের উদ্দেশ্য

ব্যর্থতার পয়েন্ট নির্ধারণ

Stress Test-এর প্রথম উদ্দেশ্য — ব্যর্থতার পয়েন্ট নির্ধারণ (breaking point)। এটি সেই মুহূর্ত যখন মূল পারফরম্যান্স সূচকগুলির একটি ক্রিটিকাল সীমা অতিক্রম করে: p95 রেসপন্স টাইম ১০ সেকেন্ডের বেশি, HTTP 5XX ত্রুটির শতাংশ ৫% এর বেশি, বা থ্রুপুট baseline-এর ৫০% এর নিচে নেমে যায়। ব্যর্থতার পয়েন্ট নির্ধারণ টিমকে সিস্টেমের স্কেলিং সীমা আগে থেকেই জানতে দেয়। Capacity planning নির্ভর করে Stress Test-এর ডেটার উপর, Load Test-এর নয়, কারণ Load Test সীমান্তবর্তী অবস্থা পরীক্ষা করে না।

পুনরুদ্ধার ব্যবস্থা পরীক্ষা

দ্বিতীয় উদ্দেশ্য — পুনরুদ্ধার ব্যবস্থা পরীক্ষা। লোড স্বাভাবিক মাত্রায় কমার পর সিস্টেমকে স্বাভাবিক সূচকে ফিরে আসতে হবে। যদি ডাটাবেসে কানেকশন পুল মুক্ত না হয় বা ক্যাশে ইনভ্যালিডেট না হয়, Stress Test এই সমস্যা চিহ্নিত করবে। Circuit breaker (Hystrix, Resilience4j) ওভারলোডে সক্রিয় হওয়া উচিত এবং স্থিতিশীলতার পরে স্বয়ংক্রিয়ভাবে সংযোগ পুনরুদ্ধার করা উচিত। Health check এন্ডপয়েন্টগুলি পরীক্ষার সময় প্রতিটি সার্ভিসের অবস্থা পর্যবেক্ষণে সাহায্য করে।

Auto-scaling বৈধকরণ

তৃতীয় উদ্দেশ্য — auto-scaling বৈধকরণ। যদি ইনফ্রাস্ট্রাকচার Kubernetes বা AWS Auto Scaling ব্যবহার করে, Stress Test পরীক্ষা করে যে নতুন pod বা ইন্সট্যান্স যথেষ্ট দ্রুত তৈরি হচ্ছে কিনা। Google Kubernetes Engine (2024) অনুযায়ী, HPA (Horizontal Pod Autoscaler) মেট্রিক সক্রিয় হওয়ার ৩০ সেকেন্ডের মধ্যে নতুন pod-এর ডিপ্লয়মেন্ট সময় অতিক্রম করা উচিত নয়। HPA CPU, মেমরি এবং কাস্টম মেট্রিকের ভিত্তিতে স্কেল করা উচিত। Cluster Autoscaler নতুন নোড যোগ করে যদি বর্তমান নোডগুলি pod ধারণ করতে না পারে।

Stress Test পদ্ধতি

ধীরে ধীরে লোড বৃদ্ধি (Ramp-up Stress Test) — সবচেয়ে সাধারণ পরিস্থিতি। প্রাথমিক লোড প্রত্যাশিত লোডের ৫০% এ সেট করা হয়, তারপর প্রতি ২ মিনিটে ১০% বৃদ্ধি করা হয় যতক্ষণ না সিস্টেম ব্যর্থ হয়। এই পরিস্থিতি স্থিতিস্থাপকতার সঠিক সীমা খুঁজে পেতে দেয়। Grafana Cloud k6 (2025) রেসপন্স টাইমের মসৃণ গ্রাফ পাওয়ার জন্য ১০% এর বেশি না বাড়ানোর পরামর্শ দেয়।

হঠাৎ লোড বৃদ্ধি (Spike Stress Test) — লোড ১০% থেকে ৫০০% এ ১০–৩০ সেকেন্ডের মধ্যে বেড়ে যায়। এই পরিস্থিতি ভাইরাল কন্টেন্ট বিস্তার বা DDoS আক্রমণের মতো পরিস্থিতি মডেল করে। Spike Stress Test পারফরম্যান্সের চেয়ে সিস্টেমের টিকে থাকার ক্ষমতা পরীক্ষা করে: পুরোপুরি না ভেঙে পড়ার এবং স্থিতিশীলতার পরে কাজে ফিরে আসার ক্ষমতা। API Gateway কে হঠাৎ বৃদ্ধি থেকে ব্যাকএন্ড রক্ষার জন্য rate limiting কনফিগার করা উচিত।

দীর্ঘমেয়াদী ওভারলোড ধরে রাখা (Sustained Stress Test) — সিস্টেম ৩০–৬০ মিনিট ধরে ওভারলোড অবস্থায় রাখা হয়। এই পরিস্থিতি রিসোর্স লিক সনাক্ত করে যা স্বল্পমেয়াদী পরীক্ষায় দেখা যায় না। মেমরি লিক Java/Kotlin অ্যাপ্লিকেশনে ২০–৪০ মিনিট তীব্র কাজের মধ্যে জমা হয় এবং শুধুমাত্র Sustained Stress Test এটি সনাক্ত করে।

ব্যর্থতার পয়েন্ট এবং পুনরুদ্ধারের বিশ্লেষণ

ব্যর্থতার পয়েন্ট তিনটি মানদণ্ড অনুযায়ী নির্ধারিত হয়: রেসপন্স টাইম, ত্রুটির শতাংশ এবং থ্রুপুট। সাধারণত প্রথমে রেসপন্স টাইমের সীমা অতিক্রম করে — অনুরোধগুলি নির্ধারিত সীমার চেয়ে বেশি সময় নেয়। তারপর ত্রুটির শতাংশ বাড়ে: সার্ভার অনুরোধ প্রক্রিয়া করতে পারে না এবং 503 ফেরত দেয়। শেষে Throughput কমে যায় — সিস্টেম এমনকি ন্যূনতম লোডও সামলাতে পারে না। ব্যর্থতার পয়েন্টের মেট্রিক ক্ষমতা পরিকল্পনার জন্য লোড প্রোফাইলে রেকর্ড করা হয়।

পুনরুদ্ধারের বিশ্লেষণ তিনটি পর্যায় অন্তর্ভুক্ত করে: তাৎক্ষণিক প্রতিক্রিয়া (লোড সরানোর প্রথম ৩০ সেকেন্ড), স্থিতিশীলতা (১–৫ মিনিট) এবং সম্পূর্ণ পুনরুদ্ধার (৫–৩০ মিনিট)। তাৎক্ষণিক প্রতিক্রিয়া পর্যায়ে রেসপন্স টাইম baseline-এর নিচে নেমে যাওয়া উচিত — সিস্টেম কিউ থেকে মুক্ত হয়। যদি এটি না হয়, তাহলে সমস্যা লোডে নয়, জমা হওয়া অবস্থায়। Graceful degradation — ওভারলোডে সিস্টেমের আংশিক কার্যকারিতা বজায় রাখার ক্ষমতা — আর্কিটেকচারের পরিপক্কতার মূল সূচক।

Chaos Engineering Stress Test-কে পরিপূরক করে ইচ্ছাকৃত ত্রুটি সৃষ্টির মাধ্যমে: ডাটাবেস সার্ভার বন্ধ করা, নেটওয়ার্কে বিলম্ব, মাইক্রোসার্ভিস বন্ধ করা। Chaos Monkey Netflix (2024) থেকে এলোমেলোভাবে production-এ প্রক্রিয়া বন্ধ করে সিস্টেমের স্থিতিস্থাপকতা পরীক্ষা করে। মোবাইল অ্যাপ্লিকেশনের জন্য Chaos Engineering মানে পরিস্থিতি পরীক্ষা: নেটওয়ার্কের অনুপস্থিতি, API-এর অনুপলব্ধতা, সার্ভারের খালি উত্তর।

Stress Test-এর জন্য টুলস

ramping-arrival-rate সহ k6

k6 Stress Test সমর্থন করে `execution` মডিউলের মাধ্যমে ramping-arrival-rate কনফিগারেশন সহ। এই মোড প্রতি সেকেন্ডে অনুরোধের সংখ্যা বাড়ায় প্রতিটি অনুরোধের নির্বাহ সময় নির্বিশেষে। Load Test-এর তুলনায়, k6-এ Stress Test-এর জন্য আরও আক্রমণাত্মক thresholds কনফিগারেশন এবং হঠাৎ ব্যর্থতা অনুকরণের জন্য gracefull-stop বন্ধ করা প্রয়োজন। Grafana Cloud স্বয়ংক্রিয়ভাবে রেসপন্স টাইম গ্রাফের ভাঙন বিন্দুতে ব্যর্থতার পয়েন্ট সনাক্ত করে। k6-operator Kubernetes-এর জন্য ক্লাস্টার থেকে ডিস্ট্রিবিউটেড Stress Test চালানোর অনুমতি দেয়।

Ultimate Thread Group সহ JMeter

JMeter Ultimate Thread Group-এর মাধ্যমে Stress Test কনফিগার করার অনুমতি দেয় — একটি প্লাগইন যা টেবিল আকারে লোড প্রোফাইল নির্ধারণ করে: থ্রেডের সংখ্যা, ওয়ার্ম-আপ সময়, ধারণ সময়, কুল-ডাউন সময়। Ultimate Thread Group জটিল মাল্টি-ফেজ পরিস্থিতির জন্য সুবিধাজনক। JMeter Backend Listener InfluxDB-তে মেট্রিক পাঠায় ব্যর্থতার পয়েন্টের গ্রাফ নির্মাণের জন্য। Stress Test-এর জন্য JMeter-এ সংযোগ টাইমআউট বন্ধ করার পরামর্শ দেওয়া হয় যাতে ওভারলোডে আচরণ আরও সঠিকভাবে পরিমাপ করা যায়।

Chaos Engineering-এর জন্য Gremlin

Gremlin — Stress Test ইনফ্রাস্ট্রাকচারের জন্য Chaos Engineering প্ল্যাটফর্ম। Gremlin নেটওয়ার্ক বন্ধ করা, CPU লোড করা, ডিস্ক পূর্ণ করা এবং Kubernetes-এর পৃথক pod-এ প্রক্রিয়া বন্ধ করার অনুমতি দেয়। SRE-টিমগুলি Gremlin k6-এর সাথে একসাথে ব্যবহার করে জটিল Stress Test-এর জন্য: k6 লোড তৈরি করে, Gremlin ত্রুটি সৃষ্টি করে। Game Day — Gremlin ব্যবহার করে নিয়মিত Stress Test সেশন যা সিস্টেমের স্থিতিস্থাপকতা বিশ্লেষণের জন্য “chaos report”-এ ডকুমেন্ট করা হয়।

k6-এ Stress Test উদাহরণ

নিচের k6 স্ক্রিপ্টটি ব্যর্থতা পর্যন্ত ধীরে ধীরে লোড বৃদ্ধি সহ Stress Test প্রদর্শন করে। Ramping-arrival-rate প্রতিটি অনুরোধের নির্বাহ সময় নির্বিশেষে প্রতি সেকেন্ডে অনুরোধের সংখ্যা বাড়ায়। Thresholds আক্রমণাত্মক ডিগ্রেডেশন সনাক্তকরণের জন্য কনফিগার করা হয়েছে: p95 ২০০০ ms-এর বেশি নয়, error rate ৫% এর বেশি নয়। সীমা অতিক্রম করলে k6 ত্রুটি কোড সহ পরীক্ষা শেষ করে, যা Stress Test-কে CI/CD পাইপলাইনে অন্তর্ভুক্ত করতে দেয়।

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

স্ট্রেস-টেস্টিংয়ের সেরা অনুশীলন

staging-এ Stress Test শুরু করুন — production-স্ট্রেস-টেস্টিংয়ের জন্য উন্নত মনিটরিং এবং রোলব্যাক পরিকল্পনা প্রয়োজন। Google SRE (2024) ১০০% বিচ্ছিন্ন পরিবেশে Stress Test পরিচালনার পরামর্শ দেয় যা আর্কিটেকচার এবং ক্ষমতায় production-এর অনুরূপ। staging-এ সফল পরীক্ষার পরে SRE পর্যবেক্ষণে production-এ যাওয়া যেতে পারে। Feature flag ওভারলোডে কার্যকারিতা বন্ধ করার জন্য — একটি বাধ্যতামূলক উপাদান।

CI/CD-তে Stress Test স্বয়ংক্রিয় করুন ব্যর্থতার পয়েন্টের রিগ্রেশন বিশ্লেষণের জন্য। যদি অ্যাপ্লিকেশনের নতুন সংস্করণের ব্যর্থতার পয়েন্ট পূর্ববর্তী সংস্করণের চেয়ে ২০% কম হয়, এটি একটি রিগ্রেশন যা রিলিজের আগে সংশোধন করা প্রয়োজন। Baseline breaking point মেট্রিকে সংরক্ষিত থাকে এবং প্রতিটি Stress Test-এর ফলাফলের সাথে স্বয়ংক্রিয়ভাবে তুলনা করা হয়। ব্যর্থতার পয়েন্ট ১০% কমলে অ্যালার্ট সক্রিয় হয়।

প্রতিটি Stress Test ডকুমেন্ট করুন: লোড প্রোফাইল, ব্যর্থতার পয়েন্ট, পুনরুদ্ধারের আচরণ এবং সনাক্ত করা সমস্যার তালিকা। Netflix Engineering (2024) “Game Day” পরিচালনা করে — নিয়মিত Stress Test সেশন যার ফলাফল “chaos report”-এ ডকুমেন্ট করা হয়। স্ট্রেস-টেস্টিং রিপোর্ট-এ “RPS — রেসপন্স টাইম” গ্রাফ থাকা উচিত যাতে ব্যর্থতার পয়েন্ট চিহ্নিত থাকে।