Რატომ არის მნიშვნელოვანი ინფრასტრუქტურის მასშტაბირება

რატომ არის ბიზნესი მასშტაბური

შემოსავალი „ჭერის“ გარეშე. პიკის მოვლენები (დერბი, ფინალი, სლოტების დიდი გამოშვებები) მრავალჯერ ზრდის RPS- ს. მასშტაბურობა ტრეფიკის ზრდას GGR ზრდად აქცევს და არა 5xx შეცდომად.

სტაბილური SLO. ჩვენ გვაქვს p95 კრიტიკული ბილიკის ლატენტობა (კურსი, ბალანსის განახლება, გაყვანა) სამიზნე ჩარჩოებში ნებისმიერი ონლაინ რეჟიმში.

ღირებულება კონტროლდება. ელასტიურობა = იხდით „ცხელ საათს“ და არა „მუდმივ მაქსიმუმს“.

მარეგულირებელი და ბრენდი. ბილეთის ოფისის/საფულის ხელმისაწვდომობა და პროგნოზირებადი მუშაობა მოთამაშეთა აუდიტისა და ნდობის საგანია.

მასშტაბის ტიპები

ჰორიზონტალური (სკალე-გარეთ)

დაამატეთ მომსახურების ნიმუშები. სახელმწიფო API- ს საფუძველი, პროვაიდერების, ვებ - კარიბჭეების, ქურდებისთვის. დადებითი: წინააღმდეგობა, ელასტიურობა. უარყოფითი: საჭიროა იდემპოტენტურობა და გარეგანი მდგომარეობა.

ვერტიკალური (სკალარული)

ჩვენ ვზრდით კვანძის რესურსებს. შესაფერისია BD და OLAP მტევანი, მაგრამ აქვს ზღვარი და უფრო ძვირია, ვიდრე ზრდის ერთეული.

გეოგრაფიული

Multi-AZ და, საჭიროების შემთხვევაში, multi-region: მოთამაშესთან უფრო ახლოს არის განაკვეთების/ნაკადების შეფერხება და უფრო მეტი წინააღმდეგობა უბედური შემთხვევების მიმართ.

რა არის მასშტაბური კაზინოში

Edge და API: კარიბჭეები, WAF, GraphQL/REST, WebSocket ჰაბები (ფსონები/მოვლენები).

Bridge მიმწოდებლებისთვის: Live/RNG გადამყვანები HPA- ით RPS- ით და დრო 'bet. accepted`.

საფულე/ლეგენდა: stateful ბირთვი - სკალირება რეპლიკების საშუალებით კითხვისთვის, შარდისა და გარიგების ოპტიმიზაციისთვის.

სალარო: ცალკეული აუზები გადახდის პროვაიდერებისთვის/კრიპტო on/off-ramp, გადახდების ხაზები.

ღონისძიებების რიგები/ავტობუსი: Kafka/NATS მტევანი ავტოსკალინგის კონცერტებიდან.

ქეში/კატალოგები: Redis/ცხელი კლავიშების მეხსიერება, CDN სტატიკური ასეტებისთვის.

Streeming: WebRTC/LL-HLS edge-nods ავტოფოლბეკით და QoS- ის სკეიტი.

საინჟინრო პრინციპები

1. იდემპოტენტობა ფულში. ნებისმიერი მიმღები. place`/`payout. request 'დამუშავებულია ზუსტად ერთხელ (იდემპოტენტურობის გასაღები).

2. რიგები და დაბლოკვა. კრიტიკული ბილიკები არ იბლოკება: თუ პროვაიდერი/BD აყოვნებს, მოთხოვნები ბუფერში შედის კონტროლირებადი „ქლიავით“, მეორეხარისხოვანი ფიჩები პირველ რიგში ამცირებს.

3. კაში ჯერ. Read heavy მოთხოვნები (ბალანსი, ლობი) - ქეში/მატერიალიზებული წარმოდგენების საშუალებით; ინვალიდობა - მოვლენებით.

4. შარდვა. ჩვენ ვყოფთ მონაცემებს/ნაკადებს ('playerID' მიხედვით, ქვეყანა, პროვაიდერი, ვალუტა).

5. Consistence არის იქ, სადაც არის ფული. მკაცრი ACID მხოლოდ საფულე/ლეჯერისთვის; დანარჩენი მოვლენებია.

6. დაკვირვება გამოშვებამდე. მეტრიკი/ტრეისი არის მომსახურების ხელშეკრულების ნაწილი, წინააღმდეგ შემთხვევაში მანქანის სკეიტი „ბრმა“.

მეტრიკა და მიზნები (SLO/SLA)

ლატენტობა p95/p99:

`bet. place '150-250 ms (რეგიონში),' wallet. debit/credit` ≤ 50–100 мс, `payout. quote/submit` ≤ 500–800 мс.
შეცდომების წილი: '5xx' <0. 1–0. 3% API, 'reect _ rate' განაკვეთები <0. 2% ნორმალური მუშაობით.
გამტარუნარიანობა: RPS API/bridge; events/sec საბურავზე.
რიგები: ლოდინის სიგრძე და დრო (მაგალითად, გადახდა 2-5 წუთი პიკის საათებში).
QoS strime: dropped frames, RTT განაკვეთების სიგნალები, რაუნდის აბორტი.
ქეში ჰიტები: hit-ratio> 85-95% ცხელ კლავიშებში.
Cost/Revenue: ინფრასტრუქტურის ღირებულება/GGR, მოთხოვნის ღირებულება (აშშ დოლარი).

💡 სასარგებლო ევრაზია (პატარა კანონის გამარტივება): სისტემაში საშუალო დრო არის რიგის/გამტარუნარიანობის სიგრძე. თუ მწვერვალზე რიგები იზრდება, გაზარდეთ consumers ან შეამცირეთ შეყვანის ნაკადი.

დომენების მასშტაბის ნიმუშები

საფულე და ლეჯერი

Reader-replicas კითხვისთვის; writer - ერთი shard.

CQRS: ჩანაწერი (მკაცრად) ცალკე კითხვისგან (მატერიალიზებული ნაჭრები).

Batch Crocker და „კორექტირების“ გარიგებები მკაცრად ხდება append-only ჟურნალის საშუალებით.

Bridge/თამაშის ინტეგრაცია

სახელმწიფო გადამყვანები ავტო სკალით latence of 'bet. accepted`.

თითოეული პროვაიდერისთვის Circuit breaker, დეგრადაციის დროს - UI- ს დროებითი დეგრადაცია და მაგიდების გამორთვა.

გადახდა/კრიპტი

გამოყოფილი აუზი webhook 'და PSP/on-chain მსმენელებისთვის; განმეორებითი დამუშავება idempotence.

პროვაიდერების როუტერი SLA/ღირებულების/ქვეყნის საფუძველზე.

დატვირთული ოპერაციები

ვორკერი/ჯობი (პრემია, მისიები, ტურნირები) - რიგებში; მასშტაბური რიგისა და ვადების სიგრძით.

ნაკადი

Edge აუზები რეგიონებში, WebRTC - LL-HLS- ის ავტოფოლკი; ვერტიკალური bitrate/ხარისხის ლიმიტები QoS- ის შესანარჩუნებლად.

არქიტექტურული გადაწყვეტილებები

HPA/VPA/Cluster Autoscaler: HPA — на API/bridge; VPA - ETL/ანგარიშებზე; კვანძები - მრავალფეროვანი აუზები (CPU-heavy, memory-heavy, ქსელი-optimized).

PodDisrupite Budget და პრიორიტეტები: ფულის ბირთვი დაცულია განდევნისგან.

Feature flags და კანარის გამოშვებები: ჩვენ ვაფიქსირებთ ახალ ფიჩხებს ტრეფიკის პროცენტზე.

Geo-routing: Anycast/DNS და რეგიონალური ინგრესული კარიბჭეები უფრო ახლოს არიან მომხმარებელთან.

ღირებულება და ეფექტურობა

რესურსების პროფილები. Requests/limits მოცემულია და შეესაბამება რეალურ პროფილს (კრიტიკულ გზებზე CPU-throttling- ის გარეშე).

სპოტის აუზები ანალიტიკოსებისთვის/ETL და ფონის ჯობებისთვის.

სატესტო/სტაგის გარემოცვის ავტომატური გამოხატვა სამუშაო ფანჯრის გარეთ.

კაში ბირთვების ნაცვლად. Redis ჰიტების დამატება იაფია, ვიდრე BD- ზე CPU- ს გამრავლებაზე.

უსაფრთხოება მასშტაბის დროს

mTLS/mesh სერვისებს შორის ზარის გრაფიკის ზრდის დროს.

ქსელის სეგმენტი: ფულის დომენები/PII - ნდობის ცალკეული ზონები.

საიდუმლოებების როტაცია და სურათების ხელმოწერა - მეტი კვანძი = მეტი რისკის ადგილები.

Blast-radius- ის კონტროლი: შარდვა და მოთხოვნის ლიმიტები იცავს კასკადს.

ანტი შაბლონები

გლობალური ბლოკირებით მონოლითის მასშტაბები: პოდების ზრდა = კონფლიქტების ზრდა.

სამუდამოდ გაათბეთ მტევანი „მწვერვალზე“, HPA- ს ნაცვლად და „მეორეხარისხოვანი“ ფიგურების დეგრადაცია.

შეურიეთ OLTP და OLAP ერთ მონაცემთა ბაზაში - ნებისმიერი ანგარიში კლავს განაკვეთების შეფერხებას.

Idempotent- ის არარსებობა არის დებატების დუბლი (განსაკუთრებით მწვერვალზე).

CPU- ს ბრმა სკეიტი - უგულებელყოფს რეალურ მეტრიკას (დრო 'bet. place ', რიგის სიგრძე).

ქვეყნის გადახდის ერთი მიმწოდებელი - არაფერია გასაფორმებელი, როდესაც ის „დევს“.

მასშტაბის განხორციელების ჩამონათვალი

სტრატეგია

განსაზღვრულია SLO (p95 ლატენტობა, შეცდომები, RPS) და შეცდომების ბიუჯეტი.
დომენების სეგმენტი: ფული/განაკვეთები/სალარო - დამოუკიდებლად მეორეხარისხოვანი ფიშებისგან.

მონაცემები

შარდვა/რეპლიკები, CQRS კითხვისთვის, მატერიალიზებული წარმოდგენებისთვის.
ქეში ფენა, რომელსაც აქვს აშკარა შეზღუდული შესაძლებლობის მქონე პოლიტიკა.

ინფრასტრუქტურა

HPA/VPA, სხვადასხვა სხეულის აუზები, PDB და პრიორიტეტები.
Geo-routing, multi-AZ, მზადყოფნა DR- სთვის.

პროგრამები

IdempotencyKey ფულისთვის/გადახდისთვის/ვებჰუკისთვის.
Circuit breakers და Timauts; backpressure/რიგები.
Feature flags და canarey.

დაკვირვება

ტრეისი (ingress-API - საფულე - პროვაიდერი - webhook).
დაშბორდები RPS/latence/errors/queues/QoS ნაკადი.
ალერტას ზრდა „reect _ rate“ და „round“ - ის დეგრადაცია. settle`.

ღირებულება

სწორი requests/limits, სპოტები ფონის დავალებებისთვის, ავტომობილი-ძილი არა-პირქუში.

ინფრასტრუქტურის მასშტაბი არ ეხება „მეტ სერვერს“. ეს ეხება კონტროლირებად ელასტიურობას: სადაც საჭიროა მკაცრი თანმიმდევრულობა (ფული) - ჩვენ ვქმნით შარდის ბირთვს და სწრაფ გარიგებებს; სადაც შეგიძლიათ - გადავიტანოთ მოვლენები, ხაზები და ქეში. ამას დაამატეთ დაკვირვება, გეოგრაფია და გამოშვების დისციპლინა - და პლატფორმა გაუძლებს ნებისმიერ მწვერვალს კომპრომისის გარეშე SLO, P&L და მოთამაშეთა ნდობას.