Discord trilyonlarca mesajı nasıl saklıyor (2023)
(discord.com)- Discord’un mesaj depolama hacmi milyarlarca iletilerden trilyonlarca iletiye büyüdükçe, 2022 başında 177 düğümlü Cassandra kümesinin operasyon yükü ve öngörülmesi zor gecikmeleri artık taşınması güç hale geldi
channel_idve zaman bucket’ı merkezli Cassandra tasarımı, büyük sunucularda yoğun okuma trafiği altında hot partition oluşturdu; quorum okuma/yazma nedeniyle gecikme daha geniş bir kullanıcı kitlesine yayıldı- API ile veritabanı arasına Rust tabanlı bir veri servisi yerleştirildi; aynı satıra yönelik eşzamanlı istekler birleştirildi ve kanal ID’si tabanlı consistent hashing yönlendirmesiyle veritabanı yükü azaltıldı
- ScyllaDB’ye geçiş yeni küme kurulumu ve Rust migrator ile yapıldı; Spark tabanlı, tahmini 3 aylık iş 9 gün seviyesine indirildi ve saniyede en fazla 3,2 milyon mesaj taşındı
- Mayıs 2022’deki geçişten sonra düğüm sayısı 177 Cassandra’dan 72 ScyllaDB’ye düştü; eski mesaj sorgulama p99’u 40–125 ms’den 15 ms’ye, mesaj ekleme p99’u 5–70 ms’den 5 ms’ye iyileşti
Cassandra’da büyüyen operasyon yükü
- Discord, 2017’de milyarlarca mesajı nasıl sakladığını yayımlayarak MongoDB’den Cassandra’ya geçiş sürecini paylaşmıştı
- O dönemde hedef ölçeklenebilir, hatalara dayanıklı ve bakımı görece az bir veritabanıydı; ancak depolanan veri arttıkça Cassandra kümesinin kendisi büyük bir operasyon yüküne dönüştü
- Mesaj depolama için kullanılan
cassandra-messageskümesi, 2017’de 12 düğümden 2022 başında 177 düğüme çıktı ve trilyonlarca mesaj saklar hale geldi - Operasyon ekibi veritabanı sorunları nedeniyle sık sık çağrılıyordu; gecikme süreleri öngörülemezdi ve maliyeti çok artan bakım işlerinin azaltılması gerekiyordu
Mesaj şeması ve hot partition’lar
- Basitleştirilmiş mesaj şeması
channel_id,bucket,message_id,author_id,contentalanlarını içeriyordu ve birincil anahtar((channel_id, bucket), message_id)idi - Discord’un ID’leri Snowflake tabanlı olduğundan zamana göre sıralanabiliyordu; mesajlar kanal ve statik zaman penceresi olan bucket ile partition’lara ayrılıyordu
- Cassandra’da belirli bir kanal ve bucket’a ait tüm mesajlar birlikte saklanıyor ve replication factor’a göre birden çok düğüme kopyalanıyordu
- Küçük arkadaş grubu sunucuları ile yüz binlerce üyeli sunucular arasında mesaj miktarı birkaç basamak fark ediyordu; bu fark partition bazında yük farkına dönüşüyordu
- Yazmalar commit log’a ve bellek içi yapı olan memtable’a append edildikten sonra diske flush edilir; ancak okumalar memtable ve birden çok SSTable’ı sorgulayabildiği için daha maliyetliydi
- Büyük sunucularda eşzamanlı okumalar yığıldığında belirli bir partition hot partition haline geliyor, ilgili düğümün gecikmesi artıyor ve başka sorgular da etkileniyordu
- Okuma ve yazmalarda quorum consistency level kullanıldığı için, hot partition’dan sorumlu düğümlerdeki gecikme artışı daha geniş bir kullanıcı etkisine yayılıyordu
Cassandra bakım darboğazları
- Cassandra’nın compaction süreci de tekrarlayan arıza müdahalelerinin nedeni oldu
- Okuma performansının iyileşmesi için SSTable’ların diskte compact edilmesi gerekiyordu; compaction geride kalırsa okuma maliyeti artıyordu
- Bir düğüm compaction yaparken gecikme zincirleme şekilde artabiliyordu
- Discord sık sık “gossip dance” adını verdiği işlemi yapıyordu
- Düğüm trafikten çıkarılarak compaction yürütülüyordu
- Yeniden devreye alınarak Cassandra hinted handoff’un hint’lerini yakalaması sağlanıyordu
- Compaction backlog’u bitene kadar bu süreç tekrarlanıyordu
- JVM garbage collector ve heap ayarlarını ince ayarlamak da çok zaman alıyordu; GC pause büyük gecikme spike’ları yaratıyordu
Neden ScyllaDB’ye geçildi
- Discord mesajlar dışında da birden fazla Cassandra kümesi işletiyordu ve her kümede benzer sorunlar görülüyordu
- Önceki yazıda ilgi gösterilen ScyllaDB, Cassandra uyumlu bir veritabanıydı; C++ ile yazılmıştı ve daha iyi performans, hızlı repair, shard-per-core mimarisi tabanlı iş yükü izolasyonu ve garbage collection olmayan bir yapı sunuyordu
- ScyllaDB de sorunsuz değildi; ancak Java yerine C++ ile yazıldığı için garbage collector içermemesi, Cassandra operasyon sorunlarıyla doğrudan karşıtlık oluşturuyordu
- Deney ve testlerde iyileşme görüldükten sonra Discord tüm veritabanlarını ScyllaDB’ye taşımaya karar verdi ve 2020’ye kadar
cassandra-messagesdışındaki tüm veritabanlarını taşıdı - Mesaj kümesi trilyonlarca mesaja ve neredeyse 200 düğüme sahip büyük bir küme olduğu için en sona kaldı
- ScyllaDB’nin ters yönlü sorgu performansı ilk testlerde gereksinimlerin altında kalmıştı
- Ters yönlü sorgu, tablo sıralamasının ters yönünde tarama yapılmasıdır; örnek olarak mesajları artan sırayla taramak verilebilir
- ScyllaDB ekibi performans iyileştirmesini öncelikli olarak uygulayınca son veritabanı migrasyonunu engelleyen faktör ortadan kalktı
Rust tabanlı veri servisi
- Discord, yalnızca veritabanını değiştirmenin tüm sorunları otomatik olarak çözmeyeceğini düşünerek veritabanının üst katmanını da değiştirdi
- API monolith’i ile veritabanı kümesi arasına, veritabanına giden eşzamanlı istekleri kontrol eden bir veri servisi yerleştirildi
- Veri servisi Rust ile yazıldı
- Discord daha önce de bazı projelerde Rust kullanmıştı
- Rust, güvenlikten vazgeçmeden C/C++ seviyesinde hız sunar
- Tokio ecosystem asenkron I/O sistemi kurmanın temeli olarak kullanıldı; Cassandra ve ScyllaDB driver desteği de vardı
- Veri servisinde her veritabanı sorgusu için kabaca bir gRPC endpoint’i bulunuyor ve kasıtlı olarak business logic içermiyordu
- Temel nokta istek birleştirme idi
- Birden fazla kullanıcı aynı anda aynı row’u isterse veritabanı yalnızca bir kez sorgulanıyordu
- İlk istek servis içinde bir worker task oluşturuyor, sonraki istekler bu task’ın varlığını görüp abone oluyordu
- Worker task veritabanını sorguluyor ve sonuç row’unu tüm abonelere döndürüyordu
Yönlendirmeyle birleştirme etkisinin artırılması
- Veri servisinin önüne consistent hashing tabanlı yönlendirme uygulandı
- Her veri servisi isteğine bir routing key veriliyor; mesajlarda routing key kanal ID’sidir
- Aynı kanaldan gelen tüm istekler aynı servis instance’ına gittiği için istek birleştirme daha iyi çalışır
- Örneğin büyük bir sunucuda
@everyonebildirimi olduğunda birçok kullanıcı uygulamayı açıp aynı mesajları okurken veritabanı trafiği hızla artabilir - Önceki yapıda bu durum hot partition’a yol açıp operasyon ekibinin çağrılmasını gerektirebilirdi; ancak veri servisi veritabanına giden trafik spike’ını büyük ölçüde azalttı
- Bu iyileştirme Cassandra kümesindeki hot partition’ları ve gecikmeleri tamamen ortadan kaldırmadı; ancak yeni ScyllaDB kümesini hazırlamak ve migrasyonu yürütmek için zaman kazandırdı
Trilyonlarca mesajın migrasyonu
- Migrasyon gereksinimleri netti
- Trilyonlarca mesaj taşınmalıydı
- Downtime olmamalıydı
- Cassandra hâlâ sık arıza müdahalesi gerektirdiği için hızlı bitirilmeliydi
- Discord önce super-disk storage topology kullanan yeni ScyllaDB kümesini kurdu
- Local SSD ile hız sağlandı
- Veriler RAID ile persistent disk’e mirror edildi
- Yerel diskin hızı ile persistent disk’in dayanıklılığını birlikte sağlayan bir yapıydı
- İlk plan, cutover time baz alınarak yeni verilerde ScyllaDB kullanmak ve geçmiş verileri arka planda taşımaktı
- Yeni veriler Cassandra ve ScyllaDB’ye çift yazılmaya başlandı; eşzamanlı olarak ScyllaDB’nin Spark migrator’ı hazırlandı
- Spark migrator çok fazla tuning gerektirdi ve yapılandırmadan sonra tahmini tamamlanma süresi 3 ay idi
- Ardından Discord mevcut hızlı veritabanı kütüphanesini genişleterek veri migrator’ını Rust ile yeniden yazdı
- Veritabanından token range okunuyordu
- SQLite ile yerel checkpoint kaydediliyordu
- Veriler ScyllaDB’ye toplu olarak gönderiliyordu
- Yeni Rust migrator’ın tahmini tamamlanma süresi 9 güne düştü; bu hız sayesinde karmaşık zaman tabanlı yaklaşım yerine tüm geçiş tek seferde yapılabildi
Geçiş ve doğrulama
- Migrasyon en fazla saniyede 3,2 milyon mesaj hızında yürütüldü
- İlerleme %99,9999’da takıldı; bunun nedeni son birkaç token range’de Cassandra’da compact edilmemiş devasa tombstone aralıklarının bulunmasıydı
- İlgili token range compact edilince migrasyon birkaç saniye sonra tamamlandı
- Discord, okuma isteklerinin küçük bir oranını iki veritabanına da gönderip sonuçları karşılaştırarak otomatik veri doğrulaması yaptı; sonuçlarda sorun yoktu
- ScyllaDB kümesi tam production trafiğini de iyi kaldırdı; Cassandra ise giderek daha sık gecikme sorunları yaşıyordu
- Ekip sahada ScyllaDB’yi primary database olarak devreye aldı
Geçiş sonrası performans ve ölçek
- Mesaj veritabanı geçişi Mayıs 2022’de gerçekleşti
- Sonrasında operasyon sessiz ve kararlıydı; tüm hafta sonu arıza müdahalesi yapmak ya da uptime’ı korumak için küme düğümlerini sürekli ayarlamak gerekmedi
- Düğüm sayısı 177 Cassandra düğümünden 72 ScyllaDB düğümüne düştü
- ScyllaDB’de düğüm başına disk alanı 9 TB idi; bu, Cassandra düğümlerindeki 4 TB ortalamasından büyüktü
- Tail latency de ciddi biçimde iyileşti
- Eski mesaj sorgulama p99: Cassandra 40–125 ms → ScyllaDB 15 ms
- Mesaj ekleme p99: Cassandra 5–70 ms → ScyllaDB 5 ms
- Performans iyileşmesi sayesinde Discord, mesaj veritabanına duyduğu güvenle yeni ürün kullanım senaryolarının önünü açabildi
World Cup trafiğinde doğrulanan yük işleme
- 2022 sonundaki World Cup sırasında dünyanın dört yanındaki kullanıcılar maçları izlerken Discord’un mesaj gönderim grafiğinde de gol anları göründü
- World Cup Final’in mesaj gönderim grafiğinde maç olaylarına karşılık gelen birçok spike görüldü
- Messi’nin penaltısı ve Argentina’nın 1-0 öne geçmesi
- Argentina’nın ek golü
- Devre arasında süren 15 dakikalık plateau
- Mbappe’nin France adına gol atması ve 90 saniye sonra yeniden gol atarak skoru eşitlemesiyle oluşan spike
- Normal sürenin bitmesi ve uzatmalara geçilmesi
- Uzatmanın ilk yarısındaki devre arası sohbeti
- Messi’nin ek golü
- Mbappe’nin beraberlik golü
- Uzatmaların bitmesi ve penaltı atışlarına geçilmesi
- France’ın kaçırdığı penaltı ve Argentina’nın şampiyonluğu
- Mesaj gönderim hacmi büyük ölçüde artsa da Rust tabanlı veri servisi ve ScyllaDB trafiği işledi
- Nihai sistem trilyonlarca mesajı işleyebilen bir yapı olarak düzenlendi
1 yorum
Hacker News yorumları
Bu yazı çöp toplamayı büyük ölçüde suçluyor gibi görünse de, önceki yazıya [0] bakınca sorun daha çok Cassandra’yı kullanma biçimine, Cassandra’nın toplu silmeleri ele alışındaki sınırlara ya da ikisinin birleşimine benziyor.
Kullanıcı API üzerinden milyonlarca mesajı silip kanalda yalnızca 1 mesaj bırakmıştı; Cassandra silmeleri tombstone olarak işlediği için kullanıcı o kanalı açtığında gerçek mesaj sayısı sadece 1 olsa bile milyonlarca tombstone’u taramak zorunda kalıyordu. Açıklamaya göre bu süreçte JVM’in toplayabileceğinden daha hızlı çöp oluşuyordu.
Ayrıca GC tuning’den söz ediliyor ama [1]’e bakınca çok fazla tuning yapılmış gibi durmuyor; Cassandra’nın ve muhtemelen JVM’in de eski sürümleri kullanılıyormuş gibi görünüyor. CMS’ten yeni geçilmiş olması da önemli bir nokta.
0) https://discord.com/blog/how-discord-stores-billions-of-messages
Asıl çözümü yanlış kullanıyor olsalar bile, yanlış kullanması zor olan bir çözümün daha iyi olduğunu düşünüyorum.
2022’de Java 11 kullanıyorlarsa 4 yıllık, Java 8 kullanıyorlarsa 8 yıllık bir runtime kullanıyorlardı; bu yüzden epey performans kaçırmış olmaları çok olası.
Needs (2023)
Bu servis katmanı büyük ve gösterişli bir dağıtık Varnish Cache gibi görünüyordu. Cache’ten söz etmeyip “coalesce” kelimesini seçmelerine bakınca gerçek anlamda çok fazla caching yapmadıkları anlaşılıyor; ama bu bana Varnish’in “grace mode”unu ve stampede’i önleme kullanımını, yani ‘request coalescing’i ilk duyduğum bağlamı hatırlattı https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.htm...
Ayrıca consistent hashingin sürekli karşımıza çıkması da sevindirici. Benzer durumlarda işe yaradığı kanıtlanmış, harika bir koli bandı teknolojisi gibi. Bir şeyin nerede olması gerektiğini biliyorsanız, herkesin onu nerede aramaya geleceğini de bilirsiniz.
proxy_cache_use_stale updating;ScyllaDB’nin kurucu ortağının eklediği birkaç nokta var: Discord, Cassandra’da repair işlemini tamamlayamıyordu ama Scylla’da durum böyle olmadı; Scylla, LSM tree ve compaction gibi konularda Cassandra ile birçok ortak noktaya sahip olsa da kendine özgü CPU/IO scheduler’ı sayesinde sorgulara compaction’dan daha yüksek öncelik verebiliyor.
Yeterli boş bant genişliği olan yarım milisaniyelere compaction’ı erteleyebiliyorlar ve bu konuda çok sayıda yazı olduğunu söylüyor. Scylla’da 1,5 yıllık
tombstone_gc=repairadlı daha güvenli bir mod var; yakın zamanda çıkan Raft ve tablets tabanlı yeni mimarinin de kullanıcılar için bir sonraki büyük değişim olduğunu söylüyor.40 yılı aşkın süredir var olan dağıtık sohbet protokolü IRC kullanılsaydı, bu sorun en başta hiç yaşanmayacaktı.
Açık bir spesifikasyona ve birden çok uygulamaya sahip olma avantajı da var. Duvarlarla çevrili bir bahçe de değil. IRC’nin günümüz için fazla eski olduğunu düşünüyorsanız Matrix’e ya da XMPP’ye bakabilirsiniz. Discord’un nasıl hâkim konuma geldiğini anlamak zor; hatta bu durum trajediye daha yakın.
IRC, birden fazla cihazda konuşmaları takip etmek için fiilen bir bouncer gerektirir. Mesajları şifrelemez; isteğe bağlı olarak yalnızca istemci-sunucu bağlantısını şifreler. Uçtan uca şifreleme yoksa sunucuya ya da operatörlerine karşı gizlilik yoktur ve o sunucu kolayca hedef hâline gelen tekil bir hata noktasıdır.
Matrix protokolü hâlâ değişiyor ve uygulamalar spesifikasyonu yakalayamıyor. Element kullanmıyorsanız özellik ve güvenlik açısından geride kalırsınız. XMPP de IRC gibi uçtan uca şifreleme benzeri temel özellikler için isteğe bağlı eklentilere dayanıyor; istemciler bunları eksiksiz ve doğru biçimde desteklemeyebilir.
soatok’un analizini okumanızı öneririm: https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
2013’teki Snowden olayı 11 yıl önceydi. Artık uçtan uca şifreleme varsayılan bir özellik, hatta metalaşmış bir beklenti olarak görülmeli; HTTPS talep ettiğimiz kadar ısrarla talep etmeliyiz. Elbette Discord uçtan uca şifreleme uygulamıyor.
Yakın zamanda içinde bulunduğum oldukça teknik bir grup Telegram’dan Matrix’e geçti, ama kullanıcı deneyimi iyi değil. Uygulama hatalı, görünümü de pek iyi değil; yeni “Element” uygulamasında SSO desteklenmediği için hesabımı kullanamadım. Benim gibi kurcalayıp çözen biri için bunlar küçük rahatsızlıklar, ama arkadaşlarımı bunu kullanmaya ikna edebileceğimi sanmıyorum.
exe’yi indirip kuruyor, hesap oluşturuyorsunuz ve hemen çalışıyor. Bunu herkes yapabilir. Kullanışlı ve harika yazılımlar çok, ama çoğu genel kitle için kolay değil; bazılarında, hatta çoğunda GUI bile yok. İnsanlar çok fazla adıma katlanmaktansa kimliklerini satmayı, hatta bunun üstüne para ödemeyi tercih ediyor.
Bu yazıdan çıkardığım sonuç, yazarın niyetinden biraz farklı olabilir.
“Sonuncusu mu? Dostumuz cassandra-messages. [...] Başından beri büyük bir kümeydi. Trilyonlarca mesaj ve neredeyse 200 node vardı; dolayısıyla herhangi bir migrasyonun karmaşık bir iş olması kaçınılmazdı.”
Discord’un ölçeğini düşününce mesaj deposunda 200’den az node olması şaşırtıcı derecede küçük görünüyor. Çok daha hızlı ölçeklenebilirliği hedefleyen, daha fazla hareketli parçaya sahip karmaşık bir mimari bekliyordum. Gerçek karmaşıklık yazıda anlatılandan daha yüksek olabilir; ama benim çok daha az iş yapan 200’den fazla fiziksel node’dan kısmen sorumlu olduğum deneyimimi düşününce, modern bulut mimarilerinin ne kadar aşırı tasarlandığını merak ediyorum.
Çok daha küçük Cassandra node kümeleriyle onlarca milyar kayıt saklamış biri olarak, Cassandra nöbet süreçlerinde gerçekten acı vericiydi ve birkaç büyük kesintinin sebebi olmuştu.
[0] https://news.ycombinator.com/item?id=34950843
Yazı çok iyi kaleme alınmış. Çözümün bir kısmının tamamen farklı bir şey getirmek değil de Cassandra’nın yerine kullanılabilecek ScyllaDB’ye geçmek olması sevindirici.
Discord eski mesajları silmeyi fiilen imkânsız hâle getiriyor. Bu bir gizlilik kâbusu ve AB’nin neden müdahale etmediğini merak ediyorum.
Temel soru, Matrix’i e-postaya mı daha yakın görmek gerektiği, yoksa Facebook’a mı daha yakın görmek gerektiği şeklinde özetleniyor. E-posta ise, gönderen kişinin benim posta spool’umdan kendi mesajını silebilmesine insanlar dehşete düşerdi; Facebook ise, silme hakkını kullandıktan sonra bile gönderinin bir yerlerde görünmesine insanlar dehşete düşerdi
Bunu çözmek için muhakeme gerektiği ve yaklaşımın önce GDPR’nin ruhunun gerçekte neyi başarmaya çalıştığını değerlendirmek şeklinde olduğu anlatılıyor
https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix...
GDPR açısından sorun, Discord’un bunları silmeyi zorlaştırması. Hesap verilerini silme niyetini algıladığında kullanıcıyı “anonimleştirme” tarafına yönlendiriyor; kamuya açık olarak kullanıcı adı mesajlardan ayrılıyor ama hâlâ belirli bir kişiye kadar izlenebiliyor. Sunucu tarafında da böyle işleniyorsa, kullanıcının kişisel olarak tanımlanabilir bilgilerini silme talebini uygulamak için muazzam miktarda mesajı taramak ya da geçmiş mesajları topluca silmek gereken bir durum ortaya çıkıyor
AB Parlamentosu’nun, yeni yasa tasarılarını yalnızca Komisyon’un önerebildiği ve seçilmiş parlamentonun çoğunlukla sadece oyladığı bir yapı olduğu için gerçek bir parlamento olmadığını; Komisyon’u kontrol edenin halk değil ABD Dışişleri Bakanlığı olduğunu düşünüyorum. Newsguard ve Musk dışındaki Amerikan büyük teknoloji şirketleri, Discord da aynı siyasi-finansal müesses nizam ağında yer alıyor ve çok sayıda eski Dışişleri Bakanlığı personeli barındırıyor
Kitlesel öfke yoksa AB düzeyindeki kurumların ele geçirilme olasılığı yüksek; kamuoyunu da yasa dışı Discord verileriyle LLM eğiten ve seçim reklamlarını hedefleyen siberpunk tarzı müesses nizamın kontrol ettiğini düşünüyorum. Sonuçta kalıcı bir müesses nizamdan kaçamayacağımız Orwellvari bir hâlin gelebileceğinden endişe etmek gerekir
Ancak bunların çoğunun geniş anlamda doğru olma ihtimalini yalnızca %50’nin biraz üzerinde gördüğüm için ciddi bir süzgeçten geçirerek dinlemek gerekir
Cassandra özünde çoğunlukla yalnızca ekleme yapılan dağıtık, hataya dayanıklı bir hash tablosuna yakın. Yüksek yazma hacmiyle tam olarak buna ihtiyacınız varsa iyi bir seçim
İnsanların bunu neden veritabanı gibi kullandığını anlamıyorum. Sınırlarına hemen çarpıyorsunuz ve veritabanı gibi kullanmaya çalışmanın acısı ölçek büyüdükçe daha da artıyor
Bu durumda bir sohbet sunucusunun mesaj deposu olarak anlamlı gelmiyor. Dağıtık sistemlerin log toplama hedefi, yani çok sayıda istemcinin veri boca ettiği ama çoğu zaman logları denetleme ihtiyacı bile olmadığı için belirli bir öğenin okunma sayısının 1’den az olduğu durumlar için uygun görünüyor. Discord mesajları açıkça böyle değil
Benim deneyimimde, Cassandra kullanmaya başlayan bir projenin yaklaşık 1 yıl sonra hâlâ kullanmaya devam ettiğini hiç görmedim. Sınırlara çarpmak yaklaşık 1 yıl sürüyor ve sonunda Postgres gibi bir veritabanıyla değiştiriliyor
Neden doğrudan sharding yapılamadığını anlamıyorum. Discord’daki her ‘sunucu’ birbirinden yalıtılmış değil mi? Birbirlerine mesaj gönderemiyorlarsa, trilyonlarca mesajı binlerce shard’a bölüp her shard’ın milyarlarcasını işlemesini sağlamak olmaz mı diye merak ediyorum
“ScyllaDB ekibi iyileştirme çalışmasını önceliklendirdi ve performanslı geriye doğru sorguları uygulayarak geçiş planındaki son veritabanı engelini kaldırdı” deniyor
ScyllaDB’yi kullanmaya başlamadan önce bunu yaptırmak için ne kadar ödeme yaptıklarını merak ediyorum