Boşta duran GPU'lar için ödeme yapmayın. Hesaplama kaynaklarını tam zamanında sağlayın, iş yükünü işleyin ve ardından kaldırın — sermaye harcamasını iş başına bir işletme maliyetine dönüştürün.

İş yükünüz ani artışlar gösteriyorsa — içerik yüklendiğinde ani yükselen video kodlama işleri, 4 saat boyunca 8 GPU'ya ihtiyaç duyup sonra duran ML eğitim çalıştırmaları, iş olaylarıyla tetiklenen toplu çıkarım işleri veya gece boyunca çalışan render işlem hatları. Ya fazla kaynak sağlıyorsunuzdur (zamanın %80'inde boşta duran kaynaklar için ödeme yapıyorsunuzdur) ya da yetersiz kaynak sağlıyorsunuzdur (yoğun zamanlarda işler saatlerce kuyrukta bekler). Tam olarak ihtiyacınız olan hesaplama gücünü, ihtiyacınız olduğunda sağlayan ve iş tamamlandığında serbest bırakan bir mimariye ihtiyacınız var — "sıfıra ölçeklemeyi" GPU iş yükleri için pratik olmaktan çıkaran soğuk başlangıç cezası yaşamadan.
Explore more design patterns and system architectures
Mimarlarımız, bu deseni kullanarak belirli gereksinimleriniz için sistemler tasarlamanıza ve oluşturmanıza yardımcı olabilir.
İletişime GeçinAçma/kapama ölçekleme mimarisi, sıcak/soğuk havuzlama, iş kuyruğu odaklı kaynak sağlama ve otomatik kaldırma yoluyla hesaplama kaynaklarını yönetir. Bir sıcak havuz, anında kullanıma hazır, önceden başlatılmış az sayıda örnek tutar. Bir soğuk havuz, talep sıcak havuzu aştığında spot/öncelikli örneklerden ek kapasite sağlar. Bir iş düzenleyici, işi uygun örneklere yönlendirir, ilerlemeyi izler, spot kesintilerinde yeniden denemeleri yönetir ve kuyruk boşaldığında ölçeklendirmeyi aşağı yönlü tetikler. Bu desen, soğuk başlangıcın (kapsayıcı çekme + model yükleme) 3-10 dakika sürebildiği GPU iş yükleri için özellikle kritiktir.
Sistem, gelen iş isteklerini arabelleğe alan bir iş kuyruğu (SQS, Redis veya özel) üzerine kuruludur. Bir ölçeklendirme denetleyicisi, kuyruk derinliğini izler ve önce sıcak havuzdan, ardından soğuk havuzdan (spot örnekler) örnekler sağlar. Her bir çalışan örnek, kuyruktan işleri çeker, iş yükünü (kodlama, eğitim, inference) yürütür, tamamlandığını bildirir ve havuza geri döner veya sonlandırılır. Bir kontrol noktası yöneticisi, ara durumu S3'e kaydederek spot kesintilerini yönetir ve işlerin farklı bir örnekte baştan başlamadan devam etmesini sağlar.
| Katman | Teknolojiler |
|---|---|
| Hesaplama | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orkestrasyon | Kubernetes (otomatik ölçeklendirme için Karpenter), AWS Batch, özel iş düzenleyici |
| İş Kuyruğu | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Depolama | S3 (kontrol noktaları, model artefaktları), NVMe (model önbelleği), EFS (paylaşımlı çalışma alanı) |
| İzleme | CloudWatch/Prometheus (kuyruk derinliği, örnek kullanımı, iş gecikmesi), özel maliyet panoları |
| Ne Zaman Kullanmalı | Ne Zaman Kaçınmalı |
|---|---|
| İş yükü ani artışlar gösteriyorsa — yoğun talep ortalama talebin 5 katı veya daha fazlasıysa | Trafik sabit ve tahmin edilebilir ise — doğru boyutlandırılmış ayrılmış örnekler daha ucuzdur |
| Boşta dururken maliyetli olan GPU/yüksek hesaplama işleri için | İş yükü sunucusuz (Lambda) platformlara uygun hafif bir CPU işleme ise |
| İşler, soğuk havuz sağlaması için 1-5 dakikalık soğuk başlangıca tahammül edebiliyorsa | Saniye altı iş başlatma gecikmesi gerekiyorsa — sürekli açık altyapıya ihtiyacınız var demektir |
| Maliyet optimizasyonu birincil endişe ise ve spot fiyatlandırma %60-90 tasarruf sağlıyorsa | Spot kesintisi, kontrol noktası oluşturmanın engelleyemeyeceği veri kaybına neden oluyorsa |
MW, açma/kapama ölçeklendirmeyi "iş başına maliyet" merceğinden tasarlar — farklı ölçekleme stratejileri arasında bir iş biriminin (bir video, bir eğitim çalıştırması, bir toplu çıkarım) toplam işleme maliyetini modeller ve gerekli gecikme SLA'sında maliyeti en aza indiren stratejiyi seçeriz. Uygulamalarımız, iş başına maliyeti, altyapı kullanımını ve spot tasarruflarını gösteren gerçek zamanlı maliyet panolarını içerir. Ayrılmış örneklere kıyasla video işleme maliyetlerini %70 oranında azaltan açma/kapama GPU altyapısı ve 4 saatlik bir eğitim çalıştırması için 64 GPU sağlayan ve bunları otomatik olarak serbest bırakan ML eğitim kümeleri inşa ettik.
Güvenlik, lansmandan sonra eklediğiniz bir özellik değildir. O, mimari bir özelliktir — sistem ya bunun için tasarlanmıştır ya da tasarlanmamıştır.
batch ağırlıklı veya periyodik iş yüklerine sahip MicrocosmWorks müşterileri, on-off scaling uygulandıktan sonra genellikle %60-80 oranında bulut maliyeti azalması görürler, çünkü işlem kaynakları 7/24 çalışmak yerine yalnızca aktif işlem pencereleri sırasında çalışır. Gerçek kullanım telemetrisine dayalı scaling politikaları tasarlarız—örneğin, günde 4 saat çalışan bir veri işleme hattı, tam 24 saat yerine sadece bu 4 saatin ücretini öder. Mimarlarımız, herhangi bir uygulama başlamadan önce kesin tasarrufları tahmin etmek için bir keşif aşamasında iş yükü desenlerinizi analiz eder.
Önceden ısıtılmış node havuzlarındaki kapsayıcılı uygulamalar için cold-start süreleri 2-3 saniyeden, özel GPU instances veya büyük model loading gerektiren iş yükleri için 5-10 dakikaya kadar değişmektedir ve MicrocosmWorks bu gecikmeyi minimize etmek için çeşitli teknikler kullanır. Geçmiş trafik modellerini ve planlanmış olayları kullanarak beklenen talepten önce kaynakları devreye sokan predictive scaling uyguluyoruz ve gecikmeye duyarlı iş yükleri için container image pre-pulling ve warm pool reservations kullanıyoruz. Hiçbir cold start'a tolerans gösteremeyen uygulamalar için, talep geldiğinde agresif bir şekilde ölçeklenen minimum bir warm baseline sürdürüyoruz.
MicrocosmWorks, queue depth, CPU utilization veya özel uygulama metrikleri tarafından tetiklenen agresif scale-up politikalarını, thrashing'i önlemek için cooldown periods içeren daha kademeli scale-down politikalarıyla birleştirerek reaktif auto-scaling'i uygular. Scale-up olayları sırasında over-provisioning buffers yapılandırıyoruz, böylece sistem talebi tek tek instance'lar halinde karşılamak yerine sürekli büyümeyi öngörür. flash sales veya viral events gibi gerçekten öngörülemeyen yoğunluklar için, pazarlama veya operasyon takviminizden gelen event-driven triggers kullanarak kapasiteyi pre-provision ederiz.
MicrocosmWorks, boşta kalma sürelerinde compute'u sıfıra ölçeklendirirken storage'ı kalıcı ve anında erişilebilir tutan Aurora Serverless, Neon veya PlanetScale gibi serverless database tekliflerini kullanarak veritabanlarına on-off scaling uygular. Serverless database'leri kullanamayan stateful iş yükleri için, query load'a göre replica ekleyip çıkarırken minimal bir primary instance'ı her zaman çalışır durumda tutan read-replica scaling uyguluyoruz. Bu hibrit yaklaşım, shutdown ve yeniden başlatma döngüleri sırasında veritabanı durumunu yönetme karmaşası olmaksızın, data tier'ları için ölçeklendirmenin maliyet avantajlarını müşterilere sunar.
MicrocosmWorks, örnek (instance) sayılarını, ölçeklendirme olayı gecikmesini, başarısız ölçeklendirme girişimlerini ve istenen ile gerçek kapasite arasındaki farkı Grafana veya Datadog panolarını kullanarak gerçek zamanlı olarak izleyen kapsamlı ölçeklendirme gözlemlenebilirliği (observability) dağıtır. Ölçeklendirme hataları, ölçeklendirme tavanının çok düşük olduğunu gösteren sürekli yüksek kaynak kullanımı ve kontrolsüz ölçeklendirmeyi gösteren maliyet anormallikleri için çok kanallı uyarılar yapılandırırız. Runbook'larımız, bulut sağlayıcı örnek (instance) limitlerine ulaşma veya belirli erişilebilirlik bölgelerinde (availability zones) yetersiz kapasite hatalarıyla karşılaşma gibi yaygın hata modları için otomatik iyileştirme içerir.