- Stripe, 2023’te toplam 1 trilyon dolarlık ödeme hacmini işlerken %99,999 erişilebilirliği korudu
- Stripe’ın veritabanı altyapı ekibi, API’nin temel katmanı olarak DocDB adlı bir database as a service (DBaaS) sunuyor
- DocDB, MongoDB Community’nin genişletilmiş bir sürümü ve Stripe içinde geliştirilen çeşitli servislerden oluşuyor
- Saniyede 5 milyondan fazla sorgu işliyor ve petabayt ölçeğindeki kritik finansal verileri 2.000’den fazla veritabanı shard’ına dağıtarak 5.000’den fazla collection’da saklıyor
- MongoDB Community’nin seçilme nedeni, belge modelinin esnekliği ve büyük ölçekli gerçek zamanlı veri işleme yeteneğiydi
- 2011’de MongoDB Atlas henüz mevcut olmadığından, bulutta çalışan kendi kendine yönetilen MongoDB instance cluster’ları kuruldu
- DocDB’nin kalbinde Data Movement Platform bulunuyor
- Başlangıçta MongoDB’nin dikey ölçekleme sınırlarını aşmak için yatay ölçekleme çözümü olarak inşa edildi, ancak farklı amaçlar için özelleştirildi
- Kullanım ve verimliliği artırmak için atıl veritabanı shard’larının birleştirilmesi, güvenilirlik için veritabanı motorunun ana sürüm yükseltmeleri, büyük kullanıcılar için multitenant yapıdan single-tenant yapıya geçiş gibi amaçlarda kullanılıyor
- Data Movement Platform, az sayıdaki büyük hacimli veritabanı shard’ından çok sayıdaki küçük hacimli veritabanı shard’ına geçişi mümkün kılıyor
- Ayrıca istemciye şeffaf migration ve sıfır kesinti sunarak son derece esnek bir DBaaS sağlanmasına imkan veriyor
- DocDB, trafik artışlarında veritabanı shard’larını bölebiliyor; trafik düşük olduğunda ise bin-packing ile binlerce veritabanını birleştirebiliyor
Veritabanı altyapısı nasıl kuruldu
- Stripe, 2011’de piyasaya çıktığında standart ilişkisel veritabanlarına göre daha yüksek geliştirici verimliliği sunduğu için MongoDB’yi çevrimiçi veritabanı olarak seçti
- MongoDB üzerinde, API güvenilirliğini önceliklendiren sağlam bir veritabanı altyapısı işletmek istiyordu ancak gereksinimlerini karşılayan hazır bir DBaaS bulamadı
- En üst düzey erişilebilirlik, dayanıklılık ve performans sağlama
- İstemci uygulamalarındaki optimize edilmemiş sorguların kendi sorunlarını yaratmasını önlemek için veritabanı özelliklerini minimum düzeyde açığa çıkarma
- Sharding ile yatay ölçeklenebilirlik desteği
- Zorunlu kotalara sahip multitenancy için birinci sınıf destek
- Yetkilendirme politikalarının uygulanmasıyla güçlü güvenlik sağlama
- Çözüm, temel depolama motoru olarak MongoDB kullanarak DocDB’yi inşa etmek oldu; gerçekten esnek ve ölçeklenebilir bir DBaaS ve bunun merkezinde çevrimiçi veri migration’ı yer alıyor
- Stripe’ın ürün uygulamaları, güvenilirlik, ölçeklenebilirlik, tahsis kontrolü ve erişim kontrolü konularını uygulamak için Go ile şirket içinde geliştirilen bir veritabanı proxy sunucu filosu üzerinden veritabanı verilerine erişiyor
- Temel mimari karar olarak yatay ölçekleme mekanizması için sharding kullanılmasına karar verildi
- Birikmiş verinin küçük parçalarını ayrı ayrı tutan binlerce veritabanı shard’ı artık Stripe’ın tüm ürünlerinin temelini oluşturuyor
- Uygulama veritabanı proxy sunucusuna bir sorgu gönderdiğinde, sorgu ayrıştırılıyor, bir veya daha fazla shard’a yönlendiriliyor, ardından shard sonuçları birleştirilip uygulamaya geri döndürülüyor
- Veritabanı proxy sunucusu, chunk metadata service’e bağımlı olarak chunk’ları veritabanı shard’larına eşliyor ve böylece belirli bir sorgu için ilgili shard’ları kolayca bulabiliyor
- Veritabanına yapılan yazmalardan doğan değişiklik olayları bir streaming yazılım sistemine gönderiliyor ve sonunda change data capture (CDC) pipeline’ı üzerinden object storage’da saklanıyor
- Stripe ekibi, ürün uygulaması seviyesinde şirket içi belge veritabanı control plane’ini kullanarak, ilişkili amaçlara sahip belgelerden oluşan bir veya daha fazla DocDB collection’ını içeren mantıksal veritabanları şeklinde verinin mantıksal kapsayıcılarını provision ediyor
- Bu DocDB collection’larındaki veriler, collection’ların küçük chunk’larını tutan birden fazla veritabanına, yani fiziksel veritabanlarına dağıtılıyor
- DocDB’nin fiziksel veritabanları, primary node ile çoğaltma ve otomatik failover içeren birden fazla secondary node’dan oluşan replica set olarak dağıtılmış shard’larda bulunuyor
Data Movement Platform nasıl tasarlandı
- Ürün uygulamalarının ihtiyaçlarına göre büyüyüp küçülebilen, yatay ölçeklenebilir ve yüksek esnekliğe sahip bir DBaaS ürünü oluşturmak için, istemciye şeffaf biçimde ve sıfır kesintiyle veritabanı shard’ları arasında veri taşıyabilme yeteneği gerekiyordu
- Bu, kritik finansal verilerin kendine özgü gereksinimleri nedeniyle daha da karmaşık hale gelen zor bir dağıtık sistem problemiydi
- Veri tutarlılığı ve bütünlüğü: Taşınan verinin hem kaynak shard’da hem de hedef shard’da tutarlı ve eksiksiz kalmasının garanti edilmesi gerekiyordu
- Erişilebilirlik: Veri migration’ı sırasında uzun süreli kesinti kabul edilemezdi. Çünkü milyonlarca işletme müşterilerinden 7/24 ödeme almak için Stripe’a güveniyor
- Hedef, migration sürecinin kritik adımlarını planlı veritabanı primary failover süresinden, yani genellikle birkaç saniyeden daha kısa tutmak ve bunu ürün uygulamalarının retry bütçesine sığdırmaktı
- Ayrıntı düzeyi ve uyarlanabilirlik: Stripe ölçeğinde, verinin istenen sayıda chunk’ı, istenen sayıda kaynaktan hedef shard’lara taşınabilmeliydi
- Filo genelinde aynı anda yürütülen veritabanı chunk migration sayısında sınır olmamalıydı ve belirli bir anda belli bir shard’ın katılabileceği migration sayısı da sınırsız olmalıydı
- Ayrıca veritabanı shard’larının önemli bir kısmı terabayt ölçeğinde veri içerdiğinden, farklı boyutlardaki chunk’ların yüksek throughput ile taşınabilmesi gerekiyordu
- Kaynak shard üzerinde performans etkisi olmaması: Veritabanı chunk’ları shard’lar arasında taşınırken, kullanıcı sorguları için performans ve kullanılabilir throughput üzerinde olumsuz etki yaratmamak amacıyla kaynak shard’ın performansı ve throughput’unun korunması hedeflendi
- Bu gereksinimleri karşılamak için, veritabanı shard’ları arasında çevrimiçi veri migration’ını yöneten, amaca özel servisleri çağıran bir veri taşıma platformu oluşturuldu
- Veri taşıma platformunun Coordinator bileşeni, çevrimiçi veri migration’ıyla ilgili çeşitli adımları orkestre etmekten sorumlu ve aşağıda açıklanan her yapılandırma adımını yerine getirmek için ilgili servisleri çağırıyor
1. adım: Chunk migration’ını kaydetme
- Önce chunk metadata service’te, bir veritabanı chunk’ını kaynak shard’dan istenen bir hedef shard’a taşıma niyeti kaydediliyor
- Ardından taşınacak chunk için hedef shard üzerinde index’ler oluşturuluyor
2. adım: Toplu veri içe aktarma
- Sonraki adımda, zaman T anındaki kaynak shard chunk snapshot’ı kullanılarak veriler bir veya daha fazla veritabanı shard’ına yükleniyor
- Toplu veri içe aktarmayı gerçekleştiren servis, çeşitli veri filtrelerini destekliyor ve yalnızca filtre ölçütlerini karşılayan veri chunk’larını içe aktarıyor
- İlk bakışta basit görünse de, DocDB shard’larına toplu veri yüklerken throughput sınırlarıyla karşılaşıldı
- Yazmaları batch’lemek ve en iyi toplu veri alımı için DocDB motor parametrelerini ayarlamak denendi, ancak büyük bir başarı elde edilemedi
- Ancak DocDB’nin verileri sıralamak için B-tree veri yapısını kullandığından yararlanılarak ekleme sırasını optimize etme yönünde önemli bir atılım sağlandı
- Collection’daki en yaygın index özelliğine göre veriler sıralanıp bu sıralı düzende eklendiğinde, yazma yakınlığı ciddi ölçüde arttı ve yazma throughput’u 10 kat yükseldi
3. adım: Asenkron çoğaltma
- Veriler hedef shard’a aktarıldıktan sonra, zaman T anından itibaren taşınan veritabanı chunk’ı için kaynaktan hedef shard’a yazma çoğaltması başlatılıyor
- Asenkron çoğaltma sistemi, CDC sisteminin kaynak shard’a yapılan yazmalardan ürettiği değişiklikleri okuyor ve hedef shard üzerinde yazmaları gerçekleştiriyor
- Operation log veya oplog, her DocDB shard’ında bulunan özel bir collection ve ilgili shard’daki veritabanı verilerini değiştiren tüm işlemlerin kaydını tutuyor
- Tüm DocDB shard’larının oplog’ları, olay akışı platformu Kafka’ya gönderiliyor ve ardından Amazon S3 gibi bulut object storage hizmetlerinde saklanıyor
- Kafka ve Amazon S3’teki oplog olaylarını kullanarak, bir veya daha fazla kaynak DocDB shard’ından bir veya daha fazla hedef DocDB shard’ına değişiklikleri çoğaltan bir servis inşa edildi
- Bu yaklaşım, CDC sistemindeki oplog olaylarına dayanarak kaynak shard’ın kullanıcı sorguları için kullanılabilecek okuma throughput’unu tüketmeden, yani kullanıcı sorgularını yavaşlatmadan ve kaynak shard’ın oplog boyutuyla sınırlanmadan çalışmayı sağlıyor
- Servis, hedef shard kullanılamıyor olsa bile dayanıklı olacak ve herhangi bir checkpoint’ten eşitlemeyi başlatma, duraklatma ve sürdürmeye izin verecek şekilde tasarlandı
- Çoğaltma servisi ayrıca replication lag’i getirme yeteneği de sunuyor
- Taşınan chunk’taki değişiklikler kaynak shard’dan hedef shard’a ve ters yönde çift yönlü olarak çoğaltılıyor; çoğaltma servisi, döngüsel asenkron çoğaltmayı önlemek için yayımladığı yazmaları etiketliyor
- Bu, hedef shard’a trafik yönlendirildiğinde sorun çıkarsa trafiği kaynak shard’a geri döndürme esnekliği sağlamak için bilinçli bir tasarım tercihiydi
4. adım: Doğruluk kontrolü
- Kaynak shard ile hedef shard arasındaki çoğaltma senkronize olduktan sonra, belirli bir zaman noktasına ait snapshot’lar karşılaştırılarak veri bütünlüğü ve doğruluğu kapsamlı biçimde doğrulanıyor
- Bu, shard throughput’unu etkilememek için bilinçli olarak alınmış bir tasarım kararıydı
5. adım: Trafiği geçirme
- Chunk verisi kaynaktan hedef shard’a aktarıldıktan ve değişiklikler aktif şekilde çoğaltıldıktan sonra, trafik geçişi Coordinator tarafından orkestre ediliyor
- Taşınan veri chunk’ı için okuma ve yazma yollarını yeniden yönlendirmek amacıyla önce kaynak shard’daki trafik kısa süreliğine durduruluyor, ardından chunk metadata service’teki rota güncelleniyor ve proxy sunucuları okuma-yazma trafiğini hedef shard’a yönlendiriyor
- Trafik geçiş protokolü, version gating fikrine dayanıyor
- Kararlı durumda her proxy sunucusu, DocDB shard’larına giden isteklere bir version token numarası ekliyor
- MongoDB’ye özel yamalar eklenerek shard’ların, proxy sunucusundan gelen istekteki version token numarasının kendi bildiği version token numarasından daha yeni olup olmadığını kontrol etmesi ve yalnızca bu ölçütü karşılayan istekleri işlemesi sağlandı
- Chunk yönlendirmesini güncellemek için Coordinator üzerinden şu adımlar uygulanıyor:
- Önce kaynak DocDB shard’ının version token numarası artırılıyor. Bu numara DocDB’deki özel bir collection içindeki belgede tutuluyor ve bu noktada kaynak shard’daki chunk için tüm okuma ve yazmalar reddediliyor
- Ardından çoğaltma servisinin kaynak shard’daki bekleyen yazmaları çoğaltması bekleniyor
- Son olarak chunk metadata service’teki chunk yönlendirmesi, hedef shard’ı ve version token numarasını gösterecek şekilde güncelleniyor
- Bu tamamlandığında, proxy sunucuları chunk metadata service’ten chunk için güncellenmiş yönlendirmeyi ve en güncel version token numarasını alıyor
- Proxy sunucuları, chunk için güncellenmiş yönlendirmeyi kullanarak okuma ve yazmaları hedef shard’a yönlendiriyor
- Tüm trafik geçiş protokolü 2 saniyeden kısa sürede tamamlanıyor ve kaynak shard’a gönderilen başarısız tüm okuma-yazmalar retry sonrasında başarılı oluyor
6. adım: Chunk migration kaydını kaldırma
- Son olarak, chunk metadata service’te migration tamamlandı olarak işaretleniyor ve kaynak shard’daki chunk verisi silinerek süreç sonlandırılıyor
Veri taşıma platformunun kullanımı
- DocDB shard’ları arasında veri chunk’larını çevrimiçi biçimde taşıyabilme yeteneği, Stripe’ın büyüme hızına uyumlu şekilde veritabanı altyapısını yatay olarak ölçeklendirmesine yardımcı oluyor
- Veritabanı altyapı ekibindeki mühendisler, yalnızca bir düğmeye basarak boyut ve throughput’a göre DocDB shard’larını bölebiliyor; böylece ürün ekipleri için veritabanı depolama ve throughput kapasitesi açılıyor
- 2023’te veri taşıma platformu, veritabanı altyapısı kullanım verimliliğini artırmak için kullanıldı
- Özellikle, ürün uygulamalarına şeffaf biçimde 1,5 petabayt veriyi taşıyarak düşük kullanılan binlerce veritabanını bin-pack etti ve alttaki toplam DocDB shard sayısını yaklaşık dörtte üç seviyesine indirdi
- Ayrıca veri taşıma platformu kullanılarak, aradaki ana ve ara sürümlerden geçmeden, veri tek adımda daha yeni bir MongoDB sürümüne forklift edilerek veritabanı altyapı filosu yükseltildi
- Stripe’ın veritabanı altyapı ekibi, internet ekonomisinin büyümesine paralel ölçeklenen sağlam ve güvenilir bir temel kurmaya odaklanıyor
- Ekip şu anda boyut ve throughput’a göre shard’lar arasında veriyi proaktif biçimde dengeleyen bir heat management system prototipi geliştiriyor ve trafik desenlerindeki değişimlere dinamik tepki veren shard auto-scaling yatırımları yapıyor
Henüz yorum yok.