Hari Ketika DNS Kami Mencapai Batas yang Tidak Didokumentasikan di AWS
Burung
7 Feb 2017
Rekayasa
1 min read
Poin Penting
SparkPost menghadapi batas throughput jaringan yang tidak terdokumentasi pada tipe instans AWS EC2 tertentu yang mendukung cluster DNS utamanya.
Pemilihan ukuran instans tradisional (CPU, RAM, disk) tidak mengungkapkan kemacetan ini karena masalah ini terkait dengan lalu lintas jaringan DNS agregat, bukan kelangkaan sumber daya.
Penggunaan DNS untuk email keluar dengan volume tinggi sangat berat: SparkPost menghasilkan jutaan pencarian DNS untuk pengalihan domain, otentikasi (SPF/DKIM), dan interaksi API AWS.
Kegagalan DNS tidak berasal dari respons DNS yang cacat — sebaliknya, batas kapasitas jaringan tingkat instans terlampaui tanpa disadari, menyebabkan kegagalan pencarian yang luas.
Karena AWS tidak secara eksplisit mendokumentasikan batas jaringan lunak ini, mendiagnosis masalah ini memerlukan kolaborasi mendalam antara tim SRE SparkPost dan insinyur AWS.
Tim menyelesaikan masalah ini dengan memigrasi layanan DNS ke tipe instans yang lebih besar dengan bandwidth jaringan yang lebih besar dan mendesain ulang bagian dari arsitektur DNS untuk isolasi dan failover yang lebih baik.
Tidak ada data atau pesan pelanggan yang hilang, tetapi peristiwa ini menyoroti bagaimana arsitektur berbasis cloud dapat menghadapi batas yang tidak terduga pada skala — dan betapa cepatnya masalah tersebut dapat diperbaiki dengan elastisitas AWS.
Sorotan Tanya jawab
Apa yang terjadi?
Kluster DNS SparkPost mengalami batas throughput jaringan AWS yang tidak terduga, menyebabkan pencarian DNS gagal secara intermittent — yang mengakibatkan keterlambatan pengiriman email.
Mengapa DNS rusak sama sekali?
DNS sangat bergantung pada banyak hal untuk email yang keluar. Setiap pengiriman memerlukan beberapa pencarian (MX, TXT, SPF, DKIM), jadi volume pengiriman yang tinggi = lalu lintas DNS yang besar.
Polanya lalu lintas ini melebihi batas yang tidak terdokumentasi pada jenis instance EC2 yang menghosting nameserver.
Bagaimana DNS untuk email berbeda dari aplikasi web?
Aplikasi web sebagian besar menarik konten (klien meminta data).
Jasa pengiriman email mendorong lalu lintas, memicu jauh lebih banyak pencarian DNS — sering kali miliaran per bulan.
Email bergantung pada DNS untuk pengaturan, validasi keamanan, dan pemulihan.
Bagaimana kegagalan itu muncul?
Permintaan DNS mulai gagal atau hilang waktu
Antrian pengiriman tertunda
Latency meningkat di beberapa bagian sistem
Tidak ada yang hilang — hanya tertunda.
Mengapa ini sulit didiagnosis?
Limit tidak didokumentasikan
Pemantauan AWS tidak secara eksplisit menunjukkan bottleneck
Semua metrik tradisional (CPU, RAM, disk) terlihat normal
Masalah hanya muncul di bawah pola lalu lintas DNS yang spesifik dan bervolume tinggi.
Bagaimana SparkPost memperbaikinya?
Ditingkatkan ke tipe instance EC2 dengan batas throughput jaringan yang lebih tinggi
Merancang ulang kluster DNS agar lebih tahan terhadap lonjakan lalu lintas agregat
Bekerja sama dengan AWS untuk mengidentifikasi pola sinyal/pemberitahuan yang lebih baik untuk menangkap ini lebih cepat
Apakah data pelanggan atau email hilang?
Tidak — hanya pengiriman yang melambat. Setelah DNS stabil, semua email melanjutkan pengiriman normal.
Apa pelajaran yang lebih luas?
Bahkan di cloud, Anda dapat mengalami batasan skala yang tidak terlihat — tetapi desain yang sesuai cloud memberi Anda fleksibilitas untuk pulih dengan cepat.
Elastisitas, kemitraan dengan AWS, dan praktik SRE yang kuat membuat pemulihan cepat menjadi mungkin.
Bagaimana Kami Menemukan Kegagalan DNS 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 pencitraan. Arsitektur cloud kami yang mendasari skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas-kualitas tersebut adalah alasan utama mengapa kami membangun infrastruktur kami di atas Amazon Web Services (AWS)—dan itulah mengapa kami dapat menawarkan jaminan tingkat layanan dan laju lonjakan yang tak tertandingi oleh siapa pun di 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 itu menyebabkan perlambatan intermiten dalam layanan kami dan penundaan pengiriman untuk beberapa pelanggan kami.
Pertama-tama, izinkan saya mengatakan, masalah ini sudah 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 menguatkan 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 itu membuat frustrasi ketika kami tidak beroperasi pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk mengabaikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikannya. Anda mungkin telah mengalaminya dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya sudah. Tetapi itu bukan cara kami berbisnis.
Saya ingin menulis tentang insiden ini juga untuk alasan lain: kami belajar sesuatu yang sangat menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahui lebih lanjut tentang hal ini.
Kami telah membangun SparkPost di sekitar ide bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan hanya sekadar pencitraan. Arsitektur cloud kami yang mendasari skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas-kualitas tersebut adalah alasan utama mengapa kami membangun infrastruktur kami di atas Amazon Web Services (AWS)—dan itulah mengapa kami dapat menawarkan jaminan tingkat layanan dan laju lonjakan yang tak tertandingi oleh siapa pun di 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 itu menyebabkan perlambatan intermiten dalam layanan kami dan penundaan pengiriman untuk beberapa pelanggan kami.
Pertama-tama, izinkan saya mengatakan, masalah ini sudah 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 menguatkan 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 itu membuat frustrasi ketika kami tidak beroperasi pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk mengabaikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikannya. Anda mungkin telah mengalaminya dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya sudah. Tetapi itu bukan cara kami berbisnis.
Saya ingin menulis tentang insiden ini juga untuk alasan lain: kami belajar sesuatu yang sangat menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahui lebih lanjut tentang hal ini.
Kami telah membangun SparkPost di sekitar ide bahwa layanan cloud seperti milik kami perlu menjadi cloud-native itu sendiri. Itu bukan hanya sekadar pencitraan. Arsitektur cloud kami yang mendasari skalabilitas, elastisitas, dan keandalan yang merupakan aspek inti dari layanan SparkPost. Kualitas-kualitas tersebut adalah alasan utama mengapa kami membangun infrastruktur kami di atas Amazon Web Services (AWS)—dan itulah mengapa kami dapat menawarkan jaminan tingkat layanan dan laju lonjakan yang tak tertandingi oleh siapa pun di 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 itu menyebabkan perlambatan intermiten dalam layanan kami dan penundaan pengiriman untuk beberapa pelanggan kami.
Pertama-tama, izinkan saya mengatakan, masalah ini sudah 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 menguatkan 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 itu membuat frustrasi ketika kami tidak beroperasi pada tingkat yang Anda harapkan.
Beberapa perusahaan tergoda untuk mengabaikan masalah seperti penurunan layanan dan berharap tidak ada yang memperhatikannya. Anda mungkin telah mengalaminya dengan layanan yang Anda gunakan di masa lalu. Saya tahu saya sudah. Tetapi itu bukan cara kami berbisnis.
Saya ingin menulis tentang insiden ini juga untuk alasan lain: kami belajar sesuatu yang sangat menarik dan berharga tentang arsitektur cloud AWS kami. Tim yang membangun layanan cloud lainnya mungkin tertarik untuk mengetahui lebih lanjut tentang hal ini.
TL;DR
Kami menemui batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Memilih ukuran instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya bekerja seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional tersebut tidak berlaku. Itu terutama benar dalam kasus penggunaan yang tidak biasa di mana batas agregat dapat berperan— dan ada kalanya Anda terjebak dalam skenario tersebut tanpa peringatan.
Kami mengalami batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak dapat ditangani oleh tipe instance kami. Namun, karena batas itu tidak jelas dari dokumen atau metrik standar yang tersedia, kami tidak tahu bahwa kami sudah mengalami hal itu. Apa yang kami amati adalah tingkat kegagalan DNS yang sangat tinggi, yang pada gilirannya menyebabkan keterlambatan sesekali di berbagai titik dalam arsitektur kami.
Kami menemui batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Memilih ukuran instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya bekerja seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional tersebut tidak berlaku. Itu terutama benar dalam kasus penggunaan yang tidak biasa di mana batas agregat dapat berperan— dan ada kalanya Anda terjebak dalam skenario tersebut tanpa peringatan.
Kami mengalami batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak dapat ditangani oleh tipe instance kami. Namun, karena batas itu tidak jelas dari dokumen atau metrik standar yang tersedia, kami tidak tahu bahwa kami sudah mengalami hal itu. Apa yang kami amati adalah tingkat kegagalan DNS yang sangat tinggi, yang pada gilirannya menyebabkan keterlambatan sesekali di berbagai titik dalam arsitektur kami.
Kami menemui batas praktis yang tidak terdokumentasi dari instance EC2 yang kami gunakan untuk kluster DNS utama kami. Memilih ukuran instance cloud berdasarkan spesifikasi tradisional (prosesor, memori, dll.) biasanya bekerja seperti yang Anda harapkan, tetapi kadang-kadang model perangkat keras tradisional tersebut tidak berlaku. Itu terutama benar dalam kasus penggunaan yang tidak biasa di mana batas agregat dapat berperan— dan ada kalanya Anda terjebak dalam skenario tersebut tanpa peringatan.
Kami mengalami batas seperti itu pada hari Jumat ketika volume kueri DNS kami menciptakan pola penggunaan jaringan yang tidak dapat ditangani oleh tipe instance kami. Namun, karena batas itu tidak jelas dari dokumen atau metrik standar yang tersedia, kami tidak tahu bahwa kami sudah mengalami hal itu. Apa yang kami amati adalah tingkat kegagalan DNS yang sangat tinggi, yang pada gilirannya menyebabkan keterlambatan sesekali di berbagai titik dalam arsitektur kami.
Menggali Lebih Dalam ke DNS
Kenapa 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 memanfaatkan dengan baik apa yang mungkin dianggap sebagai skenario "tarik" inbound klasik: klien meminta data, entah 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 kasus kami, kami melakukan banyak pempushan lalu lintas outbound: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas gaya push itu sangat bergantung pada DNS.
Jika Anda familiar dengan DNS, Anda mungkin tahu bahwa itu umumnya adalah data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda pertama-tama harus bertanya di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, sangat memanfaatkan 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. Ditambah dengan penggunaan lebih tradisional layanan API AWS untuk aplikasi kami, sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan outbound yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan agregat pada jenis instance yang seolah-olah memiliki sumber daya yang cukup untuk melayani beban itu. Dan seperti serangan denial-of-service pada infrastruktur Dyn DNS tahun lalu yang menunjukkan, ketika DNS bermasalah, segalanya bermasalah. (Itu adalah sesuatu yang sudah sangat dipahami oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons dari tim operasi dan rekayasa keandalan kami untuk mengidentifikasi masalah tersebut. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan sisi operasi AWS. Bekerja bersama, kami mengidentifikasi penyebab dan solusi. Kami menerapkan kluster nameserver kapasitas lebih besar dengan fokus yang lebih besar pada kapasitas jaringan yang mampu memenuhi kebutuhan DNS kami tanpa melewati batas throughput. Untungnya, karena semua ini ada di dalam AWS, kami dapat membuat instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS kembali berfungsi normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan outbound) kembali ke jalur yang benar.
Untuk memitigasi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih baik mengisolasi komponen inti kami dari dampak pertemuan dengan ambang batas yang serupa dan tidak terduga. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah insiden serupa sebelum berdampak pada pelanggan kami.
Topik | Kerja Beban AWS Tipikal | Kerja Beban Email Outbound SparkPost |
|---|---|---|
Pola Lalu Lintas | Sebagian besar permintaan "tarik" inbound (halaman web, API, media) | Lalu lintas outbound "dorong" yang berat (miliaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: beberapa pencarian DNS per email + pemeriksaan TXT SPF/DKIM |
Volume Kueri | Terprediksi dan proporsional dengan aktivitas pengguna | Melejit dengan kampanye outbound yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan agregat pada jenis instance |
Mode Kegagalan | Latensi menurun atau waktu tunggu API | Kegagalan pencarian DNS yang menyebabkan penundaan pengiriman |
Visibilitas | Batas biasanya didokumentasikan dan disajikan dalam metrik | Batas throughput tidak terdokumentasi dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambahkan caching | Beralih ke keluarga instance bandwidth lebih tinggi + redesain arsitektur DNS |
Kenapa 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 memanfaatkan dengan baik apa yang mungkin dianggap sebagai skenario "tarik" inbound klasik: klien meminta data, entah 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 kasus kami, kami melakukan banyak pempushan lalu lintas outbound: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas gaya push itu sangat bergantung pada DNS.
Jika Anda familiar dengan DNS, Anda mungkin tahu bahwa itu umumnya adalah data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda pertama-tama harus bertanya di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, sangat memanfaatkan 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. Ditambah dengan penggunaan lebih tradisional layanan API AWS untuk aplikasi kami, sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan outbound yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan agregat pada jenis instance yang seolah-olah memiliki sumber daya yang cukup untuk melayani beban itu. Dan seperti serangan denial-of-service pada infrastruktur Dyn DNS tahun lalu yang menunjukkan, ketika DNS bermasalah, segalanya bermasalah. (Itu adalah sesuatu yang sudah sangat dipahami oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons dari tim operasi dan rekayasa keandalan kami untuk mengidentifikasi masalah tersebut. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan sisi operasi AWS. Bekerja bersama, kami mengidentifikasi penyebab dan solusi. Kami menerapkan kluster nameserver kapasitas lebih besar dengan fokus yang lebih besar pada kapasitas jaringan yang mampu memenuhi kebutuhan DNS kami tanpa melewati batas throughput. Untungnya, karena semua ini ada di dalam AWS, kami dapat membuat instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS kembali berfungsi normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan outbound) kembali ke jalur yang benar.
Untuk memitigasi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih baik mengisolasi komponen inti kami dari dampak pertemuan dengan ambang batas yang serupa dan tidak terduga. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah insiden serupa sebelum berdampak pada pelanggan kami.
Topik | Kerja Beban AWS Tipikal | Kerja Beban Email Outbound SparkPost |
|---|---|---|
Pola Lalu Lintas | Sebagian besar permintaan "tarik" inbound (halaman web, API, media) | Lalu lintas outbound "dorong" yang berat (miliaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: beberapa pencarian DNS per email + pemeriksaan TXT SPF/DKIM |
Volume Kueri | Terprediksi dan proporsional dengan aktivitas pengguna | Melejit dengan kampanye outbound yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan agregat pada jenis instance |
Mode Kegagalan | Latensi menurun atau waktu tunggu API | Kegagalan pencarian DNS yang menyebabkan penundaan pengiriman |
Visibilitas | Batas biasanya didokumentasikan dan disajikan dalam metrik | Batas throughput tidak terdokumentasi dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambahkan caching | Beralih ke keluarga instance bandwidth lebih tinggi + redesain arsitektur DNS |
Kenapa 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 memanfaatkan dengan baik apa yang mungkin dianggap sebagai skenario "tarik" inbound klasik: klien meminta data, entah 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 kasus kami, kami melakukan banyak pempushan lalu lintas outbound: khususnya, email (dan jenis pesan lainnya seperti SMS atau notifikasi push seluler). Dan lalu lintas gaya push itu sangat bergantung pada DNS.
Jika Anda familiar dengan DNS, Anda mungkin tahu bahwa itu umumnya adalah data yang cukup ringan. Untuk meminta halaman HTML tertentu, Anda pertama-tama harus bertanya di mana halaman itu dapat ditemukan di Internet, tetapi permintaan itu hanya sebagian kecil dari ukuran konten yang Anda ambil.
Email, bagaimanapun, sangat memanfaatkan 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. Ditambah dengan penggunaan lebih tradisional layanan API AWS untuk aplikasi kami, sulit untuk melebih-lebihkan seberapa penting DNS bagi infrastruktur kami.
Semua ini berarti kami menghadapi kondisi yang tidak biasa di mana volume pesan outbound yang meningkat menciptakan volume lalu lintas DNS yang mencapai batas throughput jaringan agregat pada jenis instance yang seolah-olah memiliki sumber daya yang cukup untuk melayani beban itu. Dan seperti serangan denial-of-service pada infrastruktur Dyn DNS tahun lalu yang menunjukkan, ketika DNS bermasalah, segalanya bermasalah. (Itu adalah sesuatu yang sudah sangat dipahami oleh siapa pun yang membangun sistem yang bergantung pada DNS.)
Masalah DNS yang tiba-tiba memicu respons dari tim operasi dan rekayasa keandalan kami untuk mengidentifikasi masalah tersebut. Mereka bekerja sama dengan mitra kami di Amazon untuk meningkatkan sisi operasi AWS. Bekerja bersama, kami mengidentifikasi penyebab dan solusi. Kami menerapkan kluster nameserver kapasitas lebih besar dengan fokus yang lebih besar pada kapasitas jaringan yang mampu memenuhi kebutuhan DNS kami tanpa melewati batas throughput. Untungnya, karena semua ini ada di dalam AWS, kami dapat membuat instance baru dan bahkan mengubah ukuran instance yang ada dengan sangat cepat. DNS kembali berfungsi normal, kegagalan pencarian berhenti, dan kami (serta pengiriman pesan outbound) kembali ke jalur yang benar.
Untuk memitigasi masalah spesifik ini di masa depan, kami juga melakukan perubahan arsitektur DNS untuk lebih baik mengisolasi komponen inti kami dari dampak pertemuan dengan ambang batas yang serupa dan tidak terduga. Kami juga bekerja dengan tim Amazon untuk menentukan model pemantauan yang tepat yang akan memberi kami peringatan yang memadai untuk mencegah insiden serupa sebelum berdampak pada pelanggan kami.
Topik | Kerja Beban AWS Tipikal | Kerja Beban Email Outbound SparkPost |
|---|---|---|
Pola Lalu Lintas | Sebagian besar permintaan "tarik" inbound (halaman web, API, media) | Lalu lintas outbound "dorong" yang berat (miliaran email) |
Ketergantungan DNS | Ringan: 1–2 pencarian per permintaan konten | Sangat berat: beberapa pencarian DNS per email + pemeriksaan TXT SPF/DKIM |
Volume Kueri | Terprediksi dan proporsional dengan aktivitas pengguna | Melejit dengan kampanye outbound yang menargetkan jutaan domain |
Jenis Bottleneck | Batas CPU, memori, atau penyimpanan | Batas throughput jaringan agregat pada jenis instance |
Mode Kegagalan | Latensi menurun atau waktu tunggu API | Kegagalan pencarian DNS yang menyebabkan penundaan pengiriman |
Visibilitas | Batas biasanya didokumentasikan dan disajikan dalam metrik | Batas throughput tidak terdokumentasi dan tidak terlihat di CloudWatch |
Pendekatan Mitigasi | Meningkatkan sumber daya instance atau menambahkan caching | Beralih ke keluarga instance bandwidth lebih tinggi + redesain arsitektur DNS |
AWS dan Sisi Positif Cloud
Saya tidak ingin memperhalus dampak dari insiden ini terhadap pelanggan kami. Namun, kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi yang tidak terduga antara penggunaan kami dengan infrastruktur AWS—dan kemudian menemukan solusi untuk itu dalam waktu yang sangat singkat—sangat 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 dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata dalam mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja begitu dekat dengan AWS selama dua tahun terakhir juga telah mengajarkan kami banyak tentang membangun infrastruktur AWS dan beroperasi dengan cepat, dan kami juga memiliki keuntungan dari dukungan mendalam dari tim AWS.
Jika kami harus bekerja di sekitar batasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya teratasi. Kecepatan dan responsivitas tersebut hanyalah dua dari alasan mengapa kami bertaruh bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang dimiliki oleh perusahaan kami sulit untuk didapatkan. 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 cloud-native ini adalah dasar dari bagaimana kami merancang API email kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan untuk pengembang. Kami mengirim lebih banyak email dari platform cloud sejati daripada siapa pun, dan terkadang itu berarti memasuki wilayah yang belum terpetakan. Ini adalah kebenaran dasar dari ilmu komputer bahwa Anda tidak tahu tantangan apa yang muncul pada skala besar hingga Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh yang luar biasa dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami terhadap pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau seorang pelanggan SparkPost yang memanfaatkan milik kami, saya harap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, bermanfaat.
Saya tidak ingin memperhalus dampak dari insiden ini terhadap pelanggan kami. Namun, kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi yang tidak terduga antara penggunaan kami dengan infrastruktur AWS—dan kemudian menemukan solusi untuk itu dalam waktu yang sangat singkat—sangat 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 dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata dalam mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja begitu dekat dengan AWS selama dua tahun terakhir juga telah mengajarkan kami banyak tentang membangun infrastruktur AWS dan beroperasi dengan cepat, dan kami juga memiliki keuntungan dari dukungan mendalam dari tim AWS.
Jika kami harus bekerja di sekitar batasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya teratasi. Kecepatan dan responsivitas tersebut hanyalah dua dari alasan mengapa kami bertaruh bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang dimiliki oleh perusahaan kami sulit untuk didapatkan. 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 cloud-native ini adalah dasar dari bagaimana kami merancang API email kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan untuk pengembang. Kami mengirim lebih banyak email dari platform cloud sejati daripada siapa pun, dan terkadang itu berarti memasuki wilayah yang belum terpetakan. Ini adalah kebenaran dasar dari ilmu komputer bahwa Anda tidak tahu tantangan apa yang muncul pada skala besar hingga Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh yang luar biasa dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami terhadap pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau seorang pelanggan SparkPost yang memanfaatkan milik kami, saya harap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, bermanfaat.
Saya tidak ingin memperhalus dampak dari insiden ini terhadap pelanggan kami. Namun, kemampuan kami untuk mengidentifikasi masalah mendasar sebagai interaksi yang tidak terduga antara penggunaan kami dengan infrastruktur AWS—dan kemudian menemukan solusi untuk itu dalam waktu yang sangat singkat—sangat 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 dengan Amazon setiap hari. Kekuatan infrastruktur AWS telah memberi kami keunggulan nyata dalam mengoptimalkan arsitektur SparkPost untuk cloud. Bekerja begitu dekat dengan AWS selama dua tahun terakhir juga telah mengajarkan kami banyak tentang membangun infrastruktur AWS dan beroperasi dengan cepat, dan kami juga memiliki keuntungan dari dukungan mendalam dari tim AWS.
Jika kami harus bekerja di sekitar batasan serupa dalam model pusat data tradisional, sesuatu seperti ini bisa memakan waktu berhari-hari atau bahkan berminggu-minggu untuk sepenuhnya teratasi. Kecepatan dan responsivitas tersebut hanyalah dua dari alasan mengapa kami bertaruh bisnis kami pada cloud dan AWS. Bersama-sama, jenis keahlian cloud yang dimiliki oleh perusahaan kami sulit untuk didapatkan. 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 cloud-native ini adalah dasar dari bagaimana kami merancang API email kami untuk infrastruktur cloud, memastikan skalabilitas dan keandalan untuk pengembang. Kami mengirim lebih banyak email dari platform cloud sejati daripada siapa pun, dan terkadang itu berarti memasuki wilayah yang belum terpetakan. Ini adalah kebenaran dasar dari ilmu komputer bahwa Anda tidak tahu tantangan apa yang muncul pada skala besar hingga Anda menghadapinya. Kami menemukan satu di AWS, tetapi respons cepat kami adalah contoh yang luar biasa dari fleksibilitas yang dimungkinkan oleh cloud. Ini juga adalah komitmen kami terhadap pelanggan kami.
Apakah Anda sedang membangun infrastruktur Anda sendiri di AWS, atau seorang pelanggan SparkPost yang memanfaatkan milik kami, saya harap penjelasan ini tentang apa yang terjadi Jumat lalu, dan bagaimana kami menyelesaikannya, bermanfaat.
