Hari Ketika DNS Kami Mencapai Batas yang Tidak Terdocumentasi di AWS
Burung
7 Feb 2017
Rekayasa
1 min read
Intisari Utama
SparkPost mengalami batas throughput jaringan yang tidak terdokumentasi pada jenis instance AWS EC2 tertentu yang menggerakkan kluster DNS utama.
Ukuran instance tradisional (CPU, RAM, disk) tidak mengungkapkan kendala ini karena masalah tersebut terkait dengan lalu lintas jaringan DNS agregat, bukan kekurangan sumber daya.
Penggunaan DNS untuk email keluar volume tinggi sangat berat: SparkPost menghasilkan jutaan pencarian DNS untuk perutean domain, authentikasi (SPF/DKIM), dan interaksi AWS API.
Kegagalan DNS tidak berasal dari respons DNS yang salah — melainkan, ambang kapasitas jaringan level instance terlampaui secara diam-diam, menyebabkan kegagalan pencarian yang meluas.
Karena AWS tidak secara eksplisit mendokumentasikan batas jaringan soft ini, diagnosis masalah memerlukan kolaborasi mendalam antara tim SRE SparkPost dan insinyur AWS.
Tim menyelesaikan masalah dengan memigrasikan layanan DNS ke jenis instance yang lebih besar dengan bandwidth jaringan lebih besar dan merancang ulang bagian dari arsitektur DNS untuk isolasi dan failover yang lebih baik.
Tidak ada data pelanggan atau pesan yang hilang, tetapi kejadian tersebut menyoroti bagaimana arsitektur cloud-native dapat mencapai batas yang tidak terduga pada skala — dan seberapa cepat mereka dapat diperbaiki dengan elastisitas AWS.
Sorotan Q&A
Apa yang terjadi?
Cluster DNS SparkPost mencapai batas throughput jaringan AWS yang tidak terduga, menyebabkan pencarian DNS gagal secara berselang — yang menunda pengiriman email.
Mengapa DNS rusak sama sekali?
DNS sangat bergantung pada dependensi untuk email keluar. Setiap pengiriman memerlukan banyak pencarian (MX, TXT, SPF, DKIM), jadi volume pengiriman tinggi = lalu lintas DNS yang besar.
Pola lalu lintas ini melebihi batas yang tidak terdokumentasi pada tipe instance EC2 yang meng-host nameservers.
Bagaimana DNS untuk email berbeda dari aplikasi web?
Web apps kebanyakan menarik konten (klien meminta data).
Layanan pengiriman Email mendorong lalu lintas, memicu jauh lebih banyak pencarian DNS — seringkali miliaran per bulan.
Email bergantung pada DNS untuk perutean, validasi keamanan, dan failover.
Bagaimana kegagalan tersebut muncul?
Permintaan DNS mulai gagal atau kedaluwarsa
Antrian pengiriman menumpuk
Latensi meningkat di beberapa bagian sistem
Tidak ada yang hilang — hanya tertunda.
Mengapa ini sulit untuk didiagnosa?
Batas tidak didokumentasikan
Pemantauan AWS tidak secara eksplisit menunjukkan hambatan
Semua metrik tradisional (CPU, RAM, disk) tampak normal
Masalah hanya muncul di bawah pola lalu lintas DNS yang spesifik dan tinggi.
Bagaimana SparkPost memperbaikinya?
Ditingkatkan ke tipe instance EC2 dengan batas throughput jaringan yang lebih tinggi
Diarsitektur ulang klaster DNS agar lebih tahan terhadap lonjakan lalu lintas agregat
Bekerja sama dengan AWS untuk mengidentifikasi pola sinyal/peringatan yang lebih baik untuk menangkap ini lebih cepat
Apakah data pelanggan atau surat hilang?
Tidak — hanya pengiriman melambat. Begitu DNS stabil, semua pengiriman surat kembali normal.
Apa pelajaran yang lebih luas?
Bahkan di cloud, Anda dapat menghadapi batasan penskalaan yang tak terlihat — tetapi desain cloud-native memberi Anda fleksibilitas untuk pulih dengan cepat.
Elastisitas, kemitraan dengan AWS, dan praktik SRE yang kuat memungkinkan pemulihan yang cepat.
Bagaimana Kami Melacak Kegagalan DNS yang Tidak Biasa di AWS
Kami telah membangun SparkPost dengan gagasan bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan sekadar kata-kata. Ini adalah arsitektur cloud kami yang mendukung skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas tersebut 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 tak tertandingi oleh siapa pun dalam bisnis ini.
Tapi kami tidak berpura-pura bahwa kami tidak pernah ditantang oleh bug yang tidak terduga atau batas teknologi yang tersedia. Kami menghadapi sesuatu seperti ini Jumat lalu, dan insiden tersebut menyebabkan kelambatan yang terputus-putus dalam layanan kami dan penundaan pengiriman bagi beberapa pelanggan kami.
Pertama, saya ingin mengatakan, masalah tersebut telah diselesaikan pada hari yang sama. Selain itu, tidak ada email atau data terkait yang hilang. Namun, jika pengiriman email Anda tertunda karena masalah ini, mohon terima permintaan maaf saya (sebenarnya, permintaan maaf dari seluruh tim kami). Insiden ini menekankan pentingnya memiliki strategi cadangan yang komprehensif - baik Anda menggunakan cadangan database PostgreSQL atau metode perlindungan data lainnya untuk memastikan kelangsungan bisnis selama tantangan infrastruktur. Kami tahu Anda mengandalkan kami, dan ini mengecewakan ketika kami tidak berkinerja pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk menyembunyikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikan. Anda mungkin telah mengalami itu dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya pernah. Namun, itu bukan cara kami menjalankan bisnis.
Saya ingin menulis tentang insiden ini untuk alasan lain juga: kami mempelajari sesuatu yang benar-benar menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahuinya.
Kami telah membangun SparkPost dengan gagasan bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan sekadar kata-kata. Ini adalah arsitektur cloud kami yang mendukung skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas tersebut 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 tak tertandingi oleh siapa pun dalam bisnis ini.
Tapi kami tidak berpura-pura bahwa kami tidak pernah ditantang oleh bug yang tidak terduga atau batas teknologi yang tersedia. Kami menghadapi sesuatu seperti ini Jumat lalu, dan insiden tersebut menyebabkan kelambatan yang terputus-putus dalam layanan kami dan penundaan pengiriman bagi beberapa pelanggan kami.
Pertama, saya ingin mengatakan, masalah tersebut telah diselesaikan pada hari yang sama. Selain itu, tidak ada email atau data terkait yang hilang. Namun, jika pengiriman email Anda tertunda karena masalah ini, mohon terima permintaan maaf saya (sebenarnya, permintaan maaf dari seluruh tim kami). Insiden ini menekankan pentingnya memiliki strategi cadangan yang komprehensif - baik Anda menggunakan cadangan database PostgreSQL atau metode perlindungan data lainnya untuk memastikan kelangsungan bisnis selama tantangan infrastruktur. Kami tahu Anda mengandalkan kami, dan ini mengecewakan ketika kami tidak berkinerja pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk menyembunyikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikan. Anda mungkin telah mengalami itu dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya pernah. Namun, itu bukan cara kami menjalankan bisnis.
Saya ingin menulis tentang insiden ini untuk alasan lain juga: kami mempelajari sesuatu yang benar-benar menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahuinya.
Kami telah membangun SparkPost dengan gagasan bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan sekadar kata-kata. Ini adalah arsitektur cloud kami yang mendukung skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas tersebut 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 tak tertandingi oleh siapa pun dalam bisnis ini.
Tapi kami tidak berpura-pura bahwa kami tidak pernah ditantang oleh bug yang tidak terduga atau batas teknologi yang tersedia. Kami menghadapi sesuatu seperti ini Jumat lalu, dan insiden tersebut menyebabkan kelambatan yang terputus-putus dalam layanan kami dan penundaan pengiriman bagi beberapa pelanggan kami.
Pertama, saya ingin mengatakan, masalah tersebut telah diselesaikan pada hari yang sama. Selain itu, tidak ada email atau data terkait yang hilang. Namun, jika pengiriman email Anda tertunda karena masalah ini, mohon terima permintaan maaf saya (sebenarnya, permintaan maaf dari seluruh tim kami). Insiden ini menekankan pentingnya memiliki strategi cadangan yang komprehensif - baik Anda menggunakan cadangan database PostgreSQL atau metode perlindungan data lainnya untuk memastikan kelangsungan bisnis selama tantangan infrastruktur. Kami tahu Anda mengandalkan kami, dan ini mengecewakan ketika kami tidak berkinerja pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk menyembunyikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikan. Anda mungkin telah mengalami itu dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya pernah. Namun, itu bukan cara kami menjalankan bisnis.
Saya ingin menulis tentang insiden ini untuk alasan lain juga: kami mempelajari sesuatu yang benar-benar menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahuinya.
TL;DR
Kami menghadapi batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Mengukur instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll) biasanya berfungsi seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional itu tidak berlaku. Itulah kebenaran dalam situasi penggunaan yang tidak biasa di mana batas agregat dapat berlaku—dan ada saatnya Anda tiba-tiba menghadapi skenario tersebut tanpa peringatan.
Kami mencapai batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak siap ditangani oleh tipe 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 keterlambatan sementara di berbagai titik dalam arsitektur kami.
Kami menghadapi batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Mengukur instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll) biasanya berfungsi seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional itu tidak berlaku. Itulah kebenaran dalam situasi penggunaan yang tidak biasa di mana batas agregat dapat berlaku—dan ada saatnya Anda tiba-tiba menghadapi skenario tersebut tanpa peringatan.
Kami mencapai batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak siap ditangani oleh tipe 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 keterlambatan sementara di berbagai titik dalam arsitektur kami.
Kami menghadapi batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Mengukur instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll) biasanya berfungsi seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional itu tidak berlaku. Itulah kebenaran dalam situasi penggunaan yang tidak biasa di mana batas agregat dapat berlaku—dan ada saatnya Anda tiba-tiba menghadapi skenario tersebut tanpa peringatan.
Kami mencapai batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak siap ditangani oleh tipe 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 keterlambatan sementara di berbagai titik dalam arsitektur kami.
Menggali Lebih Dalam tentang DNS
Mengapa penggunaan DNS kami istimewa? Nah, ini sangat berkaitan dengan cara kerja email, dibandingkan dengan model konten yang dirancang untuk AWS pada awalnya. Penyajian konten berbasis web sangat banyak menggunakan skenario "pendorong" klasik yang masuk: sebuah klien meminta data, apakah itu HTML, aliran video, atau lainnya, dari cloud. Namun, kasus penggunaan untuk penyedia layanan pesan seperti SparkPost adalah pengecualian dari skenario AWS biasanya. Dalam kasus kami, kami melakukan banyak dorongan keluar lalu lintas: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas dalam gaya dorongan tersebut sangat mengandalkan DNS.
Jika Anda sudah familiar dengan DNS, Anda mungkin tahu bahwa ini umumnya data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda harus terlebih dahulu menanyakan di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, menggunakan DNS secara sangat intensif untuk mencari domain pengiriman—misalnya, SparkPost mengirimkan banyak milyar email ke lebih dari 1 juta domain unik setiap bulan. Untuk setiap email yang kami kirimkan, kami harus melakukan minimal dua pencarian DNS, dan penggunaan catatan "txt" DNS untuk teknologi anti-phishing seperti SPF dan DKIM berarti DNS juga diperlukan untuk menerima email. Tambahkan penggunaan tradisional kami terhadap layanan AWS API untuk aplikasi kami, dan sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan keluar yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan gabungan pada jenis instance yang sebaliknya tampaknya memiliki sumber daya yang cukup untuk melayani beban. Dan seperti yang serangan denial-of-service pada infrastruktur DNS Dyn tahun lalu tunjukkan, ketika DNS rusak, semua rusak. (Itu adalah sesuatu yang sudah diketahui dengan amat menyakitkan oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons oleh tim operasi dan teknik keandalan kami untuk mengidentifikasi masalah. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan di sisi operasi AWS. Bekerja sama, kami mengidentifikasi penyebabnya dan menemukan solusi. Kami menerapkan gugus server nama berkapasitas lebih besar dengan fokus lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa mencapai batas untuk throughput. Untungnya, karena semua ini berada di dalam AWS, kami dapat menyiapkan instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS melanjutkan perilaku normal, kegagalan pencarian berhenti, dan kami (dan pengiriman pesan keluar) kembali berjalan lancar.
Untuk mengurangi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih mengisolasi komponen inti kami dari dampak pertemuan dengan batas tak terduga yang serupa. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah kejadian serupa sebelum mempengaruhi pelanggan kami.
Topik | Beban Kerja AWS yang Umum | Beban Kerja Email Keluar SparkPost |
|---|---|---|
Pola Lalu Lintas | Kebanyakan permintaan "pendorong" masuk (halaman web, API, media) | Lalu lintas dorongan keluar berat (milyaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: banyak pencarian DNS per email + pemeriksaan SPF/DKIM TXT |
Volume Kuery | Dapat diprediksi dan sebanding dengan aktivitas pengguna | Memunculkan dengan kampanye keluar yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan gabungan pada jenis instance |
Mode Kegagalan | Pengurangan latensi atau waktu habis API | Kegagalan pencarian DNS menyebabkan penundaan pengiriman |
Visibilitas | Batas umumnya didokumentasikan dan muncul dalam metrik | Batas throughput tidak didokumentasikan dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambah caching | Migrasi ke keluarga instance dengan bandwidth lebih tinggi + desain ulang arsitektur DNS |
Mengapa penggunaan DNS kami istimewa? Nah, ini sangat berkaitan dengan cara kerja email, dibandingkan dengan model konten yang dirancang untuk AWS pada awalnya. Penyajian konten berbasis web sangat banyak menggunakan skenario "pendorong" klasik yang masuk: sebuah klien meminta data, apakah itu HTML, aliran video, atau lainnya, dari cloud. Namun, kasus penggunaan untuk penyedia layanan pesan seperti SparkPost adalah pengecualian dari skenario AWS biasanya. Dalam kasus kami, kami melakukan banyak dorongan keluar lalu lintas: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas dalam gaya dorongan tersebut sangat mengandalkan DNS.
Jika Anda sudah familiar dengan DNS, Anda mungkin tahu bahwa ini umumnya data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda harus terlebih dahulu menanyakan di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, menggunakan DNS secara sangat intensif untuk mencari domain pengiriman—misalnya, SparkPost mengirimkan banyak milyar email ke lebih dari 1 juta domain unik setiap bulan. Untuk setiap email yang kami kirimkan, kami harus melakukan minimal dua pencarian DNS, dan penggunaan catatan "txt" DNS untuk teknologi anti-phishing seperti SPF dan DKIM berarti DNS juga diperlukan untuk menerima email. Tambahkan penggunaan tradisional kami terhadap layanan AWS API untuk aplikasi kami, dan sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan keluar yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan gabungan pada jenis instance yang sebaliknya tampaknya memiliki sumber daya yang cukup untuk melayani beban. Dan seperti yang serangan denial-of-service pada infrastruktur DNS Dyn tahun lalu tunjukkan, ketika DNS rusak, semua rusak. (Itu adalah sesuatu yang sudah diketahui dengan amat menyakitkan oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons oleh tim operasi dan teknik keandalan kami untuk mengidentifikasi masalah. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan di sisi operasi AWS. Bekerja sama, kami mengidentifikasi penyebabnya dan menemukan solusi. Kami menerapkan gugus server nama berkapasitas lebih besar dengan fokus lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa mencapai batas untuk throughput. Untungnya, karena semua ini berada di dalam AWS, kami dapat menyiapkan instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS melanjutkan perilaku normal, kegagalan pencarian berhenti, dan kami (dan pengiriman pesan keluar) kembali berjalan lancar.
Untuk mengurangi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih mengisolasi komponen inti kami dari dampak pertemuan dengan batas tak terduga yang serupa. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah kejadian serupa sebelum mempengaruhi pelanggan kami.
Topik | Beban Kerja AWS yang Umum | Beban Kerja Email Keluar SparkPost |
|---|---|---|
Pola Lalu Lintas | Kebanyakan permintaan "pendorong" masuk (halaman web, API, media) | Lalu lintas dorongan keluar berat (milyaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: banyak pencarian DNS per email + pemeriksaan SPF/DKIM TXT |
Volume Kuery | Dapat diprediksi dan sebanding dengan aktivitas pengguna | Memunculkan dengan kampanye keluar yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan gabungan pada jenis instance |
Mode Kegagalan | Pengurangan latensi atau waktu habis API | Kegagalan pencarian DNS menyebabkan penundaan pengiriman |
Visibilitas | Batas umumnya didokumentasikan dan muncul dalam metrik | Batas throughput tidak didokumentasikan dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambah caching | Migrasi ke keluarga instance dengan bandwidth lebih tinggi + desain ulang arsitektur DNS |
Mengapa penggunaan DNS kami istimewa? Nah, ini sangat berkaitan dengan cara kerja email, dibandingkan dengan model konten yang dirancang untuk AWS pada awalnya. Penyajian konten berbasis web sangat banyak menggunakan skenario "pendorong" klasik yang masuk: sebuah klien meminta data, apakah itu HTML, aliran video, atau lainnya, dari cloud. Namun, kasus penggunaan untuk penyedia layanan pesan seperti SparkPost adalah pengecualian dari skenario AWS biasanya. Dalam kasus kami, kami melakukan banyak dorongan keluar lalu lintas: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas dalam gaya dorongan tersebut sangat mengandalkan DNS.
Jika Anda sudah familiar dengan DNS, Anda mungkin tahu bahwa ini umumnya data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda harus terlebih dahulu menanyakan di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, menggunakan DNS secara sangat intensif untuk mencari domain pengiriman—misalnya, SparkPost mengirimkan banyak milyar email ke lebih dari 1 juta domain unik setiap bulan. Untuk setiap email yang kami kirimkan, kami harus melakukan minimal dua pencarian DNS, dan penggunaan catatan "txt" DNS untuk teknologi anti-phishing seperti SPF dan DKIM berarti DNS juga diperlukan untuk menerima email. Tambahkan penggunaan tradisional kami terhadap layanan AWS API untuk aplikasi kami, dan sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan keluar yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan gabungan pada jenis instance yang sebaliknya tampaknya memiliki sumber daya yang cukup untuk melayani beban. Dan seperti yang serangan denial-of-service pada infrastruktur DNS Dyn tahun lalu tunjukkan, ketika DNS rusak, semua rusak. (Itu adalah sesuatu yang sudah diketahui dengan amat menyakitkan oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons oleh tim operasi dan teknik keandalan kami untuk mengidentifikasi masalah. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan di sisi operasi AWS. Bekerja sama, kami mengidentifikasi penyebabnya dan menemukan solusi. Kami menerapkan gugus server nama berkapasitas lebih besar dengan fokus lebih besar pada kapasitas jaringan yang dapat memenuhi kebutuhan DNS kami tanpa mencapai batas untuk throughput. Untungnya, karena semua ini berada di dalam AWS, kami dapat menyiapkan instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS melanjutkan perilaku normal, kegagalan pencarian berhenti, dan kami (dan pengiriman pesan keluar) kembali berjalan lancar.
Untuk mengurangi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih mengisolasi komponen inti kami dari dampak pertemuan dengan batas tak terduga yang serupa. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah kejadian serupa sebelum mempengaruhi pelanggan kami.
Topik | Beban Kerja AWS yang Umum | Beban Kerja Email Keluar SparkPost |
|---|---|---|
Pola Lalu Lintas | Kebanyakan permintaan "pendorong" masuk (halaman web, API, media) | Lalu lintas dorongan keluar berat (milyaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: banyak pencarian DNS per email + pemeriksaan SPF/DKIM TXT |
Volume Kuery | Dapat diprediksi dan sebanding dengan aktivitas pengguna | Memunculkan dengan kampanye keluar yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan gabungan pada jenis instance |
Mode Kegagalan | Pengurangan latensi atau waktu habis API | Kegagalan pencarian DNS menyebabkan penundaan pengiriman |
Visibilitas | Batas umumnya didokumentasikan dan muncul dalam metrik | Batas throughput tidak didokumentasikan dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambah caching | Migrasi ke keluarga instance dengan bandwidth lebih tinggi + desain ulang arsitektur DNS |
AWS dan Keunggulan di Balik Cloud
Saya tidak ingin mempermanis dampak insiden ini terhadap pelanggan kami. Namun kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi tak terduga dari penggunaan kasus kami dengan infrastruktur AWS—dan kemudian menemukan solusi dalam waktu singkat—banyak berkaitan dengan cara kami membangun SparkPost, dan hubungan baik kami dengan tim Amazon.
Tim operasi hebat SparkPost, tim Site Reliability Engineering (SRE) kami, dan arsitek teknis utama kami bekerja dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja sangat dekat dengan AWS selama dua tahun terakhir juga telah mengajari kami banyak tentang memutar infrastruktur AWS dan menjalankannya dengan cepat, dan kami juga mendapat manfaat dari dukungan mendalam dari tim AWS.
Jika kami harus mengatasi keterbatasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya diselesaikan. Kelincahan dan responsivitas itulah dua alasan mengapa kami mengandalkan bisnis kami pada cloud dan AWS. Bersama-sama, keahlian cloud yang dimiliki perusahaan kami sulit didapat. 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. Pendekatan asli berbasis cloud ini sangat mendasar bagi cara kami merancang email API kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan bagi pengembang. 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 dalam ilmu komputer bahwa Anda tidak tahu tantangan apa yang terjadi dalam skala besar sampai Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh bagus dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami kepada pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau pelanggan SparkPost yang memanfaatkan milik kami, saya berharap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, berguna.
Saya tidak ingin mempermanis dampak insiden ini terhadap pelanggan kami. Namun kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi tak terduga dari penggunaan kasus kami dengan infrastruktur AWS—dan kemudian menemukan solusi dalam waktu singkat—banyak berkaitan dengan cara kami membangun SparkPost, dan hubungan baik kami dengan tim Amazon.
Tim operasi hebat SparkPost, tim Site Reliability Engineering (SRE) kami, dan arsitek teknis utama kami bekerja dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja sangat dekat dengan AWS selama dua tahun terakhir juga telah mengajari kami banyak tentang memutar infrastruktur AWS dan menjalankannya dengan cepat, dan kami juga mendapat manfaat dari dukungan mendalam dari tim AWS.
Jika kami harus mengatasi keterbatasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya diselesaikan. Kelincahan dan responsivitas itulah dua alasan mengapa kami mengandalkan bisnis kami pada cloud dan AWS. Bersama-sama, keahlian cloud yang dimiliki perusahaan kami sulit didapat. 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. Pendekatan asli berbasis cloud ini sangat mendasar bagi cara kami merancang email API kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan bagi pengembang. 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 dalam ilmu komputer bahwa Anda tidak tahu tantangan apa yang terjadi dalam skala besar sampai Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh bagus dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami kepada pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau pelanggan SparkPost yang memanfaatkan milik kami, saya berharap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, berguna.
Saya tidak ingin mempermanis dampak insiden ini terhadap pelanggan kami. Namun kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi tak terduga dari penggunaan kasus kami dengan infrastruktur AWS—dan kemudian menemukan solusi dalam waktu singkat—banyak berkaitan dengan cara kami membangun SparkPost, dan hubungan baik kami dengan tim Amazon.
Tim operasi hebat SparkPost, tim Site Reliability Engineering (SRE) kami, dan arsitek teknis utama kami bekerja dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja sangat dekat dengan AWS selama dua tahun terakhir juga telah mengajari kami banyak tentang memutar infrastruktur AWS dan menjalankannya dengan cepat, dan kami juga mendapat manfaat dari dukungan mendalam dari tim AWS.
Jika kami harus mengatasi keterbatasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya diselesaikan. Kelincahan dan responsivitas itulah dua alasan mengapa kami mengandalkan bisnis kami pada cloud dan AWS. Bersama-sama, keahlian cloud yang dimiliki perusahaan kami sulit didapat. 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. Pendekatan asli berbasis cloud ini sangat mendasar bagi cara kami merancang email API kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan bagi pengembang. 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 dalam ilmu komputer bahwa Anda tidak tahu tantangan apa yang terjadi dalam skala besar sampai Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh bagus dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami kepada pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau pelanggan SparkPost yang memanfaatkan milik kami, saya berharap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, berguna.
