Amazon ANS-C01: Wydajność sieci i monitorowanie — Przewodnik do nauki
Część AWS Advanced Networking Specialty ANS-C01 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.
Ulepszona sieć i infrastruktura o niskim opóźnieniu
Ulepszona sieć (enhanced networking) w AWS to zestaw funkcji na poziomie systemu operacyjnego i hypervisora, które znacznie zwiększają liczbę pakietów na sekundę, redukują opóźnienia i narzut na CPU oraz zapewniają wyższą przepustowość na interfejs wirtualny. Główne technologie to Elastic Network Adapter (ENA), który zapewnia wysokowydajną sieć opartą na SR-IOV dla większości nowoczesnych rodzin instancji EC2, oraz Elastic Fabric Adapter (EFA), który jest urządzeniem typu OS-bypass, podobnym do RDMA, zaprojektowanym dla HPC i ściśle powiązanych obciążeń MPI/libfabric. Aby włączyć ENA, należy upewnić się, że typ instancji obsługuje ENA, a obraz AMI Linux ma sterownik ENA; programistycznie można go włączyć lub sprawdzić jego status za pomocą wywołań API EC2, takich jak RunInstances z InterfaceType=efa w razie potrzeby, lub ModifyInstanceAttribute dla wsparcia ena support. EFA jest dołączany poprzez utworzenie interfejsu sieciowego z InterfaceType=efa (aws ec2 create-network-interface --interface-type efa) lub uruchomienie instancji z interfejsem sieciowym z włączonym EFA; instancja musi działać na obsługiwanym kernelu z modułem kernela libfabric/efa i zazwyczaj być umieszczona w grupie rozmieszczenia typu cluster, aby uzyskać najniższe opóźnienie wewnątrz hosta i najwyższą przepustowość dwudzielną (bisection bandwidth).
Grupy rozmieszczenia wpływają na wydajność poprzez kontrolowanie umiejscowienia instancji w bazowej infrastrukturze sieciowej. Grupa rozmieszczenia typu cluster ukierunkowuje rozmieszczenie instancji w jednym racku lub domenie sieciowej o niskim opóźnieniu, aby umożliwić maksymalną przepustowość wschód-zachód (east-west) i spójne opóźnienie — jest to wymagane w wielu przypadkach użycia EFA. Grupa rozmieszczenia typu spread wymusza rozproszenie na poziomie hostów, aby uniknąć skorelowanych awarii, ale nie poprawia opóźnień. W scenariuszach o nagłym, wysokim natężeniu ruchu, rodzina instancji i liczba vCPU definiują bazowe limity przepustowości sieciowej; na przykład, niektóre rozmiary instancji oferują do 25 Gbps lub 100 Gbps, ale bez ENA/EFA przetwarzanie pakietów i stosy TCP mogą stać się wąskimi gardłami. Projektując architekturę dla tysięcy jednoczesnych połączeń TCP (na przykład gRPC over TLS), wybieraj typy instancji o wysokiej zdolności obsługi jednoczesnych połączeń, włącz ENA i preferuj NLB z target-type=ip dla bezpośredniego adresowania podów podczas pracy w EKS, aby uniknąć wąskich gardeł na portach węzłów (node port).
Kluczowe usługi i konfiguracja dla obserwowalności i egzekwowania zasad
Monitorowanie kondycji sieci i diagnozowanie wąskich gardeł opiera się na kombinacji usług VPC Flow Logs, metryk CloudWatch, Traffic Mirroring oraz analizatorów Reachability Analyzer i Access Analyzer. VPC Flow Logs dostarczają metadanych dla każdego przepływu (źródłowy/docelowy IP, porty, pakiety, bajty, akcja), które można wysyłać do CloudWatch Logs lub S3 i przeszukiwać za pomocą CloudWatch Logs Insights, aby znaleźć prefiksy o dużym wolumenie ruchu lub najbardziej aktywnych komunikujących się (top talkers). Do inspekcji na poziomie pakietów w czasie rzeczywistym, usługa Traffic Mirroring pozwala utworzyć cel lustrzany (mirror target) i filtr, a następnie utworzyć sesje (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session), aby kopiować ruch z interfejsów ENI do urządzenia inspekcyjnego działającego w EC2 lub do partnerów AWS Network Packet Broker.
CloudWatch udostępnia odpowiednie metryki dla różnych warstw: metryki instancji EC2, takie jak NetworkIn/NetworkOut i NetworkPacketsIn/NetworkPacketsOut, metryki Application Load Balancer w przestrzeni AWS/ApplicationELB, takie jak RequestCount, ActiveConnectionCount i ClientTLSNegotiationErrorCount, metryki Network Load Balancer w przestrzeni AWS/NetworkELB, takie jak ProcessedBytes i NewFlowCount, oraz metryki AWS/DirectConnect dla interfejsu wirtualnego, takie jak BytesIn/BytesOut. Użyj alarmów CloudWatch Alarms i Contributor Insights na logach przepływu (flow logs), aby wykrywać przepływy powodujące nasycenie. Do walidacji ścieżek i konfiguracji, Reachability Analyzer (za pośrednictwem API EC2 StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) pozwala modelować i testować kompleksowe ścieżki pakietów przez tablice routingu, NACL, grupy bezpieczeństwa i połączenia VPN/Direct Connect, podczas gdy Network Access Analyzer pomaga wykrywać niezamierzone ścieżki dostępu sieciowego w obrębie Twoich VPC i AWS Organizations.
Wzorce projektowe i kompromisy w zakresie równoważenia obciążenia i bezpiecznego dostępu
Gdy wymagane jest prawdziwe szyfrowanie TLS end-to-end z mutual TLS na backendzie przy jednoczesnej obsłudze tysięcy połączeń gRPC, preferowanym wzorcem jest Network Load Balancer w trybie TCP. NLB domyślnie zachowuje źródłowy adres IP klienta i może być tworzony przez AWS Load Balancer Controller dla usług EKS za pomocą adnotacji, takich jak service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” i target-type=ip, aby kierować ruch bezpośrednio na adresy IP podów. Użycie TCP passthrough na porcie 443 oznacza, że to backendowy pod terminuje mutual TLS (weryfikacja certyfikatów klienta i serwera), więc ruch nigdy nie jest deszyfrowany w load balancerze, co zachowuje uwierzytelnianie dwukierunkowe. Ten wzorzec dobrze skaluje liczbę połączeń, ponieważ NLB jest zaprojektowany do obsługi milionów jednoczesnych połączeń i ma niski narzut na pojedyncze połączenie.
W przypadku architektur, które wymagają terminacji TLS na load balancerze i routingu opartego na ścieżce (path-based routing) do wielu grup docelowych (target groups), właściwym wyborem jest Application Load Balancer, ponieważ obsługuje on HTTP/2 i gRPC, routing oparty na ścieżce oraz reguły oparte na hoście. Aby zapewnić dokładne logowanie adresów IP klientów, gdy ALB terminuje TLS, upewnij się, że aplikacja backendowa parsuje nagłówki X-Forwarded-For (ALB wstrzykuje je automatycznie) lub użyj protokołu PROXY z NLB, jeśli potrzebujesz zachowania źródłowego IP na warstwie TCP. Jeśli używasz Global Accelerator do zapewnienia statycznych adresów IP front-endu typu anycast i chcesz uniemożliwić klientom ominięcie akceleratora i bezpośrednie odpytywanie adresu URL ALB, ogranicz grupę bezpieczeństwa (security group) ALB, aby akceptowała ruch przychodzący tylko ze statycznych adresów IP akceleratora (dwóch statycznych adresów przypisanych do akceleratora), dzięki czemu bezpośredni dostęp z internetu będzie zablokowany.
Dla współdzielonych usług obejmujących wiele kont, z rygorystyczną kontrolą na poziomie jednostek biznesowych i wymaganiami dotyczącymi skali, AWS PrivateLink (VPC Endpoint Services oparte na wewnętrznych NLB) jest często najbezpieczniejszym i najbardziej skalowalnym wzorcem. VPC z usługami współdzielonymi publikuje usługi za pośrednictwem endpointów Network Load Balancer (aws ec2 create-network-interface z grupami docelowymi) i udostępnia je jako VPC Endpoint Service. Konta konsumenckie tworzą w swoich VPC endpointy interfejsowe (interface endpoints), które łączą się z NLB dostawcy; dostawca kontroluje dostęp za pomocą polityk endpointów i grup bezpieczeństwa, a ruch nigdy nie przechodzi przez scentralizowaną płaszczyznę routingu. Transit Gateway jest odpowiedni, gdy potrzebujesz pełnej widoczności routingu i łączności przechodniej (transitive connectivity), ale centralizuje on routing i jest mniej granularny do kontroli dostępu na poziomie poszczególnych usług niż PrivateLink.
Częste pułapki i kryteria decyzyjne
Częstym błędem jest zakładanie, że reklamowana przepustowość instancji jest nieograniczona; rodziny i rozmiary instancji narzucają twarde limity sieciowe, a skalowanie powinno uwzględniać podział ruchu na wiele interfejsów ENI oraz umieszczanie instancji w grupach rozmieszczenia typu cluster w celu uzyskania stałej wydajności. Kolejną pułapką jest poleganie wyłącznie na metrykach CloudWatch NetworkIn/NetworkOut bez korelowania ich z VPC Flow Logs w celu przypisania ruchu do konkretnego VPC, podsieci lub jednostki biznesowej; Flow Logs i Traffic Mirroring są niezbędne do wyizolowania, który interfejs wirtualny lub aplikacja powoduje nasycenie łącza Direct Connect. Należy również unikać kończenia sesji TLS na ALB, gdy wymagane jest wzajemne TLS (mTLS) na całej ścieżce (end-to-end) — jeśli polityka wymaga, aby backend widział certyfikat klienta, należy wybrać przekazywanie TLS (passthrough) za pomocą NLB lub zrealizować mostkowanie TLS (bridging) z odpowiednią walidacją certyfikatów, ale jasno określić, gdzie ustanawiane jest zaufanie.
Podczas diagnozowania okresowego nasycenia na współdzielonych łączach fizycznych, takich jak Direct Connect, należy korelować metryki z różnych warstw: metryki AWS/DirectConnect dla interfejsów wirtualnych, VPC Flow Logs dla liczby bajtów na poziomie podsieci/ENI oraz metryki EC2 Network* dla zachowania na poziomie instancji. Użyj Reachability Analyzer, aby zweryfikować, czy routing asymetryczny lub błędna propagacja tras powoduje problemy ze ścieżką powrotną, a także użyj Traffic Mirroring do przechwytywania zrzutów pakietów w celu głębokiej inspekcji protokołu.
Problem praktyczny: Scenariusz użycia
Firma AcmeIoT boryka się z problemem, w którym automaty sprzedające na całym świecie muszą łączyć się przez gRPC z użyciem wzajemnego TLS z backendem hostowanym na EKS. Liczba połączeń musi sięgać tysięcy, usługa musi pozostać zaszyfrowana na całej ścieżce, a pody backendu skalują się dynamicznie za pomocą Cluster Autoscaler i HPA.
- Utwórz AWS LoadBalancer typu Network Load Balancer dla usługi Kubernetes, używając AWS Load Balancer Controller i adnotacji w celu określenia typu NLB oraz target-type=ip (
undefined
i
undefined
). Skonfiguruj listener TCP na porcie 443, aby NLB realizował czyste przekazywanie TCP (passthrough); nie konfiguruj certyfikatów TLS na NLB.
Zaimplementuj kończenie i walidację wzajemnego TLS w podach aplikacji. Każdy pod powinien przedstawiać certyfikat serwera i walidować certyfikaty klienta, używając procesu rotacji certyfikatów o krótkim czasie życia, zintegrowanego z AWS Secrets Manager lub SSM Parameter Store. Upewnij się, że adresy IP podów są osiągalne poprzez użycie target-type ip oraz że sprawdzanie stanu zdrowia (health check) to sprawdzanie TCP lub gRPC skonfigurowane w grupie docelowej.
Zapewnij wysoką skalę połączeń, wybierając instancje ze wsparciem dla ENA i wystarczającą przepustowością sieciową, włącz ENA (potwierdź obecność sterownika ENA w obrazie AMI i użyj
undefined
, aby włączyć ena-support w razie potrzeby) i wdrażaj pody na wielu węzłach, pozwalając Cluster Autoscaler skalować węzły w oparciu o zapotrzebowanie podów. Użyj grup rozmieszczenia dla ciasno powiązanych klastrów wymagających stałych opóźnień i wdróż wystarczającą liczbę węzłów w różnych Strefach Dostępności (AZ).
- Monitoruj i weryfikuj za pomocą CloudWatch i VPC Flow Logs. Utwórz metryki i alarmy CloudWatch dla NLB ActiveFlowCount/NewFlowCount oraz EC2 NetworkIn/Out dla węzłów roboczych EKS. Użyj VPC Flow Logs, aby zidentyfikować najbardziej aktywne komunikacyjnie zasoby (top-talkers) oraz Reachability Analyzer (
undefined
/
undefined
), aby weryfikować ścieżki routingu podczas zdarzeń autoskalowania. Jeśli potrzebujesz debugowania na poziomie pakietów, utwórz sesje Traffic Mirroring do instancji inspekcyjnej.
Uzasadnienie ze strony AWS: Network Load Balancer w trybie TCP zachowuje źródłowy adres IP, obsługuje ogromną liczbę jednoczesnych połączeń i pozwala na szyfrowanie TLS end-to-end, ponieważ sam nie kończy sesji TLS. Użycie target-type ip z AWS Load Balancer Controller integruje się z semantyką autoskalowania EKS, dzięki czemu nowe adresy IP podów są dynamicznie rejestrowane jako cele. ENA i odpowiedni dobór rozmiaru instancji zapewniają surową wydajność sieciową do obsługi tysięcy jednoczesnych połączeń TLS bez wyczerpania CPU hosta, a połączenie CloudWatch, VPC Flow Logs, Reachability Analyzer i Traffic Mirroring zapewnia obserwowalność wymaganą do wykrywania i naprawy problemów z nasyceniem lub routingiem.
← Dostarczanie treści i sieci brzegowe · Wszystkie domeny · Automatyzacja →
Przećwicz te pytania → · Testy na czas na ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Zdaj egzamin →