Jak śledziliśmy niezwykłe usterki DNS w AWS

Zbudowaliśmy SparkPost w oparciu o ideę, że usługa chmurowa taka jak nasza musi być również natywna w chmurze. To nie jest tylko pozowanie. To nasza architektura chmurowa stanowi fundament skalowalności, elastyczności i niezawodności, które są kluczowymi aspektami usługi SparkPost. Te cechy są głównymi powodami, dla których zbudowaliśmy naszą infrastrukturę na Amazon Web Services (AWS) — i dlatego możemy oferować naszym klientom gwarancje poziomu usług i szybkości, które nie mają sobie równych w tej branży.

Ale nie udajemy, że nigdy nie stanęliśmy przed wyzwaniami związanymi z nieoczekiwanymi błędami lub ograniczeniami dostępną technologią. Natrafiliśmy na coś takiego w ostatni piątek, a ten incydent spowodował sporadyczne spowolnienia w naszej usłudze oraz opóźnienia w dostawie dla niektórych z naszych klientów.

Na początku pozwól, że powiem, że problem został rozwiązany tego samego dnia. Co więcej, żadne e-maile ani dane związane z nimi nie zostały utracone. Jednak jeśli dostawa Twoich e-maili została spowolniona z powodu tego problemu, proszę przyjmij moje przeprosiny (w rzeczywistości, przeprosiny od całego naszego zespołu). Wiemy, że liczysz na nas, i to frustrujące, gdy nie działamy na poziomie, którego oczekujesz.

Niektóre firmy są skłonne zamieścić problemy związane z degradacją usługi pod dywan i mieć nadzieję, że nikt ich nie zauważy. Mogłeś doświadczyć tego w usługu, z których korzystałeś w przeszłości. Wiem, że ja miałem. Ale w ten sposób nie lubimy prowadzić interesów.

Chciałem napisać o tym incydencie z innego powodu: nauczyliśmy się czegoś naprawdę interesującego i wartościowego o naszej architekturze chmurowej AWS. Zespoły budujące inne usługi chmurowe mogą być zainteresowane nauczeniem się tego.

TL;DR

Napotkaliśmy nieudokumentowane, praktyczne ograniczenia instancji EC2, z których korzystaliśmy dla naszego głównego klastra DNS. Ustalanie wielkości instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa tak, jak się tego oczekuje, ale czasami tradycyjny model sprzętowy nie ma zastosowania. Dotyczy to w szczególności nietypowych przypadków użycia, w których mogą wystąpić ograniczenia agregatów — i czasami natrafia się na te sytuacje bez ostrzeżenia.

Natrafiliśmy na takie ograniczenie w piątek, kiedy nasza objętość zapytań DNS stworzyła wzór wykorzystania sieci, na który nasz typ instancji nie był przygotowany. Jednak ponieważ to ograniczenie nie było oczywiste z dokumentacji ani standardowych metryki dostępnych, nie wiedzieliśmy, że je osiągnęliśmy. To, co zaobserwowaliśmy, to bardzo wysoki wskaźnik awarii DNS, co z kolei spowodowało sporadyczne opóźnienia w różnych punktach naszej architektury.

Głębsze zanurzenie w DNS

Czemu nasze wykorzystanie DNS jest specjalne? Cóż, ma to wiele wspólnego z tym, jak działa e-mail, w porównaniu do modelu treści, dla którego AWS został pierwotnie zaprojektowany. Dostarczanie treści oparte na sieci w dużej mierze korzysta z tego, co można by uznać za klasyczne scenariusze „pull”: klient żąda danych, czy to HTML, strumieni wideo czy czegokolwiek innego, z chmury. Ale przypadki użycia dla dostawców usług messagingowych, takich jak SparkPost, są wyjątkiem od zwykłego scenariusza AWS. W naszym przypadku robimy wiele outboundowego przesyłania ruchu: konkretnie, e-maile (i inne typy wiadomości, takie jak SMS lub mobilne powiadomienia push). A ten ruch w stylu push w dużej mierze polega na DNS.

Jeśli znasz DNS, możesz wiedzieć, że jest to generalnie dość lekkie dane. Aby zażądać danej strony HTML, musisz najpierw zapytać, gdzie ta strona może być znaleziona w Internecie, ale to zapytanie jest ułamkiem wielkości treści, którą pobierasz.

E-maile, jednak, wykorzystują niezwykle intensywnie DNS do wyszukiwania domen dostawy - na przykład, SparkPost wysyła wiele miliardów e-maili do ponad 1 miliona unikalnych domen co miesiąc. Dla każdego e-maila, który dostarczamy, musimy dokonać minimum dwóch wyszukiwań DNS, a użycie rekordów DNS „txt” dla technologii przeciw phishingowych, takich jak SPF i DKIM oznacza, że DNS jest również wymagany do odbierania poczty. Do tego dodajemy nasze bardziej tradycyjne wykorzystanie usług API AWS dla naszych aplikacji, i trudno jest przesadzić jak ważny jest DNS dla naszej infrastruktury.

Wszystko to oznacza, że napotkaliśmy niezwykły stan, w którym nasza rosnąca objętość wychodzących wiadomości stworzyła objętość ruchu DNS, która osiągnęła agregatowe ograniczenie przepustowości sieci na typach instancji, które z pozoru wydawały się mieć wystarczające zasoby do obsługi tego obciążenia. A jak atakujący denial-of-service na infrastrukturę Dyn DNS w ubiegłym roku pokazali, kiedy DNS się psuje, wszystko się psuje. (To coś, co każdy, kto buduje systemy, które polegają na DNS, już wie boleśnie dobrze.)

Nagle problemy z DNS spowodowały reakcję naszych zespołów operacyjnych oraz inżynierii niezawodności na zidentyfikowanie problemu. Zespoły współpracowały z naszymi partnerami w Amazonie, aby po eskalować sprawę po stronie operacyjnej AWS. Wspólnie zidentyfikowaliśmy przyczynę i rozwiązanie. Wdrożyliśmy klaster serwerów nazw o większej pojemności z większym naciskiem na pojemność sieci, który mógł spełnić nasze potrzeby DNS bez osiągania czerwonych linii dla przepustowości. Na szczęście ponieważ wszystko to było w AWS, mogliśmy bardzo szybko uruchomić nowe instancje i nawet dostosować istniejące instancje. DNS wznowił normalne działanie, błędy w wyszukiwaniu ustały, a my (i dostawa wiadomości wychodzących) wróciliśmy na właściwą drogę.

Aby złagodzić to konkretne zagadnienie w przyszłości, wprowadzamy również zmiany w architekturze DNS, aby lepiej izolować nasze podstawowe komponenty od wpływu spotkań z podobnymi, nieoczekiwanymi progami. Pracujemy również z zespołem Amazon, aby ustalić odpowiednie modele monitorowania, które będą dawać nam adekwatne ostrzeżenia w celu zapobiegania podobnym incydentom, zanim wpłyną na jakichkolwiek naszych klientów.

AWS i srebrna podszewka chmury

Nie chcę umniejszać wpływu tego incydentu na naszych klientów. Ale nasza zdolność do zidentyfikowania podstawowego problemu jako nieoczekiwanej interakcji naszego przypadku użycia z infrastrukturą AWS — a następnie znalezienia rozwiązania w bardzo krótkim czasie — ma wiele wspólnego z tym, jak zbudowaliśmy SparkPost oraz z naszą świetną relacją z zespołem Amazon.

Świetny zespół operacyjny SparkPost, nasz zespół Inżynierii Niezawodności Strony (SRE) oraz nasi główni architekci techniczni współpracują z Amazonem każdego dnia. Siły infrastruktury AWS dały nam prawdziwą przewagę w optymalizacji architektury SparkPost pod kątem chmury. Pracując tak blisko z AWS przez ostatnie dwa lata, nauczyliśmy się również dużo o uruchamianiu infrastruktury AWS i szybkim działaniu, a także korzystamy z głębokiego wsparcia ze strony zespołu AWS.

Gdybyśmy musieli znaleźć sposób na obejście podobnego ograniczenia w tradycyjnym modelu centrum danych, coś takiego mogłoby zająć dni, a nawet tygodnie, aby w pełni rozwiązać. Ta zwinność i responsywność to tylko dwa z powodów, dla których swoją działalność opieramy na chmurze i AWS. Razem, rodzaj wiedzy chmurowej, którą nasze firmy dzielą, trudno znaleźć. Amazon był dla nas wspaniałym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co zrobiliśmy z infrastrukturą AWS.

SparkPost jest pierwszą usługą dostarczania e-maili, która została zbudowana z myślą o chmurze od samego początku. Wysyłamy więcej e-maili z prawdziwej platformy chmurowej niż ktokolwiek inny, i czasami oznacza to wejście na nieodkryte terytorium. To fundamentalna prawda w informatyce, że nie wiesz, jakie wyzwania występują w skali, aż się z nimi zderzysz. Napotkaliśmy jedno w AWS, ale nasza szybka odpowiedź to doskonały przykład elastyczności, jaką chmura czyni możliwą. To również nasze zobowiązanie wobec naszych klientów.

Czy to budujesz swoją własną infrastrukturę na AWS, czy jesteś klientem SparkPost, który korzysta z naszej, mam nadzieję, że to wyjaśnienie, co wydarzyło się w ostatni piątek i jak to rozwiązaliśmy, było przydatne.