Hallo! Ik ben Jayeon.

Vandaag ga ik uitleggen hoe je een cache instelt. Dit is een bericht dat ik heb geschreven op basis van mijn eigen ervaringen in de praktijk, dus het is belangrijk om het als een referentie te beschouwen ㅎㅎ

Wat is een cache?

Een cache is een manier om resultaten van toekomstige aanvragen op te slaan om ze sneller te kunnen serveren. Met andere woorden, we slaan de resultaten van tevoren op en wanneer er later een aanvraag komt, verwerken we die aanvraag zonder de DB of API te raadplegen, maar door de cache te gebruiken. De basis voor het gebruik van een cache is de Pareto-wet.

De Pareto-wet stelt dat 80% van de resultaten wordt veroorzaakt door 20% van de oorzaken. Neem gerust een kijkje naar de onderstaande afbeelding!

Met andere woorden, een cache hoeft niet alle resultaten te cachen. Door alleen de 20% te cachen die het meest wordt gebruikt bij het serveren, kunnen we de algehele efficiëntie verhogen.

Welke gegevens moeten worden gecached?

Volgens de Pareto-wet moeten we niet zomaar alle gegevens cachen, maar alleen de gegevens die echt noodzakelijk zijn. Maar welke gegevens moeten we dan cachen?

Gegevens die vaak worden gelezen, maar zelden worden geschreven

We horen vaak dat we “gegevens die vaak worden gelezen, maar zelden worden geschreven” moeten cachen. In de praktijk is de definitie van “vaak lezen” en “zelden schrijven” echter vrij vaag.

Daarom onderzoek ik de te cachen gegevens in de volgende stappen.

• Ik gebruik een APM zoals Data Dog om de top 5 RDB query-aanroepen te controleren.
• Daarvan zoek ik naar query's die worden gebruikt om gegevens op te halen en controleer ik vanuit welke tabel ze worden opgehaald.
• Ik controleer hoe vaak de update-query's voor die tabel worden uitgevoerd.

Door dit proces te volgen, kijken we of er veel query's zijn om gegevens op te halen, maar weinig update-query's. In mijn praktijkervaring had een tabel 1.740.000 keer een query om gegevens op te halen per dag, maar de update-query's werden maximaal 500 keer uitgevoerd. Dat is een duidelijk teken dat deze gegevens geschikt zijn voor caching ㅎㅎ

Gevoelige gegevens voor bijwerking

Gevoelige gegevens voor bijwerking betekenen dat er een korte periode moet zijn waarin de gegevens in de RDB en de cache niet met elkaar overeenkomen. Bijvoorbeeld, gegevens over betalingen zijn zeer gevoelig voor bijwerking, dus zelfs als ze aan de bovenstaande cache-voorwaarden voldoen, moeten we goed nadenken over de toepassing ervan.

Ik moest gegevens over betalingen cachen die aan beide eigenschappen voldeden. Daarom heb ik de cache niet voor alle logica die deze tabel met gegevens over betalingen gebruikt toegepast, maar heb ik besloten om gedeeltelijk caching toe te passen op relatief veilige logica waar geen betalingen plaatsvinden.

Lokale caching versus globale caching

We hebben nu een idee welke gegevens we moeten cachen en wat de omvang van de caching moet zijn. Nu moeten we bepalen “waar” we de te cachen gegevens moeten opslaan. Over het algemeen kunnen we gegevens opslaan in het lokale geheugen of op een aparte server, zoals Redis.

Lokale caching

Bij lokale caching worden de te cachen gegevens opgeslagen in het geheugen van de applicatieserver. Hiervoor worden meestal Guava cache of Caffeine cache gebruikt.

Voordelen

• Het is snel omdat we de cache kunnen opzoeken in het geheugen van dezelfde server terwijl we de applicatielogica uitvoeren.
• Het is eenvoudig te implementeren.

Nadelen

• Er ontstaan verschillende problemen als er meerdere instanties zijn.
  • Wijzigingen in de cache van één instantie kunnen niet worden doorgegeven aan andere instanties. Er zijn echter ook lokale caching-bibliotheken die wijzigingen naar andere instanties kunnen doorgeven.
  • De cache wordt voor elke instantie opgeslagen, dus als er een nieuwe instantie wordt gestart, moet de cache opnieuw worden ingevuld. Dit kan leiden tot veel cachemissen, waardoor de instantie het verkeer niet aankan en crasht.

Globale caching

Bij globale caching wordt een aparte server gebruikt om de cachegegevens op te slaan, zoals Redis.

Voordelen

• De cache wordt gedeeld tussen instanties, dus als een instantie de cache wijzigt, kunnen alle instanties dezelfde cachewaarde ophalen.
• Als er een nieuwe instantie wordt gestart, hoeft deze alleen maar naar de bestaande cacheopslag te kijken, dus we hoeven de cache niet opnieuw in te vullen.

Nadelen

• Het netwerkverkeer is nodig, dus het is langzamer dan lokale caching.
• Er is een aparte cacheserver nodig, wat extra infrastructuurkosten met zich meebrengt.
  • Extra infrastructuurkosten? → serverkosten, tijd die nodig is voor het instellen en onderhouden van de infrastructuur, het bedenken van een strategie voor het beheren van storingen, enz.

Welke keuze heb ik gemaakt?

De applicatieservers van het bedrijf waar ik werk, zijn geconfigureerd om meerdere instanties te starten, maar ik heb voor lokale caching gekozen.

Er zijn drie belangrijke redenen.

• De te cachen gegevens in de RDB zijn ongeveer 40.000, dus zelfs als we ze allemaal in het geheugen laden, is dat minder dan 4 MB.
• De prestaties van het opzoeken van gegevens over betalingen moesten worden verbeterd.
• We hebben wel Redis, maar het opslaan van een nieuwe cache in Redis brengt extra infrastructuurkosten met zich mee.

Hoe worden de cachegegevens bijgewerkt?

Als er meerdere applicatieservers zijn en we lokale caching gebruiken, kunnen de cachewaarden voor elke applicatieserver verschillen. Bijvoorbeeld, de cachegegevens die zijn opgeslagen op server A kunnen “1” zijn, terwijl de cachegegevens die zijn opgeslagen op server B “2” kunnen zijn na een wijziging op server B. Als een gebruiker een aanvraag stuurt naar de load balancer, kan deze verschillende waarden van server A en server B ontvangen.

Daarom moeten we de cache op elke instantie automatisch verwijderen en de gegevens van de RDB opvragen. Dit wordt meestal gedaan met behulp van TTL.

Hoe lang moet de TTL zijn?

TTL staat voor Time To Live en is een instelling die de cache na een bepaalde tijd wist. Als we bijvoorbeeld de TTL op 5 seconden instellen, worden de cachegegevens na 5 seconden automatisch gewist. Daarna wordt er een cachemiss uitgevoerd en worden de gegevens van de RDB opgehaald en opgeslagen.

Hoe lang moet de TTL dan zijn?

Lezen/schrijven vindt plaats op één cacheserver

Als het lezen/schrijven plaatsvindt op één globale cacheserver, zoals Redis, of op één applicatieserver met lokale caching, is het geen probleem om de TTL-waarde te verhogen naar meer dan een uur. De cache wordt immers bijgeschreven en de server die gegevens van die cache ophaalt, heeft altijd toegang tot de meest recente gegevens.

In dit geval kunnen we de TTL zelfs overslaan en de cache automatisch wissen met behulp van het LRU-algoritme wanneer de cacheserver vol is.

Lezen/schrijven vindt plaats op meerdere cacheservers

Als lezen/schrijven plaatsvindt op meerdere globale cacheservers of op meerdere applicatieservers met lokale caching, is het beter om de TTL in te stellen op seconden of minuten. Dit komt omdat er een kans is dat je oude gegevens leest van een cacheserver die de bijgewerkte gegevens nog niet heeft ontvangen.

In dit geval wordt de TTL bepaald in verschillende contexten. Hoe belangrijker de bijwerking en hoe groter de kans op wijzigingen, hoe korter de TTL moet zijn. Hoe minder belangrijk de bijwerking en hoe kleiner de kans op wijzigingen, hoe langer de TTL kan zijn.

Hoe heb ik de TTL ingesteld?

De gegevens die ik cache, zijn gerelateerd aan betalingen, en hoewel ik geen caching heb toegepast op de strikte logica waarbij betalingen plaatsvinden, is bijwerking belangrijk vanwege de aard van betalingen. Omdat de kans op bijwerking echter klein is, heb ik de TTL ter veiligheid ingesteld op 5 seconden.

Conclusie

Samenvattend zijn de door mij gekozen caching-methoden als volgt:

• Gegevens over betalingen
• Zeer frequent opgevraagd, maar zelden bijgewerkt.
• Caching is toegepast op de logica waar geen betalingen plaatsvinden, maar wel gegevens worden opgevraagd.
• Lokale caching is toegepast en de TTL is ingesteld op 5 seconden.

De volgende stap is om prestatie-tests uit te voeren op basis van de werkelijke caching-methoden die ik heb geïmplementeerd. Ik ben nog steeds aan het nadenken over de precieze manier om de prestatie-tests uit te voeren, dus ik zal daarover in een volgend bericht schrijven!