Bagaimana Kami Melacak Kegagalan DNS yang Tidak Biasa di AWS

Kami telah membangun SparkPost berdasarkan ide bahwa layanan cloud seperti milik kami harus bersifat cloud-native itu sendiri. Itu bukan sekadar berpura-pura. Ini adalah arsitektur cloud kami yang menjadi dasar dari skala, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas-kualitas itu adalah alasan utama kami membangun infrastruktur kami di atas Amazon Web Services (AWS)—dan itulah mengapa kami dapat menawarkan jaminan tingkat layanan dan tingkat lonjakan yang tidak tertandingi oleh siapa pun di bisnis ini.

Tetapi kami tidak berpura-pura bahwa kami tidak pernah menghadapi tantangan oleh bug yang tidak terduga atau batasan teknologi yang tersedia. Kami mengalami sesuatu seperti ini Jumat lalu, dan kejadian itu menyebabkan perlambatan yang tidak konsisten dalam layanan kami dan keterlambatan pengiriman bagi beberapa pelanggan kami.

Pertama-tama, izinkan saya mengatakan bahwa masalah tersebut 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, mohon terima permohonan maaf saya (sebenarnya, permohonan maaf dari seluruh tim kami). Kami tahu Anda menggantungkan harapan kepada kami, dan itu sangat mengecewakan ketika kami tidak dapat memenuhi harapan Anda.

Beberapa perusahaan tergoda untuk menyaput isu seperti penurunan layanan di bawah karpet dan berharap tidak ada yang menyadarinya. Anda mungkin telah mengalami hal itu dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya pernah. Tetapi itu bukan cara kami berbisnis.

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

TL;DR

Kami menemui batasan praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk cluster DNS utama kami. Menyusun instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya berjalan seperti yang Anda harapkan, tetapi terkadang model perangkat keras tradisional tidak berlaku. Itu terutama benar dalam kasus penggunaan yang tidak biasa di mana batasan agregat dapat berperan—dan ada saat-saat Anda menghadapi skenario tersebut tanpa peringatan.

Kami mencapai batas semacam itu pada hari Jumat ketika volume query DNS kami menciptakan pola penggunaan jaringan yang tidak dipersiapkan oleh jenis instance kami. Namun, karena batas itu tidak jelas dari dokumen atau metrik standar yang tersedia, kami tidak tahu bahwa kami telah mencapainya. Apa yang kami amati adalah tingkat kegagalan DNS yang sangat tinggi, yang pada gilirannya menyebabkan penundaan yang tidak konsisten di berbagai titik dalam arsitektur kami.

Menggali Lebih Dalam ke DNS

Mengapa penggunaan DNS kami istimewa? Nah, itu banyak berkaitan dengan cara email bekerja, dibandingkan dengan model konten untuk mana AWS pada awalnya dirancang. Pengiriman konten berbasis web sangat bergantung pada apa yang mungkin dianggap sebagai skenario inbound “pull” klasik: seorang klien meminta data, baik itu HTML, streaming video, atau hal lainnya, dari cloud. Namun kasus penggunaan untuk penyedia layanan pesan seperti SparkPost adalah pengecualian dari skenario AWS yang biasa. Dalam hal ini, kami melakukan banyak dorongan lalu lintas keluar: secara spesifik, email (dan jenis pesan lainnya seperti SMS atau notifikasi dorong seluler). Dan lalu lintas gaya dorong itu sangat bergantung pada DNS.

Jika Anda akrab dengan DNS, Anda mungkin tahu bahwa itu umumnya adalah data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda harus terlebih dahulu bertanya di mana halaman itu bisa ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.

Email, bagaimanapun, sangat bergantung pada DNS untuk mencari domain pengiriman—misalnya, SparkPost mengirimkan banyak miliaran email ke lebih dari 1 juta domain unik setiap bulan. Untuk setiap email yang kami kirim, kami harus melakukan minimal dua pencarian DNS, dan penggunaan catatan DNS “txt” untuk teknologi anti-phishing seperti SPF dan DKIM berarti DNS juga diperlukan untuk menerima email. Tambahkan pada itu penggunaan kami yang lebih tradisional terhadap layanan API AWS untuk aplikasi kami, dan sulit untuk membesar-besarkan seberapa penting DNS bagi infrastruktur kami.

Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan keluar kami yang terus tumbuh menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan agregat pada jenis instance yang sebaliknya tampak memiliki sumber daya yang cukup untuk melayani beban tersebut. Dan seperti yang ditunjukkan oleh serangan denial-of-service di infrastruktur DNS Dyn tahun lalu, ketika DNS gagal, semuanya gagal. (Itu adalah sesuatu yang sudah diketahui dengan sangat menyakitkan oleh siapa pun yang membangun sistem yang bergantung pada DNS.)

Masalah DNS mendadak memicu respons dari tim operasi dan rekayasa keandalan kami untuk mengidentifikasi masalahnya. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan pada sisi operasi AWS. Bekerja sama, kami mengidentifikasi penyebab dan solusi. Kami menerapkan kluster nameserver kapasitas lebih besar dengan fokus yang lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa melanggar batas throughput. Untungnya, karena semua ini berada di dalam AWS, kami dapat segera memutar instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS kembali berperilaku normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan keluar) kembali ke jalurnya.

Untuk mengurangi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih melindungi komponen inti kami dari dampak pertemuan dengan ambang batas yang tidak terduga. Kami juga bekerja sama dengan tim Amazon untuk menentukan model pemantauan yang sesuai yang akan memberi kami peringatan yang memadai untuk menghindari kejadian serupa sebelum berdampak pada pelanggan kami.

AWS dan Sisi Positif Cloud

Saya tidak ingin menyembunyikan dampak kejadian ini pada pelanggan kami. Namun, kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi yang tidak terduga dari kasus penggunaan kami dengan infrastruktur AWS—dan kemudian menemukan solusi dengan sangat cepat—banyak berkaitan dengan bagaimana kami membangun SparkPost, dan hubungan baik kami dengan tim Amazon.

Korps operasi SparkPost yang luar biasa, tim Site Reliability Engineering (SRE) kami, dan arsitek teknis utama kami bekerja sama dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keuntungan nyata mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja begitu dekat dengan AWS selama dua tahun terakhir juga telah mengajari kami banyak hal tentang menyiapkan infrastruktur AWS dan bergerak dengan cepat, dan kami juga mendapat manfaat dari dukungan mendalam dari tim AWS.

Jika kami harus mengatasi batasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya diselesaikan. Kelincahan dan responsivitas itu hanyalah dua dari alasan mengapa kami menempatkan bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang kami bagi bersama sangat sulit ditemukan. Amazon telah menjadi mitra bisnis yang hebat bagi kami, dan kami sangat bangga dengan apa yang telah kami lakukan dengan tumpukan AWS.

SparkPost adalah layanan pengiriman email pertama yang dibangun untuk cloud sejak awal. Kami mengirim lebih banyak email dari platform cloud sejati daripada siapa pun, dan terkadang itu berarti memasuki wilayah yang belum dijelajahi. Ini adalah kebenaran fundamental ilmu komputer bahwa Anda tidak tahu tantangan apa yang muncul pada skala hingga Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh yang bagus dari fleksibilitas yang dimungkinkan oleh cloud. Itu juga adalah komitmen kami kepada pelanggan kami.

Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau sebagai pelanggan SparkPost yang memanfaatkan layanan kami, saya harap penjelasan tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, berguna.