Bufringsstrategier: Lazy Loading og Write-Through

Når De setter inn en hurtigbuffer mellom applikasjonen og databasen, trenger De en hurtigbufferstrategi – et sett med regler som avgjør når data legges i hurtigbufferen, når de leses fra den, og når de fjernes. Feil strategi kan føre til enten foreldede data (hurtigbufferen returnerer utdaterte verdier), kalde cache-misser (hurtigbufferen er tom, og hver forespørsel går til databasen) eller cache stampede (mange samtidige forespørsler etter den samme manglende nøkkelen treffer databasen samtidig). De to grunnleggende strategiene er lazy loading og write-through.

Lazy loading (også kalt cache-aside) er det vanligste hurtigbuffermønsteret. Applikasjonen sjekker hurtigbufferen først. Ved en cache hit returneres dataene direkte fra hurtigbufferen – den raske banen. Ved en cache miss henter applikasjonen data fra databasen, skriver resultatet til hurtigbufferen med en TTL og returnerer det til den som foretok forespørselen. Hurtigbufferen fylles bare med data som faktisk etterspørres – derav «lazy». Den neste forespørselen etter samme nøkkel finner dataene i hurtigbufferen.

Lazy loading har tre viktige fordeler: bare etterspurte data hurtigbufres – hurtigbufferen fylles ikke med data ingen leser, slik at minnet utnyttes effektivt. En kald hurtigbuffer stopper ikke applikasjonen – ved cache-misser faller applikasjonen tilbake til databasen, slik at den fortsetter å fungere selv om ElastiCache startes på nytt eller en node svikter (med høyere ventetid). Hurtigbufferen er alltid eventual consistent med databasen, fordi foreldede data utløper via TTL selv om oppdateringer ikke ble fanget opp.

Lazy loading har tre viktige ulemper: cache-misser er kostbare – tre operasjoner (sjekk av hurtigbuffer, lesing fra databasen og skriving til hurtigbufferen) sammenlignet med én ved en cache hit, noe som gir høyere ventetid for kalde forespørsler. Foreldede data – etter en databaseoppdatering leverer hurtigbufferen fortsatt den gamle verdien til TTL-en utløper eller nøkkelen ugyldiggjøres eksplisitt (et vindu med inkonsistens i hurtigbufferen). Cache stampede – hvis en populær nøkkel utløper, får mange samtidige forespørsler et cache-miss og treffer databasen samtidig, noe som potensielt kan overbelaste den.

I strategien write-through skrives alle databaseoppdateringer også til hurtigbufferen samtidig. Applikasjonen skriver til både hurtigbufferen og databasen som del av samme operasjon (eller databasen utløser en oppdatering av hurtigbufferen). Hurtigbufferen er derfor alltid synkronisert med databasen – det finnes ikke noe vindu med foreldede data. Write-through garanterer at dataene i hurtigbufferen alltid er oppdaterte, slik at etterfølgende leseoperasjoner alltid blir cache hits for nylig skrevne data.

Fordelene med write-through er: dataene i hurtigbufferen er alltid ferske – ingen foreldede data fordi hurtigbufferen oppdateres ved hver skriveoperasjon. Leseoperasjoner er alltid raske – populære data som skrives ofte, ligger alltid i hurtigbufferen. Ingen cache stampede ved lesing – fordi dataene forhåndsutfylles før de leses, oppstår det ingen kalde cache-misser for nylig skrevne data. Denne strategien egner seg godt for arbeidsbelastninger med mange leseoperasjoner og hyppige oppdateringer der ferske data er avgjørende, for eksempel produktkataloger, prissystemer eller hurtigbuffere for brukerprofiler.

Ulempene med write-through er: skrivekostnad – hver skriveoperasjon medfører to operasjoner (database + hurtigbuffer), noe som øker ventetiden for skriveoperasjoner. Forurensning av hurtigbufferen – data hurtigbufres selv om de aldri leses igjen (skrevet én gang, aldri etterspurt), noe som sløser med hurtigbufferminne. Omstart av hurtigbufferen gir en kald hurtigbuffer – hvis hurtigbufferklyngen startes på nytt, går alle data som ble skrevet proaktivt tapt, og hurtigbufferen må fylles på nytt gjennom skriveoperasjoner eller en oppvarmingsprosess. Kombiner write-through med en TTL for å hindre ubegrenset vekst av sjelden leste data i hurtigbufferen.

I praksis kombinerer mange produksjonssystemer begge strategiene: bruk write-through for data som oppdateres og leses ofte (for eksempel brukerøkter eller gjeldende priser), og lazy loading for data som oppdateres sjelden, men leses ofte (for eksempel produktbeskrivelser eller artikkelinnhold). Angi passende TTL-er for begge: write-through-nøkler får en lang TTL siden dataene alltid er ferske, mens lazy-loaded-nøkler får en kortere TTL for å begrense vinduet med foreldede data. Denne hybride tilnærmingen maksimerer cache hit-raten samtidig som foreldelse minimeres.

Time-To-Live (TTL) for hurtigbufrede data styrer det maksimale vinduet med foreldede data og hurtigbufferens minneavtrykk. Utform TTL-er basert på: hvor ofte dataene oppdateres (øktdata endres ofte → kort TTL; statisk innhold endres sjelden → lang TTL), toleranse for foreldelse (finansielle priser → svært kort; blogginnlegg → timer eller dager) og tilgjengelig hurtigbufferminne (lite minne → kortere TTL for å fjerne foreldede data raskere). Angi alltid en TTL – hurtigbufre aldri data uten utløp, ellers vil hurtigbufferen til slutt fylles med foreldede data.

I stedet for å bare stole på at TTL-en utløper, kan De ugyldiggjøre (slette) hurtigbuffernøkler eksplisitt når de underliggende dataene endres. Dette fjerner vinduet med foreldede data fullstendig. Vanlige mønstre er: delete-on-write (slett hurtigbuffernøkkelen etter hver databaseoppdatering – neste leseoperasjon fyller den på igjen via lazy loading) og hendelsesdrevet ugyldiggjøring (DynamoDB Streams eller endringsfangst i RDS utløser en Lambda-funksjon som sletter berørte nøkler). Ugyldiggjøring av hurtigbufferen er et av de vanskeligste problemene i distribuerte systemer. Jo enklere logikken for ugyldiggjøring er, desto mer pålitelig blir hurtigbufferen.

Et mindre vanlig, men kraftig mønster er write-behind (write-back): Applikasjonen skriver bare til hurtigbufferen, og hurtigbufferen tømmer asynkront data til databasen i bakgrunnen. Dette gir svært raske skriveoperasjoner (bare i minnet), men med risiko for datatap hvis hurtigbufferen svikter før dataene er skrevet til databasen. Write-behind egner seg for skriveoperasjoner med høy frekvens og stort volum, der dataene kan rekonstrueres eller mindre tap er akseptable – for eksempel treffellere, analysehendelser eller oppdateringer av spillpoeng. ElastiCache støtter ikke write-behind innebygd; det må implementeres i applikasjonslaget.

I denne leksjonen lærte De at lazy loading fyller hurtigbufferen ved leseoperasjoner som gir cache-miss og utnytter minnet effektivt, men kan levere foreldede data til TTL-en utløper, at write-through oppdaterer hurtigbufferen ved hver skriveoperasjon og dermed eliminerer foreldede data, men sløser med minne for data som ikke leses, og at eksplisitt ugyldiggjøring sletter hurtigbuffernøkler ved databaseoppdateringer for å fjerne vinduer med foreldede data. Deretter skal vi se nærmere på lagring av økter og mønstre for ledertavler med ElastiCache.