Netflix to lider rynku telewizji internetowej – firma, która stworzyła i aktywnie rozwija ten segment. Netflix znany jest nie tylko z obszernego katalogu filmów i seriali dostępnych niemal z każdego zakątka planety i każdego urządzenia z wyświetlaczem, ale także z niezawodnej infrastruktury i wyjątkowej kultury inżynierskiej.
Jasny przykład podejścia Netflixa do tworzenia i wspierania złożonych systemów został zaprezentowany na DevOops 2019 - Dyrektor ds. rozwoju w Netfliksie. Absolwent Wydziału Matematyki Obliczeniowej i Matematyki Państwowego Uniwersytetu w Niżnym Nowogrodzie. Lobachevsky, Sergey, jeden z pierwszych inżynierów w Open Connect – zespole CDN w Netfliksie. Budował systemy monitorowania i analizy danych wideo, uruchomił popularną usługę oceny szybkości połączenia internetowego FAST.com, a od kilku lat pracuje nad optymalizacją żądań internetowych, aby aplikacja Netflix działała dla użytkowników możliwie najszybciej.
Raport zebrał najlepsze recenzje od uczestników konferencji, dlatego przygotowaliśmy dla Państwa wersję tekstową.
W swoim raporcie Siergiej mówił szczegółowo
- o tym, co wpływa na opóźnienie żądań internetowych między klientem a serwerem;
- jak zmniejszyć to opóźnienie;
- jak projektować, utrzymywać i monitorować systemy odporne na błędy;
- jak osiągnąć rezultaty w krótkim czasie i przy minimalnym ryzyku dla biznesu;
- jak analizować wyniki i uczyć się na błędach.
Odpowiedzi na te pytania potrzebują nie tylko ci, którzy pracują w dużych korporacjach.
Przedstawione zasady i techniki powinny być znane i praktykowane przez każdego, kto tworzy i wspiera produkty internetowe.
Następnie następuje narracja z perspektywy mówiącego.
Znaczenie szybkości Internetu
Szybkość żądań internetowych jest bezpośrednio związana z biznesem. Weźmy pod uwagę branżę zakupową: Amazon w 2009 roku że opóźnienie 100 ms powoduje utratę 1% sprzedaży.
Coraz więcej urządzeń mobilnych, a w ślad za nimi strony i aplikacje mobilne. Jeśli ładowanie Twojej strony trwa dłużej niż 3 sekundy, tracisz około połowę użytkowników. Z Google bierze pod uwagę szybkość ładowania Twojej strony w wynikach wyszukiwania: im szybsza strona, tym wyższa jej pozycja w Google.
Szybkość połączenia jest również ważna w instytucjach finansowych, gdzie opóźnienie jest krytyczne. W 2015 roku Hibernia Networks kabel o wartości 400 milionów dolarów między Nowym Jorkiem a Londynem, który zmniejszy opóźnienia między miastami o 6 ms. Wyobraź sobie 66 milionów dolarów za redukcję opóźnień o 1 ms!
Według , prędkości połączenia powyżej 5 Mbit/s nie wpływają już bezpośrednio na szybkość ładowania typowej strony internetowej. Istnieje jednak liniowa zależność pomiędzy opóźnieniem połączenia a szybkością ładowania strony:
Netflix nie jest jednak typowym produktem. Wpływ opóźnienia i szybkości na użytkownika jest aktywnym obszarem analiz i rozwoju. Ładowanie aplikacji i wybór treści zależą od opóźnienia, ale ładowanie elementów statycznych i przesyłanie strumieniowe również zależą od szybkości połączenia. Analiza i optymalizacja kluczowych czynników wpływających na doświadczenie użytkownika to aktywny obszar rozwoju kilku zespołów w Netfliksie. Jednym z celów jest zmniejszenie opóźnień żądań między urządzeniami Netflix a infrastrukturą chmurową.
W raporcie skupimy się szczególnie na zmniejszeniu opóźnień na przykładzie infrastruktury Netflix. Zastanówmy się z praktycznego punktu widzenia, jak podejść do procesów projektowania, rozwoju i eksploatacji złożonych systemów rozproszonych i spędzić czas na innowacjach i wynikach, a nie na diagnozowaniu problemów operacyjnych i awarii.
Wewnątrz Netflixa
Tysiące różnych urządzeń obsługuje aplikacje Netflix. Opracowują je cztery różne zespoły, które tworzą osobne wersje klienta na Androida, iOS, TV i przeglądarki internetowe. Wkładamy wiele wysiłku w ulepszanie i personalizowanie doświadczenia użytkownika. W tym celu przeprowadzamy równolegle setki testów A/B.
Personalizacja jest wspierana przez setki mikrousług w chmurze AWS, zapewniających spersonalizowane dane użytkownika, wysyłkę zapytań, telemetrię, Big Data i Encoding. Wizualizacja ruchu wygląda następująco:
Po lewej stronie znajduje się punkt wejścia, a następnie ruch jest rozdzielany pomiędzy kilkaset mikroserwisów, które są wspierane przez różne zespoły backendowe.
Kolejnym ważnym elementem naszej infrastruktury jest Open Connect CDN, który dostarcza użytkownikowi końcowemu statyczną zawartość - filmy, obrazy, kod klienta itp. CDN znajduje się na niestandardowych serwerach (OCA - Open Connect Appliance). Wewnątrz znajdują się macierze dysków SSD i HDD ze zoptymalizowanym FreeBSD, z NGINX i zestawem usług. Projektujemy i optymalizujemy komponenty sprzętowe i programowe tak, aby taki serwer CDN mógł przesłać do użytkowników jak najwięcej danych.
„Ściana” tych serwerów w punkcie wymiany ruchu internetowego (Internet eXchange – IX) wygląda następująco:
Usługa Internet Exchange umożliwia dostawcom usług internetowych i dostawcom treści „łączenie się” ze sobą w celu bardziej bezpośredniej wymiany danych w Internecie. Na całym świecie znajduje się około 70-80 punktów wymiany Internetu, w których zainstalowane są nasze serwery, które samodzielnie instalujemy i utrzymujemy:
Ponadto udostępniamy także serwery bezpośrednio dostawcom Internetu, którzy instalują je w swojej sieci, poprawiając lokalizację ruchu Netflix i jakość streamingu dla użytkowników:
Zestaw usług AWS odpowiada za wysyłanie żądań wideo od klientów do serwerów CDN, a także konfigurację samych serwerów - aktualizację treści, kodu programu, ustawień itp. Dla tych ostatnich zbudowaliśmy także sieć szkieletową łączącą serwery w punktach wymiany Internetu z AWS. Sieć szkieletowa to globalna sieć kabli światłowodowych i routerów, którą możemy zaprojektować i skonfigurować w zależności od naszych potrzeb.
Na nasza infrastruktura CDN obsługuje około ⅛ światowego ruchu internetowego w godzinach szczytu i ⅓ ruchu w Ameryce Północnej, gdzie Netflix działa najdłużej. Liczby imponujące, ale dla mnie jednym z najbardziej niesamowitych osiągnięć jest to, że cały system CDN jest rozwijany i utrzymywany przez zespół liczący niecałe 150 osób.
Początkowo infrastruktura CDN została zaprojektowana do dostarczania danych wideo. Jednak z czasem zdaliśmy sobie sprawę, że możemy go wykorzystać także do optymalizacji dynamicznych żądań od klientów w chmurze AWS.
O akceleracji Internetu
Obecnie Netflix ma 3 regiony AWS, a opóźnienie żądań do chmury będzie zależeć od tego, jak daleko klient znajduje się od najbliższego regionu. Jednocześnie mamy wiele serwerów CDN, które służą do dostarczania treści statycznych. Czy jest jakiś sposób na wykorzystanie tego frameworka do przyspieszenia zapytań dynamicznych? Jednak niestety nie ma możliwości buforowania tych żądań – interfejsy API są personalizowane i każdy wynik jest unikalny.
Stwórzmy proxy na serwerze CDN i zacznijmy przez niego przesyłać ruch. Czy będzie szybciej?
materiał
Pamiętajmy, jak działają protokoły sieciowe. Obecnie większość ruchu w Internecie wykorzystuje protokół HTTP, który zależy od protokołów niższej warstwy TCP i TLS. Aby klient mógł połączyć się z serwerem następuje uzgadnianie, a aby nawiązać bezpieczne połączenie, klient musi trzykrotnie wymienić wiadomości z serwerem i co najmniej jeszcze raz w celu przesłania danych. Przy opóźnieniu w obie strony (RTT) wynoszącym 100 ms odebranie pierwszego bitu danych zajęłoby nam 400 ms:
Jeśli umieścimy certyfikaty na serwerze CDN, to czas uzgadniania pomiędzy klientem a serwerem może się znacznie skrócić, jeśli CDN będzie bliżej. Załóżmy, że opóźnienie do serwera CDN wynosi 30 ms. Następnie odebranie pierwszego bitu zajmie 220 ms:
Ale to nie koniec zalet. Po nawiązaniu połączenia protokół TCP zwiększa okno przeciążenia (ilość informacji, które może przesłać równolegle przez to połączenie). Jeśli pakiet danych zostanie utracony, klasyczne implementacje protokołu TCP (takie jak TCP New Reno) zmniejszają otwarte „okno” o połowę. Wydłużenie okna przeciążenia i szybkość jego odzyskiwania po utracie zależy ponownie od opóźnienia (RTT) do serwera. Jeśli to połączenie dociera tylko do serwera CDN, odzyskiwanie będzie szybsze. Jednocześnie utrata pakietów jest zjawiskiem standardowym, szczególnie w sieciach bezprzewodowych.
Przepustowość Internetu może zostać ograniczona, szczególnie w godzinach szczytu, ze względu na ruch użytkowników, co może prowadzić do zatorów w ruchu. Jednak w Internecie nie ma możliwości nadania priorytetu niektórym żądaniom przed innymi. Na przykład nadawaj priorytet małym i wrażliwym na opóźnienia żądaniom w stosunku do „ciężkich” strumieni danych obciążających sieć. Jednak w naszym przypadku posiadanie własnej sieci szkieletowej pozwala nam to robić na części ścieżki żądań – pomiędzy CDN a chmurą i możemy to w pełni skonfigurować. Możesz mieć pewność, że małe pakiety wrażliwe na opóźnienia będą traktowane priorytetowo, a duże przepływy danych będą realizowane nieco później. Im bliżej klienta znajduje się CDN, tym większa jest wydajność.
Protokoły poziomu aplikacji (poziom OSI 7) również mają wpływ na opóźnienia. Nowe protokoły, takie jak HTTP/2, optymalizują wydajność żądań równoległych. Mamy jednak klientów Netflix ze starszymi urządzeniami, które nie obsługują nowych protokołów. Nie wszystkich klientów można zaktualizować lub optymalnie skonfigurować. Jednocześnie pomiędzy proxy CDN a chmurą istnieje pełna kontrola i możliwość wykorzystania nowych, optymalnych protokołów i ustawień. Nieefektywna część ze starymi protokołami będzie działać tylko między klientem a serwerem CDN. Co więcej, możemy wysyłać żądania multipleksowe na już nawiązanym połączeniu CDN z chmurą, poprawiając wykorzystanie połączenia na poziomie TCP:
Mierzymy
Pomimo tego, że teoria obiecuje ulepszenia, nie spieszmy się z uruchomieniem systemu w produkcji. Zamiast tego musimy najpierw udowodnić, że pomysł sprawdzi się w praktyce. Aby to zrobić, musisz odpowiedzieć na kilka pytań:
- prędkość: czy serwer proxy będzie szybszy?
- Niezawodność: Czy będzie się częściej psuł?
- Złożoność: jak integrować z aplikacjami?
- Kosztować: Ile kosztuje wdrożenie dodatkowej infrastruktury?
Rozważmy szczegółowo nasze podejście do oceny pierwszego punktu. Z resztą radzimy sobie w podobny sposób.
Aby przeanalizować szybkość żądań, chcemy uzyskać dane dla wszystkich użytkowników, bez poświęcania dużej ilości czasu na rozwój i bez przerywania produkcji. Istnieje kilka podejść do tego:
- RUM, czyli pasywny pomiar żądań. Mierzymy czas realizacji bieżących żądań użytkowników i zapewniamy pełne pokrycie użytkowników. Wadą jest to, że sygnał nie jest zbyt stabilny ze względu na wiele czynników, na przykład z powodu różnej wielkości żądań, czasu przetwarzania na serwerze i kliencie. Ponadto nie można przetestować nowej konfiguracji bez wpływu na produkcję.
- Testy laboratoryjne. Specjalne serwery i infrastruktura symulująca klientów. Za ich pomocą przeprowadzamy niezbędne badania. Dzięki temu uzyskujemy pełną kontrolę nad wynikami pomiarów i wyraźny sygnał. Nie ma jednak pełnego zasięgu urządzeń i lokalizacji użytkowników (zwłaszcza w przypadku ogólnoświatowego serwisu i wsparcia dla tysięcy modeli urządzeń).
Jak połączyć zalety obu metod?
Nasz zespół znalazł rozwiązanie. Napisaliśmy mały fragment kodu – próbkę – który wbudowaliśmy w naszą aplikację. Sondy pozwalają nam na wykonanie w pełni kontrolowanych testów sieciowych z poziomu naszych urządzeń. Działa to w ten sposób:
- Krótko po załadowaniu aplikacji i zakończeniu czynności początkowych uruchamiamy nasze sondy.
- Klient wysyła żądanie do serwera i otrzymuje „przepis” na test. Przepis to lista adresów URL, do których należy wysłać żądanie HTTP. Dodatkowo przepis konfiguruje parametry żądania: opóźnienia pomiędzy żądaniami, ilość żądanych danych, nagłówki HTTP(s) itp. Jednocześnie możemy testować kilka różnych receptur równolegle – zamawiając konfigurację losowo ustalamy, który przepis wystawić.
- Czas uruchomienia sondy dobierany jest tak, aby nie kolidował z aktywnym wykorzystaniem zasobów sieciowych na kliencie. Zasadniczo wybierany jest czas, gdy klient nie jest aktywny.
- Po otrzymaniu przepisu klient wysyła żądania równolegle do każdego z adresów URL. Zapytanie na każdy z adresów można powtórzyć – tzw. „impulsy”. Przy pierwszym impulsie mierzymy, ile czasu zajęło nawiązanie połączenia i pobranie danych. Na drugim impulsie mierzymy czas potrzebny na załadowanie danych przez już nawiązane połączenie. Przed trzecim możemy ustawić opóźnienie i zmierzyć prędkość nawiązania ponownego połączenia itp.
Podczas testu mierzymy wszystkie parametry jakie urządzenie może uzyskać:
- Czas żądania DNS;
- Czas konfiguracji połączenia TCP;
- Czas konfiguracji połączenia TLS;
- czas otrzymania pierwszego bajtu danych;
- całkowity czas ładowania;
- kod wyniku stanu.
- Po zakończeniu wszystkich impulsów próbka ładuje wszystkie pomiary do analizy.
Kluczowe punkty to minimalna zależność od logiki klienta, przetwarzanie danych na serwerze i pomiar równoległych żądań. Dzięki temu jesteśmy w stanie wyizolować i przetestować wpływ różnych czynników wpływających na wydajność zapytań, różnicować je w ramach jednej receptury i uzyskiwać wyniki od rzeczywistych klientów.
Infrastruktura ta okazała się przydatna nie tylko do analizy wydajności zapytań. Obecnie mamy 14 aktywnych receptur, ponad 6000 próbek na sekundę, odbierających dane ze wszystkich zakątków ziemi i pełne pokrycie urządzenia. Gdyby Netflix kupił podobną usługę od strony trzeciej, kosztowałaby ona miliony dolarów rocznie, przy znacznie gorszym zasięgu.
Testowanie teorii w praktyce: prototyp
Dzięki takiemu systemowi byliśmy w stanie ocenić skuteczność serwerów proxy CDN w przypadku opóźnień żądań. Teraz potrzebujesz:
- utwórz prototyp proxy;
- umieść prototyp w CDN;
- określić, w jaki sposób kierować klientów do serwera proxy na konkretnym serwerze CDN;
- Porównaj wydajność z żądaniami w AWS bez serwera proxy.
Zadaniem jest jak najszybsza ocena skuteczności zaproponowanego rozwiązania. Do wdrożenia prototypu wybraliśmy Go ze względu na dostępność dobrych bibliotek sieciowych. Na każdym serwerze CDN zainstalowaliśmy prototypowy serwer proxy jako statyczny plik binarny, aby zminimalizować zależności i uprościć integrację. W początkowej implementacji wykorzystaliśmy w miarę możliwości standardowe komponenty oraz drobne modyfikacje w zakresie puli połączeń HTTP/2 i multipleksowania żądań.
Aby zrównoważyć regiony AWS, użyliśmy geograficznej bazy danych DNS, tej samej, której używano do równoważenia klientów. Aby wybrać serwer CDN dla klienta, używamy protokołu TCP Anycast dla serwerów w Internet Exchange (IX). W tej opcji używamy jednego adresu IP dla wszystkich serwerów CDN, a klient zostanie przekierowany na serwer CDN z najmniejszą liczbą przeskoków IP. W serwerach CDN instalowanych przez dostawców Internetu (ISP) nie mamy kontroli nad routerem w celu skonfigurowania protokołu TCP Anycast, dlatego używamy , która kieruje klientów do dostawców Internetu w celu przesyłania strumieniowego wideo.
Mamy więc trzy rodzaje ścieżek żądań: do chmury poprzez otwarty Internet, poprzez serwer CDN w IX lub poprzez serwer CDN zlokalizowany u dostawcy Internetu. Naszym celem jest zrozumienie, który sposób jest lepszy i jakie są zalety serwera proxy w porównaniu ze sposobem wysyłania żądań do środowiska produkcyjnego. W tym celu stosujemy następujący system próbkowania:
Każda ze ścieżek staje się oddzielnym celem i patrzymy na czas, jaki otrzymaliśmy. Do analizy łączymy wyniki proxy w jedną grupę (wybieramy najlepszy czas pomiędzy proxy IX a ISP) i porównujemy je z czasem żądań do chmury bez proxy:
Jak widać rezultaty były mieszane – w większości przypadków proxy daje niezłe przyspieszenie, ale jest też wystarczająca liczba klientów, dla których sytuacja znacznie się pogorszy.
W rezultacie zrobiliśmy kilka ważnych rzeczy:
- Oceniliśmy oczekiwaną wydajność żądań od klientów kierowanych do chmury za pośrednictwem serwera proxy CDN.
- Otrzymywaliśmy dane od prawdziwych klientów, ze wszystkich typów urządzeń.
- Zdaliśmy sobie sprawę, że teoria nie została potwierdzona w 100% i wstępna oferta z proxy CDN nie byłaby dla nas skuteczna.
- Nie podejmowaliśmy ryzyka – nie zmienialiśmy konfiguracji produkcyjnych dla klientów.
- Nic nie zostało złamane.
Prototyp 2.0
Wróć więc do deski kreślarskiej i powtórz proces od nowa.
Pomysł jest taki, że zamiast korzystać ze 100% proxy, dla każdego klienta ustalimy najszybszą ścieżkę i tam będziemy wysyłać żądania – czyli wykonamy tzw. sterowanie klientem.
Jak to wdrożyć? Nie możemy używać logiki po stronie serwera, ponieważ... Celem jest połączenie się z tym serwerem. Musi być jakiś sposób, aby to zrobić na kliencie. Najlepiej zrobić to przy minimalnej ilości złożonej logiki, aby nie rozwiązać problemu integracji z dużą liczbą platform klienckich.
Odpowiedzią jest użycie DNS. W naszym przypadku posiadamy własną infrastrukturę DNS i możemy ustawić strefę domenową, dla której nasze serwery będą autorytarne. Działa to w ten sposób:
- Klient wysyła żądanie do serwera DNS za pomocą hosta, na przykład api.netflix.xom.
- Żądanie dociera do naszego serwera DNS
- Serwer DNS wie, która ścieżka jest najszybsza dla tego klienta i przydziela odpowiedni adres IP.
Rozwiązanie ma dodatkową złożoność: autorytarni dostawcy DNS nie widzą adresu IP klienta i mogą jedynie odczytać adres IP rekursywnego mechanizmu rozpoznawania nazw, którego używa klient.
W rezultacie nasz autorytarny mechanizm rozwiązywania problemów musi podjąć decyzję nie za pojedynczego klienta, ale za grupę klientów w oparciu o rekurencyjny mechanizm rozwiązywania problemów.
Do rozwiązania używamy tych samych próbek, agregujemy wyniki pomiarów od klientów dla każdego z rekursywnych usług tłumaczących i decydujemy, gdzie wysłać tę grupę z nich - proxy przez IX za pomocą TCP Anycast, przez proxy ISP, czy bezpośrednio do chmury.
Otrzymujemy następujący układ:
Powstały model sterowania DNS umożliwia kierowanie klientów w oparciu o historyczne obserwacje szybkości połączeń klientów z chmurą.
Ponownie pojawia się pytanie, jak skutecznie to podejście będzie działać? Aby odpowiedzieć, ponownie używamy naszego systemu sond. Dlatego konfigurujemy konfigurację prezentera, gdzie jeden z celów podąża za kierunkiem ze sterowania DNS, drugi trafia bezpośrednio do chmury (bieżąca produkcja).
W rezultacie porównujemy wyniki i uzyskujemy ocenę skuteczności:
W rezultacie dowiedzieliśmy się kilku ważnych rzeczy:
- Oceniliśmy oczekiwaną wydajność żądań od klientów do chmury za pomocą sterowania DNS.
- Otrzymywaliśmy dane od prawdziwych klientów, ze wszystkich typów urządzeń.
- Skuteczność zaproponowanego pomysłu została udowodniona.
- Nie podejmowaliśmy ryzyka – nie zmienialiśmy konfiguracji produkcyjnych dla klientów.
- Nic nie zostało złamane.
A teraz trudniejsza część – wprowadzamy go do produkcji
Łatwa część już za nami – mamy działający prototyp. Teraz najtrudniejszą częścią jest uruchomienie rozwiązania dla całego ruchu Netflix, wdrożenia dla 150 milionów użytkowników, tysięcy urządzeń, setek mikrousług oraz stale zmieniających się produktów i infrastruktury. Serwery Netflix otrzymują miliony żądań na sekundę, a nieostrożnym działaniem łatwo jest złamać usługę. Jednocześnie chcemy dynamicznie kierować ruch przez tysiące serwerów CDN w Internecie, gdzie ciągle i w najbardziej nieodpowiednim momencie coś się zmienia i psuje.
A przy tym wszystkim w zespole pracuje 3 inżynierów odpowiedzialnych za rozwój, wdrożenie i pełne wsparcie systemu.
Dlatego w dalszym ciągu będziemy mówić o spokojnym i zdrowym śnie.
Jak kontynuować rozwój i nie tracić całego czasu na wsparcie? Nasze podejście opiera się na 3 zasadach:
- Zmniejszamy potencjalną skalę awarii (promień wybuchu).
- Szykujemy się na niespodzianki - spodziewamy się, że mimo testów i osobistych doświadczeń coś się zepsuje.
- Łagodna degradacja – jeśli coś nie działa prawidłowo, należy to naprawić automatycznie, nawet jeśli nie w najbardziej efektywny sposób.
Okazało się, że w naszym przypadku dzięki takiemu podejściu do problemu możemy znaleźć proste i skuteczne rozwiązanie oraz znacznie uprościć obsługę systemu. Zdaliśmy sobie sprawę, że możemy dodać mały fragment kodu do klienta i monitorować błędy żądań sieciowych spowodowane problemami z połączeniem. W przypadku błędów sieciowych wracamy bezpośrednio do chmury. Rozwiązanie to nie wymaga dużego wysiłku od zespołów klienta, ale znacznie zmniejsza dla nas ryzyko nieoczekiwanych awarii i niespodzianek.
Oczywiście, pomimo odwrotu, podczas rozwoju przestrzegamy jasnej dyscypliny:
- Próbny test.
- Testy A/B lub Wyspy Kanaryjskie.
- Wdrażanie progresywne.
Na przykładach opisano podejście – zmiany są najpierw testowane przy użyciu dostosowanej receptury.
Do testów Canary potrzebujemy porównywalnych par serwerów, na których będziemy mogli porównać działanie systemu przed i po zmianach. W tym celu z wielu naszych witryn CDN wybieramy pary serwerów, które generują porównywalny ruch:
Następnie instalujemy kompilację ze zmianami na serwerze Canary. Aby ocenić wyniki, uruchamiamy system, który porównuje około 100-150 wskaźników z próbką serwerów Control:
Jeśli testy Canary zakończą się sukcesem, wypuścimy go stopniowo, falami. Nie aktualizujemy serwerów w każdej witrynie jednocześnie - utrata całej witryny z powodu problemów ma dla użytkowników większy wpływ na usługę niż utrata tej samej liczby serwerów w różnych lokalizacjach.
Ogólnie rzecz biorąc, skuteczność i bezpieczeństwo tego podejścia zależy od ilości i jakości zebranych wskaźników. W naszym systemie akceleracji zapytań zbieramy metryki ze wszystkich możliwych komponentów:
- od klientów - liczba sesji i żądań, stawki awaryjne;
- proxy - statystyki dotyczące liczby i czasu żądań;
- DNS - liczba i wyniki żądań;
- brzeg chmury - liczba i czas przetwarzania żądań w chmurze.
Wszystko to zbieramy w jeden potok i w zależności od potrzeb decydujemy, które metryki wysłać do analityki w czasie rzeczywistym, a które do Elasticsearch lub Big Data w celu bardziej szczegółowej diagnostyki.
Monitorujemy
W naszym przypadku dokonujemy zmian na ścieżce krytycznej żądań pomiędzy klientem a serwerem. Jednocześnie liczba różnych komponentów na kliencie, na serwerze i w drodze przez Internet jest ogromna. Zmiany na kliencie i serwerze zachodzą nieustannie – podczas pracy kilkudziesięciu zespołów i naturalnych zmian w ekosystemie. Jesteśmy pośrodku - diagnozując problemy, jest duża szansa, że się zaangażujemy. Dlatego musimy jasno zrozumieć, jak definiować, gromadzić i analizować wskaźniki, aby szybko izolować problemy.
Idealnie, pełny dostęp do wszelkiego rodzaju metryk i filtrów w czasie rzeczywistym. Istnieje jednak wiele wskaźników, więc pojawia się pytanie o koszt. W naszym przypadku metryki i narzędzia programistyczne oddzielamy w następujący sposób:
Do wykrywania i selekcji problemów używamy własnego systemu czasu rzeczywistego typu open source и - do wizualizacji. Przechowuje w pamięci zagregowane metryki, jest niezawodny i integruje się z systemem alarmowym. W celu lokalizacji i diagnostyki mamy dostęp do logów z Elasticsearch i Kibana. Do analiz statystycznych i modelowania wykorzystujemy big data i wizualizację w Tableau.
Wydaje się, że takie podejście jest bardzo trudne w realizacji. Jednakże organizując hierarchicznie metryki i narzędzia, możemy szybko przeanalizować problem, określić jego typ, a następnie przejść do szczegółowych metryk. Generalnie na identyfikację źródła awarii poświęcamy około 1-2 minut. Następnie współpracujemy z konkretnym zespołem nad diagnostyką – od kilkudziesięciu minut do kilku godzin.
Nawet jeśli diagnoza zostanie postawiona szybko, nie chcemy, aby zdarzało się to często. W idealnym przypadku alert krytyczny otrzymamy tylko w przypadku znaczącego wpływu na usługę. W przypadku naszego systemu przyspieszania zapytań mamy tylko 2 alerty, które powiadomią:
- Procentowy zwrot klientów – ocena zachowań klientów;
- procent Błędy sondy - dane dotyczące stabilności elementów sieci.
Te krytyczne alerty monitorują, czy system działa w przypadku większości użytkowników. Sprawdzamy, ilu klientów skorzystało z rozwiązania awaryjnego, jeśli nie mogli uzyskać przyspieszenia żądania. Średnio pojawia się mniej niż 1 krytyczny alert tygodniowo, mimo że w systemie zachodzi mnóstwo zmian. Dlaczego to nam wystarczy?
- Jeśli nasz serwer proxy nie działa, istnieje rezerwa klienta.
- Istnieje automatyczny układ kierowniczy, który reaguje na problemy.
Więcej szczegółów na temat tego ostatniego. Nasz system próbny oraz system automatycznego wyznaczania optymalnej ścieżki żądań od klienta do chmury, pozwala nam automatycznie radzić sobie z niektórymi problemami.
Wróćmy do naszej przykładowej konfiguracji i 3 kategorii ścieżek. Oprócz czasu załadunku możemy zwrócić uwagę na sam fakt dostawy. Jeśli załadowanie danych nie było możliwe, to patrząc na wyniki różnymi ścieżkami, możemy określić, gdzie i co się zepsuło oraz czy możemy to automatycznie naprawić, zmieniając ścieżkę żądania.
Przykłady:
Proces ten można zautomatyzować. Włącz go do układu kierowniczego. I naucz go reagować na problemy z wydajnością i niezawodnością. Jeśli coś zacznie się psuć, reaguj, jeśli istnieje lepsza opcja. Jednocześnie natychmiastowa reakcja nie jest krytyczna, dzięki wsparciu klientów.
Zatem zasady wsparcia systemowego można sformułować następująco:
- zmniejszenie skali awarii;
- zbieranie metryk;
- Jeśli to możliwe, automatycznie naprawiamy awarie;
- jeśli nie jest to możliwe, powiadamiamy Cię;
- Pracujemy nad pulpitami nawigacyjnymi i zestawem narzędzi selekcji, aby zapewnić szybką reakcję.
Zdobyta wiedza
Napisanie prototypu nie zajmuje dużo czasu. W naszym przypadku był gotowy po 4 miesiącach. Dzięki niemu otrzymaliśmy nowe metryki, a 10 miesięcy od rozpoczęcia prac deweloperskich otrzymaliśmy pierwszy ruch produkcyjny. Potem zaczęła się żmudna i bardzo trudna praca: stopniowo produkuj i skaluj system, migruj główny ruch i ucz się na błędach. Jednak ten efektywny proces nie będzie przebiegał liniowo – mimo wszelkich starań nie wszystko da się przewidzieć. Dużo efektywniejsze jest szybkie iterowanie i reagowanie na nowe dane.
Bazując na naszym doświadczeniu możemy polecić:
- Nie ufaj swojej intuicji.
Intuicja ciągle nas zawodziła, pomimo ogromnego doświadczenia członków naszego zespołu. Na przykład błędnie przewidzieliśmy oczekiwane przyspieszenie korzystania z serwera proxy CDN lub zachowanie protokołu TCP Anycast.
- Pobierz dane z produkcji.
Ważne jest, aby jak najszybciej uzyskać dostęp do choć niewielkiej ilości danych produkcyjnych. Uzyskanie liczby unikalnych przypadków, konfiguracji i ustawień w warunkach laboratoryjnych jest prawie niemożliwe. Szybki dostęp do wyników pozwoli Ci szybko poznać potencjalne problemy i uwzględnić je w architekturze systemu.
- Nie kieruj się radami i wynikami innych osób – zbieraj własne dane.
Postępuj zgodnie z zasadami gromadzenia i analizowania danych, ale nie akceptuj ślepo wyników i stwierdzeń innych osób. Tylko Ty możesz dokładnie wiedzieć, co sprawdza się w przypadku Twoich użytkowników. Twoje systemy i Twoi klienci mogą znacznie różnić się od innych firm. Na szczęście narzędzia analityczne są teraz dostępne i łatwe w użyciu. Uzyskane wyniki mogą nie odpowiadać tym, co twierdzą Netflix, Facebook, Akamai i inne firmy. W naszym przypadku wydajność TLS, HTTP2 czy statystyki dotyczące żądań DNS odbiegają od wyników Facebooka, Ubera, Akamai – bo mamy inne urządzenia, klientów i przepływy danych.
- Nie kieruj się niepotrzebnie trendami w modzie i oceniaj skuteczność.
Zacznij prosto. Lepiej w krótkim czasie stworzyć prosty działający system, niż spędzać mnóstwo czasu na opracowywaniu komponentów, których nie potrzebujesz. Rozwiązuj istotne zadania i problemy w oparciu o pomiary i wyniki.
- Przygotuj się na nowe aplikacje.
Tak jak trudno jest przewidzieć wszystkie problemy, tak trudno z góry przewidzieć korzyści i zastosowania. Weź przykład ze startupów – ich umiejętności dostosowania się do warunków klienta. W Twoim przypadku możesz odkryć nowe problemy i ich rozwiązania. W naszym projekcie za cel postawiliśmy sobie zmniejszenie opóźnień żądań. Jednak podczas analiz i dyskusji zdaliśmy sobie sprawę, że możemy również skorzystać z serwerów proxy:
- zrównoważyć ruch w regionach AWS i obniżyć koszty;
- do modelowania stabilności CDN;
- skonfigurować DNS;
- aby skonfigurować TLS/TCP.
wniosek
W raporcie opisałem, jak Netflix rozwiązuje problem przyspieszania żądań internetowych pomiędzy klientami a chmurą. Jak zbieramy dane za pomocą systemu próbkowania u klientów i wykorzystujemy zebrane dane historyczne do kierowania zleceń produkcyjnych od klientów najszybszą ścieżką w Internecie. Jak wykorzystujemy zasady protokołów sieciowych, naszą infrastrukturę CDN, sieć szkieletową i serwery DNS, aby osiągnąć to zadanie.
Jednak nasze rozwiązanie to tylko przykład tego, jak w Netfliksie wdrożyliśmy taki system. Co u nas zadziałało. Część aplikacyjna mojego raportu dla Państwa to zasady rozwoju i wsparcia, którymi się kierujemy i osiągamy dobre wyniki.
Nasze rozwiązanie problemu może Ci nie odpowiadać. Jednak teoria i zasady projektowania pozostają, nawet jeśli nie posiadasz własnej infrastruktury CDN lub jeśli znacząco różni się ona od naszej.
Znaczenie szybkości rozpatrywania wniosków biznesowych również pozostaje ważne. Nawet w przypadku prostej usługi trzeba dokonać wyboru: pomiędzy dostawcami usług w chmurze, lokalizacją serwera, dostawcami CDN i DNS. Twój wybór wpłynie na skuteczność zapytań internetowych dla Twoich klientów. Ważne jest, aby zmierzyć i zrozumieć ten wpływ.
Zacznij od prostych rozwiązań, dbaj o to jak zmieniasz produkt. Ucz się na bieżąco i ulepszaj system w oparciu o dane od klientów, infrastruktury i firmy. Pomyśl o możliwości nieoczekiwanych awarii podczas procesu projektowania. A wtedy możesz przyspieszyć proces rozwoju, poprawić wydajność rozwiązania, uniknąć niepotrzebnego obciążenia wsparciem i spać spokojnie.
W tym roku w formacie internetowym. Możesz zadawać pytania jednemu z ojców DevOps, samemu Johnowi Willisowi!
Źródło: www.habr.com