Natknęliśmy się na nieudokumentowane praktyczne limity instancji EC2, których używaliśmy dla naszego głównego klastra DNS. Dobieranie instancji chmurowych w oparciu o tradycyjne specyfikacje (procesor, pamięć itp.) zazwyczaj działa tak, jakbyś się tego spodziewał, ale czasami tradycyjny model sprzętowy nie ma zastosowania.
Business in a box.
Odkryj nasze rozwiązania.
Porozmawiaj z naszym zespołem sprzedaży
Jak śledziliśmy nietypowe awarie DNS w AWS
Zbudowaliśmy SparkPost wokół idei, że usługa chmurowa taka jak nasza musi być sama w sobie cloud-native. To nie jest tylko pozowanie. To nasza architektura chmurowa, która pozwala na skalowalność, elastyczność i niezawodność, które są kluczowymi aspektami usługi SparkPost. Te cechy to główne powody, dla których zbudowaliśmy naszą infrastrukturę na Amazon Web Services (AWS)—i dlatego możemy zaoferować naszym klientom gwarancje poziomu obsługi i przepustowości, które nie mają sobie równych w branży.
Ale nie udajemy, że nigdy nie napotykamy nieoczekiwanych błędów lub ograniczeń dostępnej technologii. Napotkaliśmy coś takiego w ostatni piątek i ten incydent doprowadził do okresowej powolności naszej usługi i opóźnień w dostarczaniu wiadomości dla niektórych naszych klientów.
Najpierw chciałbym powiedzieć, że problem został rozwiązany tego samego dnia. Co więcej, żadna wiadomość e-mail ani powiązane dane nie zostały utracone. Jednak jeśli dostarczanie Twoich e-maili zostało opóźnione z powodu tego problemu, proszę przyjąć moje przeprosiny (w rzeczywistości, przeprosiny od całego naszego zespołu). Wiemy, że na nas polegasz i to frustrujące, gdy nie działamy na poziomie, jakiego oczekujesz.
Niektóre firmy kuszą się, by zamieść problemy takie jak degradacja usługi pod dywan i mieć nadzieję, że nikt tego nie zauważy. Być może spotkałeś się z tym w usługach, z których korzystałeś w przeszłości. Wiem, że ja tak. Ale to nie jest sposób, w jaki lubimy prowadzić biznes.
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, aby się o tym dowiedzieć.
TL;DR
Głębiej w DNS
Dlaczego nasze użycie DNS jest wyjątkowe? Cóż, ma to wiele wspólnego ze sposobem działania poczty e-mail, w porównaniu do modelu treści, dla którego AWS został pierwotnie zaprojektowany. Webowe dostarczanie treści intensywnie wykorzystuje to, co można uznać za klasyczne scenariusze „ściągania” przychodzącego: klient żąda danych, czy to HTML, strumieni wideo, czy czegokolwiek innego, z chmury. Ale przypadki użycia dla dostawców usług wiadomości, jak SparkPost, są wyjątkiem od zwykłego scenariusza AWS. W naszym przypadku generujemy dużo wychodzącego ruchu: konkretnie, e-mail (i innych typów wiadomości, jak SMS czy powiadomienia push na urządzenia mobilne). I ten styl ruchu oparty na pchaniu silnie polega na DNS.
Jeśli znasz DNS, możesz wiedzieć, że jest to zazwyczaj dość lekkie dane. Aby zażądać danej strony HTML, najpierw musisz zapytać, gdzie tę stronę można znaleźć w Internecie, ale to żądanie jest ułamkiem wielkości treści, którą pobierasz.
Poczta e-mail jednakże, wyjątkowo intensywnie korzysta z DNS do wyszukiwania domen dostarczenia — na przykład, SparkPost wysyła wiele miliardów e-maili do ponad 1 miliona unikalnych domen każdego miesiąca. Dla każdej poczty, którą dostarczamy, musimy wykonać co najmniej dwa wyszukiwania DNS, a wykorzystanie rekordów DNS „txt” dla technologii anty-phishing, jak SPF i DKIM, oznacza, że DNS także jest wymagany do odbioru poczty. Dodaj do tego bardziej tradycyjne użycie usług API AWS dla naszych aplikacji, i trudno jest przesadzić, jak ważne DNS jest dla naszej infrastruktury.
Wszystko to oznacza, że natrafiliśmy na nietypowy stan, w którym rosnąca ilość wychodzących wiadomości stworzyła objętość ruchu DNS, która osiągnęła sumaryczny limit przepustowości sieci na typach instancji, które wydawały się mieć wystarczające zasoby do obsługi tego obciążenia. I jak ataki typu odmowa usługi na infrastrukturę Dyn DNS w zeszłym roku pokazały, kiedy DNS się psuje, wszystko się psuje. (To coś, co każdy, kto tworzy systemy zależne od DNS, już dobrze wie.)
Nagłe problemy z DNS wywołały reakcję naszych zespołów do spraw operacyjności i niezawodności inżynierskiej w celu zidentyfikowania problemu. Współpracowali z naszymi partnerami w Amazonie, aby eskalować po stronie 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 skupieniem na pojemność sieciową, które mogłyby zaspokoić nasze potrzeby DNS bez osiągania czerwonych linii dla przepustowości. Na szczęście, ponieważ wszystko to odbywało się w AWS, mogliśmy szybko uruchomić nowe instancje, a nawet zmienić rozmiar istniejących instancji. DNS wznowił normalne działanie, błędy wyszukiwania ustały, i my (oraz dostarczanie wiadomości wychodzących) wróciliśmy na właściwe tory.
Aby złagodzić to konkretne zagadnienie w przyszłości, dokonujemy również zmian w architekturze DNS, aby lepiej izolować nasze główne komponenty od wpływu kontaktów z podobnymi, nieoczekiwanymi progami. Współpracujemy także z zespołem Amazon, aby określić odpowiednie modele monitorowania, które dadzą nam wystarczające ostrzeżenie, aby zapobiec podobnym zdarzeniom, zanim wpłyną na któregokolwiek z naszych klientów.
AWS i srebrna podszewka chmury
Nie chcę bagatelizować 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 znalezienie rozwiązania w bardzo krótkim czasie — ma wiele wspólnego z tym, jak zbudowaliśmy SparkPost i naszym świetnym relacjami z zespołem Amazon.
Specjalne operacje SparkPost, nasz zespół inżynierii niezawodności witryny (SRE) i nasi główni architekci techniczni współpracują z Amazon każdego dnia. Mocne strony infrastruktury AWS dały nam prawdziwą przewagę w optymalizacji architektury SparkPost dla chmury. Współpraca z AWS w ciągu ostatnich dwóch lat nauczyła nas również wiele o uruchamianiu infrastruktury AWS i pracy w szybkim tempie, a my również korzystamy z głębokiego wsparcia zespołu AWS.
Gdybyśmy musieli obejść podobne ograniczenie w modelu tradycyjnego centrum danych, coś takiego mogłoby potrwać dni lub nawet tygodnie, aby całkowicie rozwiązać. Ta zwinność i reaktywność to tylko dwa z powodów, dla których postawiliśmy nasz biznes na chmurze i AWS. Razem, rodzaj wiedzy na temat chmury, którą dzielą się nasze firmy, jest trudny do znalezienia. Amazon jest dla nas świetnym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co zrobiliśmy ze stosem AWS.
SparkPost jest pierwszą usługą dostarczania e-maili, która została zbudowana dla chmury od samego początku. Wysyłamy więcej wiadomości e-mail z prawdziwej platformy chmurowej niż ktokolwiek inny, a czasami oznacza to wejście na nieznane terytoria. To fundamentalna prawda informatyki, że nie wiesz, jakie wyzwania pojawią się na dużą skalę, dopóki na nie nie natrafisz. Znaleźliśmy jeden na AWS, ale nasza szybka reakcja jest doskonałym przykładem elastyczności, którą umożliwia chmura. To także nasze zobowiązanie wobec klientów.
Niezależnie od tego, czy budujesz własną infrastrukturę na AWS, czy jesteś klientem SparkPost, który korzysta z naszej, mam nadzieję, że to wyjaśnienie, co się wydarzyło w zeszły piątek i jak to rozwiązaliśmy, było przydatne.
