Bu yazı Colin Weld ve Connor Adams tarafından yazılmıştır. Buradan veya blogumuzdan okuyabilirsiniz.
Modal'da, diğer şeylerin yanı sıra, sandbox'lar (korunaklı çalışma alanları) oluşturuyoruz. Ajanlar sandbox'larda çalışır ve ajanlar yazılımı tüketiyor. Bugün Modal, günde milyonlarca sandbox çalıştırıyor, müşteri başına elli bine kadar eşzamanlı sandbox'ı destekliyor ve pekiştirmeli öğrenme'den arka plan ajanlarına kadar çeşitli kullanım senaryolarını ölçekte destekliyor.
Kullanıcılarımız giderek daha fazla sayıda sandbox'a, daha yüksek hızlarda ihtiyaç duyuyor. Pekiştirmeli öğrenme, milyonlarca sandbox'ın eşzamanlı olarak çalıştırılmasını gerektirebilir ve dağıtımların başlangıcında yüz binlerce sandbox'lık ani artışlar oluşturmayı gerektirebilir. Benzer şekilde, ajanlar da trafik artışlarıyla başa çıkmak için giderek daha fazla büyük ölçek ve yüksek eşzamanlı oluşturma oranları gerektiriyor.
Mevcut sandbox platformumuz gerçekten iyi, ancak bu ölçekler için tasarlanmamıştı; mevcut diğer çözümler de öyle. Ölçek ve performansa takıntılıyız ve altyapımızın ajanların büyümesini hızlandırmasını, sürtüşme eklememesini istiyoruz. Bu yüzden masanın başına döndük.
Son birkaç aydır, temel sandbox platformumuzu hem ölçek hem de güvenilirlik için sıfırdan yeniden inşa ettik. Yeni sistemimizde, kullanıcılar milyonlarca sandbox'ı eşzamanlı olarak çalıştırabilir ve saniyede on binlerce sandbox oluşturabilir. Kontrol düzlemimizdeki tüm merkezi darboğazları kaldırdık, böylece pratik bir ölçekleme sınırı kalmadı ve konteyner zamanlaması ve başlatmasının her parçasını optimize ettik, zamanlama yolunu, işçi filomuzda doğrudan konteynerler oluşturan bir yük dengeleyici katmanına indirgedik.
Platformumuzun neler yapabileceğinin bir göstergesi olarak, bir dakikanın altında 1 milyon sandbox'ı aynı anda oluşturarak eşzamanlı olarak çalıştırdık.
Birçok sandbox'ı çalıştırabildiğimize dair kanıt.
Çoğu çözüm neden ölçeklenemez
1 milyon sandbox'ı çalıştırmak, herhangi bir konteyner platformunun sınırlarını zorlar, yalnızca konteyner sayısı nedeniyle değil, aynı zamanda bu kadar çok sandbox'ı çalıştırmak on binlerce bilgi işlem düğümü gerektirdiğinden. Ya O(konteyner), O(düğüm) ya da her ikisi olan birçok işlem olacaktır ve bu da geleneksel konteyner platformlarının ölçekleme sınırlarına ulaşmasına neden olacaktır.
Örnek olarak Kubernetes için:
- zamanlama algoritması en kötü durumda n düğüm ve p pod için O(n x p)'dir ve zamanlama varsayılan olarak serileştirilir.
- her pod, ömrü boyunca etcd'ye (merkezi Kubernetes kalıcı deposu) birden çok yazma işlemi yapar; bu, yüksek pod oluşturma oranları veya yüksek pod değişimi altında ciddi sorunlar yaratabilir ve etcd, bir anahtar alanı içinde yerel olarak parçalanabilir değildir.
- her düğüm, canlılık sinyali vermek için en az bir kalp atışı aralığında bir kez etcd'ye yazmalıdır, bu nedenle temel etcd yazma yükü, pod oluşturmadan tamamen bağımsız olarak O(düğüm)'dir.
Kubernetes zamanlama akışının yaklaşık bir tahmini. Yeni pod'lar, API sunucusu tarafından etcd'ye (güçlü tutarlı kalıcı bir depo) yazılır. Kubernetes zamanlayıcısı, yeni atanmamış pod'ları izler ve API sunucusuna bir çağrı yoluyla bunları düğümlere atar ve bu da tekrar etcd'ye yazar; bu yazma işlemi gerçekleştikten sonra, bir düğüm pod'u başlatabilir.
Kubernetes ölçeklenebilir, ancak ciddi bir çalışma gerektirir. Çok sayıda düğüm çalıştırmak için etcd'nin genellikle yeniden yazılması veya değiştirilmesi gerekir. Yüksek zamanlama verimini desteklemek, pod durumu için tek bir doğruluk kaynağını korurken zamanlama algoritmasını paralelleştirmek için karmaşık bir scatter-gather sistemi oluşturmayı gerektirir. Parçalama ve paralelleştirme varsayılan olarak kolay değildir, çünkü Kubernetes tasarımının temel taşı olarak güçlü tutarlılığa güvenir.
Modal'ın orijinal sandbox mimarisinin de benzer sorunları vardı. Kubernetes gibi, biz de arka ucumuz boyunca güçlü tutarlılığa güveniyoruz, bu nedenle sandbox'ları oluşturmak ve zamanlamak küresel koordinasyon ve kolayca parçalayamayacağımız Postgres'e O(sandbox) yazma işlemi gerektiriyor.
Modal'ın orijinal sandbox kontrol düzlemi mimarisi. Sandbox'lar oluşturulduğunda, bir kuyruğa yerleştirilir ve Postgres'e yazılır. Zamanlama iyimserdir ve paralel olarak çalıştırılır ve çakışmaları önlemek için merkezi koordinasyon gerekir. Bir sandbox'ı bir işçiye (bilgi işlem düğümü) atamak, Postgres'e ek bir yazma işlemi gerektirir.
Kubernetes üzerine inşa etmediğimiz için, bu sistemin birçok parçasını ölçeklendirebildik. Örneğin, zamanlama varsayılan olarak paralelleştirilir, bu da çok yüksek ani sandbox oluşturma oranları elde etmemizi sağlar. Ancak daha büyük sayıda düğüme ve sandbox'a ölçeklendikçe, ya O(sandbox) ya da O(düğüm) olan ancak ölçeklendirilmesi kolay olmayan işlemlerden kaynaklanan yeni darboğazlarla sürekli karşılaştık.
Örneğin, tamamlanan her sandbox için dayanıklı bir iş akışı çalıştırıyoruz, bu nedenle yüksek sandbox değişim oranları büyük olay birikmeleri yaratıyordu. Sistemimiz genelinde beklenmedik yük sorunlarına neden olan O(sandbox) oranında çağrılan RPC'lerle tekrar tekrar karşılaşıyorduk. Ve çok sayıda sandbox'ı çalıştırmak için gereken çok sayıda düğüm, düğüm yönetimi ve otomatik ölçeklemede birden çok alt akış sorununa neden oluyordu. Son olarak, etrafından dolaşabilsek de, tüm sandbox oluşturma ve zamanlamanın kritik yolunda parçalanmamış bir Postgres örneği bırakmanın kötü bir fikir olduğu kanıtlanmıştı.
Sonsuz ölçeğin kilidini açmak
İstediğimiz ölçeğe ulaşmanın mimarimizi sıfırdan yeniden düşünmeyi gerektirdiğini çabucak fark ettik. Milyonlarca sandbox'ı çalıştırmak ve saniyede on binlerce sandbox oluşturmak istiyoruz; bu, mevcut her şeyden çok daha iyi ölçekleme özellikleri gerektiriyor. Sahip olduğumuzu geliştirmeye çalışmak yerine, en hızlı ve en temiz yolun sıfırdan başlamak olduğuna inandık.
Ölçeği optimize etmek için, O(sandbox) veya O(düğüm) yükü alan her şeyin varsayılan olarak yatay olarak ölçeklenebilir olmasına, sandbox oluşturma yolunun olabildiğince basit olmasına ve diğer her şeyin ikincil olmasına karar verdik. Ulaştığımız çözüm, mevcut sistemlerden belirgin şekilde farklıdır. Her türlü merkezi koordinasyondan tamamen vazgeçtik ve sandbox'ları çalıştırma ve oluşturma için kritik yolun her yerinde küresel tutarlılığı ölçeklenebilirlik ve performansla takas ettik. İşte nasıl çalışıyor:
- Tek bir serileştirilmiş zamanlayıcı yerine, sandbox oluşturma isteklerini eşzamanlı olarak işleyen bir zamanlama sunucuları filosu çalıştırıyoruz. Bir zamanlama sunucusu, bir oluşturma isteğini işlemek için bellekte önbelleğe alınmış verilere karşı hızlı bir zamanlama algoritması çalıştırır. Sonuç olarak, zamanlama yatay olarak ölçeklenir ve geleneksel konteyner zamanlamasından çok yük dengelemeye benzer.
- Sandbox ve işçi durumu için doğruluk kaynağı olarak hareket eden merkezi, dayanıklı bir veri deposu (çoğu konteyner platformunun çalışma şekli) yerine, yeni sistemimizdeki her işçi kendi doğruluk kaynağıdır. İşçiler durumlarını periyodik olarak bir Redis akışına yayınlar. Zamanlama sunucuları bu durumu eşzamansız olarak tüketir ve zamanlama kararları vermek için kullanır. Bir zamanlama sunucusu, bir sandbox'ı hangi işçide oluşturacağına karar verdikten sonra, bir sandbox oluşturulmasını talep etmek için doğrudan RPC aracılığıyla işçiyle iletişime geçer. İşçiler, boş kaynakları varsa zamanlama isteğini kabul eder, aksi takdirde reddeder.
- Sandbox oluşturmanın kritik yolunda hiçbir veri deposumuz yoktur, bu da ölçeklenebilirliği ve güvenilirliği artırır. Sandbox meta verilerini ve sonuçlarını dayanıklı depolamaya yazmamız gerekse de, bunu büyük ölçüde eşzamansız olarak yaparız.
- Sandbox oluşturmalar dışında, O(sandbox) olan hiçbir RPC'miz yoktur. İşçiler, veri odaklı tasarım fikirleri doğrultusunda, birden çok sandbox için kontrol mesajlarını tek RPC'lerde toplar.
Nihai tasarımımız, ilk kez beyaz tahtaya çizdiğimiz hali.
Modal'ın v2 sandbox mimarisinde sandbox oluşturma yolu. Sandbox oluşturma istekleri, yatay olarak ölçeklenmiş zamanlama sunucuları tarafından işlenir; bunlar daha sonra hızlı bir bellek içi yük dengeleme algoritmasıyla bir işçi seçer ve bir sandbox oluşturmak için doğrudan işçiyle (bilgi işlem düğümü) iletişime geçer. Sandbox nesneleri Redis'te saklanır, ancak kritik yolda değildir.
Sonuç olarak, sandbox oluşturma yolu yalnızca iki ağ atlaması ve bir ucuz CPU işlemi gerektirir. Merkezi darboğazlar veya koordinasyon maliyetleri, tek başarısızlık noktaları ve dolayısıyla toplam sandbox ölçeği veya sandbox oluşturma verimi için pratik bir tavan yoktur. Gerektiğinde daha fazla zamanlayıcı veya işçi ekleyebiliriz. En yakın darboğaz, tüm işçilerin durumu tek bir Redis akışına yayınlamasıdır, ancak yük testleri, bunun 100.000 işçinin çok ötesine kadar uygulanabilir olduğunu göstermiştir; ve yine de akıştaki sıralamaya bağlı değiliz, bu nedenle daha fazla akış eklemek kolay olacaktır. Tasarım gereği, mevcut çözümlerin ölçeklenmesini engelleyen sorunlardan kaçınıyoruz.
Bu çözümü oluşturmak kolay olmadı! Tüm geliştirme süreci, arka ucumuzdaki çoğu büyük sistemi kapsayan aylarca süren bir çalışma gerektirdi. Beyaz tahtalarda saatler geçirdik. Dört kişi, dikkat dağıtıcı unsurlardan uzak, istediğimiz yeni sistemin bir prototipini oluşturmak için Miami Beach'te bir kiralık eve çekildik. Fiziksel olarak yapamayana kadar sekiz gün kod yazdık, dinlenmek için hızlı satranç oynadık, okyanusa atladık ve sonra doğrudan koda geri dönerek yeni sistemimizi temiz ve işlevsel hale getirmek için savaştık.
En iyi mühendisimiz Miami Beach'te dinleniyor.
Temel parçaları çalışır hale getirdikten (ve New York'a döndükten) sonra, her bir Sandbox özelliğini ve tüm Sandbox gözlemlenebilirliğini yeni sistemimizin üzerinde yeniden uygulamamız gerekiyordu. Bu proje ayrıca temel işçi yönetim yığınımızda ve konteyner çalışma zamanımızda değişiklikler gerektirdi. Örneğin, karşılaştığımız ilginç bir sorun, yeni sandbox zamanlayıcılarımızın konteynerleri işçilere o kadar hızlı itebilmesiydi ki, aynı anda başlayan birçok konteyner, konteyner ağ kurallarını ayarlarken Linux çekirdeğindeki rtnl kilidi için rekabet edecek ve başlaması onlarca saniye sürecekti, bu nedenle sandbox oluşturmalarla dolup taştıklarında işçilerimizin patlamaması için sandbox'lar için konteyner ağ kurulumumuzu değiştirmek zorunda kaldık.
Performansımız nasıl karşılaştırılıyor
Sistemimizi, olabildiğince hızlı bir şekilde 1 milyon sandbox'ı başlatarak test ettik. Üst düzeyde, bir dakikanın altında bir milyon sandbox oluşturabiliyoruz; burada birincil darboğaz testin kendisidir. Bireysel sandbox'ın etkileşime geçme süresi tutarlı bir şekilde düşük kalır ve ölçekte gerçek bir bozulma görmez.
Sandbox oluşturma isteklerinin dağılımı ve eCDF'si. Bir sandbox oluşturma isteği, zamanlama sunucularımız bir sandbox'ı bir işçiye başarıyla atadığında ve başlatmaya başladığında geri döner.
Tasarımımız göz önüne alındığında bunun beklenen bir durum olduğuna inanıyoruz. Zamanlama yolunda koordinasyon yoktur, bu nedenle zamanlama, eşzamanlılık ve ölçekten bağımsız olarak çok hızlı kalmalıdır. Bizim açımızdan, mevcut kapasite dışında eşzamanlı sandbox zamanlaması veya ölçeği için ciddi bir sınırımız yok ve kapasiteyi yönetme zaten iyi yaptığımız bir şeydir.
1M sandbox testimizden rastgele seçilmiş 10 bin sandbox başlangıç zamanının serpilme grafiği.
Yeni sistemimizde sandbox başlangıç süreleri (istemcinin ilk kez bir sandbox oluşturmaya çalıştığı andan, sandbox'ın kullanıcı kodunu çalıştırabildiği ana kadar olan gecikme), medyanda yarım saniyeden azdır ve ölçekte sağlam kalır. Ayrıca, büyük ölçüde zamanlama çok daha hızlı olduğu için eski sistemimizden önemli ölçüde daha hızlıdırlar - artık yalnızca onlarca milisaniye sürmektedir. Gecikmenin uzun kuyruğu, istediğimizden biraz daha uzundur. Bu kuyruğun çoğunu, aynı işçide aynı anda birçok sandbox başladığında çekirdek ve ağ çekişmesine (daha önce bahsedilen rtnl kilidi çekişmesi dahil) bağlıyoruz ve bunu azaltmak için çalışıyoruz. Ayrıca, ölçekte kuyruk gerçektir. Bunun, konteyner başlatma yolunu optimize ettikçe iyileşmesini bekliyoruz.
Genel olarak, bu performans rakamlarından çok memnunuz. Ajanlar dünyayı ele geçirirken, açıkça onlarla birlikte ölçeklenebiliriz.
Kendiniz görün
Yakında bu yeni sistem Modal'daki tüm sandbox zamanlamasının temelini oluşturacak, ancak şimdiden Beta sürümünde mevcut. Kodunuzda basit bir değişiklikle bu sistemi tercih edebilirsiniz. Çok sayıda sandbox çalıştırmanız gerekiyorsa, deneyin ve bizimle konuşun!
Teşekkürler
Bu projeye birçok kişi kan, ter ve gözyaşı döktü. Miami POC'muz Colin Weld (ben), Daniel Shaar, Walter Tang ve Gleb Posobin tarafından oluşturuldu ve ardından Walter, Colin, Connor Adams, Akshay Balwally, Tom Wildenhain, Scott Hao ve Taylor Baldwin tarafından üretime taşındı.
