Kusurlu Sistemlerin Avantajı: Bluesky’ın Kayıplı Zaman Akışı

• Sistem tasarımında kusursuz tutarlılık, erişilebilirlik, düşük gecikme ve yüksek iş hacmini aynı anda sağlamak pratikte oldukça zordur
  • Uygulamaya uygun denge noktasını bularak doğru tasarımı seçmek önemlidir
• Bluesky, following feed/zaman akışı tasarımında yazma performansını iyileştirmek için tutarlılıktan kısmen ödün veren bir trade-off uyguladı
  • Sonuç olarak, kullanıcılar üzerinde olumsuz bir etki yaratmadan P99 gecikmesini %96’dan fazla azalttı

Zaman akışı fan-out

• Bluesky’da bir kullanıcı gönderi paylaştığında, bu içerik sistem tarafından indekslenir, veritabanına kaydedilir ve API yanıtlarıyla sunulur
• Aynı anda bu gönderi, her bir takipçinin zaman akışı tablosuna eklenen bir “fan-out” sürecinden geçer
• Bunun için önce takipçi listesi alınır, ardından her takipçinin zaman akışı tablosuna ters sırada ekleme yapılır
• Zaman akışı tabloları kullanıcı bazında partition edilerek dağıtık veritabanı (ScyllaDB) üzerinde tutulur ve yüksek erişilebilirlik için birden çok shard’a replike edilir
  • Her kullanıcı farklı bir shard’a atanabilir
• Depolama alanından tasarruf etmek için, belirli bir uzunluğu aşan zaman akışlarında eski gönderi referansları düzenli olarak silinir

Hot shard sorunu

• Bluesky’nin yaklaşık 32 milyon kullanıcısı vardır ve zaman akışı veritabanı yüzlerce shard’a bölünmüştür
• Milyonlarca kişinin kullandığı bir sistemde, olağanüstü sayıda takip ilişkisine sahip kullanıcılar ortaya çıkabilir
  • Örnek: yüz binlerce hesabı takip eden bir kullanıcı
• Tek bir shard içinde çok sayıda kullanıcının zaman akışı birlikte tutulur
• Belirli bir kullanıcı çok fazla yazma işlemi tetiklerse ilgili shard aşırı yüklenir ve “hot shard” hâline gelir
• Bu tür hot shard’larda yazma veya okuma işlemleri yoğunlaştığı için, aynı shard’daki diğer kullanıcılara da gecikme yayılır

Gecikmenin birikmesi

• Bir kullanıcının 2.000.000 takipçisi varsa, yazma işlemleri sıralı yapılırsa 20 dakikadan uzun sürebilir
• Bunu azaltmak için fan-out paralelleştirildiğinde ortalama gecikme kısalır
• Ancak P99 gecikmesi (yaklaşık 15 milisaniye ve üzeri) birçok kez ortaya çıkarak tüm paralel işi yavaşlatabilir
• Takipçi sayısı çok yüksek olduğunda, P99 veya P99.9 gecikmeleri yüzünden toplam fan-out süresi en kötü durumda birkaç dakikadan onlarca dakikaya kadar uzayabilir

Kayıplı zaman akışı

• Aşırı sayıda hesabı takip eden kullanıcılara tüm gönderileri tam ve doğru sırayla göstermek pratikte mümkün değildir
• Zaten bir insanın bu kadar çok gönderinin tamamını gerçekten tüketmesi de zordur
• Bu yüzden belirli bir eşiği (ör. reasonable_limit) aşan takip sayısına sahip kullanıcıların zaman akışında bazı yazmaların olasılıksal olarak “drop” edilmesi yaklaşımı benimsendi
• loss_factor = min(reasonable_limit / num_follows, 1) formülü kullanılır
• Fan-out sırasında rastgele bir değer üretilir; bu değer loss_factor değerinden büyükse zaman akışına yazma atlanır
• Böylece belirli kullanıcı zaman akışlarına aşırı yazma sınırlandırılır ve shard genelindeki performans düşüşü önlenir

Önbellekleme hakkında

• Zaman akışına yazma işlemleri saniyede bir milyondan fazla gerçekleştiği için, her yazmada kullanıcının takip sayısını doğrudan veritabanından sorgulamak çok büyük yük oluşturur
• Bunun yerine, yüksek takip sayısına sahip hesaplar Redis’te sorted set olarak önbelleğe alınır
• Fan-out servis instance’ları bu önbellek bilgisini her 30 saniyede bir belleğe yükler
• Sonuç olarak fan-out sırasında da çok takip edilen kullanıcı bilgileri hızlıca sorgulanabilir
• Önbellek bilgisinin tamamen güncel olması gerekmediğinden, bir miktar kusuru kabul ederek performans ve ölçeklenebilirlik artırılır

Sonuç

• Kayıplı zaman akışının devreye alınmasının ardından Timelines veritabanındaki hot shard’lar fiilen ortadan kalktı
• Bir fan-out sayfasını işlemenin P99 gecikmesi %90’dan fazla azaldı
• Toplam fan-out süresine bakıldığında, P99 bazında 5-10 dakika süren işler 10 saniyenin altına indi
• Bununla, tutarlılıktan bir miktar ödün verilse bile kullanıcı beklentilerinin rahatlıkla karşılanabildiği ve büyük ölçekli genişlemenin sürdürülebildiği gösterildi
• Bluesky zaman akışı mimarisinde hâlâ iyileştirme alanları olsa da, bu değişiklik yazma throughput’unu ve ölçeklenebilirliği büyük ölçüde artırdı

[GN⁺]

Hacker News yorumu

• Sistem meraklısı olarak bu tür yazılardan hoşlanan biriyim. "Mükemmel olmalı" düşünce yapısına kapılmak kolay

  • Blekko arama motorunun arka ucunda 'eventually consistent' bir indeks kurmuştuk. Bu, kullanıcılara güncellemeleri daha hızlı sunuyor ama aynı sorguyu yapan iki kullanıcı biraz farklı sonuçlar alabiliyor
  • Burada çokça sistem teorisi devreye giriyor ve pozitif geri besleme varsa salınım olasılığı bulunuyor. Arama motorunda, kullanıcıların tıkladığı bağlantılara ağırlık veren sıralayıcı pozitif geri besleme sağlıyordu
  • Sistemin "kritik sönümlü" kalmasını sağlamak önemliydi. Bu, hızlı yakınsamayı sağlıyordu
  • Kullanıcının zaman akışının shard'lanması ve geri besleme döngülerinin ('beğeni' veya 'repost' gibi) bulunması, ilginç bir problem alanı gibi görünüyor

• Zaman akışını hesapların popülerliğine göre hibrit bir şekilde neden uygulamadıklarını merak ediyorum

  • Ünlü hesaplar için, her mesajı milyonlarca takipçiye yaymak yerine, takipçinin zaman akışı sunulurken ünlünün gönderilerini getirip birleştirmek daha ucuz olurdu
  • Milyonlarca takipçi bunu yaptığında, hot cache'ten salt okunur şekilde almak daha ucuz olurdu

• İlginç bir probleme ilginç bir çözüm. Paylaştığın için teşekkürler

  • Yazarın "ünlü"den "bot"a geçtiği kısmı anlamakta zorlandım
  • Yazar sanki "kayıplı zaman akışı" diye tamamen farklı bir kavram ortaya atmış gibi geldi

• Tutarlılıktan ödün veren bu stratejiyi merak ediyorum. Okumada ya da yazmada tam fan-out dışında başka yöntemler üzerine düşündüler mi diye merak ediyorum

  • Her kullanıcının zaman akışına yazmak yerine, en az bir takipçisi olan her shard'a yalnızca bir kez yazmanın mümkün olduğunu hayal ediyorum
  • Okuma sırasında, ilgili kullanıcının içeriği getirilir ve gerçek takipçiler filtrelenir
  • Okuma shard içinde gerçekleştiği için gecikme düşük olur
  • Mega takipçili hesaplarda sayfa eski öğeleri görmez

• Her kullanıcının takip ettiği binlerce kişinin paylaştığı her şeyi kusursuz kronolojik sırayla sunmak gerekmiyor, ama zaman akışında her zaman yeni içerik olacak kadar içerik sunmak mantıklı

  • Çözüm, kusurlu zaman sıralaması değil de akışta gönderilerin eksikmiş gibi görünmesi gibiydi

• Hot shard sorununu önlemek için takipçi sayısını sınırlamanın nasıl işleyeceğini merak ediyorum

  • Her kullanıcının her 1000 takipçi için ayrı bir zaman akışı olur ve istemci bunları birleştirir
  • Gerekirse, kayıplı kısmı gerçekleştirmek için gerçek zaman akışının yalnızca bir bölümü yüklenebilir

• AWS'nin bu sorun için hoş, genel bir yaklaşımı var

  • Her kullanıcıyı birden fazla shard'a atayarak, başka kullanıcıların tüm shard'ları paylaşma olasılığını azaltıyorlar
  • Başından beri shuffle sharding yapılsaydı, pek çok başka kullanıcıyı etkilemeden yeni sorunları çözmek mümkün olurdu

• Yüz binlerce kullanıcıyı takip eden hesapların içerik kazıyan bot hesaplar olduğu açık. Engeller geçerim

  • Teknik zorluklar hakkında okumayı seviyorum. Twitter'ın milyonlarca takipçisi olan ünlüler için özel bir mimarisi var
  • Bluesky benzer bir klonsa neden bunu izlemediklerini merak ediyorum

• Doğrudan kullanıcının profiline gidip tüm gönderileri gördüğünüzde, zaman akışında olması gereken bazı gönderilerin eksik olduğu oluyor

  • Bluesky'da 100'den az kullanıcıyı takip ediyorum ama bazen neden zaman akışında bir kullanıcının gönderilerini görmediğimi açıklıyor

• Her "sayfa"nın bir sonraki sayfanın getirilmesini engelleyecek şekilde fan-out'u neden uyguladıklarını merak ediyorum

  • Sayfa getirme etkinliği takipçileri art arda getirmek zorunda kalmalı ve sayfadaki tüm öğelerin güncellenmesini beklememeli
  • Bir sayfayı alıp S3'e kaydeden ve metadata ile S3 konumunu bir kuyruğa (SQS) yayımlayan bir getirme bileşeni olması aklıma geliyor
  • Bu sistemde eşzamanlılığı daha iyi kontrol edebilir ve işi "yavaşlatmak" için shard'ı anahtar olarak kullanıp kuyrukta bölümleme yapabilirsiniz