Prześledź obciążenie od powstania danych do działania
Zespoły często zaczynają od preferowanej platformy, a użytecznym punktem wyjścia jest droga obciążenia: gdzie powstają dane, gdzie ma trafić wynik, ile danych trzeba przesłać, co dzieje się przy utracie połączenia i kto obsługuje system w każdym miejscu. Rozrysuj tę drogę dla reprezentatywnego żądania, zaznacz transfery, magazyny, granice tożsamości, przekształcenia, wywołania modelu, akceptacje i końcowe działania. Dopiero wtedy można porównać lokalizacje wdrożenia.
Mierz opóźnienie na całej trasie. Przejście przez sieć, serializacja, kolejki, ładowanie danych, inferencja, logika aplikacji, autoryzacja i dostarczenie wyniku składają się na czas odpowiedzi. Szybki model nie rekompensuje wolnej lub zawodnej reszty ścieżki. Ten sam schemat ujawnia przepływ danych wpływający na przepustowość, koszt, retencję, prywatność i ład zarządczy. Model NIST Fog Computing opisuje przetwarzanie blisko urządzeń IoT, lecz sama bliskość nie rozstrzyga projektu: nadal potrzebne są pojemność, integracja, monitoring, aktualizacje i zdefiniowany tryb awarii.
Każdy model wdrożenia inaczej rozmieszcza pracę i odpowiedzialność
Edge wykonuje obliczenia blisko źródła danych lub procesu fizycznego. Ogranicza transfer i może podtrzymać funkcję w trakcie awarii szerszej sieci, ale sprzęt ma ograniczenia zasilania, chłodzenia, pamięci, magazynu i akceleratorów, a flota urządzeń wymaga dystrybucji oprogramowania, konfiguracji, kontroli stanu, poświadczeń, logów i wersji.
Wdrożenie lokalne obsługuje szersze obciążenia w infrastrukturze klienta, np. aplikacje, współdzielone zasoby, akceleratory, wewnętrzne systemy tożsamości i dane. Daje kontrolę nad pojemnością i terminami zmian, lecz przenosi odpowiedzialność za obiekt, cykl życia sprzętu, systemy operacyjne, sterowniki, bezpieczeństwo, kopie zapasowe, monitoring i odtwarzanie. Chmura oferuje zarządzane zasoby i skalowanie, ale nadal wymaga zaprojektowania transferu danych, regionów, limitów usług, tożsamości, konfiguracji, zależności dostępności i ścieżek wyjścia. Model hybrydowy rozdziela elementy między lokalizacje tylko wtedy, gdy podział ma jasne uzasadnienie i właścicieli.
Średnie zapotrzebowanie ukrywa trudną część obciążenia
Dobieraj architekturę do reprezentatywnego obciążenia, także do szczytów. Zapisz rozmiar modelu i wejścia, tempo żądań, współbieżność, zachowanie wsadów, użycie pamięci i akceleratorów, wzrost magazynu oraz przetwarzanie przed i po inferencji. Żądania interaktywne, ciągłe wideo, zaplanowany trening, duże dokumenty i analizy laboratoryjne bardzo różnie obciążają ten sam nominalny sprzęt.
Współbieżność często zmienia odpowiedź: pojedyncze żądanie może działać dobrze, a kilka równoczesnych wyczerpać pamięć lub utworzyć zbyt długą kolejkę. Testuj zimne starty, ładowanie modeli, cache, pracę ciągłą i konkurujące zadania. Skalowanie również ma formę operacyjną: chmura wymaga gotowości aplikacji, limitów, budżetów i systemów zależnych, lokalny sprzęt wymaga zakupu oraz walidacji, a edge może oznaczać zmianę wielu urządzeń. Porównuj pełny koszt działania, w tym sprzęt, wsparcie, energię, chłodzenie, łącza, transfery, licencje, czas zespołu, zapas i odtwarzanie.
Bezpieczeństwo wynika z tożsamości, kontroli i odpowiedzialności
Serwer w budynku nie jest bezpieczny wyłącznie z powodu adresu. Architektura Zero Trust NIST wskazuje, że zaufania nie przyznaje się tylko na podstawie lokalizacji fizycznej lub sieciowej. Systemy lokalne nadal potrzebują kontroli tożsamości, autoryzacji, segmentacji, poprawek, zarządzania sekretami, logowania, reakcji na incydenty, ochrony fizycznej i przetestowanego odtwarzania.
Chmura również zostawia klientowi znaczną część obowiązków. Modele współdzielonej odpowiedzialności AWS i Microsoft pokazują, że klient nadal odpowiada za dane, tożsamości, decyzje dostępowe i konfigurację. Sporządź macierz właścicieli dla sprzętu, firmware, systemów, sterowników, kontenerów, artefaktów modelu, kodu, danych, reguł sieciowych, kopii, monitoringu, incydentów i relacji z dostawcami. Funkcje NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond i Recover obowiązują niezależnie od miejsca wdrożenia.
Wybierz zachowanie przy awarii przed wyborem platformy
Utrata łączności jest stanem operacyjnym, nie przypadkiem brzegowym. Ustal, czy funkcja pracuje lokalnie, buforuje zadania, zwraca widoczny stan ograniczony, przechodzi na pracę ręczną czy bezpiecznie się zatrzymuje. Określ użyteczność zakolejkowanych danych, obsługę duplikatów po ponownym połączeniu i możliwość odtworzenia. Tak samo rozważ utratę węzła, pełny dysk, wygasły certyfikat, niedostępną usługę tożsamości, błąd ładowania modelu, uszkodzone urządzenie edge, aktualizację lub niezgodność zależności.
Projektuj również ścieżkę aktualizacji oprogramowania, modeli, polityk i konfiguracji między środowiskami, z akceptacją, wycofaniem, kontrolami zgodności i dowodem użytej wersji. Framework Google Cloud Well-Architected łączy operacje, bezpieczeństwo, niezawodność, koszt i wydajność także w rozwiązaniach hybrydowych. Lokalizacja wdrożenia po uruchomieniu nigdy nie pozostaje wyłącznie decyzją techniczną.
Reprezentatywny test powinien obciążyć wybraną granicę
Porównuj kandydatów na rzeczywistej aplikacji: z planowanym modelem, wejściami, wolumenami danych, współbieżnością, integracjami, tożsamością, logami i magazynem. Test powinien trwać dość długo, aby ujawnić temperaturę, wzrost pamięci, kolejki, zadania okresowe, wahania sieci i utrzymanie. Mierz czas odpowiedzi na granicy użytkownika lub procesu, przepustowość, zasoby, wzrost kolejki, awarie, czas odtwarzania, ruch danych i wysiłek operacyjny.
W test włącz osoby utrzymujące usługę. Powinny wdrożyć wersję, sprawdzić alert, odtworzyć kopię, zmienić poświadczenie, zbadać błąd i odzyskać pracę po przerwanym połączeniu. Jeśli takie zadania wymagają stałej obecności zespołu projektowego, model operacyjny jest niepełny.
Lokalne obliczenia naukowe pokazują połączenie ładu i lokalizacji
W przypadku Gaiaa badacze potrzebowali Pythona, notebooków, uczenia maszynowego i GPU dla poufnych pomiarów pozostających w lokalnej infrastrukturze. Projekt zapisywał użytkownika, projekt, zatwierdzone wejścia, wersję kodu i środowiska oraz limity zasobów dla każdego żądania, a izolowane procesy wykonywały pracę lokalnie.
Wyniki były niezmienne i walidowane przed publikacją jako odrębne rekordy analiz. Lokalizacja spełniała granicę danych, ale niezawodność dawały tożsamość zadania, izolacja, wersjonowanie, walidacja, kontrola zasobów i właścicielstwo. To nie dowodzi, że infrastruktura lokalna jest domyślnym wyborem, tylko pokazuje konsekwencje wymogu pozostawienia danych na miejscu.
Zakończ decyzją architektoniczną, którą można utrzymać
Końcowy wybór zapisz w formie możliwej do sprawdzenia: granica danych, miejsce decyzji, wymagania czasowe, profil obciążenia, współbieżność, założenia łączności, integracje, kontrole bezpieczeństwa, zachowanie przy awarii, ścieżka aktualizacji, odtwarzanie oraz właściciel każdej warstwy. Zapisz również odrzucone warianty i powody.
Wróć do decyzji, gdy zmienią się obciążenie, klasyfikacja danych, limity usług, rozmiar modelu, liczba użytkowników lub zespół operacyjny. Wybieraj infrastrukturę dopiero po zapisaniu obciążenia, granicy danych, czasu, integracji, awarii i właścicielstwa. Gaiaa może zbudować i przetestować ścieżki edge, lokalne, chmurowe lub hybrydowe na reprezentatywnej pracy i z modelem wsparcia po uruchomieniu.