Roblox son 16+ yılda büyüdükçe, milyonlarca sürükleyici 3D ortak deneyimini destekleyen teknik altyapının ölçeği ve karmaşıklığı da arttı. Desteklediğimiz makinelerin sayısı son iki yılda üç kattan fazla artarak 36,000 Haziran 30 itibarıyla yaklaşık 2021'den bugün yaklaşık 145,000'e çıktı. Dünyanın her yerindeki insanlar için her zaman açık olan bu deneyimleri desteklemek, 1,000'den fazla dahili hizmet gerektirir. Maliyetleri ve ağ gecikmesini kontrol etmemize yardımcı olmak için bu makineleri, öncelikle şirket içinde çalışan, özel olarak oluşturulmuş ve hibrit bir özel bulut altyapısının parçası olarak dağıtıyor ve yönetiyoruz.  

Altyapımız şu anda Roblox'a güvenen yaratıcılar da dahil olmak üzere dünya çapında 70 milyondan fazla günlük aktif kullanıcıyı desteklemektedir. ekonomisini onların işleri için. Bu milyonlarca insanın tümü çok yüksek düzeyde bir güvenilirlik beklemektedir. Deneyimlerimizin sürükleyici doğası göz önüne alındığında, bırakın kesintileri, gecikmelere veya gecikmelere karşı bile son derece düşük bir tolerans söz konusudur. Roblox, insanların sürükleyici 3D deneyimlerde bir araya geldiği bir iletişim ve bağlantı platformudur. İnsanlar sürükleyici bir alanda avatarları olarak iletişim kurduğunda, küçük gecikmeler veya aksaklıklar bile bir metin dizisinde veya konferans görüşmesinde olduğundan daha fazla fark edilir.

Ekim 2021'de sistem genelinde bir kesinti yaşadık. Bir veri merkezindeki bir bileşendeki sorunla küçük bir şekilde başladı. Ancak biz araştırırken hızla yayıldı ve sonuçta 73 saatlik bir kesintiyle sonuçlandı. O zamanlar ikisini de paylaşıyorduk. yaşananlarla ilgili ayrıntılar ve konuyla ilgili ilk öğrendiklerimizden bazıları. O zamandan bu yana, bu öğrendiklerimizi inceliyoruz ve aşırı trafik ani artışları, hava durumu, donanım arızası, yazılım hataları veya sadece insanlar hata yapıyor. Bu arızalar meydana geldiğinde, tek bir bileşendeki veya bileşen grubundaki bir sorunun tüm sisteme yayılmamasını nasıl sağlayabiliriz? Bu soru son iki yıldır odak noktamız oldu ve çalışmalar devam ederken şu ana kadar yaptıklarımızın karşılığını almaya başladık. Örneğin, 2023'ün ilk yarısında, 125'nin ilk yarısına kıyasla ayda 2022 milyon etkileşim saati tasarruf ettik. Bugün, daha önce yapmış olduğumuz çalışmaların yanı sıra uzun vadeli geliştirme vizyonumuzu da paylaşıyoruz. daha dayanıklı bir altyapı sistemi.

Bir Geri Durdurucu Oluşturmak

Büyük ölçekli altyapı sistemlerinde küçük ölçekli arızalar günde birçok kez meydana gelir. Bir makinede sorun varsa ve hizmet dışı bırakılması gerekiyorsa, çoğu şirket arka uç hizmetlerinin birden çok örneğini sürdürdüğü için bu durum yönetilebilir. Yani tek bir örnek başarısız olduğunda iş yükünü diğerleri üstleniyor. Bu sık karşılaşılan hataları gidermek için istekler genellikle hata aldıklarında otomatik olarak yeniden deneyecek şekilde ayarlanmıştır.

Bir sistem veya kişi çok agresif bir şekilde yeniden denediğinde bu durum zorlu hale gelir ve bu, küçük ölçekli hataların altyapı boyunca diğer hizmetlere ve sistemlere yayılmasının bir yolu haline gelebilir. Ağ veya kullanıcı yeterince ısrarla yeniden denerse, sonunda o hizmetin her örneğini ve potansiyel olarak diğer sistemleri küresel olarak aşırı yükleyecektir. 2021'deki kesintimiz, büyük ölçekli sistemlerde oldukça yaygın olan bir şeyin sonucuydu: Bir arıza küçük olarak başlar, sonra sisteme yayılır ve o kadar hızlı büyür ki, her şey çökmeden çözülmesi zordur. 

Kesinti yaşadığımız sırada aktif bir veri merkezimiz vardı (içindeki bileşenler yedek görevi görüyordu). Bir sorun mevcut veri merkezini çökerttiğinde yeni bir veri merkezine manuel olarak devretme yeteneğine ihtiyacımız vardı. İlk önceliğimiz Roblox'un yedek dağıtımını yaptığımızdan emin olmaktı, bu yüzden bu yedeği farklı bir coğrafi bölgede bulunan yeni bir veri merkezinde oluşturduk. Bu, en kötü senaryo için ek koruma sağlar: Bir veri merkezi içindeki yeterli sayıda bileşene yayılan ve veri merkezini tamamen kullanılamaz hale getiren bir kesinti. Artık iş yüklerini yöneten bir veri merkezimiz (aktif) ve yedek olarak hizmet veren (pasif) bir veri merkezimiz var. Uzun vadeli hedefimiz, bu aktif-pasif konfigürasyondan, her iki veri merkezinin de iş yüklerini yönettiği ve bir yük dengeleyicinin istekleri gecikme, kapasite ve sağlık durumuna göre aralarında dağıttığı aktif-aktif bir konfigürasyona geçmektir. Bu gerçekleştiğinde, tüm Roblox için daha da yüksek bir güvenilirliğe sahip olmayı ve birkaç saat yerine neredeyse anında yük devretmeyi bekliyoruz.

Hücresel Altyapıya Geçiş

Bir sonraki önceliğimiz, tüm veri merkezinin arızalanma olasılığını azaltmak için her veri merkezinin içinde güçlü patlama duvarları oluşturmaktı. Hücreler (bazı şirketler onlara küme diyor) aslında bir dizi makinedir ve biz bu duvarları böyle yaratıyoruz. Daha fazla yedeklilik sağlamak için hizmetleri hem hücreler içinde hem de hücreler arasında çoğaltıyoruz. Sonuçta, Roblox'taki tüm hizmetlerin hücrelerde çalışmasını istiyoruz, böylece hem güçlü patlama duvarlarından hem de yedeklilikten faydalanabilirler. Bir hücre artık işlevsel değilse, güvenli bir şekilde devre dışı bırakılabilir. Hücreler arasında çoğaltma, hücre onarılırken hizmetin çalışmaya devam etmesini sağlar. Bazı durumlarda hücre onarımı, hücrenin tamamen yeniden sağlanması anlamına gelebilir. Sektör genelinde, tek bir makineyi veya küçük bir makine grubunu silmek ve yeniden hazırlamak oldukça yaygındır, ancak bunu yaklaşık 1,400 makine içeren bir hücrenin tamamı için yapmak pek yaygın değildir. 

Bunun işe yaraması için bu hücrelerin büyük ölçüde tekdüze olması gerekir, böylece iş yüklerini bir hücreden diğerine hızlı ve verimli bir şekilde taşıyabiliriz. Hizmetlerin bir hücrede çalıştırılmadan önce karşılaması gereken belirli gereksinimleri belirledik. Örneğin, hizmetlerin kapsayıcıya alınması gerekir, bu da onları çok daha taşınabilir hale getirir ve herhangi birinin işletim sistemi düzeyinde yapılandırma değişikliği yapmasını engeller. Hücreler için kod olarak altyapı felsefesini benimsedik: Kaynak kodu depomuza, bir hücredeki her şeyin tanımını dahil ediyoruz, böylece onu otomatik araçları kullanarak hızlı bir şekilde sıfırdan yeniden inşa edebiliyoruz. 

Şu anda tüm hizmetler bu gereksinimleri karşılamıyor; bu nedenle, hizmet sahiplerinin mümkün olan yerlerde bu gereksinimleri karşılamasına yardımcı olmak için çalıştık ve hazır olduğunda hizmetleri hücrelere taşımayı kolaylaştırmak için yeni araçlar geliştirdik. Örneğin, yeni dağıtım aracımız, hizmet dağıtımını hücreler arasında otomatik olarak "şeritlere ayırır", böylece hizmet sahiplerinin çoğaltma stratejisi hakkında düşünmelerine gerek kalmaz. Bu seviyedeki titizlik, geçiş sürecini çok daha zorlu ve zaman alıcı hale getiriyor, ancak uzun vadeli getirisi şu şekilde olacaktır: 

• Bir başarısızlığı kontrol altına almak ve diğer hücrelere yayılmasını önlemek çok daha kolaydır; 
• Altyapı mühendislerimiz daha verimli olabilir ve daha hızlı hareket edebilir; Ve 
• Sonuçta hücrelere dağıtılan ürün düzeyindeki hizmetleri oluşturan mühendislerin, hizmetlerinin hangi hücrelerde çalıştığını bilmesine veya endişelenmesine gerek yok.

Daha Büyük Zorlukları Çözmek

Yangın kapılarının alevleri kontrol altına almak için kullanılmasına benzer şekilde, hücreler, tek bir hücrede arızayı tetikleyen her türlü sorunun kontrol altına alınmasına yardımcı olmak için altyapımızda güçlü patlama duvarları görevi görür. Sonunda Roblox'u oluşturan tüm hizmetler, hücrelerin içinde ve arasında yedekli olarak dağıtılacak. Bu çalışma tamamlandıktan sonra sorunlar hâlâ tüm hücreyi çalışmaz hale getirecek kadar geniş bir alana yayılabilir, ancak bir sorunun o hücrenin ötesine yayılması son derece zor olacaktır. Hücreleri birbirinin yerine kullanılabilir hale getirmeyi başarırsak iyileşme çok daha hızlı olacaktır. çünkü yükü farklı bir hücreye devredebileceğiz ve sorunun son kullanıcıları etkilemesini önleyebileceğiz. 

Bunun zorlaştığı nokta, bu hücreleri hataların yayılma olasılığını azaltacak kadar ayırmak ve aynı zamanda işleri performanslı ve işlevsel tutmaktır. Karmaşık bir altyapı sisteminde hizmetlerin sorguları, bilgileri, iş yüklerini vb. paylaşmak için birbirleriyle iletişim kurması gerekir. Bu hizmetleri hücrelere kopyalarken çapraz iletişimi nasıl yöneteceğimiz konusunda dikkatli olmamız gerekir. İdeal bir dünyada trafiği sağlıksız bir hücreden diğer sağlıklı hücrelere yönlendiririz. Fakat bir “ölüm sorgusunu” nasıl yönetebiliriz? neden olan bir hücrenin sağlıksız olması mı? Eğer o sorguyu başka bir hücreye yönlendirirsek, o hücrenin tam da kaçınmaya çalıştığımız şekilde sağlıksız hale gelmesine neden olabilir. Hücrelerin sağlıksız hale gelmesine neden olan trafiği tespit edip sustururken, aynı zamanda "iyi" trafiği sağlıksız hücrelerden kaydıracak mekanizmalar bulmamız gerekiyor. 

Kısa vadede, veri merkezine yapılan isteklerin çoğunun tek bir hücre tarafından karşılanabilmesi için bilgi işlem hizmetlerinin kopyalarını her bir bilgi işlem hücresine dağıttık. Ayrıca hücreler arası trafiğin yükünü dengeliyoruz. Daha ileriye baktığımızda, 2024'te tamamlamayı umduğumuz bir hizmet ağı tarafından desteklenecek yeni nesil bir hizmet keşif süreci oluşturmaya başladık. Bu, hücreler arası iletişime yalnızca şu durumlarda izin verecek gelişmiş politikalar uygulamamıza olanak tanıyacak: yük devretme hücrelerini olumsuz etkilemez. Ayrıca 2024'te, bağımlı istekleri aynı hücredeki bir hizmet sürümüne yönlendirmeye yönelik bir yöntem de gelecek; bu, hücreler arası trafiği en aza indirecek ve böylece hataların hücreler arası yayılma riskini azaltacaktır.

Zirvede, arka uç hizmet trafiğimizin yüzde 70'inden fazlası hücrelerden sunuluyor ve hücrelerin nasıl oluşturulacağı hakkında çok şey öğrendik, ancak 2024'e kadar hizmetlerimizi taşımaya devam ederken daha fazla araştırma ve test bekliyoruz. öte. İlerledikçe bu patlama duvarları giderek daha da güçlenecek.

Her zaman açık bir altyapıyı taşıma

Roblox, dünyanın her yerindeki kullanıcıları destekleyen küresel bir platformdur, bu nedenle hizmetleri yoğun olmayan veya "kapalı kalma süresi" sırasında taşıyamıyoruz, bu da tüm makinelerimizi hücrelere taşıma ve hizmetlerimizi bu hücrelerde çalıştırma sürecini daha da karmaşık hale getiriyor . Üzerinde çalıştıkları makineleri ve onları destekleyen hizmetleri hareket ettirsek bile, desteklenmeye devam etmesi gereken milyonlarca her zaman açık deneyime sahibiz. Bu sürece başladığımızda, ortalıkta duran, kullanılmamış ve bu iş yüklerini taşıyabilecek on binlerce makinemiz yoktu. 

Ancak gelecekteki büyüme beklentisiyle satın alınan az sayıda ek makinemiz vardı. Başlangıç ​​olarak bu makineleri kullanarak yeni hücreler oluşturduk, ardından iş yüklerini onlara aktardık. Güvenilirliğin yanı sıra verimliliğe de değer veriyoruz; bu nedenle, "yedek" makinelerimiz bittiğinde dışarı çıkıp daha fazla makine satın almak yerine, geçiş yaptığımız makineleri silerek ve yeniden hazırlayarak daha fazla hücre oluşturduk. Daha sonra iş yüklerini yeniden sağlanan makinelere taşıdık ve süreci yeniden başlattık. Bu süreç karmaşıktır; makineler değiştirilip hücrelere yerleştirilmek üzere serbest bırakıldıkça, ideal ve düzenli bir şekilde serbest kalmıyorlar. Veri salonları arasında fiziksel olarak parçalanmış durumdalar, bu da onları parça parça tedarik etmemize neden oluyor; bu da, donanım konumlarını büyük ölçekli fiziksel arıza etki alanlarıyla aynı hizada tutmak için donanım düzeyinde bir birleştirme işlemi gerektiriyor. 

Altyapı mühendisliği ekibimizin bir kısmı, mevcut iş yüklerini eski veya "hücre öncesi" ortamımızdan hücrelere taşımaya odaklanmıştır. Bu çalışma, binlerce farklı altyapı hizmetini ve binlerce arka uç hizmetini yeni oluşturulan hücrelere taşıyana kadar devam edecek. Bazı karmaşık faktörlerden dolayı bunun önümüzdeki yılın tamamına ve muhtemelen 2025 yılına kadar sürmesini bekliyoruz. İlk olarak, bu çalışma sağlam aletlerin inşa edilmesini gerektirir. Örneğin, yeni bir hücreyi devreye aldığımızda, kullanıcılarımızı etkilemeden çok sayıda hizmeti otomatik olarak yeniden dengelemek için araçlara ihtiyacımız var. Altyapımızla ilgili varsayımlarla oluşturulan hizmetleri de gördük. Bu hizmetleri, gelecekte hücrelere geçtikçe değişebilecek şeylere bağlı olmayacak şekilde revize etmemiz gerekiyor. Ayrıca, hem hücresel mimariyle iyi çalışmayan bilinen tasarım modellerini aramanın bir yolunu hem de taşınan her hizmet için yöntemsel bir test sürecini uygulamaya koyduk. Bu süreçler, bir hizmetin hücrelerle uyumsuz olmasından kaynaklanan, kullanıcının karşılaştığı sorunların üstesinden gelmemize yardımcı olur.

Günümüzde 30,000'e yakın makine hücreler tarafından yönetilmektedir. Bu, toplam filomuzun yalnızca küçük bir kısmını oluşturuyor ancak şu ana kadar oyunculara herhangi bir olumsuz etki yaratmadan çok yumuşak bir geçiş gerçekleştirdik. Nihai hedefimiz, sistemlerimizin her ay yüzde 99.99 kullanıcı çalışma süresi elde etmesidir; bu, etkileşim saatlerinin yüzde 0.01'inden fazlasını kesintiye uğratmayacağımız anlamına gelir. Sektör genelinde kesinti süresi tamamen ortadan kaldırılamaz, ancak amacımız Roblox kesinti süresini neredeyse fark edilemeyecek kadar azaltmaktır.

Ölçeklendikçe geleceğe hazırız

İlk çabalarımız başarılı olsa da, hücreler üzerindeki çalışmalarımız henüz bitmiş değil. Roblox ölçeklenmeye devam ettikçe bu ve diğer teknolojiler aracılığıyla sistemlerimizin verimliliğini ve dayanıklılığını artırmak için çalışmaya devam edeceğiz. İlerledikçe platform sorunlara karşı giderek daha dayanıklı hale gelecek ve ortaya çıkan sorunlar, platformumuzdaki insanlar için giderek daha az görünür ve rahatsız edici hale gelecektir.

Özetle bugüne kadar elimizde: 

• İkinci bir veri merkezi kurarak aktif/pasif durumuna başarıyla ulaştık. 
• Aktif ve pasif veri merkezlerimizde hücreler oluşturduk ve arka uç hizmet trafiğimizin yüzde 70'inden fazlasını başarıyla bu hücrelere taşıdık.
• Altyapımızın geri kalanını taşımaya devam ederken tüm hücreleri tekdüze tutmak için izlememiz gereken gereksinimleri ve en iyi uygulamaları belirleyin. 
• Hücreler arasında daha güçlü “patlama duvarları” inşa etme yönünde sürekli bir süreç başlattı. 

Bu hücreler daha fazla değiştirilebilir hale geldikçe, hücreler arasında daha az karışma olacaktır. Bu, izleme, sorun giderme ve hatta iş yüklerini otomatik olarak değiştirme konusunda otomasyonun artırılması açısından bizim için bazı çok ilginç fırsatların kilidini açıyor. 

Eylül ayında ayrıca veri merkezlerimizde aktif/aktif denemeler yürütmeye başladık. Bu, güvenilirliği artırmak ve yük devretme sürelerini en aza indirmek için test ettiğimiz başka bir mekanizmadır. Bu deneyler, tamamen aktif-aktif olmaya doğru ilerlerken yeniden üzerinde çalışmamız gereken, büyük ölçüde veri erişimiyle ilgili olan bir dizi sistem tasarım modelinin belirlenmesine yardımcı oldu. Genel olarak deneme, sınırlı sayıda kullanıcımızdan gelen trafik için çalışır durumda kalmasını sağlayacak kadar başarılıydı. 

Platforma daha fazla verimlilik ve dayanıklılık kazandırmak için bu çalışmayı ilerletmeye devam etmekten heyecan duyuyoruz. Hücreler ve aktif-aktif altyapıya yönelik bu çalışma, diğer çabalarımızla birlikte, milyonlarca insan için güvenilir, yüksek performanslı bir hizmet sağlayıcıya dönüşmemizi ve bir milyar insanı gerçek anlamda birbirine bağlamak için çalışırken ölçeklenmeye devam etmemizi mümkün kılacaktır. zaman.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://blog.roblox.com/2023/12/making-robloxs-infrastructure-efficient-resilient/