Kendi barındırma kararı hacimle değil kullanım oranıyla verilir

Tez#

Barındırma kararı genellikle bir eşik sorusu olarak kuruluyor: aylık kaç milyon tokenı geçince kendi altyapımıza geçmeliyiz? Soru makul görünüyor ama yanlış değişkeni sabitliyor. Toplam hacim, maliyeti tek başına belirlemiyor; belirleyen şey o hacmin zaman içinde nasıl dağıldığı.

Nedeni iki modelin farklı şey satmasında. Yönetilen API istek satar: kullandığınız kadar ödersiniz, boşta duran kapasitenin maliyeti sağlayıcıya aittir. Kendi donanımınız ise kapasite satar: hızlandırıcı çalışıp çalışmasın kiralanmıştır, amortismanı işlemektedir, elektriği tüketilmektedir. Bu yüzden karar "ne kadar iş yapıyorum" sorusuna değil, "satın aldığım kapasitenin ne kadarı iş üretiyor" sorusuna bağlı. Günün sekiz saatinde yoğun, kalanında boş çalışan bir sistem, kendi donanımında kapasitesinin üçte ikisini boşa ödüyor.

Bağlam: dört yük profili#

Aşağıdaki tablo dört tipik yük profilini ve her birinde hangi barındırma biçiminin öne geçtiğini gösteriyor. Hacim sütunu bilinçli olarak yok — tez tam olarak hacmin belirleyici olmadığı.

Dördüncü satırın pratik değeri yüksek. Gecelik belge işleme, toplu gömme üretimi, dizin yeniden kurma gibi işler zamanlanabilir; bu işleri kendi donanımınızın boş saatlerine yerleştirmek kullanım oranını yükseltir ve karma mimariyi ekonomik kılar. Yani barındırma kararı yalnızca mevcut yük profilini okumak değil, yükü yeniden şekillendirmeyi de içeriyor.

Kanıt: hesabın doğru kurulması#

Karar aritmetikle verilebilir ama çoğu hesaplama iki kalemi atlıyor: boşta kapasite ve işletme emeği. İkisi eklendiğinde sonuç sık sık tersine dönüyor.

1. 1Saatlik yük profilini çıkarın

   Aylık toplam değil, saat bazında istek dağılımı. Tepe ile ortalama arasındaki oran kararın ana girdisidir.

2. 2Gereken kapasiteyi tepeye göre hesaplayın

   Kendi donanımınız tepeyi karşılamak zorundadır. Ortalamaya göre alınan kapasite tepe anında hizmet vermez.

3. 3Kullanım oranını bulun

   Ortalama yük bölü tepe kapasite. Bu oran düştükçe kendi barındırmanın etkin birim maliyeti yükselir.

4. 4İşletme emeğini ekleyin

   Sürücü güncellemesi, kapasite izleme, arıza müdahalesi, sürüm geçişi. Bu kalem çoğu hesapta hiç görünmüyor.

5. 5İki senaryoyu aynı yük profilinde maliyetlendirin

   Aynı saatlik dağılımı iki modelde ayrı ayrı hesaplayın. Karar bu iki sayıdan çıkar, genel bir eşikten değil.

Dördüncü adım en çok atlanan ve hesabı en çok değiştiren. Kendi barındırma bir altyapı işi ve bu iş bir ekip gerektiriyor: hızlandırıcı sürücüleri, çıkarım sunucusu ayarları, bellek profili, kapasite planlaması, arıza müdahalesi ve model sürüm geçişleri. Bu emeğin maliyeti donanım kirasıyla karşılaştırılabilir düzeyde olabiliyor ve yönetilen API senaryosunda büyük ölçüde yok.

Mekanizma: bellek neden kapasiteyi belirliyor#

Kendi barındırmada kapasite hesabının merkezinde bellek var, hesaplama gücü değil. Model ağırlıkları belleğe sığmak zorundadır; üstüne çalışma anındaki ara durumlar biner ve bu ara durumlar bağlam uzunluğuyla birlikte büyür.

Pratik sonuç şu: aynı donanımda eşzamanlı hizmet verilebilen istek sayısı, bağlam uzunluğuna ters oranlı davranır. Kısa istemlerle çalışan bir sistem aynı kartta çok daha fazla eşzamanlı istek taşır; uzun bağlamlı bir sistem aynı kartta birkaç isteğe düşer. Bu, kapasite planının uygulama tasarımına bağlı olduğu anlamına geliyor — bağlam bütçesini düşürmek, donanım almakla aynı etkiyi yaratabilir ve çok daha ucuzdur. Nicemleme de aynı kaldıraca dokunuyor: bellek kullanımını düşürür ve bellek bant genişliğine bağlı iş yüklerinde hızı da artırabilir; feragat edilen şey bellek değil, bir miktar kalitedir.

Karşı görüş#

İki itiraz güçlü. Birincisi: maliyet tek gerekçe değil. Verinin kurum dışına çıkamadığı durumlarda kendi barındırma bir tercih değil zorunluluk; hesap ne söylerse söylesin karar verilmiştir. İkincisi: sağlayıcı bağımsızlığı bir değer — kendi barındırma, fiyat ve sürüm politikası değişikliklerinden korunma sağlıyor.

Kendi barındırmaya gizlilik gerekçesiyle geçtik, maliyet hesabını hiç yapmadık. İki yıl sonra hesapladık: gizlilik gerekçesi hâlâ geçerliydi ama seçtiğimiz donanım yükümüzün üç katıydı.

Alıntı iki itirazı birleştirip nüansı gösteriyor: gizlilik veya bağımsızlık gerekçesi kendi barındırmayı zorunlu kılsa bile kapasite kararını ortadan kaldırmıyor. "Kendi barındıracağız" kararı ile "ne kadar kapasite alacağız" kararı ayrı kararlar ve ikincisi hâlâ kullanım oranı hesabıyla verilir. Bu yüzden itirazlar tezi çürütmüyor, uygulama alanını daraltıyor: barındırma biçimi kararı gizlilikle verilebilir, kapasite miktarı kararı verilemez.

Sınırlar ve belirsizlik#

Tezin güven derecesi orta ve nedeni şu: piyasa koşulları hesabı hızla değiştiriyor.

• Kiralama modelleri değişiyor: daha esnek, daha kısa süreli hızlandırıcı kiralama yaygınlaşırsa boşta kapasite maliyeti düşer ve tez zayıflar.
• İşletme emeği maliyeti ekibe özgü: mevcut altyapı yetkinliği olan bir ekip için bu kalem küçük, olmayan için belirleyici.
• Açık ağırlıklı model kalitesi değişken: kendi barındırma yalnızca açık ağırlıklı modellerle mümkün ve o modellerin yeterliliği iş yüküne bağlı.
• Kesin eşik verilemez: tez bir hesap yöntemi öneriyor, bir eşik önermiyor; eşik her ekipte farklı çıkar.

Sonuç#

Barındırma kararı bir eşik tablosundan okunamaz. Aynı aylık hacme sahip iki ekip, yük profilleri farklıysa zıt kararlar vermeli. Doğru soru "kaç tokenı geçince" değil, "satın alacağım kapasitenin ne kadarı iş üretecek".

Kararı hazırlayan pratik adım, yük profilini yeniden şekillendirmeyi de masaya koymak. Zamanlanabilir işleri boş saatlere taşımak, bağlam bütçesini düşürerek eşzamanlı kapasiteyi artırmak ve tepe yükü API'ye taşıyan karma bir mimari kurmak — üçü de kullanım oranını yükseltiyor. Bu üç kaldıraç denenmeden verilen barındırma kararı, yükü verili kabul eden bir karardır ve yük genellikle verili değildir.

Ne yapmalı?#

1. 1Saatlik yük profilini çıkarın

   Aylık toplam karar için yetersiz. Tepe bölü ortalama oranı, hesabın ana girdisi.

2. 2Kullanım oranını hesaplayın

   Ortalama yük bölü tepe kapasite. Bu oran düşükse kendi barındırma pahalıdır, hacim ne olursa olsun.

3. 3İşletme emeğini kaleme ekleyin

   Sürücü, ayar, izleme, arıza ve sürüm geçişi. Hesaba girmeyen emek, sonradan faturaya girer.

4. 4Karma mimariyi ayrı senaryo olarak hesaplayın

   Taban yük kendi donanımda, tepe API'de. Orta kullanım oranlı profillerde genellikle kazanan bu.

5. 5Yükü yeniden şekillendirmeyi deneyin

   Zamanlanabilir işleri boş saatlere taşıyın; bağlam bütçesini düşürerek eşzamanlı kapasiteyi artırın.

6. 6Kapasite kararını gizlilik kararından ayırın

   Gizlilik barındırma biçimini belirleyebilir; kapasite miktarını hâlâ kullanım oranı belirler.