Torrent Gear

Failover, რეპლიკაცია და DR გეგმები კაზინოებისთვის

1) ბიზნეს მიზნები: RTO/RPO და კრიტიკული flow

RTO (რამდენი დრო შეიძლება არ იყოს ხელმისაწვდომი მომსახურება): ლოგინი/კურსი/ანაბარი - წამები/წუთი; მოხსენებები - საათი.

RPO (რამდენი მონაცემი შეიძლება დაიკარგოს): საფულე/გარიგება - ~ 0-30 წამი; ტელემეტრია - წუთი.

კრიტიკული flow: ლოგინი, ანაბარი/გამომავალი, ფსონი/ნაკრები, KYC/AML კოლბეკი, PSP/თამაშის პროვაიდერები.

2) არქიტექტურული შეუსაბამობის ნიმუშები

აქტიური აქტივობა: ორივე რეგიონი ამუშავებს ტრაფიკს; დაბალი RTO/RPO, რთული თანმიმდევრულობა.

Active-Standby: ერთი რეგიონი სამსახურში, მეორე ცხელი; უფრო ადვილია მდგომარეობა, RTO წუთი.

Cell-based: იზოლაცია „უჯრედებზე“ (ბაზარი/ბრენდი), ადგილობრივი ინციდენტები ყველაფერს არ დებს.

Edge Part: Anycast CDN/WAF - რეგიონალური კარიბჭეები - app მტევანი - BD/ქეში რეპლიკაციით.

3) ტრაფიკის მენეჯმენტი და ქსელის ყალბი

Anycast + CDN/WAF: შეწოვა L3/4/7, health ჩეკი origin- ზე.

DNS Faylover (დაბალი TTL, multi-value), Traffic Manager/GSLB ჯანმრთელობის მეტრებში.

BGP განცხადება ანტი-DDoS პროვაიდერის მეშვეობით, ბილიკის სწრაფი შეცვლისთვის.

ჯანმრთელობის შემოწმება (ლოგიკის მაგალითი):


if p95_latency>threshold          5xx_rate>threshold          synthetic_login_fail:
drain(region_A); shift(traffic->region_B, ramp=5min)

4) მონაცემები: საფულე, შეკვეთები, ფსონები

ჭეშმარიტების წყაროა გაყვანილობის ჟურნალი (ledger): მხოლოდ append, impotention 'opotation _ id'.

კოორდინაცია: პერიოდული ჩანაწერების ჯობი ledger, PSP და თამაშების პროვაიდერებს შორის.

Anti Duble: idempotence გასაღებები დეპოზიტებისთვის/კოლბეკებისთვის/გადახდებისთვის; დედუპლიკაცია outbox/inbox.

5) მონაცემთა ბაზის რეპლიკაცია: ვარიანტები და კომპრომისები

ფიზიკური სინქრონული (semi-sync): მინიმალური RPO, შეფერხებების რისკი - წერტილოვანი (საფულე) გამოყენება.

ასინქრონული: უფრო მაღალი პროდუქტიულობა/სიმარტივე, RPO წამი-წუთი - სათამაშო მეტამონაცემებისთვის, საცნობარო წიგნებისთვის.

ლოგიკური (CDC - ნაკადი სხვა რეგიონში): მოქნილი შერჩევა, მოსახერხებელი ჯვარედინი ძრავებისა და ანალიტიკისთვის.

ქეში (Redis/Memcached): არა როგორც ჭეშმარიტების წყარო; რეპლიკა/snaphots, თბილი დაწყება.

PITR: უწყვეტი ჟურნალები (WAL/redo) ოფისის საცავზე, აღდგენის ფანჯარა 7-30 დღის განმავლობაში.

6) თანმიმდევრულობა და დამტკიცების შაბლონები

Saga + Outbox: ბიზნეს გარიგებები, როგორც ნაბიჯების ჯაჭვი, მოვლენების გამოქვეყნება ატომური საშუალებით, რომელიც ჩაწერილია მონაცემთა ბაზაში.

Exactly-once „მნიშვნელობით“: ოპერაციების იდემპოტენტურობა, ბალანსის ვერსიების კონტროლი (optimistic locking).

წარმოსახვითი კონცეფცია არა ფუფუნების ნაკადში (ლიდერი, ანალიტიკოსი); ფულის strong.

7) კომპონენტები და მათი ყალბი

API/ზურგჩანთა

Statles კონტეინერები, autoskale, blue-green/canary; კონფიგურაცია საცავის საშუალებით (ვერსირებით).

რიგები/ნაკადები

კვორუმის მტევანი (N = 3/5), ჯვარედინი AZ რეპლიკა; გამეორების პოლიტიკოსები და dlt რიგები.

BD საფულე

პრაიმერები რეგიონ A- ში, სინქრონიზებული რეპლიკა A (სხვა AZ) -ში, ასინქრონული - რეგიონ B- ში; აკრძალულია ავტომატური promote split-brain - მხოლოდ სახელმძღვანელო/სკრიპტი ჩეკის ფურცლით.

ფაილები/KUS არტეფაქტები

ობიექტის საცავი ვერსიით, ჯვარედინი რეგიონალური რეპლიკა/CRR, გასაღებები KMS- ში.

WebSocket/Real-time

შარდინგი კლავიშებზე (table/game/barket), sticky-routing; ფეილოვერში - resubscribe rejoin ნიშნით.

8) გადახდა და თამაშების პროვაიდერები: სიმართლის მრავალი წყარო

PSP ფეილოვერი: თითოეული მეთოდის მინიმუმ 2 პროვაიდერი (ბარათი, საფულეები, კრიპტო).

პროცენტი routing SLA/ღირებულებით/BIN banlists; გამანადგურებელი PSP აპარატის გამორთვა.

თამაშის პროვაიდერები: სარეზერვო არხები/ASN allow-list, ცალკეული გასაღებები რეგიონებში, დროის იზოლაცია.

9) ვებჰუკი და კოლბეკი: სტაბილური ტექნიკა და რეპროდუქცია

Inbox შაბლონი: ჩვენ ვიღებთ ვებჰუკს და ვამოწმებთ ხელმოწერას/NMAS და ვწერთ immutable inbox- ში და ვმუშაობთ idempotent- ის შემქმნელის მიერ.

პროვაიდერების retrais: backoff + dedup 'event _ id '/' signature'.

DR- ით: inbox- ის აბრევიატურა წესრიგის კონტროლით (txn - settlement).

10) Bacaps: სტრატეგია 3-2-1 და აღდგენის შემოწმება

გადამზიდავის 3 ეგზემპლარი/2 ოფსეტური (და 1 - ოფლაინ/WORM კრიტიკული ჟურნალებისთვის).

გრაფიკები: ყოველდღიური სლაიდები + მუდმივი ჟურნალები; ყოველკვირეული ტესტის აღდგენა „ბნელ“ სტენდზე.

აღდგენის კატალოგები: „როგორ ავამაღლოთ საფულე t-C- ის დროს“.

11) DR გეგმა: როლები, სკრიპტები, კომუნიკაციები

Роли: Incident Commander, Comms, DB Lead, App Lead, Payments/Game PM, SRE Oncall.

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

სკრიპტები (მინიმალური):

AZ- ის დაკარგვა, რეგიონის დაკარგვა, PSP- ის მიუწვდომლობა, BD კლასტერის დაცემა, თამაშების პროვაიდერის დეგრადაცია, გასაღების გაჟონვა, 5xx მასა.

12) DR სცენარის მატრიცის მაგალითი

სცენარი	დეტაჟი	მოქმედებები	RTO	RPO	გამოსვლის კრიტერიუმი
რეგიონი A მიუწვდომელია	Synthetics+GSLB	Shift ტრაფიკი B, promote BD, გამორთეთ მძიმე ფიჩები	10-20 წუთი	30 წამი	p95 OK, 5xx<0. 5%
PSP-1 დეგრადაცია	შეცდომები 3DS/timeout	Routing შეცვლა PSP-2- ზე, ჩართეთ ლიმიტები	2-5 წუთი	0	Success rate>99%
BD საფულე ვერ მოხერხდა	Heartbeat/replication lag	Promote standby, ledger- ის გადამოწმება, დასკვნების ჩართვა	5-10 წუთი	5 წამი	Ledger=OK
Lag თამაშების პროვაიდერი	RTT/გაშვების დრო	გადაიტანეთ ტრეფიკი ალტერნატიულ მაგიდებზე/პროვაიდერზე	1-3 წუთი	0	TTFS <800 ms

13) Runbook 'და ავტომატიზაცია

ღილაკი „DR-cutover“: მოვალეობის შემსრულებელი ნაბიჯების თანმიმდევრობა (freeze writes - promote - warm caches - ramp traffic).

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

Feature-flags: სწრაფი disable რეპორტი/ექსპორტები/მძიმე დაშბორდები ავარიის დროს.

14) დაკვირვება ფეილოვერისთვის

SLO მეტრიკა, როგორც გამომწვევი: ლოგინი, ანაბარი, განაკვეთი, თამაშის დაწყება.

Технические: replication-lag, WAL-shipping, queue-lag, 5xx, p95, SYN backlog, WebSocket disconnects.

სინთეტიკური სცენარები სხვა რეგიონებიდან: ლოგინი/ანაბარი/ფსონი ყოველ წუთს.

End-end ტრეკები, ეტიკეტები 'region', 'psp', 'game _ provider'.

15) Chaos/DR სწავლებები

GameDay არის კვარტალი: AZ გამორთვა, PSP დეგრადაცია, BD კვანძის „დაკარგვა“, რიგის გაჩერება.

რეტროსპექტივა: გადაწყვეტილების მიღების დრო, დაკარგული ალერტები, ხმაური, ვიწრო ადგილები.

RTO/RPO კორექტირება და ავტომატიზაცია ფაქტების საფუძველზე, და არა „შეგრძნებები“.

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

გასაღებები/საიდუმლოებები KMS/HSM (ჯვარედინი რეგიონალური), როტაცია და ორმაგი კონტროლი.

WORM/immutability აუდიტის და გარიგების ჟურნალებისთვის.

DPA/კონტრაქტები PSP/პროვაიდერთან SLA/DR ვალდებულებებზე და 24 × 7 საკონტაქტო წერტილებზე.

17) Faylover- ის მინიმალური პოლიტიკის მაგალითი (ფსევდო კოდი)


on Incident(type="REGION_DOWN"):
freeze_non_critical_writes()
promote_db(region=B)
verify_ledger_consistency()
warm_caches(region=B)
route_traffic(region=B, ramp=10%)
for step in [25%, 50%, 100%]:
if SLO_green(): ramp(step) else rollback()
announce_statuspage()

18) მზადყოფნის სია

განსაზღვრულია RTO/RPO თითოეული flow; მიღებული ბიზნესი.
Multi-AZ მინიმალური; მრავალჯერადი გადახდა საფულეზე, ლოგინზე და გადახდაზე.
Ledger + idempotence (keys) + outebox/inbox; ჩანაწერების გრაფიკის მიხედვით.
DD რეპლიკაცია: sync ადგილობრივად, async DR- ში; PITR ჩართულია, შემოწმებულია restore.
ორი PSP მეთოდი, როუტინგის პოლიტიკა და ტესტის გასაღებები; თამაშების პროვაიდერები ალტერნატივაა.
DNS/GSLB/Anycast, health ჩეკები და სინთეზური, დაბალი TTL.
Runbook 'და „DR-cutover ღილაკი“, დეგრადაციისთვის feature-flags.
SLO/alerty/tracing; DR სტატუსის პანელი.
კვარტალური DR სწავლებები + რეტრო; განახლებული კონტაქტები 24 × 7.

რეზიუმე

საიმედო iGaming პლატფორმა აგებულია ფულადი მიკროსქემის გარშემო: გამტარუნარიანობის ჟურნალი, პროგნოზირებადი ფეილოვერი, გადამოწმებული რეპლიკაცია და რეგულარული DR წვრთნები. გაყოფილი სისტემა უჯრედებსა და რეგიონებში, ავტომატიზაცია მოახდინეთ cutover- ზე, შეინარჩუნეთ ორი PSP და სათადარიგო თამაშების პროვაიდერები, დააკვირდით SLO- ს და ლედგერის მთლიანობას - და კიდევ დიდი უბედური შემთხვევა გახდება კონტროლირებადი მოვლენა ნდობისა და ფულის დაკარგვის გარეშე.