- Statikus fájlok kiszolgálása Cloud Run használatával - 1
- Blogbejegyzés a Google Cloud Run használatával történő statikus fájlok kiszolgálásáról. A fókusz a továbbirányításon és a teljesítménynövelésen van.
AI által fordított szöveg.
A bejegyzés durumis AI által generált összefoglalója
- A Google Cloud Storage (GCS) és a Cloud Run összekapcsolásával hatékonyan kezelhetőek a képek és a webes erőforrások, valamint egy olyan CDN rendszer hozható létre, amely a webböngésző környezetnek megfelelően optimalizált fájlokat biztosít.
- A feltöltött képek webp, avif stb. formátumokká alakíthatók és tárolhatók, a szövegfájlok pedig gzip, br stb. formátumokkal tömöríthetők, hogy a felhasználóknak optimalizált tartalmat biztosítsunk.
- A Cloud Storage és a Cloud Run a világ 8 régiójában van telepítve, így a felhasználók helyéhez legközelebbi régióból érhetőek el a források, ami minimalizálja a késleltetést és javítja a felhasználói élményt
Előző bejegyzésben bemutattuk a Cloud Run használatát statikus fájlok kiszolgálására, amit a Durumis (두루미스) is alkalmaz.
Azonban a robots.txt vagy a favicon.ico fájlokkal ellentétben a blogbejegyzésekben található képfájlok vagy a weboldalak erőforrásai nem kezelhetők egyszerű statikus fájlként.
Ezért ezeknek a fájloknak a kezeléséhez a Google Cloud Storage-t (röviden GCS) és a Cloud Run-t kell együtt használni.
Az alapkoncepció egyszerű: a feltöltött képfájlok vagy a weboldal frissítései során feltöltött új erőforrások a GCS-be kerülnek, és külső kérés esetén a Cloud Run ellenőrzi, hogy a fájl létezik-e a GCS-ben, és ha igen, akkor átküldi azt.
A valós működés azonban ennél sokkal összetettebb.
A képfájlok GCS-be történő feltöltésekor a Durumis (두루미스) alapértelmezésben három formátumban konvertálja azokat.
Feltöltéskor, ha a fájl JPEG vagy PNG formátumú, akkor automatikusan WEBP és AVIF formátumba is konvertálja, és mindhárom formátumot elmenti.
Minden képfájl URL-címét kiterjesztés nélkül kell megadni. A kérés beérkezésekor a Cloud Run ellenőrzi a böngésző fejlécét, és az AVIF, WEBP sorrendben keresi meg a böngésző által támogatott formátumot. Ha egyik sem támogatott, akkor JPEG vagy PNG formátumban küldi el a fájlt. Ezen kívül a kép mérete is optimalizálva van a weboldal igényeinek megfelelően, és ez a méretben optimalizált verzió kerül tárolásra és átküldésre.
Diagram
A szöveges fájlokra is ugyanaz vonatkozik.
A weboldalaknak számos erőforrásra van szükségük, nem csak képekre, hanem JS és CSS fájlokra is.
A JS és CSS fájlok is hasonlóan a képekhez, feltöltéskor GZIP és BR tömörítéssel kerülnek tárolásra, és a kéréskor a böngésző által támogatott fájl kerül átküldésre.
A CDN szerepe nem merül ki a tartalom egyszerű gyorsítótárazásában. A Google Cloud Platform (GCP) esetében a Google Cloud Load Balancer (GCLB) közvetlenül csatlakoztatható a Cloud CDN funkcióhoz, ezáltal még erőteljesebb képességeket biztosítva.
A Cloud CDN a háttérszolgáltatástól (Backend Service) fogadja a tartalmat, tárolja, majd továbbítja a kliensnek. Ebben a folyamatban a Cloud CDN a kliens kérésének fejléce alapján optimalizált fájlt küldhet. Ennek köszönhetően ugyanarra az URL-re különböző formátumú tartalmak is küldhetők.
Például a '/image/tempImage' URL-címre
- képfájlok esetén
- a böngésző 'Accept' fejléce alapján különböző formátumú képeket küld.
- A Chrome böngésző általában 'image/avif,image/webp,image/apng' sorrendben adja meg a preferenciákat.
- A CDN ezen sorrend alapján adja meg a lehetséges formátumú képet, és ha egyik sem támogatott, akkor JPEG vagy PNG formátumra vált.
- hasonlóképpen a szöveges fájlok esetén is
- figyelembe veszi a tömörítési módszer preferenciáját.
- A Chrome böngésző támogatja a 'gzip, deflate, br, zstd' tömörítési módszereket.
- Például a Durumis (두루미스) szolgáltatás jelenleg GZIP és BR tömörítést támogat, ezért a BR tömörített fájlt küldi el először.
A CDN ezen fejlett funkcióinak köszönhetően a felhasználó környezetének megfelelő tartalmat lehet biztosítani, ami jelentősen javítja a weboldal teljesítményét és a felhasználói élményt.
A Cloud CDN esetében is, alapvetően a CDN-ből is Cloud Run-re van szükség a fájlok lekéréséhez, ezért a Durumis (두루미스) világszerte 8 régióban telepíti előre a Cloud Storage-t és a Cloud Run-t, és a szükséges erőforrásokat is elhelyezi ott. Ennek köszönhetően, bár kissé növekszik a költség és a munka mennyisége, a felhasználók számára lényegesen alacsonyabb késleltetés érhető el.
A Cloud CDN használata esetén is alapvetően az eredeti szerverről (ebben az esetben a Cloud Run-ről) kell letölteni a fájlokat. A Durumis (두루미스) ezt a struktúrát optimalizálta, hogy jobb szolgáltatást nyújtson a globális felhasználóknak.
A Durumis (두루미스) globális optimalizálási stratégiája:
- A Cloud Storage és a Cloud Run előzetes telepítése világszerte 8 régióban
- Az egyes régiókba szükséges erőforrások előzetes telepítése
- A felhasználói kérések kiszolgálása a legközelebbi régióban lévő erőforrásokból
Ez a módszer kissé növeli a költségeket és a munkát, de a felhasználók számára a következő előnyöket nyújtja:
- Jelentősen csökkentett késleltetés
- Gyorsabb tartalombetöltési idő
- A felhasználói élmény általános javulása
Ez a struktúra vizuálisan a következőképpen néz ki:
Ezzel a struktúrával a Durumis (두루미스) következetesen gyors szolgáltatást nyújthat a globális felhasználóknak. A felhasználó helyétől függetlenül a legközelebbi régióban lévő tartalmat kapja, így a világ bármely pontjáról alacsony késleltetéssel használhatja a szolgáltatást.
Ez a megközelítés több erőfeszítést igényel a kezdeti beállítás és karbantartás során, de jelentősen javítja a végfelhasználói élményt. Különösen a globális szolgáltatásokat nyújtó vállalatok számára lehet ez a struktúra nagy segítség a versenyképes szolgáltatások nyújtásában.
A mai CDN bemutatón csak az alapvető fogalmakat érintettük.
Tulajdonképpen részletesebben is belemehetünk volna a beállításokba, de a felhőszolgáltatók (GCP, Azure, AWS) között vannak különbségek, és kissé… kevésbé szórakoztató, ezért inkább a fogalmak magyarázatára koncentráltunk.
Ha lesz rá lehetőség, akkor a későbbiekben részletesebben is bemutatjuk ezeket a részleteket.
A következő alkalommal pedig arra a kérdésre keressük a választ, hogy vajon hogyan szinkronizálódnak a több (nálunk 8!) régióban lévő Cloud Storage tárolók…
Köszönjük!