برنامه ریزی ظرفیت

1) برنامه ریزی ظرفیت چیست و چرا لازم است

برنامه ریزی ظرفیت فرایند سیستماتیک ارزیابی و تأمین منابع مورد نیاز برای دستیابی به SLO های هدف با حداقل هزینه است. ما در حال صحبت کردن نه تنها در مورد CPU/حافظه، بلکه در مورد پهنای باند شبکه، ذخیره سازی، پایگاه داده/کش، صف/اتوبوس رویداد، ارائه دهندگان خارجی (پرداخت/CCM/ضد تقلب)، و همچنین منابع انسانی (در تماس، پشتیبانی).

• انجام SLO/SLA حتی در قله و تنزل.
• TCO و تأمین بیش از حد سرمایه را به حداقل برسانید.
• کاهش خطر حوادث ناشی از اتمام منابع (saturation → p99/error).
• اطمینان از قابل پیش بینی بودن نسخه ها و کمپین ها (بازاریابی، مسابقات، مسابقات برتر).

2) ورودی ها و منابع حقیقت

قابلیت مشاهده: RPS/concatenation، P50/P95/P99، نرخ خطا، اشباع (CPU، MEM، IOPS دیسک، PPS شبکه/مگابیت در ثانیه)، طول صف، محدودیت نرخ.
رویدادهای کسب و کار: تقویم مبارزات انتخاباتی، فصلی (شب/تعطیلات آخر هفته/مگا رویدادها)، مناطق/حوزه های قضایی.
بدهی/ویژگی های فنی: نقشه راه انتشار، تغییرات معماری (به عنوان مثال، رمزگذاری، ورود به سیستم جدید).
ارائه دهندگان: سهمیه و توان پرداخت/CUS/ایمیل/خدمات ضد تقلب.
حوادث گذشته: جایی که تنگنا (پایگاه داده، حافظه پنهان، تعادل L7، اتوبوس، CDN، دیسک) است.

3) مفاهیم و فرمول های اساسی

Headroom - حاشیه ظرفیت: 'headroom = (max _ stable _ RPS − real _ RPS )/max _ stable _ RPS'.
هدف در اوج 20-40٪ (برای جریان های بحرانی).
Saturation: نسبت منابع اشغال شده به منابع موجود (CPU%, memory/GC, connections, file descriptors, IOPS, queue depth).
توان پایدار - سرعتی که در آن p99 و نرخ خطا SLO را برای مدت طولانی انجام می دهند (نه یک بار پشت سر هم).
واحد ظرفیت (CU) - واحد قدرت نرمال برای سرویس (به عنوان مثال، X RPS در هر pod vCPU = 1، RAM = 2 GiB).
حد سیستم حداکثر بدون تخریب است: «N _ pods × CU». مهم است که وابستگی های مشترک (DB/cache/bus) را در نظر بگیرید.

4) مدل تقاضا: پیش بینی

سری آماری: فصلی هفتگی/روزانه، تعطیلات، فینال های ورزشی، قله های منطقه ای.
گروه ها: بر اساس کشور، ارائه دهندگان پرداخت، دستگاه ها، بخش های VIP.
Deltas رویداد: تاثیر کمپین/pooches/انتشار/SEO.
«چه می شود اگر» (برنامه ریزی سناریو): + 50٪ به ترافیک در 19: 00-22: 00 ؛ قطره ارائه دهنده A → توزیع مجدد به B (+ 30٪ به تاخیر).
تنظیمات زمان واقعی: nowcasting توسط معیارهای سرب (احیای جلسات، صف برای یک بازی، سبد).

5) مدل عرضه: جایی که زنجیره «شکسته» می شود

نوار نقاله پرس و جو: Edge/CDN → L7 balancer → application → cache → DB → API خارجی → turn/tire → handlers/ETL.

• ظرفیت (CU/نمونه)، مقیاس پذیری (افق/راس)، محدودیت ها (اتصالات، PPS، IOPS)، تاخیر.
• سیاست های شکست (محدودیت نرخ، قطع کننده مدار، تخریب).
• SLO ها محلی هستند و سهم آنها در e2e-SLO است.

6) حاشیه خطا و بودجه

ما اتاق را به بودجه خطا متصل می کنیم: بودجه کمتر → سهام بیشتر.
برای جریانهای بحرانی (پرداخت/تأیید) - اتاق فوقانی، برای جریانهای ثانویه - در زیر.
ذخایر سرد/گرم: فعال در اوج/تصادف.

7) مقیاس بندی: تاکتیک ها

HPA (با معیارهای بار): RPS، تاخیر، طول صف، SLI های کاربر (بهتر از CPU٪).
VPA: اصلاح منابع PODAM (مراقب باشید با stateful و P99 GC).
KEDA/آداپتورها: پوسته پوسته شدن توسط منابع خارجی (تاخیر Kafka، طول لیست Redis، عمق CloudQueue).
استخرهای گرم/گرم کردن: موارد پیش از آن برای جلوگیری از شروع سرد.
رویکرد «Load-as-Code»: سیاست های Autoscale/limit/timeout/retray نسخه بندی و بررسی می شوند.

8) صف، فشار پشتی و کنترل دم

هدف این است که برای جلوگیری از رشد بهمن مانند P99.
ما همزمانی و اندازه صف را محدود می کنیم، پنجره های زمان و idempointence را وارد کنید.
Hedging/Retry-budget: بودجه کل کاربر و سیستم را محدود می کند.
تخریب برازنده: غیر فعال کردن ویژگی های ثانویه در هنگام اضافه بار.

9) DB، انبارها و ذخیره سازی

DB: محدودیت اتصال، ورود به سیستم/FSync، شاخص ها، برنامه پرس و جو، تاخیر ماکت، کلید های داغ/جداول، حداکثر TPS برای معاملات.
Keshi: آمار نسبت به بخش، «طوفان از دست می رود» در هنگام انتشار/ناتوانی، توزیع کلید.
ذخیره سازی: IOPS/توان، تاخیر، فشرده سازی، TTL، تمیز کردن دسته های قدیمی/عکس های فوری.
طرح مهاجرت: گسترش → مهاجرت → قرارداد بدون توقف قفل.

10) جریان رویداد و ETL ها

Kafka/bus: عملکرد حزب، تاخیر، ISR، تراکم، محدودیت تولید کننده/مصرف کننده.

ETL/دسته: شروع ویندوز، بودجه زمان اجرا، دریچه گاز I/O

Idempotence و دقیقا یک بار مانند برای جریان بحرانی (پرداخت/تعادل).

11) شبکه و محیط

متعادل کننده های L4/L7: محدودیت اتصال، syn backload، بارگیری TLS، استفاده مجدد از جلسه.
CDN/Edge: پهنای باند، سیاست کش برای کاهش بار مبدا.
محدودیت های درون شبکه: pps/mbps در VPC/subnet، هزینه خروج (FinOps).

12) چند منطقه، DR و حوزه های قضایی

استراتژی: فعال فعال (GSLB/Anycast)، فعال منفعل (گرم/گرم/سرد DR).
N + 1 توسط منطقه: حفظ از دست دادن AZ/منطقه در حالی که حفظ جریان اصلی SLO.
محلی سازی قانونی: تقسیم ترافیک/داده ها بر اساس کشور، محدودیت های مختلف و SLO ها به ارائه دهندگان.
تست DR: روزهای بازی منظم با انتقال بار واقعی.

13) ارائه دهندگان خارجی: سهمیه ها و مسیرها

پرداخت/KYC/ضد تقلب/ایمیل/اس ام اس: TPS، سهمیه پشت سر هم، محدودیت های روزانه.
چند ارائه دهنده: مسیریابی توسط تاخیر/موفقیت، SLO در هر ارائه دهنده، خودکار feiler.
قراردادهای SLA: انطباق e2e-SLO، کانال های تشدید، وب سایت های وضعیت.

14) FinOps: هزینه و کارایی

TCO: محاسبه + ذخیره سازی + خروج شبکه + مجوز/ارائه دهندگان + وظیفه.
اقتصاد واحد: هزینه 1k درخواست/1 معامله سپرده/1 KYC.
بهینه سازی: اندازه راست، تخفیف نقطه/پیشوند، hitrate کش، ورود/ردیابی dedup، سطح ذخیره سازی سرد است.
انتقال بار در زمان: دسته های غیر بحرانی در پنجره های «شب» و مناطق ارزان قیمت.

15) داشبورد و گزارش (حداقل مجموعه)

• بار فعلی در مقابل توان ثابت در سراسر لینک.
• دفتر مرکزی با خدمات و منطقه ؛ پیش بینی 24/72 ساعت
• KPI FinOps: درخواست $/1k، $/سپرده.

• گلوگاه های بالا (p99، اشباع، تاخیر)، حاشیه DR.

• موفقیت ارائه دهنده/تاخیر و محدودیت ؛ سهم ترافیک در جاده ها

• برنامه ارتقاء/شاخص/بهینه سازی، رشد پس انداز/ظرفیت مورد انتظار.

16) فرآیندها و نقش ها

RACI: بستر های نرم افزاری (مادون/خوشه/balancers)، پایگاه داده/داده ها (شاخص ها، تکرار)، دستورات خدمات (پروفایل/کش)، SRE (SLO، هشدار)، ثانیه/انطباق (رمزنگاری/سیاهههای مربوط)، امور مالی (بودجه).
ریتم: بررسی ظرفیت هفتگی (نقشه راه، پیش بینی، خطرات)، گزارش های ماهانه FinOps، آزمایشات DR سه ماهه.
مدیریت تغییر: کمپین های عمده/انتشار ظرفیت دروازه (چک لیست زیر).

17) ظرفیت دروازه

• پیش بینی اوج بار و «+ x٪ دم اضطراری».
• Headroom موجود برای جریان های اصلی (پرداخت/ACC/ورود).
• سهمیه ها به ارائه دهندگان تایید شده است ؛ مسیرهای جایگزین فعال هستند.
• آستانه HPA/KEDA و گرم استخر پیکربندی شده است.
• صف/محدودیت ها و تخریب چک (playbooks آماده).
• سهام قناری و بازگشت خودکار فعال می شوند.
• داشبورد/هشدار (burn-rate، saturation، p99) بررسی شده است.
• طرح DR و تماس تشدید مربوطه می باشد.

18) ضد الگوهای

CPU <70٪ - همه چیز خوب است: نادیده گرفتن محدودیت وابستگی (اتصالات DB، IOPS، صف).
متمرکز «جعبه سیاه» بدون معیارهای هر لینک - غیر ممکن است به درک که در آن حد است.
فقدان استراتژی کش - انتشار نتواند کشتن منشاء.
محدودیت بازپرداخت بدون بودجه طوفان درخواست است.
«یک ارائه دهنده پرداخت» یک نقطه شکست در اوج خود است.
نادیده گرفتن ذخایر گرم یک شروع سرد به عنوان علت حوادث است.
بدون آزمایش دوره ای DR - این طرح در صورت لزوم کار نمی کند.

19) برآورد هزینه های کوچک (به عنوان مثال)

سرویس X: پایدار 350 RPS در هر غلاف (vCPU = 1، RAM = 2 GiB). هدف 5000 RPS، سر 25٪ است.
قدرت مورد نیاز = "5000/0. 75 = 6667 RPS.
Podov = 'ceil (6667/350) = 20'. به علاوه گرم استخر 15٪ → 3 غلاف بیشتر.
DB: حد 12k TPS، اعتبار فعلی 9k TPS، پیش بینی اوج 10. 5K TPS → سهام 1. 5 کیلوگرم (14٪) نیاز به شاخص/sharding/کپی یا ذخیره سازی برای کاهش به 8. 5 کیلو.
ارائه دهنده A (KYC): سهمیه 120 دور در ثانیه, اوج 95 دور در ثانیه, مبارزات انتخاباتی + 40% → 133 دور در ثانیه> سهمیه → مسیریابی 70% A/30% ب.

20) قالب اجرای برنامه ریزی ظرفیت

1. مسیر e2e و تنگناها را توصیف کنید.
2. CU را وارد کنید و توان پایدار هر لایه را اندازه گیری کنید.
3. saturation و p99 metrics را در تمام لینک ها پیکربندی کنید.
4. تولید تقویم رویداد/کمپین/انتشار.
5. ساخت پیش بینی کوهورت و چه اگر حالات.
6. پین headroom در هر موضوع و در هر منطقه (اتصال به بودجه خطا).
7. تنظیم HPA/VPA/KEDA + گرم استخر، محدودیت/retrays/صف.
8. سهمیه ارائه دهنده را بررسی کنید، چند مسیر را فعال کنید.
9. داشبورد و بررسی ظرفیت ریتم هفتگی را جمع آوری کنید.
10. سه ماهه - تمرینات DR و بازنگری مدل.

21) خط پایین

برنامه ریزی ظرفیت یک مجموعه قابل کنترل از پیش بینی ها، محدودیت های معماری و هزینه است، نه «اضافه کردن CPU». هنگامی که هر لایه از مسیر e2e دارای ظرفیت اندازه گیری شده است و استراتژی های سر و صدا و تخریب با SLO و بودجه خطا همراه است، بارهای پیک، کمپین ها و حوادث متوقف می شود. این رویکرد خطر حوادث را کاهش می دهد، معیارهای تجاری را تثبیت می کند و هزینه ها را بهینه می کند.