Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53
Uruchamiać pełną moc produkcyjną jednocześnie w co najmniej dwóch Regionach, korzystając z DynamoDB Global Tables, Aurora Global Database i routingu Route 53 opartego na opóźnieniu.
Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53 to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.
Definicja multi-site active-active
Multi-Site Active-Active to najwyższy poziom odtwarzania po awarii, w którym aplikacja działa jednocześnie z pełną wydajnością produkcyjną w co najmniej dwóch regionach AWS. W przeciwieństwie do architektury active-passive, gdzie środowisko zapasowe czeka na przejęcie obsługi, w architekturze active-active oba regiony przez cały czas obsługują rzeczywisty ruch użytkowników. Gdy jeden region ulegnie awarii, drugi natychmiast przejmuje 100% ruchu, bez opóźnienia związanego z przełączeniem awaryjnym. Ten wzorzec zmniejsza również opóźnienia użytkowników rozproszonych globalnie, obsługując ich z najbliższego regionu.
# Active-Active traffic split (normal operation):
# us-east-1: serving ~50% of users (North America)
# eu-west-1: serving ~50% of users (Europe)
# Active-Active traffic split (us-east-1 failure):
# us-east-1: 0% (health check failed)
# eu-west-1: 100% (ASG scales up automatically)
# RTO: near-zero (DNS TTL propagation only)
# RPO: near-zero (with DynamoDB Global Tables)Architektura DynamoDB Global Tables
DynamoDB Global Tables stanowi podstawę danych dla architektur active-active. Global Tables umożliwia replikację multi-master w wielu regionach — aplikacje w dowolnym regionie mogą odczytywać i zapisywać dane w lokalnej tabeli DynamoDB, a zmiany są replikowane do wszystkich pozostałych regionów w ciągu około 1 sekundy. Global Tables włącza się, wskazując regiony, w których tabela ma istnieć. AWS automatycznie obsługuje replikację, rozwiązywanie konfliktów (last-writer-wins) oraz przełączanie awaryjne.
# Create DynamoDB table and add global regions
aws dynamodb create-table \
--table-name UserSessions \
--attribute-definitions AttributeName=userId,AttributeType=S \
--key-schema AttributeName=userId,KeyType=HASH \
--billing-mode PAY_PER_REQUEST \
--region us-east-1
# Add replica regions for Global Table
aws dynamodb update-table \
--table-name UserSessions \
--replica-updates '[{"Create":{"RegionName":"eu-west-1"}},{"Create":{"RegionName":"ap-southeast-1"}}]' \
--region us-east-1Aurora Global Database dla aktywnych zapisów i odczytów
Aurora Global Database zapewnia aktywne odczyty w wielu regionach, ale zapisy w trybie active-passive. Wszystkie regiony dodatkowe obsługują odczyty z opóźnieniem replikacji poniżej 1 sekundy, podczas gdy zapisy są przyjmowane tylko w regionie podstawowym. Jest to idealne rozwiązanie dla aplikacji intensywnie korzystających z odczytów, które wymagają niskich opóźnień odczytu na całym świecie i jednego jasno określonego regionu podstawowego dla zapisów. W przypadku regionalnej awarii regionu podstawowego można awansować region dodatkowy do roli podstawowego w czasie krótszym niż 1 minuta, uzyskując niski RTO dla warstwy zapisów. W przeciwieństwie do tego DynamoDB Global Tables obsługuje zapisy active-active we wszystkich regionach.
# Aurora Global Database read configuration
# Primary region (us-east-1): reads + writes
# Secondary region (eu-west-1): reads only
# ~100ms replication lag, serves EU users low-latency reads
# Application reads from local Aurora endpoint
# Application writes to primary region Aurora endpoint
# Java connection string with region routing:
# readEndpoint=eu-west-1.cluster-ro-xxx.aurora.amazonaws.com
# writeEndpoint=us-east-1.cluster-xxx.aurora.amazonaws.comRouting Route 53 dla architektury active-active
Route 53 pełni funkcję dyrektora ruchu w architekturach multi-site active-active. Należy użyć routingu opartego na opóźnieniach, aby kierować każdego użytkownika do regionu zapewniającego najniższe opóźnienie sieciowe z jego lokalizacji. Do każdego rekordu regionalnego należy dołączyć kontrole stanu — gdy region nie przejdzie kontroli stanu, Route 53 automatycznie usuwa go z odpowiedzi DNS, kierując cały ruch do pozostałych zdrowych regionów. Należy ustawić wartość TTL na 60 sekund lub mniej, aby skrócić czas potrzebny użytkownikom na przełączenie do zdrowego regionu.
# Route 53 latency routing with health checks
aws route53 change-resource-record-sets \
--hosted-zone-id ZXXX \
--change-batch '{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"Region": "us-east-1",
"SetIdentifier": "us-east-1",
"HealthCheckId": "hc-us-east-1",
"AliasTarget": {"DNSName": "alb-us-east-1.amazonaws.com", "EvaluateTargetHealth": false}
}
}
]
}'Auto Scaling na potrzeby przejęcia ruchu
Gdy jeden region ulegnie awarii w konfiguracji active-active, działający region musi obsłużyć co najmniej dwukrotnie większy ruch niż zwykle. Państwa Auto Scaling Group musi mieć wystarczającą maksymalną pojemność oraz zasady skalowania w górę, które szybko reagują na zmiany. Należy skonfigurować skalowanie oparte na śledzeniu wartości docelowej, korzystając z liczby żądań ALB przypadających na cel, aby ASG automatycznie dodawała instancje, gdy ruch się podwaja. Warto również rozważyć wstępne rozgrzewanie: podczas ćwiczeń przełączenia awaryjnego należy obserwować, jak szybko ASG skaluje się w górę, i upewnić się, że w ramach docelowego RTO może osiągnąć wymaganą pojemność.
# ASG target tracking for request count
aws autoscaling put-scaling-policy \
--auto-scaling-group-name app-asg-eu-west-1 \
--policy-name scale-on-requests \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 1000,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/xxx/targetgroup/my-tg/yyy"
},
"ScaleInCooldown": 60,
"ScaleOutCooldown": 30
}'Zarządzanie sesjami w architekturze active-active
W architekturze jednego regionu sesje użytkowników mogą być przechowywane lokalnie na serwerach aplikacji. W wieloregionowej architekturze active-active użytkownicy mogą przy kolejnych żądaniach trafiać do różnych regionów, co powoduje problemy z sesjami przechowywanymi po stronie serwera. Możliwe rozwiązania: 1) Sesje bezstanowe — przechowywanie danych sesji w podpisanym JWT lub pliku cookie, który może zweryfikować dowolny serwer w dowolnym regionie. 2) DynamoDB Global Tables na potrzeby sesji — centralne przechowywanie sesji z dostępem w milisekundach z dowolnego regionu. 3) ElastiCache z Global Datastore — replikacja Redis między regionami na potrzeby przechowywania sesji.
# DynamoDB Global Table for session storage
# Session item structure:
{
'sessionId': 'sess-abc123',
'userId': 'usr-456',
'data': {'cart': [...], 'preferences': {}},
'expiresAt': 1750000000,
'lastUpdatedRegion': 'us-east-1'
}
# Application reads from local region DynamoDB
# Writes replicate to all regions within ~1 second
# No sticky sessions needed on the ALBKonflikty zapisów i ich rozwiązywanie
Największym wyzwaniem w architekturze active-active z zapisami multi-master są konflikty zapisów. Jeśli dwóch użytkowników w różnych regionach jednocześnie zaktualizuje ten sam rekord, która aktualizacja powinna wygrać? DynamoDB Global Tables stosuje strategię last-writer-wins na podstawie znacznika czasu zapisu. Działa to dobrze w większości przypadków, ale może prowadzić do utraty danych przy konkurujących aktualizacjach (np. gdy dwóch użytkowników jednocześnie zwiększa licznik). Model danych należy projektować tak, aby unikać jednoczesnych zapisów tego samego elementu z różnych regionów — można w tym celu użyć zapisów warunkowych lub podzielić własność danych według regionów.
# Avoid conflicts with conditional writes
aws dynamodb update-item \
--table-name UserProfiles \
--key '{"userId":{"S":"usr-123"}}' \
--update-expression 'SET profileVersion = profileVersion + :inc, username = :name' \
--condition-expression 'profileVersion = :expectedVersion' \
--expression-attribute-values '{
":inc":{"N":"1"},
":name":{"S":"newname"},
":expectedVersion":{"N":"5"}
}'
# If another region already updated version, this fails gracefullyReplikacja S3 w architekturze active-active
W przypadku przechowywania obiektów w architekturze active-active należy użyć S3 Cross-Region Replication z replikacją dwukierunkową (dostępnej dla zasobników z włączonym przechowywaniem wersji). W przeciwieństwie do jednokierunkowej CRR replikacja dwukierunkowa utrzymuje synchronizację zasobników w obu regionach — obiekty zapisane w dowolnym regionie są automatycznie replikowane do drugiego. Ma to kluczowe znaczenie dla aplikacji, które zapisują pliki przesłane przez użytkowników w lokalnym zasobniku S3, ale muszą zapewniać globalny dostęp do tych plików. Należy włączyć funkcję S3 Replication Time Control (RTC), aby zagwarantować, że 99,99% obiektów zostanie zreplikowanych w ciągu 15 minut.
# Bidirectional S3 replication
# Bucket A (us-east-1) replicates to Bucket B (eu-west-1)
# Bucket B (eu-west-1) replicates to Bucket A (us-east-1)
# Enable S3 RTC for guaranteed replication time
aws s3api put-bucket-replication \
--bucket us-east-1-uploads \
--replication-configuration '{
"Rules": [{
"Status": "Enabled",
"ReplicationTime": {"Status": "Enabled", "Time": {"Minutes": 15}},
"Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}},
"Destination": {"Bucket": "arn:aws:s3:::eu-west-1-uploads"}
}]
}'CloudFront z originami w wielu regionach
Należy użyć CloudFront z grupami originów, aby utworzyć sieć CDN active-active z automatycznym przełączaniem awaryjnym. Należy skonfigurować origin podstawowy (ALB w us-east-1) oraz origin dodatkowy (ALB w eu-west-1). CloudFront automatycznie przełącza się na origin dodatkowy, gdy origin podstawowy zwraca błędy 5xx. W przypadku zasobów statycznych udostępnianych z S3 należy skonfigurować grupy originów wskazujące zasobniki S3 w wielu regionach, z replikacją dwukierunkową. Zapewnia to dodatkową warstwę odporności na poziomie CDN, uzupełniającą routing active-active w Route 53.
# CloudFront origin group for multi-region failover
aws cloudfront create-distribution \
--distribution-config '{
"Origins": {
"Quantity": 2,
"Items": [
{"Id": "us-east-1", "DomainName": "alb-us-east-1.amazonaws.com"},
{"Id": "eu-west-1", "DomainName": "alb-eu-west-1.amazonaws.com"}
]
},
"OriginGroups": {
"Items": [{
"Id": "multi-region-group",
"FailoverCriteria": {"StatusCodes": {"Items": [500,502,503,504]}},
"Members": {"Items": [{"OriginId": "us-east-1"},{"OriginId": "eu-west-1"}]}
}]
}
}'Monitorowanie stanu architektury active-active
Architektury active-active wymagają solidnego monitorowania, aby zapewnić prawidłowy stan obu regionów i oczekiwany rozkład ruchu. Najważniejsze metryki to: Route 53 HealthCheckPercentageHealthy dla każdego regionu, DynamoDB ReplicationLatency do monitorowania opóźnienia Global Tables, ALB RequestCount dla każdego regionu w celu weryfikacji rozkładu ruchu oraz panele kontrolne CloudWatch obejmujące wiele kont i regionów zapewniające ujednolicony widok. Należy ustawić alarmy, gdy opóźnienie replikacji przekroczy próg RPO lub gdy rozkład ruchu stanie się znacząco niezrównoważony.
# CloudWatch alarm for DynamoDB Global Table replication lag
aws cloudwatch put-metric-alarm \
--alarm-name 'GlobalTable-ReplicationLag-eu-west-1' \
--metric-name ReplicationLatency \
--namespace AWS/DynamoDB \
--dimensions Name=TableName,Value=UserSessions Name=ReceivingRegion,Value=eu-west-1 \
--period 60 \
--evaluation-periods 3 \
--threshold 5000 \
--comparison-operator GreaterThanThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-alertsKiedy wybrać architekturę active-active
Architektura active-active jest odpowiednia, gdy: użytkownicy są rozproszeni globalnie, a opóźnienie związane z obsługą z jednego regionu jest nieakceptowalne. RTO musi być bliskie zeru — firma nie może pozwolić sobie nawet na kilka minut przestoju. Duża przepustowość zapisów wymaga rozłożenia zapisów między regionami. Wymogi regulacyjne nakazują przetwarzanie danych w kraju. Koszt jest znacznie wyższy niż w przypadku innych poziomów DR, dlatego architekturę active-active należy wybierać tylko wtedy, gdy wymagania biznesowe i względy ekonomiczne wyraźnie to uzasadniają. W przypadku wielu obciążeń Warm Standby jest wystarczające i znacznie tańsze.
# Active-Active justification checklist:
# [ ] Users in 2+ continents with latency SLAs
# [ ] RTO requirement < 5 minutes
# [ ] Revenue impact of downtime justifies 2x+ cost
# [ ] Data must remain within specific regions (regulations)
# [ ] Write throughput exceeds single-region capacity
# If fewer than 2-3 boxes checked:
# Consider Warm Standby instead (lower cost, adequate RTO)Szybkie sprawdzenie
Proszę sprawdzić swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji dowiedzieli się Państwo, że: DynamoDB Global Tables umożliwia zapisy multi-master między regionami, zapewniając prawdziwą architekturę active-active, routing oparty na opóźnieniach w Route 53 wraz z kontrolami stanu kieruje użytkowników do najbliższego zdrowego regionu, a zarządzanie sesjami w architekturze active-active musi być bezstanowe lub korzystać z globalnie replikowanego magazynu. Architektura active-active zapewnia niemal zerowe RTO i RPO, ale wiąże się ze znacznie wyższym kosztem. W następnej części omówimy filary Operational Excellence i Security w AWS Well-Architected Framework.
Często zadawane pytania
Czy lekcja „Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53” jest bezpłatna?
Tak — pełny tekst „Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.
Co nauczysz się w „Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53”?
Uruchamiać pełną moc produkcyjną jednocześnie w co najmniej dwóch Regionach, korzystając z DynamoDB Global Tables, Aurora Global Database i routingu Route 53 opartego na opóźnieniu. Ćwiczysz AWS Solutions Architect z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć AWS Solutions Architect?
Nie wymagamy żadnego doświadczenia. AWS Solutions Architect w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji AWS Solutions Architect?
Tak. Każda lekcja AWS Solutions Architect zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- RTO, RPO i poziomy DR
- Kopia zapasowa i przywracanie
- Pilot light i warm standby
- Wielolokalizacyjna architektura aktywna-aktywna z Global Tables i Route 53