Szia! Én vagyok Jaeon.

Ma a gyorsítótár beállításának kritériumait fogom bemutatni. Személyes tapasztalataim alapján írt bejegyzés, ezért csak referenciaként tekintsd! ㅎㅎ

Mi a gyorsítótár?

A gyorsítótár azt jelenti, hogy a későbbi kérelmek eredményeit előre tároljuk, hogy gyorsan kiszolgálhassuk őket. Vagyis előre tároljuk az eredményeket, és amikor kérelmek érkeznek, akkor nem a DB-t vagy az API-t kérdezzük le, hanem a gyorsítótárat használjuk a kérelmek feldolgozásához. A gyorsítótár mögött a Pareto-elv áll.

A Pareto-elv azt jelenti, hogy az eredmények 80%-át az okok 20%-a okozza, és érdemes lehet megnézni az alábbi képet!

Vagyis nem kell minden eredményt gyorsítótárba helyezni, hanem csak a 20%-ot, amelyet a szolgáltatás során gyakran használunk, így növelhetjük a teljesítményét.

Milyen adatokat kell gyorsítótárba helyezni?

A Pareto-elv szerint nem szabad minden adatot gyorsítótárba helyezni, csak a szükségeseket. Akkor mely adatokat kellene gyorsítótárba helyezni?

Adatok, amelyeket gyakran kell olvasni, de ritkán írni

Sokan azt mondják, hogy "gyakran kell olvasni, de ritkán kell írni" az adatokat gyorsítótárba kell helyezni, de a "gyakran olvasás" és a "ritkán írás" kritériumai meglehetősen homályosak voltak.

Ezért a következő lépésekkel vizsgálom meg a gyorsítótárba helyezendő adatokat.

• Ellenőrizzük az RDB lekérdezési hívások TOP 5-ös listáját egy APM-mel, például a DataDog-gal.
• Keressük meg a lekérdezési lekérdezéseket, és nézzük meg, hogy melyik táblából származnak.
• Ellenőrizzük, hogy hányszor hívják meg a megfelelő tábla frissítési lekérdezéseit.

Ennek a folyamatnak a segítségével megnézzük, hogy sok lekérdezés van-e, de kevés a frissítési lekérdezés. A gyakorlatban ellenőrzött táblában naponta 1,74 millió lekérdezés történt, de a frissítési lekérdezések száma legfeljebb 500 volt. Ez egyértelműen megfelel a gyorsítótár feltételeinek ㅎㅎ

Időérzékeny adatok

Az időérzékeny adatok azt jelentik, hogy az RDB és a gyorsítótár közötti eltérésnek rövidnek kell lennie. Például a fizetésekkel kapcsolatos információk esetében nagyon fontos a frissítés, ezért még ha megfelelnek is a fenti gyorsítótár feltételeknek, akkor is meg kell fontolni az alkalmazást.

A fenti két jellemzőnek megfelelő fizetésekkel kapcsolatos táblákhoz gyorsítótárazást kellett végrehajtanom. Ezért nem alkalmaztam a gyorsítótárat minden olyan logikára, amely a fizetésekkel kapcsolatos táblákat használja, hanem csak a biztonságosabb logikákhoz, amelyekben valójában nem történik fizetés.

Helyi gyorsítótár vs globális gyorsítótár

Most már tudjuk, hogy milyen adatokat és milyen tartományban kell gyorsítótárba helyezni. Akkor fel kell tennünk a kérdést: "Hová" kell tárolni a gyorsítótárba helyezett adatokat? Általában a helyi memóriába vagy egy külön szerverre, például a Redis-re tárolhatjuk őket.

Helyi gyorsítótár

A helyi gyorsítótár az alkalmazásszerver memóriájában tárolja a gyorsítótárba helyezett adatokat, és általában a Guava cache vagy a Caffeine cache-t használják.

Előnyök

• Mivel az alkalmazáslogika futás közben közvetlenül a saját szerverének memóriájából kérdezi le a gyorsítótárat, ezért gyorsabb.
• Könnyen implementálható.

Hátrányok

• Ha több példány van, akkor több probléma merül fel.
  • Egy példányban módosított gyorsítótár nem terjed ki más példányokra. Vannak azonban olyan helyi gyorsítótár-könyvtárak, amelyek lehetővé teszik a változások terjesztését más példányokra.
  • Minden példányban tárolódik a gyorsítótár, ezért új példány indításakor be kell tölteni a gyorsítótárat. Ez gyorsítótár-hibákhoz vezethet, amelyek miatt a forgalom nem tudja kezelni, és a példányok leállhatnak.

Globális gyorsítótár

A globális gyorsítótár külön szervert használ a gyorsítótárba helyezett adatok tárolásához, például a Redis-t.

Előnyök

• A gyorsítótár megosztott a példányok között, így ha egy példány módosítja a gyorsítótárat, akkor minden példány ugyanazt a gyorsítótár-értéket kapja meg.
• Ha új példány indul, akkor nem kell új gyorsítótárat tölteni, mivel már van egy meglévő gyorsítótár-tároló.

Hátrányok

• Hálózati forgalom szükséges, ezért lassabb, mint a helyi gyorsítótár.
• Külön gyorsítótár-szerver szükséges, ezért infrastruktúra-kezelési költségek merülnek fel.
  • Infrastruktúra-kezelési költségek? → Szerver díjak, az infrastruktúra beállítása és karbantartása szükséges idő, hibaelhárítási intézkedések kidolgozása stb.

Mit választott a szerző?

A jelenlegi vállalat alkalmazásszervere több példányt futtat, de helyi gyorsítótárat választott.

Ennek több oka van:

• A gyorsítótárba helyezendő adatok mennyisége az RDB-ben körülbelül 40 000, és ha az összeset a memóriába töltjük, az kevesebb, mint 4 MB.
• A fizetésekkel kapcsolatos adatok esetében fontos a lekérdezési teljesítmény.
• Bár a Redis már van, egy új gyorsítótár tárolása a Redis-ben infrastruktúra-költségeket eredményez.

Hogyan frissítsük a gyorsítótárat?

Ha több alkalmazásszerver van, és helyi gyorsítótárazás van implementálva, akkor a gyorsítótár-értékek eltérőek lehetnek az egyes alkalmazásszervereken. Például az A szerveren a tárolt gyorsítótár-adat "1", míg a B szerveren a B szerver módosítása miatt "2" lehet. Ebben a helyzetben, ha a felhasználó kérést küld a terheléselosztóhoz, akkor az A és B szerverek eltérő értékeket kapnak.

Ezért minden példányban automatikusan el kell távolítani a gyorsítótárat, hogy az RDB-ből lehessen lekérdezni, és ehhez általában TTL-t használnak.

Milyen legyen a TTL értéke?

A TTL (Time To Live) az a beállítás, amely azt határozza meg, hogy mennyi idő után kell törölni a gyorsítótárat. Például ha a TTL 5 másodperc, akkor a gyorsítótár-adatok 5 másodperc múlva automatikusan törlődnek. Ezután, ha gyorsítótár-hiba történik, akkor az RDB-ből lekérdezik és eltárolják az adatokat.

Akkor mennyi legyen a TTL értéke?

Az olvasás/írás egyetlen gyorsítótár-szerveren történik

Ha az olvasás/írás a Redis-hez hasonló globális gyorsítótár-szerveren történik, vagy egyetlen alkalmazásszerveren, amelyen helyi gyorsítótár van implementálva, akkor a TTL értéke lehet óránkénti vagy napi szinten is. Végül is, az íráskor módosítja a meglévő gyorsítótárat, és a szerver, amely az adott gyorsítótárból olvassa ki az adatokat, mindig a frissített adatokat kapja meg.

Ebben az esetben nem is kell beállítani a TTL-t, hanem az LRU algoritmus segítségével automatikusan meg lehet tisztítani a gyorsítótárat, ha a gyorsítótár-szerver megtelt.

Az olvasás/írás több gyorsítótár-szerveren történik

Ha az olvasás/írás több globális gyorsítótár-szerveren történik, vagy több alkalmazásszerveren, amelyen helyi gyorsítótár van implementálva, akkor a TTL értéke másodperces vagy perces szinten legyen. Mivel előfordulhat, hogy a módosított adatokat még nem tükröző, elavult adatokat olvasnak ki a gyorsítótár-szerverekről.

Ebben az esetben a TTL értéket a különböző kontextusok alapján kell meghatározni. Minél fontosabb a frissítés, és minél nagyobb a változás valószínűsége, annál rövidebb legyen a TTL, míg minél kevésbé fontos a frissítés, és minél kisebb a változás valószínűsége, annál hosszabb lehet a TTL.

Hogyan állította be a szerző a TTL-t?

A gyorsítótárba helyezett adatok fizetésekkel kapcsolatos adatok, és bár a valódi fizetéshez kapcsolódó, pontos logikában nem alkalmaztam a gyorsítótárat, a fizetések természetüknél fogva fontos a frissítés. De mivel az frissítések valószínűsége alacsony, a TTL-t 5 másodpercben határoztam meg, ami biztonságos érték.

Következtetés

Összefoglalva, a választott gyorsítótár-megközelítés a következő:

• Fizetésekkel kapcsolatos adatok
• A lekérdezés nagyon gyakori, de a módosítás ritka.
• A gyorsítótárazás csak olyan logikára van alkalmazva, amely nem végez tényleges fizetéseket, de lekérdezések történnek.
• Helyi gyorsítótár alkalmazása, a TTL értéke 5 másodperc.

A következő feladat a gyorsítótár-megközelítés teljesítményének tesztelése a gyakorlatban. Még nem döntöttem el a teljesítményteszt pontos részleteit, de megírom a következő bejegyzésben!