Google ACE: Compute Engine i operacje na maszynach wirtualnych — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Przegląd

Compute Engine dostarcza elastyczne, wysokowydajne maszyny wirtualne i prymitywy orkiestracji do uruchamiania obciążeń ogólnego przeznaczenia i specjalistycznych. Doskonałość operacyjna w Compute Engine oznacza wybór odpowiedniej rodziny maszyn i dysków, kształtowanie cyklu życia instancji za pomocą szablonów i grup instancji, ustanowienie solidnych mechanizmów automatycznego leczenia i skalowania, wzmacnianie ścieżek dostępu oraz przygotowanie na tryby awaryjne za pomocą powtarzalnych procedur odzyskiwania. Ta sekcja wyjaśnia wybory projektowe, kompromisy i wzorce operacyjne, które minimalizują wysiłek oraz maksymalizują niezawodność i efektywność kosztową.

Typy maszyn, dobór rozmiaru i cykl życia instancji

Rodziny maszyn

Ogólnego przeznaczenia: E2 (zoptymalizowane kosztowo), N2 (zrównoważone), N2D (oparte na AMD), Tau T2D/T2A (wysoki stosunek ceny do wydajności dla rozwiązań scale-out), odpowiednie dla większości obciążeń.
Zoptymalizowane pod kątem obliczeń: C3 dla zadań intensywnie wykorzystujących CPU; wybierz, gdy potrzebujesz wysokiej wydajności na rdzeń.
Zoptymalizowane pod kątem pamięci: seria M dla baz danych w pamięci (in-memory) i analityki.
Procesory graficzne (GPU) i akceleratory: dołączaj do obsługiwanych rodzin, gdy potrzebujesz akceleracji CUDA lub ML; upewnij się, że inicjalizacja sterowników jest uwzględniona w procesach startowych.

Niestandardowe typy maszyn

Używaj niestandardowych liczby vCPU i ilości pamięci, aby odpowiednio dopasować rozmiar obciążeń i zredukować marnotrawstwo, zwłaszcza w przypadku asymetrycznych potrzeb (np. dużo pamięci, ale umiarkowane użycie CPU).
Dla usług intensywnie wykorzystujących CPU preferuj większą liczbę vCPU; dla usług ograniczonych pamięcią zwiększ RAM i upewnij się, że mechanizmy garbage collector i pamięci podręczne są dostrojone.
Zwracaj uwagę na modele licencjonowania powiązane z liczbą rdzeni; niestandardowe typy pomagają unikać niepotrzebnych licencjonowanych rdzeni.

Dobór rozmiaru obciążenia

Zacznij od profili zasobów zmierzonych w środowiskach deweloperskich lub poprzednich: wykorzystanie CPU na poziomie P95, maksymalne użycie pamięci (high-water mark), przepustowość/IOPS dysku, przepustowość sieci.
Dla ruchu o charakterze impulsowym (bursty) zaplanuj zapas zasobów (headroom) lub użyj automatycznego skalowania; dla ruchu o stałym natężeniu celuj w 60–70% wykorzystania w szczycie, aby zrównoważyć koszty i odporność.
Rozważ użycie maszyn Spot VM (preemptible) dla zadań wsadowych i odpornych na błędy; mogą one zostać zakończone w dowolnym momencie, więc projektuj z uwzględnieniem checkpointingu i ponawiania prób.

Zasoby cyklu życia instancji

Instancje VM: Atomowy zasób obliczeniowy. Używaj etykiet i spójnego nazewnictwa do napędzania automatyzacji.
Szablony instancji: Niezmienne wzorce (blueprints) definiujące typ maszyny, dyski, konta usług, metadane i skrypty startowe; stanowią podstawę dla zarządzanych grup instancji i zapewniają powtarzalne wdrożenia.
Zarządzane grupy instancji (MIG): Zapewniają deklaratywny rozmiar, automatyczne skalowanie, automatyczne leczenie, aktualizacje stopniowe (rolling updates), rozmieszczenie regionalne (wielostrefowe) i konfigurację per instancja. Preferuj MIG dla wzorców bezstanowych i stanowych (stanowe MIG zachowują wybrane dyski/adresy IP).
Niezarządzane grupy instancji: Proste kolekcje do równoważenia obciążenia dla starszych zestawów; brak automatycznego skalowania/leczenia. Używaj tylko wtedy, gdy musisz zarejestrować niezależnie zarządzane maszyny wirtualne.

Dostępność, automatyczne skalowanie i konserwacja

Automatyczne skalowanie

Sygnały: Wykorzystanie CPU, liczba żądań na sekundę na instancję z load balancera HTTP, metryki Cloud Monitoring i głębokość kolejki. Wybierz sygnał ściśle skorelowany z nasyceniem; CPU jest dobrym punktem wyjścia dla jednorodnych obciążeń intensywnie wykorzystujących CPU.
Okresy przejściowe (cooldown) i stabilizacja: Skonfiguruj, aby zapobiec gwałtownym zmianom (thrashing). Jeśli Twoja aplikacja potrzebuje kilku minut na rozgrzanie, zwiększ opóźnienie początkowe (initial delay) dla MIG i ustaw odpowiedni cooldown dla automatycznego skalowania.
Wzorce “dokładnie jedna”: Aby wymusić działanie dokładnie jednej maszyny wirtualnej, ustaw min=1 i max=1 w konfiguracji automatycznego skalowania MIG. Pozwala to zachować sprawność, jednocześnie włączając automatyczne leczenie.

Automatyczne leczenie i kontrole stanu

Kontrole stanu: Używaj kontroli HTTP(S) do sprawdzania żywotności (liveness) aplikacji; TCP weryfikuje tylko akceptację połączenia na gnieździe. Zaimplementuj endpoint kontroli stanu, który testuje krytyczne zależności.
Progi i interwały: Dostosuj interwał kontroli (check-interval) i progi, aby szybko wykrywać awarie bez fałszywych alarmów (false positives).
Opóźnienie początkowe: Ustaw opóźnienie początkowe automatycznego leczenia MIG na tyle długo, aby umożliwić uruchomienie i rozgrzanie, unikając przedwczesnej wymiany sprawnych instancji, które dopiero się uruchamiają.
Tryby awarii: Źle skonfigurowane endpointy kontroli stanu i zbyt krótkie opóźnienia początkowe powodują niestabilność (flapping) i nadmierną alokację zasobów (overprovisioning).

Regionalne grupy MIG i rozmieszczenie

Regionalne grupy MIG dystrybuują instancje w wielu strefach w danym regionie, zapewniając odporność na awarie stref. Wybierz docelową liczbę replik na strefę na podstawie planowania pojemności.
Używaj konfiguracji per instancja i polityk stanowych, gdy wymagane jest zachowanie dysków lub adresów IP; pamiętaj, że wymiana maszyn wirtualnych może być wolniejsza z powodu uzgadniania stanu.

Konserwacja, migracja na żywo i rezerwacje

Migracja na żywo (Live migration): Domyślne zachowanie dla większości maszyn wirtualnych; instancje są przenoszone podczas konserwacji hosta bez ponownego uruchamiania. Dla obciążeń, które nie tolerują migracji (np. wrażliwe na opóźnienia HFT), ustaw politykę konserwacji na zakończenie (terminate) i polegaj na automatycznym leczeniu.
Okna konserwacji hosta są przezroczyste dzięki migracji na żywo, ale nadal generują zdarzenia; monitoruj je i testuj.
Rezerwacje: Twórz rezerwacje strefowe, aby zagwarantować pojemność dla krytycznych uruchomień lub rygorystycznych umów SLO. Zastosuj konsumpcję rezerwacji “określoną” (specific) lub “dowolną” (any) w zależności od zasad ładu organizacyjnego.
Rezerwacje to gwarancje pojemności; połącz je ze zniżkami za zobowiązanie użycia (committed use discounts) w celu planowania kosztów.

Pamięć masowa, obrazy i wydajność

Dyski trwałe

Typy: Standard (HDD) dla sekwencyjnej przepustowości przy niskim koszcie; Balanced (pd-balanced) do ogólnego użytku; SSD (pd-ssd) dla wysokiej liczby IOPS i niskich opóźnień; Extreme (pd-extreme) dla provisioned IOPS i przepustowości na wysokich poziomach wydajności. Regionalne dyski trwałe (Regional PDs) zapewniają synchroniczną replikację między strefami dla zwiększonej dostępności.
Wydajność skaluje się wraz z rozmiarem dysku dla typów standard, balanced i SSD; należy wstępnie dobrać rozmiar, aby sprostać szczytowemu zapotrzebowaniu na IOPS/przepustowość, lub użyć typu Extreme, aby jawnie je alokować.
Tryb Multi-attach tylko do odczytu pozwala na współdzielenie zbiorów danych między wieloma maszynami wirtualnymi; należy odpowiednio koordynować dostęp i warstwy buforowania.

Lokalne dyski SSD

Efemeryczne, podłączone bezpośrednio do hosta, o bardzo wysokiej liczbie IOPS i niskich opóźnieniach. Dane są tracone podczas zatrzymania, zakończenia lub migracji maszyny. Używane jako przestrzeń tymczasowa (scratch), pamięci podręczne i warstwy danych z replikacją. Należy zapewnić replikację lub punkty kontrolne na poziomie aplikacji.

Migawki i obrazy

Migawki to przyrostowe kopie zapasowe dysków trwałych w punkcie w czasie; należy je zaplanować za pomocą Resource Manager lub gcloud, aby spełnić RPO. Przechowywanie w wielu regionach wspiera odtwarzanie po awarii (DR).
Obrazy zawierają dyski rozruchowe wraz z konfiguracją. Należy utrzymywać utwardzony, zarządzany proces tworzenia obrazów z uwzględnieniem poprawek. Weryfikuj działanie agentów gościa (do logowania/monitorowania) w swoich złotych obrazach.
Wzorce przywracania: Aby zapewnić szybkie odzyskiwanie, utrzymuj małe obrazy bazowe, a resztę konfiguruj za pomocą skryptów startowych lub cloud-init; zmniejsza to dryf konfiguracyjny i przyspiesza aktualizacje.

Wybór dysku: kompromisy i tryby awarii

Niedostatecznie zwymiarowane dyski ograniczają przepustowość aplikacji; nadmierne wymiarowanie generuje niepotrzebne koszty. Zmierz rzeczywistą charakterystykę I/O i wybierz najmniejszy dysk spełniający szczytowe potrzeby z marginesem.
W przypadku baz danych rozważ użycie regionalnych dysków trwałych oraz pd-ssd/pd-extreme; zweryfikuj zachowanie fsync i głębokości kolejek. Unikaj lokalnych dysków SSD do przechowywania trwałego stanu, chyba że dane są replikowane.

Dostęp, bezpieczeństwo, sieć i wyspecjalizowane obciążenia

Administracja systemami Linux i Windows

SSH w Linuksie: Preferuj OS Login, aby scentralizować autoryzację SSH i przypisywać dostęp do tożsamości. Nadawaj role compute.osLogin lub compute.osAdminLogin grupom, a nie pojedynczym użytkownikom.
RDP w Windows: Ustaw poświadczenia Windows w konsoli lub przez gcloud; upewnij się, że reguły zapory sieciowej zezwalają na ruch TCP 3389 tylko z zaufanych adresów IP. Użyj IAP TCP forwarding, aby uniknąć publicznej ekspozycji.
Konsola szeregowa: Włącz jako ścieżkę awaryjną (break-glass); użyj gcloud compute connect-to-serial-port do debugowania rozruchu. Ograniczaj dostęp za pomocą IAM i audytuj go.

SSH, OS Login i zarządzanie kluczami

Włącz OS Login na poziomie projektu lub instancji za pomocą metadanych enable-oslogin=TRUE. Użytkownicy dodają swój publiczny klucz SSH do swojego konta Google; IAM kontroluje dostęp oparty na rolach.
Aby uzyskać uprawnienia sudo/root, użyj roli compute.osAdminLogin. Wyłącz klucze SSH na poziomie projektu, jeśli używasz OS Login, aby zapobiec rozbieżnościom.

Metadane, skrypty startowe i cloud-init

Serwer metadanych dostarcza dane instancji/projektu oraz tokeny kont serwisowych. Używaj tylko tokenów o wąskim zakresie; nigdy nie zaszywaj na stałe danych uwierzytelniających w kodzie.
Skrypty startowe i cloud-init: Inicjuj agentów, pobieraj konfiguracje i rejestruj usługi. Twórz skrypty idempotentne i zapisuj logi do konsoli szeregowej w celach diagnostycznych.
Metadane na poziomie instancji mogą nadpisywać ustawienia szablonu; używaj ich ostrożnie, aby uniknąć niespójności konfiguracji.

Konta serwisowe i zakresy

Przypisuj dedykowane konto serwisowe do każdego obciążenia, z rolami IAM o najmniejszych uprawnieniach do wymaganych zasobów (np. storage.objectCreator dla konkretnego bucketu).
Preferuj szerokie zakresy dostępu do Cloud API tylko wtedy, gdy dostęp jest ściśle kontrolowany przez IAM; w przeciwnym razie ogranicz zakresy do minimalnego zestawu API.

Sieć i adresacja

Karty sieciowe (NIC) mogą mieć tylko wewnętrzne lub również zewnętrzne adresy IP. Preferuj prywatne maszyny wirtualne z Cloud NAT lub IAP dla ruchu wychodzącego i dostępu administracyjnego.
Rezerwuj statyczne wewnętrzne adresy IP dla stabilnych punktów końcowych, takich jak serwery licencji; unikaj zależności od adresów efemerycznych.
Zewnętrzny External HTTP(S) Load Balancing kończy sesję TLS na brzegu sieci; używaj zarządzanych certyfikatów i kontroli stanu (health checks) dla backendowych grup MIG. Utrzymuj zgodność gotowości backendu z kontrolą stanu i opóźnieniem początkowym MIG.

Wyspecjalizowane obciążenia i izolacja

Shielded VMs: Secure boot, vTPM i monitorowanie integralności ograniczają ryzyko rootkitów; włączaj domyślnie, chyba że wymagają tego niekompatybilne sterowniki.
Confidential VMs: Szyfrowanie pamięci za pomocą AMD SEV chroni dane w użyciu; zazwyczaj narzut wydajnościowy jest minimalny, ale należy to zweryfikować dla aplikacji wrażliwych na opóźnienia.
Sole-tenant nodes: Dedykowane hosty fizyczne dla zgodności z regulacjami, izolacji od “głośnego sąsiada” (noisy-neighbor) i powiązania licencji (license affinity). Należy uwzględnić fragmentację zasobów i wyższy koszt.

Rozwiązywanie problemów i operacje odzyskiwania

Typowe działania diagnostyczne

Łączność: Sprawdź reguły zapory sieciowej, uprawnienia konta usługi i trasy. Użyj testów łączności w Network Intelligence Center.
Problemy z uruchamianiem: Sprawdź logi konsoli szeregowej, zrób zrzut ekranu i sprawdź dane wyjściowe skryptu startowego. Tymczasowo wyłącz secure boot, jeśli niepodpisane sterowniki blokują uruchomienie, a następnie napraw problem.
Blokada dostępu: W przypadku problemów z SSH przy użyciu OS Login, potwierdź role IAM i istnienie kluczy na kontach użytkowników; użyj konsoli szeregowej, aby dodać użytkownika w trybie awaryjnym (break-glass).
Uszkodzenie dysku: Odłącz dysk rozruchowy, podłącz go do ratunkowej maszyny wirtualnej, napraw systemy plików, zmień poświadczenia i po naprawie utwórz obraz.

Zachowania MIG i load balancera

Nadmiarowe przydzielanie zasobów (overprovisioning): Jeśli instancje potrzebują długiego czasu na rozgrzanie, zwiększ początkowe opóźnienie (initial delay) w MIG i czas uspokojenia (cooldown) autoskalera; w przeciwnym razie może dojść do skalowania w górę z powodu błędów 4xx/5xx, gdy aplikacja wciąż się inicjalizuje.
Pętle samonaprawiania (autohealing): Potwierdź semantykę punktu końcowego kontroli stanu i gotowość zależności; rozłóż w czasie uruchamianie zależności lub dodaj ponawianie prób.

Wzorce odzyskiwania

Odtwórz instancję z szablonu lub obrazu; wzorce niezmienności (immutable patterns) skracają MTTR.
Przywróć dane z ostatniego udanego snapshotu; zweryfikuj RPO/RTO pod kątem wymagań biznesowych.
W przypadku awarii regionalnych, przełącz się na inną strefę lub region, używając regionalnych grup MIG i replikacji snapshotów między regionami.

Zabezpieczenia operacyjne

Rezerwacje dla krytycznej pojemności; używaj alertów opartych na monitoringu zużycia rezerwacji i limitów (quota).
Audyt i logowanie: Włącz logi aktywności administratora i dostępu do danych dla krytycznych usług. Przypisuj dostęp za pomocą OS Login i kont usług.

Krótkie przykłady

Zarezerwuj statyczny wewnętrzny adres IP:

undefined

Włącz OS Login na poziomie projektu:

undefined

Utwórz kontrolę stanu HTTP i podłącz ją do MIG z samonaprawianiem:

undefined

Praktyczny scenariusz problemu

Firma Northwind Analytics uruchamia wrażliwe na opóźnienia API na Compute Engine. Incydenty wykazują częste nadmiarowe przydzielanie zasobów podczas wdrożeń, sporadyczne niejasności dotyczące dostępu przez SSH wśród administratorów oraz licencjonowany serwer telemetryczny, który musi pozostać osiągalny pod adresem 10.0.3.21. Celem jest ustabilizowanie skalowania, wzmocnienie zabezpieczeń dostępu i zapewnienie stabilności punktu końcowego licencji.

Podejście

Utwórz szablon instancji z dopasowanym niestandardowym typem maszyny i bootstrappingiem przy uruchomieniu

Uzasadnienie: Szablon wymusza niezmienność (immutability). Niestandardowy kształt 6 vCPU/20 GB RAM odpowiada zmierzonemu użyciu procesora i pamięci na poziomie P95, unikając jednocześnie nadmiarowych rdzeni, które zwiększają koszty licencji. Skrypt startowy rejestruje API w load balancerze dopiero po pomyślnym przejściu kontroli stanu, co zmniejsza wpływ rozgrzewania się instancji.

Wdróż regionalną zarządzaną grupę instancji (MIG) za zewnętrznym HTTP(S) Load Balancer

Uzasadnienie: Regionalna grupa MIG rozkłada instancje na różne strefy, zapewniając odporność na awarie stref. HTTP(S) load balancer kończy sesję TLS na brzegu sieci i wykonuje kontrole stanu dla każdej instancji, kierując ruch tylko do gotowych backendów.

Skonfiguruj autoskalowanie na podstawie użycia procesora z czasem uspokojenia (cooldown) i samonaprawianie z realistycznym opóźnieniem początkowym

Uzasadnienie: Użycie procesora jest silnie skorelowane z nasyceniem tego API. 90-sekundowy czas uspokojenia zapobiega gwałtownym zmianom w odpowiedzi na chwilowe skoki. 200-sekundowe opóźnienie początkowe jest zgodne z czasem rozgrzewania kontenera i kompilacji JIT, co zapobiega interpretowaniu zimnych startów przez autoskaler jako niedoboru mocy obliczeniowej.

Dostosuj kontrolę stanu i dodaj punkt końcowy /healthz na poziomie aplikacji

Uzasadnienie: Kontrola stanu HTTP, która weryfikuje zależności (pamięć podręczną, łączność z bazą danych), wykrywa ukryte awarie (gray failures). Użycie 10-sekundowych interwałów i 3 progów niezdrowego stanu równoważy szybkość wykrywania i ryzyko fałszywych alarmów.

Włącz OS Login i przyznaj dostęp administracyjny grupie IAM

Uzasadnienie: OS Login centralizuje autoryzację i atrybucję SSH. Administratorzy dodają swoje publiczne klucze SSH do swoich kont Google; przyznanie roli compute.osAdminLogin grupie dyżurnej zapewnia dostęp z uprawnieniami sudo, zachowując jednocześnie ślady audytowe. Eliminuje to problem rozjeżdżania się kluczy między maszynami wirtualnymi.

Zarezerwuj statyczny wewnętrzny adres IP serwera licencji i przypisz go do małej, dedykowanej maszyny wirtualnej

Uzasadnienie: Zarezerwowanie adresu 10.0.3.21 gwarantuje, że jest on dostępny i zapobiega jego przypadkowemu ponownemu użyciu. Przypisz go do interfejsu sieciowego (NIC) maszyny wirtualnej z licencją, aby zależne aplikacje nie wymagały zmian w konfiguracji. Ogranicz zakres reguł zapory sieciowej tylko do dozwolonych podsieci źródłowych.

Przypisz dedykowane konto usługi do szablonu API z najmniejszymi wymaganymi uprawnieniami IAM

Uzasadnienie: Zasada najmniejszych uprawnień (Principle of least privilege) zmniejsza promień rażenia (blast radius). Konto usługi otrzymuje tylko niezbędne role (np. dostęp do odczytu określonych sekretów i tematów Pub/Sub). Użycie szablonu zapewnia, że wszystkie instancje dziedziczą prawidłową tożsamość.

Wzmocnij zabezpieczenia instancji za pomocą Shielded VM i wymuś awaryjny dostęp przez konsolę szeregową

Uzasadnienie: Secure Boot i monitorowanie integralności ograniczają ryzyko manipulacji jądrem/bootloaderem. Ogranicz dostęp do konsoli szeregowej za pomocą IAM i loguj dostęp do celów audytowych; zachowaj go na potrzeby odzyskiwania w przypadku awarii SSH.

Zaimplementuj harmonogramy snapshotów dla dysków stanowych i przetestuj przywracanie

Uzasadnienie: Chociaż API jest bezstanowe, stwórz harmonogram snapshotów dla serwera licencji i wszelkich dysków konfiguracyjnych, aby spełnić wymagania RPO. Okresowe testy odtwarzania weryfikują narzędzia i procedury (runbooks).

Zweryfikuj i wdróż

Uzasadnienie: Wdrożenia typu blue/green lub canary z wykorzystaniem ustawień aktualizacji kroczącej (rolling update) w MIG zmniejszają ryzyko. Pulpity monitoringu potwierdzają stabilizację liczby instancji podczas wdrożeń, lepszą atrybucję dostępu administratorów oraz nieprzerwaną osiągalność adresu 10.0.3.21.

← Hierarchia zasobów · Wszystkie domeny · Kontenery →

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