Raskere anropsloggsøk uten flaskehalser - det er derfor vi forlater RDS

Når du håndterer millioner av telefonsamtaler hver dag, samler det raskt enorme mengder data. Hos Lynes behandler vi enorme mengder samtalelogger — og antallet vokser raskt. Kundene våre stoler på å kunne få tilgang til disse dataene umiddelbart, enten det er å følge opp et tapt anrop, lytte til et tidligere anrop eller søke i historikken.

Men selv i skyen setter skalerbarheten til slutt sine grenser.

‍

Problemet: IOPS, kostnad og skala

Inntil nylig kjørte vi anropsloggdatabasen vår i Amazon RDS ved å bruke PostgreSQL i utgangspunktet. RDS er pålitelig og enkel å administrere - men etter hvert som datasettet vårt vokste, vokste også utfordringene våre.

Flaskehalsen var ikke CPU eller minne. Det var Lagring IOPS.

Ethvert søk som berørte eldre data betydde at kalde data måtte leses fra disken, som raskt traff IOPS-taket vårt (rundt 15 000). det går å skalere opp IOPS på EBS-volumer - men det er dyrt. Og siden det er en backend-kostnad vi ikke direkte kan ta betalt for, ble det vanskelig å rettferdiggjøre. Vi ønsket fortsatt å kunne tilby lynraske søk i eldre samtalelogger - bare uten å gå på akkord med hastigheten eller øke uholdbare kostnader.

Vi trengte en ny vei fremover.

‍

Løsningen: Selvstyrt PostgreSQL i Kubernetes

Vi migrerte vår samtalelogglagring til en PostgreSQL-klynge i Kubernetes, ved hjelp av raske NVMe-baserte EC2-forekomster - og forskjellen er enorm.

Sammenlignet med vår tidligere RDS-løsning gir den nye klyngen oss:

~ 20x høyere IOPS (fra 15K til ~ 250K)
2x mer CPU og minne per node
Alt til ~ 10% lavere totalkostnad

For klarhet: RDS er fortsatt et godt valg i de fleste tilfeller. Det er pålitelig, krever lite vedlikehold og fungerer bra med andre AWS-verktøy. Vi valgte å gå en annen rute utelukkende fordi vi allerede driver hele infrastrukturen vår i Kubernetes, og fordi teamet vårt har tilstrekkelig operasjonell kompetanse til å håndtere det. Det krevde mye praktisk innsats - men det var verdt det, gitt våre mål rundt skala og ytelse.

‍

En enklere og smartere arkitektur

Tidligere i RDS hadde vi et enkelt oppsett for primær replika - men både lese- og skrivetrafikk gikk til den primære noden. Kopien var der bare som failover.

Med denne nye tilnærmingen har vi tatt et stort skritt fremover:

EN primær node håndterer skriving (og litt lesing)
to replikanoder forvalter alle søk
Alle replikaer kan overta som primære i failover

Det er fortsatt en enkel arkitektur - men nå er det optimalisert for både robusthet og raskt søk i store datasett.

‍

En jevnere overgang enn forventet

Vi planla opprinnelig en gradvis migrering bort fra RDS. Men i praksis gikk det raskere enn forventet. Vi byttet ganske enkelt over til den nye klyngen - og da alt fungerte som det skulle, fjernet vi den gamle RDS-forekomsten.

Noen ganger er den retteste veien den beste.

‍

Innebygd robusthet

Alle nye samtalelogger strømmer automatisk til S3 via Firehose og lagret med riktig tagging og versjonering. Det gir oss et pålitelig sikkerhetsnett - selv i tilfelle endringer i infrastruktur.

Og hvis PostgreSQL skulle gå ned midlertidig, kan vi fortsatt laste ned ferske logger direkte fra S3 for enkle oppslag. Dette betyr at kundene alltid har tilgang til viktige data, selv i grensesaker. Denne flerlags tilnærmingen gir nesten null RPO og flere uavhengige gjenopprettingsveier - både før og etter inntak - noe som øker systemets motstandskraft sterkt.

‍

Får fremover: smartere oppbevaring med tidsskaladeDB

Vi har allerede installert TimescaleDB-utvidelsen i klyngen vår - ikke for umiddelbar bruk, men for fremtiden.

Etter hvert som samtaleloggen vokser, ønsker vi en smartere løsning enn bare å slette gamle linjer. TidsskalaDB: s automatisk partisjonering, komprimering og potensiell støtte for vektordata vil hjelpe oss med å administrere langsiktig lagring effektivt og uten å miste ytelsen.

Når tiden er moden, vil vi kunne holde mer historie tilgjengelig - uten å gå på akkord med hastigheten.

‍