Google PCNE: Równoważenie obciążenia, Cloud CDN i globalne zarządzanie ruchem — Przewodnik do nauki

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Część Google Professional Cloud Network Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Ta sekcja wyjaśnia, jak Google Cloud Load Balancing, Cloud CDN i globalne zarządzanie ruchem współpracują ze sobą, aby dostarczać odporne, wydajne i bezpieczne usługi. Obejmuje ona rodziny i wybór systemów równoważenia obciążenia, zachowanie typu proxy w porównaniu z passthrough, komponenty backendu i routingu, zarządzanie przełączaniem awaryjnym i pojemnością, buforowanie i ochronę origin w Cloud CDN, projekty anycast i międzyregionalne, sterowanie DNS i kontrole stanu, obserwowalność oraz wzorce projektowe dla solidnych globalnych punktów wejścia.

Rodziny systemów równoważenia obciążenia, ich wybór i zachowanie płaszczyzny danych

Google Cloud oferuje zewnętrzne i wewnętrzne systemy równoważenia obciążenia o odmiennych zakresach, protokołach i charakterystykach płaszczyzny danych. Wybór odpowiedniego z nich pozwala dopasować potrzeby protokołu, geografię i mechanizmy kontroli operacyjnej.

Zewnętrzny proxy L7 (globalny): External Application Load Balancer dla HTTP(S) i gRPC. Terminuje TLS, wymusza polityki L7, obsługuje mapy URL, Cloud CDN, Cloud Armor, funkcje żądań/odpowiedzi oraz anycast IPv4/IPv6. Najlepszy dla publicznych interfejsów API/stron internetowych wymagających zaawansowanego routingu, bezpieczeństwa i buforowania.
Zewnętrzny proxy L4.5: External TCP Proxy Load Balancer (globalny) i External UDP Proxy Load Balancer (regionalny) terminują połączenia klientów i przekazują je do backendów. Używaj, gdy potrzebujesz globalnego VIP i funkcji L4 (polityka TLS, zachowanie adresu IP klienta poprzez nagłówki dla TCP) bez routingu L7.
Zewnętrzny passthrough L3/L4 (regionalny): External Network Load Balancer przekazuje pakiety bez terminowania połączenia. Najniższe opóźnienie i najprostsza konfiguracja; obsługuje TCP/UDP/ESP/ICMP. Odpowiedni dla migracji typu lift-and-shift, heterogenicznych backendów lub protokołów, które nie tolerują terminacji przez proxy. Klasyczny NLB używa pul docelowych (target pools); nowszy regionalny NLB typu passthrough używa usług backendu (backend services).
Wewnętrzny proxy (regionalny): Internal HTTP(S) Load Balancer (L7) i Internal TCP Proxy Load Balancer (L4.5) terminują i przekazują ruch wewnątrz VPC dla komunikacji północ-południe (north-south) mikrousług i komunikacji między usługami. Obsługują routing na podstawie hosta/ścieżki (HTTP), mTLS do klientów przez aplikację oraz polityki bezpieczeństwa per usługa.
Wewnętrzny passthrough (regionalny): Internal TCP/UDP Load Balancer dystrybuuje połączenia do backendów w prywatnej przestrzeni adresowej RFC1918, zachowując IP klienta i używając haszowania MAGLEV. Idealny dla usług wschód-zachód (east-west) (bazy danych, niestandardowe protokoły) wymagających dystrybucji z uwzględnieniem strefy (zone-aware) i niskiego narzutu.

Kompromisy dotyczące warstwy i terminacji:

Proxy L7/4.5 zapewnia zaawansowany routing, odciążenie TLS, obserwowalność, Cloud Armor/CDN i międzyregionalne przełączanie awaryjne kosztem dodatkowych przeskoków (hops) i możliwych zmian w nagłówkach/NAT. Pasuje do publicznych punktów wejścia i siatek usług (service meshes).
Passthrough L3/L4 zachowuje IP klienta na całej trasie (end-to-end) i minimalizuje opóźnienia, ale nie oferuje funkcji L7 i ma mniej punktów zaczepienia dla obserwowalności. Zachowanie sesji opiera się na haszowaniu; kontrole stanu są prostsze.

Zakres i rodziny adresów IP:

Globalne adresy VIP anycast są dostępne dla zewnętrznego Application LB i zewnętrznego TCP Proxy LB, zapewniając pojedyncze adresy IPv4/IPv6 osiągalne z każdego miejsca. Regionalne systemy LB używają regionalnych adresów VIP unicast. Udostępnienie usług publicznych przez IPv6 jest realizowane poprzez skonfigurowanie zewnętrznego globalnego systemu równoważenia obciążenia z adresem IPv6.

Najważniejsze kryteria wyboru:

Potrzebujesz routingu na podstawie hosta/ścieżki, przekierowań, Cloud CDN, Cloud Armor lub gRPC: External Application LB.
Potrzebujesz globalnego TCP bez L7: External TCP Proxy LB.
Protokoły, które nie działają dobrze z proxy (np. niektóre starsze UDP/TFTP): Zewnętrzny lub wewnętrzny passthrough.
Prywatna komunikacja między usługami z routingiem HTTP: Internal HTTP(S) LB.
Minimalizacja kosztów/przeskoków dla ruchu wewnątrz VPC: Wewnętrzny passthrough.

Usługi backendowe, obiekty routingu, sprawdzanie kondycji i lepkość ruchu

Podstawowe obiekty płaszczyzny danych:

Backend services: Definiują backendy (grupy instancji, zonal NEG, hybrid NEG, serverless NEG), sprawdzanie kondycji, tryb równoważenia, pojemność, koligację sesji, limit czasu i politykę przełączania awaryjnego. Wymagane dla systemów równoważenia obciążenia typu proxy oraz nowszych systemów typu passthrough.
Target pools: Starsza konstrukcja dla klasycznego zewnętrznego NLB. Odpowiednie dla prostych dystrybucji TCP/UDP i heterogenicznych maszyn wirtualnych podczas migracji typu lift-and-shift.
Named ports: Klucze w grupach instancji mapujące nazwy logiczne (np. http) na numery portów, do których odwołują się usługi backendowe i mapy URL. Należy zapewnić spójność między członkami grupy.

Sprawdzanie kondycji i przełączanie awaryjne:

Typy: HTTP(S), HTTP/2, gRPC, TCP, SSL. Wybierz kontrolę, która weryfikuje faktyczną gotowość usługi, a nie tylko osiągalność systemu operacyjnego.
Zakres: Sprawdzanie kondycji ma zasięg regionalny; każdy backend powinien mieć kontrolę kondycji o zakresie odpowiadającym regionowi, w którym działa.
Polityka przełączania awaryjnego: Usługa backendowa może wyznaczyć backendy podstawowe i awaryjne. Ruch jest przełączany awaryjnie, gdy backend podstawowy jest w złej kondycji lub wyczerpał swoją pojemność (jeśli włączono przełączanie przy wyczerpaniu pojemności i osiągnięto próg). Rozważ opróżnianie połączeń (draining) i rezerwację pojemności, aby uniknąć efektu „pędzącego stada” (thundering herd).

Mapy URL i routing:

Mapa URL jest dołączana do zewnętrznego lub wewnętrznego systemu równoważenia obciążenia HTTP(S) i definiuje reguły hosta oraz dopasowania ścieżek (path matchers).
Usługa domyślna: Backend typu catch-all dla żądań, które nie pasują do żadnej reguły; jeśli nie jest ustawiony, zwracany jest błąd 404.
Przekierowania i przepisywanie: Użyj akcji mapy URL do wykonywania przekierowań HTTPS, przekierowań do hosta kanonicznego lub przepisywania ścieżek przed routingiem.

Przykład: minimalna mapa URL z przekierowaniem HTTPS i domyślnym backendem

Utwórz regułę hosta dla example.com, przekierowującą HTTP na HTTPS, kierującą /static do zasobnika backendowego z włączonym CDN i domyślnie do regionalnej usługi backendowej.

Koligacja sesji i opróżnianie połączeń:

Opcje koligacji zależą od typu systemu równoważenia obciążenia. Typowe opcje:
- Brak: Najlepsza dla aplikacji bezstanowych; maksymalizuje dystrybucję obciążenia.
- Adres IP klienta: Utrzymuje sesję na podstawie źródłowego adresu IP w warstwach L4/L7; używaj, gdy wiele protokołów (np. HTTP i TFTP) musi być powiązanych z tym samym backendem.
- Wygenerowane ciasteczko (tylko L7): System równoważenia obciążenia ustawia ciasteczko, aby utrzymać sesję z backendem; zapewnia lepszą dystrybucję niż koligacja po IP klienta w przypadku klientów za NAT.
Kompromisy: Koligacja może powodować powstawanie gorących punktów (hotspotting) i komplikować autoskalowanie. W miarę możliwości preferuj rozwiązania bezstanowe.
Opróżnianie połączeń: Podczas skalowania w dół lub usuwania backendu, system równoważenia obciążenia respektuje limit czasu opróżniania, aby pozwolić istniejącym połączeniom na łagodne zamknięcie. Dostosuj czas opróżniania do najdłuższego oczekiwanego żądania, aby zapobiec resetowaniu połączeń.

Pojemność i autoskalowanie:

Tryby równoważenia: Oparte na wykorzystaniu (np. CPU), liczbie żądań na sekundę (RPS) lub liczbie połączeń. Każdy backend ogłasza swoją pojemność; system równoważenia obciążenia odrzuca nadmiarowy ruch lub przełącza awaryjnie, gdy nastąpi nasycenie.
Autoskalowanie: Zarządzane grupy instancji skalują się na podstawie sygnałów (CPU, metryki niestandardowe). Opóźnienie w skalowaniu w górę może powodować błędy 503, jeśli systemowi równoważenia obciążenia zabraknie pojemności; zastosuj wstępne rozgrzewanie (pre-warming) poprzez ustawienie minimalnej liczby replik lub predykcyjne autoskalowanie dla ruchu dobowego.
Przełączanie awaryjne i nadmiarowość: Włączenie przełączania awaryjnego przy wyczerpaniu pojemności z odpowiednim progiem pozwala na płynne przenoszenie nadmiarowego ruchu między regionami.

Bezpieczeństwo na poziomie backendów:

Ogranicz dostęp do backendu za pomocą reguł zapory sieciowej kierowanych na tagi instancji lub konta usług. Zezwalaj tylko na ruch pochodzący z zakresów źródłowych systemów równoważenia obciążenia i mechanizmów sprawdzania kondycji Google oraz z zatwierdzonych zakresów klientów, jeśli wymagany jest bezpośredni dostęp dla klientów wewnętrznych.

Przykład: ograniczenie dostępu dla klientów i mechanizmów sprawdzania kondycji do grupy oznaczonej tagiem backendu

Oznacz instancje tagiem application.
Utwórz regułę zezwalającą na ruch przychodzący (ingress) dla tcp:80 z Twoich zakresów CIDR klientów oraz zakresów sprawdzania kondycji Google, kierowaną na tag application.
Zalecana jest domyślna polityka blokowania (deny-by-default), aby odrzucony ruch był widoczny w logach.

Cloud CDN, polityka pamięci podręcznej i ochrona origin

Cloud CDN integruje się z zewnętrznym Application Load Balancer, aby buforować odpowiedzi w brzegowych punktach obecności (POP), zmniejszając opóźnienia i odciążając zasoby serwerów origin.

Tryby pamięci podręcznej i TTL:

Użyj nagłówków origin: Respektuje nagłówki Cache-Control i Expires z Twojego serwera origin. Preferowane dla zapewnienia poprawności.
Wymuś buforowanie: Buforuje wszystkie odpowiedzi z skonfigurowanym domyślnym czasem życia (TTL), opcjonalnie nadpisując lub ignorując nagłówki origin dla treści statycznych. Używaj ostrożnie, aby uniknąć buforowania danych dynamicznych.
Omiń pamięć podręczną: Przydatne dla ścieżek, które nigdy nie powinny być buforowane.

Klucze pamięci podręcznej:

Pola klucza obejmują protokół, hosta, ścieżkę, parametry zapytania, nagłówki i pliki cookie. Skonfiguruj politykę dla query-string (uwzględnij wszystkie, uwzględnij wybrane lub ignoruj), selektywne dołączanie nagłówków i plików cookie oraz segmentację urządzeń w zależności od potrzeb.
Utrzymuj klucze na minimalnym poziomie, aby zmaksymalizować współczynnik trafień (hit ratio); różnicuj je tylko na podstawie pól, które zmieniają reprezentację treści.

Podpisane żądania:

Podpisane adresy URL: Dołącz sygnaturę HMAC lub RSA z datą wygaśnięcia i zakresem ścieżki, aby przyznać ograniczony czasowo dostęp do określonych zasobów. Dobre rozwiązanie dla CDN jako akceleratora z autoryzacją na poziomie pojedynczych obiektów.
Podpisane pliki cookie: Autoryzuj zestaw ścieżek za pomocą pliku cookie; przydatne dla treści chronionych na całej stronie.
Rotuj klucze i wymuszaj krótkie okresy ważności, aby zmniejszyć ryzyko ataków typu replay.

Kompresja i poprawność:

Serwery origin muszą kompresować dane, nawet gdy żądania zawierają nagłówek Via. Jeśli CDN serwuje nieskompresowane obiekty, podczas gdy origin „wspiera kompresję”, sprawdź, czy origin jest skonfigurowany do kompresji, gdy nagłówek Via jest obecny.

Bezpieczeństwo serwerów origin:

Używaj HTTPS od serwerów proxy na brzegu sieci do serwerów origin z nowoczesnymi politykami TLS.
Ogranicz osiągalność serwerów origin: reguły firewalla dla backendu, które zezwalają na ruch tylko z zakresów źródłowych load balancera Google i health checków oraz od znanych prywatnych producentów. Instancje backendu nie powinny akceptować dowolnego ruchu przychodzącego z sieci publicznej.
Połącz z Cloud Armor w celu ochrony przed atakami DDoS na warstwie 7 (L7)/WAF, ograniczania liczby zapytań (rate limiting) i wykrywania zagrożeń. Użyj trybu podglądu (preview mode) dla nowych reguł, aby ograniczyć fałszywe alarmy (false positives).
Celowo unieważniaj zawartość za pomocą API do unieważniania pamięci podręcznej, gdy musisz usunąć dane przed wygaśnięciem TTL. W przypadku treści dynamicznych preferuj krótkie czasy TTL i rewalidację (ETag/If-None-Match).

Tryby awarii i kompromisy:

Zbyt szerokie klucze pamięci podręcznej marnują miejsce w cache’u i obniżają współczynnik trafień; zbyt wąskie klucze grożą serwowaniem nieprawidłowych wariantów treści.
Wymuszone buforowanie danych dynamicznych może prowadzić do wycieku spersonalizowanych treści.
Podpisane adresy URL/pliki cookie chronią dostęp na brzegu sieci, ale bezpośredni dostęp do serwerów origin z pominięciem CDN musi być nadal blokowany za pomocą polityki sieciowej.

← Łączność hybrydowa · Wszystkie domeny · Cloud DNS →

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