Google PCA: Moc obliczeniowa, platformy aplikacyjne i architektura obciążeń roboczych — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Przegląd

Ta domena obejmuje sposób wyboru i projektowania platform obliczeniowych w Google Cloud, pakowania i wdrażania aplikacji oraz obsługi obciążeń pod kątem niezawodności, wydajności, bezpieczeństwa i efektywności kosztowej. Obejmuje ona maszyny wirtualne, Kubernetes, bezserwerowe środowiska uruchomieniowe, równoważenie obciążenia, strategie wdrażania, stanowe i wyspecjalizowane zasoby obliczeniowe oraz wzorce modernizacji, które redukują dług techniczny, jednocześnie spełniając zmieniające się wymagania.

Compute Engine i architektury oparte na maszynach wirtualnych

Compute Engine zapewnia szczegółową kontrolę nad systemami operacyjnymi, siecią i typami maszyn. Wybieraj rodziny maszyn na podstawie charakterystyki obciążenia:

E2: zoptymalizowane pod kątem kosztów, ogólnego przeznaczenia; dobre dla środowisk deweloperskich/testowych, aplikacji o nierównomiernym obciążeniu.
N2/N2D: zrównoważony stosunek ceny do wydajności dla większości obciążeń produkcyjnych; N2D wykorzystuje procesory AMD z wysoką przepustowością pamięci.
C2/C2D/C3: zoptymalizowane pod kątem mocy obliczeniowej dla zadań intensywnie wykorzystujących procesor (np. API o wysokiej liczbie zapytań na sekundę, przetwarzanie wsadowe).
M3: zoptymalizowane pod kątem pamięci dla dużych zbiorów danych w pamięci (pamięci podręczne, analityka w pamięci).
A3: zoptymalizowane pod kątem GPU (NVIDIA) do trenowania/wnioskowania; GPU można również dołączać do innych rodzin maszyn.
Confidential VMs (na obsługiwanych procesorach) szyfrują dane w trakcie ich używania przy minimalnych zmianach w kodzie.

Zarządzane grupy instancji (MIGs) zapewniają elastyczność i odporność:

Używaj Szablonów Instancji (Instance Templates) do tworzenia niezmiennej konfiguracji oraz grup MIG do skalowania horyzontalnego w różnych strefach.
Zasady automatycznego skalowania: na podstawie użycia procesora, wykorzystania load balancera, metryk Cloud Monitoring lub głębokości kolejki za pomocą metryk niestandardowych. Ustaw minimalną/maksymalną liczbę replik i okres oczekiwania (cooldown), aby uniknąć gwałtownych zmian przy nierównomiernym obciążeniu.
Aktualizacje stopniowe (rolling updates) i wdrożenia typu canary zmniejszają ryzyko; utrzymuj konserwatywne ustawienia surge (nadmiarowe) i unavailable (niedostępne) dla usług stanowych lub z długim czasem uruchamiania (cold start).

Równoważenie obciążenia i kontrole stanu (health checks):

Globalny zewnętrzny load balancer HTTP(S) kończy sesje TLS, obsługuje mapowanie adresów URL i jest standardowym front-endem dla webowych API; wewnętrzny load balancer HTTP(S) służy do ruchu wschód-zachód (east-west).
Kontrole stanu muszą docierać do backendów. Częstą przyczyną awarii są zablokowane sondy, co powoduje ciągłe restarty instancji i utratę ruchu. Zezwól na ruch z zakresów źródłowych kontroli stanu do portów backendu za pomocą reguł zapory sieciowej VPC i tagów docelowych.

Przykład zezwolenia na kontrole stanu HTTP do grupy MIG:

undefined

Kwestie związane z cyklem życia maszyny wirtualnej:

Używaj skryptów startowych lub metadanych obrazu do inicjalizacji (bootstrap); przechowuj konfigurację środowiska uruchomieniowego w Secret Manager, a nie wbudowaną w obrazy.
W przypadku maszyn wirtualnych typu preemptible/Spot, dodaj skrypt zamykający (shutdown-script), aby dokończyć bieżące zadania po otrzymaniu powiadomienia o zakończeniu.
Stosuj poprawki poprzez przygotowane obrazy i stopniową wymianę, aby unikać dryfu konfiguracji.
Zmiana rozmiaru dysku trwałego (Persistent Disk) odbywa się online: zwiększ rozmiar dysku, a następnie rozszerz system plików (np. resize2fs na ext4) przy minimalnym czasie przestoju.

Przykład zmiany rozmiaru PD:

undefined

Bezpieczna tożsamość i obserwowalność:

Dołączaj do instancji konta usług (service accounts) z minimalnymi wymaganymi uprawnieniami; nie osadzaj statycznych poświadczeń.
Zainstaluj Ops Agent dla Cloud Logging i Cloud Monitoring. Użyj Cloud Trace i Cloud Profiler, aby zmniejszyć opóźnienia krańcowe (tail latency) i zidentyfikować gorące punkty (hot spots).
Eksportuj dane audytowe i metryki do BigQuery lub Cloud Storage w celu długoterminowego przechowywania i analizy.

Przetwarzanie wsadowe i wyspecjalizowane zasoby obliczeniowe:

Używaj Cloud Batch lub grup MIG z maszynami wirtualnymi typu preemptible do odpornego na błędy przetwarzania wsadowego, aby zmniejszyć koszty; zaimplementuj checkpointing (tworzenie punktów kontrolnych).
Dołączaj GPU/TPU tam, gdzie potrzebna jest akceleracja ML. Używaj dedykowanych pul węzłów lub węzłów typu sole-tenant, aby spełnić wymagania dotyczące zgodności/izolacji.
Confidential VMs chronią wrażliwe dane w pamięci; zmierz narzut wydajnościowy w stosunku do wymagań.

Kwestie związane ze stanem:

Utrzymuj instancje aplikacji jako bezstanowe; przenieś sesje do współdzielonego magazynu (np. Memorystore, Cloud SQL), aby uniknąć anomalii widocznych dla użytkownika podczas skalowania.
Dla stanu powiązanego z maszyną wirtualną używaj regionalnych dysków trwałych lub replikowanych baz danych; przetestuj ścieżki przełączania awaryjnego (failover).

Kubernetes i platformy kontenerowe (GKE)

GKE zapewnia zarządzaną płaszczyznę sterowania z elastycznymi pulami węzłów roboczych:

Klastry regionalne replikują płaszczyznę sterowania i węzły w różnych strefach w celu zapewnienia wysokiej dostępności; klastry strefowe koncentrują zasoby w celu obniżenia kosztów i dla zastosowań wrażliwych na opóźnienia.
Używaj wielu pul węzłów do segmentacji obciążeń (np. ogólnego przeznaczenia, GPU, o dużej ilości pamięci, spot). Stosuj taints/tolerations oraz affinity/anti-affinity, aby kontrolować umiejscowienie podów i redukować efekt „głośnego sąsiada”.
Warstwy autoskalowania: cluster autoscaler dodaje/usuwa węzły; Horizontal Pod Autoscaler (HPA) skaluje repliki na podstawie metryk procesora/niestandardowych; Vertical Pod Autoscaler (VPA) dopasowuje zasoby (requests). Połącz HPA z cluster autoscaler, aby uzyskać elastyczność.

Harmonogramowanie obciążeń i usługi:

Dopasuj wartości CPU/memory requests/limits, aby zminimalizować ryzyko eksmisji (eviction) i zmaksymalizować wydajność upakowania (binpacking).
Używaj PodDisruptionBudgets, aby zachować dostępność podczas aktualizacji.
Typy usług (Service): ClusterIP (wewnątrz klastra), NodePort/LoadBalancer (ruch północ-południe) oraz Ingress do routingu HTTP(S) za pomocą globalnego LB. W przypadku wdrożeń canary kieruj ruch za pomocą oddzielnych backendów Service/Ingress lub siatki usług (service mesh).

Aktualizacje i odporność:

Używaj aktualizacji typu surge i parametru maxUnavailable do kontrolowania zmian; przypinaj krytyczne obciążenia do wielu stref i pul.
Ustawiaj okna/wykluczenia konserwacyjne na okresy krytyczne dla działalności biznesowej.
Weryfikuj działanie w środowisku przedprodukcyjnym i na pulach węzłów typu canary przed wdrożeniem na szeroką skalę.

Obrazy i bezpieczeństwo:

Przechowuj obrazy kontenerów w Artifact Registry; włącz skanowanie podatności i skonfiguruj autoryzację binarną lub atestacje pochodzenia.
Używaj Workload Identity do mapowania GSA na KSA w celu uzyskania dostępu do interfejsów API Google bez poświadczeń, zgodnie z zasadą najniższych uprawnień.
Pobieraj konfigurację środowiska uruchomieniowego z Secret Manager za pomocą sterownika CSI; unikaj Kubernetes Secrets dla bardzo wrażliwych danych, chyba że są one zaszyfrowane za pomocą CMEK, a RBAC jest ściśle skonfigurowany.

Wdrożenia (rollout) i wycofywanie zmian (rollback):

Preferuj aktualizacje kroczące (rolling updates) typu Deployment z małymi krokami i sondami kondycji (health probes); dla systemów o niskiej tolerancji na błędy używaj wdrożeń blue-green za pomocą dwóch zasobów Deployment za jedną usługą (Service) i przełączaj etykiety/selektor.
Zawsze definiuj sondy gotowości (readiness) i żywotności (liveness); błędnie skonfigurowane sondy powodują kaskadowe restarty lub czarne dziury podczas wdrożeń.

Platformy bezserwerowe i sterowane zdarzeniami

Platformy bezserwerowe Google Cloud abstrahują infrastrukturę, zapewniając jednocześnie silną kontrolę nad skalą, bezpieczeństwem i kosztami:

Cloud Run: natywnie kontenerowy, wyzwalany przez żądania HTTP lub Eventarc. Skaluje się do zera; konfigurowalna współbieżność; dzielenie ruchu według rewizji dla wdrożeń canary i rollback. Ustaw minimalną liczbę instancji (min instances), aby zredukować zimne starty dla punktów końcowych wrażliwych na opóźnienia. Integruj z VPC za pomocą Serverless VPC Access w celu uzyskania prywatnego ruchu wychodzącego (egress).
App Engine: platforma PaaS o z góry zdefiniowanych założeniach. Środowisko Standard oferuje szybkie skalowanie i ograniczenia współbieżności na żądanie w zależności od języka; Flexible uruchamia kontenery na maszynach wirtualnych z większą kontrolą. Unikaj stanu sesji lokalnego dla instancji; przenieś go do współdzielonej pamięci masowej, aby zapobiec nieaktualnym lub zduplikowanym doświadczeniom użytkownika pod obciążeniem.
Cloud Functions: granularność na poziomie funkcji dla logiki sterowanej zdarzeniami. Używaj wyzwalaczy Pub/Sub, Cloud Storage lub Eventarc do lekkich mikrooperacji; utrzymuj funkcje jako idempotentne i bezstanowe. Dla połączonych potoków wsadowych/strumieniowych bez istniejącego kodu, Dataflow zapewnia zunifikowane przetwarzanie z autoskalowaniem.

Kompromisy przy wyborze platformy:

Kontrola operacyjna: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
Przenośność: oparte na kontenerach (GKE/Cloud Run/App Engine Flex) > obrazy VM > funkcje i App Engine Standard.
Opóźnienie: Cloud Run z min instances lub GKE dla niskiego opóźnienia końcowego (tail latency); unikaj zimnych startów dla obciążeń interaktywnych.
Skalowanie: Cloud Functions/Run skalują się najszybciej; GKE HPA plus cluster autoscaler; MIGs wymagają rozgrzania i sprawdzania kondycji.
Koszt: bezserwerowe (pay-per-use) dla ruchu nieregularnego/niskiego; GKE/VM z rabatami za zobowiązanie użycia (CUD) dla stabilnych usług o dużej przepustowości; preemptible/Spot dla zadań wsadowych.

Tożsamość i konfiguracja:

Każda usługa powinna używać dedykowanego konta serwisowego z najniższymi uprawnieniami. Dla Cloud Run i Functions jawnie ustaw konto serwisowe środowiska uruchomieniowego.
Przechowuj sekrety w Secret Manager i powiąż dostęp za pomocą IAM; wstrzykuj je poprzez zmienne środowiskowe lub montowane woluminy.

Wzorce architektoniczne, dostarczanie i operacje

Dekompozycja usług i granice:

Monolit: najprostsze wdrożenie i transakcje, ale ogranicza niezależne skalowanie i kontrolę nad zasięgiem awarii (blast-radius); może maskować problemy z wydajnością głęboko w łańcuchach wywołań.
Monolit modularny: jasno zdefiniowane moduły wewnętrzne, współdzielony proces; dobry krok pośredni — wymusza stosowanie interfejsów bez narzutów związanych z dystrybucją.
Mikroserwisy: niezależna wdrażalność i skalowanie; wprowadza opóźnienia sieciowe, transakcje rozproszone i wyzwania związane ze spójnością. Zdefiniuj jasne, ograniczone konteksty (bounded contexts) i własność danych; unikaj współdzielonych baz danych, aby zapobiec powiązaniom (coupling).

Wzorce modernizacji:

Wzorzec dusiciela (Strangler-fig): stopniowo kieruj część ruchu do nowych komponentów, wycofując starsze punkty końcowe (endpoints).
Lift and shift: najpierw skonteneryzuj lub zmigruj do maszyn wirtualnych w celu stabilizacji, a następnie refaktoryzuj.
Warstwa antykorozyjna/fasada (Anti-corruption layer/facade): izoluj starsze kontrakty podczas budowania nowych usług.
Nadaj priorytet domenom o wysokiej zmienności i dużym tarciu (high-friction), aby zmaksymalizować wartość biznesową i zredukować ryzyko.

Dostarczanie i wdrożenia (rollouts):

CI/CD z automatycznymi testami i środowiskami przejściowymi (staged environments) redukuje liczbę wycofań (rollbacks). Dodaj analizę canary, budżety błędów (error budgets) i progresywne dostarczanie (progressive delivery).
Blue-green: minimalizuje przestoje i upraszcza wycofywanie kosztem podwójnej pojemności.
Dzielenie ruchu (Traffic splitting): Cloud Run/App Engine wspierają routing procentowy między rewizjami/wersjami; testuj pod rzeczywistym ruchem z ciasnymi budżetami błędów SLO.

Równoważenie obciążenia i kondycja (health):

Używaj globalnego load balancera L7 dla HTTP i TCP proxy dla protokołów innych niż HTTP; wewnętrznych LB dla usług prywatnych. Konfiguruj powinowactwo sesji (session affinity) tylko wtedy, gdy jest to konieczne, i eksternalizuj stan sesji.
Kontrole kondycji (health checks) powinny odzwierciedlać dostępność aplikacji (np. kondycję zależności); proste 200 OK, które maskuje awarię bazy danych, może powodować błędne kierowanie ruchem.

Obserwowalność i ład (governance):

Instrumentuj ślady (traces) w celu przypisania opóźnień end-to-end między usługami; włącz logowanie identyfikatorów żądań (request IDs), aby korelować logi i ślady.
Eksportuj logi/metryki/dzienniki audytu do BigQuery lub Cloud Storage na potrzeby retencji i audytu; zabezpiecz dostęp za pomocą widoków (views) i IAM.
Dla logów z maszyn wirtualnych zainstaluj Ops Agent; zdefiniuj retencję i ujścia (sinks), aby kontrolować koszty i zgodność.

Bezpieczny łańcuch dostaw oprogramowania:

Używaj Artifact Registry ze skanowaniem; utrzymuj minimalne obrazy. Optymalizuj pliki Dockerfile: preferuj lekkie obrazy bazowe (slim), najpierw instaluj zależności, a następnie kopiuj kod źródłowy, aby wykorzystać pamięć podręczną budowania (build cache).

Sieć i segmentacja:

Wymuszaj dostęp warstwowy za pomocą tagów i reguł zapory sieciowej VPC, aby zezwalać tylko na oczekiwane przepływy (np. web → API → DB). Zabroń bezpośredniego dostępu web → DB.

Pojemność, wydajność i wyspecjalizowane zasoby obliczeniowe

Projektowanie pod zmienne zapotrzebowanie:

GCE: autoskalowanie grup MIG w oparciu o wskaźniki wiodące (długość kolejki), aby wyprzedzić nasycenie CPU; dodaj ograniczanie liczby żądań i mechanizmy przeciwciśnienia (backpressure), aby chronić usługi podrzędne.
GKE: połącz HPA w oparciu o liczbę żądań na sekundę lub metryki niestandardowe z autoskalerem klastra; zapewnij mały bufor, aby uniknąć opóźnień w skalowaniu.
Serverless: dostosuj współbieżność i minimalną liczbę instancji, aby zrównoważyć koszt i opóźnienia; użyj wdrożenia regionalnego, aby zapewnić niskie opóźnienia dla użytkowników.

Odporność i testowanie:

Uruchom obciążenie syntetyczne, aby zweryfikować autoskalowanie i cele SLO; uwzględnij testowanie chaosu (np. losowe zamykanie instancji/podów), aby upewnić się, że system utrzymuje dostępność podczas awarii i aktualizacji.
Skonfiguruj PodDisruptionBudgets i hooki łagodnego zamykania (graceful termination), aby opróżnić połączenia przed zamknięciem poda/maszyny wirtualnej.

Wydajność i wybór pamięci masowej:

Ingestia szeregów czasowych i strumieni kliknięć o wysokiej przepustowości i niskiej latencji dobrze pasuje do Bigtable; projektuj szerokie wiersze i klucze z przedziałami czasowymi, aby unikać gorących punktów (hotspots).
Dla Spark/Hadoop z minimalnymi zmianami operacyjnymi użyj Dataproc; dopasuj rozmiar klastrów za pomocą autoskalowania.
Dla połączonych zadań wsadowych (batch) i strumieniowych bez istniejącego kodu użyj Dataflow z autoskalowaniem i okienkowaniem (windowing), aby zunifikować potoki danych.

Przenoszenie danych i łączność:

Dla stałej, prywatnej replikacji o wysokiej przepustowości (np. wieloterabajtowe bazy danych) rozważ Dedicated Interconnect; użyj załączników VLAN i Cloud Router do dynamicznego routingu. W przypadku zadań ad hoc lub niższej przepustowości wystarczy Cloud VPN.

Obciążenia stanowe:

W GKE używaj StatefulSets z woluminami trwałymi (regionalne dyski PD dla wysokiej dostępności) oraz uporządkowanymi, stabilnymi tożsamościami; rozważ Filestore dla semantyki NFS.
Używaj zarządzanych baz danych (Cloud SQL, AlloyDB, Spanner) dla zapewnienia trwałości i skalowalności tam, gdzie to możliwe; zaplanuj repliki do odczytu i przełączanie awaryjne (failover).

Bezpieczeństwo i zgodność:

Rozważ Confidential VMs, aby chronić dane w użyciu przy ograniczonym wpływie na wydajność; oceń to rozwiązanie pod kątem wymagań obciążenia.
Używaj CMEK, gdy klucze muszą być kontrolowane przez klienta; wymuszaj izolację dla każdego środowiska i oddzielne projekty dla dev/test/prod.

Kontrola kosztów:

Korzystaj z rabatów za zobowiązanie (committed use) i za stałe użycie (sustained use) dla zasobów obliczeniowych o stałym obciążeniu; instancje Preemptible/Spot dla zadań wsadowych odpornych na błędy; autoskalowanie do zera w usługach serverless.
Dopasuj rozmiar zasobów, korzystając z rekomendacji Monitoring; usuwaj nieaktywne usługi i ustawiaj limity dla metryk opartych na logach, aby uniknąć niespodziewanych kosztów.

Rozwiązywanie problemów z opóźnieniami:

Użyj Cloud Trace, aby zidentyfikować mikrousługę powodującą największe opóźnienia; zoptymalizuj ścieżkę kodu, buforowanie lub indeksy bazy danych tej usługi. Zweryfikuj ulepszenia za pomocą wdrożeń kanarkowych A/B.

Praktyczny scenariusz problemowy

Firma FerroLine Logistics planuje zmodernizować monolit J2EE, który obsługuje śledzenie przesyłek i powiadomienia dla klientów. Obciążenie jest niestabilne w okresach regionalnych terminów granicznych, musi spełniać cel dostępności na poziomie 99,9%, a zespół chce uzyskać przenośność przy minimalnym wysiłku operacyjnym, wprowadzając jednocześnie funkcje oparte na zdarzeniach.

Stabilizacja i obserwacja obecnego systemu

Uzasadnienie: Przed wprowadzeniem zmian należy ustalić bazowe zachowanie i błędy, aby zmniejszyć ryzyko konieczności wycofania zmian. Wdróż Ops Agent na istniejących maszynach wirtualnych, aby korzystać z Cloud Logging i Monitoring, oraz zaimplementuj śledzenie rozproszone na ścieżkach żądań o wysokich opóźnieniach. Eksportuj logi i metryki do BigQuery w celu analizy historycznej i raportowania SLO.

Wybór etapowej strefy docelowej i mieszanki platform

Uzasadnienie: Zrównoważenie kontroli i szybkości działania. Zmigruj monolit jako kontener do zadań Cloud Run dla komponentów wsadowych i usług Cloud Run dla bezstanowych interfejsów API HTTP, ustawiając minimalną liczbę instancji dla punktów końcowych wrażliwych na opóźnienia. Początkowo zachowaj stanową bazę danych Oracle na Compute Engine, z regionalnym wewnętrznym load balancerem HTTP(S) dla wewnętrznych API, i zaplanuj przyszłą migrację do AlloyDB.

Eksternalizacja stanu sesji i konfiguracji

Uzasadnienie: Uniknięcie problemów z sesjami lokalnymi dla instancji i umożliwienie bezpiecznego autoskalowania. Przechowuj sekrety w Secret Manager z kontami serwisowymi dla każdej usługi, aby zapewnić dostęp z najniższymi uprawnieniami. Przenieś stan sesji do Memorystore, a współdzielone pliki do Cloud Storage. Zapobiega to wyświetlaniu użytkownikom nieaktualnych danych podczas szczytowego obciążenia.

Ustanowienie kontroli tożsamości i rejestru

Uzasadnienie: Wymuszenie zasady najniższych uprawnień i śledzenia pochodzenia. Przechowuj obrazy w Artifact Registry z włączonym skanowaniem podatności. Przypisz unikalne konto serwisowe czasu wykonania do każdej usługi Cloud Run i obciążenia GKE (dla komponentów dekomponowanych w późniejszym etapie) i nadaj tylko wymagane role (np. Pub/Sub Publisher).

Implementacja CI/CD z bezpiecznymi strategiami wdrażania

Uzasadnienie: Zmniejszenie liczby nieplanowanych wycofań. Zbuduj potok, który uruchamia testy jednostkowe/integracyjne i wdraża na środowisko przejściowe (staging). Użyj podziału ruchu w Cloud Run, aby w ramach wdrożenia kanarkowego (canary) skierować 5–10% ruchu do nowych wersji i umożliwić szybkie wycofanie. W przypadku zmian w bazie danych na maszynach wirtualnych użyj wzorców migracji schematu blue-green, aby oddzielić wdrożenia aplikacji od wdrożeń bazy danych.

Dekompozycja w pierwszej kolejności domen o wysokiej zmienności

Uzasadnienie: Wartość przyrostowa przy niższym ryzyku. Zastosuj wzorzec dusiciela (strangler): wydziel dostarczanie powiadomień jako mikrousługę na GKE, aby wykorzystać HPA do obsługi skoków obciążenia i Pub/Sub do oddzielenia komponentów. Pozostałą część monolitu utrzymuj jako monolit modularny na Cloud Run, dopóki interfejsy się nie ustabilizują.

Projektowanie autoskalowania i odrzucania nadmiarowego obciążenia (load shedding)

Uzasadnienie: Obsługa nagłych wzrostów obciążenia bez awarii kaskadowych. Skonfiguruj współbieżność i minimalną liczbę instancji w Cloud Run dla każdego punktu końcowego; ustaw limity liczby żądań w Cloud Armor na globalnym load balancerze HTTP(S), aby chronić przed nagłymi wzrostami ruchu od nieuwierzytelnionych użytkowników. Dla usług GKE włącz HPA w oparciu o metryki niestandardowe (żądania na sekundę) i zapewnij mały bufor węzłów za pomocą autoskalera klastra.

Przygotowanie usług stanowych i ścieżek danych

Uzasadnienie: Zapewnienie trwałości i wydajności. Do ponawiania powiadomień w GKE użyj tabeli Bigtable z kluczem opartym na regionie klienta i przedziałach czasowych, aby przechowywać przejściowy stan dostarczenia przy wysokiej liczbie zapisów. Dla prywatnej, spójnej łączności z systemem ERP on-premise w okresie przejściowym użyj Dedicated Interconnect z Cloud Router.

← Projektowanie organizacji · Wszystkie domeny · Przechowywanie danych →

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