How ShareChat engineers rebuilt a low-latency ML feature store on ScyllaDB after an initial scalability failure — and what they learned along the way Düşük latensiyel makine öğrenme özelliği mağazalarına olan talep her zamankinden daha yüksektir, ancak aslında birini ölçekte uygulamak hala bir zorluk kalır.Bu, ShareChat mühendisleri Ivan Burmistrov ve Andrei Manakov, P99 CONF 23 aşamasını ScyllaDB'ye dayanan düşük latensiyel ML özelliği mağazasını nasıl inşa ettiklerini paylaşmak için ortaya çıktı. Bu, yeni bir ürünün gününü kurtardığı düzgün bir vaka çalışması değildir. “öğrenme dersleri” hikayesi, acımasız performans optimizasyonunun değerine bir bakış - bazı önemli mühendislik önlemleri ile. Orijinal sistem uygulanması şirketin ölçeklenebilirlik gereksinimlerinin çok altında düştü. nihai hedefi saniyede 1 milyar özellik desteklemekti, ancak sistem sadece 1 milyon yük altında başarısız oldu. Bazı akıllı sorun çözümü ile ekibi bunu kaldırdı. ShareChat: Hindistan'ın önde gelen sosyal medya platformu Sorunun kapsamını anlamak için, Hindistan'da önde gelen sosyal medya platformu olan ShareChat hakkında biraz bilgi edinmek önemlidir. ShareChat uygulamasında kullanıcılar video, resimler, şarkılar ve daha fazlası dahil olmak üzere 15'den fazla farklı dilde içerik keşfetmek ve tüketmek için kullanılır. ShareChat ayrıca kullanıcıları trend etiketleri ve yarışmalarla yaratıcı olmaya teşvik eden bir TikTok benzeri kısa video platformu (Moj) barındırır. İki uygulama arasında, ayda 325 milyondan fazla aktif kullanıcıya sahip hızla büyüyen bir kullanıcı tabanına hizmet veriyorlar. ShareChat'ta Satış Yöntemleri Bu hikaye, kısa formlu video uygulaması Moj için ML özellik mağazalarının arkasındaki sistemle ilgilidir. Günlük aktif yaklaşık 20 milyon kullanıcıya, aylık aktif 100 milyon kullanıcıya tam olarak kişiselleştirilmiş akışlar sunar. akışlar saniyede 8.000 isteğe hizmet eder ve her isteğe göre ortalama 2.000 içerik adayı sıralanır (örneğin, tavsiye etmek için en iyi 10 öğeyi bulmak için). İvan Burmistrov, ShareChat'ın ana personel yazılım mühendisi, şöyle açıklıyor: Post bir entite, User bir diğer ve benzeri. Hesaplama bakış açısıyla, onlar oldukça benzer. Ancak, önemli fark, her tür entite için toplamak için ihtiyacımız olan özelliklerin sayısıdır. Bir kullanıcı bir akış isteyince, biz o tek kullanıcı için kullanıcı özellikleri toplamak. Ancak, tüm mesajları sıralamak için, biz her aday (post) sıralanması için özellikleri toplamak gerekir, böylece posta özellikleri tarafından oluşturulan sistem üzerindeki toplam yük çok daha büyük olan kullanıcı özellikleri tarafından oluşturulan. Bu fark bizim hikayede önemli bir rol oynar. Post bir entite, User bir diğer ve benzeri. Hesaplama bakış açısıyla, onlar oldukça benzer. Ancak, önemli fark, her tür entite için toplamak için ihtiyacımız olan özelliklerin sayısıdır. Bir kullanıcı bir akış isteyince, biz o tek kullanıcı için kullanıcı özellikleri toplamak. Ancak, tüm mesajları sıralamak için, biz her aday (post) sıralanması için özellikleri toplamak gerekir, böylece posta özellikleri tarafından oluşturulan sistem üzerindeki toplam yük çok daha büyük olan kullanıcı özellikleri tarafından oluşturulan. Bu fark bizim hikayede önemli bir rol oynar. Neden İlk Özellik Mağazası Mimarisi Ölçülemedi Başlangıçta, temel odak, gerçek zamanlı bir kullanıcı özellik mağazası oluşturmaktı, çünkü o noktada kullanıcı özellikleri en önemli olanıydı. Ekip bu amaçla özellik mağazasını inşa etmeye başladı. Ama sonra öncelikler değişti ve posta özellikleri de odaklandı. Bu değişiklik, ekibin öncekinden iki ana farkı olan tamamen yeni bir sıralama sistemi oluşturmaya başladığı için gerçekleşti: Yakın gerçek zamanlı posta özellikleri daha önemli Sıralaması gereken yerlerin sayısı yüzlerden binlere yükseldi Ivan, “Bu yeni sistemi test etmeye gittiğimizde acımasız bir şekilde başarısız oldu. saniyede yaklaşık 1 milyon özellikle, sistem yanıt vermedi, gecikmeler çatıdan geçti ve böylece.” Sonuçta, sorun, sistem mimarisinin tahtalar olarak adlandırılan önceden toplanan veritabanlarını nasıl kullandığından kaynaklanıyordu. Örneğin, belirli bir dakikada veya başka bir zaman aralığında bir yazı için beğenilerin sayısını toplayabilirler. İşte sistem mimarisine yüksek düzeyde bir bakış. Temel verilerle birkaç gerçek zamanlı konu (kısaca beğeniler, tıklamalar, vb.) Bir Flink işi bunları yapraklara birleştirir ve onları ScyllaDB'ye yazar. Başlangıçta, her varlık kendi bölümüne sahipti, satır zamanlaması ve özellik adı gruplandırma sütunları düzenleniyordu. [ Bir saat, bir gün, yedi gün veya 30 gün aramak, ortalama bir özelliğe göre yaklaşık 70 yaprak toplamak zorunda kaldı. Bu NoSQL veri modelleme masterclass'da daha fazla bilgi edinin Matematiği yaparsanız, neden başarısız olduğunu anlarsınız.Sistem saniyede yaklaşık 22 milyar satır işlemek zorunda kaldı.Ancak veritabanı kapasitesi saniyede sadece 10 milyon satırdı. Erken Özellik Mağazası Optimizasyonları: Veri Modellemesi ve Şekillendirme Değişiklikleri Bu noktada ekibi bir optimizasyon misyonu yürüttü. Başlangıç veritabanı şeması, tüm özellik satırlarını birlikte depolamak için güncellenmiş ve belirli bir zaman çizelgesi için protokol tamponları olarak serialize edilmiştir. Arşiv zaten Apache Flink'i kullanıyordu çünkü yeni şemaya geçiş Flink'in veri borularını inşa etme gelişmiş yetenekleri sayesinde oldukça kolaydı. Bu optimizasyonla, yukarıdaki eşitlikten “Funksiyonlar” çoğaltıcı kaldırıldı ve alınması gereken satır sayısı 100X azaldı: yaklaşık 2 milyardan 200 milyon satır/s'ye. Ekip ayrıca, beş dakikalık, üç saatlik ve beş günlük ekstra kalıpları bir dakikalık, 30 dakikalık ve bir günlük kalıplara ekleyerek kalıp yapılandırmasını optimize etti. Veritabanı tarafında daha fazla satır / saniye işlemek için, ScyllaDB sıkıştırma stratejisini artışlı olarak düzeyde değiştirdiler. [ ]. Bu seçenek, ilgili satırları bir arada tutarak ve okuma I/O'yu azaltarak sorgu desenlerine daha iyi uyum sağladı. Kompresyon stratejileri hakkında daha fazla bilgi edinin Geriye kalan yükü karşılamak için en kolay yol, ScyllaDB'yi 4 katına çıkarmak olacaktır. Bununla birlikte, daha fazla / daha büyük kümeler maliyetleri artıracak ve bu sadece bütçelerinde değildi. Veritabanı yükünü azaltmak için Store Cache Lokasyonunu geliştirin ScyllaDB'de yükü azaltmanın potansiyel bir yolu, yerel cache hit oranını iyileştirmekti, bu yüzden ekibi bunun nasıl gerçekleştirilebileceğini araştırmaya karar verdi. Açıkçası seçenek, bir talebin istemci tarafından belirli bir kopyaya yönlendirilmesi için bilinen bir tekniği olan tutarlı bir hashing yaklaşımı kullanmaktı. Ekibin Kubernetes kurulumlarında NGINX Ingress'i kullandığından, NGINX'in tutarlı hashing yeteneklerini kullanmak doğal bir seçim gibi görünüyordu. NGINX Ingress belgelerine göre, tutarlı hashing'i kurmak üç satır kodu eklemek kadar basit olurdu. Neler yanlış olabilir? Bu basit yapılandırma işe yaramadı. Müşteri alt kümesi büyük bir anahtar yeniden yapılandırmasına yol açtı - en kötü durumda %100'e yükseldi. düğüm anahtarları bir hash yüzükte değiştirilebildiğinden, otomatik ölçeklendirme ile gerçek yaşam senaryolarını kullanmak imkansızdı. Bir talep için bir hash değerini sağlamak zordu, çünkü Ingress en belirgin çözümü desteklemiyordu: bir gRPC başlığı. Geçerlilik şiddetli bir bozulma yaşadı ve kıç geçişinin neden olduğu belli değildi. Pod'ların bir alt kümesini desteklemek için, ekibi yaklaşımlarını değiştirdiler. İki adımlı bir hash fonksiyonu oluşturdular: önce bir entiteyi hash ettikten sonra rastgele bir önbilgi ekledik. Bu, entiteyi istenen sayıdaki pods üzerinde dağıttı. Teorik olarak, bu yaklaşım, bir entite aynı pod'a birkaç kez haritalandığında çarpışmaya neden olabilir. Bununla birlikte, büyük sayıda replika nedeniyle risk düşüktür. Ingress, gRPC başlığı bir değişken olarak kullanmayı desteklemiyor, ancak ekibi bir çözüm buldu: yol yeniden yazma kullanmak ve yolun kendisinde gerekli hash anahtarı sağlamak. Ne yazık ki, gecikme bozukluğunun nedenini belirlemek önemli bir zaman ve gözlemlenebilirlik iyileştirmeleri gerektirirdi. Sınırı karşılamak için ekip, Feature hizmeti 27 farklı hizmete bölünmüş ve tüm varlıkları müşteri üzerinde el ile bölünmüştür. En zarif yaklaşım değildi, ancak, basit ve pratikti – ve harika sonuçlar elde etti. Cache hit oranı% 95'e yükseldi ve ScyllaDB yükü saniyede 18.4 milyon satırya düşürüldü. Bu tasarımı kullanarak, ShareChat, özellik mağazasını Mart ayına kadar saniyede 1B özelliklere genişletti. Bununla birlikte, bu “eski okul” dağıtım bölünme yaklaşımı hala ideal tasarımı değildi. 27 dağıtımı korumak sıkıcı ve verimsizdi. Artı, bellek hit oranı istikrarlı değildi ve ölçüm her dağıtımda yüksek minimum pod sayısını korumak zorunda kalarak sınırlıydı. Optimizasyonun Sonraki Fazı: Düzenli Hashing, Özellik Hizmetleri Başka bir optimizasyon turuna hazırlanarak, ekibi, özellik servisiyle birlikte dağıtılan Envoy Proxy olarak adlandırılan bir sidecar kullanarak tutarlı hashing yaklaşımını tekrar inceledi. Envoy Proxy, gecikme sırası sorunu tanımlamaya yardımcı olan daha iyi gözlemlenebilirliği sağladı. Sorun: Özellik hizmetine farklı isteklilik desenleri gRPC tabakası ve cache üzerinde büyük bir yük oluşturdu. Ekip daha sonra Özellik hizmetini optimize etti. Cache kütüphanesi (VictoriaMetrics'ten FastCache) ve 100x mutex tartışmasını azaltmak için batch yazarları ve daha iyi dışlamayı uyguladı. Yüksek paralellik sırasında tartışmalar önlemek için farklı bağlantılarda forked gprc-go ve uygulanan tampon havuzu. Kullanılan nesne toplama ve ayarlanmış çöp toplama (GC) parametreleri dağıtım oranlarını ve GC döngüleri azaltmak için. Envoy Proxy, kavramı kanıtlamak için trafiğin% 15'ini ele aldığında, sonuçlar umut vericiydi: ScyllaDB'deki yükü 7.4M satır / s'ye düşüren% 98 cache hit oranı. Yüksek Performanslı Bir Özellik Mağazasından Öğrenilen Dersler İşte bu yolculuk zaman çizelgesinden bakıldığında nasıl görünüyordu: Son olarak, Andrei, ekibin bu projede öğrendiği en önemli dersleri özetledi (Şimdiye kadar): ShareChat ekibi sistem tasarımındaki değişikliklere rağmen, ScyllaDB, Apache Flink ve VictoriaMetrics iyi çalışmaya devam etti. Her optimizasyon öncekinden daha zor ve daha az etkiye sahiptir. Basit ve pratik çözümler (örneğin, özellik mağazasını 27 dağıtmaya bölmek gibi) gerçekten işe yarıyor. En iyi performans sağlayan çözüm her zaman kullanıcı dostu değildir. Örneğin, revize edilmiş veritabanı şemaları iyi performans sağlar, ancak sürdürülmesi ve anlaşılması zordur. Bazen varsayılan bir kütüphaneyi döşemek ve en iyi performans elde etmek için belirli sisteminiz için ayarlamak gerekebilir.
