28 Ekim'den başlayarak ve 31 Ekim'de tamamen çözülen Roblox, 73 saatlik bir kesinti yaşadı.¹ Elli milyon oyuncu her gün düzenli olarak Roblox kullanıyor ve oyuncularımızın beklediği deneyimi yaratmak için ölçeğimiz yüzlerce dahili çevrimiçi hizmeti içeriyor. Herhangi bir büyük ölçekli hizmette olduğu gibi, zaman zaman hizmet kesintileri yaşıyoruz, ancak bu kesintinin uzun sürmesi onu özellikle dikkate değer kılıyor. Kapalı kalma süresi için topluluğumuzdan içtenlikle özür dileriz.

Topluluğumuza sorunun temel nedenini, sorunu nasıl ele aldığımızı ve gelecekte benzer sorunların olmasını önlemek için ne yaptığımızı anlamak için bu teknik ayrıntıları paylaşıyoruz. Olay sırasında herhangi bir kullanıcı veri kaybı veya yetkisiz kişilerin herhangi bir bilgiye erişimi olmadığını tekrarlamak isteriz.

Roblox Mühendislik ve HashiCorp'tan teknik personel, Roblox'u hizmete döndürmek için çabaları birleştirdi. İnanılmaz kaynakları bir araya getiren ve sorunlar çözülene kadar bizimle yorulmadan çalışan HashiCorp ekibine teşekkür etmek istiyoruz.

Kesinti Özeti

Kesinti hem süre hem de karmaşıklık açısından benzersizdi. Ekip, temel nedeni anlamak ve hizmeti yeniden başlatmak için bir dizi zorluğu sırayla ele almak zorunda kaldı.

• Kesinti 73 saat sürdü.
• Temel neden iki sorundan kaynaklanıyordu. Alışılmadık derecede yüksek okuma ve yazma yükü altında Consul'da nispeten yeni bir akış özelliğinin etkinleştirilmesi, aşırı çekişmeye ve düşük performansa neden oldu. Ek olarak, belirli yük koşullarımız BoltDB'de patolojik bir performans sorununu tetikledi. Açık kaynaklı BoltDB sistemi, lider seçimi ve veri replikasyonu için önden yazma günlüklerini yönetmek için Consul içinde kullanılır. 
• Birden çok iş yükünü destekleyen tek bir Consul kümesi, bu sorunların etkisini daha da kötüleştirdi.
• Konsolosluk uygulamasında derinlere gömülü olan, birbiriyle alakasız bu iki sorunu teşhis etmede yaşanan zorluklar, uzun süren kesinti süresinin büyük ölçüde sorumlusuydu. 
• Kesinti nedeninin daha iyi görülebilmesini sağlayacak kritik izleme sistemleri, Consul gibi etkilenen sistemlere dayanıyordu. Bu kombinasyon, triyaj sürecini ciddi şekilde engelledi.
• Roblox'u, aynı zamanda kayda değer bir zaman alan, tamamen çökmüş bir durumdan yukarı çıkarma yaklaşımımızda düşünceli ve dikkatliydik.
• İzlememizi geliştirmek, gözlemlenebilirlik yığınımızdaki döngüsel bağımlılıkları kaldırmak ve önyükleme sürecimizi hızlandırmak için mühendislik çabalarını hızlandırdık. 
• Birden çok kullanılabilirlik bölgesine ve veri merkezine geçmek için çalışıyoruz.
• Konsoloslukta bu olayın temel nedeni olan sorunları düzeltiyoruz.

Önsöz: Küme Ortamımız ve HashiStack

Roblox'un çekirdek altyapısı, Roblox veri merkezlerinde çalışır. Kendi donanımımızın yanı sıra bu donanımın üzerinde kendi bilgi işlem, depolama ve ağ sistemlerimizi devreye alıyor ve yönetiyoruz. 18,000'den fazla sunucu ve 170,000 kapsayıcı ile dağıtımımızın ölçeği önemlidir.

Birden fazla sitede binlerce sunucuyu çalıştırmak için, yaygın olarak “ olarak bilinen bir teknoloji paketinden yararlanıyoruz.HashiYığın". Göçebe, konsolos ve Tonoz dünya çapındaki sunucuları ve hizmetleri yönetmek için kullandığımız ve Roblox hizmetlerini destekleyen kapsayıcıları düzenlememize izin veren teknolojilerdir.

Göçebe işleri planlamak için kullanılır. Hangi kapsayıcıların hangi düğümlerde çalışacağına ve bunların hangi bağlantı noktalarında erişilebilir olacağına karar verir. Ayrıca kapsayıcı sağlığını da doğrular. Tüm bu veriler, IP:Port kombinasyonlarından oluşan bir veri tabanı olan bir Hizmet Kaydı'na aktarılır. Roblox hizmetleri, iletişim kurabilmeleri için birbirlerini bulmak için Hizmet Kayıt Defterini kullanır. Bu işleme “hizmet keşfi” denir. Kullanırız konsolos hizmet keşfi, sağlık kontrolleri için oturum kilitleme (üstte yerleşik HA sistemleri için) ve bir KV mağazası olarak.

Consul, iki rolde bir makine kümesi olarak dağıtılır. “Seçmenler” (5 makine) kümenin durumunu yetkili bir şekilde elinde tutuyor; "Oy vermeyen" (5 ek makine), okuma isteklerini ölçeklendirmeye yardımcı olan salt okunur kopyalardır. Herhangi bir zamanda, seçmenlerden biri küme tarafından lider olarak seçilir. Lider, verileri diğer seçmenlere kopyalamaktan ve yazılı verilerin tamamen taahhüt edilip edilmediğini belirlemekten sorumludur. Konsolos adlı bir algoritma kullanır. Raft Lider seçimi için ve durumu kümedeki her düğümün güncellemeler üzerinde anlaşmasını sağlayacak şekilde kümeye dağıtmak. Liderin, belirli bir gün boyunca birkaç kez lider seçimi yoluyla değişmesi nadir değildir.

Aşağıdaki, olaydan sonra Roblox'taki bir Konsolos panosunun yakın tarihli bir ekran görüntüsüdür. Bu blog gönderisinde atıfta bulunulan temel operasyonel metriklerin çoğu normal seviyelerde gösterilmektedir. Örneğin KV Uygulama süresi, 300 ms'den daha az normal kabul edilir ve şu anda 30.6 ms'dir. Konsolos lideri, çok yeni olan son 32 ms'de kümedeki diğer sunucularla temas kurdu.

1. Konsolosluğun Roblox'taki Normal İşlemleri

Ekim olayına giden aylarda, Roblox Konsolos 1.9'dan yükseltildi. Konsolos 1.10 yararlanmak yeni bir akış özelliği. Bu akış özelliği, güncellemeleri Roblox'taki gibi büyük ölçekli kümeler arasında dağıtmak için gereken CPU ve ağ bant genişliğini önemli ölçüde azaltmak için tasarlanmıştır.

İlk Tespit (10/28 13:37)

28 Ekim öğleden sonra V.ault performansı düştü ve tek bir Consul sunucusunda yüksek CPU yükü vardıD. Roblox mühendisleri araştırmaya başladı. Bu noktada oyuncular etkilenmedi.

Erken Triyaj (10/28 13:37 – 10/29 02:00)

İlk soruşturma, Vault ve diğer birçok hizmetin bağlı olduğu Konsolos kümesinin sağlıksız olduğunu ileri sürdü. Spesifik olarak, Consul küme ölçümleri, Consul'un verileri depoladığı temeldeki KV deposu için yüksek yazma gecikmesi gösterdi. Bu işlemlerdeki yüzde 50'lik gecikme genellikle 300 ms'nin altındaydı, ancak şimdi 2 saniyeydi. Donanım sorunları Roblox ölçeğinde olağandışı değildir ve Consul, donanım arızasından kurtulabilir. Bununla birlikte, donanım başarısız olmak yerine yalnızca yavaşsa, genel Consul performansını etkileyebilir. Bu durumda ekip, temel nedenin donanım performansının düşmesinden şüphelendi ve Consul küme düğümlerinden birini değiştirme işlemine başladı. Bu, olayı teşhis etmek için ilk girişimimizdi.. Bu süre zarfında, HashiCorp'tan personel, teşhis ve düzeltmeye yardımcı olmak için Roblox mühendislerine katıldı. Bu noktadan itibaren "ekip" ve "mühendislik ekibi" ile ilgili tüm referanslar hem Roblox hem de HashiCorp personeline atıfta bulunur.

Yeni donanımla bile Consul küme performansı düşmeye devam etti. 16:35'te çevrimiçi oyuncu sayısı normalin %50'sine düştü.

2. 16:35 PST Oyuncu Düşüşü sırasında CCU

Bu düşüş, sistem sağlığında önemli bir bozulma ile aynı zamana denk geldi ve sonuçta tam bir sistem kesintisi yaşandı. Niye ya? Bir Roblox hizmeti başka bir hizmetle konuşmak istediğinde, konuşmak istediği hizmetin konumu hakkında güncel bilgilere sahip olması için Konsolos'a güvenir. Ancak, Consul sağlıklı değilse, sunucular bağlanmak için mücadele eder. Ayrıca Nomad ve Vault, Consul'a güveniyor, bu nedenle Consul sağlıksız olduğunda, sistem yeni kapsayıcılar planlayamaz veya kimlik doğrulama için kullanılan üretim sırlarını alamaz. Kısacası sistem başarısız oldu çünkü Consul tek bir başarısızlık noktasıydı ve Consul sağlıklı değildi.

Bu noktada ekip, neyin yanlış gittiğine dair yeni bir teori geliştirdi: artan trafik. Belki de Consul yavaştı çünkü sistemimiz bir devrilme noktasına geldi ve Consul'un çalıştığı sunucular artık yükü kaldıramadı? Bu, olayın temel nedenini teşhis etmeye yönelik ikinci girişimimizdi.

Olayın ciddiyeti göz önüne alındığında ekip, Consul kümesindeki tüm düğümleri yeni, daha güçlü makinelerle değiştirmeye karar verdi. Bu yeni makinelerde 128 çekirdeğe (2 kat artış) ve daha yeni, daha hızlı NVME SSD diskleri vardı. Saat 19:00'a kadar ekip kümenin çoğunu yeni makinelere taşıdı ancak küme hala sağlıklı değildi. Küme, düğümlerin çoğunun yazma işlemlerine ayak uyduramadığını ve KV yazmalarındaki 50. yüzdelik gecikmenin tipik 2 ms veya daha az yerine hala 300 saniye civarında olduğunu bildiriyordu.

Servise Dönüş Denemesi #1 (10/29 02:00 – 04:00)

Konsolos kümesini sağlıklı bir duruma döndürmeye yönelik ilk iki girişim başarısız oldu. Açıklayamadığımız yeni bir açıklanamayan semptomun yanı sıra yüksek KV yazma gecikmesini hala görebiliyorduk: Konsolos lideri düzenli olarak diğer seçmenlerle uyumsuzdu. 

Ekip, tüm Konsolos kümesini kapatmaya ve kesintinin başlangıcından birkaç saat öncesine ait bir anlık görüntü kullanarak durumunu sıfırlamaya karar verdi. Bunun potansiyel olarak az miktarda sistem yapılandırma veri kaybına neden olacağını anladık (değil kullanıcı veri kaybı). Kesintinin ciddiyeti ve gerekirse bu sistem yapılandırma verilerini elle geri yükleyebileceğimize olan güvenimiz göz önüne alındığında, bunun kabul edilebilir olduğunu düşündük. 

Sistem sağlıklıyken alınan bir anlık görüntüden geri yüklemenin kümeyi sağlıklı bir duruma getireceğini bekliyorduk, ancak bir endişemiz daha vardı. Roblox'un bu noktada sistem üzerinden kullanıcı tarafından oluşturulmuş herhangi bir trafiği olmamasına rağmen, dahili Roblox hizmetleri hala canlı ve görev bilinciyle Konsolos'a ulaşıyordu. bağımlılıklarının yerini öğrenmek için ve sağlık bilgilerini güncellemek için. Bu okuma ve yazma işlemleri küme üzerinde önemli bir yük oluşturuyordu. Küme sıfırlama başarılı olsa bile, bu yükün kümeyi hemen sağlıksız bir duruma geri itebileceğinden endişeliydik. Bu endişeyi gidermek için yapılandırdık iptables erişimi engellemek için kümede. Bu, kümeyi kontrollü bir şekilde geri getirmemize ve Consul'a kullanıcı trafiğinden bağımsız olarak yüklediğimiz yükün sorunun bir parçası olup olmadığını anlamamıza yardımcı olur.

Sıfırlama sorunsuz geçti ve başlangıçta metrikler iyi görünüyordu. Kaldırdığımızda iptables blok, beklendiği gibi döndürülen dahili hizmetlerden hizmet keşfi ve sağlık denetimi yükü. Ancak, Consul performansı tekrar düşmeye başladı ve sonunda başladığımız noktaya geri döndük: KV yazma işlemlerinde 50. yüzdelik dilim 2 saniyede geri döndü. Konsolos'a bağlı hizmetler kendilerini “sağlıksız” olarak işaretlemeye başlıyordu ve sonunda sistem artık tanıdık sorunlu duruma geri döndü. Şimdi saat 04:00'dü. Konsolos'taki yükümüzle ilgili sorun yaratan bir şey olduğu açıktı ve olayın üzerinden 14 saat geçmesine rağmen hala ne olduğunu bilmiyorduk.

Servise Dönüş Denemesi #2 (10/29 04:00 – 10/30 02:00)

Donanım arızasını elemiştik. Daha hızlı donanım yardımcı olmadı ve daha sonra öğrendiğimiz gibi, potansiyel olarak kararlılığa zarar verdi. Konsolos'un iç durumunu sıfırlamak da yardımcı olmadı. Gelen kullanıcı trafiği yoktu, ancak Consul hala yavaştı. biz kaldıraç vardı iptables trafiğin kümeye yavaşça geri dönmesine izin vermek için. Küme, yeniden bağlanmaya çalışan binlerce konteyner hacmi tarafından sağlıksız bir duruma geri mi itildi? Bu, olayın temel nedenini teşhis etmeye yönelik üçüncü girişimimizdi..

Mühendislik ekibi, Consul kullanımını azaltmaya ve ardından dikkatli ve sistematik olarak yeniden uygulamaya karar verdi. Temiz bir başlangıç ​​noktamız olduğundan emin olmak için kalan dış trafiği de engelledik. Consul'u kullanan kapsamlı bir hizmet listesi oluşturduk ve gerekli olmayan tüm kullanımları devre dışı bırakmak için yapılandırma değişikliklerini kullanıma sunduk. Bu işlem, çok çeşitli sistemler ve hedeflenen yapılandırma değişikliği türleri nedeniyle birkaç saat sürdü. Tipik olarak yüzlerce örneğe sahip olan Roblox hizmetleri, tek haneli rakamlara düşürüldü. Sağlık kontrol sıklığı, kümeye ek nefes alma odası sağlamak için 60 saniyeden 10 dakikaya düşürüldü. 16 Ekim 00:29'da, kesintinin başlamasından 24 saat sonra, ekip Roblox'u tekrar çevrimiçi hale getirmek için ikinci girişimine başladı. Bir kez daha, bu yeniden başlatma girişiminin ilk aşaması iyi görünüyordu, ancak 02 Ekim 00:30'ye kadar Consul, bu sefer ona bağlı Roblox hizmetlerinden önemli ölçüde daha az yük ile sağlıksız bir durumdaydı.

Bu noktada, 28'inde ilk fark ettiğimiz performans düşüşüne tek katkıda bulunan faktörün genel Konsolos kullanımının olmadığı açıktı. Bu farkındalık göz önüne alındığında, takım tekrar döndü. Ekip, Consul'a ona bağlı olan Roblox hizmetleri açısından bakmak yerine, ipuçları için Konsolos'un içindekilere bakmaya başladı.

Tartışma Araştırması (10/30 02:00 – 10/30 12:00)

Sonraki 10 saat boyunca, mühendislik ekibi hata ayıklama günlüklerini ve işletim sistemi düzeyindeki ölçümleri daha derinlemesine inceledi. Bu veriler, Konsolos KV'nin yazmalarının uzun süre engellendiğini gösterdi. Başka bir deyişle, "çekişme." Çekişmenin nedeni hemen belli değildi, ancak bir teori, kesintinin başlarında 64'ten 128 CPU Çekirdekli sunucuya geçişin sorunu daha da kötüleştirmiş olabileceğiydi. Ekip, aşağıdaki ekran görüntülerinde gösterilen htop verilerine ve performans hata ayıklama verilerine baktıktan sonra, kesintiden önce kullanılanlara benzer 64 Core sunucuya geri dönmenin değer olduğu sonucuna vardı. Ekip donanımı hazırlamaya başladı: Consul kuruldu, işletim sistemi konfigürasyonları üç kez kontrol edildi ve makineler mümkün olduğunca ayrıntılı bir şekilde hizmete hazır hale getirildi. Ekip daha sonra Consul kümesini 64 CPU Core sunucusuna geri geçirdi, ancak bu değişiklik yardımcı olmadı. Bu, olayın temel nedenini teşhis etmeye yönelik dördüncü girişimimizdi.

3. Daha sonra bunu yukarıda gösterildiği gibi mükemmel bir raporla gösterdik. Zamanın çoğu, Akış aboneliği kod yolu aracılığıyla çekirdek döndürme kilitlerinde harcandı.

4. 128 çekirdekte CPU Kullanımını gösteren HTOP.

Bulunan Kök Nedenler (10/30 12:00 – 10/30 20:00)

Birkaç ay önce, hizmetlerimizin bir alt kümesinde yeni bir Consul akış özelliğini etkinleştirdik. Consul kümesinin CPU kullanımını ve ağ bant genişliğini azaltmak için tasarlanan bu özellik beklendiği gibi çalıştı, bu nedenle önümüzdeki birkaç ay içinde bu özelliği kademeli olarak daha fazla arka uç hizmetimizde etkinleştirdik. 27 Ekim saat 14:00'te, kesintiden bir gün önce, trafik yönlendirmesinden sorumlu bir arka uç hizmetinde bu özelliği etkinleştirdik. Bu sunumun bir parçası olarak, genellikle yıl sonunda gördüğümüz artan trafiğe hazırlanmak için, trafik yönlendirmesini destekleyen düğüm sayısını da %50 oranında artırdık. Sistem, olay başlamadan bir gün önce bu seviyede akışla iyi çalıştı, bu nedenle performansının neden değiştiği başlangıçta net değildi. Ancak, Consul sunucularından gelen mükemmel raporların ve alev grafiklerinin analiziyle, yüksek CPU kullanımına neden olan çekişmeden sorumlu akış kodu yollarının kanıtlarını gördük. Trafik yönlendirme düğümleri de dahil olmak üzere tüm Consul sistemleri için akış özelliğini devre dışı bıraktık. Yapılandırma değişikliği 15:51'de yayılmayı tamamladı ve bu sırada Consul KV yazma için 50. yüzdelik dilim 300 ms'ye düşürüldü. Sonunda bir atılım gerçekleştirdik.

Akış neden bir sorundu? HashiCorp, akışın genel olarak daha verimli olmasına rağmen uygulamasında uzun yoklamaya göre daha az eşzamanlılık kontrol öğesi (Go kanalları) kullandığını açıkladı. Çok yüksek yük altında - özellikle, hem çok yüksek okuma yükü hem de çok yüksek yazma yükü - akış tasarımı, tek bir Go kanalındaki çekişme miktarını artırır, bu da yazma sırasında engellemeye neden olarak onu önemli ölçüde daha az verimli hale getirir. Bu davranış aynı zamanda daha yüksek çekirdek sayılı sunucuların etkisini de açıklıyordu: bu sunucular bir NUMA bellek modeline sahip çift yuvalı mimarilerdi. Paylaşılan kaynaklar üzerindeki ek çekişme, bu mimari altında daha da kötüleşti. Akışı kapatarak, Konsolos kümesinin sağlığını önemli ölçüde iyileştirdik.

Atılıma rağmen, henüz ormandan çıkmamıştık. Konsolos'un aralıklı olarak yeni küme liderleri seçtiğini gördük, bu normaldi, ancak bazı liderlerin akışı devre dışı bırakmadan önce gördüğümüz gecikme sorunlarının aynısını sergilediklerini de gördük, bu normal değildi. Yavaş lider sorununun temel nedenine işaret eden herhangi bir açık ipucu olmadan ve belirli sunucular lider olarak seçilmediği sürece kümenin sağlıklı olduğuna dair kanıtlarla ekip, sorunlu olanı önleyerek sorunu çözmek için pragmatik bir karar verdi. liderler seçilmekten kurtuldu. Bu, ekibin Consul'a dayanan Roblox hizmetlerini sağlıklı bir duruma döndürmeye odaklanmasını sağladı.

Ama yavaş liderlere ne oluyordu? Olay sırasında bunu çözemedik, ancak HashiCorp mühendisleri, kesintiden sonraki günlerde temel nedeni belirledi. Consul, Raft günlüklerini depolamak için BoltDB adlı popüler bir açık kaynaklı kalıcılık kitaplığı kullanır. Bu değil Consul içinde mevcut durumu depolamak için kullanılır, bunun yerine uygulanan işlemlerin yuvarlanan bir günlüğüdür. BoltDB'nin süresiz olarak büyümesini önlemek için Consul, düzenli olarak anlık görüntüler gerçekleştirir. Anlık görüntü işlemi, Consul'un mevcut durumunu diske yazar ve ardından BoltDB'den en eski günlük girişlerini siler. 

Ancak BoltDB'nin tasarımı nedeniyle, en eski günlük girişleri silinse bile BoltDB'nin diskte kullandığı alan asla küçülmez. Bunun yerine, silinen verileri depolamak için kullanılan tüm sayfalar (dosya içindeki 4 kb'lik bölümler) bunun yerine "ücretsiz" olarak işaretlenir ve sonraki yazma işlemleri için yeniden kullanılır. BoltDB, bu ücretsiz sayfaları “serbest liste” adı verilen bir yapıda izler. Tipik olarak, yazma gecikmesi, ücretsiz listeyi güncellemek için geçen süreden anlamlı bir şekilde etkilenmez, ancak Roblox'un iş yükü BoltDB'de serbest liste bakımını son derece pahalı hale getiren patolojik bir performans sorununu ortaya çıkardı. 

Önbelleğe Alma Hizmetinin Geri Yüklenmesi (10/30 20:00 – 10/31 05:00)

Arızanın başlamasının üzerinden 54 saat geçmişti. Akış devre dışı bırakıldığında ve yavaş liderlerin seçili kalmasını önleyen bir süreç uygulandığında, Consul artık tutarlı bir şekilde istikrarlıydı. Ekip, hizmete geri dönüşe odaklanmaya hazırdı.

Roblox, arka ucu için tipik bir mikro hizmet modeli kullanır. Mikro hizmet "yığınının" altında veritabanları ve önbellekler bulunur. Bu veritabanları kesintiden etkilenmedi, ancak düzenli sistem çalışması sırasında çoklu katmanlarında saniyede 1B isteği düzenli olarak işleyen önbelleğe alma sistemi sağlıksızdı. Önbelleklerimiz, temel alınan veritabanlarından kolayca yeniden doldurulabilen geçici verileri depoladığından, önbelleğe alma sistemini yeniden sağlıklı bir duruma getirmenin en kolay yolu, onu yeniden dağıtmaktı.

Önbellek yeniden dağıtım işlemi bir dizi sorunla karşılaştı: 

1. Muhtemelen daha önce gerçekleştirilen Consul küme anlık görüntüsü sıfırlaması nedeniyle, önbellek sisteminin Consul KV'de depoladığı dahili zamanlama verileri yanlıştı. 
2. Küçük önbelleklerin devreye alınması beklenenden daha uzun sürüyordu ve büyük önbelleklerin devreye alınması tamamlanmıyordu. İş planlayıcının sağlıksız değil tamamen açık olarak gördüğü sağlıksız bir düğüm olduğu ortaya çıktı. Bu, iş zamanlayıcının bu düğümdeki önbellek işlerini agresif bir şekilde planlamaya çalışmasına neden oldu, bu da düğümün sağlıksız olması nedeniyle başarısız oldu. 
3. Önbelleğe alma sisteminin otomatik dağıtım aracı, büyük bir kümeyi sıfırdan yeniden başlatmaya yönelik yinelemeli girişimleri değil, zaten büyük bir ölçekte trafiği işleyen büyük ölçekli dağıtımlarda artımlı ayarlamaları desteklemek için oluşturulmuştur. 

Ekip, bu sorunları belirlemek ve çözmek, önbellek sistemlerinin düzgün bir şekilde dağıtıldığından emin olmak ve doğruluğu doğrulamak için gece boyunca çalıştı. 05 Ekim 00:31'da, kesintinin başlamasından 61 saat sonra, sağlıklı bir Konsolos kümemiz ve sağlıklı bir önbellek sistemimiz vardı. Roblox'un geri kalanını ortaya çıkarmaya hazırdık.

Oyuncuların Dönüşü (10/31 05:00 – 10/31 16:00)

Son hizmete dönüş aşaması, resmi olarak 05'i, 00:31'da başladı. Önbelleğe alma sistemine benzer şekilde, ilk kesinti veya sorun giderme aşamalarında çalışan hizmetlerin önemli bir kısmı kapatılmıştı. Ekibin bu hizmetleri doğru kapasite seviyelerinde yeniden başlatması ve bunların doğru şekilde çalıştığını doğrulaması gerekiyordu. Bu sorunsuz gitti ve 10:00'a kadar oyunculara açılmaya hazırdık.

Soğuk önbellekler ve hala emin olmadığımız bir sistemle, sistemi potansiyel olarak tekrar istikrarsız bir duruma getirebilecek bir trafik akışı istemedik. Bir selden kaçınmak için, Roblox'a erişebilecek oyuncu sayısını yönetmek için DNS yönlendirmesini kullandık. Bu, rastgele seçilen oyuncuların belirli bir yüzdesini içeri almamıza izin verirken, diğerleri statik bakım sayfamıza yönlendirilmeye devam etti. Yüzdeyi her artırdığımızda, veritabanı yükünü, önbellek performansını ve genel sistem kararlılığını kontrol ettik. Çalışmalar gün boyunca devam etti ve erişimi yaklaşık %10'luk artışlarla hızlandırdı. En özverili oyuncularımızdan bazılarının DNS yönlendirme planımızı anladığını ve bu bilgileri Twitter'da değiş tokuş etmeye başladığını görmekten keyif aldık, böylece hizmeti geri getirirken "erken" erişim elde edebilirler. Kesinti başladıktan 16 saat sonra Pazar 45:73'te oyuncuların %100'üne erişim verildi ve Roblox tamamen çalışır durumdaydı.

Kesintiden Kaynaklanan Daha Fazla Analiz ve Değişiklikler

Oyuncuların 31 Ekim'de Roblox'a dönmelerine izin verilirken, Roblox ve HashiCorp sonraki hafta boyunca kesinti konusundaki anlayışlarını iyileştirmeye devam etti. Yeni akış protokolündeki belirli çekişme sorunları belirlendi ve izole edildi. HashiCorp varken kıyaslamalı akış Roblox kullanımına benzer bir ölçekte, hem çok sayıda akışın hem de yüksek bir çalkantı oranının birleşiminden ortaya çıkması nedeniyle bu özel davranışı daha önce gözlemlememişlerdi. HashiCorp mühendislik ekibi, belirli çekişme sorununu yeniden oluşturmak ve ek ölçek testleri gerçekleştirmek için yeni laboratuvar ölçütleri oluşturuyor. HashiCorp ayrıca aşırı yük altında çekişmeyi önlemek ve bu koşullarda istikrarlı performans sağlamak için akış sisteminin tasarımını iyileştirmek için çalışıyor. 

Yavaş lider sorununun daha fazla analizi, iki saniyelik Raft veri yazmalarının ve küme tutarlılığı sorunlarının temel nedenini de ortaya çıkardı. Mühendisler, BoltDB'nin iç işleyişini daha iyi anlamak için aşağıdaki gibi alev grafiklerine baktılar.

5. BoltDB serbest liste operasyon analizi.

Daha önce belirtildiği gibi, Consul, Raft günlük verilerini depolamak için BoltDB adlı bir kalıcılık kitaplığı kullanır. Olay sırasında oluşturulan belirli bir kullanım kalıbı nedeniyle, 16 kB yazma işlemleri çok daha büyük hale geliyordu. Bu ekran görüntülerinde gösterilen sorunu görebilirsiniz:

6. Analizde kullanılan ayrıntılı BoldDB istatistikleri.

Önceki komut çıktısı bize birkaç şey söyler:

• Bu 4.2 GB'lık günlük deposu, yalnızca 489 MB gerçek veri depolar (tüm dahili dizinler dahil). 3.8GB "boş" alandır.
• The ücretsiz liste 7.8MB neredeyse bir milyon ücretsiz sayfa kimliği içerdiğinden.

Bu, her günlük ekleme için (bir miktar toplu işlemden sonra her Raft yazma), eklenen gerçek ham veri 7.8 kB veya daha az olsa bile diske yeni bir 16 MB serbest listenin yazıldığı anlamına gelir. 

Bu işlemler üzerindeki geri baskı da tam TCP arabellekleri oluşturdu ve sağlıksız liderler üzerinde 2-3 saniyelik yazma sürelerine katkıda bulundu. Aşağıdaki resim, olay sırasında TCP Zero Windows araştırmasını göstermektedir.

7. TCP sıfır pencerelerini araştırın. Bir TCP alıcısının arabelleği dolmaya başladığında, alma penceresini azaltabilir. Doldurursa, pencereyi sıfıra indirebilir, bu da TCP göndericisine göndermeyi durdurmasını söyler.

HashiCorp ve Roblox, veritabanını "sıkıştırmak" için mevcut BoltDB araçlarını kullanarak performans sorunlarını çözen bir süreç geliştirdi ve devreye aldı.

Son İyileştirmeler ve Gelecek Adımlar

Arızanın üzerinden 2.5 ay geçti. Neler yaptık? Bu zamanı kesintiden öğrenebildiğimiz kadar çok şey öğrenmek, öğrendiklerimize göre mühendislik önceliklerini ayarlamak ve sistemlerimizi agresif bir şekilde güçlendirmek için kullandık. Roblox değerlerimizden biri Topluluğa Saygıdır ve ne olduğunu açıklamak için daha erken bir gönderi yayınlayabilirdik, ancak yayınlamadan önce sistemlerimizin güvenilirliğini artırma konusunda önemli ilerleme kaydetmeyi size, topluluğumuza borçlu olduğumuzu hissettik. 

Tamamlanan ve uçuş sırasındaki güvenilirlik iyileştirmelerinin tam listesi, bu yazı için çok uzun ve çok ayrıntılı, ancak işte önemli öğeler:

Telemetri İyileştirmeleri

Telemetri sistemlerimiz ile Konsolos arasında döngüsel bir bağımlılık vardı, bu da Konsolos sağlıksız olduğunda, neyin yanlış olduğunu bulmamızı kolaylaştıracak telemetri verilerinden yoksun olduğumuz anlamına geliyordu. Bu döngüsel bağımlılığı kaldırdık. Telemetri sistemlerimiz artık izlemek üzere yapılandırıldıkları sistemlere bağlı değil.

Consul ve BoltDB performansına daha iyi görünürlük sağlamak için telemetri sistemlerimizi genişlettik. Sistemin bu kesintiye neden olan duruma yaklaştığına dair herhangi bir işaret varsa, artık son derece hedefli uyarılar alıyoruz. Roblox hizmetleri ve Consul arasındaki trafik düzenlerine daha fazla görünürlük sağlamak için telemetri sistemlerimizi de genişlettik. Sistemimizin davranışına ve performansına yönelik bu ek görünürlük, sistem yükseltmeleri ve hata ayıklama oturumları sırasında bize zaten yardımcı oldu.

Çoklu Erişilebilirlik Alanlarına ve Veri Merkezlerine Genişletme

Tüm Roblox arka uç hizmetlerini bir Konsolos kümesinde çalıştırmak, bizi bu türden bir kesintiye maruz bıraktı. Arka uç hizmetlerimizi barındıracak, coğrafi olarak farklı ek bir veri merkezi için sunucuları ve ağları zaten kurduk. Bu veri merkezlerinde birden fazla kullanılabilirlik alanına geçmek için çalışmalarımız sürüyor; bu çalışmalarımızı hızlandırmak için mühendislik yol haritamızda ve personel planlarımızda büyük değişiklikler yaptık.

Konsolos Yükseltmeleri ve Sharding

Roblox hala hızla büyüyor, bu nedenle birden fazla Consul kümesiyle bile Consul'a yüklediğimiz yükü azaltmak istiyoruz. Hizmetlerimizin Consul'un KV mağazasını ve sağlık kontrollerini nasıl kullandığını gözden geçirdik ve bazı kritik hizmetleri kendi özel kümelerine ayırarak merkezi Consul kümemizdeki yükü daha güvenli bir düzeye indirdik.

Bazı temel Roblox hizmetleri, muhtemelen daha uygun olan başka depolama sistemlerimiz olsa da, verileri depolamak için doğrudan uygun bir yer olarak Consul'un KV mağazasını kullanıyor. Bu verileri daha uygun bir depolama sistemine geçirme sürecindeyiz. Tamamlandığında, bu aynı zamanda Konsolos üzerindeki yükü de azaltacaktır.

Büyük miktarda eskimiş KV verisi keşfettik. Bu eski verilerin silinmesi, Consul performansını iyileştirdi.

BoltDB'nin yerine yeni bir Consul sürümünü dağıtmak için HashiCorp ile yakın bir şekilde çalışıyoruz. cıvata bu, sınırsız serbest liste büyümesiyle aynı sorunu yaşamaz. Yoğun yıl sonu trafiğimiz sırasında karmaşık bir yükseltmeden kaçınmak için bu çabayı kasıtlı olarak yeni yıla erteledik. Yükseltme şu anda test ediliyor ve 1. çeyrekte tamamlanacak.

Önyükleme Prosedürlerinde ve Yapılandırma Yönetiminde İyileştirmeler

Hizmete dönüş çabası, Roblox hizmetlerinin ihtiyaç duyduğu önbelleklerin yerleştirilmesi ve ısınması da dahil olmak üzere bir dizi faktör tarafından yavaşlatıldı. Bu süreci daha otomatik ve daha az hataya açık hale getirmek için yeni araçlar ve süreçler geliştiriyoruz. Özellikle, önbellek sistemimizi sabit bir başlangıçtan hızla getirebilmemizi sağlamak için önbellek dağıtım mekanizmalarımızı yeniden tasarladık. Bunun uygulaması yapılıyor.

Uzun bir süre kapalı kaldıktan sonra büyük işler bulmamızı kolaylaştıracak birkaç Nomad geliştirmesini belirlemek için HashiCorp ile birlikte çalıştık. Bu geliştirmeler, bu ay içinde yapılması planlanan bir sonraki Nomad yükseltmemizin bir parçası olarak dağıtılacak.

Daha hızlı makine konfigürasyon değişiklikleri için mekanizmalar geliştirdik ve devreye aldık.

Akışın Yeniden Başlaması

Başlangıçta, Consul kümesinin CPU kullanımını ve ağ bant genişliğini azaltmak için akışı dağıttık. İş yükümüzle ölçeğimizde yeni bir uygulama test edildikten sonra, onu sistemlerimize dikkatlice yeniden eklemeyi umuyoruz.

Genel Bulut Üzerine Bir Not

Böyle bir kesintinin ardından, Roblox'un genel buluta geçmeyi ve üçüncü bir tarafın temel bilgi işlem, depolama ve ağ hizmetlerimizi yönetmesine izin vermeyi düşünüp düşünmediğini sormak doğaldır.

Roblox değerlerimizden bir diğeri Take The Long View'dur ve bu değer karar verme sürecimizi büyük ölçüde bilgilendirir. Kendi temel altyapımızı yerinde oluşturuyor ve yönetiyoruz, çünkü mevcut ölçeğimizde ve daha da önemlisi, platformumuz büyüdükçe ulaşacağımızı bildiğimiz ölçekte, işimizi ve topluluğumuzu desteklemenin en iyi yolu olduğuna inanıyoruz. Özellikle, arka uç ve ağ uç hizmetleri için kendi veri merkezlerimizi kurup yöneterek, genel buluta kıyasla maliyetleri önemli ölçüde kontrol edebildik. Bu tasarruflar, platformdaki içerik oluşturuculara ödeyebileceğimiz tutarı doğrudan etkiler. Ayrıca, kendi donanımımıza sahip olmak ve kendi uç altyapımızı oluşturmak, performans farklılıklarını en aza indirmemize ve dünya çapındaki oyuncularımızın gecikmelerini dikkatli bir şekilde yönetmemize olanak tanır. Tutarlı performans ve düşük gecikme, genel bulut sağlayıcılarının veri merkezlerinin yakınında bulunması gerekmeyen oyuncularımızın deneyimi için kritik öneme sahiptir.

İdeolojik olarak belirli bir yaklaşıma bağlı olmadığımızı unutmayın: genel bulutu oyuncularımız ve geliştiricilerimiz için en anlamlı olan kullanım durumları için kullanıyoruz. Örnek olarak, patlama kapasitesi, DevOps iş akışlarımızın büyük bölümleri ve şirket içi analizlerimizin çoğu için genel bulut kullanıyoruz. Genel olarak, performans ve gecikme açısından kritik olmayan ve sınırlı ölçekte çalışan uygulamalar için genel bulutun iyi bir araç olduğunu düşünüyoruz. Ancak performans ve gecikme açısından kritik iş yüklerimizin çoğu için kendi altyapımızı şirket içinde oluşturma ve yönetme seçimini yaptık. Bu seçimi zaman, para ve yetenek gerektirdiğini ve aynı zamanda daha iyi bir platform oluşturmamıza olanak sağlayacağını bilerek yaptık. Bu, Take The Long View değerimizle tutarlıdır.

Kesintiden Beri Sistem Kararlılığı

Roblox, genellikle Aralık ayının sonunda bir trafik dalgası alır. Yapacak daha çok güvenilirlik işimiz var, ancak Aralık dalgalanması sırasında Roblox'un tek bir önemli üretim olayı yaşamadığını ve bu dalgalanma sırasında hem Consul hem de Nomad'ın performansının ve istikrarının mükemmel olduğunu bildirmekten memnuniyet duyuyoruz. Görünen o ki, ani güvenilirlik iyileştirmelerimiz şimdiden meyvelerini veriyor ve uzun vadeli projelerimiz sona erdikçe daha da iyi sonuçlar bekliyoruz.

Kapanış Düşünceler

Anlayışları ve destekleri için küresel Roblox topluluğumuza teşekkür etmek istiyoruz. Roblox değerlerimizden bir diğeri de Sorumluluk Al'dır ve burada olanların tüm sorumluluğunu üstleniriz. HashiCorp ekibine bir kez daha yürekten teşekkür etmek istiyoruz. Mühendisleri, bu eşi benzeri görülmemiş kesintinin başlangıcında bize yardım etmek için devreye girdi ve yanımızdan ayrılmadı. Şimdi bile, kesintinin birkaç hafta geride kalmasına rağmen, Roblox ve HashiCorp mühendisleri, benzer bir kesintinin bir daha yaşanmasını önlemek için toplu olarak elimizden gelen her şeyi yaptığımızdan emin olmak için yakın işbirliğine devam ediyor.

Son olarak, buranın çalışmak için neden harika bir yer olduğunu doğruladıkları için Roblox meslektaşlarımıza teşekkür etmek istiyoruz. Roblox'ta nezaket ve saygıya inanıyoruz. İşler iyi giderken medeni ve saygılı olmak kolaydır, ancak asıl sınav, işler zorlaştığında birbirimize nasıl davrandığımızdır. 73 saatlik bir kesinti sırasında, saatin ilerlemesi ve stresin artmasıyla bir noktada, birinin soğukkanlılığını yitirdiğini, saygısızca bir şey söylediğini veya tüm bunların kimin hatası olduğunu yüksek sesle merak ettiğini görmek şaşırtıcı olmaz. Ama öyle olmadı. Birbirimize destek olduk ve hizmet sağlıklı olana kadar XNUMX saat tek bir ekip olarak birlikte çalıştık. Elbette bu kesintiden ve topluluğumuz üzerindeki etkisinden gurur duymuyoruz, ancak vardır Roblox'u hayata döndürmek için bir ekip olarak nasıl bir araya geldiğimizden ve yol boyunca her adımda birbirimize nasıl nezaket ve saygıyla davrandığımızdan gurur duyuyoruz.

Bu deneyimden çok şey öğrendik ve Roblox'u ileriye dönük daha güçlü ve daha güvenilir bir platform haline getirmek için her zamankinden daha fazla kararlıyız.

Tekrar teşekkür ederim. 

¹ Bu blog gönderisindeki tüm tarih ve saatlerin Pasifik Standart Saati'ne (PST) göre olduğunu unutmayın.

Source: https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/