Microsoft AZ-204: Buforowanie, CDN i wydajność w Azure — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Szybkie i niezawodne doświadczenia użytkowników w Azure zależą od umieszczania treści i stanu blisko użytkowników, minimalizowania obciążenia serwera źródłowego oraz eleganckiego obsługiwania awarii. Usługi Azure Cache for Redis, Azure CDN i Azure Front Door wspólnie zapewniają akcelerację w pamięci, buforowanie brzegowe oraz globalny routing anycast z zabezpieczeniami. Opanowanie struktur danych i wzorców połączeń Redis, profili i semantyki buforowania CDN oraz routingu i sond kondycji Front Door pozwala projektować aplikacje o niskim opóźnieniu i wysokiej odporności.

Azure Cache for Redis: warstwy, struktury danych, eksmisja i wzorce

Azure Cache for Redis to zarządzana usługa Redis, która zapewnia dostęp do danych w czasie poniżej milisekundy, obsługując popularne struktury danych Redis oraz zaawansowane funkcje w wyższych warstwach.

Warstwy:

Basic: Jednowęzłowa pamięć podręczna bez umowy SLA i bez replikacji danych. Dobra do zastosowań deweloperskich/testowych i obciążeń niekrytycznych. Brak trwałości danych, klastrowania i integracji z VNet.
Standard: Dwuwęzłowa konfiguracja podstawowy/replika z automatycznym przełączaniem awaryjnym i umową SLA. Odpowiednia do środowisk produkcyjnych. Obsługuje skalowanie w górę/w dół z minimalnymi zakłóceniami, ale bez klastrowania i trwałości.
Premium: Wyższa wydajność i przepustowość, większe rozmiary pamięci podręcznej, trwałość Redis (RDB i AOF), klastrowanie (sharding) do skalowania horyzontalnego, integracja z siecią wirtualną, redundancja strefowa (w obsługiwanych regionach) i georeplikacja na potrzeby odzyskiwania po awarii (DR). Obsługuje również zaplanowane okna wdrażania poprawek i zaawansowane zabezpieczenia.

Struktury danych i kiedy ich używać:

Strings: Podstawowe pary klucz/wartość, liczniki, obiekty JSON; atomowe operacje INCR/DECR do ograniczania szybkości i liczników.
Hashes: Przechowywanie pól obiektu (np. profilu użytkownika) jako pojedynczego klucza z parami pole-wartość w celu częściowych aktualizacji i efektywności przestrzennej.
Lists: Kolejki lub stosy, uporządkowane według kolejności wstawiania; używane z LPUSH/BRPOP do prostych kolejek zadań.
Sets: Unikalne kolekcje; używane do tagów, sprawdzania przynależności, operacji na zbiorach.
Sorted Sets: Ranking z wynikami; idealne do tabel wyników i zdarzeń uporządkowanych w czasie.
Bitmaps/Bitfields: Kompaktowe śledzenie flag logicznych i liczników na pozycjach.
HyperLogLog: Przybliżona liczność (liczba unikalnych elementów) przy stałym zużyciu pamięci.
Geospatial: Przechowywanie i odpytywanie współrzędnych geograficznych (szerokość/długość), wyszukiwanie w promieniu.
Streams: Dziennik typu append-only do przyjmowania zdarzeń i grup konsumentów.

Polityki eksmisji (stosowane po osiągnięciu maxmemory):

volatile-lru: Usuwa najdawniej używane klucze z ustawionym czasem wygaśnięcia (domyślne w Azure Cache for Redis).
allkeys-lru: Usuwa najdawniej używane klucze, niezależnie od tego, czy mają ustawiony czas wygaśnięcia.
volatile-ttl: Usuwa klucze z najbliższym czasem wygaśnięcia.
volatile-random / allkeys-random: Usuwa losowe klucze, ograniczone do wygasających lub wszystkich kluczy.
noeviction: Nie usuwa kluczy; polecenia zapisu, które dodałyby dane do pamięci, kończą się błędem.
volatile-lfu / allkeys-lfu: Warianty usuwania najrzadziej używanych kluczy (dla nowszych wersji Redis).

Wybierz politykę eksmisji na podstawie krytyczności danych i wzorców dostępu. Dla pamięci podręcznych allkeys-lru lub allkeys-lfu zapewnia najlepszy współczynnik trafień. Dla mieszanych magazynów z ostrożnie ustawionymi czasami wygaśnięcia, volatile-ttl lub volatile-lru może respektować ustawione TTL.

Typowe przypadki użycia:

Buforowanie sesji: Przechowywanie stanu sesji użytkownika za pomocą IDistributedCache lub oprogramowania pośredniczącego sesji. Utrzymuj małe klucze, używaj TTL zgodnego z czasem wygaśnięcia sesji i włącz powinowactwo sesji na brzegu sieci, jeśli jest to potrzebne.
Buforowanie wyjścia: Buforowanie wyrenderowanych fragmentów stron lub całych odpowiedzi, z kluczem opartym na ścieżce i segmencie użytkownika. Unieważniaj przy zmianach treści za pomocą wersjonowania kluczy lub jawnego polecenia DEL.
Pub/Sub: Komunikacja w czasie zbliżonym do rzeczywistego do powiadomień lub rozgłaszania unieważnień pamięci podręcznej. Używaj kanałów do rozgłaszania zmian do wielu subskrybentów.
Tabele wyników: Zbiory posortowane z wynikami do rankingu; ZADD/ZREVRANGE do aktualizacji i odczytu N najlepszych; używaj dodatkowych zbiorów posortowanych do rankingów w oknach czasowych.

Łączenie z Azure Redis: parametry połączenia, StackExchange.Redis i odporność

Punkty końcowe połączeń i klucze są dostępne w portalu Azure w sekcji Access keys. Podstawowy ciąg połączenia zawiera hosta, port, TLS i hasło (na przykład, contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). W środowisku produkcyjnym zawsze używaj TLS na porcie 6380.

Dobre praktyki dla StackExchange.Redis:

Używaj pojedynczej, długo żyjącej instancji ConnectionMultiplexer na proces. Jest ona bezpieczna wątkowo i efektywnie multipleksuje żądania. Utwórz ją raz, przechowuj w statycznym polu lub kontenerze DI i używaj ponownie.
Opcje konfiguracji: ustaw AbortOnConnectFail=false dla tolerancji na awarie w chmurze; ustaw ConnectRetry i ConnectTimeout na wypadek przejściowych problemów; SyncTimeout dostosowany do obciążenia; KeepAlive do utrzymywania otwartych połączeń przez NAT. Przykładowe opcje w formie tekstowej: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
Używaj metod asynchronicznych, aby uniknąć głodzenia puli wątków pod obciążeniem. Metody IDatabase (StringGetAsync, HashSetAsync, SortedSetAddAsync) są nieblokujące.
Obsługuj zdarzenia związane z odpornością: subskrybuj zdarzenia ConnectionFailed, ConnectionRestored i ConfigurationChanged, aby logować i obserwować zmiany topologii oraz przełączenia awaryjne. StackExchange.Redis automatycznie ponownie rozpoznaje węzeł podstawowy po przełączeniu awaryjnym.
Unikaj długo działających skryptów Lua i ciężkich transakcji; preferuj małe, atomowe polecenia. Potokowanie odbywa się naturalnie przez multiplekser; nie grupuj zbyt wielu poleceń naraz, aby uniknąć przekroczenia limitu czasu.
Limity czasu i ponawianie prób: nie ponawiaj na ślepo poleceń, które nie są idempotentne. Używaj wzorców idempotentnych lub kolejek typu write-through dla krytycznych zapisów.
Serializacja: przechowuj kompaktowe dane (np. MessagePack), aby zminimalizować ruch sieciowy i zużycie pamięci. Unikaj gigantycznych wartości; preferuj hashe z dostępem na poziomie pól.
Nazewnictwo kluczy: dodawaj prefiksy według aplikacji/środowiska (prod:session:{userId}), aby unikać kolizji i uprościć operacje masowe oraz czyszczenie.
Bezpieczeństwo: rotuj klucze dostępu, ograniczaj dostęp za pomocą VNet (warstwa Premium) i rozważ użycie Private Link dla dostępu prywatnego. W środowisku produkcyjnym nie ustawiaj opcji „Allow access only via SSL” na false.

Azure Front Door: globalny routing, kondycja, bezpieczeństwo i koligacja

Azure Front Door zapewnia globalny load balancing warstwy 7 oparty na anycast, dynamiczne przyspieszanie witryn oraz zintegrowany WAF. Uzupełnia CDN, kierując i chroniąc ruch dynamiczny, jednocześnie opcjonalnie buforując zawartość statyczną w warstwach Standard/Premium.

Reguły routingu:

Dopasowują przychodzące nazwy hostów i wzorce ścieżek, a następnie kierują ruch do grupy źródeł (puli zaplecza). Umożliwiają stosowanie przepisywania ścieżek, transformacji nagłówków, przekierowań i ustawień protokołu dla każdej reguły.
Konfiguracja buforowania na poziomie trasy (Standard/Premium) dla buforowania na brzegu sieci (edge caching) zasobów statycznych lub częściowo statycznych, gdy wymagana jest ściślejsza kontrola na brzegu aplikacji.
Użycie przełączania awaryjnego (failover) opartego na priorytetach i ważonego load balancingu między źródłami, opcjonalnie z geofiltrowaniem dla routingu specyficznego dla regionu.

Sondy kondycji i kondycja zaplecza:

Zdefiniuj ścieżkę sondy, protokół, interwał i oczekiwane kody statusu HTTP. Sondy są uruchamiane z wielu lokalizacji brzegowych w celu określenia kondycji źródła.
Front Door wykorzystuje status kondycji do kierowania ruchu do sprawnych źródeł o niskim opóźnieniu. Dostosuj timeouty i rozmiar próbki, aby unikać niestabilności (flapping); upewnij się, że punkt końcowy sondy jest lekki i nie jest buforowany.

Integracja z WAF:

Dołącz politykę WAF do swojego Front Door, aby wymusić stosowanie zarządzanych zestawów reguł dla popularnych podatności webowych i dodać niestandardowe reguły dla ograniczeń IP, geoblokowania lub limitów rozmiaru żądań.
Użyj ochrony przed botami i ograniczania szybkości (rate limiting), aby absorbować szkodliwy ruch na brzegu sieci, chroniąc zasoby źródłowe.

Koligacja sesji:

Włącz koligację sesji, gdy Twoja aplikacja wymaga, aby kolejne żądania trafiały do tego samego zaplecza (np. nierozproszony stan sesji). Front Door wstrzykuje plik cookie koligacji i kieruje kolejne żądania w tej samej sesji do wybranego zaplecza w ramach reguły routingu.
Preferuj projekty bezstanowe lub stan sesji oparty na Redis, aby unikać koligacji, jeśli to możliwe; jeśli jest używana, starannie określ jej zakres i ustaw odpowiednie czasy życia (TTL) dla plików cookie.

Współdziałanie z CDN:

CDN powinien obsługiwać zasoby statyczne (obrazy, skrypty, media) z długim czasem życia (TTL); Front Door kieruje żądania dynamiczne z WAF, terminacją TLS i routingiem opartym na ścieżce. Taki podział maksymalizuje wskaźniki trafień w pamięci podręcznej (cache hit rate) i minimalizuje opóźnienia dynamiczne.
Dla API lub stron, które nie mogą być buforowane, utrzymuj niski TTL lub omijaj buforowanie; dla częściowo statycznego HTML rozważ krótkie TTL z przepływami pracy typu purge-on-change (czyszczenie przy zmianie).

Praktyczny scenariusz problemu

Mozilla uruchamia globalną mikrowitrynę do odkrywania dodatków, spodziewając się wysokich skoków ruchu podczas wydań. Potrzebują szybkiego dostarczania zasobów statycznych, odpornych dynamicznych API oraz bezpiecznych interakcji użytkownika o niskim opóźnieniu na całym świecie.

Front Door dla globalnego punktu wejścia i bezpieczeństwa

Utwórz profil Front Door Standard z domeną niestandardową i zarządzanym TLS. Zdefiniuj reguły routingu: /api/* do grupy źródeł API w App Service oraz /* do nazwy hosta punktu końcowego CDN.
Dlaczego: Routing anycast kieruje użytkowników do najbliższego brzegu sieci; WAF na poziomie Front Door blokuje złośliwe wzorce przed dotarciem do źródeł; routing oparty na ścieżce czysto oddziela ruch dynamiczny od statycznego.

Polityka WAF i ograniczanie szybkości

Dołącz politykę WAF z włączonymi zarządzanymi zestawami reguł oraz niestandardową regułą dławiącą nadmierne żądania POST do /api/search.
Dlaczego: Chroni API przed atakami klasy OWASP i szkodliwymi klientami, oszczędzając zasoby źródłowe podczas skoków ruchu.

Sondy kondycji i grupy źródeł

Skonfiguruj grupę źródeł API z dwiema instancjami App Service w różnych regionach. Użyj sond kondycji na /healthz z oczekiwanym statusem 200 i interwałem 10 sekund. Ustaw jeden region na priorytet 1, a drugi na priorytet 2, z przełączaniem awaryjnym (failover).
Dlaczego: Zapewnia automatyczny regionalny failover, jeśli główny region ulegnie degradacji; sondy wykrywają kondycję niezależnie od odpowiedzi z pamięci podręcznej.

Sesja oparta na Redis i buforowanie danych wyjściowych

Wdróż Azure Cache for Redis Standard i zintegruj API z IDistributedCache, aby przechowywać minimalny stan sesji i krótko żyjące fragmenty danych wyjściowych dla popularnych odpowiedzi API (np. listy popularnych dodatków) z TTL wynoszącym 60–300 sekund.
Dlaczego: Redukuje opóźnienia API i obciążenie bazy danych, utrzymując stan poza warstwą webową; krótkie TTL zapewniają aktualność danych bez potrzeby ręcznego unieważniania.

Struktury danych Redis dla rankingów

Użyj posortowanego zbioru (sorted set) Redis dla każdej kategorii (np. addons:top:{category}), aby utrzymywać rankingi oparte na liczbie pobrań. Aktualizuj wyniki asynchronicznie przez konsumenta kolejki i udostępniaj API do odczytu, które pobierają N najlepszych wpisów.
Dlaczego: Posortowane zbiory zapewniają aktualizacje w czasie O(log n) i szybkie odczyty zakresów, co jest idealne dla rankingów w czasie rzeczywistym z wysoką współbieżnością odczytu.

Odporność połączenia z StackExchange.Redis

Zainicjuj singleton ConnectionMultiplexer z ustawieniami ssl=True, abortConnect=False, connectRetry=5 i rozsądnymi timeoutami. Obsługuj zdarzenia ConnectionFailed/Restored dla obserwacji i ustaw SyncTimeout na tyle wysoko, aby obsłużyć nagłe wzrosty ruchu, używając jednocześnie API asynchronicznych.
Dlaczego: Zapewnia płynną obsługę przełączania awaryjnego (failover) i unika awarii w całym procesie podczas przejściowych zdarzeń sieciowych lub przełączeń awaryjnych Redis.

CDN dla zasobów statycznych z agresywnym buforowaniem

Utwórz profil i punkt końcowy Azure CDN zoptymalizowany pod kątem ogólnego dostarczania treści internetowych, używając statycznej witryny internetowej na koncie magazynu jako źródła. Skonfiguruj reguły buforowania, aby respektowały nagłówki źródłowe, ale nadpisz TTL na 7 dni dla /static/* i włącz kompresję. Ustaw buforowanie ciągów zapytań na “Buforuj każdy unikalny adres URL” i stosuj fingerprinting zasobów (app.css?v=hash).
Dlaczego: Buforowanie na brzegu sieci dostarcza zasoby szybko na całym świecie; fingerprinting pozwala na długie TTL z natychmiastowymi aktualizacjami przy wdrożeniach; kompresja zmniejsza rozmiary transferowanych danych.

Proces czyszczenia (purge) w CI/CD

Dodaj krok wdrożenia, który czyści ścieżki CDN dla plików HTML i manifestów JSON podczas wydania (np. /index.html, /manifest/*.json) i wstępnie ładuje krytyczne strony, aby rozgrzać pamięć podręczną w obsługiwanych warstwach.
Dlaczego: Zapewnia, że użytkownicy szybko otrzymują świeży HTML, jednocześnie utrzymując niezmienne zasoby w pamięci podręcznej; wstępne ładowanie zmniejsza opóźnienie zimnego startu po wdrożeniu.

Koligacja sesji Front Door tylko tam, gdzie jest to wymagane

Utrzymuj API bezstanowe i polegaj na Redis dla stanu sesji; wyłącz koligację sesji Front Door dla tras /api/. Dla starszego narzędzia administracyjnego, które wymaga koligacji, włącz ją na /admin/ z krótkim TTL.
Dlaczego: Maksymalizuje dystrybucję obciążenia i możliwość buforowania dla większości użytkowników, ograniczając jednocześnie koligację do minimalnego wymaganego zakresu.

Ta architektura wykorzystuje Front Door do bezpiecznego, inteligentnego routingu na brzegu sieci i WAF, Azure CDN do dostarczania treści statycznych z wysokim wskaźnikiem trafień i precyzyjną kontrolą aktualności, oraz Azure Cache for Redis do odciążania gorących odczytów, utrzymywania danych sesji i rankingów z niskim opóźnieniem oraz płynnego absorbowania skoków ruchu.

← Rozwiązania oparte na zdarzeniach i komunikatach w Azure · Wszystkie domeny · Monitorowanie →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →