Profile i punkty końcowe Azure CDN

Sieć dostarczania treści (Content Delivery Network, CDN) to rozproszona sieć serwerów umieszczonych w geograficznie rozmieszczonych punktach obecności (Points of Presence, PoP), blisko użytkowników końcowych. Gdy użytkownik żąda treści, CDN dostarcza ją z pamięci podręcznej najbliższego punktu PoP zamiast z serwera źródłowego. Zmniejsza to opóźnienia (szczególnie w przypadku użytkowników znajdujących się daleko od regionu źródłowego), ogranicza obciążenie serwera źródłowego i zwiększa odporność rozwiązania. Azure CDN natywnie integruje się z Blob Storage, App Service oraz dowolnym publicznie dostępnym źródłem HTTP.

Azure CDN jest oferowany w ramach kilku warstw dostawców: Azure CDN Standard from Microsoft — domyślna, ściśle zintegrowana opcja z podstawowymi regułami buforowania i obsługą HTTP/2. Azure CDN Standard from Akamai — szeroki globalny zasięg punktów PoP i szybka propagacja. Azure CDN Standard/Premium from Verizon — zaawansowany aparat reguł i analityka (warstwa Premium). Każdy dostawca oferuje inny zestaw funkcji i cennik; w większości scenariuszy AZ-900 omawiana jest opcja Azure CDN Standard from Microsoft.

Profil Azure CDN to kontener najwyższego poziomu, który grupuje punkty końcowe CDN oraz określa dostawcę i warstwę cenową. Punkt końcowy CDN to konkretna nazwa hosta (np. myapp.azureedge.net) mapowana na źródło. Każdy punkt końcowy ma własną konfigurację zasad buforowania. Jeden profil może zawierać wiele punktów końcowych — na przykład oddzielne punkty dla zasobów statycznych, odpowiedzi interfejsu API i strumieni wideo, z różnymi regułami buforowania dla każdego z nich.

Time-to-Live (TTL) określa, jak długo buforowana odpowiedź pozostaje w punkcie PoP, zanim trzeba ją odświeżyć ze źródła. Reguły buforowania można ustawiać na trzech poziomach: globalna reguła buforowania (dotyczy wszystkich żądań do punktu końcowego), reguły niestandardowe (dopasowywane według wzorca ścieżki lub rozszerzenia pliku) oraz zachowanie względem parametrów zapytania (oddzielne buforowanie dla każdego unikatowego ciągu zapytania lub ignorowanie ciągów zapytania). Dobrą praktyką jest stosowanie wartości TTL zależnych od typu treści — dłuższych dla obrazów i krótszych dla dokumentów HTML.

Jedna z najczęstszych konfiguracji Azure CDN wykorzystuje kontener Blob Storage jako źródło. Należy przesłać zasoby statyczne (obrazy, pliki CSS, JS i filmy) do konta magazynu, udostępnić kontener do odczytu publicznego i skonfigurować punkt końcowy CDN wskazujący podstawowy punkt końcowy obiektu blob (myaccount.blob.core.windows.net). CDN buforuje obiekty blob w punktach PoP na całym świecie, a użytkownicy pobierają je z najbliższego punktu PoP zamiast z regionu, w którym znajduje się magazyn. Można również użyć niestandardowej nazwy hosta źródła na potrzeby hostingu witryny statycznej.

Po zaktualizowaniu zawartości w źródle (np. wdrożeniu nowej wersji pliku JavaScript) kopie przechowywane w lokalizacjach PoP mogą udostępniać nieaktualną zawartość do czasu wygaśnięcia TTL. Czyszczenie pamięci podręcznej natychmiast usuwa określone pliki lub całą zawartość pamięci podręcznej ze wszystkich lokalizacji PoP, dzięki czemu kolejne żądanie musi ponownie pobrać dane ze źródła. Można wyczyścić konkretne adresy URL, ścieżki z symbolami wieloznacznymi (np. /assets/*) albo całą zawartość punktu końcowego. Rozpropagowanie czyszczenia do wszystkich lokalizacji PoP na świecie zajmuje 2–3 minuty.

Domyślnie punkty końcowe CDN używają domeny .azureedge.net. Aby udostępniać zawartość z własnej domeny (np. static.contoso.com), należy dodać ją jako domenę niestandardową punktu końcowego CDN, tworząc rekord CNAME wskazujący nazwę hosta punktu końcowego. Po dodaniu domeny można włączyć dla niej protokół HTTPS, korzystając z certyfikatu zarządzanego przez Azure (bezpłatnego i automatycznie odnawianego) albo własnego certyfikatu przechowywanego w Key Vault. Wymuszanie HTTPS automatycznie przekierowuje ruch HTTP.

Włączenie kompresji plików w punkcie końcowym CDN zmniejsza rozmiar plików przesyłanych przez sieć, kompresując zasoby tekstowe (HTML, CSS, JavaScript, SVG) za pomocą gzip lub Brotli. CDN kompresuje zawartość przed zapisaniem jej w pamięci podręcznej lokalizacji PoP, dlatego kolejne żądania tego samego zasobu otrzymują już skompresowaną wersję bez dodatkowego obciążenia procesora. Kompresja jest szczególnie skuteczna w przypadku pakietów JS, których rozmiar po kompresji może być od 5 do 10 razy mniejszy.

Filtrowanie geograficzne w punkcie końcowym CDN umożliwia zezwalanie na dostęp do zawartości z określonych krajów lub blokowanie takiego dostępu. Można je stosować w celu zapewnienia zgodności z licencjami na zawartość (np. gdy wideo jest objęte licencją tylko w wybranych krajach), spełnienia wymogów prawnych albo blokowania krajów będących źródłem dużej liczby złośliwego ruchu. Reguły filtrowania geograficznego konfiguruje się dla każdego kodu kraju i każdej ścieżki URL — można zablokować tylko określony katalog zawartości, a nie cały punkt końcowy.

Azure CDN udostępnia wbudowaną analizę użycia w portalu, obejmującą między innymi wykorzystaną przepustowość, współczynnik trafień i chybionych odwołań, łączną liczbę żądań oraz oszczędność przepustowości w porównaniu z udostępnianiem danych ze źródła. W przypadku CDN warstwy Microsoft można także za pomocą ustawień diagnostycznych wysyłać dzienniki dostępu do obszaru roboczego Log Analytics lub konta Storage, a następnie wykonywać zapytania KQL na nieprzetworzonych danych dzienników dostępu CDN. Analiza współczynników trafień pamięci podręcznej pomaga dostosować wartości TTL — niski współczynnik trafień oznacza, że większość żądań trafia do źródła, co niweczy cel używania CDN.

Azure CDN i Azure Front Door buforują zawartość w lokalizacjach PoP, ale służą przede wszystkim do różnych celów. Azure CDN doskonale sprawdza się w buforowaniu i dostarczaniu zawartości statycznej z jednego źródła przy niskim koszcie. Azure Front Door dodatkowo zapewnia inteligentne równoważenie obciążenia i routing między wieloma backendami źródłowymi, sondy kondycji na potrzeby automatycznego przełączania awaryjnego, wbudowany Web Application Firewall oraz routing oparty na ścieżkach — dlatego lepiej nadaje się do wieloregionowych aplikacji internetowych działających w trybie active-active. W jednym rozwiązaniu często używa się obu usług.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo: sposób, w jaki profile i punkty końcowe Azure CDN dostarczają buforowaną zawartość z lokalizacji PoP znajdujących się blisko użytkowników, aby zmniejszyć opóźnienia; sposób, w jaki reguły buforowania i TTL określają, jak długo zawartość jest przechowywana przed ponownym pobraniem ze źródła; oraz sposób, w jaki czyszczenie pamięci podręcznej natychmiast usuwa nieaktualną zawartość po aktualizacji źródła. W następnej części omówimy Azure Front Door, który służy do globalnego równoważenia obciążenia i routingu między wieloma źródłami backendowymi.