Pemadaman Braze pada 29 April: Apa yang Terjadi, Mengapa Terjadi, dan Bagaimana Kami Menanggapinya

Memahami arsitektur layanan platform Braze

Braze mengelola set server terpisah untuk masing-masing delapan cluster kami di AS. Klaster Braze US 01 hingga 07 dihosting di Amazon Web Services (AWS), sedangkan klaster Braze US 08 dihosting di Microsoft Azure. Di setiap lingkungan ini, Braze menggunakan beberapa zona ketersediaan dan memiliki redundansi untuk setiap bagian sistem kami. Jika terjadi kegagalan zona ketersediaan, kami secara rutin dan transparan menonaktifkan zona ketersediaan yang terganggu dari perutean dan pemrosesan. Hal ini memungkinkan kami menjaga keterkiriman layanan dengan andal selama pemadaman penyedia layanan cloud.

Dengan sedikit pengecualian, masing-masing klaster AS memiliki infrastruktur tersendiri dan, kecuali beberapa komponen yang digunakan di semua lingkungan di wilayah cloud tertentu, klaster-klaster ini sangat terisolasi satu sama lain, untuk mengurangi risiko. bahwa gangguan pada satu klaster akan berdampak pada klaster lainnya.

Karena intensitas beban kerja pemrosesan real-time platform Braze, sejak tahun 2013 kami telah melengkapi penggunaan AWS dan Azure dengan bermitra dengan Rackspace untuk menghosting perangkat keras yang dikonfigurasi secara khusus untuk menjalankan database MongoDB. Lingkungan AWS dan Azure kami dikonfigurasikan dengan konektor cloud pribadi AWS Direct Connect dan Azure ExpressRoute, yang menghubungkan lingkungan cloud ke jaringan internal kami yang dikelola di pusat data Rackspace melalui kabel serat optik khusus. Koneksi terenkripsi ini, yang didukung oleh tautan jaringan yang mendukung banyak antarmuka yang mendorong lebih dari 100 gigabit lalu lintas jaringan per detik, memberikan akses berperforma tinggi antara cloud kami dan lingkungan Rackspace.

Lingkungan khusus kami di Rackspace adalah rumah bagi ratusan server fisik yang disimpan di lemari yang didedikasikan untuk Braze. Pengaturan ini mencakup catu daya redundan dan sakelar rak atas redundan. Switch top-of-rack adalah perangkat jaringan yang berada di rak server dan menghubungkan perangkat dan server bersama-sama di rak server yang sama. Sakelar ini diuji setidaknya setiap tahun untuk failover tanpa dampak; pengujian tahun lalu berhasil diselenggarakan pada tanggal 3 Agustus 2023. Dalam lingkungan khusus ini, kami memelihara puluhan ribu kontainer virtual untuk database MongoDB. Mirip dengan lingkungan cloud kami, kami mempertahankan isolasi fisik tingkat tinggi antar kontainer di klaster AS yang berbeda untuk meminimalkan gangguan dan mengurangi risiko bahwa satu kontainer dapat memengaruhi kontainer lain dalam database kami.

Penyebab pemadaman pada tanggal 29 April dan cara kami meresponsnya

Kegagalan sakelar parsial awal

Pada tanggal 29 April pukul 09:15 UTC, terjadi kegagalan sebagian pada switch jaringan Cisco Nexus utama yang terhubung ke lemari server Rackspace kami. Sakelar yang tidak berfungsi gagal dengan cara yang tidak secara otomatis mengaktifkan sakelar jaringan sekunder melalui failover, dan malah menjadikan sakelar yang tidak berfungsi sebagai sakelar utama.

Jaringan mengalihkan rute lalu lintas dengan meneruskan paket jaringan—disebut "frame"—ke tujuannya. Untuk melakukan hal ini secara efisien, switch ini mempertahankan pemahaman tentang topologi jaringan yang menghubungkan perangkat bersama-sama. Biasanya rute jaringan berubah secara dinamis sebagai respons terhadap kegagalan atau kelambatan masing-masing komponen. Ketika perubahan ini terjadi, switch dan perangkat jaringan lainnya berkomunikasi satu sama lain untuk menjaga pemahaman yang akurat tentang topologi jaringan.

Dalam jaringan besar, sering kali terdapat lebih dari satu jalur antar perangkat, yang dapat menyebabkan "loop" perutean (yaitu suatu kondisi di mana paket gagal berhenti di tujuan yang dituju, dan malah kembali ke tempat asalnya). Perulangan dapat menciptakan "badai siaran", yang menyebabkan lalu lintas berakhir perulangan tanpa batas, memenuhi tautan jaringan dan menyebabkan pemadaman listrik. Untuk mencegah hal ini terjadi, saklar diprogram untuk mengirimkan pesan yang membantu mengidentifikasi tautan yang berlebihan. Pesan-pesan tersebut disebut unit data protokol jembatan pohon spanning (BPDU) dan merupakan bagian dari protokol jaringan yang disebut Protokol Spanning Tree (STP). Switch kemudian menggunakan informasi ini untuk memblokir port lalu lintas untuk mencegah terjadinya loop ketika merutekan lalu lintas. Jika link atau switch fisik gagal, STP membantu menyediakan redundansi, karena dapat digunakan untuk mengidentifikasi link fisik lain yang lalu lintasnya dapat dikirim dan mempromosikan link yang sebelumnya pasif (yaitu diblokir) menjadi aktif untuk menjaga koneksi.

Pada awal insiden tanggal 29 April, ketika switch mulai tidak berfungsi, switch mulai meneruskan pemberitahuan perubahan topologi dan BPDU secara terus-menerus, sehingga membanjiri jaringan dengan pemberitahuan perubahan tersebut. Paket-paket ini disebarkan ke switch distribusi dan switch lainnya, menyebabkan loop peralihan pohon rentang yang mengakibatkan pemadaman jaringan total. Meskipun STP diterapkan untuk mengurangi perulangan jaringan dengan memblokir port jaringan di mana perulangan terdeteksi, selama insiden tanggal 29 April, lalu lintas pohon rentang yang diteruskan secara salah dari sakelar yang tidak berfungsi menyebabkan sakelar lain di jaringan menganalisis ulang topologi pohon rentangnya. Kemudian, karena switch-switch lain tersebut mendeteksi bahwa paket BPDU berprioritas tinggi berasal dari switch yang tidak berfungsi, switch distribusi mulai meneruskan ke port yang sebelumnya diblokir dan mengakibatkan loop switching yang membebani jaringan dan mematikannya.

Remediasi Rackspace

Sebagai hasil dari aktivitas ini, teknisi pusat data Rackspace menerima peringatan sekitar pukul 09:20 UTC mengenai masalah konektivitas jaringan yang tidak terduga dan mulai mengatasi masalah tersebut. Antara pukul 09:39 dan 10:03 UTC, teknisi pusat data Rackspace menangguhkan sakelar jaringan, mengubah daya sakelar utama, dan memaksa kartu antarmuka jaringan (NIC) di kabinet server untuk melakukan failover ke sakelar sekunder. Setelah failover NIC, konektivitas dipulihkan ke server fisik di lingkungan Braze.

Bagaimana fungsi database Braze MongoDB

Basis data MongoDB yang digunakan oleh Braze memungkinkan data disimpan di beberapa server basis data yang dikenal sebagai "pecahan". MongoDB menyediakan layanan perutean yang disebut "mongoS", yang memproses kueri dari layanan platform Braze, menentukan lokasi data yang relevan dalam klaster shard, lalu merutekan kueri ke database MongoDB yang sesuai. Braze memiliki ratusan database MongoDB yang berbeda, yang terdiri dari lebih dari 15.000 proses "mongoD", yang merupakan program yang menjalankan database dan menyimpan data untuk pecahan MongoDB tertentu.

Setiap pecahan basis data terdiri dari satu mongoD utama dan setidaknya dua proses mongoD sekunder, yang menyediakan ketersediaan tinggi jika terjadi kegagalan. Setiap server mongoS memelihara koneksi jaringan ke setiap mongoD yang dapat merutekan kueri. Proses mongoD ini juga terhubung ke proses primer dan sekunder dalam konfigurasinya; ini dikenal sebagai set replika. Jika mongoS tidak dapat terhubung ke mongoD tertentu, proses tersebut akan ditandai sebagai offline dan menjadwalkan percobaan ulang. Demikian pula, jika mongoD tidak dapat terhubung ke anggota mongoD lain dari kumpulan replikanya dalam satu detik, waktu habis, menandai proses tersebut sebagai offline, dan menjadwalkan percobaan ulang.

Dampak loop jaringan pada proses MongoDB kami dan cara kami meresponsnya

Selama loop jaringan, karena proses MongoDB kami tidak dapat terhubung secara normal, masing-masing proses menandai semua proses terkait sebagai offline. Artinya, setiap proses mongoS menandai semua proses mongoD terkait sebagai offline, dan setiap proses mongoD menandai anggota kumpulan replika terkait sebagai offline. Namun, bahkan setelah konektivitas jaringan dipulihkan ke server fisik kami oleh Rackspace, baik proses mongoS maupun mongoD tidak membangun kembali semua koneksi ke proses lain yang telah ditandai offline.

Pada titik ini, untuk membantu upaya remediasi tim Rackspace database administrator (DBA), tim Braze DevOps mulai melakukan debug dengan cepat dan menguji metode untuk memulihkan konektivitas tersebut. Investigasi kami menentukan bahwa satu-satunya opsi yang tersedia adalah memulai ulang setiap proses dari hampir 16.000 mongoD dan 6.000+ mongoS dalam wadah virtualnya. Mengingat besarnya skala upaya ini dan fakta bahwa otomatisasi tidak ada untuk memulai kembali begitu banyak kontainer dengan cepat, para insinyur Rackspace menulis kode baru selama kejadian tersebut untuk menciptakan kemampuan otomatisasi on-the-fly.

Sayangnya, seiring dengan semakin intensifnya proses restart, masalah lain muncul pada sistem Sistem Nama Domain (DNS). Saat proses mongoS dan mongoD online, mereka meminta informasi dari penyelesai DNS dalam proses yang dikenal sebagai pencarian DNS. Dengan pencarian DNS berkelanjutan yang didorong oleh kecepatan restart, server DNS mengalami beban berat, menyebabkan batas waktu konektivitas pada lapisan mongoS saat mereka terhubung kembali ke proses mongoD. Untuk mengakomodasi beban yang terus bertambah ini, tim Rackspace kami meningkatkan kapasitas CPU DNS, namun kemudian terpaksa memulai ulang tingkat mongoS untuk kedua kalinya guna membuat koneksi yang sehat dari setiap mongoS ke proses mongoD terkait.

Sekitar pukul 17:05 UTC, proses restart memungkinkan beberapa cluster mulai kembali online. Ketika kinerja basis data pulih dan klaster menjadi stabil, Braze terus meningkatkan kapasitas pemrosesan data dan pengiriman pesan; namun, upaya tersebut dipersulit oleh tumpukan besar-besaran yang diakibatkan oleh ketidaktersediaan sebelumnya.

Mengingat skala dan kecanggihan lingkungan basis data Rackspace kami, yang terdiri dari ratusan basis data berbeda, lamanya pemadaman, dan volume simpanan kami yang dihasilkan (mewakili miliaran pesan dan miliaran titik data yang diserap), proses pemulihan diperlukan dalam -adaptasi saat ini dari proses pemulihan normal kita. Hal ini diperlukan untuk memastikan bahwa sumber daya database tetap seimbang dengan tuntutan pemrosesan yang sedang berlangsung, termasuk penggunaan kapasitas pemrosesan keseluruhan dalam jumlah besar.

Namun, saat melakukan hal tersebut, Braze mencapai batas AWS pada jumlah CPU virtual yang dapat kami sediakan, sehingga menghalangi kami untuk menambahkan kapasitas server tambahan. Tim Braze dengan cepat meningkatkan keadaan ini dengan tim AWS kami dan menerima peningkatan, sehingga teknisi kami dapat meningkatkan kapasitas pemrosesan server kami ke tingkat rekor, yang lebih dari 50% lebih tinggi dari kapasitas maksimum kami sebelumnya, yang telah dicapai pada Black Jumat 2023.

Pada pukul 20:30 UTC, semua klaster AS kami kecuali US 01, US 03, dan US 08 telah selesai memproses backlog mereka, dan klaster lainnya memproses pada atau di atas kecepatan puncak dari hari sebelum kejadian. Dalam beberapa jam, semua cluster berhasil diproses secara real-time dan kami menyatakan bahwa insiden tersebut telah teratasi.

Bagaimana Braze mengkomunikasikan pembaruan selama insiden

Komunikasi yang jelas dan sering selama insiden seperti ini sangatlah penting. Meskipun masalah teknis secara umum jarang terjadi, dan masalah sebesar ini belum pernah terjadi sebelumnya di Braze, kami selalu melakukan yang terbaik untuk berkomunikasi dengan pihak-pihak yang terkena dampak dengan jelas dan cepat.

Dalam situasi seperti ini, prinsip panduan yang mendasari strategi komunikasi kita adalah kejujuran, transparansi, dan kepercayaan. Kami tahu bahwa kami hanya mempunyai satu kesempatan untuk jujur ​​dan berterus terang mengenai apa yang terjadi, dan bahwa transparansi mengenai insiden—baik saat ini maupun setelah penyelesaiannya—sangat penting untuk menjaga kepercayaan. Pada akhirnya, kami ingin pelanggan kami yakin bahwa Braze akan selalu melakukan segala daya kami untuk menjelaskan, memulihkan, dan mencegah terulangnya insiden apa pun.

Selama terjadi insiden, kami menggunakan Halaman Status kami untuk mengelola komunikasi dan memberikan pembaruan berkala mengenai keadaan; Saya sangat menganjurkan pelanggan untuk mendaftar pembaruan dari halaman itu agar tetap mendapatkan informasi terbaru. Selama pemadaman pada tanggal 29 April, kami melengkapi pembaruan Halaman Status yang sering dilakukan ini dengan email dari rekan pendiri dan CEO kami, Bill Magnuson. Pesan tersebut dikirim ke semua pengguna dasbor Braze dan diberikan kepada tim akun kami untuk dibagikan kepada pemangku kepentingan pelanggan lainnya sesuai kebutuhan.

Bagaimana Braze menindaklanjuti insiden tersebut dan rencana pencegahan di masa depan

Sebelum kejadian ini, pengalaman kami membuat kami yakin bahwa jaringan kami tangguh, karena peralihan jaringan kami yang berlebihan. Namun, pemadaman ini menunjukkan bahwa topologi jaringan kami—yang telah mendukung kami dengan baik selama lebih dari satu dekade—rentan terhadap kegagalan besar. Sekarang jelas bahwa hal ini harus ditingkatkan ke depannya.

Sejak kejadian tersebut, Braze dan Rackspace telah bertukar dan mengganti saklar yang rusak, dan tim teknik Rackspace telah menyelesaikan audit penuh terhadap infrastruktur jaringan yang diandalkan oleh layanan Braze. Meskipun kegagalan perangkat keras sangat sulit diprediksi, terutama pada peralatan yang masih bergaransi, pemantauan dilakukan untuk mendeteksi kelainan dan memastikan respons yang cepat. Kedua tim kini berkolaborasi untuk membuat perubahan yang akan mencegah loop jaringan di masa depan, bahkan jika peralatan tidak berfungsi. Beberapa perubahan jaringan memerlukan waktu untuk diterapkan, karena kami berencana membuat perubahan berarti pada topologi jaringan kami untuk lebih meningkatkan perlindungan terhadap loop. Kami juga telah membuka tiket dukungan dengan Cisco dan MongoDB untuk lebih memahami skenario kegagalan yang kami alami, dan untuk meningkatkan kemampuan proses mongoD dan mongoS untuk melakukan pemulihan mandiri setelah kegagalan jaringan.

Kami telah melakukan kontak setiap hari dengan Rackspace sejak kejadian tersebut untuk mengambil tindakan terhadap perubahan jangka pendek dan melakukan peningkatan jaringan yang lebih besar, dan akan terus melakukannya hingga kami yakin bahwa desain jaringan yang lebih baik dan lebih tangguh telah tercapai.

Saya ingin meminta maaf sekali lagi atas kejadian ini dan dampaknya terhadap bisnis Anda dan hubungan Anda dengan pelanggan. Jumlah waktu Braze tidak tersedia tidak dapat diterima. Kepemimpinan teknik dan tim eksekutif kami berkomitmen penuh untuk melakukan semua perubahan yang diperlukan untuk mengidentifikasi dan menyelesaikan kerentanan pemadaman listrik secepat dan seefisien mungkin, sehingga kami sekali lagi dapat memperoleh kepercayaan Anda sebagai mitra yang andal dan berkinerja baik.

— Jon