29 Nisan Braze Kesintisi: Ne Oldu, Neden Meydana Geldi ve Nasıl Müdahale Ediyoruz?

Braze platformunun hizmet mimarisini anlama

Braze, ABD'deki sekiz kümemizin her biri için ayrı sunucu kümeleri bulundurmaktadır. Braze US 01'den 07'ye kadar olan kümeler Amazon Web Services'te (AWS) barındırılırken Braze US 08 kümesi Microsoft Azure'da barındırılır. Bu ortamların her birinde Braze, birden fazla kullanılabilirlik alanı kullanır ve sistemimizin her bir parçası için yedeklere sahiptir. Kullanılabilirlik alanı arızası durumunda, sorunlu kullanılabilirlik bölgelerini yönlendirme ve işleme açısından rutin ve şeffaf bir şekilde devre dışı bırakırız. Bu, bulut hizmeti sağlayıcısının kesintisi sırasında hizmet teslim edilebilirliğini güvenilir bir şekilde sürdürmemizi mümkün kılıyor.

Birkaç istisna dışında, ABD kümelerinin her biri kendine özel bir altyapıya sahiptir ve belirli bir bulut bölgesindeki tüm ortamlarda kullanılan bir avuç bileşen dışında bu kümeler, riski azaltmak amacıyla birbirlerinden büyük ölçüde izole edilmiştir. Bir kümedeki bozulmanın diğer kümeleri de etkileyeceği anlamına gelir.

Braze platformunun gerçek zamanlı işleme iş yükünün yoğunluğundan dolayı, 2013 yılından bu yana, MongoDB veritabanlarını çalıştırmak üzere özel olarak yapılandırılmış donanımları barındırmak için Rackspace ile ortaklık kurarak AWS ve Azure kullanımımızı destekledik. AWS ve Azure ortamlarımız, bulut ortamını özel bir fiber optik kablo üzerinden Rackspace veri merkezlerinde tutulan dahili ağımıza bağlayan AWS Direct Connect ve Azure ExpressRoute özel bulut bağlayıcılarıyla yapılandırılmıştır. Saniyede 100 gigabitin üzerinde ağ trafiğini yönlendiren birden fazla arayüzü destekleyen ağ bağlantılarıyla desteklenen bu şifreli bağlantı, bulutumuz ile Rackspace ortamları arasında yüksek performanslı erişim sağlar.

Rackspace'teki özel ortamımız, Braze'e ayrılmış kabinlerde tutulan yüzlerce fiziksel sunucuya ev sahipliği yapar. Bu kurulum, yedek güç kaynaklarını ve yedek raf üstü anahtarları içerir. Raf üstü anahtarlar, bir sunucu rafında bulunan ve cihazları ve sunucuları aynı sunucu rafında birbirine bağlayan ağ cihazlarıdır. Bu anahtarlar en az yılda bir kez darbesiz yük devretme açısından test edilir; geçen yılın testi 3 Ağustos 2023'te başarıyla gerçekleştirildi. Bu özel ortamda MongoDB veritabanları için on binlerce sanallaştırılmış konteynerin bakımını yapıyoruz. Bulut ortamlarımıza benzer şekilde, kesintiyi en aza indirmek ve bir konteynerin veritabanlarımız içindeki diğer konteynerleri etkileme riskini azaltmak için farklı ABD kümelerindeki konteynerler arasında yüksek düzeyde fiziksel izolasyon sağlıyoruz.

29 Nisan kesintisinin nedeni ve nasıl müdahale ettiğimiz

İlk kısmi anahtar arızası

29 Nisan 09:15 UTC'de, Rackspace sunucu dolaplarımıza bağlı birincil Cisco Nexus ağ anahtarında kısmi bir arıza oluştu. Arızalı anahtar, ikincil ağ anahtarını yük devretme yoluyla otomatik olarak etkinleştirmeyecek şekilde arızalandı ve bunun yerine arızalı anahtarı birincil olarak tuttu.

Ağ anahtarları, trafiği "çerçeveler" adı verilen ağ paketlerini hedeflerine ileterek yönlendirir. Bunu verimli bir şekilde gerçekleştirmek için bu anahtarlar, cihazları birbirine bağlayan ağ topolojisinin anlaşılmasını sağlar. Bireysel bileşen arızalarına veya yavaşlığına yanıt olarak ağ oluşturma yollarının dinamik olarak değişmesi yaygın bir durumdur. Bu değişiklikler meydana geldiğinde, anahtarlar ve diğer ağ cihazları, ağ topolojisinin doğru bir şekilde anlaşılmasını sağlamak için birbirleriyle iletişim kurar.

Büyük ağlarda, cihazlar arasında genellikle birden fazla yol bulunur ve bu da yönlendirme "döngülerine" (yani paketlerin amaçlanan hedefte duramadığı ve bunun yerine oluştukları yere geri döndüğü bir duruma) neden olabilir. Döngüler, trafiğin süresiz olarak döngüye girdiği, ağ bağlantılarının doymasına ve kesintilere neden olduğu "yayın fırtınaları" yaratabilir. Bunun olmasını önlemek için anahtarlar, gereksiz bağlantıları belirlemeye yardımcı olan mesajlar gönderecek şekilde programlanmıştır. Bu mesajlara yayılan ağaç köprüsü protokolü veri birimleri (BPDU'lar) denir ve Yayılan Ağaç Protokolü (STP) adı verilen bir ağ protokolünün parçasıdır. Anahtarlar daha sonra trafiği yönlendirirken döngülerin oluşmasını önlemek amacıyla trafik bağlantı noktalarını engellemek için bu bilgiyi kullanır. Fiziksel bir bağlantı veya anahtar arızalanırsa STP, trafiğin gönderilebileceği diğer fiziksel bağlantıları tanımlamak ve bağlantıları sürdürmek için önceden pasif (yani engellenmiş) bağlantıyı aktif hale getirmek için kullanılabildiğinden yedeklilik sağlamaya yardımcı olur.

29 Nisan olayının başlangıcında, anahtar arızalanmaya başladığında, topoloji değişikliği bildirimlerini ve BPDU'ları sürekli olarak iletmeye başladı ve ağı bu değişiklik bildirimleriyle doldurdu. Bu paketler dağıtım anahtarlarına ve diğer anahtarlara yayılarak, tam bir ağ kesintisine yol açan yayılan bir ağaç anahtarlama döngüsüne neden oldu. STP, döngünün tespit edildiği ağ bağlantı noktalarını bloke ederek ağ döngülerini azaltmak için mevcut olsa da, 29 Nisan olayı sırasında arızalı anahtardan yanlış iletilen yayılan ağaç trafiği, ağdaki diğer anahtarların yayılan ağaç topolojilerini yeniden analiz etmesine neden oldu. Daha sonra, diğer anahtarlar arızalı anahtardan yüksek öncelikli bir BPDU paketinin geldiğini tespit ettiğinden, dağıtım anahtarları daha önce engellenen bağlantı noktalarında iletmeye başladı ve ağın aşırı yüklenmesine ve onu kapatmasına neden olan bir anahtarlama döngüsüyle sonuçlandı.

Rackspace iyileştirmesi

Bu etkinliğin sonucunda Rackspace veri merkezi mühendisleri, yaklaşık 09:20 UTC'de beklenmeyen ağ bağlantısı sorunlarına ilişkin uyarılar aldılar ve sorunu çözmeye başladılar. 09:39 ile 10:03 UTC arasında, Rackspace veri merkezi mühendisleri ağ anahtarını askıya aldı, birincil anahtarı kapatıp açtı ve sunucu kabinindeki ağ arayüz kartlarını (NIC) ikincil anahtara devretmeye zorladı. NIC yük devretmesinden sonra, Braze ortamındaki fiziksel sunuculara bağlantı yeniden sağlandı.

Braze MongoDB veritabanları nasıl çalışır?

Braze tarafından kullanılan MongoDB veritabanları, verilerin "parçalar" olarak bilinen birden fazla veritabanı sunucusunda depolanmasına olanak tanır. MongoDB, Braze platformunun hizmetlerinden gelen sorguları işleyen, parçalanmış bir kümedeki ilgili verilerin konumunu belirleyen ve ardından bir sorguyu uygun MongoDB veritabanına yönlendiren "mongoS" adı verilen bir yönlendirme hizmeti sağlar. Braze, veritabanını çalıştıran ve belirli bir MongoDB parçası için veri depolayan programlar olan 15.000'den fazla "mongoD" işleminden oluşan yüzlerce farklı MongoDB veritabanına sahiptir.

Her veritabanı parçası, bir birincil mongoD ve en az iki ikincil mongoD işleminden oluşur; bu, bir arıza durumunda yüksek kullanılabilirlik sağlar. Her mongoS sunucusu, sorguları yönlendirebileceği her mongoD ile bir ağ bağlantısı sağlar. Bu mongoD işlemleri aynı zamanda konfigürasyonunda birincil ve ikincil öğelere de bağlanır; buna kopya seti adı verilir. Bir mongoS belirli bir mongoD'ye bağlanamazsa, bu işlemi çevrimdışı olarak işaretler ve yeniden deneme planlar. Benzer şekilde, bir mongoD, kopya kümesindeki diğer mongoD üyelerine bir saniye içinde bağlanamazsa zaman aşımına uğrar, bu işlemleri çevrimdışı olarak işaretler ve yeniden deneme planlar.

Ağ döngüsünün MongoDB süreçlerimiz üzerindeki etkisi ve buna nasıl yanıt verdiğimiz

Ağ döngüsü sırasında MongoDB süreçlerimiz normal şekilde bağlanamadığından her biri ilgili tüm süreçleri çevrimdışı olarak işaretledi. Yani, her mongoS işlemi, ilişkili tüm mongoD işlemlerini çevrimdışı olarak işaretledi ve her mongoD işlemi, ilgili kopya kümesi üyelerini çevrimdışı olarak işaretledi. Ancak fiziksel sunucularımıza Rackspace tarafından ağ bağlantısı yeniden sağlandıktan sonra bile ne mongoS ne de mongoD işlemleri çevrimdışı olarak işaretlenen diğer işlemlerle tüm bağlantıları yeniden kurmadı.

Bu noktada, Rackspace veritabanı yöneticisi (DBA) ekibimizin iyileştirme çabalarına yardımcı olmak amacıyla Braze DevOps ekipleri, bu bağlantıyı geri yüklemeye yönelik yöntemleri hızla hata ayıklamaya ve test etmeye başladı. Araştırmamız, mevcut tek seçeneğin sanallaştırılmış konteynerlerdeki yaklaşık 16.000 mongoD ve 6.000'den fazla mongoS işleminin her birini yeniden başlatmak olduğunu belirledi. Bu girişimin büyüklüğü ve bu kadar çok konteyneri hızlı bir şekilde yeniden başlatacak otomasyonun mevcut olmadığı gerçeği göz önüne alındığında, Rackspace mühendisleri, olay sırasında anında otomasyon yeteneği oluşturmak için yeni kod yazdılar.

Ne yazık ki, yeniden başlatma süreci hızlandıkça Etki Alanı Adı Sistemi (DNS) sisteminde başka bir sorun ortaya çıktı. MongoS ve mongoD işlemleri çevrimiçi hale geldikçe, DNS araması olarak bilinen bir süreçte DNS çözümleyicilerden bilgi isterler. Yeniden başlatma hızı nedeniyle sürekli DNS aramaları yapıldığında, DNS sunucuları ağır yük altına girdi ve mongoS katmanlarında mongoD işlemlerine yeniden bağlanırken bağlantı zaman aşımlarına yol açtı. Bu artan yükü karşılamak için Rackspace ekibimiz DNS CPU kapasitesini artırdı, ancak daha sonra her mongoS'tan ilgili mongoD süreçlerine sağlıklı bağlantılar oluşturmak için mongoS katmanını ikinci kez yeniden başlatmak zorunda kaldı.

17:05 UTC civarında, yeniden başlatma süreci bazı kümelerin tekrar çevrimiçi olmaya başlamasına olanak sağladı. Veritabanı performansı iyileştikçe ve kümeler istikrar kazandıkça Braze, veri işleme ve mesajlaşma gönderme kapasitesini artırmaya devam etti; ancak bu çaba, daha önce mevcut olmamasından kaynaklanan büyük birikmiş iş nedeniyle karmaşık hale geldi.

Yüzlerce farklı veritabanından oluşan Rackspace veritabanı ortamımızın ölçeği ve karmaşıklığı, kesintinin uzunluğu ve bunun sonucunda ortaya çıkan biriktirme hacmimiz (milyarlarca mesajı ve milyarlarca alınan veri noktasını temsil eden) göz önüne alındığında, Normal iyileşme süreçlerimizin anlık adaptasyonu. Bu, çok büyük miktarda genel işleme kapasitesinin devreye sokulması da dahil olmak üzere, veritabanı kaynaklarının devam eden işleme talepleriyle dengede kalmasını sağlamak için gerekliydi.

Ancak bunu yaparken Braze, tedarik edebildiğimiz sanal CPU sayısı açısından bir AWS sınırına ulaştı ve herhangi bir ek sunucu kapasitesi eklememizi engelledi. Braze ekibi, bu durumu hızla AWS ekibimizle birlikte ele aldı ve bir artış elde ederek mühendislerimizin sunucu işleme kapasitemizi, Black'te ulaşılan önceki maksimum kapasitemizden %50 daha yüksek olan rekor bir seviyeye yükseltmesine olanak tanıdı. Cuma 2023.

UTC 20:30 itibariyle, US 01, US 03 ve US 08 dışındaki tüm ABD kümelerimiz birikmiş iş yığınlarını işlemeyi bitirmişti ve geri kalan kümeler olaydan önceki günden itibaren en yüksek hızlarda veya bu oranların üzerinde işlem yapıyordu. Birkaç saat içinde tüm kümeler gerçek zamanlı işlemeye alındı ​​ve olayın çözüldüğünü ilan ettik.

Braze olaylar sırasında güncellemeleri nasıl iletir?

Bu gibi olaylar sırasında açık ve sık iletişim önemlidir. Genel olarak teknik sorunlar nadir görülen olaylar olsa da ve Braze için bu büyüklükte bir sorun daha önce duyulmamış olsa da, etkilenen taraflarla net ve hızlı bir şekilde iletişim kurmak için her zaman elimizden gelenin en iyisini yapıyoruz.

Bu gibi durumlarda iletişim stratejimizi şekillendiren yol gösterici ilkeler dürüstlük, şeffaflık ve güvendir. Olan biten hakkında dürüst ve açık sözlü olmak için yalnızca tek bir fırsatımız olduğunu ve olaylarla ilgili şeffaflığın - hem o anda hem de çözüm sonrasında - güveni korumak için çok önemli olduğunu biliyoruz. Günün sonunda müşterilerimizin, Braze'in herhangi bir olayı açıklamak, düzeltmek ve tekrarını önlemek için her zaman gücümüzün yettiği her şeyi yapacağından emin olmalarını istiyoruz.

Olaylar sırasında, iletişimleri yönetmek ve durumun ne durumda olduğuna ilişkin düzenli güncellemeler sağlamak için Durum Sayfamızı kullanırız; Müşterilerin, gelişmelerden haberdar olabilmeleri için bu sayfadaki güncellemelere kaydolmalarını şiddetle tavsiye ediyorum. 29 Nisan kesintisi sırasında, bu sık sık Durum Sayfası güncellemelerini, kurucu ortağımız ve CEO'muz Bill Magnuson'dan gelen bir e-postayla destekledik. Bu mesaj tüm Braze kontrol paneli kullanıcılarına gönderildi ve gerektiğinde diğer müşteri paydaşlarıyla paylaşmaları için hesap ekiplerimize iletildi.

Braze olayı nasıl takip etti ve gelecekteki önleme planları

Bu olaydan önce deneyimlerimiz, yedekli ağ anahtarlarımız nedeniyle ağımızın dayanıklı olduğuna inanmamıza yol açmıştı. Ancak kesinti, on yılı aşkın bir süredir bizi iyi bir şekilde destekleyen ağ topolojimizin yıkıcı arızalara karşı savunmasız olduğunu ortaya çıkardı. Artık bunun ileriye dönük olarak geliştirilmesi gerektiği açıktır.

Olaydan bu yana, Braze ve Rackspace arızalı anahtarı değiştirdi ve değiştirdi ve Rackspace mühendislik ekibi, Braze hizmetlerinin dayandığı ağ altyapısının tam denetimini tamamladı. Özellikle garanti kapsamındaki ekipmanlarda donanım arızalarını tahmin etmek inanılmaz derecede zor olsa da, anormallikleri tespit etmek ve hızlı müdahale sağlamak için izleme mevcuttur. Her iki ekip de ekipmanın arızalanması durumunda bile gelecekteki ağ döngülerini önleyecek değişiklikler yapmak için şimdi işbirliği yapıyor. Döngülere karşı korumayı daha da geliştirmek için ağ topolojimizde anlamlı değişiklikler yapmayı planladığımızdan, bazı ağ değişikliklerinin uygulanması zaman alacaktır. Ayrıca karşılaştığımız arıza senaryolarını daha iyi anlamak ve mongoD ve mongoS süreçlerinin ağ arızaları sonrasında kendi kendini iyileştirme yeteneğini geliştirmek için hem Cisco hem de MongoDB ile destek biletleri açtık.

Kısa vadeli değişiklikler konusunda harekete geçmek ve daha büyük bir ağ geliştirmesi gerçekleştirmek için olaydan bu yana Rackspace ile her gün iletişim halindeyiz ve gelişmiş, daha dayanıklı bir ağ tasarımının elde edildiğine güveninceye kadar bunu yapmaya devam edeceğiz.

Bu olaydan ve olayın işletmeniz ve müşterilerinizle ilişkileriniz üzerindeki etkisinden dolayı tekrar özür dilemek istiyorum. Braze'in kullanılamadığı süre kabul edilemez. Mühendislik liderliğimiz ve yönetici ekibimiz, güvenilir ve performanslı bir ortak olarak güveninizi bir kez daha kazanabilmemiz için, kesinti güvenlik açıklarını olabildiğince hızlı ve verimli bir şekilde tespit etmek ve çözmek için gerekli tüm değişiklikleri yapmaya kendini adamıştır.

— Jon