Როგორ არის მოწყობილი failover და სარეზერვო iGaming

რატომ არის iGaming სპეციალური DR/BCP დისციპლინა

კაზინოს პლატფორმა არის რეალურ დროში ფული (საფულე/ლეგენდა), ცოცხალი რაუნდები (RNG/Live), გადახდები, აფილიტები და მკაცრი შესაბამისობა. ხელმისაწვდომობის ნებისმიერი „ხვრელი“ სწრაფად გადაიქცევა ფინანსურ და იურიდიულ რისკებად. აქედან გამომდინარე, არქიტექტურა აგებულია პროგნოზირებადი აღდგენის გარშემო: ცნობილი მიზნები, ცნობილი სცენარები, რეპეტიციური პროცედურები.

ძირითადი მიზნები და ტერმინები

RTO (Recovery Time Objective): მომსახურების აღდგენის დრო.

საფულე/მენეჯერისთვის: 60-300 წამი (შიდა რეგიონალური ყალბი), 15 წუთი (ინტერრეგიონალური DR).

RPO (Recovery Point Objective): დასაშვები მონაცემთა დაკარგვა.

მენეჯერისთვის: 0-5 წამი (სინქრონული/კვაზისინქრონული რეპლიკაცია), მოხსენებისთვის: 15 წუთი.

SLA და Error Budget: ფორმალურად კომპრომისები ცვლილებების სიჩქარესა და სტაბილურობას შორის.

წინააღმდეგობის ფენა

1) ინფრასტრუქტურა: Multi-AZ/Multi-Region

Multi-AZ (მინიმუმ 3 ზონა): ყველა კრიტიკული მომსახურება განაწილებულია ზონების მიხედვით, BD/ავტობუსის ავტომატური ყალბი.

Multi-Region DR: „ცხელი“ (Active-Active) ან „Active-Passive“ მეორე რეგიონი, რომელსაც აქვს იზოლაცია იურისდიქციებში (მონაცემთა აღდგენა).

გამოსავალი, როდის რა რეჟიმია:

Active-Active: დაბალი ლატენტობა ორ რეგიონში მოთამაშეთა მიმართ, cross-region ლეგენდა მოვლენების სინქრონიზაციის გზით + მკაცრი ერთეული „ჭეშმარიტების ადგილი“ გაანგარიშებისთვის.
აქტიური (warm): უფრო მარტივი და იაფი; ვნება ინარჩუნებს თბილ ინსტანციებს + BD რეპლიკებს, მაგრამ არ ემსახურება ტრეფიკს.

2) ქსელი და პერიმეტრი

დუბლირებული ingress/WAF, Anycast ან DNS ფეილოვერი ჯანმრთელობის შემოწმებით.

ცალკეული egress კარიბჭეები სალაროებისა და პროვაიდერებისთვის, ორივე რეგიონში IP ნებადართული სიები.

3) მონაცემები და რიგები

სარელეო BD (Postgres): Patroni/მმართველი HA, სინქრონული შენიშვნები AZ- ში, ასინქრონული რეპლიკა DR რეგიონში (ლაგების მონიტორინგით). PITR სნაიპშოტებით ყოველ N წუთში + WAL არქივი.

OLAP (ClickHouse/BigQuery): რეპლიკაცია/შარდვა; დაკარგვა დასაშვებია ზემოთ (RPO 15-30 წუთამდე).

კეში (Redis): მტევანი failover- ით, მაგრამ არა ჭეშმარიტების წყარო; გადართვისას - თბილი დათბობა.

მოვლენების ავტობუსი (Kafka/NATS): სარკის მტევანი ან/ან cross-cluster-mirroring, გარანტია „at-least-once“, მომხმარებლებზე idempotent- ის კონტროლი.

4) პროგრამები და დომენები

საფულე/ლეგენდა: stateful ბირთვი მკაცრი თანმიმდევრობით, რეგიონში ერთი „მასტერ-მხედარი“; ინტერრეგიონალური DR- ით - „ელექტრული ჩაწერის“ პროცედურა ორმაგი ჩაწერის ბლოკირებით.

თამაშის bridge/API: stateless, ჰორიზონტალური ფეილოვერი ჯანმრთელობის შემოწმებისთვის; idempotencyKey ყველა ფინანსური გზისთვის.

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

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

5) ცოცხალი ნაკადები

WebRTC/LL-HLS გეითვეი რეგიონალური edge კვანძებით; fallback მარშრუტები LL-HLS- ზე WebRTC- ის დეგრადაციის დროს.

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

Failover ნიმუშები

აქტივი აქტივი (ორი რეგიონალური)

დადებითი: მინიმალური RTO/RPO, ფეხბურთელებთან სიახლოვე.

უარყოფითი: მენეჯერის სირთულე და ჩაწერის კონფლიქტი, ძვირადღირებული ქსელი.

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

აქტივი (თბილი)

დადებითი: ფასების/სირთულის ბალანსი.

უარყოფითი მხარეები: RTO უფრო მაღალია, თქვენ გჭირდებათ პასიური რეგიონის „პოპულარიზაციის“ შემუშავებული გეგმა.

პრაქტიკა: ავტომატიზაცია + სახელმძღვანელო დადასტურება (4 - თვალის პრინციპი) საფულის გადართვისას.

შიდა რეგიონი (Multi-AZ)

BD/Kash/ingress ავტოფეილერი.

DNS/Anycast- ის შეცვლის გარეშე, RTO წამი-წუთები.

სარეზერვო (Backup) მონაცემთა კლასებში

კლასი	მაგალითები	მეთოდი	სიხშირე	შენახვა	გადამოწმება
ფულის გარიგებები/ლეჯერი	Postgres (საფულე, ლეჯერი)	Snaphots + WAL არქივი (PITR), ლოგიკური შენიშვნა	5-15 წუთი WAL, Snapshot 1-4 საათი	ობიექტის საცავი Object Lock (WORM), ჯვარედინი რეგიონი	ყოველკვირეული DR აღდგენა „ცივ“ + საკონტროლო თანხების შედარება
მოვლენები	კაფკას ტოპები	Tiered storage + mirror в DR	განუწყვეტლივ	ობიექტის საცავი	საცდელი ფანჯრები
OLAP/ანგარიში	ClickHouse/BigQuery	Snaphots/პარტიების ექსპორტი	1-6 საათი	ობიექტის საცავი	საკონტროლო ნიმუშების კითხვა
სტატიკური ნიმუშები	ბილეთები, ლოგები, ექსპორტი	ვერსირებული S3, Glacier	ყოველდღიურად	WORM/ვერსიები	პერიოდული restore
საიდუმლოებები/გასაღებები	KMS/HSM მეტამონაცემები	ექსპორტი შეფუთვით, ორმაგი კონტროლით	გრაფიკით	HSM შენიშვნები	გაშიფვრის ტესტი

პრინციპები:

Becap დაშიფრულია მარტო და ტრანზიტში, გასაღებები KMS/HSM- ში.
Immutable რეჟიმი (WORM) კრიტიკული ზურგჩანთებისთვის (დაცვა წაშლისგან/დაშიფვრისგან).
მეტამონაცემების ბეკების კატალოგი (სქემის ვერსია, WAL ფანჯარა, საკონტროლო თანხები).
PITR სავალდებულოა მენეჯერისთვის.

მონაცემები და იდემპოტენტობა: როგორ ავარიდოთ თავი „ხვრელებს“ ფეილოვერში

IdempotencyKey მოთხოვნით 'bet. place`, `payout. request`, `cashier. webhook`.

ლეჯერი მხოლოდ append-only: ხელახალი settle შექმნის კორექტირების ჩანაწერს და არა „გადაწერას“.

ბალანსის გარიგების საკეტები/ვერსია იცავს რბოლებს მწერლის როლის შეცვლისას.

მოვლენების დედუპლიკაცია (consumer-side, hash საკვანძო მინდვრებში).

სალარო, PSP და კრიპტი: გეგმა B ყოველთვის ჩართულია

გადახდის მეთოდის მინიმუმ ორი მიმწოდებელი (ბარათი/ARM), წინასწარ განსაზღვრული სავაჭრო ანგარიშები ორივე რეგიონში.

Stablecoins- ისთვის - ორი ქსელი (მაგალითად, TRC-20 და ERC-20) და ორი on/off-ramp პროვაიდერი.

გადახდის როუტერი: ჩავარდნის დროს, PSP მყისიერად გადადის სარეზერვო შემადგენლობაში, ატარებს მიზეზების ჟურნალს.

KYT/AML ნაკადები დუბლირებულია; თუ გარე სერვისი მიუწვდომელია, სახელმძღვანელო ესკალაციით „degraded mode“.

ოპერაციული პროცედურები (Runbooks)

ავტომატური

Ingress-API ჯაჭვის ჯანმრთელობის შემოწმება - BD - პროვაიდერის საფულე.

საფულის დეგრადაციის დროს „მძიმე“ ფუნქციების (ტურნირები/მისიები) ავტომატიზაცია.

Taimauts/retrais ექსპონენციალური პაუზით და მკაცრი ვადებით.

სახელმძღვანელო (დადასტურებით)

DR რეგიონის აქტივში დაწინაურება: ნაბიჯების შემსრულებლები, ჟურნალისტიკა, კომიქსების შაბლონები (საფოსტო/პარტნიორები/რეგულატორი).

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

ორმაგი კონტროლის გადასახადების გაყინვა.

სავარჯიშოები და მზადყოფნის შემოწმება

Game Day/Chaos Drill ყოველთვიურად: AZ გამორთვა, BD- ის დეგრადაცია, პროვაიდერის დაცემა.

Full DR Rehearsal კვარტალურია: DR რეგიონის „სრული ზრდისთვის“ ამაღლება, განაკვეთების/გადახდების რეალური სცენარების გადატანა.

Restore ტესტები: langer- ის აღდგენა T- ის დროს, შეამოწმეთ საკონტროლო P&L და hash sess.

Table-top შესაბამისობით: ვინ და ვის აცნობებს, რომელი მოხსენებები იქმნება (რეგულატორი, PSP, აფილიატები).

დაკვირვება და ფეილოვერის სიგნალები

SLO მეტრიკა: p95 ლატენტური საფულე, წილი 'bet. Rejected ', Settle რაუნდის დრო, SLA გადახდები, BD რეპლიკაციის ლაგი, Kafka Consumers lag.

გადართვის მოვლენები: ალერტები „role change“, „გამოსწორება lag> X“, „object-lock violation“.

Dashboards DR: კვანძების ამჟამინდელი როლი, RPO ქულა (WAL წუთი), PITR ფანჯრის სტატუსი.

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

იურისდიქციის მონაცემების იზოლაცია (EU/UK/CA/...): რეპლიკაცია ნებადართული კანონებით.

ჟურნალები უცვლელი (S3 Object Lock/WORM), რეგულირების ვადა.

საიდუმლოებები: გასაღებების როტაცია, მოვალეობების გამიჯვნა DR ოპერაციებისთვის.

ყველა გადართვისა და აღდგენის აუდიტის ბილიკი.

ანტი-ნიმუშები, რომლებიც არღვევს DR- ს

ერთი PSP/ერთი stablecoin ქსელი ქვეყანაში - არ არსებობს სარეზერვო სარკინიგზო მაგისტრალი.

OLTP და OLAP ერთ მონაცემთა ბაზაზე - აღდგენა ბლოკავს „ცოცხალ“ ოპერაციებს.

არ არსებობს idempotencyKey - დებეტის/გადახდების დუბლები.

Bacaps რეგულარული სარეაბილიტაციო ტესტის გარეშე - „Shrödinger bacap“.

WORM/immutability- ის არარსებობა არის დაუცველობა ინსაიდერის/მავნე მოცილების მიმართ.

DNS Faylover მოკლე TTL და თბილი endpoints გარეშე.

ერთდროულად ორ რეგიონში ლეჯერის ერთი მწერალი არის სახელმწიფო გაყოფა.

უბედური შემთხვევებისთვის მზადყოფნის სია

არქიტექტურა

Multi-AZ ყველა კრიტიკული მომსახურებისთვის, დოკუმენტირებული ტოპოლოგია.
DR რეგიონი აღწერილი როლით (Active-Active/Passive) და ბიუჯეტი.

მონაცემები

Postgres: PITR, Snapshots, lag მონიტორინგი, რეგულარული აღდგენითი ტესტები.
Kafka/NATS: მარცვლეული/არქივი, რაფლის გეგმა.
ClickHouse/OLAP: პარტიული ზურგჩანთები, ნიმუშების აღდგენა.
S3: Obect Lock (WORM), ვერსიები, ჯვარედინი რეგიონი.

პროგრამები

idempotence ფულზე, append-only ლეგენდა, ბალანსის ვერსია.
ავტო-feature-degrade ინციდენტების დროს (ტურნირები/მისიები off).
კანარის შემოწმება რეგიონის გადართვამდე.

სალარო და საძვალე

ორი პროვაიდერი მეთოდით და ორი სტეილერის ქსელი.
გადართვის მიზეზების მარშრუტიზაცია და ჟურნალი.
KYT/AML degrade რეჟიმში ესკალაციით.

ოპერაციები

Runbooks ერთად RACI და მოვალეობის შემსრულებელი ტელეფონები.
ყოველთვიური Chaos დღეები და კვარტალური Full-DR სავარჯიშოები.
საკომუნიკაციო შაბლონები (საფორტი, პარტნიორები, რეგულატორი).

დაკვირვება

დაშბორდები RTO/RPO, ალერტები BD- ს როლის, ლაგების, განაკვეთების/გადახდების უარის თქმის შესახებ.
გადართვისა და აღდგენის აუდიტის ჟურნალი.

iGaming- ის საიმედოობა არ არის „ფეილოვერის ღილაკი“, არამედ ჩვევების სისტემა: გეოგრაფიული იზოლაცია, პროგნოზირებადი RTO/RPO, idempotent ფული, მრავალსაფეხურიანი სალარო, immutable-backs, რეგულარული წვრთნები და გამჭვირვალე კომუნიკაცია. ეს დისციპლინა საშუალებას გაძლევთ განიცადოთ გაუმართაობა ლეჯერში დანაკარგების გარეშე, „ჩაძირული“ რაუნდის გარეშე და მოთამაშეთა და რეგულატორების ნდობის დარტყმის გარეშე.