Multi-site Active-Active med Global Tables og Route 53

Aurora Global Database understøtter aktive læsninger, men passive skrivninger. Alle sekundære regioner leverer læsninger med under 1 sekunds replikationsforsinkelse, mens kun den primære region accepterer skrivninger. Det er ideelt til læsetunge applikationer, der ønsker læsninger med lav latenstid globalt og en tydeligt defineret primær skrive-region. Under et regionalt svigt i den primære region kan du promovere en sekundær region til primær på under 1 minut og dermed opnå en lav RTO for skrive-området. Sammenlign dette med DynamoDB Global Tables, som understøtter aktive skrivninger i alle regioner.

Route 53 fungerer som trafikdirigent for active-active-arkitekturer med flere lokationer. Brug latensbaseret routing til at sende hver bruger til den region, der har den laveste netværkslatenstid fra brugerens placering. Tilknyt sundhedstjek til hver regional post — når en region ikke består sit sundhedstjek, fjerner Route 53 den automatisk fra DNS-svarene og sender al trafik til de resterende sunde regioner. Indstil DNS-TTL til 60 sekunder eller mindre for at minimere den tid, det tager for brugere at skifte over til den sunde region.

Når én region svigter i en active-active-konfiguration, skal den overlevende region håndtere 2 gange (eller mere) den normale trafik. Din Auto Scaling Group skal have tilstrækkelig maksimal kapacitet og politikker for opskalering, der reagerer hurtigt. Konfigurer målbaseret skalering baseret på ALB-anmodningstælling pr. mål, så ASG automatisk tilføjer instanser, når trafikken fordobles. Overvej også forvarmning: Under failover-øvelser skal du observere, hvor hurtigt din ASG skalerer ud, og sikre, at den kan nå den krævede kapacitet inden for dit RTO-mål.

I en arkitektur med én region kan brugersessioner gemmes lokalt på applikationsservere. I active-active på tværs af flere regioner kan brugere skifte mellem regioner ved efterfølgende anmodninger, så sessionshåndtering på serversiden bryder sammen. Løsninger: 1) Tilstandsløse sessioner — gem sessionsdata i en signeret JWT eller cookie, som enhver server i enhver region kan validere. 2) DynamoDB Global Tables til sessioner — gem sessioner centralt med adgang på millisekundniveau fra enhver region. 3) ElastiCache with Global Datastore — Redis-replikering på tværs af regioner til lagring af sessioner.

Den største udfordring ved active-active med skrivninger fra flere mastere er skrivekonflikter. Hvis to brugere i forskellige regioner opdaterer den samme post samtidig, hvilken opdatering vinder så? DynamoDB Global Tables bruger den senest skrevne vinder baseret på tidspunktet for skrivningen. Det fungerer godt i de fleste anvendelser, men kan medføre datatab ved konkurrerende opdateringer (f.eks. når to brugere øger en tæller samtidig). Design din datamodel, så samtidige skrivninger til det samme element fra forskellige regioner undgås, ved hjælp af betingede skrivninger eller ved at fordele dataejerskabet efter region.

Til objektlagring i active-active skal du bruge S3 Cross-Region Replication with bidirectional replication (tilgængelig for buckets, hvor versionering er aktiveret). I modsætning til CRR i én retning holder tovejsreplikering begge regionsbuckets synkroniserede — objekter, der skrives i den ene region, replikeres automatisk til den anden. Dette er afgørende for applikationer, der skriver brugeruploadede filer til den lokale regions S3-bucket, men har brug for, at filerne er tilgængelige globalt. Aktivér S3 Replication Time Control (RTC) for at garantere, at 99,99 % af objekterne replikeres inden for 15 minutter.

Brug CloudFront with origin groups til at oprette et active-active-CDN med automatisk failover. Konfigurer en primær oprindelse (ALB i us-east-1) og en sekundær oprindelse (ALB i eu-west-1). CloudFront skifter automatisk over til den sekundære oprindelse, når den primære returnerer 5xx-fejl. For statiske aktiver, der leveres fra S3, skal du konfigurere oprindelsesgrupper, som peger på S3-buckets i flere regioner med tovejsreplikering. Dette tilføjer et robusthedslag på CDN-niveau oven på din active-active-routing med Route 53.

Active-active-arkitekturer kræver robust overvågning for at sikre, at begge regioner er sunde, og at trafikken fordeles som forventet. Vigtige målepunkter er: Route 53 HealthCheckPercentageHealthy pr. region, DynamoDB ReplicationLatency for forsinkelsen i Global Tables, ALB RequestCount pr. region for at kontrollere trafikfordelingen samt CloudWatch cross-account/cross-region dashboards for et samlet overblik. Opret alarmer, når replikationsforsinkelsen overskrider din RPO-tærskel, eller når trafikfordelingen bliver markant skæv.

Active-active er passende, når: brugerne er geografisk spredt, og latenstiden til én enkelt region er uacceptabel. RTO skal være tæt på nul — virksomheden kan ikke acceptere selv få minutters nedetid. Høj skrivegennemstrømning kræver, at skrivninger fordeles på tværs af regioner. Lovgivningsmæssige krav kræver databehandling i det pågældende land. Omkostningerne er væsentligt højere end ved andre DR-niveauer, så vælg kun active-active, når forretningskravene og økonomien tydeligt berettiger det. For mange arbejdsbelastninger er Warm Standby tilstrækkeligt og langt billigere.

I denne lektion har du lært, at: DynamoDB Global Tables muliggør skrivninger med flere mastere på tværs af regioner og dermed ægte active-active, Route 53-latensrouting med sundhedstjek leder brugerne til den nærmeste sunde region, og sessionshåndtering skal være tilstandsløs eller bruge globalt replikeret lagring i active-active. Active-active giver en RTO og RPO tæt på nul, men til betydeligt højere omkostninger. Dernæst ser vi på søjlerne Operational Excellence og Security i Well-Architected Framework.