How We Tracked Down Unusual DNS Failures in AWS

We’ve built SparkPost around the idea that a cloud service like ours needs to be cloud-native itself. That’s not just posturing. It’s our cloud architecture that underpins the scalability, elasticity, and reliability that are core aspects of the SparkPost service. Those qualities are major reasons we’ve built our infrastructure atop Amazon Web Services (AWS)—and it’s why we can offer our customers service level and burst rate guarantees unmatched by anyone else in the business.

But we don’t pretend that we’re never challenged by unexpected bugs or limits of available technology. We ran into something like this last Friday, and kejadian itu led to intermittent slowness in our service and delivery delays for some of our customers.

Pertama-tama saya ingin mengatakan bahwa masalah ini telah diselesaikan pada hari yang sama. Selain itu, tidak ada email atau data terkait yang hilang. Namun, jika pengiriman email Anda melambat karena masalah ini, terimalah permintaan maaf saya (sebenarnya, permintaan maaf dari seluruh tim kami). Kami tahu Anda mengandalkan kami, dan akan membuat frustasi jika kami tidak bekerja sesuai dengan yang Anda harapkan.

Some companies are tempted to brush issues like a service degradation under the rug and hope no one notices. You may have experienced that with services you’ve used in the past. I know I have. But that’s not how we like to do business.

Saya ingin menulis tentang kejadian ini karena alasan lain: kami belajar sesuatu yang sangat menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lain mungkin tertarik untuk mempelajarinya.

TL; DR

Kami menemukan batasan praktis yang tidak terdokumentasi pada instance EC2 yang kami gunakan untuk cluster DNS utama kami. Penentuan ukuran instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya berfungsi seperti yang Anda harapkan, tetapi terkadang model perangkat keras tradisional tersebut tidak berlaku. Hal ini terutama terjadi pada kasus penggunaan yang tidak lazim, di mana batas agregat dapat berperan - dan ada kalanya Anda langsung berhadapan dengan skenario tersebut tanpa peringatan.

Kami mencapai batas tersebut pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak dipersiapkan untuk jenis instance kami. Namun, karena batas tersebut tidak terlihat jelas dalam dokumen atau metrik standar yang tersedia, kami tidak tahu bahwa kami telah mencapainya. Yang kami amati adalah tingkat kegagalan DNS yang sangat tinggi, yang pada gilirannya menyebabkan penundaan yang terputus-putus di berbagai titik dalam arsitektur kami.

Menggali lebih dalam tentang DNS

Mengapa penggunaan DNS kami istimewa? Nah, ini banyak berkaitan dengan cara kerja email, dibandingkan dengan model konten yang pada awalnya dirancang untuk AWS. Pengiriman konten berbasis web sangat memanfaatkan apa yang dapat dianggap sebagai skenario "tarikan" masuk klasik: klien meminta data, baik itu HTML, streaming video, atau apa pun, dari awan. Namun, kasus penggunaan untuk penyedia layanan pesan seperti SparkPost merupakan pengecualian dari skenario AWS pada umumnya. Dalam kasus kami, kami melakukan banyak lalu lintas push keluar: khususnya, email (dan jenis pesan lain seperti SMS atau notifikasi push seluler). Dan lalu lintas gaya push itu sangat bergantung pada DNS.

Jika Anda terbiasa dengan DNS, Anda mungkin tahu bahwa ini adalah data yang cukup ringan. Untuk meminta halaman HTML tertentu, pertama-tama Anda harus bertanya di mana halaman tersebut dapat ditemukan di Internet, tetapi permintaan tersebut adalah sebagian kecil dari ukuran konten yang Anda ambil.

Email, however, makes exceptionally heavy use of DNS to look up delivery domains—for example, SparkPost sends many billions of emails to over 1 million unique domains setiap bulan. For every email we deliver, we have to make a minimum of two DNS lookups, and the use of DNS “txt” records for anti-phishing technologies like SPF and DKIM means DNS also is required to receive mail. Add to that our more traditional use of AWS API services for our apps, and it’s hard to exaggerate how important DNS is to our infrastructure.

All of this means we ran into an unusual condition in which our growing volume of outbound messages created a DNS traffic volume that hit an aggregate network throughput limit on instance types that otherwise seemed to have sufficient resources to service that load. And as serangan penolakan layanan pada infrastruktur Dyn DNS last year demonstrated, when DNS breaks, everything breaks. (That’s something anyone who builds systems that rely on DNS already knows painfully well.)

Masalah DNS yang tiba-tiba terjadi memicu respons dari tim teknik operasi dan keandalan kami untuk mengidentifikasi masalahnya. Mereka bekerja sama dengan mitra kami di Amazon untuk melakukan eskalasi di sisi operasi AWS. Dengan bekerja sama, kami mengidentifikasi penyebab dan solusinya. Kami menggunakan sekelompok server nama berkapasitas lebih besar dengan fokus lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa mengalami masalah dalam hal throughput. Untungnya, karena semua ini ada di dalam AWS, kami dapat menjalankan instance baru dan bahkan mengubah ukuran instance yang sudah ada dengan sangat cepat. DNS kembali berjalan normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan keluar) kembali ke jalurnya.

Untuk memitigasi masalah khusus ini di masa mendatang, kami juga membuat perubahan arsitektur DNS untuk melindungi komponen inti kami dengan lebih baik dari dampak pertemuan dengan ambang batas yang serupa dan tak terduga. Kami juga bekerja sama dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberikan peringatan yang memadai untuk mencegah insiden serupa sebelum memengaruhi pelanggan kami.

AWS and the Cloud’s Silver Lining

Saya tidak ingin menutup-nutupi dampak dari insiden ini terhadap pelanggan kami. Tetapi kemampuan kami untuk mengidentifikasi masalah yang mendasarinya sebagai interaksi tak terduga dari kasus penggunaan kami dengan infrastruktur AWS-dan kemudian menemukan penyelesaiannya dalam waktu yang sangat singkat-memang sangat berkaitan dengan cara kami membangun SparkPost, dan hubungan baik kami dengan tim Amazon.

SparkPost’s superb operations corps, our Site Reliability Engineering (SRE) team, and our principal technical architects work with Amazon every day. The strengths of AWS’ infrastructure has given us a real leg up mengoptimalkan arsitektur SparkPost untuk cloud. Working so closely with AWS over the past two years also has taught us a lot about spinning up AWS infrastructure and running quickly, and we also have the benefit of deep support from the AWS team.

Jika kami harus mengatasi keterbatasan serupa dalam model pusat data tradisional, hal seperti ini dapat memakan waktu berhari-hari atau bahkan berminggu-minggu untuk menyelesaikannya. Kelincahan dan ketanggapan tersebut hanyalah dua dari sekian banyak alasan kami mempertaruhkan bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang dimiliki oleh perusahaan kami sulit didapat. Amazon telah menjadi mitra bisnis yang hebat bagi kami, dan kami sangat bangga dengan apa yang telah kami lakukan dengan AWS.

SparkPost adalah layanan pengiriman email pertama yang dibangun untuk cloud sejak awal. Kami mengirim lebih banyak email dari platform cloud yang sebenarnya daripada siapa pun, dan terkadang itu berarti memasuki wilayah yang belum dipetakan. Ini adalah kebenaran mendasar dalam ilmu komputer bahwa Anda tidak akan tahu tantangan apa yang terjadi dalam skala besar hingga Anda mengalaminya. Kami menemukannya di AWS, tetapi respons cepat kami adalah contoh yang bagus tentang fleksibilitas yang dimungkinkan oleh cloud. Hal ini juga merupakan komitmen kami kepada pelanggan.

Baik Anda sedang membangun infrastruktur Anda sendiri di AWS, atau pelanggan SparkPost yang memanfaatkan infrastruktur kami, semoga penjelasan tentang apa yang terjadi pada hari Jumat lalu, dan bagaimana kami mengatasinya, bermanfaat.