এই পর্বে যা পাবেন
- Cloud আর DevOps-এর প্রতিটি ধরনের numerical-এর সূত্র, নিয়ম আর সাধারণ ফাঁদ এক জায়গায়
- TCO, availability, IOPS, CIDR, NAT আর CDN-এর হিসাব ধাপে ধাপে লেখার অভ্যাস
- HPA, rolling update, GB-second, burn rate আর Little-এর সূত্রের পূর্ণ উদাহরণ
- উল্টো প্রশ্ন সামলানো: “RTO ২ ঘণ্টা রাখতে কত গতি লাগবে?”, “কত VM-এ commitment নেব?”
- ছোট প্রোগ্রাম দিয়ে নিজের উত্তর যাচাই, আর AI-এর দেওয়া হিসাব সন্দেহের চোখে দেখা
১ · পাতার নিয়ম, ভাগের মানচিত্র আর খাতার কৌশল
মডিউল ১৪-এ স্বাগতম। ঢাকা থেকে সিলেটের ট্রেনের সময়সূচি মুখস্থ থাকলেই ট্রেন ধরা যায় না, ঘড়ি মিলিয়ে স্টেশনে পৌঁছাতে হয়। সূত্রও তেমন। জানা এক জিনিস, আর ঘড়ির চাপে সঠিক একক বসিয়ে উত্তর বের করা আরেক জিনিস। এই পাতা দ্বিতীয় অভ্যাসটি তৈরি করে। এ ধরনের হিসাব বিশ্ববিদ্যালয়, চাকরির লিখিত পরীক্ষা আর ইন্টারভিউতে প্রায়ই আসে, আর বাস্তবে সিদ্ধান্ত নিতেও এগুলোই লাগে।
কোন ভাগে কী, কোন পর্ব ঝালাবেন
| ভাগ | কী আছে | মূল পর্ব |
|---|---|---|
| ২ | TCO, break-even, elasticity, nines, availability-র গঠন | ৪, ৫ |
| ৩ | IOPS, throughput, durability, transfer time, RPO, RTO | ২০, ২৪, ৭৫ |
| ৪ | CIDR, VPC-র নকশা, NAT, cross-AZ, peering, DNS failover, CDN | ২৫, ২৬, ২৮, ২৯, ৩০ |
| ৫ | KMS call-এর খরচ, layer, multi-stage, pull time | ৩৩, ৩৭, ৩৮ |
| ৬ | Rolling update, request ও QoS, HPA, target tracking | ১৭, ৪৪, ৪৮ |
| ৭ | GB-second, concurrency, VM বনাম FaaS | ৬৯ |
| ৮ | PromQL rate, histogram quantile, burn rate, MTTx, Little-এর সূত্র, capacity | ৬৩, ৬৬, ৬৭, ৬৮ |
| ৯ | Commitment, spot, rightsizing, unit economics | ৭২, ৭৩ |
এই পাতার নিয়ম — প্রশ্নে অন্য কিছু না বললে
| বিষয় | নিয়ম |
|---|---|
| সময় | মাস = ৩০ দিন = ৭২০ ঘণ্টা = ৪৩,২০০ মিনিট = ২৫,৯২,০০০ সেকেন্ড; বছর = ৩৬৫ দিন = ৮,৭৬০ ঘণ্টা |
| আকার | দশমিক: 1 KB = 10³ B, 1 MB = 10⁶ B, 1 GB = 10⁹ B, 1 TB = 10¹² B. GiB লেখা থাকলে 2³⁰ B |
| গতি | 1 Gbps = 125 MB/s. Link-এর গতি bit-এ, ফাইলের আকার byte-এ, তাই ৮ দিয়ে গুণ বা ভাগ লাগে |
| Subnet | ঠিকানা = 232−p; কাটা ঠিকানা AWS-এর মতো ৫টি। অন্য provider-এ সংখ্যা আলাদা হতে পারে |
| Availability | স্তর series-এ গুণ হয়; কপি parallel-এ: 1 − (1 − a)n. কপির ব্যর্থতা স্বাধীন ধরা হয়, প্রশ্নে β থাকলে নয় |
| MTTR, MTBF | MTTR প্রভাব শুরু থেকে সেবা ফেরা পর্যন্ত; MTBF এক ঘটনার শেষ থেকে পরের শুরু পর্যন্ত; A = MTBF ÷ (MTBF + MTTR) |
| দশমিক | টাকা দুই ঘরে; শতাংশ দরকারমতো। ক্ষমতার উত্তর সবসময় ওপরের পূর্ণসংখ্যায় (⌈ ⌉) |
অনুমিত দামের তালিকা
এগুলো শেখার জন্য ধরা গোল সংখ্যা, কোনো provider-এর আসল দাম নয়। একই সংখ্যা সংশ্লিষ্ট পর্বগুলোতে আছে। আসল কাজে provider-এর pricing পাতা দেখে নিন।
| জিনিস | অনুমিত দাম | পর্ব |
|---|---|---|
| VM | on-demand $০.৫০/ঘণ্টা; ১ বছরের অঙ্গীকার $০.৩৫ (৩০% ছাড়); ৩ বছরের $০.২৫ (৫০% ছাড়); spot $০.১৫ | ৪, ৭২ |
| NAT gateway | $০.০৫/ঘণ্টা + $০.০৫/GB; internet egress $০.০৯/GB; AZ পার হলে $০.০২/GB | ২৬ |
| Peering, hub | peering $০.০১/GB; hub attachment $০.০৫/ঘণ্টা + $০.০২/GB | ২৮ |
| CDN | user-এর কাছে পাঠানো $০.০৬/GB; অনুরোধ $১/মিলিয়ন; origin থেকে CDN-এ $০.০২/GB; origin সরাসরি $০.০৯/GB | ৩০ |
| KMS | প্রতি ১০,০০০ call-এ $০.০৩ | ৩৩ |
| FaaS | প্রতি মিলিয়ন call-এ $০.২০; প্রতি GB-second-এ $০.০০০০২; free tier বাদ | ৬৯ |
১. দেওয়া তথ্য আর একক এক লাইনে। “৩ TB, ১ Gbps = ১২৫ MB/s” লিখলেই bit-byte-এর ভুল সেখানে ধরা পড়ে।
২. নিয়ম ঘোষণা করুন। “৩০ দিনের মাস, কাটা ঠিকানা ৫টি, ব্যর্থতা স্বাধীন।” প্রশ্নে স্পষ্ট না থাকলে এটিই আপনার রক্ষাকবচ।
৩. সূত্র আগে, মান পরে। গণনায় ভুল হলেও সূত্র দেখে পরীক্ষক যুক্তি বুঝতে পারেন।
৪. ভগ্নাংশের অর্থ ভাবুন। ১৬.৭টি server হয় না, ১৭টি লাগে। ২৫.৪৫ মাসের break-even মানে ২৬তম মাসে cloud মোট খরচে পিছিয়ে যায়।
৫. একটি sanity check দিন। Parallel-এর ফল প্রতিটি কপির চেয়ে ভালো তো? Series-এর ফল সবচেয়ে দুর্বল স্তরের চেয়ে খারাপ তো? উত্তর বসিয়ে উল্টো হিসাব মেলে তো?
২ · Cloud-এর অর্থনীতি আর availability
ঝালিয়ে নিন: পর্ব ৪ · Cloud-এর অর্থনীতি (CapEx, OpEx, TCO, elasticity), পর্ব ৫ · Cloud-এর ভৌগোলিক কাঠামো (nines, series, parallel), পর্ব ৭২ · Cloud-এর বিল.
TCO: CapEx + মাস × মাসিক খরচ। Break-even মাস = CapEx ÷ (cloud-এর মাসিক − নিজের মাসিক)।
Break-even utilisation: U* = নিজের মাসিক স্থির খরচ ÷ (মোট server-ঘণ্টা × cloud-এর ঘণ্টার দাম)। PAR = peak ÷ গড়; peak-এ কেনা হলে utilisation = ১ ÷ PAR.
Availability: downtime = (১ − A) × সময়। Series: A = a₁ × a₂ × …; parallel: A = 1 − (1 − a)n; beta factor থাকলে 1 − (βu + ((1 − β)u)n), u = 1 − a.
TCO আর elasticity
২.১(সহজ) ৮টি server, প্রতিটি $৭,০০০; নিজের চলতি খরচ মাসে $১,৮০০. একই কাজ cloud-এ মাসে $৪,০০০. দিনরাত পূর্ণ load. ৩৬ মাসের TCO আর break-even মাস কত? (ঝালিয়ে নিন: পর্ব ৪)
CapEx = 8 x 7000 = 56,000
own(36) = 56,000 + 36 x 1,800 = 56,000 + 64,800 = 120,800
cloud(36) = 36 x 4,000 = 144,000
monthly saving = 4,000 - 1,800 = 2,200
break-even = 56,000 / 2,200 = 25.45 monthsযাচাই: ২৪ মাসে নিজের $৯৯,২০০, cloud $৯৬,০০০, তখনো cloud সস্তা। ২৬ মাসে $১,০২,৮০০ বনাম $১,০৪,০০০, এবার নিজের server এগিয়ে। ৩৬ মাসে নিজের $১,২০,৮০০, cloud $১,৪৪,০০০; break-even প্রায় ২৫.৪৫ মাসে, তাই ২৬তম মাস থেকে নিজের server সস্তা। পূর্ণ load আর পুরো সময় চলার শর্ত ভাঙলে উত্তর বদলায়।
২.২(মাঝারি) ১০টি server $৪৮,০০০-তে কেনা, আয়ু ৫ বছর; চলতি খরচ মাসে $২,০০০. Cloud-এ কাজের প্রতি server-ঘণ্টা $০.৫০, বসে থাকা ঘণ্টা দিতে হয় না। কত utilisation-এর নিচে cloud সস্তা? U = ৪০% হলে নিজের server-এ কাজের প্রতি ঘণ্টা কত পড়ে? (ঝালিয়ে নিন: পর্ব ৪)
own per month = 48,000 / 60 + 2,000 = 800 + 2,000 = 2,800
server-hours = 10 x 720 = 7,200
equal cost: 2,800 / (7,200 x U) = 0.50
U* = 2,800 / 3,600 = 0.778
at U = 0.40: 2,800 / (7,200 x 0.40) = 0.97 per useful hourনিজের server-এর খরচ স্থির, তাই কাজ কম হলে প্রতি ঘণ্টার দাম বাড়ে। U* ≈ ৭৭.৮%; ৪০%-এ কাজের প্রতি ঘণ্টা প্রায় $০.৯৭, cloud-এর প্রায় দ্বিগুণ।
২.৩(মাঝারি) একটি অ্যাপে দিনে ৮ ঘণ্টা ১২টি আর ১৬ ঘণ্টা ৩টি server লাগে; ঘণ্টায় $০.৫০. গড়, PAR, peak-এ স্থির ১২টি রাখলে utilisation, আর ৩০ দিনে স্থির বনাম elastic খরচ কত? (ধরুন scaling সঙ্গে সঙ্গে হয়) (ঝালিয়ে নিন: পর্ব ৪)
used = 12 x 8 + 3 x 16 = 96 + 48 = 144 server-hours/day
avg = 144 / 24 = 6 PAR = 12 / 6 = 2
utilisation = 144 / (12 x 24) = 50%
fixed = 12 x 720 x 0.50 = 4,320
elastic = 144 x 30 x 0.50 = 2,160ভালো লক্ষণ: utilisation = ১ ÷ PAR, দুই পথেই ৫০%. গড় ৬, PAR ২, utilisation ৫০%, স্থির $৪,৩২০, elastic $২,১৬০. বাস্তবে নতুন VM ওঠার দেরির জন্য কিছু বাড়তি রাখতে হয়, তাই আসল সাশ্রয় একটু কম।
Nines আর availability-র গঠন
স্তর গুণ হয়, স্তরের ভেতরের কপি parallel
Tiers in series, copies in parallel — numbers for problem ২.৫
২.৪(সহজ) ৯৯.৯৫% আর ৯৯.৯৯% availability-তে ৩০ দিনের মাসে আর ৩৬৫ দিনের বছরে সর্বোচ্চ কতটা বন্ধ থাকা চলে? (ঝালিয়ে নিন: পর্ব ৫)
99.95%: 0.0005 x 43,200 = 21.6 min/month
0.0005 x 8,760 = 4.38 h/year
99.99%: 0.0001 x 43,200 = 4.32 min/month
0.0001 x 8,760 = 0.876 h/year = 52.56 min/year৯৯.৯৫%: মাসে ২১.৬ মিনিট, বছরে ৪.৩৮ ঘণ্টা। ৯৯.৯৯%: মাসে ৪.৩২ মিনিট, বছরে ৫২.৫৬ মিনিট। ৯৯.৯৫% থেকে ৯৯.৯৯%-এ গেলে downtime ঠিক পাঁচ ভাগের এক ভাগ হয়।
২.৫(মাঝারি) DNS ৯৯.৯৯%, load balancer ৯৯.৯৯%, ৯৯% মানের তিনটি app কপি, ৯৯.৯৫% মানের দুটি database কপি (ব্যর্থতা স্বাধীন, failover তাৎক্ষণিক)। মোট availability আর মাসিক downtime কত? দ্বিতীয় database সরালে কী হয়? (ঝালিয়ে নিন: পর্ব ৫)
app tier = 1 - 0.01^3 = 0.999999
db tier = 1 - 0.0005^2 = 0.99999975
total = 0.9999 x 0.9999 x 0.999999 x 0.99999975 = 0.9997988
downtime = (1 - 0.9997988) x 43,200 = 8.69 min/month
one db: 0.9999 x 0.9999 x 0.999999 x 0.9995 = 0.9992991সীমা ঠিক করছে একা থাকা DNS আর load balancer, কারণ ফলাফল তাদের গুণফল ৯৯.৯৮%-এর সামান্য নিচে। Sanity check: মোট সবচেয়ে দুর্বল series স্তরের চেয়ে খারাপ। মোট ≈ ৯৯.৯৭৯৮৮%, মাসে প্রায় ৮.৬৯ মিনিট; একটি database-এ ≈ ৯৯.৯২৯৯১%.
২.৬(কঠিন) DNS আর LB দুটোই ৯৯.৯৯%, তাদের পরে একটি app স্তর, যার প্রতি কপি ৯৮%. পুরো পথে অন্তত ৯৯.৯৫% চাই। (ক) কয়টি স্বাধীন কপি লাগবে? (খ) ৩টি কপির ব্যর্থতা একসাথে ঘটার beta factor ০.০৫ হলে ফল কত? (ঝালিয়ে নিন: পর্ব ৫)
need app tier >= 0.9995 / (0.9999 x 0.9999) = 0.99970
so 0.02^n <= 0.00030
n = 2: 0.02^2 = 0.00040 no (end to end 99.94001%)
n = 3: 0.02^3 = 0.000008 yes (end to end 99.97920%)
beta = 0.05, u = 0.02, n = 3
tier = 1 - (0.05 x 0.02 + (0.95 x 0.02)^3) = 0.998993
end to end = 0.9998 x 0.998993 = 99.87934%ফাঁদ: দুই কপিতে app স্তর ৯৯.৯৬%, যা ৯৯.৯৫%-এর ওপরে দেখে থেমে গেলে ভুল, কারণ series-এর গুণে মোট নেমে যায়। (ক) ৩টি কপি। (খ) ≈ ৯৯.৮৭৯৩৪%, লক্ষ্যের নিচে। যে ব্যর্থতা সব কপিকে একসাথে ফেলে, তা কপি বাড়িয়ে পার হওয়া যায় না।
// TCO, break-even month, break-even utilisation, elasticity. Prices ASSUMED.
const usd = (x) => "$" + x.toLocaleString("en-US", { maximumFractionDigits: 2 });
// Buy vs rent: 8 servers at $7,000, own $1,800 a month, cloud $4,000 a month
const capex = 8 * 7000, own = 1800, cloud = 4000;
for (const m of [12, 24, 26, 36, 60])
console.log(`month ${String(m).padStart(2)}: own ${usd(capex + own * m)}, cloud ${usd(cloud * m)}`);
console.log("break-even month =", (capex / (cloud - own)).toFixed(2));
// Utilisation: 5-year life, 10 servers, cloud $0.50 per useful server-hour
const fixed = 48000 / 60 + 2000, hours = 10 * 720, price = 0.5;
console.log("own per month", usd(fixed));
console.log("U* =", (100 * fixed / (hours * price)).toFixed(1) + "%");
for (const u of [0.4, 0.778, 0.9])
console.log(`U ${u}: own ${usd(fixed / (hours * u))} per useful hour`);
// Elasticity: 12 servers for 8 hours, 3 servers for 16 hours, $0.50 an hour
const day = [[12, 8], [3, 16]], peak = 12;
const used = day.reduce((s, [n, h]) => s + n * h, 0), avg = used / 24;
console.log("server-hours", used, "avg", avg, "PAR", peak / avg);
console.log("fixed", usd(peak * 720 * price), "elastic", usd(used * 30 * price),
"utilisation", (100 * used / (peak * 24)).toFixed(0) + "%");আউটপুট:
month 12: own $77,600, cloud $48,000
month 24: own $99,200, cloud $96,000
month 26: own $102,800, cloud $104,000
month 36: own $120,800, cloud $144,000
month 60: own $164,000, cloud $240,000
break-even month = 25.45
own per month $2,800
U* = 77.8%
U 0.4: own $0.97 per useful hour
U 0.778: own $0.5 per useful hour
U 0.9: own $0.43 per useful hour
server-hours 144 avg 6 PAR 2
fixed $4,320 elastic $2,160 utilisation 50%প্রথম অংশ ২.১-এর টেবিল: ২৪ মাসে cloud এগিয়ে, ২৬ মাসে পিছিয়ে। তারপর ২.২-এর U* ৭৭.৮%, আর শেষ দুই লাইন ২.৩. capex, day আর price বদলে নিজের অঙ্ক মেলান।
// Availability: downtime, copies in parallel, tiers in series, beta factor.
const par = (a, n, beta = 0) => {
const u = 1 - a;
return n === 1 ? a : 1 - (beta * u + ((1 - beta) * u) ** n);
};
const series = (...xs) => xs.reduce((p, x) => p * x, 1);
const pct = (a) => (a * 100).toFixed(5) + "%";
const down = (a) => `${((1 - a) * 43200).toFixed(2)} min/mo, ${((1 - a) * 8760).toFixed(2)} h/yr`;
for (const a of [0.999, 0.9995, 0.9999]) console.log(a, down(a));
const dns = 0.9999, lb = 0.9999;
const stack = series(dns, lb, par(0.99, 3), par(0.9995, 2));
console.log("3 app + 2 db :", pct(stack), down(stack));
console.log("3 app + 1 db :", pct(series(dns, lb, par(0.99, 3), 0.9995)));
console.log("1 app + 2 db :", pct(series(dns, lb, 0.99, par(0.9995, 2))));
// How many copies of a 98% app tier for 99.95% end to end?
for (const n of [1, 2, 3])
console.log(`n=${n}:`, pct(series(dns, lb, par(0.98, n))));
console.log("n=3, beta 0.05:", pct(series(dns, lb, par(0.98, 3, 0.05))));আউটপুট:
0.999 43.20 min/mo, 8.76 h/yr
0.9995 21.60 min/mo, 4.38 h/yr
0.9999 4.32 min/mo, 0.88 h/yr
3 app + 2 db : 99.97988% 8.69 min/mo, 1.76 h/yr
3 app + 1 db : 99.92991%
1 app + 2 db : 98.98018%
n=1: 97.98040%
n=2: 99.94001%
n=3: 99.97920%
n=3, beta 0.05: 99.87934%“3 app + 2 db” লাইনটি ২.৫-এর উত্তর। “1 app + 2 db”-তে ৯৮.৯৮০১৮% দেখুন: একা app কপিই মোটকে ৯৯%-এর নিচে নামায়। শেষ চারটি লাইন ২.৬: n=2-তে লক্ষ্য ফসকায়, n=3-তে পূরণ হয়, আর beta আবার নামিয়ে দেয়।
(সহজ) ৯৯.৯৯% availability-তে ৩০ দিনের মাসে সর্বোচ্চ কত মিনিট বন্ধ থাকা চলে?
- ৪৩.২ মিনিট
- ৫২.৫৬ মিনিট
- ৪.৩২ মিনিট
- ০.৪৩২ মিনিট
(মাঝারি) ৯৯% মানের দুটি অংশ পরপর (series) জুড়লে, আর একই দুটি স্বাধীন কপি parallel-এ রাখলে availability কত?
- ৯৮.০১% আর ৯৯.৯৯%
- ৯৯.৯৯% আর ৯৮.০১%
- ৯৮% আর ৯৯.৯%
- ৯৯% আর ৯৯%
(মাঝারি) CapEx $৩০,০০০, নিজের চলতি খরচ মাসে $১,০০০, cloud-এ মাসে $২,৫০০. Break-even কত মাসে?
- ১২ মাস
- ৩০ মাস
- প্রায় ৮.৬ মাস
- ২০ মাস
(মাঝারি) Peak-এ ২০টি server লাগে, গড়ে ৫টি। Peak-এর মাপে স্থির server কিনলে PAR আর utilisation কত?
- PAR ০.২৫, utilisation ৪০০%
- PAR ৪, utilisation ২৫%
- PAR ৪, utilisation ৫০%
- PAR ১৫, utilisation ৭৫%
৩ · Storage, ডেটা সরানো, RPO আর RTO
ঝালিয়ে নিন: পর্ব ২০ · Object, block আর file storage, পর্ব ২৪ · Backup আর disaster recovery, পর্ব ৭৫ · Cloud migration.
Throughput = IOPS × block size. সত্যিকার IOPS = min(volume-এর IOPS, volume-এর MB/s ÷ block, VM-এর MB/s ÷ block, queue depth ÷ latency).
Durability: বছরে প্রত্যাশিত ক্ষতি = N × (১ − durability). Transfer: T = আকার × ৮ ÷ (গতি × e); পরিবর্তন চলতে থাকলে T ÷ (১ − r ÷ b).
RPO: সবচেয়ে খারাপ ≈ I + S, গড় ≈ I ÷ ২ + S (I = ব্যবধান, S = নিরাপদ জায়গায় পৌঁছানোর সময়)। RTO ≈ স্থির ধাপগুলোর যোগ + ডেটা ÷ সবচেয়ে ধীর গতি।
৩.১(মাঝারি) একটি volume-এর সীমা ৩,০০০ IOPS আর ১২৫ MB/s. (ক) ১৬ KB I/O-তে throughput কত? (খ) কোন block size-এ দুই সীমা একসাথে ছোঁয়? (গ) ৬৪ KB-তে IOPS কত? (ঝালিয়ে নিন: পর্ব ২০)
(a) 3,000 x 16 KB = 48 MB/s (under 125, IOPS binds)
(b) 125,000 KB/s / 3,000 = 41.67 KB
(c) 125,000 / 64 = 1,953 IOPS (under 3,000, MB/s binds)(ক) ৪৮ MB/s. (খ) প্রায় ৪১.৬৭ KB. (গ) প্রায় ১,৯৫৩ IOPS. ৪১.৬৭ KB-র ছোট I/O-তে বাড়তি IOPS কিনলে লাভ, বড় I/O-তে বাড়তি throughput.
৩.২(মাঝারি) Volume ১৬,০০০ IOPS আর ৫০০ MB/s, VM-এর storage সীমা ২৫০ MB/s. (ক) ১৬ KB I/O-তে আসল সীমা কী? (খ) আলাদা ঘটনা: ৮ KB, একটির পর একটি fsync (queue depth ১), latency ১ ms, volume ৩,০০০ IOPS. তখন IOPS কত? (ঝালিয়ে নিন: পর্ব ২০)
(a) volume IOPS : 16,000
volume MB/s : 500,000 / 16 = 31,250
VM MB/s : 250,000 / 16 = 15,625 smallest
15,625 x 16 KB = 250 MB/s
(b) queue limit = 1 / 0.001 s = 1,000 IOPS (under 3,000)
1,000 x 8 KB = 8 MB/s(ক) VM-ই সীমা: ১৫,৬২৫ IOPS, ২৫০ MB/s. (খ) ১,০০০ IOPS, ৮ MB/s. দুই ক্ষেত্রেই দামি volume-এর পুরো ক্ষমতা পড়ে থাকে, বাধা অন্য জায়গায়।
৩.৩(সহজ) ৫০০ কোটি object, durability এগারো nine (প্রতি object-এ বছরে হারানোর সম্ভাবনা 10−11, স্বাধীন ধরে)। বছরে প্রত্যাশিত ক্ষতি কত? গড়ে কত বছরে একটি? (ঝালিয়ে নিন: পর্ব ২০)
N x p = 5 x 10^9 x 10^-11 = 0.05 objects/year
1 / 0.05 = 20 years per objectবছরে ০.০৫টি, মানে গড়ে ২০ বছরে একটি। এটি নকশার লক্ষ্য। নিজের ভুল delete এই হিসাবে নেই, তাই versioning আর backup তবু লাগে।
৩.৪(কঠিন) ২০ TB ডেটা ২০০ Mbps লিংকে সরাতে হবে, কার্যকারিতা e = ৭৫%. (ক) ডেটা স্থির থাকলে কত দিন? (খ) সোর্সে দিনে ৩০০ GB বদলালে কত দিন? (গ) ৮০ TB-র appliance-এ আনা-নেওয়া মিলিয়ে ১৪ দিন লাগলে কোন পথ দ্রুত? (ঝালিয়ে নিন: পর্ব ৭৫)
(a) b = 200 x 0.75 = 150 Mbps
T = 20 x 10^12 x 8 / (150 x 10^6) = 1,066,667 s = 12.35 days
(b) r = 300 x 10^9 x 8 / 86,400 = 27.78 Mbps
r / b = 0.1852
total = 12.35 / (1 - 0.1852) = 15.15 days
(c) backlog after 14 days = 14 x 300 GB = 4.2 TB
catch-up = 4.2 x 10^12 x 8 / ((150 - 27.78) x 10^6) = 274,909 s = 3.18 days
appliance total = 14 + 3.18 = 17.18 days(গ) স্থির ডেটায় network ১২.৩৫ দিনে জেতে। বদলাতে থাকা ডেটায় ১৪ বনাম ১৫.১৫ দেখে appliance এগিয়ে মনে হয়, কিন্তু ফাঁদ এখানেই: ১৪ দিনে জমা ৪.২ TB পরিবর্তন পরে লিংকেই পাঠাতে হয়, মোট প্রায় ১৭.১৮ দিন। r যদি b ছাড়ায়, online কপি কখনো শেষ হয় না। (ক) ১২.৩৫ দিন। (খ) ১৫.১৫ দিন। (গ) দুই ক্ষেত্রেই network: ১২.৩৫ বনাম ১৪ দিন, আর ১৫.১৫ বনাম প্রায় ১৭.১৮ দিন।
৩.৫(মাঝারি) প্রতি ঘণ্টায় snapshot, অন্য region-এ পৌঁছাতে ১০ মিনিট। Region হারালে সবচেয়ে খারাপ আর গড় RPO কত? মিনিটে ২টি অর্ডার এলে সবচেয়ে খারাপ ক্ষেত্রে কতটি অর্ডার হারায়? (ঝালিয়ে নিন: পর্ব ২৪)
worst = I + S = 60 + 10 = 70 min
mean = I/2 + S = 30 + 10 = 40 min
orders lost (worst) = 70 x 2 = 140ফাঁদ: S ভুলে “৬০ মিনিট” বলা। পৌঁছানোর আগের বিপর্যয়ে শেষ snapshot-ও অন্য region-এ নেই। সবচেয়ে খারাপ ৭০ মিনিট, গড় ৪০ মিনিট, ১৪০টি অর্ডার।
৩.৬(কঠিন) ৩ TB database ফেরাতে হবে। (ক) ১ Gbps পথ, বাকি ধাপ ৮০ মিনিট: RTO কত? (খ) বাকি ধাপ কমিয়ে ৪০ মিনিট করা হলো, লক্ষ্য ২ ঘণ্টা: কত গতি লাগবে? (গ) network ১০ Gbps, কিন্তু disk লেখে ৪০০ MB/s: লক্ষ্য পূরণ হবে? (ঝালিয়ে নিন: পর্ব ২৪)
(a) 1 Gbps = 125 MB/s
3 x 10^12 / (125 x 10^6) = 24,000 s = 400 min
RTO = 400 + 80 = 480 min = 8 h
(b) data budget = 120 - 40 = 80 min = 4,800 s
speed = 3 x 10^12 / 4,800 = 625 MB/s = 5 Gbps
(c) slowest = 400 MB/s
3 x 10^12 / (400 x 10^6) = 7,500 s = 125 min
RTO = 125 + 40 = 165 min > 120(ক) ৮ ঘণ্টা। (খ) ৬২৫ MB/s, মানে ৫ Gbps. (গ) না, ১৬৫ মিনিট; সবচেয়ে ধীর ধাপটিই গতি ঠিক করে।
// IOPS, throughput, durability and transfer time. Decimal units.
function bind(iopsCap, mbCap, vmMb, kb, qd = 64, latMs = 1) {
const lim = { "volume IOPS": iopsCap, "volume MB/s": mbCap * 1000 / kb,
"VM MB/s": vmMb * 1000 / kb, "queue": qd / (latMs / 1000) };
const [who, iops] = Object.entries(lim).sort((a, b) => a[1] - b[1])[0];
return `${kb} KB: ${Math.round(iops)} IOPS, ${(iops * kb / 1000).toFixed(1)} MB/s (${who})`;
}
console.log(bind(3000, 125, 250, 16));
console.log(bind(3000, 125, 250, 64));
console.log(bind(16000, 500, 250, 16));
console.log(bind(3000, 125, 250, 8, 1, 1));
console.log("crossover size", (125e3 / 3000).toFixed(2), "KB");
console.log("expected loss/yr", (5e9 * 1e-11).toFixed(2), "objects");
// Transfer: T = size x 8 / (b x e), then T / (1 - r/b) if data keeps changing
const days = (s) => (s / 86400).toFixed(2);
const T = 20e12 * 8 / (200e6 * 0.75), b = 150, r = 300e9 * 8 / 86400 / 1e6;
console.log("T", T.toFixed(0), "s =", days(T), "days");
console.log("r", r.toFixed(2), "Mbps; with changes", days(T / (1 - r / b)), "days");
// Restore: RTO = fixed steps + data / slowest speed
const rto = (bytes, MBps, fixedMin) => bytes / (MBps * 1e6) / 60 + fixedMin;
console.log("3 TB, 125 MB/s, 80 min fixed:", rto(3e12, 125, 80), "min");
console.log("3 TB, 400 MB/s, 40 min fixed:", rto(3e12, 400, 40), "min");
console.log("needed for 120 min:", 3e12 / ((120 - 40) * 60) / 1e6, "MB/s");আউটপুট:
16 KB: 3000 IOPS, 48.0 MB/s (volume IOPS)
64 KB: 1953 IOPS, 125.0 MB/s (volume MB/s)
16 KB: 15625 IOPS, 250.0 MB/s (VM MB/s)
8 KB: 1000 IOPS, 8.0 MB/s (queue)
crossover size 41.67 KB
expected loss/yr 0.05 objects
T 1066667 s = 12.35 days
r 27.78 Mbps; with changes 15.15 days
3 TB, 125 MB/s, 80 min fixed: 480 min
3 TB, 400 MB/s, 40 min fixed: 165 min
needed for 120 min: 625 MB/sপ্রথম চার লাইনের শেষে বন্ধনীতে বলা আছে কোন সীমা আগে ঠেকেছে: ৩.১ আর ৩.২-এর উত্তর। এরপর ৩.৩, ৩.৪ আর ৩.৬. bind()-এর চারটি সীমার সবচেয়ে ছোটটিই জেতে, এটিই পুরো ভাগের মূল কথা।
(সহজ) ৫,০০০ IOPS-এ ৮ KB block হলে throughput কত?
- ৬২৫ KB/s
- ৪০০ MB/s
- ৪০ MB/s
- ৪ MB/s
(মাঝারি) ১ TB ডেটা ৫০০ Mbps লিংকে, কার্যকারিতা ৮০%. কত সময় লাগবে? (ডেটা স্থির)
- প্রায় ৫.৫৬ ঘণ্টা
- প্রায় ০.৬৯ ঘণ্টা
- প্রায় ৪.৪৪ ঘণ্টা
- প্রায় ৪৪ ঘণ্টা
(মাঝারি) প্রতি ৬ ঘণ্টায় backup, অন্য region-এ পৌঁছাতে ৩০ মিনিট। সবচেয়ে খারাপ আর গড় RPO কত?
- ৬ ঘণ্টা আর ৩ ঘণ্টা
- ৬.৫ ঘণ্টা আর ৩.৫ ঘণ্টা
- ১২ ঘণ্টা আর ৬ ঘণ্টা
- ৩০ মিনিট আর ১৫ মিনিট
(মাঝারি) ১০০ কোটি (109) object, প্রতি object-এ বছরে হারানোর সম্ভাবনা 10−11. গড়ে কত বছরে একটি object হারায়?
- ১ বছরে
- ১০ বছরে
- ১০,০০০ বছরে
- ১০০ বছরে
৪ · Network — CIDR, NAT, peering, DNS আর CDN
ঝালিয়ে নিন: পর্ব ২৫ · VPC আর subnet, পর্ব ২৬ · Route table, internet gateway আর NAT, পর্ব ২৮ · VPC জোড়া, পর্ব ২৯ · Cloud DNS, পর্ব ৩০ · CDN, WAF আর DDoS সুরক্ষা. Binary subnetting-এর পুরো তত্ত্ব আছে Computer Networks-এর subnetting পর্বে.
CIDR: ঠিকানা = 232−p; ব্যবহারযোগ্য = ঠিকানা − কাটা ঠিকানা। Block-এর আকার B হলে network = ⌊octet ÷ B⌋ × B. Subnet বাছাই: দরকার = ⌈host × (১ + বৃদ্ধি)⌉ + কাটা ঠিকানা, তারপর 2-এর পরের ঘাত।
NAT বিল = সংখ্যা × ঘণ্টার দর × ৭২০ + NAT দিয়ে যাওয়া GB × দর + egress + AZ পার হওয়া GB × দর। Full mesh = n(n − ১) ÷ ২.
DNS failover, সবচেয়ে খারাপ ≈ I × F + TTL + A. CDN: origin-এর অনুরোধ = মোট × (১ − h), h হলো hit ratio.
৪.১(সহজ) /20, /24 আর /28-এ কয়টি ঠিকানা? প্রতি subnet-এ ৫টি কাটা গেলে কয়টি ব্যবহারযোগ্য? (ঝালিয়ে নিন: পর্ব ২৫)
/20: 2^12 = 4,096 usable 4,091
/24: 2^8 = 256 usable 251
/28: 2^4 = 16 usable 11এক ধাপ prefix বাড়লে subnet অর্ধেক হয়। ৪,০৯৬/৪,০৯১, ২৫৬/২৫১, ১৬/১১.
৪.২(মাঝারি) (ক) 172.18.77.200/21 কোন network-এর, শেষ ঠিকানা কী? (খ) 10.20.16.0/20-এর সাথে 10.20.24.0/21 আর 10.20.32.0/21 ওভারল্যাপ করে কি? (ঝালিয়ে নিন: পর্ব ২৫)
(a) /21 -> block in 3rd octet = 2^(24-21) = 8
floor(77 / 8) x 8 = 72
172.18.72.0 .. 172.18.79.255 (2,048 addresses)
(b) /20 -> block 16: 10.20.16.0 .. 10.20.31.255
10.20.24.0/21 = .24.0 .. .31.255 inside it -> overlap
10.20.32.0/21 = .32.0 .. .39.255 outside -> no overlap(ক) 172.18.72.0/21, শেষ 172.18.79.255. (খ) প্রথমটি ওভারল্যাপ করে, দ্বিতীয়টি করে না। ওভারল্যাপ থাকলে peering তৈরিই হয় না, আর একই VPC-তে এমন subnet বানানো যায় না।
৪.৩(মাঝারি) একটি subnet-এ এখন ৪০০ host, ৫০% বৃদ্ধি ধরতে হবে, ৫টি ঠিকানা কাটা। সবচেয়ে ছোট কোন prefix? ১২০ host আর ২৫% হলে? (ঝালিয়ে নিন: পর্ব ২৫)
400 x 1.5 + 5 = 605 -> next power of 2 = 1,024 = /22
120 x 1.25 + 5 = 155 -> next power of 2 = 256 = /24Sanity check: /23-এ ৫১২ < ৬০৫, চলবে না। /25-এ ১২৮ < ১৫৫, চলবে না। /22 আর /24.
VPC: 10.20.0.0/16 (65,536)
AZ : a, b, c
app : /20 per AZ
web : /24 per AZ
db : /24 per AZ
rule: biggest blocks first
app-a 10.20.0.0/20 .0 - .15 app-b 10.20.16.0/20 .16 - .31 app-c 10.20.32.0/20 .32 - .47 /20 starts must be multiples of 16
web-a 10.20.48.0/24 web-b 10.20.49.0/24 web-c 10.20.50.0/24 db-a 10.20.51.0/24 db-b 10.20.52.0/24 db-c 10.20.53.0/24
used = 3 x 4,096 + 6 x 256
= 12,288 + 1,536 = 13,824
share = 13,824 / 65,536 = 21.1%
app usable = 3 x 4,091 = 12,273
overlap: none (.0-.47, .48-.53) free /24s: 10.20.54.0 .. 10.20.63.0 next free /20: 10.20.64.0/20 .48-.63 is a partly used /20
- তথ্য লিখুন। /16-এ ৬৫,৫৩৬টি ঠিকানা। প্রতি AZ-এ তিনটি subnet, মোট নয়টি। ছোট আগে বসালে পরে বড় block-এর সীমায় ফাঁক পড়ে, তাই বড় আগে।
- বড় block. /20-এর আকার তৃতীয় octet-এ ১৬, তাই শুরু ০, ১৬, ৩২. প্রতিটিতে ৪,০৯৬টি ঠিকানা।
- ছোট block. পরের ফাঁকা জায়গা 10.20.48.0. /24 যেকোনো পূর্ণ তৃতীয় octet-এ বসে, তাই পরপর ছয়টি: ৪৮ থেকে ৫৩.
- গোনা। মোট ১৩,৮২৪টি ঠিকানা, /16-এর ২১.১%. App স্তরে ব্যবহারযোগ্য ১২,২৭৩টি, কারণ প্রতি subnet-এ ৫টি কাটা।
- যাচাই। কোনো ওভারল্যাপ নেই। 10.20.54.0 থেকে 10.20.63.0 পর্যন্ত /24 ফাঁকা। পরের পূর্ণ /20 বসবে 10.20.64.0-তে, কারণ ৪৮-এর /20 আংশিক ব্যবহৃত।
৪.৪(কঠিন) ওপরের নকশায় নতুন দুটি block লাগবে: একটি /22 আর একটি /19. ফাঁকা জায়গায় কোথায় বসবে? দুটি বসার পরেও /16-এর কত অংশ বাকি? (ঝালিয়ে নিন: পর্ব ২৫)
/22: 3rd octet block = 4. After .53 the first multiple of 4 is .56
10.20.56.0/22 = .56 .. .59 (1,024)
/19: block = 32. First free multiple of 32 is .64
10.20.64.0/19 = .64 .. .95 (8,192)
used = 13,824 + 1,024 + 8,192 = 23,040
free = 65,536 - 23,040 = 42,496 = 64.8%ফাঁদ: 10.20.54.0/22 বৈধ নয়, কারণ ৫৪ চারের গুণিতক নয়, block শুরু হবে ৫২ থেকে, যা db-b আর db-c-তে পড়ে। 10.20.56.0/22 আর 10.20.64.0/19; বাকি ৪২,৪৯৬টি ঠিকানা, ৬৪.৮%.
৪.৫(মাঝারি) ৩টি AZ-এ private subnet থেকে মাসে ২০,০০০ GB বেরোয়: ১৪,০০০ GB একই region-এর object storage-এ, ৬,০০০ GB internet-এ। Traffic তিন AZ-এ সমান। AZ পার হওয়া খরচ প্রতি GB-তে একবার ধরুন, gateway endpoint বিনা খরচে, দর ওপরের তালিকার মতো। (A) ৩টি NAT, (B) ৩টি NAT + endpoint, (C) ১টি NAT, (D) ১টি NAT + endpoint: মাসিক বিল কত? (ঝালিয়ে নিন: পর্ব ২৬)
A: 3 x 0.05 x 720 = 108; 20,000 x 0.05 = 1,000; 6,000 x 0.09 = 540
total 1,648
B: 108 + 6,000 x 0.05 (300) + 540 = 948
C: 36 + 1,000 + 540 + (20,000 x 2/3) x 0.02 (266.67) = 1,842.67
D: 36 + 300 + 540 + (6,000 x 2/3) x 0.02 (80) = 956“টাকা বাঁচাতে” একটি NAT রাখা (C) সবচেয়ে দামি, কারণ দুই-তৃতীয়াংশ traffic AZ পার হয়। Endpoint-ই আসল সাশ্রয়: A থেকে B-তে $৭০০. B আর D-র পার্থক্য মাত্র $৮, অথচ D-তে NAT-এর AZ পড়লে সব AZ-এর বাইরের পথ বন্ধ। A $১,৬৪৮, B $৯৪৮, C $১,৮৪২.৬৭, D $৯৫৬.
৪.৬(মাঝারি) ১৫টি VPC. (ক) Peering-এর full mesh-এ কয়টি link? (খ) ১৬তম VPC যোগ করতে কয়টি নতুন peering, আর দুই পাশ মিলিয়ে কয়টি route (প্রতি VPC-তে একটি route table)? (গ) মাসে ৫,০০০ GB traffic হলে peering আর hub-এর বিল কত? (ঝালিয়ে নিন: পর্ব ২৮)
(a) 15 x 14 / 2 = 105
(b) new peerings = 15, routes = 15 x 2 = 30
check: 16 x 15 / 2 - 105 = 120 - 105 = 15
(c) peering = 5,000 x 0.01 = 50
hub = 15 x 0.05 x 720 + 5,000 x 0.02 = 540 + 100 = 640(ক) ১০৫. (খ) ১৫টি peering, ৩০টি route. (গ) peering $৫০, hub $৬৪০. টাকায় peering সস্তা। Hub-এর পক্ষে যুক্তি কাজের জটে: ১০৫টি link-এর বদলে ১৫টি attachment.
৪.৭(মাঝারি) Health check interval I = ৩০ s, threshold F = ৩. (ক) TTL ৬০ s আর ৩০০ s-এ সবচেয়ে খারাপ failover সময় কত? (খ) I = ১০, F = ৩, TTL ৬০, app-এর নিজের cache ১২০ s হলে? (গ) I = ১০, F = ২ রেখে ৬০ s-এর মধ্যে আনতে TTL সর্বোচ্চ কত? (ঝালিয়ে নিন: পর্ব ২৯)
(a) 30 x 3 + 60 = 150 s
30 x 3 + 300 = 390 s
(b) 10 x 3 + 60 + 120 = 210 s
(c) 10 x 2 + TTL <= 60 -> TTL <= 40 s(ক) ১৫০ s আর ৩৯০ s. (খ) ২১০ s. (গ) ৪০ s. কিন্তু ছোট TTL মানে বেশি query. আর F = ২ মানে সামান্য ঝামেলাতেও ভুল failover-এর ঝুঁকি বাড়ে।
৪.৮(কঠিন) মাসে ১২.৯৬ কোটি অনুরোধ, peak গড়ের ১০ গুণ, গড় উত্তর ১০০ KB. (ক) গড় আর peak req/s? (খ) Hit ৯০% হলে peak-এ origin কত পায়? (গ) Origin peak-এ ১০ req/s-এর বেশি না নিতে পারলে hit কত লাগবে? (ঘ) ৯০% hit-এ CDN-সহ মাসের বিল, আর origin থেকে সরাসরি পাঠালে বিল কত (server বাদে)? (ঝালিয়ে নিন: পর্ব ৩০)
(a) 129,600,000 / 2,592,000 = 50 req/s; peak = 500
(b) 500 x (1 - 0.90) = 50 req/s
(c) 500 x (1 - h) <= 10 -> h >= 0.98
(d) total = 129.6e6 x 100 KB = 12,960 GB
CDN out = 12,960 x 0.06 = 777.60
requests = 129.6 x 1.00 = 129.60
fill = 12,960 x 0.10 x 0.02 = 25.92
with CDN = 933.12
direct = 12,960 x 0.09 = 1,166.40লক্ষ করুন, ৯০% থেকে ৯৮% মানে origin-এর চাপ পাঁচ ভাগের এক ভাগ, যদিও hit মাত্র ৮ পয়েন্ট বেড়েছে। Hit-এর হিসাব miss দিয়ে করুন। (ক) ৫০ আর ৫০০. (খ) ৫০ req/s. (গ) ৯৮%. (ঘ) $৯৩৩.১২ বনাম $১,১৬৬.৪০.
// CIDR: size, range, usable addresses, overlap and smallest subnet.
const toInt = (ip) => ip.split(".").reduce((n, o) => n * 256 + Number(o), 0);
const toIp = (n) => [24, 16, 8, 0].map((s) => Math.floor(n / 2 ** s) % 256).join(".");
function cidr(text, reserved = 5) {
const [ip, p] = text.split("/"), size = 2 ** (32 - Number(p));
const first = Math.floor(toInt(ip) / size) * size;
return { first, last: first + size - 1, size, usable: size - reserved };
}
const show = (t) => { const c = cidr(t);
console.log(t.padEnd(18), toIp(c.first), "..", toIp(c.last), c.size, "usable", c.usable); };
["10.20.0.0/20", "10.20.37.5/20", "172.18.77.200/21", "10.20.48.0/24", "10.20.0.0/28"].forEach(show);
const overlap = (a, b) => { const x = cidr(a), y = cidr(b);
return x.first <= y.last && y.first <= x.last; };
console.log("overlap A:", overlap("10.20.16.0/20", "10.20.24.0/21"));
console.log("overlap B:", overlap("10.20.16.0/20", "10.20.32.0/21"));
function fit(hosts, growthPct, reserved = 5) {
const need = Math.ceil(hosts * (100 + growthPct) / 100) + reserved;
const prefix = 32 - Math.ceil(Math.log2(need));
return `${hosts} +${growthPct}% +${reserved} = ${need} -> /${prefix} (${2 ** (32 - prefix)})`;
}
console.log(fit(400, 50)); console.log(fit(120, 25));
const used = 3 * 4096 + 6 * 256;
console.log("plan uses", used, "of 65536 =", (100 * used / 65536).toFixed(1) + "%");আউটপুট:
10.20.0.0/20 10.20.0.0 .. 10.20.15.255 4096 usable 4091
10.20.37.5/20 10.20.32.0 .. 10.20.47.255 4096 usable 4091
172.18.77.200/21 172.18.72.0 .. 172.18.79.255 2048 usable 2043
10.20.48.0/24 10.20.48.0 .. 10.20.48.255 256 usable 251
10.20.0.0/28 10.20.0.0 .. 10.20.0.15 16 usable 11
overlap A: true
overlap B: false
400 +50% +5 = 605 -> /22 (1024)
120 +25% +5 = 155 -> /24 (256)
plan uses 13824 of 65536 = 21.1%Math.floor(ip ÷ size) × size লাইনটিই হাতের “octet ÷ block” হিসাব, শুধু পুরো ঠিকানার ওপর। JavaScript-এর bit operator ৩২ বিটের signed সংখ্যা ধরে, তাই এখানে ভাগ আর গুণ ব্যবহার করা হয়েছে। দ্বিতীয় লাইনে দেখুন, host bit শূন্য না হলেও network ঠিকই বেরোল: 10.20.32.0.
// NAT, peering, DNS failover and CDN. All prices ASSUMED.
const usd = (x) => "$" + x.toFixed(2);
const P = { natHour: 0.05, natGB: 0.05, egress: 0.09, crossAZ: 0.02, hours: 720 };
function nat(nats, storeGB, netGB, endpoint) {
const via = (endpoint ? 0 : storeGB) + netGB, azs = 3;
const cross = nats === 1 ? via * (azs - 1) / azs : 0;
return nats * P.natHour * P.hours + via * P.natGB + netGB * P.egress + cross * P.crossAZ;
}
console.log("A 3 NAT ", usd(nat(3, 14000, 6000, false)));
console.log("B 3 NAT + endpoint ", usd(nat(3, 14000, 6000, true)));
console.log("C 1 NAT ", usd(nat(1, 14000, 6000, false)));
console.log("D 1 NAT + endpoint ", usd(nat(1, 14000, 6000, true)));
const n = 15, gb = 5000;
console.log("mesh links", n * (n - 1) / 2, "peering", usd(gb * 0.01),
"hub", usd(n * 0.05 * P.hours + gb * 0.02));
const failover = (I, F, ttl, app = 0) => I * F + ttl + app;
console.log("DNS", failover(30, 3, 60), failover(30, 3, 300), failover(10, 3, 60, 120));
const req = 129.6e6, kb = 100, avg = req / 2592000, peak = 10 * avg;
const gbTotal = req * kb * 1e3 / 1e9, cdn = (h) => gbTotal * 0.06 + req / 1e6 + gbTotal * (1 - h) * 0.02;
console.log("CDN avg", avg, "peak", peak, "GB", gbTotal);
for (const h of [0.9, 0.98]) console.log(` hit ${h}: origin ${(peak * (1 - h)).toFixed(0)} req/s, bill ${usd(cdn(h))}`);
console.log("direct", usd(gbTotal * 0.09), "hit needed for 10 req/s:", 1 - 10 / peak);আউটপুট:
A 3 NAT $1648.00
B 3 NAT + endpoint $948.00
C 1 NAT $1842.67
D 1 NAT + endpoint $956.00
mesh links 105 peering $50.00 hub $640.00
DNS 150 390 210
CDN avg 50 peak 500 GB 12960
hit 0.9: origin 50 req/s, bill $933.12
hit 0.98: origin 10 req/s, bill $912.38
direct $1166.40 hit needed for 10 req/s: 0.98চারটি NAT সারি ৪.৫-এর, তারপর ৪.৬, ৪.৭ আর ৪.৮. ৯৮% hit-এ CDN-এর বিল প্রায় একই ($৯১২.৩৮) থাকে। Hit বাড়ানোর আসল লাভ origin-এর চাপ কমায়, তাই server কম লাগে।
(সহজ) একটি /27 subnet-এ ৫টি ঠিকানা কাটা গেলে কয়টি ব্যবহারযোগ্য?
- ১১
- ২৭
- ৩০
- ৫৯
(মাঝারি) 10.0.37.200/22 ঠিকানাটি কোন range-এ পড়ে?
- 10.0.37.0 – 10.0.37.255
- 10.0.32.0 – 10.0.39.255
- 10.0.37.0 – 10.0.40.255
- 10.0.36.0 – 10.0.39.255
(সহজ) ৩০টি VPC-র full mesh peering-এ কয়টি link লাগে?
- ৪৩৫
- ৮৭০
- ৩০
- ৯০০
(মাঝারি) Health check interval ১০ s, পরপর ৩টি ব্যর্থতায় unhealthy, DNS TTL ৩০ s, app-এর আলাদা cache নেই। সবচেয়ে খারাপ failover সময় প্রায় কত?
- ৩০ s
- ৪০ s
- ৬০ s
- ৯০ s
(মাঝারি) CDN-এর hit ratio ৯৫% থেকে ৯৯% হলো। মোট অনুরোধ একই থাকলে origin-এর অনুরোধ কতটা হলো?
- মাত্র ৪ শতাংশ কমল
- পাঁচ ভাগের এক ভাগ হলো
- ঠিক অর্ধেক হয়ে গেল
- আগের মতোই থাকল
৫ · Secret আর container image
ঝালিয়ে নিন: পর্ব ৩৩ · Secret আর KMS, পর্ব ৩৭ · Docker image, পর্ব ৩৮ · ভালো Dockerfile.
KMS বিল = call ÷ ১০,০০০ × দর। Data key cache থাকলে call/s = instance ÷ cache-এর মেয়াদ। এক key ঢাকে = প্রতি instance-এর object/s × মেয়াদ (envelope encryption).
Image: আকার = সব layer-এর যোগ; মুছে ফেলা ফাইলও আগের layer-এ থেকে যায়। Pull time = আকার × compression × ৮ ÷ Mbps. Multi-stage-এ শুধু শেষ stage-এর layer থাকে।
৫.১(মাঝারি) সেকেন্ডে ২০০টি object encrypt হয়, ২৫টি instance-এ সমান ভাগে, দিনরাত ৩০ দিন। (ক) প্রতি object-এ একটি KMS call হলে বিল কত? (খ) ২ মিনিটের data key cache-এ বিল কত? (গ) তখন এক key কয়টি object ঢাকে? (ঝালিয়ে নিন: পর্ব ৩৩)
(a) 200 x 2,592,000 = 518,400,000 calls
518,400,000 / 10,000 = 51,840; x 0.03 = 1,555.20
(b) calls = 25 x 2,592,000 / 120 = 540,000
54 x 0.03 = 1.62
(c) 200 / 25 = 8 per instance; 8 x 120 = 960 objectsবিল ৯৬০ ভাগের এক ভাগ, আর এক key-এর ঢাকা object-এর সংখ্যাও ৯৬০. এটি কাকতাল নয়: call কমার অনুপাতই এক key-এর ব্যবহার। (ক) $১,৫৫৫.২০. (খ) $১.৬২. (গ) ৯৬০টি।
৫.২(কঠিন) ৪০টি instance, প্রতিটি নিজের data key cache করে। KMS বিল মাসে $২-এর মধ্যে রাখতে cache-এর মেয়াদ কমপক্ষে কত? মোট ১,০০০ object/s আর মেয়াদ ৩ মিনিট হলে এক key কয়টি object ঢাকে, বিল কত? (ঝালিয়ে নিন: পর্ব ৩৩)
bill = 40 x 2,592,000 / TTL / 10,000 x 0.03 = 311.04 / TTL
311.04 / TTL <= 2 -> TTL >= 155.52 s
TTL = 180 s: bill = 311.04 / 180 = 1.73
per instance = 1,000 / 40 = 25 objects/s
one key = 25 x 180 = 4,500 objectsবেশি মেয়াদে বিল কমে, কিন্তু plain key memory-তে বেশিক্ষণ থাকে, আর এক key ফাঁস হলে বেশি object ঝুঁকিতে পড়ে। কমপক্ষে প্রায় ১৫৬ s; ৩ মিনিটে ৪,৫০০ object, বিল প্রায় $১.৭৩.
৫.৩(মাঝারি) Base ১২০ MB. (ক) তিনটি আলাদা RUN: ২৫০ MB-র archive নামানো, খুলে ৩০ MB ফাইল বসানো, archive মোছা। Image-এ কত MB জমা থাকে, ভেতরে দেখা যায় কত, নষ্ট কত? (খ) সব এক RUN-এ করলে? (গ) দিনে ২০ build, dependency install ৯০ s, বাকি কাজ ২ s, dependency বদলায় ১০% build-এ। Build cache ঠিকমতো কাজে লাগালে আর COPY . . আগে দিলে দিনে কত মিনিট? (ঝালিয়ে নিন: পর্ব ৩৭, ৩৮)
(a) stored = 120 + 250 + 30 + 0 = 400 MB
visible = 120 + 30 = 150 MB; wasted = 250 MB
(b) stored = 120 + 30 = 150 MB, wasted 0
(c) deps first: 0.1 x 90 + 2 = 11 s; 20 x 11 = 220 s = 3.67 min
code first: 90 + 2 = 92 s; 20 x 92 = 1,840 s = 30.67 minLayer শুধু যোগ হয়, পরের layer আগেরটিকে ছোট করতে পারে না। আর code-এর এক অক্ষর বদলালে তার পরের সব layer আবার বানাতে হয়, তাই যা কম বদলায় তা আগে। (ক) ৪০০, ১৫০, ২৫০ MB. (খ) ১৫০ MB. (গ) ৩.৬৭ মিনিট বনাম ৩০.৬৭ মিনিট।
৫.৪(মাঝারি) এক stage-এর image: base ১২০, build tool ৩০০, source ৫, binary ১৫ MB. Multi-stage-এ শেষে থাকে base ২০ আর binary ১৫ MB. Compression ০.৫, লাইন ৪০ Mbps. প্রতিটির pull time? ১০টি server-এ মাসে ২০ বার deploy হলে (প্রতিবার পুরো image নামে ধরে) মাসে কত GB? (ঝালিয়ে নিন: পর্ব ৩৮)
fat = 120 + 300 + 5 + 15 = 440 MB -> wire 220 MB
slim = 20 + 15 = 35 MB -> wire 17.5 MB
pull fat = 220 x 8 / 40 = 44 s
pull slim = 17.5 x 8 / 40 = 3.5 s
pulls = 10 x 20 = 200
month fat = 220 x 200 = 44,000 MB = 44 GB
month slim = 17.5 x 200 = 3,500 MB = 3.5 GB
reduction = 1 - 35/440 = 92.0%বাস্তবে node-এ আগের layer থাকলে শুধু বদলানো layer নামে, তাই আসল সংখ্যা কম হবে। ৪৪ s বনাম ৩.৫ s; মাসে ৪৪ GB বনাম ৩.৫ GB; আকার ৯২% কম।
// KMS call cost, image layers, pull time and build-cache order. ASSUMED numbers.
const usd = (x) => "$" + x.toFixed(2), SEC = 2592000, PER = 0.03 / 10000;
const kms = (callsPerSec) => callsPerSec * SEC * PER;
console.log("no cache, 200 obj/s ", usd(kms(200)), 200 * SEC, "calls");
console.log("25 instances, 120 s ", usd(kms(25 / 120)), 25 / 120 * SEC, "calls");
console.log("40 instances, budget $2: TTL >=", (40 * SEC * PER / 2).toFixed(2), "s");
const stored = (layers) => layers.reduce((s, x) => s + x, 0);
console.log("three RUN lines: stored", stored([120, 250, 30, 0]), "MB, visible 150 MB");
console.log("one RUN line: stored", stored([120, 30]), "MB");
const pull = (mb, ratio, mbps) => mb * ratio * 8 / mbps;
const fat = 120 + 300 + 5 + 15, slim = 20 + 15;
for (const [name, mb] of [["fat", fat], ["slim", slim]])
console.log(name, mb, "MB, wire", mb * 0.5, "MB, pull", pull(mb, 0.5, 40), "s,",
"monthly", mb * 0.5 * 200 / 1000, "GB");
console.log("reduction", (100 * (1 - slim / fat)).toFixed(1) + "%");
const avgBuild = (depsChange) => depsChange * 90 + 2;
console.log("deps first:", avgBuild(0.1), "s per build,", (20 * avgBuild(0.1) / 60).toFixed(2), "min/day");
console.log("code first:", avgBuild(1), "s per build,", (20 * avgBuild(1) / 60).toFixed(2), "min/day");আউটপুট:
no cache, 200 obj/s $1555.20 518400000 calls
25 instances, 120 s $1.62 540000 calls
40 instances, budget $2: TTL >= 155.52 s
three RUN lines: stored 400 MB, visible 150 MB
one RUN line: stored 150 MB
fat 440 MB, wire 220 MB, pull 44 s, monthly 44 GB
slim 35 MB, wire 17.5 MB, pull 3.5 s, monthly 3.5 GB
reduction 92.0%
deps first: 11 s per build, 3.67 min/day
code first: 92 s per build, 30.67 min/dayপ্রথম তিন লাইন ৫.১ আর ৫.২, তারপর ৫.৩ আর ৫.৪. 25 / 120 মানে সারা system-এ সেকেন্ডে কতবার key নবায়ন হয়।
(মাঝারি) KMS-এর অনুমিত দাম প্রতি ১০,০০০ call-এ $০.০৩. সেকেন্ডে ৫০টি object, প্রতিটিতে একটি call, ৩০ দিন দিনরাত। বিল কত?
- $১২.৯৬
- $৩.৮৯
- $১,২৯৬
- $৩৮৮.৮০
(মাঝারি) Base layer ১০০ MB. একটি RUN ২০০ MB ফাইল যোগ করল, পরের RUN সেটি মুছল। শেষ image-এ কত MB জমা থাকে, আর container-এর ভেতরে দেখা যায় কত?
- ৩০০ MB জমা, ১০০ MB দেখা যায়
- ১০০ MB জমা, ১০০ MB দেখা যায়
- ৩০০ MB জমা, ৩০০ MB দেখা যায়
- ২০০ MB জমা, ০ MB দেখা যায়
(সহজ) ১০০ MB-র image, compression ০.৫, লাইন ২০ Mbps. Pull time প্রায় কত?
- ২.৫ s
- ৪০ s
- ২০ s
- ৮০ s
৬ · Kubernetes আর autoscaling
Rolling update: শতাংশে maxSurge ওপরে, maxUnavailable নিচে round হয়। সর্বোচ্চ Pod = R + surge; সর্বনিম্ন available = R − unavail; সময় ≈ ⌈R ÷ (surge + unavail)⌉ × (ready + minReady).
Scheduler দেখে শুধু request, আসল ব্যবহার নয়। QoS: সব container-এ CPU ও memory-র request = limit হলে Guaranteed; কিছুই না থাকলে BestEffort; বাকি Burstable.
HPA ও target tracking: desired = ⌈current × metric ÷ target⌉, তারপর min ও max-এ আটকানো। অনুপাত ১ থেকে ১০%-এর মধ্যে থাকলে HPA কিছু করে না (tolerance). CPU-র শতাংশ মাপা হয় request-এর ওপর।
৬.১(সহজ) maxSurge আর maxUnavailable দুটোই শতাংশে দেওয়া। R = ১০ (২৫%), R = ৭ (৩০%), R = ৩ (২৫%): প্রতিটিতে সর্বোচ্চ Pod আর সর্বনিম্ন available কত? (ঝালিয়ে নিন: পর্ব ৪৪)
R=10, 25%: surge ceil(2.5)=3, unavail floor(2.5)=2 -> max 13, min 8
R=7, 30%: surge ceil(2.1)=3, unavail floor(2.1)=2 -> max 10, min 5
R=3, 25%: surge ceil(0.75)=1, unavail floor(0.75)=0 -> max 4, min 3দুই দিকের rounding এমন, যাতে সেবা নিরাপদ দিকে থাকে। ছোট Deployment-এ unavail ০ হতে পারে, তখন নতুন Pod আগে ওঠে। ১৩/৮, ১০/৫, ৪/৩.
৬.২(মাঝারি) (ক) R = ১২, surge ২, unavail ১, Ready হতে ৮ s, minReadySeconds ১২: rollout-এর সময় কত? (খ) প্রতি Pod-এর CPU request 500m, প্রতি node-এ ২ CPU. surge ৩, unavail ০ হলে আর surge ০, unavail ৩ হলে কয়টি node লাগে, আর দ্বিতীয় পথে সবচেয়ে কম ক্ষমতা কত? (ঝালিয়ে নিন: পর্ব ৪৪)
(a) batches = ceil(12 / (2 + 1)) = 4
T = 4 x (8 + 12) = 80 s
(b) 4 pods fit per node (2 / 0.5)
surge 3: 15 pods -> ceil(15 / 4) = 4 nodes
unavail 3: 12 pods -> 3 nodes; lowest 9 of 12 = 75%দুটি পথের দাম দুই রকম: surge-এ বাড়তি node, unavail-এ কম ক্ষমতা। (ক) প্রায় ৮০ s. (খ) ৪টি বনাম ৩টি node; সর্বনিম্ন ৭৫% ক্ষমতা।
৬.৩(মাঝারি) একটি node-এর allocatable ৩.৭৫ CPU, ৭.৫ GiB. চলমান Pod-গুলোর request-এর যোগ ২.৫ CPU, ৫ GiB, আসল ব্যবহার মাত্র ১ CPU. (ক) Pod A (request 1200m, 2Gi) বসবে? (খ) তারপর Pod B (request 200m, 1Gi)? (গ) ৪০টি Pod (250m, 512Mi) ২ CPU, ৮ GiB allocatable-এর node-এ কয়টি node নেবে? (ঝালিয়ে নিন: পর্ব ৪৮)
free = 3.75 - 2.5 = 1.25 CPU; 7.5 - 5 = 2.5 GiB
(a) 1.2 <= 1.25 and 2 <= 2.5 -> fits
(b) free now 0.05 CPU, 0.5 GiB
0.2 > 0.05 -> Pending, Insufficient cpu
(c) per node: CPU 2 / 0.25 = 8; memory 8192 / 512 = 16 -> 8
nodes = ceil(40 / 8) = 5আসল ব্যবহার ১ CPU হলেও B বসে না, কারণ scheduler খাতার request দেখে। (ক) বসবে। (খ) বসবে না। (গ) ৫টি node, CPU-ই সীমা।
৬.৪(সহজ) HPA, tolerance ০.১. (ক) ৩টি Pod ৯০%, লক্ষ্য ৬০%. (খ) ১০টি Pod ৩০%, লক্ষ্য ৬০%. (গ) ৪টি Pod ৬৩%, লক্ষ্য ৬০%. (ঘ) ৪টি Pod ৭০%, লক্ষ্য ৬০%. প্রতিটিতে desired কত? (ঝালিয়ে নিন: পর্ব ৪৮)
(a) 90/60 = 1.50; ceil(3 x 1.50) = ceil(4.5) = 5
(b) 30/60 = 0.50; ceil(10 x 0.50) = 5
(c) 63/60 = 1.05; |1.05 - 1| <= 0.1 -> no change, 4
(d) 70/60 = 1.17; ceil(4 x 1.17) = ceil(4.67) = 5৫, ৫, ৪, ৫. (গ)-তে tolerance না থাকলে সূত্র দিত ৫, আর সামান্য ওঠানামায় Pod বারবার বদলাত।
৬.৫(মাঝারি) ৪টি Pod, CPU request 200m, প্রতিটি গড়ে 150m ব্যবহার করছে, লক্ষ্য ৫০%, maxReplicas ৫. (ক) Utilisation কত? (খ) Desired কত? (গ) Request 300m করলে (ব্যবহার একই) কী হয়? (ঝালিয়ে নিন: পর্ব ৪৮)
(a) 150 / 200 = 75%
(b) ceil(4 x 75 / 50) = ceil(6) = 6, clamped to max 5
(c) 150 / 300 = 50% -> ratio 1 -> stays at 4একই ব্যবহার, শুধু request বদলাতেই সিদ্ধান্ত বদলে গেল। এজন্য request ঠিক না রেখে HPA-র শতাংশ পড়া যায় না। (ক) ৭৫%. (খ) ৫ (সূত্রে ৬, max আটকায়)। (গ) ৪.
৬.৬(কঠিন) ৬টি instance, min ৪, max ৩০, লক্ষ্য ৬০% (১ instance = ১০০ req/s = ১০০%). চাহিদা হঠাৎ ১,৮০০ req/s. Metric ১০০%-এর ওপরে উঠতে পারে না। প্রতিটি নতুন instance ওঠার পর একবার করে হিসাব হলে কত ধাপে স্থির হবে? (ঝালিয়ে নিন: পর্ব ১৭)
round 1: load min(100, 1800/6 = 300) = 100; ceil(6 x 100/60) = 10
round 2: load min(100, 180) = 100; ceil(10 x 100/60) = 17
round 3: load min(100, 105.9) = 100; ceil(17 x 100/60) = 29
round 4: load 1800/29 = 62.07; ceil(29 x 62.07/60) = 30
round 5: load 60.0; ceil(30 x 60/60) = 30 stableMetric ১০০-তে আটকে থাকে বলে আসল চাহিদা দেখা যায় না, তাই একবারে ৩০-এ যাওয়া সম্ভব হয় না, প্রতি ধাপে ৫/৩ গুণ করে বাড়ে। ৬ → ১০ → ১৭ → ২৯ → ৩০; চার ধাপে ৩০, পঞ্চম হিসাবে স্থির। Requests per target-এর মতো metric হলে এক ধাপেই ৩০ পাওয়া যেত, কারণ সেটি আটকে থাকে না।
৬.৭(কঠিন) (ক) Group-এর max ৪০, vCPU quota ১৬০, instance ৪ vCPU-র; প্রতিটি instance ২৫টি DB connection নেয়, DB-র সীমা ৮০০. আসল max কত? (খ) ৩ AZ-এ লক্ষ্য ৬০%: একটি AZ গেলে বাকিরা কত? ৪ AZ-এ? (গ) চাহিদা মিনিটে ৫% বাড়ে, instance উঠতে ৪ মিনিট লাগে: headroom-সহ লক্ষ্য সর্বোচ্চ কত? ৩ AZ-এ একটি হারিয়েও ১০০% না ছাড়াতে? (ঘ) ৯০,০০০ job-এর সারি, প্রতি worker সেকেন্ডে ২০টি, ৫ মিনিটে শেষ চাই: কয়টি worker? (ঝালিয়ে নিন: পর্ব ১৭)
(a) min(40, 160/4 = 40, 800/25 = 32) = 32
(b) 60 x 3/2 = 90%; 60 x 4/3 = 80%
(c) target <= 100 / 1.05^4 = 82.3%
with zone loss: 82.3 x 2/3 = 54.8%
(d) per worker in 300 s: 20 x 300 = 6,000
ceil(90,000 / 6,000) = 15(গ)-তে দুই বিপদ একসাথে ধরা হয়েছে: ঢেউ আর zone হারানো। (ক) ৩২. (খ) ৯০% আর ৮০%. (গ) ৮২.৩%; zone-সহ ৫৪.৮%. (ঘ) ১৫টি।
// Rolling update: percent rounding, walls, duration and node count.
const count = (v, R, up) => {
if (typeof v === "number") return v;
const x = R * parseInt(v) / 100;
return up ? Math.ceil(x) : Math.floor(x);
};
function walls(R, surge, unavail) {
const s = count(surge, R, true), u = count(unavail, R, false);
return { R, surge: s, unavail: u, maxPods: R + s, minAvail: R - u };
}
for (const [R, s, u] of [[10, "25%", "25%"], [7, "30%", "30%"], [3, "25%", "25%"], [1, "25%", "25%"]])
console.log(JSON.stringify(walls(R, s, u)));
const duration = (R, s, u, ready, minReady) => Math.ceil(R / (s + u)) * (ready + minReady);
console.log("T =", duration(12, 2, 1, 8, 12), "s");
const nodes = (pods, cpu, nodeCpu) => Math.ceil(pods / Math.floor(nodeCpu / cpu));
console.log("surge 3:", nodes(15, 0.5, 2), "nodes; unavailable 3:", nodes(12, 0.5, 2),
"nodes, capacity", (100 * 9 / 12) + "%");
const perNode = Math.min(Math.floor(2 / 0.25), Math.floor(8192 / 512));
console.log("per node", perNode, "nodes", Math.ceil(40 / perNode));আউটপুট:
{"R":10,"surge":3,"unavail":2,"maxPods":13,"minAvail":8}
{"R":7,"surge":3,"unavail":2,"maxPods":10,"minAvail":5}
{"R":3,"surge":1,"unavail":0,"maxPods":4,"minAvail":3}
{"R":1,"surge":1,"unavail":0,"maxPods":2,"minAvail":1}
T = 80 s
surge 3: 4 nodes; unavailable 3: 3 nodes, capacity 75%
per node 8 nodes 5চতুর্থ সারিতে R = ১: surge ১, unavail ০, তাই একটি মাত্র Pod-এর Deployment-ও নতুন Pod ওঠার আগে পুরোনোটি সরায় না। এরপর ৬.২ আর ৬.৩-এর উত্তর।
// HPA and target tracking: ceil(current x metric / target), tolerance, clamp.
function hpa(n, m, t, min = 1, max = 100, tol = 0.1) {
const r = m / t;
if (Math.abs(r - 1) <= tol) return n; // inside the tolerance
return Math.min(max, Math.max(min, Math.ceil(n * r - 1e-9)));
}
for (const [n, m, t] of [[3, 90, 60], [10, 30, 60], [4, 63, 60], [4, 70, 60]])
console.log(`${n} pods at ${m}% target ${t}% -> ${hpa(n, m, t)}`);
console.log("request 200m, using 150m:", 150 / 200 * 100 + "%", "->", hpa(4, 75, 50));
console.log("same, max 5 ->", hpa(4, 75, 50, 1, 5));
// Target tracking when the metric is stuck at 100 until capacity arrives
let n = 6; const demand = 1800, trail = [n];
for (let i = 0; i < 5; i++) {
const load = Math.min(100, demand / n);
n = Math.min(30, Math.max(4, Math.ceil(n * load / 60 - 1e-9)));
trail.push(n);
}
console.log("rounds:", trail.join(" -> "), " final load", (demand / n).toFixed(0));
console.log("real max", Math.min(40, Math.floor(160 / 4), Math.floor(800 / 25)));
const survivors = (u, z) => (u * z / (z - 1)).toFixed(1);
console.log("lose 1 of 3 at 60%:", survivors(60, 3), " lose 1 of 4:", survivors(60, 4));
const boot = 100 / 1.05 ** 4;
console.log("boot limit", boot.toFixed(1), " with zone loss", (boot * 2 / 3).toFixed(1));
console.log("workers", Math.ceil(90000 / (20 * 300)));আউটপুট:
3 pods at 90% target 60% -> 5
10 pods at 30% target 60% -> 5
4 pods at 63% target 60% -> 4
4 pods at 70% target 60% -> 5
request 200m, using 150m: 75% -> 6
same, max 5 -> 5
rounds: 6 -> 10 -> 17 -> 29 -> 30 -> 30 final load 60
real max 32
lose 1 of 3 at 60%: 90.0 lose 1 of 4: 80.0
boot limit 82.3 with zone loss 54.8
workers 15- 1e-9 অংশটি দশমিকের ক্ষুদ্র ভুল ঠেকায়, নইলে পূর্ণসংখ্যার ফল এক বেশি হতে পারত। এটি শুধু এই ক্যালকুলেটরের কৌশল। শেষ পাঁচ লাইন ৬.৬ আর ৬.৭.
(সহজ) replicas ৮, maxSurge আর maxUnavailable দুটোই ২৫%. Rollout-এর সময় সর্বোচ্চ Pod আর সর্বনিম্ন available কত?
- ১০ আর ৬
- ৯ আর ৭
- ১২ আর ৪
- ১০ আর ৮
(মাঝারি) replicas ৫, maxSurge ২৫%, maxUnavailable ২৫%. সর্বোচ্চ Pod আর সর্বনিম্ন available কত?
- ৬ আর ৪
- ৭ আর ৩
- ৭ আর ৪
- ৬ আর ৩
(মাঝারি) HPA-তে ১০টি Pod, CPU ৫৭%, লক্ষ্য ৬০%, tolerance ০.১. Desired কত?
- ৯
- ১০
- ১১
- ৬
(মাঝারি) একটি Pod-এর একমাত্র container-এ CPU request 100m, limit 100m; memory request 128Mi, limit 256Mi. QoS class কী?
- Guaranteed
- BestEffort
- Critical
- Burstable
৭ · Serverless — GB-second আর concurrency
ঝালিয়ে নিন: পর্ব ৬৯ · Serverless function, পর্ব ১৯ · কোন compute কখন.
FaaS বিল = call × call-এর দাম + call × memory (GB) × সময় (s) × GB-second-এর দাম। Concurrency = rate × duration; reserved concurrency C হলে সর্বোচ্চ rate = C ÷ duration.
৭.১(মাঝারি) মাসে ২ কোটি call. তিনটি memory-তে মাপা সময়: ১ GB-তে ০.৩ s, ০.৫ GB-তে ০.৫ s, ০.২৫ GB-তে ১.৪ s. প্রতিটির বিল কত? কোনটি সস্তা? (ঝালিয়ে নিন: পর্ব ৬৯)
call fee = 20 x 0.20 = 4
1 GB : 20e6 x 1 x 0.3 = 6,000,000 GB-s -> 120 + 4 = 124
0.5 GB : 20e6 x 0.5 x 0.5 = 5,000,000 GB-s -> 100 + 4 = 104
0.25 GB: 20e6 x 0.25 x 1.4 = 7,000,000 GB-s -> 140 + 4 = 144Memory বাড়ালে CPU-ও বাড়ে, তাই সময় কমে। সবচেয়ে ছোট memory সবচেয়ে সস্তা হবে, এমন নিয়ম নেই; মেপে ঠিক করতে হয়। $১২৪, $১০৪, $১৪৪; ০.৫ GB সবচেয়ে সস্তা।
৭.২(মাঝারি) গড়ে ১২০ req/s, প্রতিটি ০.২৫ s; peak-এ ৮০০ req/s, ধীর database-এ প্রতিটি ০.৫ s. (ক) গড় আর peak concurrency? (খ) Database-এর ৩০০ connection রক্ষায় reserved concurrency ৩০০ করলে সর্বোচ্চ কত req/s চলে, peak-এ কত throttle হয়? (ঝালিয়ে নিন: পর্ব ৬৯)
(a) 120 x 0.25 = 30; 800 x 0.5 = 400
(b) max rate = 300 / 0.5 = 600 req/s
throttled = 800 - 600 = 200 req/sPeak-এ চাপ ৬.৭ গুণ, কিন্তু concurrency ১৩ গুণ বেড়েছে, কারণ duration-ও দ্বিগুণ। (ক) ৩০ আর ৪০০. (খ) ৬০০ req/s, ২০০ req/s throttle.
৭.৩(কঠিন) ০.৫ GB, ০.১২ s-এর function বনাম একটি VM, ঘণ্টায় $০.১০ (ধরুন VM-টি পুরো চাপ নিতে পারে)। কত call/মাসে দুটির খরচ সমান? সেটি গড়ে কত req/s? (ঝালিয়ে নিন: পর্ব ১৯, ৬৯)
per million = 0.20 + 1e6 x 0.5 x 0.12 x 0.00002 = 0.20 + 1.20 = 1.40
VM = 0.10 x 720 = 72
break-even = 72 / 1.40 = 51.4 million calls/month
rate = 51.4e6 / 2,592,000 = 19.8 req/sগড়ে ২০ req/s-এর নিচে FaaS সস্তা, ওপরে VM. একটি VM-এ redundancy নেই; দুটি রাখলে সীমা দ্বিগুণ। এই হিসাবে দলের সময়ও ধরা হয়নি। প্রায় ৫.১৪ কোটি call, গড়ে প্রায় ১৯.৮ req/s.
// FaaS bill and concurrency. Prices ASSUMED: $0.20 per million, $0.00002 per GB-second.
const usd = (x) => "$" + x.toFixed(2);
function bill(calls, gb, sec) {
const gbs = calls * gb * sec;
return { gbs, compute: gbs * 0.00002, fee: calls / 1e6 * 0.2, total: gbs * 0.00002 + calls / 1e6 * 0.2 };
}
for (const [gb, sec] of [[1, 0.3], [0.5, 0.5], [0.25, 1.4]]) {
const b = bill(20e6, gb, sec);
console.log(`${gb} GB ${sec} s: ${b.gbs} GB-s, compute ${usd(b.compute)}, total ${usd(b.total)}`);
}
const conc = (rate, sec) => rate * sec;
console.log("avg", conc(120, 0.25), "peak", conc(800, 0.5));
console.log("max rate under 300 reserved:", 300 / 0.5, "req/s; throttled at peak:", 800 - 300 / 0.5);
const perM = bill(1e6, 0.5, 0.12).total, vm = 0.1 * 720;
console.log("per million", usd(perM), "VM", usd(vm));
const be = vm / perM;
console.log("break-even", be.toFixed(1), "million calls =", (be * 1e6 / 2592000).toFixed(1), "req/s");আউটপুট:
1 GB 0.3 s: 6000000 GB-s, compute $120.00, total $124.00
0.5 GB 0.5 s: 5000000 GB-s, compute $100.00, total $104.00
0.25 GB 1.4 s: 7000000 GB-s, compute $140.00, total $144.00
avg 30 peak 400
max rate under 300 reserved: 600 req/s; throttled at peak: 200
per million $1.40 VM $72.00
break-even 51.4 million calls = 19.8 req/sওপরের তিন লাইন ৭.১, মাঝের দুই লাইন ৭.২, শেষের দুই লাইন ৭.৩. bill()-এ নিজের মাপা memory আর সময় বসান, আন্দাজের সময় নয়।
(সহজ) মাসে ১ কোটি call, ০.৫ GB, প্রতিটি ০.২ s. দর: প্রতি মিলিয়নে $০.২০, প্রতি GB-second-এ $০.০০০০২. মোট বিল কত?
- $২
- $২০
- $২২
- $৪২
(সহজ) সেকেন্ডে ২৫০টি call, প্রতিটি ০.২ s. গড় concurrency কত?
- ১,২৫০
- ২৫০
- ৫
- ৫০
৮ · Observability, SLO আর capacity
ঝালিয়ে নিন: পর্ব ৬৩ · Metric আর Prometheus, পর্ব ৬৬ · Alerting আর SLO, পর্ব ৬৭ · Incident management, পর্ব ৬৮ · Reliability প্রকৌশল.
rate() = জানালায় বৃদ্ধি ÷ সেকেন্ড, counter reset সামলে। histogram_quantile: rank = q × মোট; ফল ≈ lower + (upper − lower) × (rank − below) ÷ in_bucket; bucket cumulative.
Error budget = ১ − SLO. Burn rate = error rate ÷ (১ − SLO); খরচ হওয়া budget = burn rate × জানালা ÷ ৭২০ ঘণ্টা; burn = খরচ × ৭২০ ÷ জানালা।
Little: L = λW. M/M/1: ρ = λS, W = S ÷ (১ − ρ)। MTBF = (সময়কাল − মোট downtime) ÷ ঘটনা। Capacity: plan = peak × বৃদ্ধি × ঘটনা × margin; zone-প্রতি = ⌈plan ÷ (z − ১) ÷ নিরাপদ ক্ষমতা⌉ (N+1).
৮.১(মাঝারি) (ক) একটি counter ৫ মিনিটে ১,০০০ থেকে ১,৬০০ হলো, rate কত? (খ) ৬০ s পরপর sample: ১০০, ১৬০, ৩০, ৯০ (মাঝে app restart). সরল বিয়োগ, সঠিক বৃদ্ধি আর গড় rate কত? (প্রান্তের extrapolation বাদ দিন) (গ) Instance A ১০০ req/s-এ ১% error, B ৯০০ req/s-এ ০.১% error: মোট error ratio কত? (ঝালিয়ে নিন: পর্ব ৬৩)
(a) (1600 - 1000) / 300 = 2 req/s
(b) naive = 90 - 100 = -10
steps: +60, reset -> +30, +60 = 150
rate = 150 / 180 = 0.833/s
(c) errors = 100 x 0.01 + 900 x 0.001 = 1.9/s
ratio = 1.9 / 1000 = 0.19%(খ)-তে নেমে যাওয়া মানে counter শূন্য থেকে আবার শুরু, তাই নতুন মানটুকুই বৃদ্ধি। আসল rate() জানালার প্রান্ত পর্যন্ত অনুমান করে, তাই সামান্য আলাদা মান দেখাতে পারে। (গ)-তে দুই ratio-র গড় ০.৫৫% হলে ভুল: আগে হারগুলো যোগ, তারপর ভাগ। (ক) ২ req/s. (খ) −১০, ১৫০, প্রায় ০.৮৩৩/s. (গ) ০.১৯%.
৮.২(মাঝারি) Cumulative histogram: le=0.05: ৮০০, le=0.1: ১,৪০০, le=0.25: ১,৮০০, le=0.5: ১,৯৬০, le=1: ২,০০০, +Inf: ২,০০০. p50, p90, p95 আর p99 কত? (ঝালিয়ে নিন: পর্ব ৬৩)
p50: rank 1000, bucket (0.05, 0.1], below 800, in 600
0.05 + 0.05 x 200/600 = 0.0667 s
p90: rank 1800 = exactly le=0.25 -> 0.25 s
p95: rank 1900, bucket (0.25, 0.5], below 1800, in 160
0.25 + 0.25 x 100/160 = 0.40625 s
p99: rank 1980, bucket (0.5, 1], below 1960, in 40
0.5 + 0.5 x 20/40 = 0.75 sখোপের ভেতরে মান সমানভাবে ছড়ানো ধরা হয়, তাই এগুলো আন্দাজ। খোপ যত মোটা, আন্দাজ তত দুর্বল। Prometheus-এর নথি অনুযায়ী quantile যদি +Inf খোপে পড়ে, ফল হয় শেষ সসীম সীমা। ৬৬.৭ ms, ২৫০ ms, প্রায় ৪০৬ ms, ৭৫০ ms.
// rate with a counter reset, ratio of sums, histogram_quantile by interpolation.
function increase(samples) {
let inc = 0;
for (let i = 1; i < samples.length; i++) {
const d = samples[i] - samples[i - 1];
inc += d >= 0 ? d : samples[i]; // a drop means the counter restarted
}
return inc;
}
const s = [100, 160, 30, 90], span = 180;
console.log("naive", s.at(-1) - s[0], "increase", increase(s), "rate", (increase(s) / span).toFixed(3));
const buckets = [[0.05, 800], [0.1, 1400], [0.25, 1800], [0.5, 1960], [1, 2000], [Infinity, 2000]];
function quantile(q) {
const rank = q * buckets.at(-1)[1]; let lo = 0, below = 0;
for (const [le, c] of buckets) {
if (c >= rank) {
if (le === Infinity) return lo; // lands in +Inf: highest finite bound
return lo + (le - lo) * (rank - below) / (c - below);
}
lo = le; below = c;
}
}
for (const q of [0.5, 0.9, 0.95, 0.99]) console.log("q", q, "->", quantile(q).toFixed(4), "s");
const ratio = (100 * 0.01 + 900 * 0.001) / (100 + 900);
console.log("true error ratio", (ratio * 100).toFixed(2) + "%, average of ratios 0.55%");আউটপুট:
naive -10 increase 150 rate 0.833
q 0.5 -> 0.0667 s
q 0.9 -> 0.2500 s
q 0.95 -> 0.4063 s
q 0.99 -> 0.7500 s
true error ratio 0.19%, average of ratios 0.55%এই ফাংশনগুলো Prometheus-এর হিসাবের সরল রূপ, শেখার জন্য। প্রথম লাইন ৮.১(খ), পরের চারটি ৮.২, শেষ লাইন ৮.১(গ). buckets বদলে দেখুন, খোপ মোটা হলে p95 কতটা সরে।
SLO = 99.9% period = 720 h
budget = 1 - 0.999 = 0.1%
rule: page if 2% of budget
goes in 1 h
short window: 5 min
burn = spend x period / window
= 0.02 x 720 / 1
= 14.4
error > burn x (1 - SLO)
= 14.4 x 0.001
= 1.44%
1 h error 2.00% -> burn 20 > 14.4
5 min error 2.00% -> burn 20 > 14.4
both true -> page
spend in 1 h = 20 x 1 / 720 = 2.78% empty in 720 / 20 = 36 h
1 h error 2.00% -> still high
5 min error 0.05% -> burn 0.5
one is false -> alert clears
- তথ্য। ৩০ দিনে ৭২০ ঘণ্টা, budget ০.১%. নিয়ম: এক ঘণ্টায় মাসের budget-এর ২% গেলে কাউকে ডাকা হবে।
- Burn-এর সীমা। সূত্র উল্টে নিলে ০.০২ × ৭২০ ÷ ১ = ১৪.৪. Workbook-এর চেনা সংখ্যাটি এখান থেকেই আসে।
- Error-এর সীমা। ১৪.৪ × ০.০০১ = ০.০১৪৪, মানে ১.৪৪%. SLO বদলালে এই সংখ্যাও বদলায়।
- ঘটনা। ১ ঘণ্টা আর ৫ মিনিট, দুই জানালাতেই error ২%, burn ২০. দুটিই সীমা ছাড়িয়েছে, তাই alert বাজে।
- ক্ষতি। এক ঘণ্টায় budget-এর ২.৭৮% গেছে। এই গতিতে চললে ৩৬ ঘণ্টায় সব শেষ।
- সারার পর। বড় জানালা তখনো পুরোনো error মনে রাখে, কিন্তু ছোট জানালায় error ০.০৫%. দুই শর্ত একসাথে না থাকায় alert দ্রুত থেমে যায়, ঘণ্টাখানেক বাজতে থাকে না।
৮.৩(মাঝারি) SLO ৯৯.৯%, মাসে ২ কোটি অনুরোধ। (ক) Budget সময়ে আর অনুরোধে কত? (খ) ১২ ঘণ্টা ধরে error ০.২%: burn rate, খরচ আর পুরো budget ফুরোতে কত সময়? (গ) SLO ৯৯.৯৫%, পূর্ণ বিভ্রাট ৩ মিনিট: budget-এর কত অংশ গেল? (ঝালিয়ে নিন: পর্ব ৬৬)
(a) 0.001 x 43,200 = 43.2 min; 0.001 x 2 crore = 20,000 requests
(b) burn = 0.002 / 0.001 = 2
spent = 2 x 12 / 720 = 3.33%
empty in 720 / 2 = 360 h = 15 days
(c) burn = 1 / 0.0005 = 2,000
spent = 2,000 x 3 / 43,200 = 13.89%(ক) ৪৩.২ মিনিট, ২০,০০০ অনুরোধ। (খ) ২, ৩.৩৩%, ১৫ দিন। (গ) ১৩.৮৯%. মাত্র ৩ মিনিটের পূর্ণ বিভ্রাট বড় ক্ষতি, আর ছোট error অনেকক্ষণ চললেও চোখে পড়ে না। তাই দুই রকম জানালা লাগে।
৮.৪(কঠিন) SLO ৯৯.৯%, ৩০ দিন। Budget-এর ২% ১ ঘণ্টায়, ৫% ৬ ঘণ্টায় আর ১০% ৩ দিনে গেলে alert চাই। তিনটির burn আর error সীমা বের করুন। SLO ৯৯.৯৫% হলে প্রথমটির error সীমা কত? Burn ১৪.৪ চলতে থাকলে পুরো budget কত ঘণ্টায় শেষ? (ঝালিয়ে নিন: পর্ব ৬৬)
burn = spend x 720 / window
2% in 1 h : 0.02 x 720 / 1 = 14.4 -> error 1.44%
5% in 6 h : 0.05 x 720 / 6 = 6 -> error 0.60%
10% in 72 h: 0.10 x 720 / 72 = 1 -> error 0.10%
SLO 99.95%: 14.4 x 0.0005 = 0.72%
empty: 720 / 14.4 = 50 hএই সংখ্যাগুলো Google-এর SRE Workbook-এর সূচনা-বিন্দু, নিজের সেবা অনুযায়ী বদলানো যায়। ১৪.৪/১.৪৪%, ৬/০.৬০%, ১/০.১০%; ০.৭২%; ৫০ ঘণ্টা।
৮.৫(মাঝারি) ৩০ দিনে ৪টি incident. প্রভাব শুরু থেকে ধরা পড়া: ৩, ৯, ৬, ২ মিনিট; ধরা পড়া থেকে স্বীকার: ৫, ৪, ৯, ৬ মিনিট; প্রভাব শুরু থেকে সেবা ফেরা: ২০, ৭৫, ৪১, ২৪ মিনিট। MTTD, MTTA, MTTR, median restore, MTBF আর availability কত? (ঝালিয়ে নিন: পর্ব ৬৭)
MTTD = (3 + 9 + 6 + 2) / 4 = 5 min
MTTA = (5 + 4 + 9 + 6) / 4 = 6 min
MTTR = (20 + 75 + 41 + 24) / 4 = 160 / 4 = 40 min
median of 20, 24, 41, 75 = (24 + 41) / 2 = 32.5 min
MTBF = (43,200 - 160) / 4 = 10,760 min = 179.3 h
A = 10,760 / (10,760 + 40) = 99.630%
check: 1 - 160 / 43,200 = 99.630%একটি লম্বা ঘটনা গড়কে টানে, তাই median-ও লিখুন। MTTR আর MTBF-এর সংজ্ঞা দলভেদে আলাদা, তাই উত্তরে কোন নিয়ম নিলেন বলে দিন। ৫, ৬, ৪০, ৩২.৫ মিনিট; MTBF ১০,৭৬০ মিনিট; A ≈ ৯৯.৬৩০%.
৮.৬(সহজ) Little-এর সূত্র: (ক) ২০০ req/s, গড় ০.২৫ s: ভেতরে গড়ে কয়টি? (খ) ভেতরে ৬০টি, গড় ৫০ ms: throughput কত? (গ) ৩০০ query/s, প্রতিটি ২০ ms: কয়টি connection ব্যস্ত? ৭০% ব্যবহারে রাখতে pool কত? (ঝালিয়ে নিন: পর্ব ৬৮)
(a) L = 200 x 0.25 = 50
(b) lambda = 60 / 0.05 = 1,200 req/s
(c) L = 300 x 0.02 = 6; pool = ceil(6 / 0.7) = ceil(8.57) = 9একক মিলিয়ে নিন: ms-কে সেকেন্ডে আনুন। সূত্রটি স্থির অবস্থায় খাটে। (ক) ৫০. (খ) ১,২০০ req/s. (গ) ৬টি, pool ৯.
৮.৭(মাঝারি) M/M/1 মডেলে সেবার সময় S = ২০ ms. (ক) ρ = ০.৫, ০.৮, ০.৯, ০.৯৫-এ গড় সময় কত? (খ) ০.৮ থেকে ০.৯-এ চাপ কত বাড়ে, সময় কত গুণ? (গ) গড় সময় ৫০ ms-এর মধ্যে রাখতে ρ সর্বোচ্চ কত? ৫০০ req/s সামলাতে এমন কয়টি server, চাপ সমান ভাগে? (ঝালিয়ে নিন: পর্ব ৬৮)
(a) W = 20 / (1 - rho): 40, 100, 200, 400 ms
(b) load: 0.9 / 0.8 = +12.5%; W: 100 -> 200 ms, x 2
(c) 50 = 20 / (1 - rho) -> rho = 0.6
capacity = 1 / 0.02 = 50 req/s; at 0.6 = 30 req/s
servers = ceil(500 / 30) = ceil(16.67) = 17এটিই knee: queueing delay ১ ÷ (১ − ρ) হারে বাড়ে। আসল server M/M/1 নয়, তাই সংখ্যা load test-এ মাপতে হয়, মডেল শুধু আকৃতি দেখায়। (ক) ৪০, ১০০, ২০০, ৪০০ ms. (খ) ১২.৫% চাপে সময় ২ গুণ। (গ) ρ = ০.৬, ১৭টি server.
৮.৮(কঠিন) আজকের peak ৮০০ req/s, ঈদের আগে বৃদ্ধি ২৫%, সেলের গুণক ৩, safety margin ২০%, এক instance নিরাপদে ৭৫ req/s নেয়। (ক) Plan কত req/s? (খ) ৩ zone-এ একটি হারালেও চালাতে হলে মোট কত instance? (গ) ৪ zone-এ? (ঘ) Zone-বিমা ছাড়া কত? (ঝালিয়ে নিন: পর্ব ৬৮)
(a) 800 x 1.25 x 3 = 3,000; x 1.2 = 3,600 req/s
(b) 3,600 / 2 / 75 = 24 per zone; 24 x 3 = 72
(c) 3,600 / 3 / 75 = 16 per zone; 16 x 4 = 64
(d) 3,600 / 75 = 48ছাদ নয়, ছাদের নিচের নিরাপদ মান দিয়ে হিসাব। (ক) ৩,৬০০ req/s. (খ) ৭২. (গ) ৬৪. (ঘ) ৪৮; মানে ৩ zone-এ বিমার দাম ২৪টি বাড়তি instance.
// Error budget, burn rate, MTTx, Little's law, queueing and capacity.
const burn = (err, slo) => err / (1 - slo);
const used = (b, hours) => b * hours / 720;
console.log("budget", ((1 - 0.999) * 43200).toFixed(1), "min,", Math.round(2e7 * (1 - 0.999)), "requests");
console.log("burn", burn(0.002, 0.999).toFixed(2), "used", (100 * used(2, 12)).toFixed(2) + "%", "empty in", 720 / 2, "h");
console.log("outage 3 min, 99.95%:", (100 * burn(1, 0.9995) * 0.05 / 720).toFixed(2) + "%");
for (const [f, h] of [[0.02, 1], [0.05, 6], [0.1, 72]]) {
const b = f * 720 / h;
console.log(`spend ${f * 100}% in ${h} h: burn ${b.toFixed(1)}, error > ${(b * 0.1).toFixed(2)}%`);
}
const mean = (a) => a.reduce((s, x) => s + x, 0) / a.length;
const det = [3, 9, 6, 2], ack = [5, 4, 9, 6], res = [20, 75, 41, 24];
const mtbf = (43200 - res.reduce((s, x) => s + x, 0)) / res.length;
console.log("MTTD", mean(det), "MTTA", mean(ack), "MTTR", mean(res), "MTBF", mtbf,
"A", (100 * mtbf / (mtbf + mean(res))).toFixed(3) + "%");
console.log("L", 200 * 0.25, "lambda", 60 / 0.05, "pool", Math.ceil(300 * 0.02 / 0.7));
for (const r of [0.5, 0.8, 0.9, 0.95, 0.99])
console.log(`rho ${r}: x${(1 / (1 - r)).toFixed(0)}, W ${(20 / (1 - r)).toFixed(0)} ms`);
const plan = 800 * 1.25 * 3 * 1.2;
for (const z of [3, 4]) {
const perZone = Math.ceil(plan / (z - 1) / 75 - 1e-9);
console.log(`plan ${plan.toFixed(0)}, ${z} zones: ${perZone} per zone, ${perZone * z} total`);
}আউটপুট:
budget 43.2 min, 20000 requests
burn 2.00 used 3.33% empty in 360 h
outage 3 min, 99.95%: 13.89%
spend 2% in 1 h: burn 14.4, error > 1.44%
spend 5% in 6 h: burn 6.0, error > 0.60%
spend 10% in 72 h: burn 1.0, error > 0.10%
MTTD 5 MTTA 6 MTTR 40 MTBF 10760 A 99.630%
L 50 lambda 1200 pool 9
rho 0.5: x2, W 40 ms
rho 0.8: x5, W 100 ms
rho 0.9: x10, W 200 ms
rho 0.95: x20, W 400 ms
rho 0.99: x100, W 2000 ms
plan 3600, 3 zones: 24 per zone, 72 total
plan 3600, 4 zones: 16 per zone, 64 totalওপরের ছয় লাইন ৮.৩ আর ৮.৪, তারপর ৮.৫, ৮.৬, ৮.৭ আর ৮.৮. rho-র সারিগুলো দেখুন: ০.৯৫ থেকে ০.৯৯-এ চাপ মাত্র ৪% বাড়ে, সময় ৫ গুণ।
(সহজ) SLO ৯৯.৫%, ৩০ দিন। Error budget কত মিনিট?
- ৪৩.২ মিনিট
- ২১৬ মিনিট
- ৪৩২ মিনিট
- ২১.৬ মিনিট
(মাঝারি) SLO ৯৯.৯%, ৩০ দিন। Error rate ২% এক ঘণ্টা চলল। Burn rate আর budget খরচ কত?
- ২০ আর ২.৭৮%
- ২ আর ০.২৮%
- ১৪.৪ আর ২%
- ২০ আর ২০%
(মাঝারি) Cumulative bucket: le=0.1 → ৯০০, le=0.5 → ১,০০০, +Inf → ১,০০০. Linear interpolation-এ p95 কত?
- ০.৫ s
- ০.১ s
- ০.৩ s
- ০.২৫ s
(সহজ) একটি সেবায় ভেতরে গড়ে ৪০টি অনুরোধ থাকে, throughput ২০০ req/s. গড় সময় কত?
- ৮,০০০ s
- ৫ s
- ০.০২ s
- ০.২ s
(কঠিন) M/M/1, S = ১০ ms. ρ ০.৯ থেকে ০.৯৫ হলে গড় সময়ের কী হয়?
- ৫.৬% বাড়ে
- ১০০ ms থেকে ২০০ ms
- ৯ ms থেকে ৯.৫ ms
- ১০ ms-ই থাকে
৯ · FinOps — commitment, spot আর unit economics
ঝালিয়ে নিন: পর্ব ৭২ · Cloud-এর বিল, পর্ব ৭৩ · FinOps.
অঙ্গীকারের ছাড় d: break-even utilisation U* = ১ − d. Fleet-এ n-তম VM-কে আলাদা দেখুন: সে U*-এর চেয়ে বেশি সময় ব্যস্ত থাকলেই অঙ্গীকারে ঢোকান। Spot-এর খরচ = (কাজ + আবার করা কাজ) × spot দর।
Rightsizing: প্রয়োজন = বর্তমান ক্ষমতা × p95 ÷ লক্ষ্য। Unit cost = বিল ÷ ব্যবসার একক। স্থির অংশ আলাদা করতে দুটি মাসের ঢাল নিন। Showback: shared ভাগ = shared × direct ÷ মোট direct.
৯.১(মাঝারি) একটি VM মাসে ৫০০ ঘণ্টা চলে। On-demand $০.৫০, ১ বছরের অঙ্গীকার $০.৩৫, ৩ বছরের $০.২৫ (দুই অঙ্গীকারেই ৭২০ ঘণ্টার দাম দিতে হয়)। মাসিক খরচ কত? Break-even utilisation-এর সাথে মেলান। (ঝালিয়ে নিন: পর্ব ৭২)
on-demand = 500 x 0.50 = 250
1 year = 720 x 0.35 = 252
3 year = 720 x 0.25 = 180
U = 500 / 720 = 69.4%
U*(30% off) = 70% -> 69.4% is just below: on-demand wins by $2
U*(50% off) = 50% -> 69.4% is above: commitment winsফাঁদ: ছাড় দেখেই অঙ্গীকার কেনা। ব্যবহার সীমার ঠিক নিচে হলে ১ বছরের অঙ্গীকারে লাভ নেই। আর ৩ বছরের সিদ্ধান্তে VM-এর প্রয়োজন, পরিবর্তনের ঝুঁকিও ধরতে হয়। $২৫০, $২৫২, $১৮০.
৯.২(কঠিন) দিনের ৬টি ৪-ঘণ্টার ব্লকে চাহিদা ২, ২, ৪, ৪, ৬, ৪টি VM. মাসে প্রতি ব্লক ১২০ ঘণ্টা। বাকিটা on-demand ($০.৫০), অঙ্গীকার $০.৩৫ (৭২০ ঘণ্টা)। কয়টি VM-এ অঙ্গীকার সবচেয়ে সস্তা? (ঝালিয়ে নিন: পর্ব ৭২)
one committed VM = 720 x 0.35 = 252
commit 0: 22 VM-blocks x 60 = 1,320
commit 1: 252 + 16 x 60 = 1,212
commit 2: 504 + 10 x 60 = 1,104 lowest
commit 3: 756 + 6 x 60 = 1,116
commit 4: 1,008 + 2 x 60 = 1,128
commit 5: 1,260 + 1 x 60 = 1,320(একটি VM-block = ১২০ × $০.৫০ = $৬০.) নিয়ম দিয়ে যাচাই: ২য় VM ৬টি ব্লকেই ব্যস্ত, ১০০%. ৩য় VM ৪টিতে, ৬৬.৭%, যা ৭০%-এর নিচে, তাই বাদ। ২টি VM-এ, মাসে $১,১০৪; সব on-demand-এর চেয়ে $২১৬ কম।
৯.৩(মাঝারি) ২,০০০ VM-ঘণ্টার batch কাজ। On-demand $০.৫০, spot $০.১৫. Interruption-এর জন্য ৫% কাজ আবার করতে হয়। (ক) দুটির খরচ আর সাশ্রয়? (খ) কত ঘণ্টা বিল হলে spot-এর লাভ শেষ? (ঝালিয়ে নিন: পর্ব ৭২)
(a) on-demand = 2,000 x 0.50 = 1,000
spot = 2,000 x 1.05 x 0.15 = 315
saving = 1 - 315/1,000 = 68.5%
(b) 1,000 / 0.15 = 6,667 hours (work + redo)সাশ্রয় ৭০% নয়, ৬৮.৫%, কারণ আবার করা কাজের বিলও আসে। Checkpoint না থাকলে rework অনেক বাড়তে পারে, তবু টাকার হিসাবে spot অনেকটা সহ্য করে; সময়সীমাই সাধারণত আগে ভাঙে। (ক) $১,০০০ বনাম $৩১৫, ৬৮.৫%. (খ) প্রায় ৬,৬৬৭ ঘণ্টা।
৯.৪(মাঝারি) (ক) ৮ vCPU-র VM-এ p95 CPU ১৮%, লক্ষ্য ৬০%: কত vCPU লাগে? (খ) ৩টি instance $৪৮০ থেকে $২৪০-এর আকারে নামালে মাসে আর বছরে সাশ্রয় কত? (গ) Shared $১,৮০০ তিন দলে ভাগ করতে হবে, direct খরচ $৪,০০০, $২,০০০, $১,৫০০: কে কত পাবে? (ঝালিয়ে নিন: পর্ব ৭৩)
(a) 8 x 18 / 60 = 2.4 vCPU -> next real size, e.g. 4 vCPU
(b) 3 x (480 - 240) = 720 a month; 720 x 12 = 8,640 a year
(c) direct total = 7,500
1,800 x 4,000 / 7,500 = 960
1,800 x 2,000 / 7,500 = 480
1,800 x 1,500 / 7,500 = 360 (sum 1,800)Memory-র p95-ও দেখতে হয়, আর rollback-এর শর্ত আগে লিখে রাখতে হয়। (ক) ২.৪, মানে ৪ vCPU-র আকার। (খ) $৭২০ আর $৮,৬৪০. (গ) $৯৬০, $৪৮০, $৩৬০.
৯.৫(কঠিন) তিন মাসের বিল আর অর্ডার: আগস্ট $১০,০০০, ২,০০,০০০; সেপ্টেম্বর $১২,০০০, ৩,০০,০০০; অক্টোবর $১২,৫০০, ২,৫০,০০০. (ক) প্রতি মাসের unit cost? (খ) প্রথম দুই মাস ধরে সরলরেখা টেনে স্থির খরচ আর প্রতি অর্ডারের পরিবর্তনশীল খরচ বের করুন। (গ) অক্টোবরে কত বিল আশা করা উচিত ছিল, বাড়তি কত? (ঘ) ৪,০০,০০০ অর্ডারে পূর্বাভাস? (ঝালিয়ে নিন: পর্ব ৭৩)
(a) 10,000/200,000 = 0.050; 12,000/300,000 = 0.040;
12,500/250,000 = 0.050
(b) slope = 2,000 / 100,000 = 0.02 per order
fixed = 10,000 - 0.02 x 200,000 = 6,000
(c) 6,000 + 0.02 x 250,000 = 11,000; extra = 1,500
(d) 6,000 + 0.02 x 400,000 = 14,000 (0.035 per order)সেপ্টেম্বরে বিল বেড়েও unit cost কমেছে, ভালো খবর। অক্টোবরে বিল সামান্য বেড়েছে, অথচ unit cost ২৫% বেড়েছে: খোঁজার সময়। দুটি বিন্দুর রেখা মোটা দাগের অনুমান। (ক) $০.০৫০, $০.০৪০, $০.০৫০. (খ) $৬,০০০ আর $০.০২. (গ) $১১,০০০, বাড়তি $১,৫০০. (ঘ) $১৪,০০০.
// Commitment, spot, rightsizing and unit cost. Prices ASSUMED.
const usd = (x) => "$" + x.toFixed(2), OD = 0.5, ONE = 0.35, THREE = 0.25, SPOT = 0.15;
const run = 500;
console.log("500 h: on-demand", usd(run * OD), "1y", usd(720 * ONE), "3y", usd(720 * THREE));
console.log("U* 1y", ONE / OD, " U* 3y", THREE / OD, " this VM:", (100 * run / 720).toFixed(1) + "%");
const demand = [2, 2, 4, 4, 6, 4], block = 120; // 6 blocks a day, 120 h a month each
for (let n = 0; n <= 6; n++) {
const od = demand.reduce((s, d) => s + Math.max(0, d - n), 0) * block * OD;
const used = demand.filter((d) => d >= n).length;
console.log(`commit ${n}: ${usd(n * 720 * ONE + od)}` + (n ? ` nth VM busy ${used}/6` : ""));
}
const work = 2000, rework = 0.05;
console.log("spot", usd(work * (1 + rework) * SPOT), "vs", usd(work * OD),
" break-even hours", (work * OD / SPOT).toFixed(0));
console.log("rightsize:", 8 * 18 / 60, "vCPU; fleet saving", usd(3 * 480 - 3 * 240));
const months = [["Aug", 10000, 200000], ["Sep", 12000, 300000], ["Oct", 12500, 250000]];
for (const [m, bill, orders] of months) console.log(m, "$" + (bill / orders).toFixed(3));
const slope = (12000 - 10000) / (300000 - 200000), base = 10000 - slope * 200000;
console.log("fixed", usd(base), "per order", usd(slope), "Oct expected", usd(base + slope * 250000));
for (const c of [4000, 2000, 1500]) console.log(c, "gets", usd(1800 * c / 7500));আউটপুট:
500 h: on-demand $250.00 1y $252.00 3y $180.00
U* 1y 0.7 U* 3y 0.5 this VM: 69.4%
commit 0: $1320.00
commit 1: $1212.00 nth VM busy 6/6
commit 2: $1104.00 nth VM busy 6/6
commit 3: $1116.00 nth VM busy 4/6
commit 4: $1128.00 nth VM busy 4/6
commit 5: $1320.00 nth VM busy 1/6
commit 6: $1512.00 nth VM busy 1/6
spot $315.00 vs $1000.00 break-even hours 6667
rightsize: 2.4 vCPU; fleet saving $720.00
Aug $0.050
Sep $0.040
Oct $0.050
fixed $6000.00 per order $0.02 Oct expected $11000.00
4000 gets $960.00
2000 gets $480.00
1500 gets $360.00“commit” সারিগুলো ৯.২-এর টেবিল; ডানের nth VM busy সংখ্যা ৬ ভাগের কত ভাগে সেই VM ব্যস্ত। U* লাইনে দুই ছাড়ের সীমা। এরপর ৯.৩, ৯.৪ আর ৯.৫.
(সহজ) অঙ্গীকারে ৪০% ছাড়, পুরো সময়ের দাম দিতে হয়। Break-even utilisation কত?
- ৪০%
- ১০০%
- ৬০%
- ৭০%
(মাঝারি) ১০০ ঘণ্টার কাজ, ২০% rework. Spot $০.১৫, on-demand $০.৫০. দুই পথের খরচ কত?
- Spot $১৮, on-demand $৫০
- Spot $১৫, on-demand $৫০
- Spot $১৮, on-demand $৬০
- Spot $৩০, on-demand $৫০
(সহজ) মাসের বিল $৯,০০০, অর্ডার ১,৫০,০০০. Cost per order কত?
- $০.৬০
- $১৬.৬৭
- $০.০০৬
- $০.০৬
১০ · শেষ মুহূর্তের সূত্র-তালিকা
পরীক্ষার আগে এই এক টেবিলই যথেষ্ট। শেষ কলামে সবচেয়ে সাধারণ ফাঁদ। সূত্রের চেয়ে সেটি মনে রাখাই বেশি কাজের।
| বিষয় | সূত্র | ফাঁদ |
|---|---|---|
| Break-even | CapEx ÷ (cloud − নিজের মাসিক) | ভগ্নাংশ মাসের অর্থ না বলা |
| Downtime | (১ − A) × ৪৩,২০০ মিনিট; × ৮,৭৬০ ঘণ্টা | মাস আর বছর গুলিয়ে ফেলা |
| Availability | series গুণ; parallel 1 − (1 − a)n | ব্যর্থতা স্বাধীন ধরে নেওয়া |
| Throughput | IOPS × block; সব সীমার min | VM-এর সীমা আর queue ভুলে যাওয়া |
| Transfer | আকার × ৮ ÷ (গতি × e); পরিবর্তনে ÷ (১ − r/b) | ৮ ভুলে যাওয়া; bit আর byte |
| RPO, RTO | I + S; স্থির ধাপ + ডেটা ÷ ধীরতম গতি | S বাদ দেওয়া; disk-এর গতি ভুলে যাওয়া |
| CIDR | 232−p − কাটা; network = ⌊x ÷ B⌋ × B | /20-এ block ১৬, শুরু গুণিতকে না রাখা |
| NAT | ঘণ্টা + GB + egress + AZ পার | এক NAT-কে সবসময় সস্তা ভাবা |
| Peering | n(n − ১) ÷ ২; নতুন VPC-তে n | n² লেখা |
| DNS failover | I × F + TTL + A | Detection ভুলে শুধু TTL বলা |
| CDN | origin = মোট × (১ − h) | Hit দিয়ে ভাবা, miss দিয়ে নয় |
| KMS | call ÷ ১০,০০০ × দর; instance ÷ মেয়াদ | মেয়াদ বাড়ানোর নিরাপত্তা-মূল্য ভুলে যাওয়া |
| Image | Σ layer; pull = MB × ratio × ৮ ÷ Mbps | পরের RUN-এ মুছলে আকার কমে ভাবা |
| Rolling update | surge ⌈ ⌉, unavail ⌊ ⌋; R + surge; R − unavail | দুটোই একদিকে round করা |
| HPA | ⌈n × m ÷ t⌉, clamp; tolerance ০.১ | Max ভুলে যাওয়া; request-এর শতাংশ না দেখা |
| AZ headroom | u × z ÷ (z − ১); 100 ÷ (1 + g)T | Zone হারানো হিসাবে না রাখা |
| FaaS | call × দাম + call × GB × s × দাম; C = rate × s | Call-এর ফি বা MB থেকে GB ভুলে যাওয়া |
| Quantile | lower + (upper − lower) × (rank − below) ÷ in_bucket | Cumulative সংখ্যাকে খোপের সংখ্যা ভাবা |
| Burn rate | error ÷ (১ − SLO); burn × জানালা ÷ ৭২০ | SLO-র ওপর ভাগ করা, budget-এর ওপর নয় |
| Little, M/M/1 | L = λW; W = S ÷ (১ − ρ) | ms আর s মেশানো; ρ ≥ ১-এ খাটানো |
| Commitment | U* = ১ − d | কম ব্যবহারে ছাড় দেখে কেনা |
| Unit cost | বিল ÷ একক; ঢাল = Δবিল ÷ Δএকক | মোট বিল দেখে ভালো-মন্দ বলা |
AI-এর যুগে — numerical-এর উত্তর যাচাই
AI-কে CIDR বা burn rate-এর অঙ্ক দিলে পরিষ্কার টেবিলে আত্মবিশ্বাসী উত্তর আসে, অথচ তাতে প্রায়ই ভুল থাকে। AI-এর লেখা Terraform-এ 0.0.0.0/0, * অনুমতি বা public storage যেমন চোখ এড়িয়ে যায়, হিসাবের ভুলও তেমন। পুরোনো মুখস্থ দামকে আজকের দাম বলে দেয়, এমনকি পুরোনো দাম-তালিকা থেকে “free tier” ধরে নেয়। ভুলগুলো চেনা:
| AI-এর ভুল | পরিণাম | কীভাবে ধরবেন |
|---|---|---|
| Mbps আর MB/s গুলিয়ে ফেলা; ৮ বাদ | Transfer আর RTO ৮ গুণ ভুল | একক আলাদা লাইনে লিখতে বলুন |
| /24-এ “২৫৪ host” বলা, কাটা ঠিকানা ভুলে যাওয়া | Subnet ছোট পড়ে, autoscaling আটকায় | Provider-এর নথি আর এই পাতার ক্যালকুলেটর |
| Series-এ গুণের বদলে “সবচেয়ে কমটি” বলা; correlation উপেক্ষা | Availability বেশি দেখায় | স্তর ধরে গুণ দেখতে চান, shared অংশ জিজ্ঞেস করুন |
| Burn rate-এ SLO দিয়ে ভাগ; ৩০ দিনের বদলে ৩১ বা ২৮ দিন | Alert ভুল সীমায় | Workbook-এর ১৪.৪ দিয়ে উল্টো যাচাই |
| দামকে তথ্য বলে দেওয়া; NAT, AZ পার, log-এর সারি বাদ | বিল অনুমানের চেয়ে অনেক বেশি | Provider-এর pricing পাতা, budget alert |
| HPA-তে tolerance বা max ভুলে যাওয়া; Mi আর MB মেশানো | ভুল replica, ভুল node-সংখ্যা | Test cluster-এ --dry-run, প্রথমে স্থির মানে চালান |
AI-কে উত্তরদাতা নয়, যাচাইকারী হিসেবে ব্যবহার করুন। কোনো account id, key বা আসল বিলের গোপন তথ্য prompt-এ দেবেন না।
যাচাইয়ের চেকলিস্ট
নিজেকে যাচাই করুন
প্রতিটি প্রশ্নে খাতায় হিসাব করে তবে উত্তর বাছুন। ওপরের ভাগগুলোর ৩০টি প্রশ্নের সাথে এগুলো মিলিয়ে মোট ৩৬টি।
ক্রমপরীক্ষার খাতায় একটি পূর্ণ numerical উত্তরের ধাপগুলো সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- দেওয়া তথ্য আর একক এক লাইনে লেখা
- ধরে নেওয়া নিয়ম ঘোষণা করা
- সূত্র লেখা
- মান বসিয়ে ধাপে ধাপে হিসাব
- Sanity check বা উল্টো হিসাব
- শেষ উত্তর, একক আর এক লাইনের মন্তব্য
(কঠিন) ৩ zone-এ autoscaling-এর লক্ষ্য ৭০%, zone-গুলোতে চাপ সমান। একটি zone পুরো হারালে বাকি instance-এ চাপ কত হবে, নতুন instance ওঠার আগে?
- ৭০%
- ১০৫%
- ৯০%
- ২১০%
(মাঝারি) ২টি NAT gateway, দর ঘণ্টায় $০.০৫ আর প্রতি GB-তে $০.০৫, মাসে ১০,০০০ GB. Egress বাদে শুধু NAT-এর বিল কত?
- $৫৭২
- $৫০০
- $৫৩৬
- $১,০৭২
(মাঝারি) ৮টি instance, CPU ৯০%, লক্ষ্য ৬০%, max ১০. Target tracking-এর সূত্রে desired কত?
- ১২
- ৮
- ৯
- ১০
(কঠিন) ১ TB ডেটা ১০০ MB/s-এ ফেরে, বাকি ধাপ ৩০ মিনিট, RTO লক্ষ্য ৩ ঘণ্টা। লক্ষ্য পূরণ হবে?
- হ্যাঁ, প্রায় ৪৭ মিনিট
- হ্যাঁ, প্রায় ১৬৭ মিনিট
- না, প্রায় ১৯৭ মিনিট
- না, প্রায় ২৩ ঘণ্টা
(মাঝারি) মোট ১৫০ req/s, এর মধ্যে ৩ req/s 5xx. SLO ৯৯%. Error ratio আর burn rate কত?
- ০.৫% আর ০.৫
- ২% আর ২
- ২% আর ২০
- ৩% আর ৩
(মাঝারি) ১০টি VPC একটি hub-এ। Attachment ঘণ্টায় $০.০৫, প্রতি GB $০.০২, মাসে ২,০০০ GB. Hub-এর বিল কত?
- $৪০
- $৩৬০
- $৪০০
- $১,৬৬০
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব শব্দ এখানে একসাথে:
মনে রাখুন
- একক আগে: bit না byte, GB না GiB, ms না s, মাসে কত ঘণ্টা। অর্ধেক ভুল এখানেই।
- সবচেয়ে ধীর সীমাই সীমা: IOPS, VM, disk, quota বা database, যেটিতে আগে ঠেকে।
- গড়ে নয়, চূড়ায় ভাবুন: peak, p95, zone হারানোর পরের চাপ।
- ছোট শতাংশের বড় দাম: ρ ০.৯ থেকে ০.৯৫, hit ৯৫ থেকে ৯৯, এক ঘণ্টার burn ২০.
- দাম সবসময় অনুমিত: শেষ সিদ্ধান্তের আগে provider-এর আসল পাতা দেখুন, আর মেপে মেলান।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ৭৮ · MCQ প্রশ্নব্যাংক — cloud computing ও DevOpsপরবর্তী পর্বহিসাবের পর এবার ধারণা যাচাই: প্রতিটি মডিউলের MCQ, ব্যাখ্যাসহ।
- ক্লাউড কম্পিউটিং ও DevOps · কোর্স হোম৮১টি পর্বপরের পর্ব ৭৮, MCQ প্রশ্নব্যাংক, আর পুরো রোডম্যাপ এখান থেকে।
- পর্ব ৬৬ · Alerting আর SLOআবার পড়ুনBurn rate-এর পুরো তত্ত্ব আর দুই জানালার alert.
- পর্ব ২৫ · VPC আর subnetআবার পড়ুনCIDR আর ঠিকানার নকশা, উদাহরণসহ।
- Computer Networks · Subnettingপাশের ট্র্যাকBinary থেকে subnet-এর পুরো হিসাব।
- System Design · Estimationপাশের ট্র্যাকমোটা দাগের capacity হিসাবের অভ্যাস।