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.
Jak śledziliśmy nietypowe awarie DNS w AWS
Opracowaliśmy SparkPost wokół idei, że usługa w chmurze, taka jak nasza, sama musi być natywna dla chmury. To nie jest tylko poza. To nasza architektura chmury jest podstawą 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 zaoferować naszym klientom gwarancje poziomu usług i szybkości, które nie mają sobie równych w branży.
Jednak nie udajemy, że nigdy nie zmagamy się z nieoczekiwanymi błędami czy ograniczeniami dostępnej technologii. Coś takiego przytrafiło się w zeszły piątek i ten incydent doprowadził do przerywanej powolności naszej usługi i opóźnień w dostarczaniu dla niektórych naszych klientów.
Chcę najpierw powiedzieć, że problem został rozwiązany tego samego dnia. Ponadto, żadne e-maile ani powiązane dane nie zostały utracone. Jednakże, jeśli dostarczanie Twoich e-maili zostało spowolnione z powodu tego problemu, przyjmij moje przeprosiny (w rzeczywistości przeprosiny od całego naszego zespołu). Ten incydent wzmocnił znaczenie posiadania kompleksowych strategii backupowych - niezależnie od tego, czy używasz kopii zapasowych baz danych PostgreSQL czy innych metod ochrony danych, aby zapewnić ciągłość działania podczas wyzwań infrastrukturalnych. Wiemy, że na nas liczysz, i to frustrujące, gdy nie działamy na poziomie, jakiego się spodziewasz.
Niektóre firmy są skłonne zamiatać pod dywan problemy, takie jak degradacja usługi, i liczyć, że nikt nie zauważy. Mogłeś doświadczyć tego z usługami, których używałeś w przeszłości. Wiem, że ja tak miałem. Ale to nie jest sposób, w jaki lubimy prowadzić interesy.
Chciałem napisać o tym incydencie z innego powodu: nauczyliśmy się czegoś naprawdę interesującego i cennego na temat naszej architektury chmury AWS. Zespoły budujące inne usługi w chmurze mogą być zainteresowane poznaniem tego.
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ę osładzać wpływu tego incydentu na naszych klientów. Jednak nasza zdolność do zidentyfikowania podstawowego problemu jako nieoczekiwana interakcja naszego przypadku użycia z infrastrukturą AWS — a następnie znalezienia rozwiązania tego problemu w bardzo krótkim czasie — ma dużo wspólnego z tym, jak zbudowaliśmy SparkPost i naszym świetnym związkiem z zespołem Amazona.
Wspaniałe zespoły operacyjne SparkPost, nasz zespół Site Reliability Engineering (SRE) i nasi główni architekci techniczni pracują z Amazonem każdego dnia. Mocne strony infrastruktury AWS dały nam realną przewagę w optymalizacji architektury SparkPost dla chmury. Współpracując tak blisko z AWS przez ostatnie dwa lata, nauczyliśmy się również wiele o szybkim uruchamianiu infrastruktury AWS, a także korzystamy z głębokiego wsparcia zespołu AWS.
Gdybyśmy musieli obejść podobne ograniczenie w tradycyjnym modelu centrum danych, coś takiego mogłoby zająć dni lub nawet tygodnie do pełnego rozwiązania. Ta zwinność i reaktywność to tylko dwa z powodów, dla których postawiliśmy nasz biznes na chmurze i AWS. Razem dzielimy rodzaj ekspertizy chmurowej, którą trudno znaleźć. Amazon był dla nas świetnym partnerem biznesowym i jesteśmy naprawdę dumni z tego, co zrobiliśmy z zestawem AWS.
SparkPost to pierwsza usługa dostarczania e-maili, która została zbudowana dla chmury od samego początku. To natywne podejście do chmury jest kluczowe dla tego, jak projektujemy nasze e-mail API dla infrastruktury chmurowej, zapewniając skalowalność i niezawodność dla deweloperów. Wysyłamy więcej e-maili z prawdziwej platformy chmurowej niż ktokolwiek inny, a czasami oznacza to wchodzenie na niezbadane terytoria. To fundamentalna prawda informatyki, że nie wiadomo, jakie wyzwania wystąpią na skalę, dopóki się z nimi nie zmierzysz. Znaleźliśmy jedno na AWS, ale nasza szybka reakcja jest świetnym przykładem elastyczności, jaką umożliwia chmura. To także nasze zobowiązanie wobec naszych 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 stało się w zeszły piątek i jak to rozwiązaliśmy, było użyteczne.
