عملیات و → مدیریت مقیاس زیرساخت های عملیاتی

مقیاس زیرساخت عملیاتی

1) چرا و چه چیزی «مقیاس» در نظر گرفته شده است

مقیاس پذیری توانایی سیستم برای افزایش توان (RPS/TPS، اتصالات، IOPS، توان) و حجم داده بدون از دست دادن SLO و با هزینه کنترل شده است. برای iGaming/fintech، این به طور مستقیم در مورد پول است: تبدیل سپرده/شرط، بازی های زنده و حل و فصل.

• SLO ها را در رشد بار X برابر و قله های فصلی نگه دارید.
• زمان مقیاس قابل پیش بینی (دقیقه، نه ساعت) را فراهم کنید.
• صرفه جویی در اقتصاد: هزینه/RPS، هزینه/معامله، هزینه/رویدادهای 1k.

2) اصول پلت فرم مقیاس پذیر

1. افقی اول: تقسیم به خدمات کوچک و بدون دولت ؛ وضعیت - در خوشه های داده.
2. فشار برگشتی و صف: انفجار صاف، حفاظت در برابر «طوفان».
3. ذخیره سازی در تمام لایه ها: مشتری/لبه/سرویس/پایگاه داده.
4. Idempotence و تکرارپذیری: عقب نشینی امن، outbox، dedup.
5. وابستگی های محدود: وقفه ها، قطع کننده ها، انزوا در دیوار، محدودیت های نرخ.
6. قابلیت مشاهده توسط سیگنال های ظرفیت: headroom، p95/p99، تاخیر، اتصالات، سهمیه.
7. مقیاس خودکار با ریل های گارد: HPA/VPA/Cluster Autoscaler + شرایط توقف.
8. چند منطقه با طراحی: مناطق انفجار مستقل، داده های محلی، fylovers پایدار.

3) برنامه ریزی ظرفیت: چگونه «محاسبه چقدر شما نیاز دارید»

ورودی های مدل: TPS پیک هدف، مشخصات ترافیک (ساعتی)، «مسیرهای بحرانی»، نسبت های ضربه کش، بارهای متوسط، SLO ها و محدودیت های ارائه دهنده.

• RPS → CPU/pods: 'pods = RPS p99_time/effective _ CPU _ in _ pod' (با حاشیه 30-50٪).
• صف ها: "minimum _ speed _ of _ consumers ≥ peak _ speed _ of _ producers 1. 2`.
• اتصالات DB: 'max _ conns = active _ service _ pools medium _ pool _ size 1. 3`.
• کش: اندازه = «مجموعه کار گرم در N دقیقه» + حاشیه 20-30٪.
• خروج/CDN: اوج خروج = اوج درخواست متوسط اندازه پاسخ (در نظر گرفتن فشرده سازی).

اتاق سر: هدف 20-40٪ در اوج (توسط لایه). زیر 15٪ → ماشه «افزایش ظرفیت».

4) لایه ها و الگوهای پوسته پوسته شدن

4. 1 لبه/CDN/WAF

ذخیره سازی لبه (TTL + SWR)، تعادل جغرافیایی، فشرده سازی، HTTP/2/3.
محدودیت نرخ در محیط توسط IP/JWT/کلید، حفاظت از افزایش.
طرفداران رویداد (jackpots، هشدارهای زنده) از طریق کارگزاران/کانال های میخانه/زیر.

4. 2 Backend-for-Frontend API دروازه

مقیاس افقی توسط statles، استخرهای اختصاصی توسط downstreams.
HPA با معیارهای تجاری: RPS، P99، صف استخر کار - نه فقط CPU.

4. 3 صف های ناهمزمان/جریان (کافکا/خرگوش/پولسار)

مقیاس توسط احزاب و مصرف کنندگان ؛ اجتناب از انحراف (کلید و توزیع).

هشدار تاخیر + مقیاس خودکار مصرف کنندگان ؛ DLQ و موضوعات مجدد

حفظ تحت SLA آشتی و پخش مجدد.

4. 4 حافظه پنهان (Redis/Memcached)

حالت های خوشه ای، کپی، سیاست های تخلیه (LFU)، چند منظوره، خط لوله.
جداسازی وظایف کلید داغ و پس زمینه، محدودیت های مشتری و سیاست حداکثر حافظه.

4. 5 پایگاه داده ها

خواندن کپی و خواندن مسیریابی، اتصال اتصال.
شاردینگ توسط منطقه/مستاجر/محدوده کلیدی.
CQRS: به استاد/رهبر می نویسد، به کپی می خواند.
Indexing and batch-writing workflows (خروجی → جریان → سینک).
بایگانی و داده های گرم/سرد (tiering).

4. 6 فروشگاه فایل/شیء

Multithreading، دانلود چند بخش، CDN جلو، تحولات ناهمزمان.
سهمیه ارائه دهنده، تمیز کردن دم و بودجه خروج.

4. 7 ارائه دهندگان (PSP/KYC/استودیو)

چند فروشنده و نقل قول/SLO/هزینه مسیریابی.
قطع کننده مدار + نرخ محدود برای هر ارائه دهنده, retray صف, «حالت فضل».

5) ریل های خودکار و گارد

• HPA: метрики 'rps _ per _ pod', 'queue _ depth', 'p99 _ latency'; 'targetAverageValue'.
• VPA: دستورالعمل منابع ؛ به روز رسانی از قله.
• خوشه Autoscaler: نقطه + بر روی تقاضا پروفایل با اولویت.
• PodDisruptionBudget/TopologySpreadConstraints: یکنواخت در سراسر مناطق.
• LimitRange/ResourceQuota: حفاظت در برابر خستگی های «مست».

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• «مکث و برگشت»، اگر با قناری p99> 1. 3 × پایه 10 دقیقه.
• «یخ مقیاس پایین» در زمان نخست، فقط مقیاس بالا.
• «توقف تلاش مجدد» در 'open _ circuit = 1' به تنگناها.

6) چند منطقه: دارایی/دارایی و دارایی/بدهی

مناطق انفجار جدا شده: خوشه های مستقل، اسرار/سهمیه های محلی.
مسیریابی جهانی: latency-/geo-based، health-probes، override دستی.

• داغ - به صورت محلی + تکرار احتمالی (جریان).
• معاملات بحرانی - سازگار با دامنه (دفتر کل/تعادل).
• کتابهای پخش Failover: تغییر منبع گام به گام، TTL، کش های گرم کردن.
• تنظیم ورزش (DR): تمرینات سه ماهه با اهداف RTO/RPO.

7) الگوهای شبکه و خدمات

مش سرویس: mTLS، retry/breaker، تشخیص بیرونی، محدودیت های هر پایین دست.
eBPF/مشاهده پذیری در L4/L7، محدودیت اتصال، حفاظت از سر خط.
دروازه های API داخلی برای S2S، محدودیت نرخ عمومی و حسابرسی.
VPC/subnets توسط مناطق انفجار، کنترل NAT/Egress، با فروشندگان همکاری می کند.

8) عملکرد: تست ها و اثبات ها

بار و استرس در زمان اولیه + مشخصات بدترین مورد.
خیس (طولانی) - نشت حافظه/توصیف، رشد تاخیر.
هرج و مرج/بازی روز: کارگزار/ارائه دهنده/قطره منطقه، «ارائه دهنده آهسته».
رگرسیون Perf در CI: مجموعه ای از سناریوهای مرجع و دروازه های اتوماتیک.

9) داده ها و ذخیره سازی: استراتژی های رشد

رشد عمودی تا سقف → افقی/شاردینگ.
خواندن → ماکت/کش; سوابق → batch/asynchron/log.
مهاجرت طرح: گسترش → مهاجرت → قرارداد, هیچ قفل جهانی.
بایگانی: دسته های سرد برای ذخیره سازی ارزان + هیدراتاسیون مجدد بر روی تقاضا.
جستجو: شاخص های فردی (OpenSearch/Solr) با خط لوله به روز رسانی افزایشی.

10) مدیریت ارائه دهندگان و سهمیه

کارت سهمیه (TPS، پنجره ها، هزینه) ؛ استفاده از هشدارها _ نسبت> 0. 9`.
مسیریابی با هزینه/کیفیت (مسیریابی هوشمند).
OLA ↔ موافقت نامه های SLO و روند افزایش سهمیه.
استخر جایگزین و «داغ» تعویض.

11) سیگنال های قابل مشاهده و مقیاس پذیری

• ظرفیت headroom по слоям ؛ 'صف _ تاخیر/رشد عقب مانده' ؛ 'kafka ISR' ؛ 'اتصالات db '/' repl تاخیر' ؛ 'redis اخراج' ؛ 'open _ circuit '/' retry _ rate' ؛ 'quota _ usage'.
• معیارهای کسب و کار: نرخ موفقیت/تبدیل سپرده، زمان شروع بازی.
• هزینه: هزینه/RPS، هزینه/1k تماس.

• بررسی ظرفیت (سر و صدا، خطرات بالا، SLO سوختگی).
• پانل جریان و صف (تاخیر/عقب ماندگی، اشباع مصرف کننده).
• DB & Cache (P99، اتصالات، ضربه/اخراج).
• ارائه دهندگان و نقل قول (TPS، زمان، هزینه، تعویض).
• تغییر ایمنی (قبل/بعد از انتشار، قناری، autogates).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: مقیاس پذیری سودآور است

نسبت بهره وری: هزینه/RPS، هزینه/سپرده، هزینه/رویدادهای 1k.
اندازه گیری راست: VPA/توصیه ها، گزارش های بیش از حد ارائه شده.
نقطه/قابل پیش بینی برای غیر بحرانی ؛ محفوظ/متعهد برای بار پایه.
بودجه و ذخیره سازی را خارج کنید، بارگیری CDN/edge.
جمع آوری و بایگانی سیاهههای مربوط به سطح ارزش (گرم در مقابل سرد).
سهمیه های هشدار دهنده (soft-cap) و بلیط های خودکار برای گسترش.

13) فرآیندها و مردم

مدیریت تغییر: canaries، phicheflags، توقف در رگرسیون.
آمادگی حادثه: runbook "و" کجا برای اضافه کردن ظرفیت "،" نحوه تغییر منطقه ".
قله های برنامه ریزی: تقویم مسابقه/مسابقات/مبارزات انتخاباتی و پنجره های ارائه دهنده.
روزهای بازی منظم و تمرینات DR.
ماتریس مالکیت: چه کسی می تواند «دکمه» را در feilover/افزایش سهمیه ها فشار دهد.

14) چک لیست پیاده سازی

• نقشه مسیرهای بحرانی و محدودیت ها (توسط لایه)، هدف headroom ≥ 30٪.
• HPA توسط معیارهای کسب و کار + خوشه Autoscaler ؛ PDB/SpreadConstraints
• صف در مسیرهای داغ، idempotency-کلید، صندوق پستی.
• حافظه های پنهان: اهداف ضربه ≥ 90٪، سیاست اخراج، شاخص های کلیدی.
• DB: خواندن کپی، استخر اتصال، طرح sharding.
• ارائه دهندگان: چند فروشنده، سهمیه، شکن/عقب نشینی.
• داشبورد «ظرفیت/جریان/DB/ارائه دهندگان»، هشدار از § 11.
• قناری و قبل/بعد از انتشار autogates.
• دفترچه راهنمای DR و یک آموزش جزئی feilover.

• گرم کردن انبارها، پیش مقیاس HPA/ASG، کپی گرم آماده به کار.
• افزایش سهمیه ارائه دهنده، مسیریابی هوشمند را فعال کنید.
• سرکوب های حالت شب را برای هشدارهای غیر بحرانی فعال می کند.
• ویژگی «safe mode» برای فعال سازی فوری آماده است.

15) ضد الگوهای

ارتقاء عمودی «توقف کامل» به جای افقی.
یک استخر سر از خط مشترک از موضوعات/اتصالات در تمام downstreams.
Retrai در زمان تنگنا، عدم لرزش → طوفان.
هیچ هیسترزیس در هشدار و سیاست های مقیاس → «اره» وجود دارد.
پایگاه داده جهانی تنها بدون sharding داده ها و محلی سازی.
ایمان کور در SDK فروشنده بدون کنترل زمان/retray/مشاهده.
فقدان تمرینات DR: feilover «تنها بر روی کاغذ».

16) مقیاس پذیری KPI

انطباق SLO در اوج (p95/p99، میزان موفقیت).
سر و صدا توسط لایه در زمان نخست.
MTTS (میانگین زمان برای مقیاس) - تا زمانی که منابع اضافی در دسترس هستند.
Backlog/Lag Resolution Time: زمانی که صف ها بعد از پیک بسته می شوند.
نرخ شکست تغییر برای یک دوره رشد فعال.
هزینه/RPS و صرفه جویی از کش/CDN/لبه offload.
آمادگی DR: RTO/RPO در ورزش.

17) نمونه هایی از قالب های «سریع»

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) سوالات متداول

س: چه چیزی برای اولین بار مقیاس می شود ؟

A: تنگناها با توجه به داشبورد: صف/کش/پایگاه داده می خواند. مسیرهای داغ (راه اندازی سپرده/شرط/بازی) یک اولویت است.

س: چگونه می توان فهمید که مقیاس خودکار «آن را بدتر می کند» ؟

A: همبستگی را ببینید: مقیاس up↑ و p99/خطاها بهبود نمی یابند - شاید شما «مقیاس مشکل» (محدود کردن جریان/سهمیه). شامل شکستن/تخریب.

س: آیا شما همیشه به یک ارائه دهنده دوم نیاز دارید ؟

A: برای مسیرهای بحرانی، بله. در غیر این صورت، حداقل «حالت امن» با یک اسکریپت ساده و کش.

س: فعال فعال или فعال منفعل ؟

A: اگر الزامات RTO کم باشد و بسیاری از بازیکنان منطقه ای فعال هستند. در غیر این صورت، با فعال-منفعل با یک feilover استفاده می شود شروع می شود.