Dzień, w którym nasz DNS osiągnął nieudokumentowany limit w AWS
Ptak
7 lut 2017
Inżynieria
1 min read
Najważniejsze informacje
SparkPost napotkał nieudokumentowane ograniczenie przepustowości sieci na określonym typie instancji AWS EC2, która zasilała jego główny klaster DNS.
Tradycyjne określanie rozmiaru instancji (CPU, RAM, dysk) nie ujawniło tego wąskiego gardła, ponieważ problem dotyczył agregowanego ruchu sieciowego DNS, a nie niedoboru zasobów.
Użycie DNS do wysyłania poczty e-mail o dużym wolumenie jest niezwykle intensywne: SparkPost generuje miliony zapytań DNS dla trasowania domen, uwierzytelniania (SPF/DKIM) i interakcji z API AWS.
Awaria DNS nie wynikała z błędnie sformułowanych odpowiedzi DNS — raczej, poziomy pojemności sieciowej instancji były cicho przekraczane, co powodowało powszechne awarie zapytań.
Ponieważ AWS nie dokumentuje explicite tych miękkich limitów sieciowych, diagnozowanie problemu wymagało głębokiej współpracy między zespołem SRE SparkPost a inżynierami AWS.
Zespół rozwiązał problem poprzez migrację usług DNS na większe typy instancji z lepszą przepustowością sieciową oraz redesign części architektury DNS w celu lepszej izolacji i awaryjnego przekierowania.
Nie utracono danych klientów ani wiadomości, ale wydarzenie podkreśliło, jak architektury chmurowe mogą napotkać niespodziewane limity na dużą skalę — i jak szybko mogą być naprawione dzięki elastyczności AWS.
Podsumowanie pytań i odpowiedzi
Co się stało?
Klaster DNS SparkPost trafił na nieoczekiwany sufit przepustowości sieci AWS, co spowodowało sporadyczne błędy w wyszukiwaniu DNS — co opóźniło dostarczanie wiadomości e-mail.
Dlaczego DNS w ogóle przestał działać?
DNS jest niezwykle zależny od zależności w przypadku wychodzącego e-maila. Każde wysłanie wymaga wielu zapytań (MX, TXT, SPF, DKIM), więc wysoka objętość wysyłania = ogromny ruch DNS.
Ten wzór ruchu przekroczył nieudokumentowany limit na typie instancji EC2 hostującej serwery nazw.
Jak DNS dla e-maila różni się od aplikacji internetowych?
Aplikacje internetowe głównie ściągają treści (klienty żądają danych).
Usługi dostarczania e-maili wdrażają ruch, co wywołuje znacznie więcej zapytań DNS - często miliardy miesięcznie.
E-mail polega na DNS w celu routowania, weryfikacji bezpieczeństwa i awaryjnego przełączania.
Jak manifestowała się porażka?
Zapytania DNS zaczęły się gubić lub przekraczać czas oczekiwania
Kolejki dostaw były zablokowane
Opóźnienie wzrosło w różnych częściach systemu
Nic nie zostało stracone — tylko opóźnione.
Dlaczego to było trudne do zdiagnozowania?
Limit nie został udokumentowany
Monitoring AWS nie pokazywał wyraźnie wąskiego gardła
Wszystkie tradycyjne metryki (CPU, RAM, dysk) wyglądały normalnie
Problem ujawnił się tylko w specyficznym wzorcu ruchu DNS o dużym wolumenie.
Jak SparkPost to naprawił?
Ulepszono typy instancji EC2 z wyższymi limitami przepustowości sieci
Re-architektura klastrów DNS, aby były bardziej odporne na szczyty ruchu agregatowego
Współpracowano z AWS, aby zidentyfikować lepsze wzorce sygnalizacji/alertów, aby wychwycić to wcześniej
Czy dane klienta lub poczta zostały utracone?
Nie — tylko dostawa została spowolniona. Gdy DNS się ustabilizował, cała poczta wróciła do normalnej dostawy.
Jaka jest szersza lekcja?
Nawet w chmurze możesz napotkać niewidoczne ograniczenia skalowania — ale projekty natywne dla chmury dają ci elastyczność do szybkiej regeneracji.
Elastyczność, partnerstwo z AWS i mocne praktyki SRE umożliwiają szybką regenerację.
Jak śledziliśmy nietypowe awarie DNS w AWS
Zbudowaliśmy SparkPost w oparciu o pomysł, że usługa chmurowa, taka jak nasza, musi być natywna dla chmury. To nie jest tylko pozowanie. To nasza architektura chmury stanowi podstawę skalowalności, elastyczności i niezawodności, które są podstawowymi 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 gwarancje szybkości dostarczania, które są niewspółmierne z tym, co oferuje ktokolwiek inny w branży.
Ale nie udajemy, że nigdy nie jesteśmy wyzwani przez niespodziewane błędy lub ograniczenia dostępnej technologii. Napotkaliśmy coś takiego w zeszły piątek, a to zdarzenie doprowadziło do przejrzystych opóźnień w naszej usłudze i opóźnień w dostawie dla niektórych naszych klientów.
Najpierw chcę powiedzieć, że problem został rozwiązany tego samego dnia. Co więcej, żaden e-mail ani pokrewne dane nie zostały utracone. Jednak jeśli dostarczanie twoich e-maili zostało spowolnione z powodu tego problemu, proszę przyjąć moje przeprosiny (w rzeczywistości, przeprosiny od całego naszego zespołu). To zdarzenie wzmocniło znaczenie posiadania kompleksowych strategii backupowych - niezależnie od tego, czy korzystasz z kopii zapasowych bazy danych PostgreSQL, czy innych metod ochrony danych, aby zapewnić ciągłość biznesową podczas wyzwań związanych z infrastrukturą. Wiemy, że na nas liczysz, i to frustrujące, gdy nie działamy na poziomie, który oczekujesz.
Niektóre firmy są skłonne zamiatać problemy takie jak degradacja usługi pod dywan i mieć nadzieję, że nikt nie zauważy. Mogłeś doświadczyć tego w przypadku usług, z których korzystałeś w przeszłości. Wiem, że tak było. Ale nie o to chodzi w naszym stylu prowadzenia biznesu.
Chciałem napisać o tym zdarzeniu z jeszcze jednego powodu: nauczyliśmy się czegoś naprawdę interesującego i wartościowego o naszej architekturze chmury AWS. Zespoły budujące inne usługi chmurowe mogą być zainteresowane nauką na ten temat.
Zbudowaliśmy SparkPost w oparciu o pomysł, że usługa chmurowa, taka jak nasza, musi być natywna dla chmury. To nie jest tylko pozowanie. To nasza architektura chmury stanowi podstawę skalowalności, elastyczności i niezawodności, które są podstawowymi 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 gwarancje szybkości dostarczania, które są niewspółmierne z tym, co oferuje ktokolwiek inny w branży.
Ale nie udajemy, że nigdy nie jesteśmy wyzwani przez niespodziewane błędy lub ograniczenia dostępnej technologii. Napotkaliśmy coś takiego w zeszły piątek, a to zdarzenie doprowadziło do przejrzystych opóźnień w naszej usłudze i opóźnień w dostawie dla niektórych naszych klientów.
Najpierw chcę powiedzieć, że problem został rozwiązany tego samego dnia. Co więcej, żaden e-mail ani pokrewne dane nie zostały utracone. Jednak jeśli dostarczanie twoich e-maili zostało spowolnione z powodu tego problemu, proszę przyjąć moje przeprosiny (w rzeczywistości, przeprosiny od całego naszego zespołu). To zdarzenie wzmocniło znaczenie posiadania kompleksowych strategii backupowych - niezależnie od tego, czy korzystasz z kopii zapasowych bazy danych PostgreSQL, czy innych metod ochrony danych, aby zapewnić ciągłość biznesową podczas wyzwań związanych z infrastrukturą. Wiemy, że na nas liczysz, i to frustrujące, gdy nie działamy na poziomie, który oczekujesz.
Niektóre firmy są skłonne zamiatać problemy takie jak degradacja usługi pod dywan i mieć nadzieję, że nikt nie zauważy. Mogłeś doświadczyć tego w przypadku usług, z których korzystałeś w przeszłości. Wiem, że tak było. Ale nie o to chodzi w naszym stylu prowadzenia biznesu.
Chciałem napisać o tym zdarzeniu z jeszcze jednego powodu: nauczyliśmy się czegoś naprawdę interesującego i wartościowego o naszej architekturze chmury AWS. Zespoły budujące inne usługi chmurowe mogą być zainteresowane nauką na ten temat.
Zbudowaliśmy SparkPost w oparciu o pomysł, że usługa chmurowa, taka jak nasza, musi być natywna dla chmury. To nie jest tylko pozowanie. To nasza architektura chmury stanowi podstawę skalowalności, elastyczności i niezawodności, które są podstawowymi 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 gwarancje szybkości dostarczania, które są niewspółmierne z tym, co oferuje ktokolwiek inny w branży.
Ale nie udajemy, że nigdy nie jesteśmy wyzwani przez niespodziewane błędy lub ograniczenia dostępnej technologii. Napotkaliśmy coś takiego w zeszły piątek, a to zdarzenie doprowadziło do przejrzystych opóźnień w naszej usłudze i opóźnień w dostawie dla niektórych naszych klientów.
Najpierw chcę powiedzieć, że problem został rozwiązany tego samego dnia. Co więcej, żaden e-mail ani pokrewne dane nie zostały utracone. Jednak jeśli dostarczanie twoich e-maili zostało spowolnione z powodu tego problemu, proszę przyjąć moje przeprosiny (w rzeczywistości, przeprosiny od całego naszego zespołu). To zdarzenie wzmocniło znaczenie posiadania kompleksowych strategii backupowych - niezależnie od tego, czy korzystasz z kopii zapasowych bazy danych PostgreSQL, czy innych metod ochrony danych, aby zapewnić ciągłość biznesową podczas wyzwań związanych z infrastrukturą. Wiemy, że na nas liczysz, i to frustrujące, gdy nie działamy na poziomie, który oczekujesz.
Niektóre firmy są skłonne zamiatać problemy takie jak degradacja usługi pod dywan i mieć nadzieję, że nikt nie zauważy. Mogłeś doświadczyć tego w przypadku usług, z których korzystałeś w przeszłości. Wiem, że tak było. Ale nie o to chodzi w naszym stylu prowadzenia biznesu.
Chciałem napisać o tym zdarzeniu z jeszcze jednego powodu: nauczyliśmy się czegoś naprawdę interesującego i wartościowego o naszej architekturze chmury AWS. Zespoły budujące inne usługi chmurowe mogą być zainteresowane nauką na ten temat.
TL;DR
Natrafiliśmy na nieudokumentowane praktyczne ograniczenia instancji EC2, które używaliśmy do naszego głównego klastra DNS. Wybór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa, tak jak się spodziewasz, ale czasami tradycyjny model sprzętowy się nie sprawdza. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, w których mogą wystąpić ograniczenia zbiorcze — i są momenty, kiedy bez ostrzeżenia natrafiasz prosto na te scenariusze.
Natrafiliśmy na takie ograniczenie w piątek, kiedy nasza objętość zapytań DNS stworzyła wzór użycia sieci, na który nasz typ instancji nie był przygotowany. Jednak ponieważ to ograniczenie nie było oczywiste z dokumentacji ani standardowych metryk dostępnych, nie wiedzieliśmy, że go osiągnęliśmy. To, co zaobserwowaliśmy, to bardzo wysoki wskaźnik awarii DNS, co z kolei prowadziło do sporadycznych opóźnień w różnych punktach naszej architektury.
Natrafiliśmy na nieudokumentowane praktyczne ograniczenia instancji EC2, które używaliśmy do naszego głównego klastra DNS. Wybór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa, tak jak się spodziewasz, ale czasami tradycyjny model sprzętowy się nie sprawdza. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, w których mogą wystąpić ograniczenia zbiorcze — i są momenty, kiedy bez ostrzeżenia natrafiasz prosto na te scenariusze.
Natrafiliśmy na takie ograniczenie w piątek, kiedy nasza objętość zapytań DNS stworzyła wzór użycia sieci, na który nasz typ instancji nie był przygotowany. Jednak ponieważ to ograniczenie nie było oczywiste z dokumentacji ani standardowych metryk dostępnych, nie wiedzieliśmy, że go osiągnęliśmy. To, co zaobserwowaliśmy, to bardzo wysoki wskaźnik awarii DNS, co z kolei prowadziło do sporadycznych opóźnień w różnych punktach naszej architektury.
Natrafiliśmy na nieudokumentowane praktyczne ograniczenia instancji EC2, które używaliśmy do naszego głównego klastra DNS. Wybór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa, tak jak się spodziewasz, ale czasami tradycyjny model sprzętowy się nie sprawdza. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, w których mogą wystąpić ograniczenia zbiorcze — i są momenty, kiedy bez ostrzeżenia natrafiasz prosto na te scenariusze.
Natrafiliśmy na takie ograniczenie w piątek, kiedy nasza objętość zapytań DNS stworzyła wzór użycia sieci, na który nasz typ instancji nie był przygotowany. Jednak ponieważ to ograniczenie nie było oczywiste z dokumentacji ani standardowych metryk dostępnych, nie wiedzieliśmy, że go osiągnęliśmy. To, co zaobserwowaliśmy, to bardzo wysoki wskaźnik awarii DNS, co z kolei prowadziło do sporadycznych opóźnień w różnych punktach naszej architektury.
Zagłębianie się w DNS
Dlaczego nasze użycie DNS jest szczególne? Cóż, ma to wiele wspólnego ze sposobem działania e-maila w porównaniu do modelu treści, dla którego AWS został pierwotnie zaprojektowany. Webowa dostawa treści w dużym stopniu opiera się na tym, co można by uznać za klasyczne scenariusze “pull” przychodzące: klient żąda danych, czy to HTML, strumieni wideo, czy czegokolwiek innego, z chmury. Ale przypadki użycia dla dostawców usług komunikacyjnych, takich jak SparkPost, są wyjątkiem od zwykłego scenariusza AWS. W naszym przypadku robimy wiele wychodzącego przepychania ruchu: konkretnie, e-mail (i inne typy wiadomości, takie jak SMS czy mobilne powiadomienia push). A ten ruch typu push w dużym stopniu opiera się na DNS.
Jeśli znasz DNS, wiesz, że zazwyczaj jest to stosunkowo lekkie dane. Aby zażądać danej strony HTML, najpierw musisz zapytać, gdzie ta strona może być znaleziono w Internecie, ale to żądanie stanowi ułamek rozmiaru treści, którą pobierasz.
E-mail jednak wyjątkowo intensywnie korzysta z DNS do wyszukiwania domen dostarczania – na przykład, SparkPost wysyła wiele miliardów e-maili do ponad 1 miliona unikalnych domen co miesiąc. Na każdy e-mail, który dostarczamy, musimy wykonać minimum dwa zapytania DNS, a użycie rekordów DNS “txt” dla technologii przeciw phishingowi, takich jak SPF i DKIM, oznacza, że DNS jest również wymagany do odbierania poczty. Dodajmy do tego nasze bardziej tradycyjne wykorzystanie usług API AWS dla naszych aplikacji, i trudno jest przesadzić, jak ważne jest DNS dla naszej infrastruktury.
Wszystko to oznacza, że napotkaliśmy niezwykły warunek, w którym nasza rosnąca liczba wychodzących wiadomości stworzyła wolumen ruchu DNS, który osiągnął łączny limit przepustowości sieci na typach instancji, które w przeciwnym razie wydawały się mieć wystarczające zasoby, aby obsłużyć ten ładunek. A jak pokazały ataki typu denial-of-service na infrastrukturę Dyn DNS w zeszłym roku, gdy DNS zawodzi, wszystko zawodzi. (To jest coś, co każdy, kto buduje systemy polegające na DNS, już doskonale wie.)
Nagłe problemy z DNS wywołały reakcję naszych zespołów operacyjnych i inżynierii niezawodności w celu zidentyfikowania problemu. Współpracowali z naszymi partnerami w Amazonie, aby eskalować ze strony operacji 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óre mogły spełnić nasze potrzeby DNS bez przekraczania granic przepustowości. Na szczęście, ponieważ wszystko to miało miejsce w AWS, mogliśmy szybko uruchomić nowe instancje, a nawet zmienić rozmiar istniejących instancji. DNS wznowił normalne działanie, awarie wyszukiwania ustały, a my (oraz dostarczanie wiadomości wychodzących) wróciliśmy na właściwe tory.
Aby zminimalizować to konkretne zagrożenie w przyszłości, wprowadzamy również zmiany w architekturze DNS, aby lepiej izolować nasze podstawowe komponenty od skutków spotkań z podobnymi, nieoczekiwanymi progami. Pracujemy także z zespołem Amazonu, aby określić odpowiednie modele monitorowania, które dadzą nam wystarczające ostrzeżenie, aby zapobiec podobnemu incydentowi, zanim wpłynie to na jakiegokolwiek z naszych klientów.
Temat | Typowy ładunek roboczy AWS | Wychodzący ładunek e-mailowy SparkPost |
|---|---|---|
Wzór ruchu | Głównie przychodzące żądania “pull” (strony internetowe, interfejsy API, multimedia) | Intensywny ruch wychodzący “push” (miliardy e-maili) |
Zależność od DNS | Lekka: 1–2 zapytania na żądanie treści | Bardzo duża: wiele zapytań DNS na e-mail + kontrole TXT SPF/DKIM |
Wolumen zapytań | Przewidywalny i proporcjonalny do aktywności użytkownika | Eksploduje w przypadku kampanii wychodzących skierowanych do milionów domen |
Typ wąskiego gardła | Ograniczenia CPU, pamięci lub przechowywania | Łączne limity przepustowości sieci na typach instancji |
Tryb awarii | Pogorszona latencja lub limit czasu API | Awarie zapytań DNS powodujące opóźnienia w dostarczaniu |
Widoczność | Limity zazwyczaj udokumentowane i widoczne w metrykach | Limit przepustowości był niedokumentowany i niewidoczny w CloudWatch |
Podejście do łagodzenia | Skalowanie zasobów instancji lub dodawanie pamięci podręcznej | Migrowanie do rodzin instancji o wyższej przepustowości + redesign architektury DNS |
Dlaczego nasze użycie DNS jest szczególne? Cóż, ma to wiele wspólnego ze sposobem działania e-maila w porównaniu do modelu treści, dla którego AWS został pierwotnie zaprojektowany. Webowa dostawa treści w dużym stopniu opiera się na tym, co można by uznać za klasyczne scenariusze “pull” przychodzące: klient żąda danych, czy to HTML, strumieni wideo, czy czegokolwiek innego, z chmury. Ale przypadki użycia dla dostawców usług komunikacyjnych, takich jak SparkPost, są wyjątkiem od zwykłego scenariusza AWS. W naszym przypadku robimy wiele wychodzącego przepychania ruchu: konkretnie, e-mail (i inne typy wiadomości, takie jak SMS czy mobilne powiadomienia push). A ten ruch typu push w dużym stopniu opiera się na DNS.
Jeśli znasz DNS, wiesz, że zazwyczaj jest to stosunkowo lekkie dane. Aby zażądać danej strony HTML, najpierw musisz zapytać, gdzie ta strona może być znaleziono w Internecie, ale to żądanie stanowi ułamek rozmiaru treści, którą pobierasz.
E-mail jednak wyjątkowo intensywnie korzysta z DNS do wyszukiwania domen dostarczania – na przykład, SparkPost wysyła wiele miliardów e-maili do ponad 1 miliona unikalnych domen co miesiąc. Na każdy e-mail, który dostarczamy, musimy wykonać minimum dwa zapytania DNS, a użycie rekordów DNS “txt” dla technologii przeciw phishingowi, takich jak SPF i DKIM, oznacza, że DNS jest również wymagany do odbierania poczty. Dodajmy do tego nasze bardziej tradycyjne wykorzystanie usług API AWS dla naszych aplikacji, i trudno jest przesadzić, jak ważne jest DNS dla naszej infrastruktury.
Wszystko to oznacza, że napotkaliśmy niezwykły warunek, w którym nasza rosnąca liczba wychodzących wiadomości stworzyła wolumen ruchu DNS, który osiągnął łączny limit przepustowości sieci na typach instancji, które w przeciwnym razie wydawały się mieć wystarczające zasoby, aby obsłużyć ten ładunek. A jak pokazały ataki typu denial-of-service na infrastrukturę Dyn DNS w zeszłym roku, gdy DNS zawodzi, wszystko zawodzi. (To jest coś, co każdy, kto buduje systemy polegające na DNS, już doskonale wie.)
Nagłe problemy z DNS wywołały reakcję naszych zespołów operacyjnych i inżynierii niezawodności w celu zidentyfikowania problemu. Współpracowali z naszymi partnerami w Amazonie, aby eskalować ze strony operacji 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óre mogły spełnić nasze potrzeby DNS bez przekraczania granic przepustowości. Na szczęście, ponieważ wszystko to miało miejsce w AWS, mogliśmy szybko uruchomić nowe instancje, a nawet zmienić rozmiar istniejących instancji. DNS wznowił normalne działanie, awarie wyszukiwania ustały, a my (oraz dostarczanie wiadomości wychodzących) wróciliśmy na właściwe tory.
Aby zminimalizować to konkretne zagrożenie w przyszłości, wprowadzamy również zmiany w architekturze DNS, aby lepiej izolować nasze podstawowe komponenty od skutków spotkań z podobnymi, nieoczekiwanymi progami. Pracujemy także z zespołem Amazonu, aby określić odpowiednie modele monitorowania, które dadzą nam wystarczające ostrzeżenie, aby zapobiec podobnemu incydentowi, zanim wpłynie to na jakiegokolwiek z naszych klientów.
Temat | Typowy ładunek roboczy AWS | Wychodzący ładunek e-mailowy SparkPost |
|---|---|---|
Wzór ruchu | Głównie przychodzące żądania “pull” (strony internetowe, interfejsy API, multimedia) | Intensywny ruch wychodzący “push” (miliardy e-maili) |
Zależność od DNS | Lekka: 1–2 zapytania na żądanie treści | Bardzo duża: wiele zapytań DNS na e-mail + kontrole TXT SPF/DKIM |
Wolumen zapytań | Przewidywalny i proporcjonalny do aktywności użytkownika | Eksploduje w przypadku kampanii wychodzących skierowanych do milionów domen |
Typ wąskiego gardła | Ograniczenia CPU, pamięci lub przechowywania | Łączne limity przepustowości sieci na typach instancji |
Tryb awarii | Pogorszona latencja lub limit czasu API | Awarie zapytań DNS powodujące opóźnienia w dostarczaniu |
Widoczność | Limity zazwyczaj udokumentowane i widoczne w metrykach | Limit przepustowości był niedokumentowany i niewidoczny w CloudWatch |
Podejście do łagodzenia | Skalowanie zasobów instancji lub dodawanie pamięci podręcznej | Migrowanie do rodzin instancji o wyższej przepustowości + redesign architektury DNS |
Dlaczego nasze użycie DNS jest szczególne? Cóż, ma to wiele wspólnego ze sposobem działania e-maila w porównaniu do modelu treści, dla którego AWS został pierwotnie zaprojektowany. Webowa dostawa treści w dużym stopniu opiera się na tym, co można by uznać za klasyczne scenariusze “pull” przychodzące: klient żąda danych, czy to HTML, strumieni wideo, czy czegokolwiek innego, z chmury. Ale przypadki użycia dla dostawców usług komunikacyjnych, takich jak SparkPost, są wyjątkiem od zwykłego scenariusza AWS. W naszym przypadku robimy wiele wychodzącego przepychania ruchu: konkretnie, e-mail (i inne typy wiadomości, takie jak SMS czy mobilne powiadomienia push). A ten ruch typu push w dużym stopniu opiera się na DNS.
Jeśli znasz DNS, wiesz, że zazwyczaj jest to stosunkowo lekkie dane. Aby zażądać danej strony HTML, najpierw musisz zapytać, gdzie ta strona może być znaleziono w Internecie, ale to żądanie stanowi ułamek rozmiaru treści, którą pobierasz.
E-mail jednak wyjątkowo intensywnie korzysta z DNS do wyszukiwania domen dostarczania – na przykład, SparkPost wysyła wiele miliardów e-maili do ponad 1 miliona unikalnych domen co miesiąc. Na każdy e-mail, który dostarczamy, musimy wykonać minimum dwa zapytania DNS, a użycie rekordów DNS “txt” dla technologii przeciw phishingowi, takich jak SPF i DKIM, oznacza, że DNS jest również wymagany do odbierania poczty. Dodajmy do tego nasze bardziej tradycyjne wykorzystanie usług API AWS dla naszych aplikacji, i trudno jest przesadzić, jak ważne jest DNS dla naszej infrastruktury.
Wszystko to oznacza, że napotkaliśmy niezwykły warunek, w którym nasza rosnąca liczba wychodzących wiadomości stworzyła wolumen ruchu DNS, który osiągnął łączny limit przepustowości sieci na typach instancji, które w przeciwnym razie wydawały się mieć wystarczające zasoby, aby obsłużyć ten ładunek. A jak pokazały ataki typu denial-of-service na infrastrukturę Dyn DNS w zeszłym roku, gdy DNS zawodzi, wszystko zawodzi. (To jest coś, co każdy, kto buduje systemy polegające na DNS, już doskonale wie.)
Nagłe problemy z DNS wywołały reakcję naszych zespołów operacyjnych i inżynierii niezawodności w celu zidentyfikowania problemu. Współpracowali z naszymi partnerami w Amazonie, aby eskalować ze strony operacji 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óre mogły spełnić nasze potrzeby DNS bez przekraczania granic przepustowości. Na szczęście, ponieważ wszystko to miało miejsce w AWS, mogliśmy szybko uruchomić nowe instancje, a nawet zmienić rozmiar istniejących instancji. DNS wznowił normalne działanie, awarie wyszukiwania ustały, a my (oraz dostarczanie wiadomości wychodzących) wróciliśmy na właściwe tory.
Aby zminimalizować to konkretne zagrożenie w przyszłości, wprowadzamy również zmiany w architekturze DNS, aby lepiej izolować nasze podstawowe komponenty od skutków spotkań z podobnymi, nieoczekiwanymi progami. Pracujemy także z zespołem Amazonu, aby określić odpowiednie modele monitorowania, które dadzą nam wystarczające ostrzeżenie, aby zapobiec podobnemu incydentowi, zanim wpłynie to na jakiegokolwiek z naszych klientów.
Temat | Typowy ładunek roboczy AWS | Wychodzący ładunek e-mailowy SparkPost |
|---|---|---|
Wzór ruchu | Głównie przychodzące żądania “pull” (strony internetowe, interfejsy API, multimedia) | Intensywny ruch wychodzący “push” (miliardy e-maili) |
Zależność od DNS | Lekka: 1–2 zapytania na żądanie treści | Bardzo duża: wiele zapytań DNS na e-mail + kontrole TXT SPF/DKIM |
Wolumen zapytań | Przewidywalny i proporcjonalny do aktywności użytkownika | Eksploduje w przypadku kampanii wychodzących skierowanych do milionów domen |
Typ wąskiego gardła | Ograniczenia CPU, pamięci lub przechowywania | Łączne limity przepustowości sieci na typach instancji |
Tryb awarii | Pogorszona latencja lub limit czasu API | Awarie zapytań DNS powodujące opóźnienia w dostarczaniu |
Widoczność | Limity zazwyczaj udokumentowane i widoczne w metrykach | Limit przepustowości był niedokumentowany i niewidoczny w CloudWatch |
Podejście do łagodzenia | Skalowanie zasobów instancji lub dodawanie pamięci podręcznej | Migrowanie do rodzin instancji o wyższej przepustowości + redesign architektury DNS |
Srebro chmur AWS i chmury
Nie chcę umniejszać wpływu tego incydentu na naszych klientów. Jednak nasza zdolność do zidentyfikowania podstawowego problemu jako niespodziewanej interakcji naszego użycia z infrastrukturą AWS - a następnie znalezienie 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.
Rewelacyjny zespół operacyjny SparkPost, nasz zespół Inżynierii Niezawodności Stron (SRE) oraz nasi główni architekci techniczni współpracują z Amazonem każdego dnia. Moc infrastruktury AWS dała nam wyraźną przewagę optymalizując architekturę SparkPost dla chmury. Tak bliska współpraca z AWS w ciągu ostatnich dwóch lat nauczyła nas również wiele o uruchamianiu infrastruktury AWS i szybkim działaniu, a także mamy wsparcie głębokie wsparcie od zespołu AWS.
Gdybyśmy musieli obejść podobne ograniczenie w tradycyjnym modelu centrum danych, coś takiego mogłoby zająć dni lub nawet tygodnie, aby w pełni rozwiązać. Ta zwinność i szybkość reakcji to tylko dwa powody, dla których postawiliśmy naszą firmę na chmurze i AWS. Razem, rodzaj ekspertyzy chmurowej, którą dzielą nasze firmy, trudno znaleźć. Amazon był dla nas świetnym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co osiągnęliśmy z infrastrukturą AWS.
SparkPost to pierwsza usługa dostarczania maili, która została zbudowana dla chmury od samego początku. To podejście natywne dla chmury jest fundamentalne dla tego, jak projektujemy nasze API dla infrastruktury chmurowej, zapewniając skalowalność i niezawodność dla programistów. Wysyłamy więcej maili z prawdziwej platformy chmurowej niż ktokolwiek inny, a czasami oznacza to wejście na nieodkrytą ziemię. To fundamentalna prawda informatyki, że nie wiesz, jakie wyzwania występują w skali, dopóki się z nimi nie zmierzysz. Napotkaliśmy jedno w AWS, ale nasza szybka reakcja to świetny przykład elastyczności, jaką oferuje chmura. To również nasze zobowiązanie wobec naszych klientów.
Czy budujesz własną infrastrukturę na AWS, czy jesteś klientem SparkPost, który korzysta z naszej, mam nadzieję, że to wyjaśnienie tego, co wydarzyło się w ubiegły piątek i jak to rozwiązaliśmy, było przydatne.
Nie chcę umniejszać wpływu tego incydentu na naszych klientów. Jednak nasza zdolność do zidentyfikowania podstawowego problemu jako niespodziewanej interakcji naszego użycia z infrastrukturą AWS - a następnie znalezienie 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.
Rewelacyjny zespół operacyjny SparkPost, nasz zespół Inżynierii Niezawodności Stron (SRE) oraz nasi główni architekci techniczni współpracują z Amazonem każdego dnia. Moc infrastruktury AWS dała nam wyraźną przewagę optymalizując architekturę SparkPost dla chmury. Tak bliska współpraca z AWS w ciągu ostatnich dwóch lat nauczyła nas również wiele o uruchamianiu infrastruktury AWS i szybkim działaniu, a także mamy wsparcie głębokie wsparcie od zespołu AWS.
Gdybyśmy musieli obejść podobne ograniczenie w tradycyjnym modelu centrum danych, coś takiego mogłoby zająć dni lub nawet tygodnie, aby w pełni rozwiązać. Ta zwinność i szybkość reakcji to tylko dwa powody, dla których postawiliśmy naszą firmę na chmurze i AWS. Razem, rodzaj ekspertyzy chmurowej, którą dzielą nasze firmy, trudno znaleźć. Amazon był dla nas świetnym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co osiągnęliśmy z infrastrukturą AWS.
SparkPost to pierwsza usługa dostarczania maili, która została zbudowana dla chmury od samego początku. To podejście natywne dla chmury jest fundamentalne dla tego, jak projektujemy nasze API dla infrastruktury chmurowej, zapewniając skalowalność i niezawodność dla programistów. Wysyłamy więcej maili z prawdziwej platformy chmurowej niż ktokolwiek inny, a czasami oznacza to wejście na nieodkrytą ziemię. To fundamentalna prawda informatyki, że nie wiesz, jakie wyzwania występują w skali, dopóki się z nimi nie zmierzysz. Napotkaliśmy jedno w AWS, ale nasza szybka reakcja to świetny przykład elastyczności, jaką oferuje chmura. To również nasze zobowiązanie wobec naszych klientów.
Czy budujesz własną infrastrukturę na AWS, czy jesteś klientem SparkPost, który korzysta z naszej, mam nadzieję, że to wyjaśnienie tego, co wydarzyło się w ubiegły piątek i jak to rozwiązaliśmy, było przydatne.
Nie chcę umniejszać wpływu tego incydentu na naszych klientów. Jednak nasza zdolność do zidentyfikowania podstawowego problemu jako niespodziewanej interakcji naszego użycia z infrastrukturą AWS - a następnie znalezienie 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.
Rewelacyjny zespół operacyjny SparkPost, nasz zespół Inżynierii Niezawodności Stron (SRE) oraz nasi główni architekci techniczni współpracują z Amazonem każdego dnia. Moc infrastruktury AWS dała nam wyraźną przewagę optymalizując architekturę SparkPost dla chmury. Tak bliska współpraca z AWS w ciągu ostatnich dwóch lat nauczyła nas również wiele o uruchamianiu infrastruktury AWS i szybkim działaniu, a także mamy wsparcie głębokie wsparcie od zespołu AWS.
Gdybyśmy musieli obejść podobne ograniczenie w tradycyjnym modelu centrum danych, coś takiego mogłoby zająć dni lub nawet tygodnie, aby w pełni rozwiązać. Ta zwinność i szybkość reakcji to tylko dwa powody, dla których postawiliśmy naszą firmę na chmurze i AWS. Razem, rodzaj ekspertyzy chmurowej, którą dzielą nasze firmy, trudno znaleźć. Amazon był dla nas świetnym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co osiągnęliśmy z infrastrukturą AWS.
SparkPost to pierwsza usługa dostarczania maili, która została zbudowana dla chmury od samego początku. To podejście natywne dla chmury jest fundamentalne dla tego, jak projektujemy nasze API dla infrastruktury chmurowej, zapewniając skalowalność i niezawodność dla programistów. Wysyłamy więcej maili z prawdziwej platformy chmurowej niż ktokolwiek inny, a czasami oznacza to wejście na nieodkrytą ziemię. To fundamentalna prawda informatyki, że nie wiesz, jakie wyzwania występują w skali, dopóki się z nimi nie zmierzysz. Napotkaliśmy jedno w AWS, ale nasza szybka reakcja to świetny przykład elastyczności, jaką oferuje chmura. To również nasze zobowiązanie wobec naszych klientów.
Czy budujesz własną infrastrukturę na AWS, czy jesteś klientem SparkPost, który korzysta z naszej, mam nadzieję, że to wyjaśnienie tego, co wydarzyło się w ubiegły piątek i jak to rozwiązaliśmy, było przydatne.
