Kami menemui batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Menentukan ukuran instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya berjalan seperti yang Anda harapkan, tetapi terkadang model perangkat keras tradisional itu tidak berlaku.
Business in a box.
Temukan solusi kami.
Bicaralah kepada tim penjualan kami
Bagaimana Kami Melacak Kegagalan DNS yang Tidak Biasa di AWS
Kami telah membangun SparkPost di sekitar ide bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan hanya sekadar klaim. Arsitektur cloud kami yang mendukung skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas-kualitas tersebut adalah alasan utama kami membangun infrastruktur kami di atas Amazon Web Services (AWS)—dan itulah mengapa kami dapat menawarkan kepada pelanggan kami jaminan tingkat layanan dan tingkat lonjakan yang tak tertandingi oleh siapa pun dalam bisnis ini.
Tetapi kami tidak berpura-pura bahwa kami tidak pernah menghadapi tantangan dari bug yang tidak terduga atau batasan teknologi yang tersedia. Kami mengalami sesuatu seperti ini Jumat lalu, dan insiden tersebut menyebabkan kelambatan sementara dalam layanan kami dan penundaan pengiriman untuk beberapa pelanggan kami.
Pertama izinkan saya mengatakan, masalah tersebut telah diselesaikan pada hari yang sama. Selain itu, tidak ada email atau data terkait yang hilang. Namun, jika pengiriman email Anda terlambat karena masalah ini, mohon maafkan saya (bahkan, mohon maaf dari seluruh tim kami). Kami tahu Anda mengandalkan kami, dan sangat frustrasi ketika kami tidak beroperasi pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk menyembunyikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikan. Anda mungkin telah mengalaminya dengan layanan yang pernah Anda gunakan di masa lalu. Saya tahu saya pernah. Tapi itu bukan cara kami berbisnis.
Saya ingin menulis tentang insiden ini untuk alasan lain juga: kami mempelajari sesuatu yang sangat menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mempelajarinya.
TL;DR
Mendalami DNS
Mengapa penggunaan DNS kami istimewa? Nah, ini banyak berkaitan dengan cara kerja email, dibandingkan dengan model konten untuk mana AWS awalnya dirancang. Pengiriman konten berbasis web sangat memanfaatkan apa yang mungkin dianggap skenario "tarik" inbound klasik: sebuah klien meminta data, baik itu HTML, streaming video, atau lainnya, dari cloud. Namun, kasus penggunaan untuk penyedia layanan pesan seperti SparkPost adalah pengecualian terhadap skenario AWS yang biasa. Dalam kasus kami, kami melakukan banyak mendorong lalu lintas keluar: khususnya, email (dan jenis pesan lainnya seperti SMS atau pemberitahuan dorong seluler). Dan lalu lintas gaya dorong itu sangat bergantung pada DNS.
Jika Anda terbiasa dengan DNS, Anda mungkin tahu bahwa umumnya data ini cukup ringan. Untuk meminta halaman HTML tertentu, Anda pertama-tama harus bertanya di mana halaman itu bisa ditemukan di Internet, tetapi permintaan itu adalah sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, membuat penggunaan DNS yang sangat berat untuk mencari domain pengiriman—misalnya, SparkPost mengirimkan banyak miliar 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 rekaman DNS "txt" untuk teknologi anti-phishing seperti SPF dan DKIM berarti DNS juga diperlukan untuk menerima email. Tambahkan ke penggunaan tradisional kami terhadap layanan API AWS untuk aplikasi kami, dan sulit untuk berlebihan seberapa pentingnya DNS bagi infrastruktur kami.
Semua ini berarti kami mengalami kondisi yang tidak biasa di mana volume pesan keluar yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan agregat pada jenis instance yang sepertinya memiliki sumber daya yang cukup untuk melayani beban tersebut. Dan seperti yang serangan denial-of-service pada infrastruktur Dyn DNS tahun lalu tunjukkan, ketika DNS rusak, semuanya rusak. (Itulah sesuatu yang sudah diketahui oleh siapa saja yang membangun sistem yang bergantung pada DNS dengan sangat baik.)
Masalah DNS mendadak memicu respons oleh tim operasi dan rekayasa keandalan kami untuk mengidentifikasi masalahnya. Mereka bekerjasama dengan mitra kami di Amazon untuk meningkatkan di sisi operasi AWS. Bekerja sama, kami mengidentifikasi penyebab dan solusi. Kami menyebarkan kluster dari nameserver berkapasitas lebih besar dengan fokus yang lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa batas throughput yang terlampaui. Untungnya, karena semuanya berada dalam AWS, kami dapat memutus instance baru dan bahkan mengubah ukuran instance yang sudah ada dengan sangat cepat. DNS kembali berperilaku normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan keluar) kembali ke jalur yang benar.
Untuk mengurangi masalah khusus ini di masa depan, kami juga membuat perubahan arsitektur DNS untuk lebih mengisolasi komponen inti kami dari dampak pertemuan dengan ambang batas serupa yang tidak terduga. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk menghadang insiden serupa sebelum itu mempengaruhi salah satu pelanggan kami.
AWS dan Lining Perak Cloud
Saya tidak ingin menggambarkan dampak kejadian ini pada pelanggan kami dengan cara yang berlebihan. Namun, kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi tak terduga dari penggunaan kasus kami dengan infrastruktur AWS—dan kemudian menemukan resolusi dalam waktu yang sangat singkat—banyak berkaitan dengan cara kami membangun SparkPost, dan hubungan yang hebat dengan tim Amazon.
Korps operasi unggulan SparkPost, tim Site Reliability Engineering (SRE) kami, dan arsitek teknis utama kami bekerja dengan Amazon setiap hari. Kekuatan infrastruktur AWS memberikan kami keuntungan nyata mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja begitu dekat dengan AWS selama dua tahun terakhir juga mengajarkan banyak hal kepada kami tentang memulai infrastruktur AWS dan beroperasi dengan cepat, dan kami juga mendapat manfaat dari dukungan mendalam dari tim AWS.
Jika kami harus menangani keterbatasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk benar-benar terselesaikan. Ketangkasan dan responsivitas itulah yang menjadi salah satu alasan kami mendasari bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang dibagikan perusahaan kami sulit ditemukan. Amazon telah menjadi mitra bisnis yang hebat bagi kami, dan kami sangat bangga dengan apa yang telah kami lakukan dengan AWS stack.
SparkPost adalah layanan pengiriman email pertama yang dibangun untuk cloud sejak awal. Kami mengirimkan lebih banyak email dari platform cloud sejati dibandingkan siapa pun, dan terkadang itu berarti memasuki wilayah yang belum dipetakan. Ini adalah kebenaran mendasar dari ilmu komputer bahwa Anda tidak tahu tantangan apa yang terjadi dalam skala besar sampai menghadapinya. Kami menemukan salah satunya di AWS, tetapi respons cepat kami adalah contoh hebat dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga merupakan komitmen kami kepada pelanggan kami.
Entah Anda membangun infrastruktur Anda sendiri di AWS, atau pelanggan SparkPost yang memanfaatkan infrastruktur kami, saya harap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, telah berguna.
