Uber'in muhasebe verilerini DynamoDB'den LedgerStore'a taşıması

• Geçen hafta Uber'in ekibe özel muhasebe tarzı veritabanı LedgerStore (LSG)'yi incelemiştik.
• Bu hafta Uber'in iş açısından kritik muhasebe verilerini LSG'ye nasıl taşıdığını ele alıyoruz.
• 1 trilyondan fazla kaydı (birkaç petabayt veri) kesinti olmadan ve şeffaf biçimde nasıl taşıdıklarını ve bu süreçte neler öğrendiklerini tartışıyor.

Geçmiş

• Gulfstream, Uber'in ödeme platformu ve 2017'de DynamoDB kullanılarak yayına alındı.
• Uber'in ölçeğinde DynamoDB pahalı hale geldi; bu yüzden yalnızca 12 haftalık veriyi (hot data) DynamoDB'de tutmaya, daha eski veriyi (cold data) ise Uber'in blobstore'u TerraBlob'da saklamaya başladılar.
• Uzun vadeli çözüm olarak LSG'yi kullanmak istiyorlardı. LSG, ödeme tarzı verileri depolamak için amaca uygun şekilde tasarlanmıştı.
• LSG'nin başlıca özellikleri:
  • Doğrulanabilir değişmezlik (kriptografik imzalar kullanılarak kayıtların değiştirilmediği doğrulanabiliyor)
  • Maliyet yönetimi için katmanlı depolama (hot data istekleri karşılamaya uygun yerde, cold data ise depolama için optimize edilmiş yerde tutuluyor)
  • Sonuçta tutarlı ikincil indeksler için daha düşük gecikme
• 2021'e kadar Gulfstream verileri DynamoDB, TerraBlob ve LSG kombinasyonunda saklıyordu.
  • DynamoDB: son 12 haftalık veri
  • TerraBlob: cold data
  • LSG: verilerin yazıldığı ve taşınmak istendiği hedef

Neden taşıma gerekiyordu?

• LSG, değişmezlik özelliği nedeniyle muhasebe tarzı verileri saklamak için daha uygundu.
• LSG'ye geçiş ciddi ölçüde tekrarlayan maliyet tasarrufu sağladı.
• Üç depolama sisteminden tek depolama sistemine geçmek, Gulfstream servisinin kodunu ve tasarımını sadeleştirebilirdi.
• LSG daha kısa indeksleme gecikmesi vadediyordu ve Uber'in veri merkezlerinde on-premise çalıştığı için daha düşük ağ gecikmesi sunuyordu.

Verinin doğasından kaynaklanan riskler

• Taşınan veri, 2017'den bu yana Uber'in tüm iş açısından kritik muhasebe verisiydi:
  • Değişmez kayıtlar: sıkıştırılmış boyut 1.2 PB
  • İkincil indeksler: sıkıştırılmamış boyut 0.5 PB
• Değişmez kayıtlar değiştirilemezken, ikincil indeks verisi sorunları düzeltmek için değiştirilebilecek esnekliğe sahipti.

Doğrulama

• Backfill'in her açıdan doğru ve kabul edilebilir olduğunu doğrulamak için, hem mevcut trafiği işleyebildiğini hem de şu anda erişilmeyen verinin doğru olduğunu doğrulamak gerekiyordu.
• Doğrulama ölçütleri:
  • Eksiksizlik: tüm kayıtlar backfill ile taşındı mı
  • Doğruluk: tüm kayıtlar doğru mu
  • Yük: LSG mevcut yükü kaldırabiliyor mu
  • Gecikme süresi: LSG'nin P99 gecikmesi kabul edilebilir aralıkta mı
  • Lag: ikincil indeks oluşturma gecikmesi kabul edilebilir aralıkta mı

Shadow validation

• Taşıma öncesi ve sonrası yanıtlar karşılaştırılarak mevcut trafiğin veri taşıma sorunları veya kod hataları nedeniyle etkilenmemesi sağlandı.
• Shadow validation ile backfill'in en az %99.99 eksiksiz ve doğru olduğu doğrulandı; üst sınır %99.9999 olarak belirlendi.
• Shadow validation, LSG'nin production trafiğini işleyebildiğini doğruladı ve veri erişim koduna güven sağladı.
• Shadow validation, şu anda erişilen verinin eksiksizliği ve doğruluğu konusunda güven sağladı.

Offline validation ve artımlı backfill

• LSG'deki tüm veri, DynamoDB veri dökümüyle karşılaştırıldı.
• Offline validation, veri backfill'inin doğru yapıldığını doğrular ve tüm veri kümesini kapsar.
• Offline validation, shadow validation ile birlikte yürütülmelidir.

Backfill sorunları

• Her backfill risklidir. Uber backfill'i Apache Spark kullanarak gerçekleştirdi.
• Sorunları ele alma yöntemleri:
  • Ölçeklenebilirlik: küçük ölçekte başlayıp kademeli olarak büyütmek
  • Artımlı backfill: veriyi küçük partilere bölerek taşımak
  • Hız kontrolü: backfill işlerinin hızını ayarlamak
  • Dinamik hız kontrolü: sistemin anlık durumunu izleyerek hızı ayarlamak
  • Acil durdurma: aşırı yük şüphesi olduğunda backfill'i hızla durdurabilmek
  • Veri dosyası boyutu: veri dökümü dosyalarının boyutunu uygun seviyede tutmak
  • Hata toleransı: veri kalitesi/bozulma sorunlarını ele almak
  • Loglama: log altyapısını zorlamamak için log miktarını sınırlamak

Risk azaltma

• Çeşitli doğrulama ve backfill istatistikleri analiz edilerek LSG rollout'u temkinli biçimde gerçekleştirildi.
• Başlangıçta, backfill başarısız olursa veriyi DynamoDB'den getiren bir fallback kullanıldı.
• Fallback logları incelenerek LSG'de verinin gerçekten eksik olup olmadığı kontrol edildi.

Sonuç

• Bu yazı, büyük ölçekli ve iş açısından kritik muhasebe verilerinin bir veri deposundan diğerine taşınma sürecini ele alıyor.
• Taşıma ölçütleri, doğrulama, backfill sorunları ve güvenlik gibi çeşitli boyutlar inceleniyor.
• Taşıma 2 yıl boyunca kesinti veya arıza olmadan tamamlandı.

GN⁺ görüşü

• Veri taşımanın önemi: Büyük ölçekli veri taşıma karmaşık ve riskli olsa da, maliyet tasarrufu ve sistem sadeleşmesi sayesinde uzun vadede büyük fayda sağlar.
• Shadow validation'ın faydası: Shadow validation, gerçek trafiği etkilemeden verinin eksiksizliğini ve doğruluğunu doğrulamak için güçlü bir araçtır.
• Offline validation'ın gerekliliği: Yalnızca shadow validation ile ortaya çıkmayan sorunlar bulunabildiği için offline validation da şarttır.
• Backfill'e kademeli yaklaşım: Backfill işlerini küçük partilere bölüp kademeli yürütmek, sistemin aşırı yüklenmesini önlemede etkilidir.
• Acil durdurma özelliği: Backfill sırasında sorun çıkarsa işi hızla durdurabilmek, sistem kararlılığını korumak açısından önemlidir.

[GN⁺]

Hacker News görüşü

Hacker News yorum derlemesi özeti

• Çeyrek başına 2 milyar yolculuk

  • Uber her çeyrekte 2 milyar yolculuk işliyor. Bu, saniyede yaklaşık 1000 işleme karşılık gelebilir. Altyapı ölçeklendirmesine neden bu kadar odaklandıklarını anlamak zor.

• DynamoDB’nin kötü kullanımı

  • Uber DynamoDB’yi kötü kullanıyordu. Belirli kritik kullanıcı yolculukları (CUJ) için güçlü tutarlılık gerekiyor ve geçmiş işlemler için veri ambarı gerekli. DynamoDB ve Redshift mimarisine geçmemiş olmaları garip.

• Google’ın reddettikleri

  • Uber sanki Google’da başarısız olmuş bir projeyi almış gibi görünüyor. Bu tür projeler genelde büyük bir terfiyi hedefler. “Kendi sistemimi tasarlayıp kurarak $Xm tasarruf sağladım! Bana terfi verin!” gibi. Ama kurulum maliyeti daha yüksek olur ve birkaç yıl sonra çöpe gitme ihtimali büyüktür.

• Tek sunucuda SQLite

  • 1,7 petabayt verinin (1 trilyon indekslenmiş kayıt) tek bir yüksek performanslı bare-metal sunucuda SQLite ile tutulup tutulamayacağı merak ediliyor. Örnek bağlantı verilmiş.

• LedgerStore açık kaynak değil

  • LedgerStore açık kaynak değil. Bununla ilgili bilgi bulmak için Uber blog yazılarını takip etmek gerekiyor. 2021 tarihli bir yazıya bağlantı verilmiş.

• Özel altyapı dönemi

  • 2015 civarında Netflix, Spotify, SoundCloud, Uber gibi birçok teknoloji şirketi altyapı ve veritabanı araçlarını yoğun biçimde geliştiriyordu. Bugünse birçok mühendis AWS/bulut terminolojisiyle konuşuyor. Hâlâ kendi araçlarını geliştiren organizasyonlar görmek ferahlatıcı.

• Pahalı, kapalı bulut

  • Bu, özel mülkiyetli bulut tabanlı veri depolamanın ne kadar pahalı olabildiğini gösteren iyi bir örnek. Başka bir şeye geçiş yapmak mümkün.

• TigerBeetle düşünüldü mü?

  • TigerBeetle’ın değerlendirilip değerlendirilmediği merak ediliyor.

• DynamoDB pahalı

  • Bu projenin ekonomik tarafı bilinmiyor ama DynamoDB gerçekten pahalı. Başkalarının onu yanlış kullandığı düşünülse bile, dağıtık hash tablosu gibi kullanıldığında da maliyet çok yüksek kalıyor.

• Ekibi yürütmenin maliyeti

  • Proje ekibini işletmenin maliyeti, sağlanan tasarrufa (6 milyon dolar) çok da uzak görünmüyor. Buna bakım maliyeti de eklenecek. Ödeme sistemleri muhtemelen uzun vadeli bir bahis değil. Neden böyle projelere girildiği ilginç. Bu, mevcut mühendislik ekibiyle ilgili bir batık maliyet meselesi de olabilir.