Vercel Sandbox failover desteğiyle 4 bölgeden 20 compute bölgesinin tamamına genişliyor

Genişleme

Vercel blog'unda yapılan duyuruya göre Vercel Sandbox artık daha önce dört olan Vercel'in 20 compute bölgesinin tamamında çalışabiliyor. En somut etkisi gecikme sürelerinde: sandbox'lar artık birkaç sabit konumda çalışmak zorunda değil ve bunun yerine eriştikleri veritabanları, depolama ve diğer hizmetlerle aynı bölgede konumlanabiliyorlar. Böylece bir sandbox ile bağımlılıkları arasındaki istekler kıtalar arası geçmek yerine bölge içinde kalıyor.

Vercel bu değişikliği aynı zamanda bir kontrol meselesi olarak da sunuyor. Daha geniş kapsam, ekiplerin iş yüklerinin nerede çalışacağına karar vermesini sağlıyor; şirket bunun sandbox kullanımını veri yerleşimi ve bölgesel işleme gereksinimleriyle uyumlu hale getirmeye yardımcı olduğunu söylüyor.

Bölge varsayılanları ve failover

iad1 bölgesi varsayılan olarak kalıyor ve bölge seçimi her planda kullanılabiliyor. Pro ve Enterprise ekipleri ek bir seçenek daha elde ediyor: yapılandırılabilir failover bölgeleri. Vercel bir sandbox'ı birincil bölgede oluşturamazsa, yapılandırılan failover bölgelerini sırayla, biri başarılı olana kadar deniyor.

Katı uyumluluk yaklaşımlarına sahip ekipler için hem birincil hem de failover bölgeleri onaylı coğrafyalarla sınırlanabiliyor. Bu, ince bir boşluğu kapatıyor — failover'ın nereye düşebileceğine dair kısıtlama olmadığında, otomatik bir yedekleme işlemi ilke olarak yürütmeyi ekibin onaylamadığı bir yargı alanına taşıyabilirdi.

Nasıl yapılandırılır

Changelog üç yapılandırma yüzeyini açıklıyor:

• Proje varsayılanları: yeni sandbox'lar için varsayılan bir bölge, proje panelinde Settings > Sandboxes altından ayarlanabiliyor.
• SDK: Sandbox.create() fonksiyonuna bir region ve bir failoverRegions dizisi geçiriliyor. Vercel'in örneği, Sydney (syd1) içinde bir sandbox hazırlıyor ve Hong Kong (hkg1) ile Singapur (sin1) failover olarak belirtiliyor.
• CLI: sandbox create --name my-sandbox --region syd1 --failover-regions hkg1,sin1 komutu aynı sonucu komut satırından üretiyor.

Oluşturma sırasında geçirilen bir bölge, proje varsayılanının yerine geçiyor. Mevcut sandbox'lar taşınmıyor; oluşturuldukları bölgelerde çalışmaya devam ediyorlar.

Fiyatlandırma ve uyumluluk

Yayının yanı sıra iki operasyonel detay var. Fiyatlandırma bölgeye bağlı: Vercel, Active CPU ve Provisioned Memory ücretlerinin bölgeye göre değiştiğini belirtiyor; bu yüzden iş yüklerini yeni bir konuma taşıyan ekiplerin iad1 ücretlerinin geçerli olduğunu varsaymak yerine Sandbox fiyatlandırmasını kontrol etmeleri gerekiyor. Araçlarda ise bir sürüm gereksinimi var — SDK ve CLI, yeni desteklenen bölgelerden birinin seçilebilmesi için en son sürümlerine güncellenmeli.

Neden önemli

Sandbox'lanmış compute, ancak sandbox ile dokunduğu sistemler arasındaki mesafe kadar hızlıdır. Bir veritabanına veya API'ye çok sayıda küçük çağrı yapan bir iş yükü her çağrıda bir ağ gidiş-dönüşü ödüyor ve bölgeler arası gecikme, sık iletişim kuran görevlerin çalışma süresine hâkim olabilir. Sandbox'ın bağımlılıklarının yanında çalışmasına izin vermek, içinde çalışan koddaki hiçbir değişiklik olmadan bu cezayı ortadan kaldırıyor.

Yerleşim boyutu belki daha da önemli olabilir. Daha fazla geliştirme ve test işi yönetilen bulut ortamlarında gerçekleştiği için, bu işlemenin nerede çalıştığı sorusu yalnızca bir performans sorunu olmaktan çıkıp bir uyumluluk sorusu haline geliyor. Hem birincil hem de failover bölgelerini onaylı coğrafyalara sabitleyebilme yeteneği, bölgesel kullanılabilirliği bir gecikme özelliğinden, düzenlemeye tabi bir ekibin gerçekten benimseyebileceği bir şeye dönüştüren şeydir.

Failover bölgeleri bunun üzerine bir dayanıklılık katmanı ekliyor: bir fallback listesi yapılandırıldığı ve fallback'lerin kendileri onaylı sınırlar içinde kaldığı sürece, bir bölgedeki arıza artık sandbox oluşturmayı tamamen engellemek zorunda değil.