Roblox'un Altyapısını Nasıl Daha Verimli ve Dayanıklı Hale Getiriyoruz
Roblox, son 16 yılı aşkın süredir büyüdükçe, milyonlarca sürükleyici 3D ortak deneyimi destekleyen teknik altyapının ölçeği ve karmaşıklığı da artmıştır. Desteklediğimiz makine sayısı, son iki yılda üç katından fazla artarak 30 Haziran 2021 itibarıyla yaklaşık 36.000'den bugün yaklaşık 145.000'e ulaşmıştır. Dünyanın dört bir yanındaki insanlar için bu kesintisiz deneyimleri desteklemek, 1.000'den fazla dahili hizmet gerektirir. Maliyetleri ve ağ gecikmesini kontrol etmemize yardımcı olması için, bu makineleri esas olarak tesis içinde çalışan, özel olarak oluşturulmuş ve hibrit bir özel bulut altyapısının parçası olarak devreye alıyoruz ve yönetiyoruz.
Altyapımız şu anda, işleri için Roblox ekonomisine güvenen içerik oluşturucular da dahil olmak üzere, dünya çapında 70 milyondan fazla günlük aktif kullanıcıyı desteklemektedir. Bu milyonlarca insanın tamamı, çok yüksek düzeyde bir güvenilirlik beklemektedir. Deneyimlerimizin sürükleyici doğası göz önüne alındığında, kesintiler bir yana, gecikmelere veya gecikme sürelerine karşı tolerans son derece düşüktür. Roblox, insanların sürükleyici 3D deneyimlerinde bir araya geldiği bir iletişim ve bağlantı platformudur. İnsanlar sürükleyici bir alanda avatarları aracılığıyla iletişim kurarken, en ufak gecikmeler veya aksaklıklar bile bir metin sohbeti veya konferans görüşmesindekinden daha fazla fark edilir.
Ekim 2021'de sistem genelinde bir kesinti yaşadık. Kesinti, bir veri merkezindeki tek bir bileşende yaşanan küçük bir sorunla başladı. Ancak, sorunu araştırırken hızla yayıldı ve sonuçta 73 saatlik bir kesintiye neden oldu. O zaman, hem olanlarla ilgili ayrıntıları hem de bu sorundan edindiğimiz ilk dersleri paylaştık. O zamandan beri, bu dersleri inceliyor ve aşırı trafik artışları, hava koşulları, donanım arızaları, yazılım hataları veya sadece insan hataları gibi faktörler nedeniyle tüm büyük ölçekli sistemlerde meydana gelen arıza türlerine karşı altyapımızın dayanıklılığını artırmak için çalışıyoruz. Bu arızalar meydana geldiğinde, tek bir bileşendeki veya bir grup bileşendeki sorunun tüm sisteme yayılmamasını nasıl sağlarız? Bu soru, son iki yıldır odak noktamız olmuştur ve çalışmalarımız devam etmekte olsa da, şu ana kadar yaptıklarımız şimdiden meyvesini vermektedir. Örneğin, 2023'ün ilk yarısında, 2022'nin ilk yarısına kıyasla aylık 125 milyon etkileşim saatinden tasarruf ettik. Bugün, halihazırda yaptığımız çalışmaların yanı sıra, daha dayanıklı bir altyapı sistemi oluşturmaya yönelik uzun vadeli vizyonumuzu da paylaşıyoruz.
Bir Yedekleme Sistemi 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 oluşur ve hizmet dışı bırakılması gerekirse, bu durum yönetilebilir bir durumdur çünkü çoğu şirket arka uç hizmetlerinin birden fazla örneğini barındırır. Böylece, tek bir örnek arızalandığında, diğerleri iş yükünü üstlenir. Bu sık arızaları gidermek için, istekler genellikle bir hata aldıklarında otomatik olarak yeniden denenmek üzere ayarlanır.
Bir sistem veya kişi çok agresif bir şekilde yeniden deneme yaparsa bu durum zorlaşır; bu da küçük ölçekli arızaların altyapı genelinde diğer hizmetlere ve sistemlere yayılmasına neden olabilir. Ağ veya bir kullanıcı yeterince ısrarlı bir şekilde yeniden deneme yaparsa, sonunda o hizmetin tüm örnekleri ve potansiyel olarak diğer sistemler de küresel olarak aşırı yüklenir. 2021'deki kesintimiz, büyük ölçekli sistemlerde oldukça yaygın olan bir durumun sonucuydu: Bir arıza küçük başlar, ardından sistem genelinde yayılır ve her şey çökmeden önce çözülmesi zor olacak kadar hızla büyür.
Kesinti anında, aktif bir veri merkezimiz vardı (içinde yedek olarak işlev gören bileşenler ile). Bir sorun mevcut veri merkezini devre dışı bıraktığında, manuel olarak yeni bir veri merkezine geçiş yapabilme yeteneğine ihtiyacımız vardı. Öncelikli hedefimiz, Roblox'un yedek bir dağıtımına sahip olmayı sağlamaktı; bu nedenle, farklı bir coğrafi bölgede bulunan yeni bir veri merkezinde bu yedeği kurduk. Bu, en kötü senaryo için ek koruma sağladı: bir kesintinin veri merkezi içindeki bileşenlere yayılması ve veri merkezinin tamamen çalışmaz hale gelmesi. Artık iş yüklerini yöneten bir veri merkezimiz (aktif) ve yedek olarak hizmet veren bir veri merkezimiz (pasif) bulunmaktadır. Uzun vadeli hedefimiz, bu aktif-pasif yapılandırmadan, her iki veri merkezinin de iş yüklerini yönettiği ve bir yük dengeleyicinin gecikme süresi, kapasite ve durum bilgilerine göre istekleri bu merkezler arasında dağıttığı bir aktif-aktif yapılandırmaya geçmektir. Bu yapılandırma devreye girdiğinde, Roblox'un tamamında daha da yüksek bir güvenilirlik elde etmeyi ve birkaç saat yerine neredeyse anında yedekleme yapabilmeyi bekliyoruz.
Hücresel Altyapıya Geçiş
Bir sonraki önceliğimiz, veri merkezinin tamamının arızalanma olasılığını azaltmak için her veri merkezi içinde güçlü koruma duvarları oluşturmaktı. Hücreler (bazı şirketler bunlara küme adını verir), esasen bir dizi makineden oluşur ve bu duvarları oluşturmamızı sağlar. Ek yedeklilik sağlamak için hizmetleri hem hücreler içinde hem de hücreler arasında çoğaltıyoruz. Nihai hedefimiz, Roblox'taki tüm hizmetlerin hücrelerde çalışmasını sağlamak ve böylece hem güçlü koruma duvarlarından hem de yedeklilikten yararlanabilmelerini sağlamaktır. Bir hücre artık işlevsel değilse, güvenli bir şekilde devre dışı bırakılabilir. Hücreler arası çoğaltma, hücre onarılırken hizmetin çalışmaya devam etmesini sağlar. Bazı durumlarda, hücre onarımı, hücrenin tamamen yeniden yapılandırılması anlamına gelebilir. Sektör genelinde, tek bir makineyi veya küçük bir makine grubunu silip yeniden yapılandırmak oldukça yaygındır, ancak yaklaşık 1.400 makine içeren bir hücrenin tamamı için bunu yapmak yaygın değildir.
Bunun işe yaraması için, bu hücrelerin büyük ölçüde tek tip 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ışmadan önce karşılaması gereken belirli gereksinimler belirledik. Örneğin, hizmetler konteynerleştirilmelidir; bu, onları çok daha taşınabilir hale getirir ve kimsenin işletim sistemi düzeyinde yapılandırma değişiklikleri yapmasını engeller. Hücreler için "altyapı olarak kod" felsefesini benimsedik: Kaynak kod depomuzda, bir hücrede bulunan her şeyin tanımını dahil ediyoruz, böylece otomatik araçları kullanarak onu sıfırdan hızlı bir şekilde yeniden oluşturabiliriz.
Şu anda tüm hizmetler bu gereksinimleri karşılamadığından, hizmet sahiplerinin mümkün olduğunca bu gereksinimleri karşılamasına yardımcı olmak için çalıştık ve hazır olduklarında hizmetlerin hücrelere kolayca taşınmasını sağlamak için yeni araçlar geliştirdik. Örneğin, yeni dağıtım aracımız bir hizmet dağıtımını hücreler arasında otomatik olarak "dağıtır", böylece hizmet sahiplerinin çoğaltma stratejisi hakkında düşünmesine gerek kalmaz. Bu titizlik düzeyi, taşıma sürecini çok daha zorlu ve zaman alıcı hale getirir, ancak uzun vadede elde edilecek kazanç, aşağıdakileri içeren bir sistem olacaktır:
- Bir arızayı kontrol altına almak ve diğer hücrelere yayılmasını önlemek çok daha kolaydır;
- Altyapı mühendislerimiz daha verimli çalışabilir ve daha hızlı hareket edebilir; ve
- Sonuçta hücrelere dağıtılan ürün düzeyindeki hizmetleri geliştiren mühendislerin, hizmetlerinin hangi hücrelerde çalıştığını bilmelerine veya bu konuda endişelenmelerine gerek kalmaz.
Daha Büyük Zorlukları Çözmek
Yangın kapılarının alevleri kontrol altına almak için kullanıldığı gibi, hücreler de altyapımız içinde güçlü patlama duvarları görevi görerek, tek bir hücrede arızaya neden olan her türlü sorunu kontrol altına almaya yardımcı olur. Sonunda, Roblox'u oluşturan tüm hizmetler hücrelerin içinde ve arasında yedekli olarak dağıtılacaktır. Bu çalışma tamamlandığında, sorunlar hala tüm bir hücreyi çalışmaz hale getirecek kadar yayılabilir, ancak bir sorunun o hücrenin ötesine yayılması son derece zor olacaktır. Ve hücreleri birbirinin yerine kullanılabilir hale getirmeyi başarırsak, farklı bir hücreye yedekleme yapıp sorunun son kullanıcıları etkilemesini önleyebileceğimiz için kurtarma işlemi önemli ölçüde daha hızlı olacaktır.
İşin zor kısmı, performansı ve işlevselliği korurken, hataların yayılma olasılığını azaltacak kadar bu hücreleri birbirinden ayırmaktı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 çoğaltırken, çapraz iletişimi nasıl yöneteceğimiz konusunda dikkatli olmamız gerekir. İdeal bir dünyada, sağlıksız bir hücreden gelen trafiği diğer sağlıklı hücrelere yönlendiririz. Peki, bir hücrenin sağlıksız hale gelmesine neden olan bir "ölüm sorgusu"nu nasıl yönetiriz? Bu sorguyu başka bir hücreye yönlendirirsek, tam da kaçınmaya çalıştığımız şekilde o hücrenin de sağlıksız hale gelmesine neden olabiliriz. Hücrelerin sağlıksız hale gelmesine neden olan trafiği tespit edip engellerken, "iyi" trafiği sağlıksız hücrelerden uzaklaştırmak için mekanizmalar bulmamız gerekir.
Kısa vadede, veri merkezine gelen isteklerin çoğunun tek bir hücre tarafından karşılanabilmesi için her hesaplama hücresine hesaplama hizmetlerinin kopyalarını dağıttık. Ayrıca hücreler arasında trafiği dengeliyoruz. Daha uzun vadede ise, bir hizmet ağı tarafından kullanılacak yeni nesil bir hizmet keşif süreci oluşturmaya başladık; bunu 2024 yılında tamamlamayı umuyoruz. Bu, yedek hücrelere olumsuz etki etmeyeceği durumlarda hücreler arası iletişime izin verecek gelişmiş politikalar uygulamamızı sağlayacaktır. Ayrıca 2024'te, bağımlı istekleri aynı hücredeki bir hizmet sürümüne yönlendirecek bir yöntem de devreye girecek; bu, hücreler arası trafiği en aza indirecek ve dolayısıyla arızaların hücreler arası yayılma riskini azaltacaktır.
En yoğun zamanlarda, arka uç hizmet trafiğimizin yüzde 70'inden fazlası hücrelerin dışından sağlanıyor ve hücrelerin nasıl oluşturulacağı konusunda çok şey öğrendik, ancak 2024 ve sonrasında hizmetlerimizi taşıma sürecine devam ederken daha fazla araştırma ve test yapmayı planlıyoruz. İlerledikçe, bu koruma duvarları giderek daha da güçlenecek.
Sürekli çalışır durumda olan bir altyapının taşınması
Roblox, dünyanın her yerindeki kullanıcıları destekleyen küresel bir platformdur; bu nedenle, hizmetleri yoğun olmayan saatlerde veya "kesinti sürelerinde" taşıyamayız, bu da tüm makinelerimizi hücrelere ve hizmetlerimizi bu hücrelerde çalışacak şekilde taşıma sürecini daha da karmaşık hale getirir. Çalıştıkları makineleri ve onları destekleyen hizmetleri taşırken bile, desteklenmeye devam etmesi gereken milyonlarca sürekli açık deneyimimiz var. Bu sürece başladığımızda, bu iş yüklerini taşıyabileceğimiz, kullanılmadan duran on binlerce makinemiz yoktu.
Ancak, gelecekteki büyümeyi öngörerek satın alınmış az sayıda ek makinemiz vardı. Başlangıç olarak, bu makineleri kullanarak yeni hücreler oluşturduk, ardından iş yüklerini bu hücrelere taşıdık. Verimliliğin yanı sıra güvenilirliğe de önem veriyoruz, bu nedenle "yedek" makinelerimiz bittiğinde dışarı çıkıp daha fazla makine satın almak yerine, taşıma işlemini tamamladığımız makineleri silip yeniden yapılandırarak daha fazla hücre oluşturduk. Ardından iş yüklerini bu yeniden yapılandırılmış makinelere taşıdık ve süreci baştan başlattık. Bu süreç karmaşıktır; makineler değiştirilip hücrelere dahil edilmek üzere boşaldıkça, ideal ve düzenli bir şekilde boşalmamaktadır. Makineler veri salonları arasında fiziksel olarak dağınık durumdadır, bu da onları parça parça yeniden yapılandırmamızı gerektirir; bu da donanım konumlarını büyük ölçekli fiziksel arıza alanlarıyla uyumlu tutmak için donanım düzeyinde bir birleştirme süreci gerektirir.
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 edecektir. Bazı karmaşık faktörler nedeniyle bunun tüm gelecek yılı ve muhtemelen 2025'e kadar süreceğini tahmin ediyoruz. İlk olarak, bu çalışma için sağlam araçlar geliştirilmesi gerekiyor. Örneğin, yeni bir hücreyi devreye aldığımızda, kullanıcılarımızı etkilemeden çok sayıda hizmeti otomatik olarak yeniden dengeleyecek araçlara ihtiyacımız var. Ayrıca, altyapımızla ilgili varsayımlara dayalı olarak oluşturulmuş hizmetler de gördük. Hücrelere geçerken gelecekte değişebilecek unsurlara bağımlı olmamaları için bu hizmetleri revize etmemiz gerekiyor. Ayrıca, hücresel mimariyle iyi çalışmayacak bilinen tasarım kalıplarını aramak için bir yolun yanı sıra, taşınan her hizmet için metodik bir test süreci de uyguladık. Bu süreçler, bir hizmetin hücrelerle uyumsuz olmasından kaynaklanan kullanıcı sorunlarını önlememize yardımcı oluyor.
Bugün, 30.000'e yakın makine hücreler tarafından yönetiliyor. Bu, toplam filomuzun sadece bir kısmı olsa da, şu ana kadar oyuncular üzerinde herhangi bir olumsuz etki yaratmadan çok sorunsuz bir geçiş süreci yaşandı. Nihai hedefimiz, sistemlerimizin her ay %99,99 kullanıcı çalışma süresi elde etmesidir; bu, etkileşim saatlerinin %0,01'inden fazlasını kesintiye uğratmayacağımız anlamına gelir. Sektör genelinde kesinti süreleri tamamen ortadan kaldırılamaz, ancak hedefimiz Roblox kesinti sürelerini neredeyse fark edilmeyecek bir düzeye indirmektir.
Büyürken geleceğe hazırlık
İlk çabalarımız başarılı olsa da, hücreler üzerindeki çalışmalarımız henüz bitmiş değil. Roblox büyümeye 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. Bu süreçte platform, sorunlara karşı giderek daha dayanıklı hale gelecek ve ortaya çıkan sorunlar, platformumuzdaki kullanıcılar için giderek daha az görünür ve rahatsız edici hale gelecektir.
Özetle, bugüne kadar şunları başardık:
- İkinci bir veri merkezi kurduk ve 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ı bu hücrelere başarıyla taşıdık.
- Altyapımızın geri kalanını taşıma sürecine devam ederken, tüm hücreleri tek tip tutmak için uymamız gereken gereklilikleri ve en iyi uygulamaları belirledik.
- Hücreler arasında daha güçlü "patlama duvarları" oluşturmaya yönelik sürekli bir süreci başlattık.
Bu hücreler birbirleriyle daha fazla değiştirilebilir hale geldikçe, hücreler arasındaki çapraz iletişim azalacaktır. Bu, izleme, sorun giderme ve hatta iş yüklerini otomatik olarak kaydırma konusunda otomasyonu artırmak açısından bizim için çok ilginç fırsatlar sunuyor.
Eylül ayında, veri merkezlerimizde aktif/aktif deneyler yapmaya da başladık. Bu, güvenilirliği artırmak ve yük devretme sürelerini en aza indirmek için test ettiğimiz bir başka mekanizmadır. Bu deneyler, tamamen aktif-aktif hale gelme yolunda yeniden çalışmamız gereken, büyük ölçüde veri erişimiyle ilgili bir dizi sistem tasarım modelini belirlememize yardımcı oldu. Genel olarak, deney, sınırlı sayıda kullanıcımızın trafiği için çalışmaya devam edecek kadar başarılı oldu.
