Slack'in veri deposunu Vitess ile ölçeklendirmesi

• Slack'in Active-Active küme yapısından, MySQL için yatay ölçekleme sistemi olan Vitess'e geçiş hikâyesi

• Geçiş 2017'de başladı; bugün Vitess tüm sorguların %99'unu işliyor ve yıl sonuna kadar tam geçiş planlanıyor

→ Şu anda tepe noktada 2,3 milyon QPS (2 milyonu okuma, 300 bini yazma)

→ Sorgu gecikmesi medyanı 2 ms, p99 sorgu gecikmesi 11 ms

• Slack, LAMP yığınıyla başladı (Linux, Apache, MySQL, PHP)

• 3 veritabanı kümesi

→ Shard'lar: tüm mesajlar, kanallar, DM'ler ve diğer kullanıcı verileri. Workspace ID'ye göre bölümleniyor; bir workspace tek bir shard'da yer alıyor

Yani Slack uygulamasının yalnızca tek bir veritabanına bağlanması yeterli

→ Metadata kümesi: workspace'i shard'a bağlamak için kullanılan lookup table

→ Kitchen sink kümesi: belirli bir workspace'e ait olmayan tüm verileri depolar. App dizini vb.

• Sharding yönetimi ve koordinasyonu monolitik webapp tarafından yapılıyordu

• Her küme bir veya daha fazla shard'dan oluşuyor ve her shard, farklı veri merkezlerinde bulunan en az iki MySQL instance'ı ile provision ediliyordu

• Active-Active yapısının avantajları

→ yüksek erişilebilirlik

→ hızlı ürün geliştirme temposu

→ kolay debugging

→ kolay ölçekleme

Ancak organizasyon büyüyüp ürün ekipleri yeni özellikler geliştirmeye başladıkça geliştirme hızı yavaşladı

• Active-Active'in dezavantajları

→ Ölçekleme sınırları: daha büyük müşteriler geldikçe, yüksek performanslı host'ların kaldırabileceği sınıra ulaşıldı

→ Tek bir veri modeline kilitlenme:

Enterprise Grid ve Slack Connect gibi özellikler eklendikçe, yalnızca tek bir sunucuya bağlanma paradigmasına ters düşmeye başladı

→ Hotspot'lar: veritabanı filosu verimli kullanılamıyordu. Shard bölmek ve ekip taşımak zordu; Slack kullanımını öngörmek güç olduğu için çoğu shard aşırı provision ediliyor ve long tail'den yararlanmak zorlaşıyordu

→ Workspace ve shard erişilebilirliği sorunu: bir shard'da sorun çıkarsa o shard'daki tüm müşteriler Slack'i kullanamaz hâle geliyordu

→ Operasyon: standart bir MySQL yapılandırması olmadığı için çok sayıda dahili araç yazılmıştı

• 2016 sonbaharında saniyede yüz binlerce MySQL sorgusu ve binlerce sharded MySQL host'u yönetiliyordu

• Düzenli olarak ölçekleme ve performans sorunları yaşandığı için yeni bir yaklaşım arayışına girildi

• Mevcut sistemi geliştirmek ya da yeni bir ürün benimsemek değerlendirildi, ancak

→ kendi cloud altyapılarında çalışan MySQL'i kullanmaya devam etmek istiyorlardı

→ binlerce benzersiz sorgu vardı ve bunların bir kısmı özel MySQL yapılandırmalarından yararlanıyordu

→ deployment, backup, data warehouse ETL, compliance vb. süreçlerin tamamı MySQL tabanlıydı

• Neden Vitess? : uygulama ve operasyon gereksinimlerinin çoğunu karşılıyordu

→ MySQL Core: Vitess, MySQL tabanlı

→ Scalability: MySQL'in temel özellikleri ile NoSQL veritabanlarının ölçeklenebilirliğini birleştiriyor. Yerleşik sharding sayesinde ek özel mantık yazmadan esnek biçimde ölçeklenebiliyor

→ Operability: varsayılan failover ve backup gibi işleri otomatik olarak yürütüyor. Küme yapılandırmasına ilişkin metadata'yı izleyerek tutarlılığı koruyor

→ Extensibility: Go tabanlı açık kaynak. Geniş test kapsamı ve açık bir geliştirici topluluğu var

• Önce küçük özelliklerle Vitess üretim kullanımına alındı

→ 2017'de RSS feed'lerini Slack kanallarına entegre eden bir özellik geliştirildi

→ 2018'de tüm yeni tablolar yalnızca Vitess üzerinde oluşturuldu

→ 2019 ortasında Vitess'e yapılan yazmalar, legacy DB'den daha fazlaydı

→ Slack ayrıca Vitess açık kaynağına düzenli katkı yapmayı sürdürdü

→ 3 yıl içinde sistemin %99'u Vitess'e taşındı. Bu yıl kalan %1'in de tamamlanması planlanıyor

• Slack'in Vitess benimsemesi başarılı oldu mu?

→ Dünyanın farklı bölgelerinde birden fazla Vitess kümesi, onlarca keyspace'i işletiyor

→ Keyspace'ler, kullanıcı/takım/kanal sayısına göre ölçeklenen mantıksal koleksiyonlar

→ Esnek sharding sayesinde Slack ölçeklenebilir hâle geldi

→ COVID-19 sırasında Slack'in sorgu sayısı bir hafta içinde %50 arttı

→ En yoğun keyspace, Vitess'in split workflow'u kullanılarak yatay olarak ölçeklendirildi

→ Eskiden bu ölçekte büyüme mümkün olmayacağından downtime yaşanacaktı

[xguru]

https://vitess.io/

Vitess: "MySQL için Sharding Middleware"

• MySQL ve MariaDB'yi bulutta kolayca dağıtmak/ölçeklemek/yönetmek için oluşturulmuş bir çözüm

• Docker (yerel) ve Kubernetes üzerinde MySQL shard'larını çalıştırır ve yönetir

• Uygulama, VTGate adlı proxy'yi MySQL ile iletişim kurar gibi kullanır; içeride ise gRPC ile diğer sunuculara bağlanır

[xguru]

E-posta hizmeti Hey de Vitess kullanıyor

Hey'in teknoloji yığını: https://tr.news.hada.io/topic?id=2355