- Wykorzystanie Cloud Run do serwowania plików statycznych - 1
- Wpis na blogu opisujący sposób udostępniania plików statycznych za pomocą Google Cloud Run. Skupia się na przekierowaniach i optymalizacji wydajności.
Tekst przetłumaczony przez AI.
Podsumowanie posta wygenerowane przez AI durumis
- Zintegrowaliśmy Google Cloud Storage (GCS) z Cloud Run, aby efektywnie zarządzać obrazami i zasobami internetowymi oraz tworzyć system CDN dostarczający zoptymalizowane pliki dostosowane do środowiska przeglądarki internetowej.
- Wgrywane obrazy są konwertowane i zapisywane w różnych formatach, takich jak webp, avif, a pliki tekstowe są kompresowane za pomocą gzip, br, co pozwala na dostarczanie użytkownikom zoptymalizowanych treści.
- Umieściliśmy Cloud Storage i Cloud Run w 8 regionach na całym świecie, aby dostarczać zasoby z najbliższego regionu w zależności od lokalizacji użytkownika. Dzięki temu minimalizujemy opóźnienia i poprawiamy komfort użytkowania.
Poprzedni wpiszawierał opis obsługi plików statycznych za pomocą Cloud Run, który jest wykorzystywany przez durumis.
Jednakże, w przeciwieństwie do plików takich jak robots.txt czy favicon.ico, obrazy publikowane na blogu lub zasoby samej strony internetowej nie mogą być traktowane wyłącznie jako pliki statyczne.
Dlatego do obsługi takich plików należy wykorzystać Cloud Run połączone z Google Cloud Storage (dalej GCS).
Podstawowa koncepcja jest prosta: obrazy publikowane w czasie rzeczywistym lub nowe zasoby pojawiające się podczas aktualizacji strony są przesyłane do GCS, a gdy nadejdzie żądanie z zewnątrz, Cloud Run sprawdza, czy dany plik istnieje w GCS, i jeśli tak, to przesyła go.
Jednak rzeczywisty sposób działania jest znacznie bardziej złożony.
Podczas przesyłania obrazu do GCS, durumis domyślnie konwertuje go do trzech formatów.
W przypadku przesyłania obrazu w formacie JPEG lub PNG, plik jest automatycznie konwertowany do formatów WebP i AVIF i zapisywany w obu formatach.
Wszystkie obrazy są dostępne za pośrednictwem adresu URL bez rozszerzenia. Po otrzymaniu żądania, Cloud Run sprawdza nagłówki żądania przeglądarki internetowej i próbuje wysłać obraz w formacie AVIF, a następnie WebP. Jeśli żaden z tych formatów nie jest obsługiwany, wysyłany jest obraz w formacie JPEG lub PNG. Ponadto, oprócz prostej konwersji formatów, obrazy są również wstępnie skalowane do wymaganych rozmiarów i przechowywane/przesyłane w ten sposób.
Diagram
Podobnie jest w przypadku plików tekstowych.
Oprócz obrazów, wiele zasobów potrzebnych stronie internetowej to pliki tekstowe, takie jak JS i CSS.
Pliki JS i CSS, podobnie jak obrazy, są kompresowane podczas przesyłania za pomocą gzip i br, a następnie, po otrzymaniu żądania, wysyłany jest plik w formacie obsługiwanym przez przeglądarkę.
Rola CDN nie ogranicza się jedynie do buforowania treści. W przypadku Google Cloud Platform (GCP) funkcja Cloud CDN może być bezpośrednio połączona z Google Cloud Load Balancer (GCLB), co zapewnia jeszcze większe możliwości.
Cloud CDN pobiera dane z usługi zaplecza (Backend Service), przechowuje je w pamięci podręcznej i przesyła do klienta. W tym procesie Cloud CDN może wysyłać zoptymalizowane pliki w zależności od nagłówków żądania klienta. Dzięki temu dla tego samego adresu URL można dostarczać różne formaty treści.
Na przykład, dla tego samego adresu URL '/image/tempImage'
- w przypadku plików graficznych
- wysyłany jest inny format obrazu w zależności od nagłówka 'Accept' przeglądarki.
- Przeglądarka Chrome zazwyczaj preferuje formaty 'image/avif,image/webp,image/apng' w tej kolejności.
- CDN dostarcza obraz w odpowiednim formacie zgodnie z tą kolejnością, a jeśli żaden z nich nie jest obsługiwany, to używa JPEG lub PNG.
- podobnie w przypadku plików tekstowych
- brana jest pod uwagę preferencja metody kompresji.
- Przeglądarka Chrome obsługuje metody kompresji, takie jak 'gzip, deflate, br, zstd'.
- Na przykład, w usłudze durumis obecnie obsługiwane są gzip i br, więc plik skompresowany za pomocą br jest wysyłany w pierwszej kolejności.
Te zaawansowane funkcje CDN umożliwiają dostarczanie treści zoptymalizowanych pod kątem środowiska użytkownika, co znacznie poprawia wydajność witryny i komfort korzystania z niej.
Nawet w przypadku Cloud CDN, domyślnie CDN nadal musi żądać pliku z Cloud Run. Dlatego durumis wdraża Cloud Storage i Cloud Run w 8 regionach na całym świecie, aby wstępnie umieścić tam zasoby i wysyłać je. Chociaż wiąże się to z pewnym wzrostem kosztów i zwiększoną ilością pracy, użytkownicy mogą doświadczyć znacznie krótszego czasu odpowiedzi.
Nawet przy użyciu Cloud CDN, domyślnie pliki muszą być pobierane z oryginalnego serwera (w tym przypadku Cloud Run). Durumis zoptymalizował tę strukturę, aby zapewnić lepszą obsługę użytkownikom na całym świecie.
Globalna strategia optymalizacji durumis:
- Wstępne wdrożenie Cloud Storage i Cloud Run w 8 regionach na całym świecie
- Wstępne rozmieszczenie wymaganych zasobów w każdym regionie
- Wysyłanie zasobów z najbliższego regionu podczas żądania użytkownika
To podejście wiąże się z pewnym wzrostem kosztów i dodatkowymi zadaniami, ale zapewnia użytkownikom następujące korzyści:
- Znacznie krótszy czas odpowiedzi
- Szybszy czas ładowania treści
- Ogólna poprawa doświadczeń użytkownika
Wizualizacja tej struktury wygląda następująco:
Dzięki tej strukturze durumis może zapewniać użytkownikom na całym świecie spójnie szybkie usługi. Ponieważ treści są dostarczane z najbliższego regionu, niezależnie od lokalizacji użytkownika, można korzystać z usług o niskim czasie odpowiedzi na całym świecie.
To podejście wymaga większego wysiłku w fazie początkowej konfiguracji i konserwacji, ale ma znaczącą zaletę w postaci znacznej poprawy doświadczeń użytkownika końcowego. Szczególnie dla firm świadczących usługi globalne taka struktura może być dużym atutem w zapewnianiu konkurencyjnych usług.
W dzisiejszym wpisie o CDN omówiliśmy jedynie podstawowe koncepcje.
W rzeczywistości moglibyśmy omówić szczegóły konfiguracji, ale różnią się one w zależności od dostawcy chmury (GCP, Azure, AWS), a ponadto... są mniej interesujące, dlatego skupiliśmy się na wyjaśnieniu koncepcji.
Mam nadzieję, że w przyszłości będę mógł omówić bardziej szczegółowe aspekty.
W następnym wpisie zastanowimy się, jak synchronizować Cloud Storage w wielu regionach (w naszym przypadku aż 8!).
Dziękuję.