Uber’ın muhasebe verilerini DynamoDB’den LedgerStore’a taşıması

 (uber.com)
2 puan yazan GN⁺ 2024-05-21 | 1 yorum | WhatsApp'ta paylaş
  • Uber ödeme platformu, 2017’den beri biriken muhasebe verilerinin 1 trilyondan fazla kayda ve birkaç PB ölçeğine ulaşmasıyla, DynamoDB·TerraBlob·LedgerStore karışımı yapıyı LedgerStore merkezli hale taşıdı
  • DynamoDB’nin maliyet yükü nedeniyle yalnızca son 12 haftalık veriyi tutan yapı yerine, append-only muhasebe tipi depolama olan LedgerStore uzun vadeli çözüm olarak seçildi
  • Doğrulama için üretim trafiğini kopyalayan shadow validation ile tüm dump’ları karşılaştıran çevrimdışı doğrulama birlikte kullanılarak güncel veri ve soğuk verideki riskler ayrı ayrı kontrol edildi
  • Backfill, normal trafikten daha büyük yük oluşturabildiği için küçük batch’ler, idempotency, hız kontrolü, acil durdurma ve sorunlu kayıtları ayırma yöntemleriyle kademeli olarak yürütüldü
  • Geçiş birkaç hafta boyunca temkinli biçimde rollout edildi; ilk fallback, bir aylık DynamoDB veri tutma süresi, son yedekleme ve tablo silme aşamalarının tamamı kesinti olmadan tamamlandı

Geçişin hedefi ve mevcut depolama yapısı

  • Uber ödeme platformu Gulfstream, 2017’de kullanıma sunulduğunda depo olarak DynamoDB kullanıyordu
  • Uber ölçeğinde DynamoDB maliyeti büyüyünce depolama yapısı üç kola ayrıldı
    • Son 12 haftalık hot data DynamoDB’de saklandı
    • Daha eski cold data, Uber’in dahili blob deposu TerraBlob’da saklandı
    • LedgerStore’a zaten veri yazılıyordu ve nihai geçiş hedefi o oldu
  • Geçiş kapsamı, 2017’den bu yana Uber’in tüm iş kollarındaki muhasebe verilerini kapsıyordu
    • Değiştirilemez kayıtlar: sıkıştırılmış halde 1.2PB
    • İkincil indeksler: sıkıştırılmamış halde 0.5PB
  • Muhasebe kayıtları bir kez yazıldıktan sonra fiilen değiştirilemiyor; sorun düzeltmek gerektiğinde ise ikincil indeks verileri değiştirilebiliyor

Neden LedgerStore seçildi?

  • LedgerStore bir append-only muhasebe tarzı veritabanı
  • Ödeme tipi verilere uygun tasarımı, Gulfstream’in ihtiyaçlarıyla örtüştü
    • Kriptografik imzalarla bir kaydın değiştirilip değiştirilmediğini kontrol eden doğrulanabilir değişmezlik
    • Hot data ve cold data’yı istek işleme ve depolama maliyetine göre ayıran katmanlı depolama
    • Eventual consistency kullanan ikincil indekslerde daha iyi gecikme özellikleri
  • Üç depoyu bire indirmek, Gulfstream’in depolama erişim kodunu ve indeks üretim tasarımını sadeleştirdi
  • LedgerStore, Uber veri merkezlerinde on-premise çalıştığı için daha düşük ağ gecikmesi sağlayabiliyordu
  • LedgerStore’a geçiş, tekrar eden maliyetleri azaltma açısından da büyüktü

Shadow validation ile güncel trafikte istikrarın doğrulanması

  • Backfill’in doğru yapıldığını değerlendirmek için beş ölçüt belirlendi
    • Eksiksizlik: tüm kayıtlar backfill edildi mi?
    • Doğruluk: tüm kayıtlar doğru mu?
    • Yük: LedgerStore mevcut yükü kaldırabiliyor mu?
    • Gecikme: LedgerStore’un P99 gecikmesi kabul edilebilir aralıkta mı?
    • İndeks gecikmesi: arka plandaki ikincil indeks oluşturma gecikmesi kabul edilebilir aralıkta mı?
  • Shadow validation, mevcut depo tabanlı yanıtlarla LedgerStore veri kaynağı kullanıldığında üretilen yanıtları karşılaştırdı
  • Hedef, shadow validation ölçütlerine göre backfill’in eksiksizlik ve doğruluk seviyesini en az %99.99 yapmak, ama üst sınırı %99.9999 olarak tutmaktı
  • Üst sınırın gerekmesi, büyük ölçekli veri doğrulamada her şüpheli vakayı sonuna kadar incelemenin projeyi durdurabilmesiydi
    • Geçmiş veri geçişlerinde ilk geliştirme dönemindeki hatalı yazımlar veya ölçek kaynaklı veri bozulmaları karışmış olabilir
    • S3, 11 nines dayanıklılık sunsa bile 1 trilyon kayıt ölçeğinde 10 bozulmuş kayıt beklenebilir
    • Eventual consistency kullanan indekslerde, birkaç saniye sonra görünecek kayıtlar shadow validation sırasında eksikmiş gibi görünen false positive üretebilir
    • 6 nines güven düzeyini sağlam biçimde doğrulamak için 100 milyon karşılaştırma gerekir; saniyede 1.000 karşılaştırmada bu, bir günden uzun veri toplama anlamına gelir
    • 7 nines için aynı koşullarda 12 gün beklemek gerekir
  • Üretim trafiği LedgerStore’a kopyalanırken yük, gecikme, indeks gecikmesi ve erişim kodunun güvenilirliği birlikte doğrulanabildi
  • Geçiş sırasında bulunan gecikme ve indeks gecikmesi sorunları çeşitli iyileştirmelere yol açtı
    • İndeks verisi dağılımını iyileştirmek için partition key optimizasyonu
    • Point lookup yerine kayıt taramasına yol açan indeks sorunlarının düzeltilmesi
  • Canlı shadow validation, şu anda erişilen veriler için yararlı olsa da neredeyse hiç erişilmeyen tarihsel verinin tamamı için güçlü güvence vermekte zorlanır

Çevrimdışı doğrulama ve artımlı backfill

  • Çevrimdışı doğrulama, LedgerStore’daki tüm veri ile DynamoDB veri dump’larını karşılaştırdı
  • Canlı trafik çoğunlukla güncel verilere eriştiği için, cold data içinde gizli kalan sorunları yalnızca shadow validation ile yakalamak zordur
  • Veri sorunu olan kayıtların, backfill ilerleyebilsin diye atlanması gerekir; ayrıca backfill işinin kendi içinde hata barındırma olasılığı da hesaba katılmalıdır
  • En büyük doğrulama işi, sıkıştırılmış 70TB, sıkıştırılmamış tahmini 300TB veri üzerinde yapıldı ve tek bir işte 760 milyar kayıt karşılaştırıldı
  • Bu ölçekteki Apache Spark işi veri shuffle gerektiriyordu; bu yüzden Distributed Shuffle as a Service for Spark, Dynamic Resource Allocation ve Speculative Execution birlikte kullanıldı
  • Çevrimdışı doğrulamada bulunan eksik kayıtlar, artımlı backfill girdisi olarak kullanıldı
  • Doğrulama ve backfill tekrarlanarak tüm kayıtların yazıldığından emin olundu

Backfill sırasında karşılaşılan operasyonel sorunlar

  • Backfill, küçük ölçekte başlayıp sistem sınırlarına kadar kademeli olarak büyütülmeli
    • Sınırı aşıp kontrolsüz biçimde yüklenmek, kendi sistemine DDoS uygulamak anlamına gelir
    • Darboğazlar bulunup giderildikten sonra yeniden ölçeklenmek gerekir
    • Her büyütme adımından sonra yakın izleme şarttır
  • Birkaç yılın verisini birkaç ay içinde backfill etmek, normal trafikten çok daha büyük yük doğurur
    • Üretim saniyede 1.000 kayıt işlerken, saniyede 10.000 kayıt hızında 100 milyar kaydı backfill etmek 120 gün sürer
    • Backfill işi devam ederken arıza çıkarma ihtimali varsa hemen durdurulmalıdır
  • Backfill, tek seferde sonuna kadar koşan bir iş değil, artımlı batch’lere bölünmüş bir süreç olmalı
    • Her batch birkaç dakika içinde bitecek kadar küçük olmalı
    • İş batch ortasında sonlanabileceği için idempotent olmalı
    • Batch tamamlandığında okunan kayıt sayısı, backfill edilen kayıt sayısı gibi istatistikler dosyaya yazılıp toplanarak ilerleme izlenmeli
  • Güvenli bir backfill için ayarlanabilir hız kontrolü gerekir
    • Java/Scala’da Guava’nın RateLimiter’ı kullanılabilir
    • Üretim trafiği düşükken daha hızlı çalıştırmak mümkünse, sistem durumu izlenerek RPS ayarlanır
    • Uber, additive increase/multiplicative decrease yaklaşımıyla RPS ayarladı, ancak güvenlik için üst sınırı korudu
  • Arıza veya aşırı yük şüphesi varsa backfill hızlıca durdurulabilmeli
    • Arıza sırasında backfill, önleyici tedbir ve gürültüyü azaltma amacıyla durdurulmalı
    • Arıza sonrasında da sistem toparlanırken ek yük oluşabilir
    • Acil durdurma özelliği, ölçekle ilgili sorunların debug edilmesinde de yardımcı olur

Büyük dosyalar, hata toleransı ve loglama

  • Veri dump dosya boyutunu yaklaşık 1GB civarında tutmak ve her iki yönde yaklaşık 10 kat esneklik bırakmak uygun kabul edildi
    • Dosyalar çok büyük olursa çeşitli araçların MultiPart sınırlarına takılabilir
    • Dosyalar çok küçük olursa dosya sayısı aşırı artar ve yalnızca listeleme bile ciddi zaman alır
    • Shell komutları çalıştırılırken ARGMAX sınırına çarpılabilir
  • Backfill’in veri dönüştürme sürecinde veri kalitesi sorunları veya bozuk kayıtlar kaçınılmazdır
    • Sorunlu kayıtlar rastgele dağılmışsa işi her seferinde durdurmak mümkün değildir
    • Aynı zamanda bunun kod hatası olma ihtimali de göz ardı edilmemelidir
    • Sorunlu kayıtlar ayrı dump edilir ve istatistikleri izlenir
    • Hata oranı yükselirse backfill elle durdurulur, sorun giderilir ve sonra devam edilir
  • RPC timeout nedeniyle kayıt yazma işlemi başarısız olabilir
    • Yeniden deneme mümkün olsa da bir noktadan sonra, nedeni ne olursa olsun vazgeçip ilerlemek gerekir ki tüm iş akışı devam edebilsin
  • Debug ve ilerleme takibi için bol log bırakmak istenseniz de loglama altyapısında ciddi baskı oluşabilir
    • Log yazılabilse bile saklanması gereken miktar aşırı büyüyebilir
    • Çok log üreten bölümlerde rate limiting uygulanır
    • Hatalar seyrek yaşanıyorsa tüm hata logları tutulabilir

Kademeli rollout ve fallback’in kaldırılması

  • LedgerStore geçişinde, doğrulama ve backfill istatistiklerinin analizine ek olarak temkinli rollout ile risk azaltıldı
  • Rollout birkaç hafta boyunca sürdü ve ana çağıran servislerin on-call mühendislerinin onayıyla ilerledi
  • İlk aşamada, LedgerStore’da veri bulunamazsa DynamoDB’den getiren bir fallback kullanıldı
  • Fallback loglarında eksik görünen her kayıt için, gerçekten LedgerStore’da eksik olup olmadığı tekrar kontrol edildi
  • Fallback kaldırıldıktan sonra da DynamoDB verisi bir ay daha tutuldu
  • Ardından DynamoDB’ye yazma durduruldu, son bir yedek alındı ve tablolar silindi
  • Tüm geçiş iki yıla yayıldı; geçiş sırasında da sonrasında da kesinti veya arıza yaşanmadan tamamlandı

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-21
Hacker News yorumları

  • 1,7 petabayt veriyi (indekslenmiş 1 trilyon kayıt) ayda birkaç bin dolardan daha düşük maliyetli, çok güçlü tek bir bare-metal sunucuya koyup SQLite ile servis etmenin mümkün olup olmadığını merak ediyorum
    Örneğin şöyle bir yöntemle: https://use.expensify.com/blog/scaling-sqlite-to-4m-qps-on-a...

    • 1,7 petabaytı SQLite'a koymak mı? SQLite'ın kendi tavsiyesi şöyle: Verilerinizin tek bir disk dosyasına sığdırılması rahatsız edici ya da imkânsız olacak kadar büyüyeceğini düşünüyorsanız SQLite yerine başka bir çözüm seçin
      SQLite, 281 terabaytlık dosyaları destekleyen bir disk ve dosya sistemi bulabileceğiniz varsayımıyla en fazla 281 terabayt veritabanını destekler. Yine de içerik boyutunun terabaytlar mertebesine çıkacağına dair işaretler varsa, SQLite yerine merkezi bir istemci/sunucu veritabanını değerlendirmenin daha iyi olduğu belirtiliyor
    • 30,7 TB SSD'lerin tanesi yaklaşık 5.500 dolar ve 1,7 PB'ye ulaşmak için yedeklilik olmadan bile 56 adet gerekiyor. Üstelik SQLite'ın maksimum DB boyutu 140 TB
      Bu kadar depolamayı tek bir sunucuya koymak zor görünüyor; ayda birkaç bin dolar seviyesinde olması ise daha da zor. SQLite da bu kullanım için uygun değil
    • Ticari bulutun değer önerisi; güvenlik riskleri, ısıtma/soğutma, veri merkezi personeli, donanım yaşam döngüsü gibi yan ve dış etkenlerin tamamını hesaba katmadığınız sürece maliyet düşürmek değildir
      Yeterli sermayesi ve kurumsal kapasitesi olan bir şirket kendi bulutunu çok daha ucuza kurabilir, ancak hesabın önemli bir kısmı risk unsurlarını dışarıya devretmekle ilgilidir
    • Ne kadar iyi bir çekiciniz olursa olsun, bazı şeyler en başta çivi değildir
    • Olmaz. SQLite “sadece” 281 TB'a kadar çalışır [0] [1]
      [0] https://www.sqlite.org/releaselog/3_33_0.html
      [1] https://www.sqlite.org/limits.html (#12)

  • LedgerStore açık kaynak değil gibi görünüyor [1] ve ilgili bilgi bulmak için birbirine geri bağlantı veren Uber blog yazılarını takip etmek gerekiyor
    2021 tarihli yazılar içinde LedgerStore hakkında en çok bilgi içerenin bu olduğu anlaşılıyor:
    https://www.uber.com/en-US/blog/dynamodb-to-docstore-migrati...
    [1]:https://github.com/uber

    • Doğru. İç çözüm gibi görünüyor
      Genel olarak Uber'in kendisi yapma eğilimi güçlü gibi. Mevcut açık kaynak çözümlerin yeterli olmadığı sonucuna varıp kendileri geliştirmeye meyilliler. Örneğin Facebook'un MySQL'i MyRocks/RocksDB ekleyerek iyileştirmesi ve açık kaynak olarak sürdürmesi yaklaşımından farklı

  • Yazıyı okuyunca Uber'in oldukça erken dönemde DynamoDB'yi yanlış kullandığı ortaya çıkıyor
    Bazı kritik kullanıcı yolculukları güçlü tutarlılık gerektiriyormuş; geçmiş işlemler için de büyük ölçekli veri ambarı gerekiyormuş gibi görünüyor
    İki tablolu DynamoDB yapısını önce DynamoDB + Redshift gibi bir yapıya çevirmemiş olmaları garip. Bu oldukça yaygın bir desen

    • Bu desen hakkında referans paylaşabilir misin?
    • Neden 2 haftalık değişmez işlemleri Dynamo'ya koymaları gerektiğini anlamıyorum. İpucu verebilecek biri var mı?

  • 2015 civarında Netflix, Spotify, SoundCloud, Uber gibi havalı teknoloji şirketlerinin çok sayıda altyapı ve veritabanı aracı geliştirdiği bir dönem vardı
    Günümüzde mühendisler çoğu zaman AWS/bulut terimleriyle konuşuyor
    Hâlâ bu tür araçları kendisi geliştiren organizasyonlar olduğunu görmek ferahlatıcı

  • Bu özel projenin ekonomisini bilmiyorum ama DynamoDB gerçekten pahalı
    Bir dönem herkesin DynamoDB'yi yanlış kullandığını; önceden hesaplanmış tablolarda nokta okuma yapmak yerine scan ve query yaptıkları için böyle olduğunu sanıyordum
    Ama dağıtık hash tablosu gibi kullansanız bile hâlâ büyük bir prim ödüyorsunuz

    • Neden pahalı dendiğini anlamıyorum. 100 WCU başına yılda 120 dolar, 100 RCU başına yılda 30 dolar ise kulağa pahalı gelmiyor
      1 RCU en fazla 4 KB okuduğuna göre 100 MB okumak için 100.000 RCU gerekir; bu da yılda 30.000 dolar veya ayda 2.500 dolar eder. Hesabım yanlış değilse fiyat açısından buna yaklaşan bir şey bile yok gibi

  • https://tigerbeetle.com'u değerlendirmişler mi merak ediyorum

    • İlginç olurdu. TigerBeetle Zig ile yazılmış
      Ayrıca Uber muhtemelen Zig Foundation ile destek sözleşmesi olan nadir büyük şirketlerden biridir

  • Bu işe katkı verenleri tebrik ederim. Yine de yalnızca bu ekibi çalıştırmanın maliyeti bile epey yüksek ve 6 milyon dolarlık tasarruftan çok farklı olmayacak gibi; buna bakım yükü de ekleniyor
    Ödeme sisteminin uzun vadeli bir bahis olma ihtimali de düşük görünüyor; ekiplerin neden böyle projeler üstlendiği ilginç. Ellerinde zaten bulunan mühendislik ekibinden kaynaklanan bir tür batık maliyet mi?

    • Yelpazenin bir ucunda bu tür yazılımları hafta sonunda geliştirdiğini iddia edenler var. Diğer ucunda ise yıllık 600 bin dolar maaş gerektiğini ve bunu başarmak için 9 meslektaşa daha ihtiyaç olduğunu savunanlar var
      Arada bir yerde daha gerçekçi bir maliyet tahminine yer açan çok alan var
    • Bu tahmin, şüpheli derecede DynamoDB'nin yalnızca veri depolama maliyetini hesaplamaya benziyor
      Veri ve indeksler 1,7 PB ise DynamoDB depolamasının liste fiyatı üzerinden yıllık yaklaşık 5,1 milyon dolar eder
    • Bu ölçekte tamamen özel bir DB sistemi geliştirmek ve sürdürmek yılda 5 milyon dolarsa, kabaca 25 kıdemli mühendis işe alıp yine de ekipman maliyetleri için 1 milyon dolar bırakabilirsiniz
      İşin çekirdek kısmına iyi uyarlanmış özel bir sisteme sahip olmak için yeterince gerçekçi görünüyor
    • Onların kendi maliyetleri hakkında çok daha fazla şey bildiğini, sizinse neredeyse hiçbir şey bilmediğinizi varsaymak daha doğru olur. Ekip üyelerini bu şekilde küçümsemenin pek değeri yok
    • Yazıyı okuyunca bu sistemin DynamoDB'nin üzerinde bir katman olduğu, bunun şirket içi ürün olan Docstore'u kullanacak şekilde güncellendiği ve bu süreçte Docstore'a bir özellik eklemeleri gerektiği anlaşılıyor
      İnsanların söylediği kadar büyük bir iş değil. Üstelik kayıtlar değişmez olduğu için birçok kısım çok daha kolaylaşıyor

  • Belirli bir ölçeğe ulaşıldığında kendin yapmanın daha avantajlı olduğu bir başka istisnai örnek mi, merak ediyorum. Uber'in işlemesi gereken ölçek epey şaşırtıcı
    Orijinal metinden, yeni refaktör edilen servisin toplam sahip olma maliyetinin ne olduğu net değil. Artık kendi veritabanlarını ve arkasındaki depolamayı yönetmeleri gerekmiyor mu? Kaçırdığım bir şey mi var?

    • Prototip aşamasında Redis kullanıp performans ve dayanıklılığı artırmak için kendi veritabanını yazan bir şirkette çalışmıştım
      Bu şirket son kullanıcıya yönelik ürün satan bir yer değil, ürünü dağıtık dosya sistemi olan bir yerdi
      Bana göre çoğu şirket veritabanı gibi sistemler geliştirecek uzmanlığa sahip değil; maliyet açısından geliştirmek mantıklı görünse bile pratikte böyle işlerden çekiniyorlar

  • Tescilli bulut tabanlı veri depolarının ne kadar pahalı olabileceğini ve oradan başka bir şeye geçmenin pratikte mümkün olduğunu çok iyi gösteren bir örnek olduğunu düşünüyorum

  • Mantıklı davranılacağı varsayımıyla, bulut hizmeti sağlayıcıları için hesaplaşma zamanının geleceğini düşünüyorum
    Küçük bir şirkette sözleşmeli iş yapmıştım; 375 MB'lık bir MySQL DB'den gelen verilerle rapor çalıştırmak için GCP Bigtable kullanıyorlardı ve ayda 11.000 dolardan fazla ödüyorlardı
    Okuldan yeni mezun bir veri bilimciyi raporlar hazırlaması için işe almışlardı; çok küçük bir veri kümesi üzerinde akıl almaz derecede verimsiz işler yapıyordu. Yarın hemen üç kuruşa düzeltmemi istediler, reddettim

    • Genel fikre katılıyorum ama bu örneğin iyi bir vaka olduğunu düşünmüyorum
      Bu sadece kötü tasarlanmış bir sistem. Aynı işi çalıştırmak için on-premise bir veritabanını aşırı ölçüde fazla provision etselerdi de aynı sorun yaşanırdı