Dwa kierunki ruchu, jedna skrzynka
Witamy
Większość diagramów architektonicznych pokazuje ruch jednym kierunkiem: klient na górze, serwer na dole, strzałka w dół. Rzeczywistość ma ruch w obu kierunkach.
Wewnętrzny: zewnętrzni klienci docierają do Twoich usług tymi drogami. Odwrócony proxy na krawędzi Twojej sieci kończy TLS, kieruje żądania i narzucza politykę dostępu.
Zewnętrzny: Twoje usługi docierają do zewnętrznych usług tymi drogami. Wywołanie API procesora płatności, pobranie celu webhooka, wysyłanie żądania do partnera. Często przez proxy przekierowujący lub bramkę NAT z allowlist.
Wiele architektur zaczyna się od jednej skrzynki obsługującej obie. Działa, aż do dnia, w którym tego nie robi. Modus zawodzenia jest subtelny, pojawia się tylko po wystarczającym czasie istnienia wewnętrznych usług i nauczania ważnego nauki separacji zainteresowań.
Po zakończeniu tego lekcji zrozumiesz:
- Dlaczego wewnętrzny i zewnętrzny reprezentują ostatecznie różne schematy ruchu z różnymi osiami skalowania i różnymi modami zawodzenia
- Hairpin NAT i dlaczego proxy, który próbuje połączyć się z sobą niepowoduje
- Architektoniczny wśczep: jedna skrzynka staje się dwiema, a co każda z nich posiada wyłącznie
- Zyski izolacji bezpieczeństwa: każda strona może zablokować się do swoich rzeczywistych dopuszczonych partnerów
- Jak zidentyfikować, gdy projekt jednolitej skrzynki przekroczy próg, w którym podział jest konieczny
Dlaczego kierunki wymagają różnych narzędzi
Dwa różne obciążenia na jednej granicy sieci
Charakterystyki ruchu wewnętrznego:
- Inicjowany przez strony z zewnątrz (internet na ogół)
- Objętość wzrasta wraz z bazą użytkowników
- Zakończenie TLS, routowanie żądań, ograniczanie szybkości na źródło
- Związane z bezpieczeństwem: DDoS, nadużycia, skraplanie
- Publiczny IP musi akceptować połączenia od każdej strony
Charakterystyki ruchu zewnętrznego:
- Inicjowany przez własne usługi (znanego, ograniczonego zestawu klientów)
- Objętość wzrasta wraz z wzrostem wzajemnych usług i wywoływaniem API
- Ustalenia IP źródłowego na urządzeniach końcowych (masz jedno stałe IP wyjściowe, na które partnerzy się zgodzili)
- Kwestie związane z głębokim zabezpieczeniem: wydostawanie danych, usługi wewnętrzne kompromitowane, które wywołują wyjście
- Powinien odrzucać połączenia od osób poza własnymi usługami
Kluczowa asymetria: przychodzące akceptują ruch od świata; wyjście akceptuje ruch tylko od własnych usług. Umieszczenie ich na tej samej maszynie oznacza, że ta maszyna musi być jednocześnie dostępna z poziomu świata (dla przychodzących) & być dostępna tylko od własnych usług (dla wyjścia). Reguły zapory, które spełniają jedne, działają przeciwko drugim.
Ścieżka wzrostu: małe przedsięwzięcie może ukryć oba za jednym IP & jednym narzędziem, ponieważ objętość jest mała & allowlist IP partnerów jest krótka. W miarę jak projekt rośnie, napięcie między dwoma rolami wzrasta & kiedyś jedno konkretnie (hairpin NAT) zmusza do podziału.
The Bug That Forces the Split
Historia Wyłączenia Zsanitowanego
Obrazuj architektoniczny rozgałęzienie, które występuje w flotach produkcyjnych. Nazwiska poniżej zostały zmienione; kształt jest identyczny z tym, który zespoły napotykają w dziko.
Organizacja uruchamia pojedynczy serwer proxy na 203.0.113.5. Obsługuje przychodzące (port 443 dla użytkowników) & wyjście (port 1080 SOCKS5 dla usług wewnętrznych wywołujących wyjście). Usługi wewnętrzne znajdują się w prywatnych podsieciach & kierują wszystki ruch wyjściowy przez ten SOCKS5 proxy na 203.0.113.5:1080.
Jedna z usług hostowanych za tą samą 203.0.113.5 to api.example.com. Publiczny DNS rozwiązuje api.example.com do 203.0.113.5.
Teraz różne wewnętrzne usługi potrzebują wywołania api.example.com. Jego ścieżka wyjściowa:
1. Wewnętrzna usługa rozwiązuje api.example.com → 203.0.113.5
2. Wewnętrzna usługa wysyła żądanie przez SOCKS5 proxy egress na 203.0.113.5:1080
3. Proxy próbuje otworzyć połączenie od siebie do 203.0.113.5:443
4. Odrzucone połączenie. Pakiet musiałby wyjść & ponownie wejść w ten sam NAT, co większość stosów sieciowych odrzuca. Proxy nie może połączyć się ze sobą za pomocą własnego IP publicznego.
To jest NAT włoskowaty: pakiet, który wyjdzie z NAT i musi ponownie wejść do tego samego NAT, aby osiągnąć swoją cel. Bez specjalnego wsparcia włoskowania w warstwie routingu, pakiet upada.
Dlaczego pojawia się późno
Na początku życia projektu każde wewnętrzne usługi rozmawiały z innymi usługami wewnętrznymi za pomocą prywatnego hosta (internal-api.local) lub nie wywoływały usług publicznych swojej organizacji. Scenariusz włoskowania po prostu nie istniał.
Następnie nowa funkcja wymagała, aby usługa A zwróciła się do api.example.com (publiczny host). Scenariusz włoskowania aktywował się. Odrzucona połączenie. Wyłączenie.
Naprawa usunęła objaw (przymusiła rozwiązywacz do podania prywatnego IP api.example.com zamiast publicznego). Prawdziwa przyczyna: jeden serwer robił zbyt wiele rzeczy.
Architektoniczne rozwidlenie
Jedna skrzynka staje się dwie
Oczyszczająca naprawa: rozdziel proxy na dwie maszyny.
Serwer przychodzący (publiczny IP 203.0.113.5):
- Caddy / odwrotny proxy na portach 80, 443
- Zapisy DNS wskazują tutaj
- Gospodaruje api.example.com, app.example.com, itp.
Serwer wyjściowy (inny publiczny IP 203.0.113.99):
- SOCKS5 / forward proxy na porcie 1080
- Filtr błędów ogranicza połączenia przychodzące tylko do IP podstawowych sieci wewnętrznych
- Wewnętrzne usługi kierują wszystkie wyjściowe przez tę adres
Co to daje:
1. Rozwiązanie włoskowania. Wewnętrzna usługa, która zwraca się do api.example.com, kieruje wyjściowo przez 203.0.113.99 (wyjściowy), który następnie łączy się normalnie z 203.0.113.5 (przychodzący, inny IP). Pętla NAT znika, ponieważ dwa IP adresy znajdują się na różnych maszynach.
2. Izolacja bezpieczeństwa. Serwer wyjściowy może zablokować ogniodem do małego zestawu IP wewnętrznych. Serwer przychodzący pozostaje otwarty na świat. Dwa osobne zestawy reguł, każdy wyrażający jedno role czysto.
3. Niezależne skalowanie. Pasmo przychodzące skaluje się z użytkownikami; pasmo wyjściowe skaluje się z działalnością usług wewnętrznych. Zaktualizuj jedno bez dotykania drugiego.
4. Izolacja awaryjna. Błędnie skonfigurowany serwer wyjściowy nie przerywa już publicznego strony. Atak DDoS na publiczną stronę nie zniechęca już pasma wyjściowego.
5. Szybsze zrozumienie modelu. Każda maszyna ma jedno zadanie. Inżynierowie myślą o kwestiach wprowadzających (ingress) bez myślenia o wyjściu (egress) i odwrotnie.
Dwa osie, dwa decyzje rozmiaru
Niezależne skalowanie
Przed podziałem wzrost w jednym kierunku streszczał tę samą maszynę. Po podziale każdy kierunek ma własne zaprojektowanie.
Rozmiar ingress: skaluje się z użytkownikami. Decyzje dotyczące zdolności znajdują się w warstwie wychodzącej (więcej replik proxy odwrotnego, większe maszyny w chmurze, CDN na przodzie). Budżet przepustowości obliczany jest w oparciu o ruch użytkownika na szczytowym poziomie.
Rozmiar egress: skaluje się z połączeniami usługi wewnętrznej z zewnętrznym API. Często dominują wydawanie webhook, połączenia z procesorem płatnic, czy pobieranie danych zewnętrznych. Budżet przepustowości obliczany jest w oparciu o wzorce wywołań wewnętrznych.
Izolacja awarii: atak DDoS na publiczny ingress nie je przepustowości egress (te połączenia z procesorem płatnic idą nadal). Zawalenie egress proxy nie powoduje zawalenia strony publicznej (użytkownicy nadal docierają na stronę; tylko wewnętrzne wyjściowe wywołania nie działają).
Różne SLO: dostępność ingress istotna jest dla użytkowników (widoczne zawalenie strony); dostępność egress istotna jest dla operatorów (ukryte niepowodzenia, które mogą dłużej nie zostać wykryte). Każda strona może mieć swój własny SLO.
Wiele serwerów egress
Kiedy rola egress jest własną maszyną, kolejnym oczywistym ruchem jest uruchomienie kilku serwerów egress za balancerem obciążenia dla HA. Każde nowe wewnętrzne usługi wskazują na nazwę hosta egress (która rozwiązuje się do puli balansującej) zamiast na pojedyncze IP.
To samo lekcja, jak reszta systemów rozproszonych: gdy warstwa staje się bezstanowa i ma własną rolę, mnoży się tanio.
Nowy partner integracja
Twoja organizacja uruchamia podział ingress / egress tak, jak zaprojektowano. Serwer egress ma stałe publiczne IP (203.0.113.99), które umówiono z trzema istniejącymi partnerami API (procesorem płatnic, bramą SMS, dostawcą e-mail).
Zespół produktowy chce dodać czwarte integrowanie: system dostarczania webhooków, który dzwoni do punktów końcowych klientów na całym świecie. Przewidywana liczba wywołań: 10 000 na minutę, z wybuchami do 30 000.
Projektowanie Granicy Sieci dla Usługi Rozrastającej Się
Synteza
Nauczysz się, dlaczego dostęp i wyjście wymagają różnych narzędzi, porażka hairpin NAT, która zmusza do podziału w rzeczywistych flotach, oraz jak niezależne skalowanie, izolacja bezpieczeństwa i izolacja awaryjna się zwiększają, gdy podział zostaje zrealizowany.
Zastosuj wszystkie cztery.
Średniej wielkości firma z usługą w chmurze obsługuje trzy poddomeny produktu (app, api, admin) dla swoich użytkowników, a także cztery integracje wyjściowe (Stripe, Twilio, SendGrid, system webhooków dla klientów). Wszystko żyje za jednym prostym urządzeniem proxy o jednym publicznym IP. Zaczęły pojawiać się doniesienia o przerywanych porażkach hairpin, gdy wewnętrzne usługi próbują dzwonić do api.example.com. Chcą zaprojektować trwałe rozwiązanie.
Gdzie Ta Kurs Pójdzie Następnie
Gdzie Ta Kurs Pójdzie Następnie
Teraz zobaczyłeś jedno z czystych refactorów rozróżniania trosk w systemach rozproszonych: jedna skrzynka staje się dwiema, każda z jasną rolą, a system uzyskuje korzyści z skalowania, bezpieczeństwa i izolacji awaryjnej.
Następny wykład (cs_distsys_failure_modes_and_blast_radius) rozszerza rozumowanie dotyczące izolacji awaryjnej. Przeczytasz zsanitowany DNS-SERVFAIL postmortem, zidentyfikujesz wzorzec porażki cascading, a napiszesz bezwinne działania, które docelą się systemów zamiast ludzi.
Lekcja towarzysząca: geometry_of_ingress_egress_separation przedstawia podział jako graf bipartytowy i baduje węzły rozdzielające, podziały sieci i to, co teoria grafów mówi o granicy sieci.
Brawo. Dalej.