Snabbare sökningar i samtalsloggen utan flaskhalsar – därför lämnar vi RDS
När man hanterar miljontals telefonsamtal varje dag samlas det snabbt på sig stora mängder data. På Lynes bearbetar vi enorma volymer samtalsloggar — och den siffran växer snabbt. Våra kunder förlitar sig på att kunna komma åt denna data direkt, oavsett om det handlar om att följa upp ett missat samtal, lyssna på ett tidigare samtal eller söka i historiken.
Men även i molnet sätter skalbarheten till slut sina gränser.
Problemet: IOPS, kostnad och skala
Fram tills nyligen körde vi vår samtalsloggsdatabas i Amazon RDS med PostgreSQL i grunden. RDS är pålitligt och lätt att hantera — men när vår datamängd växte gjorde även våra utmaningar det.
Flaskhalsen var inte CPU eller minne. Det var lagrings-IOPS.
Varje sökning som berörde äldre data innebar att kall data behövde läsas från disk, vilket snabbt slog i vårt IOPS-tak (runt 15 000). Det går att skala upp IOPS på EBS-volymer — men det är dyrt. Och eftersom det är en backendkostnad vi inte direkt kan ta betalt för, blev det svårt att motivera. Vi ville fortfarande kunna erbjuda blixtsnabba sökningar i äldre samtalsloggar — bara utan att kompromissa med hastighet eller driva upp ohållbara kostnader.
Vi behövde en ny väg framåt.
Lösningen: Självhanterad PostgreSQL i Kubernetes
Vi migrerade vår samtalslogglagring till ett PostgreSQL-kluster i Kubernetes, med snabba NVMe-baserade EC2-instanser — och skillnaden är enorm.
Jämfört med vår tidigare RDS-lösning ger det nya klustret oss:
- ~20x högre IOPS (från 15K till ~250K)
- 2x mer CPU och minne per nod
- Allt till ~10% lägre total kostnad
För tydlighetens skull: RDS är fortfarande ett utmärkt val i de flesta fall. Det är driftsäkert, kräver lite underhåll och fungerar bra med övriga AWS-verktyg. Vi valde att gå en annan väg enbart för att vi redan kör hela vår infrastruktur i Kubernetes, och för att vårt team har tillräcklig operativ kompetens för att hantera det. Det krävdes en hel del handpåläggning — men det var värt det, givet våra mål kring skala och prestanda.
En enklare, smartare arkitektur
Tidigare i RDS hade vi ett enkelt primär-replika-upplägg — men både läs- och skrivtrafik gick till primärnoden. Replikan fanns där bara som failover.
Med det nya upplägget har vi tagit ett stort kliv framåt:
- En primärnod hanterar skrivningar (och viss läsning)
- Två replikanoder hanterar alla sökfrågor
- Alla repliker kan ta över som primär vid failover
Det är fortfarande en enkel arkitektur — men nu är den optimerad för både robusthet och snabb sökning i stora datamängder.
En smidigare övergång än väntat
Vi planerade ursprungligen en gradvis migrering från RDS. Men i praktiken gick det snabbare än väntat. Vi bytte helt enkelt över till det nya klustret — och när allt fungerade som det skulle, tog vi bort den gamla RDS-instansen.
Ibland är den rakaste vägen den bästa.
Inbyggd robusthet
Alla nya samtalsloggar strömmar automatiskt till S3 via Firehose och lagras med korrekt taggning och versionshantering. Det ger oss ett pålitligt skyddsnät — även vid förändringar i infrastrukturen.
Och om PostgreSQL skulle gå ner tillfälligt, kan vi fortfarande hämta färska loggar direkt från S3 för enkla uppslag. Det gör att kunderna alltid har tillgång till viktig data, även i gränsfall. Denna flerlagrade strategi ger nära noll RPO och flera oberoende återställningsvägar — både före och efter ingestion — vilket kraftigt ökar systemets motståndskraft.
Framåt: smartare retention med TimescaleDB
Vi har redan installerat TimescaleDB-tillägget i vårt kluster — inte för omedelbar användning, utan för framtiden.
När samtalshistoriken växer vill vi ha en smartare lösning än att bara radera gamla rader. TimescaleDB:s automatiska partitionering, komprimering och potentiella stöd för vektordata kommer att hjälpa oss att hantera långtidslagring effektivt och utan att tappa i prestanda.
När tiden är mogen kommer vi kunna hålla mer historik tillgänglig — utan att kompromissa med hastigheten.
Vad det här betyder för Lynes kunder
- Snabbare åtkomst till samtalsloggar — särskilt över längre tidsperioder
- Effektiv infrastruktur — byggd för skala och fart
- Robust fallback — med säker backup till S3
- Ingen kompromiss på säkerhet eller lagring
Och allt sker sömlöst i bakgrunden — så kunderna får helt enkelt en snabbare och mer tillförlitlig upplevelse.
Vi kommer fortsätta dela med oss av fler tekniska inblickar allt eftersom vi växer. Är du partner, kund eller bara en nyfiken utvecklare — håll utkik!
