Pytania rekrutacyjne Systemy rozproszone

Czym jest system rozproszony i czym różni się od architektury klient-serwer?

System rozproszony to aplikacja złożona z wielu współpracujących ze sobą komponentów uruchomionych na różnych maszynach, komunikujących się przez sieć. Może to być wiele różnych aplikacji albo wiele replik tej samej aplikacji, które razem realizują jedną logiczną usługę (np. wyszukiwarkę czy platformę sprzedażową).

W klasycznej architekturze klient-serwer podział jest prosty: klient wysyła żądania, a serwer je obsługuje. System rozproszony idzie dalej — sama "strona serwerowa" składa się z wielu współpracujących procesów rozsianych po różnych maszynach.

Główne różnice:

• Niezawodność — odpowiednio zaprojektowany system rozproszony jest z natury bardziej odporny na awarie, bo brak pojedynczego punktu, którego awaria kładzie całość.
• Skalowalność — można skalować niezależnie poszczególne komponenty zamiast całej aplikacji.
• Złożoność — w zamian za te zalety płacimy znacznie wyższym kosztem projektowania, budowy i debugowania. Wymagania inżynierskie są wyraźnie wyższe niż przy aplikacjach jednomaszynowych.

Jakie korzyści daje stosowanie wzorców projektowych przy budowie systemów rozproszonych?

Wzorzec to ogólny plan organizacji systemu, niezależny od konkretnej technologii czy aplikacji — w przeciwieństwie do przepisu na instalację konkretnej bazy NoSQL czy stosu technologicznego. Korzyści są trzy:

• Uczenie się na cudzych błędach — wzorce kodyfikują rozwiązania, do których inni doszli poprzez kosztowne pomyłki. Nie musisz mieć osobistego doświadczenia z danym typem systemu, by zbudować go solidnie.
• Wspólny język — gdy obie strony rozmowy wiedzą, czym jest "sidecar", nie tracą czasu na ustalanie nazewnictwa i mogą od razu dyskutować o szczegółach rozwiązania.
• Reużywalne komponenty — zidentyfikowanie powtarzalnych wzorców pozwala zaimplementować je raz (np. jako obraz kontenera z interfejsem HTTP) i wielokrotnie używać w różnych językach i kontekstach, co dodatkowo podnosi jakość, bo wspólny kod jest intensywnie testowany.

Jaką rolę pełnią kontenery i orkiestratory w budowie systemów rozproszonych?

Kontenery odegrały dla systemów rozproszonych podobną rolę, jaką obiekty odegrały dla programowania — stały się podstawowym, reużywalnym budulcem. Kontener wyznacza granice wokół zasobów (np. dwa rdzenie i 8 GB pamięci), wokół własności zespołu oraz wokół odpowiedzialności (jeden kontener robi jedną rzecz).

Orkiestrator kontenerów (np. tego typu jak Kubernetes) dostarcza obiekt i interfejs do wyrażania wzorców rozproszonych oraz przejmuje odpowiedzialność za niezawodne uruchamianie:

• automatycznie restartuje kontener po awarii lub zawieszeniu (jeśli skonfigurowano health check),
• przenosi kontener na inną maszynę przy awarii sprzętu,
• skaluje liczbę replik w odpowiedzi na obciążenie.

Dzięki temu wiele wzorców można zaimplementować jako współpracujące kontenery, nie pisząc od zera infrastruktury niezawodności.

Czym różni się architektura mikroserwisowa od monolitycznej i jakie są jej kompromisy?

Monolit umieszcza całą funkcjonalność usługi w jednej, ściśle skoordynowanej aplikacji. Mikroserwisy dzielą system na wiele komponentów działających w osobnych procesach i komunikujących się przez zdefiniowane API.

Formalne API między serwisami pełni rolę stabilnego kontraktu, który odprzęga zespoły: dostawca wie, jaką powierzchnię musi utrzymać, a konsument może polegać na usłudze bez znajomości jej wnętrza.

flowchart LR
    subgraph Monolit
        M["Jeden proces<br/>UI + logika + dostęp do danych"]
    end
    subgraph Mikroserwisy
        A["Serwis A"] -->|API| B["Serwis B"]
        A -->|API| C["Serwis C"]
        B -->|API| D["Serwis D"]
    end

Co to jest grupa kontenerów (pod) i po co dzielić aplikację jednowęzłową na kilka kontenerów?

Grupa kontenerów (w Kubernetes nazywana podem) to zbiór kontenerów współplanowanych na jednej maszynie, które mogą dzielić wolumeny, część systemu plików, przestrzeń sieciową czy pamięć współdzieloną. Kontenery w takiej grupie są ściśle powiązane i zawsze trafiają na ten sam węzeł.

Powody dzielenia nawet pojedynczej aplikacji na kilka kontenerów:

• Izolacja zasobów — usłudze front-end nadasz wysoki priorytet i gwarantowane zasoby, a komponentowi działającemu w tle (np. ładowanie konfiguracji) niski; w razie wycieku pamięci to kontener tła zostanie ubity jako pierwszy.
• Reużywalność i skala zespołu — dobrze wyodrębniony moduł (np. synchronizacja katalogu z repozytorium Git) może być współdzielony przez wiele aplikacji w różnych językach i utrzymywany przez mały, dedykowany zespół.
• Separacja odpowiedzialności — małe, skupione komponenty łatwiej zrozumieć, testować i wdrażać niezależnie, co daje wdrożenia o mniejszym zasięgu i bezpieczniejsze wycofania zmian.

Jakie są główne wady architektury mikroserwisowej?

Mimo zalet w obszarze niezawodności i zwinności, mikroserwisy mają dwie zasadnicze wady:

• Trudniejsze debugowanie — nie da się po prostu wczytać jednej aplikacji do debuggera. Błędy są wypadkową wielu systemów działających na różnych maszynach, a takie środowisko jest trudne do odtworzenia.
• Trudniejsze projektowanie — system korzysta z wielu metod komunikacji (synchronicznej, asynchronicznej, opartej na komunikatach) oraz różnych wzorców koordynacji i sterowania.

Dlatego właśnie wzorce są tak cenne: jeśli architektura mikroserwisowa składa się ze znanych wzorców, łatwiej ją projektować (część decyzji narzucają wzorce) i debugować (można przenosić wnioski między systemami stosującymi te same wzorce).

Na czym polega wzorzec sidecar?

Sidecar to wzorzec jednowęzłowy złożony z dwóch kontenerów współplanowanych w jednej grupie. Pierwszy to kontener aplikacji zawierający główną logikę. Drugi to kontener sidecar, którego rolą jest rozszerzanie i ulepszanie kontenera aplikacji — często bez jego wiedzy.

Oba kontenery dzielą szereg zasobów: część systemu plików, nazwę hosta i sieć, a także inne przestrzenie nazw. Dzięki temu sidecar może np. nasłuchiwać na tym samym localhost, na którym serwuje aplikacja.

Klasyczny przykład: starsza usługa serwuje wyłącznie nieszyfrowany HTTP na localhost, a dołożony sidecar (np. serwer proxy) terminuje HTTPS na zewnętrznym adresie i przekazuje ruch lokalnie do aplikacji. W ten sposób modernizujemy usługę bez przebudowy jej kodu.

flowchart LR
    U["Ruch z zewnątrz"] -->|HTTPS| S
    subgraph Pod["Grupa kontenerów (pod)"]
        direction LR
        S["Sidecar<br/>terminacja HTTPS"] -->|HTTP po localhost| App["Kontener aplikacji"]
    end

Podaj przykłady zastosowania wzorca sidecar.

Sidecar nie służy tylko do adaptacji starszych aplikacji. Typowe zastosowania:

• Dodanie HTTPS do starszej usługi — sidecar terminuje szyfrowanie i proxuje ruch do aplikacji nasłuchującej lokalnie na nieszyfrowanym porcie.
• Dynamiczna konfiguracja — kontener menedżera konfiguracji pobiera zmiany przez API, zapisuje je w dzielonym katalogu i sygnalizuje aplikacji konieczność przeładowania (np. przez sygnał czy nadpisanie pliku).
• Modularne narzędzia introspekcji — kontener typu "top" współdzielący przestrzeń PID może raportować zużycie zasobów wszystkich procesów aplikacji przez spójny interfejs, dołączany automatycznie do wszystkich wdrożeń.
• Prosta platforma PaaS — sidecar synchronizujący kod z repozytorium Git w pętli, połączony z serwerem auto-przeładowującym aplikację, daje wdrożenie "push to deploy".

Kluczowa zaleta: sidecar jest modularny i reużywalny, więc raz zbudowany przyspiesza tworzenie wielu różnych aplikacji.

Na czym polega parametryzacja kontenerów i dlaczego jest ważna dla reużywalności?

Parametryzacja to potraktowanie kontenera jak funkcji w programie: każdy parametr to wejście, które dostosowuje generyczny kontener do konkretnej sytuacji. Bez parametrów sidecar terminujący SSL byłby bezużyteczny — potrzebuje przynajmniej nazwy certyfikatu i portu aplikacji, do której proxuje.

Parametry przekazuje się zwykle przez zmienne środowiskowe lub przez wiersz poleceń. Wewnątrz kontenera prosty skrypt startowy czyta te zmienne i dostosowuje pliki konfiguracyjne lub samą aplikację.

Parametryzacja jest najważniejszą rzeczą, jaką można zrobić, by kontener stał się modularny i reużywalny w wielu aplikacjach. Bez niej każdy nowy przypadek użycia wymagałby budowy osobnego, dedykowanego obrazu.

Co składa się na API kontenera i dlaczego pozornie drobna zmiana parametru może być "breaking change"?

API kontenera to wszystkie aspekty tego, jak kontener wchodzi w interakcję ze światem: parametry wejściowe, wywołania, jakie wykonuje do innych usług, oraz interfejsy (np. HTTP), które sam udostępnia. Czysto zdefiniowane API zapewnia separację między aplikacją a sidecarem i gwarantuje, że kolejne wersje nie zepsują istniejących konsumentów.

Zmiany łamiące API nie zawsze są oczywiste. Rozważ parametr UPDATE_FREQUENCY:

• zmiana nazwy na UPDATE_PERIOD — oczywiste złamanie,
• zmiana z liczby sekund na format tekstowy typu 10m/5s — stare wartości (10) przestaną się parsować,
• sprytna próba: wartości bez jednostki parsowane jako milisekundy zamiast sekund — brak błędu, ale ta sama liczba oznacza teraz tysiąckrotnie częstsze odpytywanie, co przeciąża serwer konfiguracji.

Wniosek: prawdziwa modularność wymaga świadomości, że zmiana semantyki — nie tylko nazwy — bywa zmianą łamiącą.

Na czym polega wzorzec ambassador i czym różni się od sidecar?

Ambassador to wzorzec jednowęzłowy, w którym kontener-ambasador pośredniczy w interakcjach między aplikacją a światem zewnętrznym. Aplikacja łączy się "lokalnie" z ambasadorem, a ten przejmuje całą logikę komunikacji na zewnątrz.

Różnica względem sidecar: sidecar rozszerza i ulepsza kontener aplikacji (dodaje mu funkcję), natomiast ambassador brokeruje i modyfikuje sposób, w jaki aplikacja komunikuje się ze światem (np. trasuje żądania, dzieli ruch, znajduje właściwą usługę).

Wartość wzorca jest dwojaka: separacja odpowiedzialności (kontenery łatwiej budować i utrzymywać) oraz reużywalność — ten sam ambasador działa z wieloma różnymi aplikacjami, a jego implementacja jest spójniejsza i wyższej jakości, bo powstaje raz i jest używana wielokrotnie.

Jak wzorzec ambassador pomaga w komunikacji z usługą shardowaną?

Gdy dane nie mieszczą się na jednej maszynie, dzielimy warstwę przechowywania na shardy. Problem: retrofit logiki trasującej do istniejącego kodu klienta, który spodziewa się jednego backendu, jest trudny; dochodzą też różnice między środowiskiem deweloperskim (jeden shard) a produkcją (wiele shardów).

Ambassador rozwiązuje to elegancko: aplikacja łączy się z tym, co wygląda jak pojedynczy backend na localhost, a w rzeczywistości jest to proxy-ambasador, który zawiera całą logikę routingu do właściwego sharda, wysyła żądanie i zwraca wynik. Aplikacja "wie" tylko, że rozmawia z usługą składowania.

Alternatywą jest wbudowanie routingu w samą usługę shardowaną (rozproszony load balancer jako usługa). Kompromis: ambasador po stronie klienta upraszcza wdrożenie usługi kosztem bardziej złożonego wdrożenia klienta — i odwrotnie. Wybór zależy m.in. od przebiegu granic między zespołami.

Czym jest service discovery i jak ambassador wspiera przenośność aplikacji?

Przy przenoszeniu aplikacji między środowiskami (chmura publiczna, prywatna, własny datacenter) wyzwaniem jest odnajdywanie i konfiguracja usług. Ta sama baza (np. MySQL) raz jest dostępna jako usługa SaaS, a innym razem trzeba dynamicznie uruchomić dla niej maszynę czy kontener.

Proces odnajdywania właściwej usługi nazywamy service discovery, a komponent, który to realizuje — service brokerem. Ambassador pozwala oddzielić logikę aplikacji od logiki brokera: aplikacja zawsze łączy się z instancją usługi na localhost, a to ambasador-broker bada środowisko i ustanawia właściwe połączenie.

Dzięki temu ten sam obraz aplikacji jest przenośny — to ambasador, a nie kod aplikacji, ponosi koszt różnic między środowiskami.

Jak zrealizować eksperymenty (np. 10% ruchu) lub request splitting?

Request splitting polega na kierowaniu części ruchu do innej implementacji usługi. Najczęstsze zastosowania:

• Eksperymenty — np. 10% żądań trafia do nowej, beta wersji usługi, by sprawdzić jej niezawodność i wydajność względem produkcji.
• Tee/duplikacja — całość ruchu trafia jednocześnie na produkcję i na nową wersję, ale użytkownik dostaje wyłącznie odpowiedź produkcyjną; odpowiedzi z wersji testowej są ignorowane. Pozwala to symulować obciążenie produkcyjne bez ryzyka dla użytkowników.

Realizuje to ambassador: aplikacja łączy się z usługą lokalnie, a ambasador proxuje żądania do obu systemów i zwraca odpowiedź produkcyjną. Ważny szczegół: warto użyć trwałego przypisania użytkownika (np. po haszu IP), by ten sam użytkownik nie "przeskakiwał" między wersjami i miał spójne doświadczenie.

Alternatywnie można wdrożyć eksperymenty jako osobny mikroserwis przed aplikacją — sensowne, jeśli to stały element architektury; ambasador po stronie klienta lepiej pasuje do użycia okazjonalnego.

Na czym polega wzorzec adapter i do czego służy?

Adapter to trzeci wzorzec jednowęzłowy. Kontener-adapter modyfikuje interfejs kontenera aplikacji tak, by pasował do z góry ustalonego, jednolitego interfejsu oczekiwanego od wszystkich aplikacji.

Problem, który rozwiązuje: rzeczywiste aplikacje są heterogeniczne — część piszesz sam, część dostarcza vendor, część to gotowe oprogramowanie open source. Każdy komponent loguje i raportuje metryki inaczej. Aby skutecznie operować systemem, potrzebujesz jednolitych interfejsów.

W tym wzorcu różne kontenery aplikacji mogą udostępniać różne interfejsy, a kontener-adapter sprowadza tę różnorodność do jednego spójnego interfejsu. Dzięki temu wdrażasz jedno narzędzie (np. do monitoringu), które oczekuje jednego, dobrze zdefiniowanego interfejsu.

Dlaczego warto użyć adaptera zamiast po prostu zmodyfikować kontener aplikacji?

Jeśli jesteś właścicielem kodu aplikacji, modyfikacja może być sensowna. Problem pojawia się, gdy używasz kontenera dostarczonego przez kogoś innego.

• Koszt utrzymania — tworzenie własnego, lekko zmodyfikowanego obrazu oznacza wieczne łatanie i rebase'owanie przy każdej nowej wersji oryginału. Adapter działający obok cudzego obrazu jest znacznie tańszy w utrzymaniu.
• Współdzielenie i reużywalność — adapter wyodrębniony do osobnego kontenera można dzielić między wiele aplikacji; modyfikacja kontenera aplikacji takiej możliwości nie daje.
• Izolacja zasobów — osobny kontener adaptera ma własne CPU i pamięć, więc np. źle zachowujący się adapter monitoringu nie zaszkodzi usłudze obsługującej użytkowników.

Wniosek: adapter zamienia heterogeniczny świat aplikacji w jednorodny świat wspólnych interfejsów, jednocześnie umożliwiając dzielenie się rozwiązaniami w społeczności.

Jak adapter pomaga ujednolicić monitoring i logowanie heterogenicznych usług?

Systemy monitoringu chcą automatycznie wykrywać i monitorować każdą wdrożoną aplikację, co wymaga, by wszystkie udostępniały ten sam interfejs metryk. W praktyce interfejsy bywają różne (syslog, JMX, ETW i wiele innych), różniące się protokołem i stylem (push vs pull).

• Monitoring — adapter przekształca interfejs metryk aplikacji do formatu oczekiwanego przez agregator. Np. usługa, która nie eksportuje metryk we właściwym formacie, zyskuje kontener-eksporter, który tłumaczy je na oczekiwany interfejs. Aktualizacja aplikacji nie wymaga wtedy aktualizacji adaptera monitoringu i odwrotnie.
• Logowanie — aplikacje logują różnie (różne poziomy, różne pliki, stdout/stderr, różne formaty znaczników czasu). Adapter przekierowuje logi do stdout i normalizuje je do jednej, ustrukturyzowanej reprezentacji, którą rozumie agregator logów.
• Health checks — adapter może udostępniać bogate sprawdzenia zdrowia (np. wykonując zapytanie testowe do bazy) przez standardowy interfejs HTTP, bez modyfikowania obrazu bazy.

Czym jest usługa bezstanowa i dlaczego replikujemy ją za load balancerem?

Usługa bezstanowa (stateless) to taka, która do poprawnego działania nie wymaga zapisanego stanu między żądaniami. W najprostszej postaci nawet pojedyncze żądania tego samego użytkownika mogą trafiać do różnych instancji. Przykłady to serwery treści statycznych czy warstwy pośredniczące agregujące odpowiedzi z wielu backendów.

Najprostszy wzorzec rozproszony to usługa replikowana za load balancerem: skalowalna liczba identycznych serwerów, z których każdy może obsłużyć każde żądanie, a przed nimi load balancer (round-robin lub z przypisaniem sesji).

Replikacja daje dwie rzeczy: redundancję (awaria jednej repliki nie kładzie usługi) oraz skalowanie poziome (więcej użytkowników obsługujemy, dodając repliki).

Dlaczego nawet mała usługa potrzebuje co najmniej dwóch replik?

Chodzi o dotrzymanie SLA dostępności. Usługa "trzech dziewiątek" (99,9%) dopuszcza około 1,4 minuty niedostępności dziennie.

Z jedną instancją oznacza to, że nawet jeśli aplikacja nigdy się nie zawiesza, każde wdrożenie nowej wersji musisz zmieścić w 1,4 minuty na dobę. A jeśli wdrażasz częściej — np. co godzinę w modelu continuous delivery — musiałbyś wdrożyć w ~3,6 sekundy, by nie przekroczyć budżetu niedostępności.

Zamiast tej heroicznej walki wystarczą dwie repliki za load balancerem. Podczas wdrożenia (albo w razie awarii jednej repliki) użytkowników obsługuje druga replika i nikt nie zauważy, że coś się działo. Dlatego dwie repliki to praktyczne minimum dla usługi o wysokiej dostępności.

Czym różni się readiness probe od health/liveness probe?

To dwa różne sygnały dla orkiestratora i load balancera:

Rozróżnienie ma sens, bo wiele aplikacji żyje, ale nie jest jeszcze gotowa — potrzebuje czasu na inicjalizację: połączenie z bazą, załadowanie wtyczek czy pobranie plików z sieci. Taki kontener nie powinien być restartowany (żyje), ale też nie powinien dostawać ruchu (nie jest gotów). Projektując usługę replikowaną, warto udostępnić osobny URL realizujący sprawdzenie gotowości.