Zaprojektuj samonaprawiającą się strukturę obliczeniową, która autonomicznie ewakuje krytyczne obciążenia robocze z przemijających instancji chmurowych do alternatywnych stref dostępności i wtórnych dostawców chmurowych po otrzymaniu sygnałów o zakończeniu, jednocześnie zapewniając ciągłość usług bez przestojów i ścisłe przestrzeganie wymagań SLA dla opóźnień poniżej 100 ms.

Odpowiedź na pytanie.

Architektura koncentruje się na Płaszczyźnie Sterującej, która przechwytuje sygnały metadanych dostawcy chmury (np. AWS powiadomienia o przerwaniu instancji Spot, GCP ostrzeżenia o preempcji) i organizuje migrację obciążenia roboczego na żywo. Harmonogram utrzymuje mapę cieplną zdrowia instancji Spot w czasie rzeczywistym wraz z wstępnie podgrzanymi pulami zapasowymi w regionach Na Żądanie i wtórnych chmurach. Po otrzymaniu ostrzeżenia o zakończeniu system inicjuje spójne z aplikacją punktowanie kontrolne do rozproszonego magazynu (np. Ceph lub S3), jednocześnie uruchamiając zastępcze pody na zarezerwowanej pojemności. Sidecary w Sieci Usług (np. Istio) zajmują się płynnym przesuwaniem ruchu przy użyciu odwadniania połączeń i sygnałów HTTP/2 GOAWAY, aby zapobiec utracie żądań. Na koniec Globalny Load Balancer aktualizuje kontrole zdrowotne, aby skierować ruch tylko po pomyślnej weryfikacji zdrowia, zapewniając, że opóźnienie pozostaje poniżej progu 100 ms, wybierając priorytetowo geograficznie pobliskie strefy zapasowe.

Sytuacja z życia.

Firma zajmująca się handlem o wysokiej częstotliwości wykorzystywała AWS EC2 Instancje Spot dla swojego opartego na Kubernetesie silnika kalkulacji ryzyka w celu zmniejszenia kosztów obliczeń o 60%. Podczas szczytu zmienności rynkowej, AWS wydał masowe powiadomienia o zakończeniu instancji Spot w ich głównej strefie dostępności us-east-1. To groziło zlikwidowaniem 500 podów w ciągu dwóch minut podczas przetwarzania transakcji na żywo z rygorystycznymi wymaganiami opóźnienia 50 ms, ryzykując milionowe straty w transakcjach.

Rozwiązanie A: Natychmiastowe Budżety Zakłóceń Podów Kubernetes.

Zespół rozważał poleganie na standardowych Budżetach Zakłóceń Podów (PDB) w połączeniu z Autoscalerem Klastera, aby płynnie ewakuować pody na węzły na żądanie. To podejście oferowało prostotę i nie wymagało niestandardowego kodu. Jednak 120-sekundowy czas na zakończenie okazał się niewystarczający dla stanowych silników ryzyka, aby zserializować swoje złożone modele pochodnych w pamięci do trwałego magazynu, co skutkowało nieakceptowalną utratą danych i lukami w obliczeniach.

Rozwiązanie B: Niestandardowy Kontroler Węzła Preemptible z Velero.

Inną opcją było wdrożenie niestandardowego kontrolera, który wykorzystywał Velero do zrzutów wolumenów trwałych oraz Karpenter do szybkiej provisionowania węzłów. Chociaż Karpenter doskonale radził sobie z szybkim uruchamianiem węzłów (poniżej 30 sekund), cykl zrzutu i przywracania Velero dla 50 GB stanów pamięci średnio wynosił trzy minuty. To opóźnienie naruszało wymaganie zerowego przestoju i ryzykowało kaskadowe awarie, ponieważ kolejkowane transakcje gromadziły się ponad pojemność buforową systemu.

Rozwiązanie C: Punktowanie Kontrolne na Poziomie Aplikacji z Multi-Chmurą Zapasową.

Wybrane rozwiązanie wdrożyło punktowanie kontrolne świadome aplikacji wykorzystując CRIU (Checkpoint/Restore in Userspace) do zamrożenia i serializacji stanów procesów do klastrów Redis Persistent co 30 sekund. Architektura utrzymywała ciepły zapas w GCP Compute Engine z wykorzystaniem Anthos do federacji sieci serwisów między klastrami. Po otrzymaniu sygnału o zakończeniu od AWS, kontroler natychmiast uruchomił ostatnią synchronizację delta do Redis, uruchomił zastępcze pody w GCP przy użyciu wstępnie pobranych obrazów kontenerów i wykorzystał domyślne przełączanie ruchu Istio do przesunięcia ruchu. To podejście poświęciło nieco złożoności aplikacji, ale gwarantowało przełączenie w poniżej 60 sekund bez utraty danych.

Wynik.

Firma pomyślnie ewakuowała 98% obciążeń roboczych w ciągu 90 sekund podczas masowego zdarzenia zakończenia. Średnie opóźnienie przełączania wyniosło 45 ms, co było znacznie poniżej wymagań SLA, a system utrzymał 99,99% dostępności przez cały incydent. Po wdrożeniu analizy ujawniono 55% redukcję kosztów w porównaniu do czystego użytkowania na żądanie, co potwierdziło odporność strategii instancji Spot multi-chmury.

Co kandydaci często pomijają.

Jak zapobiegasz scenariuszom podziału mózgu, gdy sieć instancji Spot jest podzielona, ale sygnał o zakończeniu jest opóźniony lub zgubiony?

Kandydaci często zakładają, że 2-minutowe ostrzeżenie jest gwarantowane. W rzeczywistości podziały sieci mogą opóźnić dostarczenie sygnału. Rozwiązanie implementuje mechanizm Leasingu za pomocą etcd lub Consul, w którym obciążenia robocze trzymają czasowo ograniczone blokady. Jeśli płaszczyzna sterująca nie może odnowić leasingu z powodu podziału, oznacza węzeł jako podejrzany i przestaje kierować nowy ruch. Równocześnie, rekord Tombstone w rozproszonym dzienniku (np. Apache Kafka) zapewnia, że nawet jeśli izolowana instancja nadal przetwarza, jej wyniki są odrzucane jako nieaktualne po ponownym połączeniu, zapobiegając konfliktnym aktualizacjom stanu.

Jaka strategia zapewnia spójność danych podczas ostatecznej synchronizacji, gdy instancja może być wymuszona do zakończenia w trakcie punktowania kontrolnego?

Wielu proponuje proste punktowanie kontrolne, ale ignoruje problem "ostatniej mili" spójności. Poprawne podejście wykorzystuje semantykę Copy-on-Write (COW) i atomowe protokoły zatwierdzania. Przed ostateczną synchronizacją aplikacja wstrzymuje alokacje (poprzez pauzy GC lub haki aplikacji), tworzy zrzut pamięci za pomocą CRIU i zapisuje do S3 z S3 Silną Spójnością lub do Ceph przy użyciu atomowych transakcji RADOS. System wykorzystuje wzorzec Two-Phase Commit (2PC): przygotowanie punktu kontrolnego, potwierdzenie do płaszczyzny sterującej, a następnie odwadnianie połączeń. Jeśli zakończenie nastąpi w trakcie fazy zatwierdzania, instancja zapasowa wraca do poprzedniego spójnego punktu kontrolnego i odtwarza zdarzenia z dziennika przesunięcia Kafka.

Jak łagodzisz problemy skutków lawiny, gdy tysiące instancji Spot otrzymują jednoczesne powiadomienia o zakończeniu i rywalizują o ograniczoną pojemność zapasową?

Kandydaci często pomijają kontencję zasobów podczas masowych ewakuacji. Rozwiązanie implementuje algorytm Token Bucket na warstwie płaszczyzny sterującej, throttling migracje tak, aby odpowiadały poziomowi absorpcji puli zapasowej. Dodatkowo wykorzystuje Klasy Priorytetowe (PriorityClass w Kubernetes), aby zapewnić, że krytyczne obciążenia finansowe wyprzedzają mniej krytyczne zadania wsadowe na pojemności zapasowej. Mechanizm Backpressure sygnalizuje API Gateway, aby tymczasowo kolejkować nadchodzące żądania, zapobiegając natychmiastowemu przytłoczeniu nowych instancji skokami ruchu tuż po migracji. Wreszcie, predykcyjne modele uczenia maszynowego analizują historie cen Spot AWS, aby wstępnie skalować pojemność zapasową 15 minut przed przewidywanymi falami zakończenia, wygładzając krzywą przejścia.