Dzień, w którym nasz DNS osiągnął nieudokumentowany limit w AWS
Ptak
7 lut 2017
Inżynieria
1 min read
Kluczowe Wnioski
SparkPost napotkał nieudokumentowany limit przepustowości sieci na konkretnym typie instancji AWS EC2, który zasilał jego główny klaster DNS.
Tradycyjne określanie wielkości instancji (CPU, RAM, dysk) nie ujawniło tego wąskiego gardła, ponieważ problem był związany z zagregowanym ruchem sieciowym DNS, a nie brakami zasobów.
Użycie DNS dla e-maili wychodzących o dużej objętości jest niezwykle intensywne: SparkPost generuje miliony zapytań DNS do routingu domen, uwierzytelniania (SPF/DKIM) oraz interakcji z API AWS.
Awaria DNS nie wynikała z wadliwych odpowiedzi DNS — raczej przekroczono cicho progi pojemności sieci na poziomie instancji, co spowodowało powszechne awarie zapytań.
Ponieważ AWS nie dokumentuje wyraźnie tych ukrytych limitów sieciowych, diagnoza problemu wymagała głębokiej współpracy między zespołem SRE SparkPost i inżynierami AWS.
Zespół rozwiązał problem poprzez migrację usług DNS do większych typów instancji z większym pasmem sieci i przeprojektowanie części architektury DNS dla lepszej izolacji i odtwarzania awaryjnego.
Żadne dane ani wiadomości klientów nie zostały utracone, ale wydarzenie podkreśliło, jak architektury cloud-native mogą napotkać nieoczekiwane limity w skali — i jak szybko można je naprawić dzięki elastyczności AWS.
Q&A Highlights
Co się stało?
DNS klaster SparkPost napotkał niespodziewany limit przepustowości sieci AWS, co spowodowało sporadyczne niepowodzenia w odnajdywaniu DNS — co opóźniło dostarczanie wiadomości email.
Dlaczego DNS w ogóle się zepsuł?
DNS jest niezwykle zależny od zewnętrznych wiadomości e-mail. Każde wysyłanie wymaga wielu sprawdzeń (MX, TXT, SPF, DKIM), więc wysoki wolumen wysyłania = ogromny ruch DNS.
Ten wzorzec ruchu przekroczył nieudokumentowany limit na typie instancji EC2, który hostuje serwery nazw.
Jak DNS dla email różni się od aplikacji webowych?
Web apps głównie pobierają treści (klienci żądają danych).
Usługi dostarczania e-maili wysyłają ruch, co powoduje znacznie więcej zapytań DNS — często miliardy miesięcznie.
E-mail zależy od DNS do routingu, walidacji bezpieczeństwa i przełączania awaryjnego.
Jak objawiła się awaria?
Żądania DNS zaczęły zanikać lub kończyć się czasem oczekiwania
Kolejki dostawcze się zapełniły
Opóźnienie wzrosło w niektórych częściach systemu
Nic nie zostało utracone — tylko opóźnione.
Dlaczego było to trudne do zdiagnozowania?
Limit nie był udokumentowany
Monitorowanie AWS nie wskazywało jednoznacznie na wąskie gardło
Wszystkie tradycyjne metryki (CPU, RAM, dysk) wyglądały normalnie
Problem pojawiał się tylko pod określonym, dużym obciążeniem ruchem DNS.
Jak SparkPost to naprawił?
Ulepszono do typów instancji EC2 z wyższymi limitami przepustowości sieci
Przeprojektowano klastry DNS, aby były bardziej odporne na skoki ruchu
Współpracowano z AWS w celu zidentyfikowania lepszych wzorców sygnałów/powiadomień, aby szybciej to wychwycić
Czy dane klienta lub poczta zostały utracone?
Nie — tylko dostawa się spowolniła. Gdy DNS się ustabilizował, cała poczta wznowiła normalną dostawę.
Jaka jest szersza lekcja?
Nawet w chmurze możesz napotkać niewidoczne ograniczenia skalowania — ale projekty oparte na chmurze dają Ci elastyczność do szybkiego odzyskania.
Elastyczność, współpraca z AWS i silne praktyki SRE umożliwiają szybką regenerację.
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.
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.
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
Napotkaliśmy nieudokumentowane praktyczne ograniczenia instancji EC2, których używaliśmy do naszego głównego klastra DNS. Dobór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa zgodnie z oczekiwaniami, ale czasami ten tradycyjny model sprzętowy nie ma zastosowania. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, gdzie mogą mieć znaczenie ograniczenia łączne — i zdarzają się momenty, gdy natykasz się na te scenariusze bez ostrzeżenia.
Napomknęliśmy o takim ograniczeniu w piątek, kiedy nasza objętość zapytań DNS stworzyła wzorzec użytkowania sieci, do którego nasz typ instancji nie był przygotowany. Jednakże, ponieważ to ograniczenie nie było oczywiste z dokumentacji czy standardowych metryk dostępnych, nie wiedzieliśmy, że na nie trafimy. Zaobserwowaliśmy bardzo wysoką częstość błędów DNS, co z kolei prowadziło do przerywanych opóźnień w różnych punktach naszej architektury.
Napotkaliśmy nieudokumentowane praktyczne ograniczenia instancji EC2, których używaliśmy do naszego głównego klastra DNS. Dobór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa zgodnie z oczekiwaniami, ale czasami ten tradycyjny model sprzętowy nie ma zastosowania. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, gdzie mogą mieć znaczenie ograniczenia łączne — i zdarzają się momenty, gdy natykasz się na te scenariusze bez ostrzeżenia.
Napomknęliśmy o takim ograniczeniu w piątek, kiedy nasza objętość zapytań DNS stworzyła wzorzec użytkowania sieci, do którego nasz typ instancji nie był przygotowany. Jednakże, ponieważ to ograniczenie nie było oczywiste z dokumentacji czy standardowych metryk dostępnych, nie wiedzieliśmy, że na nie trafimy. Zaobserwowaliśmy bardzo wysoką częstość błędów DNS, co z kolei prowadziło do przerywanych opóźnień w różnych punktach naszej architektury.
Napotkaliśmy nieudokumentowane praktyczne ograniczenia instancji EC2, których używaliśmy do naszego głównego klastra DNS. Dobór instancji chmurowych na podstawie tradycyjnych specyfikacji (procesor, pamięć itp.) zazwyczaj działa zgodnie z oczekiwaniami, ale czasami ten tradycyjny model sprzętowy nie ma zastosowania. Jest to szczególnie prawdziwe w nietypowych przypadkach użycia, gdzie mogą mieć znaczenie ograniczenia łączne — i zdarzają się momenty, gdy natykasz się na te scenariusze bez ostrzeżenia.
Napomknęliśmy o takim ograniczeniu w piątek, kiedy nasza objętość zapytań DNS stworzyła wzorzec użytkowania sieci, do którego nasz typ instancji nie był przygotowany. Jednakże, ponieważ to ograniczenie nie było oczywiste z dokumentacji czy standardowych metryk dostępnych, nie wiedzieliśmy, że na nie trafimy. Zaobserwowaliśmy bardzo wysoką częstość błędów DNS, co z kolei prowadziło do przerywanych opóźnień w różnych punktach naszej architektury.
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.
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.
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.
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.
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.
