Sprout Social'ın büyük verilere yaklaşımını yeniden keşfetme

Sprout Social, özünde veri odaklı bir şirkettir. Sprout, her gün birden fazla sosyal ağdan gelen milyarlarca mesajı işler. Bu nedenle, Sprout mühendisleri benzersiz bir zorlukla karşı karşıyadır: platformumuza çok yüksek bir hacimde gelen aynı mesajın birden çok sürümünü (örn. retweet'ler, yorumlar vb.) nasıl saklayacak ve güncelleyeceğiz.

Mesajların birden fazla versiyonunu sakladığımız için, Sprout mühendislerine günde birkaç kez "dünyayı yeniden yaratma" görevi veriliyor; bu, bir sosyal mesajın her bir parçasını tek bir "gerçeğin kaynağında" birleştirmek için tüm veri setini yinelemeyi gerektiren temel bir süreç.

Örneğin, tek bir Twitter gönderisinin beğenilerini, yorumlarını ve retweetlerini takip etmek. Tarihsel olarak, bu kadar büyük miktarda veriyi korumak ve bunlar üzerinde çalışmak için kendi kendini yöneten Hadoop kümelerine güvendik. Her bir Hadoop kümesi, büyük veri projelerini uygun ölçekte yönetmek için Sprout mühendislik ekibinin güvendiği bir uygulama olan Sprout platformunun farklı bölümlerinden sorumlu olacaktır.

Sprout'un büyük veri yaklaşımının anahtarları

Hadoop ekosistemimiz, ölçeklenebilir ve dağıtılmış bir NoSQL veritabanı olan Apache Hbase'e bağlıydı. Hbase'i büyük verileri işleme konusundaki yaklaşımımız için çok önemli kılan şey, yalnızca tüm veri kümeleri üzerinde hızlı aralık taramaları yapabilmesi değil, aynı zamanda hızlı, rastgele, tek kayıt aramaları yapabilmesidir.

Hbase ayrıca toplu veri yüklememize ve rastgele verileri güncellememize izin verir, böylece düzensiz veya kısmi güncellemelerle gelen mesajları ve sosyal medya verileriyle gelen diğer zorlukları daha kolay halledebiliriz. Ancak kendi kendini yöneten Hadoop kümeleri, altyapı mühendislerimize olağanüstü durum kurtarma, küme genişletme ve düğüm yönetimini manuel olarak yönetme dahil olmak üzere yüksek işletme maliyetleri yükler.

Sprout'un Altyapı ve Geliştirme ekipleri, yüzlerce terabayt veri içeren bu sistemleri yönetmekten kaynaklanan süreyi azaltmaya yardımcı olmak için kendi kendini yöneten Hadoop kümelerini çalıştırmaktan daha iyi bir çözüm bulmak için bir araya geldi. Hedeflerimiz şunlardı:

• Sprout mühendislerinin büyük veri kümelerini daha iyi oluşturmasına, yönetmesine ve çalıştırmasına izin verin
• Mühendislerin sisteme manuel olarak sahip olması ve bakımını yapması için harcadığı zamanı en aza indirin
• Küme genişletme nedeniyle gereksiz fazla sağlama maliyetlerini azaltın
• Daha iyi felaket kurtarma yöntemleri ve güvenilirlik sağlayın

Mevcut büyük veri sistemimizin alternatiflerini değerlendirirken, mevcut işleme ve kalıplarımızla kolayca entegre olan ve bir kümeyi manuel olarak yönetmenin getirdiği operasyonel zahmeti azaltacak bir çözüm bulmaya çalıştık.

Yeni veri deseni alternatiflerini değerlendirme

Ekiplerimizin üzerinde düşündüğü çözümlerden biri de veri ambarlarıydı. Veri ambarları, veri analizi ve birleştirme için merkezi bir depo görevi görür, ancak Hbase ile karşılaştırıldığında geleneksel ilişkisel veritabanlarına daha çok benzer. Verileri yapılandırılmıştır, filtrelenmiştir ve katı bir veri modeline sahiptir (yani, tek bir nesne için tek bir satıra sahip olmak).

Yan yana yaşayan bir mesajın birçok versiyonuna sahip sosyal mesajları saklama ve işleme kullanım durumumuz için, veri ambarlarının ihtiyaçlarımızı karşılayacak verimsiz bir modeli vardı. Mevcut modelimizi veri ambarlarına etkin bir şekilde uyarlayamadık ve performans beklediğimizden çok daha yavaştı. Veri ambarı modeline uyum sağlamak için verilerimizi yeniden biçimlendirmek, sahip olduğumuz zaman çizelgesinde yeniden çalışmak için büyük bir ek yük gerektirecektir.

İncelediğimiz bir başka çözüm de veri göl evleriydi. Veri gölevleri, daha az yapılandırılmış veri, daha ucuz depolama ve hassas veriler etrafında ekstra bir güvenlik katmanı sağlamak için veri ambarı kavramlarını genişletir. Veri göl evleri, veri ambarlarının sunabileceğinden daha fazlasını sunarken, mevcut Hbase çözümümüz kadar verimli değildi. Birleştirme kaydımızı ve ekleme ve silme işleme modellerimizi test ederek, toplu işlerimiz için kabul edilebilir yazma gecikmeleri oluşturamadık.

AWS EMR ile genel giderleri ve bakım maliyetlerini azaltın

Veri ambarı ve göl evi çözümleri hakkında öğrendiklerimizi göz önünde bulundurarak, yönetilen Hbase'i çalıştıran alternatif araçları araştırmaya başladık. Mevcut Hbase kullanımımızın Sprout'ta yaptıklarımız için etkili olduğuna karar verirken kendimize şunu sorduk: "Ana kullanım modellerimizi korurken operasyonel yükümüzü azaltmak için Hbase'i nasıl daha iyi çalıştırabiliriz?"

Bu, Amazon'un Hbase için Elastic Map Reduce (EMR) tarafından yönetilen hizmetini değerlendirmeye başladığımız zamandır. EMR'yi değerlendirmek, performans gereksinimlerimizi karşılayıp karşılamadığını görmek için veri alımını test etmek gibi veri ambarlarını ve göl evlerini test ettiğimiz şekilde performansının değerlendirilmesini gerektiriyordu. EMR'nin altyapı/yönetim açısından ihtiyaçlarımıza uygun olduğundan emin olmak için veri depolama, yüksek kullanılabilirlik ve olağanüstü durum kurtarmayı da test etmemiz gerekti.

EMR'nin özellikleri, mevcut kendi kendini yöneten çözümümüzü geliştirdi ve Hbase ile yaptığımız gibi okuma, yazma ve işleri yürütme için mevcut modellerimizi yeniden kullanmamızı sağladı. EMR'nin en büyük faydalarından biri, verileri düğümlerin kendileri yerine S3'te depolayan EMR Dosya Sisteminin (EMRFS) kullanılmasıdır.

Bulduğumuz bir zorluk, EMR'nin sınırlı yüksek kullanılabilirlik seçeneklerine sahip olmasıydı, bu da bizi tek bir kullanılabilirlik bölgesinde birden çok ana düğümü veya birden çok kullanılabilirlik bölgesinde bir ana düğümü çalıştırmakla sınırladı. Bu risk, olağanüstü durum kurtarma için ek hata toleransı ve veri depolamanın bilgi işlem işlevlerinden ayrıştırılması için EMRFS'den yararlanılarak azaltıldı. EMR'yi Hbase çözümümüz olarak kullanarak, ölçeklenebilirliğimizi ve hata düzeltmemizi geliştirebiliyor ve kümelerin bakımı için gereken manuel müdahaleyi en aza indirebiliyoruz. Sonunda EMR'nin ihtiyaçlarımıza en uygun olduğuna karar verdik.

Milyarlarca kaydı yeni EMR kümelerine herhangi bir müşteri kesintisi olmadan geçirmek için geçiş süreci önceden kolayca test edildi ve uygulandı. Yeni kümeler, gelişmiş performans gösterdi ve maliyetleri yaklaşık %40 oranında düşürdü. EMR'ye geçmenin altyapı maliyetlerini düşürmeye ve performansımızı iyileştirmeye nasıl yardımcı olduğu hakkında daha fazla bilgi edinmek için Sprout Social'ın AWS ile ilgili örnek olay incelemesine göz atın.

Ne öğrendik

Bu projenin boyutu ve kapsamı, Altyapı Veritabanı Güvenilirlik Mühendisliği ekibi olarak bize, birden çok mühendislik ekibiyle fonksiyonlar arası çalışma fırsatı verdi. Zorlu olsa da, işbirlikçi bir mühendislik organizasyonu olarak Sprout'ta üstesinden gelebileceğimiz büyük ölçekli projelerin inanılmaz bir örneği olduğunu kanıtladı. Bu proje sayesinde, Altyapı ekibimiz Sprout'un verilerinin nasıl kullanıldığı, saklandığı ve işlendiği konusunda daha derin bir anlayış kazandı ve gelecekteki sorunları gidermeye yardımcı olmak için daha donanımlıyız. Yeni nesil müşteri özelliklerini oluşturmamıza yardımcı olabilecek birden çok ekip arasında ortak bir bilgi tabanı oluşturduk.

İnşa ettiğimiz şeyle ilgileniyorsanız, ekibimize katılın ve bugün açık mühendislik rollerimizden biri için başvurun.