- Saniyede 2 milyon mesaj işleyen bir NoSQL DB kümesi (ScyllaDB) işletiliyor
- DB performansını en çok etkileyen şey fiziksel disk donanımının gecikmesi
→ Sorgu miktarı düşük seviyedeyken sorun olmaz, ancak belirli bir eşiği aştığında yalnızca 1~2 ms süren okuma zamanı bile diskten okuma kuyruğu oluşturur ve sorgunun kendisinde zaman aşımına yol açar
- Disk gecikmesi normalde mikrosaniye düzeyindeyken, disk işlemleri neden 1~2 ms sürüyor?
- Discord donanımının büyük kısmını Google Cloud üzerinde çalıştırıyor
- NVMe tabanlı yerel SSD desteği var, ancak kendi testlerinde kararlılık sorunları görüldüğü için kritik veri depolama alanı olarak kullanmak iç rahatlatıcı değildi
- Persistent Disk sunucuya gerçek zamanlı olarak takılıp çıkarılabiliyor, kesinti olmadan yeniden boyutlandırılabiliyor, her zaman snapshot oluşturulabiliyor ve varsayılan olarak çoğaltılacak şekilde tasarlanmış
→ Sorun, sunucuya doğrudan bağlı olmaması ve ağ üzerinden bağlanması
- Yerel ağ bağlantısının gecikmesi ne kadar düşük olursa olsun, PCI/SATA’dan daha düşük değil
→ Ağ 1~2 ms, doğrudan bağlı disk ise 0.5 ms
- Yerel SSD’lerde HDD’lerde olduğu gibi donanım arızası yaşanırsa o diskteki veriler kaybedilebilir; ayrıca host’un kendisinde sorun çıkarsa snapshot da mümkün olmayacağı için veriler tamamen kaybolabilir
→ Bu yüzden Discord Local SSD kullanmıyor, Persistent Disk kullanıyor
Sorun analizi
- Yerel SSD ile Persistent Disk’in avantajlarını bir araya getiren bir depolama aygıtı olsaydı ideal olurdu, ancak böyle bir şey yok. Peki avantajların sadece bir kısmı alınabilirse?
- Discord için yazma gecikmesi sorun değil. Performansı etkileyen şey "okuma gecikmesi"
- "Kesintisiz disk yeniden boyutlandırma" zorunlu bir özellik değil. Boyut önceden tahmin edilebiliyor
- Nihai gereksinimler şunlar:
- GCP üzerinde kalmaya devam etmek
- Veri yedekleme için Point-in-Time snapshot kullanmak
- En yüksek öncelik olarak okuma gecikmesini en aza indirmek
- Mevcut veritabanı uptime güvencesinden ödün vermemek
- Okumaları GCP’nin Local SSD’sinde, yazmaları ise Persistent Disk’te yapmak iyi bir fikir gibi görünüyor
→ Yazılım seviyesinde böyle bir Super-disk yapılabilir mi?
Super-Disk oluşturmak
- Gereksinim temelde bir Write-Through cache idi. GCP’nin Local SSD’si cache olarak, PD ise depolama katmanı olarak kullanılacaktı
- DB sunucusu olarak Ubuntu kullanıldığı için, Linux çekirdeği seviyesinde disk düzeyinde cache uygulanabiliyor (
dm-cache, lvm-cache, bcache gibi modüller)
- Ancak deneylerde cache diskinde bad sector oluştuğunda tüm okuma işlemleri başarısız oldu
- Bad sector oluşursa depolama katmanından okunup üzerine yazılması gerekir, fakat değerlendirilen disk cache çözümlerinde bu özellik yoktu
- Bad sector oluştuğunda veritabanı veri bütünlüğü sorunu nedeniyle kapanıyordu
- Buna ek olarak şu gereksinim de eklendi: "Yerel SSD’de bad sector oluşsa bile sistem ayakta kalmalı"
- Bunun üzerine Linux çekirdeğindeki
md incelendi
md, yazılımsal RAID oluşturmayı destekliyor- SSD ile PD’yi mirror yapmak tek başına sorunu çözmüyor. Çünkü okumaların yarıdan fazlası PD’den gelecekti
md içinde, geleneksel RAID’lerde olmayan bir write-mostly özelliği var
- Belirli bir disk
write-mostly olarak ayarlanırsa normal okumalarda devre dışı bırakılır, yalnızca başka seçenek olmadığında okunur. "Yavaş bağlı aygıtlar için kullanışlı"
- Yani SSD ile PD’yi RAID1 altında birleştirip PD’yi
write-mostly olarak ayarlayınca gereksinimler karşılanabiliyor
- Geriye kalan son sorun, GCP’nin Local SSD’sinin tam olarak 375 GB boyutunda olmasıydı
- Discord bazı uygulamalar için veritabanı instance başına 1 TB’dan fazlasına ihtiyaç duyuyor
- Bu yüzden birden fazla SSD’yi RAID0 altında birleştirmeye karar verildi
- Son yapı şöyle oldu:
- RAID0 altında birleştirilmiş 4 yerel SSD,
md0
md0 ile Persistent Disk’in RAID1 altında birleştirildiği md1
DB performansı
- Sonuç tam da beklendiği gibi çıktı
- Zirve yük altında bile disk işlemleri kuyrukta birikmedi ve sorgu gecikmesi değişmedi
- Performans iyileşti, böylece sunucu başına işlenebilen sorgu miktarı arttı
- RAID kullanmış olanlar bunun için "bu gerçekten öylece çalışır mı?" diye şüphe duyabilir, ancak gerçekte çeşitli olaylar yaşandı ve geri kalanı daha sonra ayrıca ayrıntılı olarak paylaşılacak
3 yorum
Eskiden Golang performansından memnun kalmayıp sunucuyu bile Rust ile yazdıklarını görünce, Discord şirketinin ne kadar geek olduğu da gerçekten etkileyici geliyor.
Bu, sanki boğazdaki balgamı kazmayla temizlemeye çalışıyormuşsunuz gibi bir his veriyor.
HN'de bunun sadece GCP kaynaklı bir sorun olup olmadığına dair yorumlar da var ama.. https://news.ycombinator.com/item?id=32474093
Bunu da böyle bir denemenin mümkün olabileceğini gösteren bir örnek olarak bilmekte fayda var.