ხელმისაწვდომობის ზონები და ჯვარედინი რეგიონები

1) ტერმინები და მიზნები

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

• RTO (Recovery Time Objective) - რამდენი დრო არ შეგიძლიათ მომსახურების გაწევა.
• RPO (Recovery Point Objective) - რამდენი მონაცემების დაკარგვა დასაშვებია.

ჩვეულებრივ: რეგიონის შიგნით, ჩვენ გავაფართოვებთ RTO-5 წუთი, RPO ~ 0-1 წუთი, ინტერრეგიონალურად - RTO - 1 საათი, RPO - 5 წუთი (ეს დამოკიდებულია პროდუქტზე და ბიუჯეტზე).

2) არქიტექტურული მოდელები

2. 1 რეგიონში (multi-AZ)

სტატუსის ფენა: ნაწილდება AZ; დაბალანსება - L4/L7 ჯანმრთელობის შემოწმებებით.
Stateful ფენა: მტევანი სინქრონული რეპლიკაციით (ან კვორუმი) AZ- ს შორის.
კეში/ხაზები: კლასტერული, AZ და ავტომატური failover შარდვით.

2. 2 ინტერ-რეგიონალური

აქტიური: ორივე რეგიონი იღებს ტრაფიკს.

მომხმარებლების მინიმალური ლატენტობა, სწრაფი აღდგენა; - თანმიმდევრულობისა და კონფლიქტების სირთულე.
Active-Passive (ცხელი/warm): მთავარი რეგიონი ემსახურება, მეორე - ცხელი/თბილი მოლოდინით.

მონაცემები უფრო ადვილია, იაფია; - უფრო მაღალი, ვიდრე RTO.
Pilot-Light: მინიმალური „შუქი“ (მონაცემები სინქრონიზებულია, გამოთვლები ვითარდება უბედური შემთხვევის დროს).
DR-backup: მხოლოდ ზურგჩანთები და აღდგენის სცენარი (ყველაზე იაფი და ნელი).

3) მონაცემები და თანმიმდევრულობა

3. 1 მონაცემთა ბაზა

სინქრონული კვორუმი (RPO-0, ლატენტობა): PostgreSQL სინქრონული standbys რეგიონში; განაწილებული BD (CockroachDB/Cassandra) ადგილობრივი კვორუმებით (ადგილობრივი Qurum) და AZ დაბალანსებით.
ასინქრონული ინტერრეგიონალური (RPO> 0, ლატენტობა): Postgres/MySQL ლოგიკური რეპლიკაცია; «global tables» в KV/NoSQL; CDC არის ნაკადი სხვა რეგიონში.
კონფლიქტური ჩანაწერები: აქტიური აქტიურობისთვის გამოიყენეთ CRDT/ვერსია ან „ჭეშმარიტების წყარო“ სტრატეგია.

3. 2 ღონისძიება და რიგები

რიგები/ნაკადები (Kafka/Pulsar/SQS მსგავსი): mirror-topics ან ჯვარედინი რეგიონალური რეპლიკატორები; გასაღები არის Consumers idempotence და dedup კლავიშებზე.
ვებჰუკი და გარე პარტნიორები: ხელი მოაწერეთ, გქონდეთ ანგარიში, შეინახოთ ოფსეტური/შემოწმება ორივე ზონაში.

3. 3 კეში

ადგილობრივი ქეში per რეგიონი (write-through/refresh-ahead); გლობალური საერთო ქეში მხოლოდ გამძლე KV- სთვის (წინააღმდეგ შემთხვევაში split-brain). ინვალიდობა (pub/sub), TTL - კონსერვატიული.

4) გლობალური ტრაფიკი და ქსელის კონტური

GSLB/DNS: Geo-/Latency-based routing, health checks, „traffic weights“ კანარებისა და უბედური შემთხვევებისთვის.
Anycast/Edge: ჩვენ ვუახლოვდებით მომხმარებლის შესასვლელს, შემდეგ უახლოეს ჯანმრთელ რეგიონს.
Failover პოლიტიკოსები: upstream- ის რეგიონალური აუზები, კრიტიკულ მარშრუტებზე 0-RTT აკრძალვა, რეგიონალურ დამოკიდებულებებზე დაბალი ტაიმაუტები.
Retray პოლიტიკოსები: ექსპონენციალური backoff + gitter, total-deadline შეზღუდვა, idempotent PUT/POST 'Idempotency-Key'.

5) Kubernetes და mesh

5. 1 Multi-AZ ერთ კლასტერში

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - თავიდან აიცილოთ რეპლიკების მოწყობა.
შენახვის ადგილები: PV რეპლიკაციით AZ- ით ან განაწილებული volume სისტემებით.

5. 2 Multi-region (multi-cluster)

ცალკეული მტევანი per რეგიონი + GitOps (Argo CD/Flux) დეკლარაციული სინქრონიზაციისთვის.
Service Mesh (Istio/Linkerd): load-balancing და failover რეგიონებს შორის; mTLS, საერთო თვითმყოფადობა.
Traffic-shifting: ეტაპობრივად 1% - 10% - 50% ახალი რეგიონისთვის; სახელური „მიეცი 0%“ მყისიერად.

6) RTO/RPO არჩევანი და ნიმუშების მითითება

7) წინააღმდეგობის ტესტირება (DR)

GameDays: კვარტალური სრულმასშტაბიანი სცენარი „რეგიონი/AZ“.
Chaos ინექციები: ქსელის შეფერხებები, პაკეტების დაკარგვა, ბროკერის/ბაზის გათიშვა ერთ AZ- ში.
RTO/RPO ფაქტობრივი: გაზომეთ მონაცემების გადართვისა და დაკარგვის დრო, გამოაქვეყნეთ ანგარიში.
Runbooks: ეტაპობრივი ინსტრუქციები და „წითელი ღილაკები“ გადართვისთვის (DNS weights, feature-flags, მძიმე დარტყმების გამორთვა).

8) დაკვირვება და კონტროლი

მეტრიკის სექციები რეგიონის/AZ/ტენანტის მიხედვით; p95/p99 ლატენტობა მარშრუტებზე.
SLO და Error Budgets რეგიონში და გლობალურ აუზზე.
ალერტები: ერთი რეგიონის დეგრადაციამ არ უნდა „დააზიანოს“ პეიჯინგი, თუ მეორე ნორმალურ ტრაფიკს ატარებს.
Трейсы: baggage `region`, `az`, `failover=true/false`; მოხსენებები „რამდენი მოთხოვნა წავიდა failover- ზე“.

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

მონაცემთა აღდგენა: PII/გადახდის მონაცემების დაკავშირება გარკვეულ რეგიონებში (იურისდიქცია).
საიდუმლოებები: KMS/smart-HSM ჯვარედინი რეგიონალური კლავიშებით და როტაციით; გააზიარეთ გასაღების მასალები per რეგიონში.
mTLS და რეგიონებს შორის ურთიერთდაჯერებული; შეზღუდეთ ჯვარედინი რეგიონალური egress ACL- ისთვის.

10) ღირებულება და დაზოგვა

Edge ქეში + SWR - ინტერრეგიონალური ეგრისის შემცირება.
სხვადასხვა შენახვის კლასები (ცხელი/warm/cold) და downsampling მეტრიკა/ლოგები.
ავტო-სკალის პროფილები რეგიონების მიხედვით (ღამის მინიმუმი).
სურათების იდენტურობა + დიფერენცირებული კონფიგურაცია გარემოს ცვლილებით/Helm values.

11) ანტიპატერები

ერთი Stateful ოსტატი მთელ სისტემაზე; split-brain კვორუმის გარეშე.
ინტერრეგიონალური სინქრონული ჩანაწერი ერთადერთ RDBMS- ში (აუტანელი ლატენტობა).
გლობალური ქეში ძლიერი თანმიმდევრულობით CRDT- ს გარეშე არის შეშუპება და „ფანტომები“.
Retrai idempotence - ოპერაციების/გადახდების დუბლიკატები.
ერთი „გლობალური“ SLO - მალავს ერთი რეგიონის წარუმატებლობას.
არ არსებობს რეგულარული DR წვრთნები - გეგმები ბრძოლაში არ მუშაობს.

12) iGaming/ფინანსების სპეციფიკა

გადახდის პროვაიდერები/KUS შეირჩევა რეგიონალურად; გააკეთეთ smart-routing PSP- ზე ჯანმრთელობის სიგნალებით, failover სარეზერვო.
იურისდიქცია: PII და ოპერაციების ჟურნალების შენახვა ქვეყნის/რეგიონის შიგნით; ჯვარედინი რეგიონი - მხოლოდ აგრეგატები/ანონიმი.
ლიმიტები/საპასუხისმგებლო თამაში: ადგილობრივი წესები და საათები - ნუ შეამოწმებთ რეგიონებს შორის „შუბლზე“, გამოიყენეთ ღონისძიების თანმიმდევრულობა.
პრემია/ბალანსი: idempotent გასაღებები და „ჭეშმარიტების წყარო“ per tenant/region; ჩანაწერების ჯობი DR- ის შემდეგ.

13) მინი რეცეპტები (ფსევდოკონფიგები)

13. 1 Envoy locality-aware + failover

yaml load_assignment:
endpoints:
- locality: { region: eu, zone: eu-a }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: eu, zone: eu-b }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: us, zone: us-a } # failover target lb_endpoints: [{ endpoint: { address:... } }]
common_lb_config:
zone_aware_lb_config: {}
locality_weighted_lb_config: {}
outlier_detection:
consecutive_5xx: 5 base_ejection_time: 30s

13. 2 Kubernetes topology spread

yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

13. 3 DNS წონის ფეილოვერი (იდეა)

'weight (eu) = 90', 'weight (us) = 10' ჯანმრთელობის შემოწმებები და შემცირებული TTL (მაგრამ არც ისე აგრესიული, 30-120 გვ).

14) მზადყოფნის ჩეკის სია

• განსაზღვრულია RTO/RPO per სერვისი და შეთანხმებულია ბიზნესთან.
• სახელმწიფო განაწილებულია AZ- ში; stateful- ს აქვს კვორუმი/რეპლიკაცია და თანმიმდევრულობის გასაგები მოდელი.
• რეპლიკაცია არის ინტერრეგიონალური (ასინქრონი/CDC), კონფლიქტების/დედუპლიკატორის ტესტები.
• GSLB/Anycast მორგებულია, health checks და weights ავტომატიზებულია.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retrai ერთად jitter, idempotence write; მოკლე ტაიმაუტები ინტერრეგიონალურად.
• DR სწავლებები, იზომება ფაქტობრივი RTO/RPO; შესაბამისი runbook.
• რეგულირების/AZ- ის, SLO- ს და ბურნის სექციებზე დაკვირვება, ალერტები არ „ჩურჩულებენ“ ნორმალურ მუშაობას.
• მონაცემთა აღდგენა/საიდუმლოებები/გასაღებები შეესაბამება მარეგულირებელს.
• ეკონომიკა: egress, შენახვა, სკეიტის პროფილები კონტროლდება.

15) TL; DR

ააშენეთ multi-AZ, როგორც ძირითადი ფენა, მულტიმედია - როგორც ბიზნესის დაზღვევა. შეარჩიეთ Active Active/standby RTO/RPO და ღირებულება, გაითვალისწინეთ მონაცემები შეგნებულად (კვორუმები/CDC/CRDT), მართეთ გლობალური ტრაფიკი GSLB/Anycast- ის მეშვეობით და დაბალანსება. სავალდებულოა: idempotence, მოკლე Timauts, რეგულარული DR სწავლებები, SLO/მეტრიკა რეგიონის/AZ სექციებზე. IGaming/ფინანსებისთვის დაამატეთ რეგიონალური PSP/KYC, მონაცემების მოთხოვნები და იურისდიქციების ცალკეული SLO.