Roblox Cloud'da Ağ Paketi Kaybı ve Gecikme İzleme

Roblox Ağ Mühendisliği ekibi, dünya çapında dağıtılmış veri merkezi ve erişim noktası (POP) siteleriyle büyük ve hızla büyüyen bir ağı yönetmektedir. Roblox platformunda mükemmel bir kullanıcı deneyimi sunmak, bu ağın performansına ve güvenilirliğine bağlıdır. Ağ operatörlerinin ağdaki sorunları tespit edip gidermesi ve ağ performansını görebilmesi çok önemlidir. Ağ izleme genellikle cihaz istatistikleri, hata metrikleri ve sistem günlüklerini periyodik olarak toplayarak ve bunları zaman serisi veya günlük veritabanında depolayarak gerçekleştirilir. Veriler, SNMP, Netconf, Rest API'leri veya Akış Telemetrisi gibi standart protokoller kullanılarak itme veya çekme modeliyle toplanır.

Yalnızca cihaz telemetrisi yoluyla ağ arızalarının tespit edilmesi, pasif bir izleme tekniği olduğu için bazı eksikliklere sahiptir. Bu yöntem, ağ düğümlerinin anormal durumları ortaya çıkar çıkmaz tespit edip raporlama yeteneğine bağlıdır. Cihaz her zaman verileri geri bildirmeyebilir veya bazı durumlarda tüm sağlık istatistikleri olağan telemetri toplama yöntemlerine açık olmayabilir. Ayrıca, ağ cihazları bazen hatalı veriler sağlayabilir veya trafiği sessizce kara deliğe gönderebilir. Cihaz telemetrisinin en büyük sınırlaması, ağın uçtan uca erişilebilirliği, paket kaybı ve gecikme istatistikleri hakkında çok az görünürlük sağlamasıdır.

Bir ağı aktif olarak izlemenin harika bir yolu, aşağıdaki şekillerde gösterildiği gibi bir ağ üzerinden düzenli olarak sentezlenmiş sondalar iletmektir.

Üretim kesintilerini giderirken, ağ operatörlerine sık sık "Ağ paketleri düşürüyor mu?" veya "Hizmet bağlantısını etkileyen devam eden bir ağ arızası var mı?" gibi sorular sorulur. Geçmiş paket kaybı ve gecikme verilerine erişmeden bu tür soruları yanıtlamak için, ağ içindeki çok sayıda bağlantı ve düğümü incelemeleri gerekir.

Güvenilir ve ölçeklenebilir bir ağ örgüsü izleme sistemi tasarımı

Bir kara kutu ağ izleme sisteminin paket kaybını veya gecikme artışlarını etkili bir şekilde tespit edebilmesi için, ağın farklı bölümlerinde sürekli sondalama yapılması gerekir. Veri merkezi ağları, kullanıcı trafiği için düğümler arasındaki tüm bağlantıları kullanır. Üretim ağı cihazları BGP çalıştırır ve trafiği birden fazla eşit maliyetli yol üzerinden dengeler. Ağ topolojisindeki değişiklikler, normal koşullar altında genellikle saniyeler içinde yönlendirme tablosu güncellemeleriyle yansıtılır. Ağ paket kaybını doğru bir şekilde ölçmek için, test sondaları tüm ağ düğümlerini ve bağlantılarını kapsayacak şekilde mümkün olduğunca çok sayıda yol üzerinden ilerlemelidir. Bizimki gibi dünya çapında birden fazla siteyi kapsayan büyük bir ağda, her düğüm veya raf çifti arasında sondalama yapmak ölçeklenebilir değildir. Görünürlük düzeyinden ödün vermeyen, daha sürdürülebilir bir çözüm olarak, her site içindeki raflar arasında bir N² ağını ve tüm siteler arasında başka bir N² ağını sondalamayı seçtik.

Ağı neyle test ediyoruz?

Test probları, üretim ağından geçen canlı trafiği taklit etmelidir. Ağımızdaki trafiğin çoğu TCP, UDP veya HTTP'dir ve bunların her biri potansiyel olarak problar için kullanılabilir. TCP problamanın sorunlarından biri, büyük bir ağı izlemek için gereken bağlantı sayısına ölçeklenebilecek kadar hafif olmamasıdır. TCP ile ilgili bir diğer sorun ise, yerleşik akış kontrolü ve kayan pencere tabanlı iletimlerin, anlık paket düşüşlerini ölçmek veya tespit etmek için ideal olmayan değişken bir prob iletim hızına yol açmasıdır. Ping ve traceroute tarafından kullanılan ICMP, genellikle sunucularda veya ağ düğümlerinde hız sınırlamasına tabidir. Bu, kullanılabilecek ICMP problarının toplam hızını sınırlar. HTTP istekleri, uygulama katmanında daha üstte yer alır ve sunucu veya uygulama performansı gibi ağ dışındaki bazı faktörlere bağlıdır. HTTP, sonuçlara ayrıştırılması zor olan ek bir değişken faktör ekler. Bu sistemin amacı, esas olarak OSI katman 4 ve altındaki katmanlarda çalışan temel ağ altyapısının performansını izlemektir. Ağımızdaki birincil taşıma katmanı protokolü olmasının yanı sıra bu nedenlerle UDP sondalarını seçtik.

Nereden sondaj yapıyoruz?

Büyük bir toplam sonda hızı elde etmenin ve aynı zamanda çok sayıda ağ yolunu kapsamanın bir yolu, sondaları iletmek için mümkün olduğunca çok sayıda hesaplama düğümü kullanmaktır. Bunun iki avantajı vardır: sondaları üreten sistemler üzerindeki yükü dağıtmaya yardımcı olur ve bunları taşıyan ağ bağlantı noktalarının sayısını artırır. Ancak bu, çok kararlı ve ana sistem kaynaklarını mümkün olduğunca az kullanan bir aracı gerektirir. Aynı zamanda, ajan, ana sistemdeki CPU, bellek veya I/O kullanımındaki dalgalanmalardan etkilenmeden birden fazla yoldaki paket kaybını ve gecikmeyi doğru bir şekilde ölçebilmelidir. Ajan, hafiflik ve yüksek performans arasında bu hassas dengeyi sürekli olarak korumalıdır.

Ağ kaybını ve gecikmeyi nasıl ölçüyoruz?

Bu, tek bir sonda akışı üzerinde önemsiz bir hesaplama gibi görünebilir, ancak ölçeklendirme sırasında ilk bakışta fark edilmeyen bazı zorluklar ortaya çıkar. Böylesine büyük bir ağa ölçeklendirmek için, ajanın çok sayıda akış üzerinde zaman damgalı hızlı ve doğru iletim (Tx) ve alım (Rx) paket sayılarını aynı anda hesaplaması gerekir. Ağ kaybı metriklerinin, ajanın çalıştığı ana bilgisayarda CPU meşgul olduğunda veya ağ tamponları taştığında kaybolan paketleri içermemesi önemlidir. Ağ gecikmesi, sondaların kabloda veya ara ağ düğümlerinde kaldıkları toplam süre ile hesaplanmalı, I/O tamponlarında bekleme süresi ve ajanın işletim sistemi zamanlamasını bekleme süresi hariç tutulmalıdır.

Roblox’un Ping Mesh sistemi

Kamu ve özel bulut altyapısının büyümesinden bu yana, kara kutu ağ kaybı ve gecikme izleme ihtiyacı ortaya çıkmıştır. Büyük ağımıza uyarlanabilen hazır bir çözüm bulmak zor olmuştur. Birkaç büyük bulut operatörü ve ağ araçları sağlayıcısı, ağ kaybını ve gecikmeyi izlemek için kendi çözümlerini tasarlamıştır. Halka açık bazı araçları denedik, ancak ağ performansı hakkında sınırlı bir görünürlük elde ederken, kararlılık ve ölçeklenebilirlik sorunlarıyla karşılaştık. Bu durum, düşük ek yükle düşük frekanslı hataları daha iyi tespit eden kendi ağ izleme sistemimizi kurmamıza neden oldu. Sistemimizin öne çıkan özelliklerinden bazıları şunlardır:

• Sistemimizin tüm bileşenlerini uygulamak için Go'yu seçtik ve bu, minimum sistem kaynağı kullanarak yüksek performans elde etmemize yardımcı oldu.
• Ajanlarımız son derece kararlıdır ve trafik, önbellekleme ve uygulama sunucuları gibi Roblox platformunda kritik hizmetler sunanlar da dahil olmak üzere çok çeşitli üretim ana bilgisayarlarında çalışabilir.
• Ajan, Linux sendmmsg() ve recvmmsg() sistem çağrıları üzerinden Go sarmalayıcı işlevleriyle paket I/O işlemlerini toplu olarak gerçekleştirecek şekilde optimize edilmiştir; bu da düşük ek yükle yüksek oranda sonda iletilmesini sağlar. Dağıtımımızdaki her ajan, saniyede 100 paket (PPS) hızında, aynı anda 100 adede kadar başka ana bilgisayara sonda iletir. Ajan, her saniye her hedefe paket patlamaları iletir.
• Sondalar, IP başlığında her hedefe farklı hizmet türü (TOS) alan değerleri taşır ve ağ üzerindeki paket kaybı ve gecikme için ayrı ayrı hesaplanır. Her paket patlaması, diğer tüm hedeflere yönelik birden fazla TOS değerinin bir karışımını içerir. Bu, farklı hizmet kalitesi (QoS) sınıfları için ağ performansını izlemeye yardımcı olur.
• Aracı, her prob yolunda dakikada 6000 paketten 1'i kadar düşük ağ düşüşlerini tespit edebilir. BGP flap sırasında olduğu gibi, ağın çekirdeğinde veya kenarında 1 saniyeden kısa süren paket kayıpları tespit edilebilir.
• Prob paket düşüş grafikleri, düşüşlerin hatalardan kaynaklandığı durumlarda ağ cihazı arayüz hata oranlarını taklit eder. Ağda tespit edilmesi zor olan trafik kara delik hatalarını keşfedebildik.
• Ajanlar, ağ gecikme ölçümlerinde yüksek doğruluk elde etmek için NIC çekirdek okuma zaman damgalarını kullanır. Ana bilgisayar işletim sistemi zamanlama gecikmesi ve ağ saati sapması hariç tutulurken, 50–100 mikrosaniyelik tutarlı bir site içi gidiş-dönüş gecikmesi ölçülebilir.
• Düşük CPU kullanımı ve bellek ayak izi. Ajan, en yüksek iletim ve alım hızlarında (her biri 5 kpps) tek bir çekirdeğin %25'inden azını kullanır. Dağıtılan ajanların çoğu, bir çekirdeğin yalnızca yaklaşık %5'ini kullanır. Ajanın Tx ve Rx paket tamponlarını ve sayaçlarını yönetmek için yalnızca 10 MB yığın belleği gereklidir. Ağ büyüdüğünde, sınırları ayarlayarak veya ek ajanlar ekleyerek dikey veya yatay olarak ölçeklendirebiliriz.
• Ana sistem yük altında olduğunda ajan nadiren etkilenir. Ana sistem CPU yükü birkaç kez %99'a yaklaştığında bile doğru sonuçlar elde ettik.
• Her ajandan telemetri toplanarak sağlık durumları izlenir. Ajanlar, ana bilgisayar sisteminin yeniden başlatılması, ajan işleminin yeniden başlatılması veya soket tamponlarının taşması nedeniyle paketlerin düşmesi gibi sorunlu durumları tespit edebilir.

Ajanlar, ağ taramasına katılan düğüm sayısını yüksek tutmak için Chef ile geniş bir sunucu kümesi setine dağıtılır. Ajan ikili dosyası, Linux'ta systemd ile çalıştırılır ve yönetilir, böylece ana bilgisayarın yeniden başlatılması veya ajanın yükseltilmesinden sonra otomatik olarak yeniden başlatılır. Mesh zamanlayıcı, ajanlardan herhangi biri devre dışı kaldığında veya yenileri devreye girdiğinde akışları dinamik olarak algılar ve gerektiği şekilde ayarlar. Zamanlayıcı uygulamamız, Intra-Pod, Intra-Site ve Inter-Site taramaları için hedefler tahsis etmeden önce yeni ajanları ve sunucu sağlık durumunu tespit etmek üzere cihaz envanterini ve hizmet keşif sistemini periyodik olarak yoklar. Mesaj veriyolu, test sondalarını ileten her ajana hedef ana bilgisayar listesini iletmek için kullanılır. Belirli bir rafta başlayan veya biten tek tek akışlar, o raf içindeki tüm kullanılabilir ajanlar arasında dağıtılır. Bu, aşağıdaki şekillerde gösterildiği gibi, ağ yapımız içinde çok sayıda eşit maliyetli yolu kullanmamıza yardımcı olur.

İlk kurulumumuzda 150 ajanla başladık ve şu anda sayımızı 10 katına çıkardık. Ağ, dünya çapında yayılmış 25 siteyi birbirine bağlayan omurgamızı kapsıyor. Ana veri merkezi sitelerimizden birinde, 200'den fazla rafı kapsayan ve yaklaşık 33.000 akışla 1,65 Mpps sonda oranına ulaşan bir site içi ağımız bulunmaktadır. Her raf, diğer raflardan 5–10 kpps sonda almaktadır. Zamanlayıcı uygulaması, farklı sitelerdeki tüm ajanlarımız arasında 35.000'den fazla hedefi hesaplayarak eşit bir şekilde dağıtır.

Veri toplama ve görselleştirme

Paket kaybı ve gecikme sonuçları için tüm Ping Mesh ajanlarını periyodik olarak sorgulayan ayrı bir toplayıcı uygulaması çalıştırıyoruz. Bu veriler, toplayıcıda yerel olarak önbelleğe alınan durum bilgilerine göre geçersiz sonuçları hariç tutacak şekilde otomatik olarak filtrelenir. Örneğin, durum kontrollerine yanıt vermeyen bir sunucuda veya yeni yeniden başlatılmış bir sunucuda çalışan bir ajanın sonuçlarını hariç tutarız. Toplayıcımız, 1.500'den fazla düğümden sonuçları eşzamanlı olarak sorgulayıp filtreleyebilir ve ardından verileri 2 saniye içinde bir zaman serisi veritabanına aktarabilir.

Hem toplu hem de akış başına sonuçlar, Grafana panoları yardımıyla görselleştirilir. Isı haritası ızgaralarının kullanımı, özellikle büyük veri merkezi sitemiz gibi büyük veri kümeleriyle zor olabilir. Binlerce sonuç arasından en yüksek tekil paket kaybına sahip yolları görüntülemek için Prometheus topk() sorgusunu kullanırız; bu sonuçlar genellikle çok azdır. Sonuçlar, toplayıcı tarafından sık sık sorgulanan ajan ve ana bilgisayar sistemi sağlık istatistiklerine göre kapsamlı bir şekilde incelenir. Bu, paket kaybı varyasyonlarının ne kadar büyük olduğuna bakılmaksızın, her bir sonuç için bize yüksek düzeyde güven sağlar. Tek tek sonuçlar bir arada incelendiğinde, ağ arızasının nerede meydana geldiğine dair ipuçları verebilir. Mesh izleme sistemimiz tarafından yakalanan paket kaybı örneklerinden bazıları aşağıda gösterilmiştir.

Özet ve sonraki adımlar

Ping Mesh sistemimiz, Ağ Mühendisliği ekibinin uçtan uca paket kaybını ve gecikmeyi izlemesi için güçlü bir araç olmuştur. Bu veriler, "Ağ paketleri düşürüyor mu?" sorusuna anında cevap vermek için kullanılabilir. Deneyimlerimize göre, müşterileri etkileyen büyük ağ olayları genellikle cihaz telemetri izleme sistemi tarafından tespit edilir ve uyarı verilir. Ağ arabellekleme veya izole trafik kara deliği ile ilgili etkisi düşük ancak potansiyel olarak sorun teşkil eden sorunlar bu sistem sayesinde ortaya çıkar.

Sistemimiz ayrıca Roblox Bulut Ağı'nın genel güvenilirliği hakkında da içgörüler sağlayabilir. Başlıca veri merkezi tesislerimizden birinde, ağın durumunu izleyen dakikada 100 milyondan fazla sonda bulunmaktadır ve dakikada 50'den fazla paket kaybı sayısına nadiren ulaşırız. Bu, veri merkezi ağımızın yaklaşık 6 9'luk (99,9999%) bir güvenilirliğe sahip olduğunu gösterir. Sık sık, 100 milyon paket arasında hiçbir paket kaybı fark edilmez. Önemli miktarda paket kaybolduğunda, bu sistem paket kaybının nerede ve ne kadar süreyle meydana geldiğine dair bilgiler sağlar. Bir otomatik düzeltme motoru, ağı kendi kendine onarır ve kullanıcı trafiğini ağdaki farklı bir yola yönlendirerek daha fazla kayıp yaşanmasını önler. Roblox'taki Ağ ekibi, son derece güvenilir bir bulut ağı oluşturmuştur.

Gelecekte, cihaz telemetrisi, sistem günlükleri ve diğer veri kümelerinden gelen verileri ilişkilendirmek için bir analiz motoru kullanmayı planlıyoruz. Ardından, bunu Ping Mesh verileriyle karşılaştırarak ağ arızasının nerede meydana geldiğini tespit etmeyi planlıyoruz. Roblox’un bulut ağı genişlemeye ve gelişmeye devam ettikçe, IPv6 ve jumbo çerçeveleri de içerecek şekilde sondalama mekanizmalarımızı geliştirmeyi ve site arası kapsama alanını artırmak için daha fazla ajan eklemeyi planlıyoruz.