XFaaS: Meta'nın her gün trilyonlarca çağrıyı işleyen sunucusuz platformu

• Meta'nın dahili olarak kullandığı FaaS platformu
• Onlarca veri merkezi bölgesine dağıtılmış 100 binden fazla sunucuda her gün trilyonlarca fonksiyon çağrısını işliyor
• AWS Lambda ve Azure Functions'tan daha verimli olduğunu savunuyor ve bunu XFaaS: Hyperscale and Low Cost Serverless Functions makalesiyle paylaşıyor

İlgi çekici istatistikler ve çıkarımlar

• Makalenin ana fikri, donanım kullanımını yazılım yoluyla optimize ederek sunucusuz performansın iyileştirilebileceği
• Meta, Serverless Functions'taki başlangıç yükü israfını fark etti ve tüm worker'ların başlangıç ek yükü olmadan tüm işlevleri anında çalıştırabildiği bir Universal Worker'ı emüle etmeyi hedefledi
  • Bu ölçekte donanım maliyeti çok büyük ve çok küçük oranlar bile önemli
• XFaaS yalnızca kullanıcıya doğrudan görünmeyen işlevlerde kullanılıyor. Sunucusuz fonksiyonlar, kullanıcıya dönük işlevlerde tutarlı biçimde kullanılmak için fazla değişken gecikmeye sahip
• XFaaS'in istemcileri fonksiyon çağrılarını çok ani patlamalar halinde çalıştırıyor. Tepe talep, düşük talep dönemlerine göre 4,3 kat daha yüksek
  • Bir örnekte, 15 dakika içinde XFaaS'e 20 milyon fonksiyon çağrısı gönderildi
  • Meta, ani yükselen fonksiyonlarda da kalıplar olduğunu keşfetti ve bunu kullanarak iş yüklerindeki sıçrayan fonksiyonları daha öngörülebilir hale getirdi

XFaaS ne kadar verimli?

• Sektör ortalamasının çok üzerinde, günlük ortalama %66 CPU kullanımına ulaşıyor
• Yükü, zamanı kullanarak (fonksiyon gecikmesi üzerinden) ve alanı kullanarak (daha az yüklü veri merkezlerine göndererek) verimli biçimde dağıtıyor
  > Meta, birçok işlevi - yükü ve maliyeti tahmin edilebilenleri - kullanımın düşük olduğu saatlerde zamanlanacak şekilde taşımayı sürdürüyor
• Dahili bir bulut olduğu için Meta, aynı süreç içinde birden çok kullanıcının birden çok işlevini çalıştırmak gibi çeşitli benzersiz optimizasyonlar yapabiliyor
• Çoğu fonksiyon 1 saniyeden kısa sürede çalışsa da hepsi böyle değil

XFaaS'in çözdüğü problemler

• Problem: uzun cold start süreleri
  • Konteyner çok erken sonlandırılırsa bir sonraki çağrı için tüm konteynerin yeniden başlatılması gerekir
  • Konteyner çok geç sonlandırılırsa boşta kalarak değerli hesaplama kaynaklarını israf eder
  • Çözüm: XFaaS, JIT derleme gibi yöntemler kullanarak tüm worker'ların tüm fonksiyonları anında çalıştırabilmesini yaklaşık olarak sağlar
• Problem: ciddi yük dengesizliği
  • Aşırı kapasite ayırma ek donanım maliyeti yaratır; yetersiz kapasite ayırma ise sistemi yavaşlatır
  • Çözüm: XFaaS, gecikmeye toleranslı fonksiyon çalıştırmalarını düşük kullanım zamanlarına erteler ve fonksiyon çağrılarını dünya genelindeki veri merkezi bölgelerine dağıtır
• Problem: aşağı akış servislerinin aşırı yüklenmesi
  • Örnek: kullanıcıya görünmeyen fonksiyon çağrılarındaki artış, kullanıcıya dönük çevrimiçi hizmetlerin kesintiye uğramasına neden oldu
  • Çözüm: XFaaS, fonksiyon yürütmesini düzenlemek için TCP tıkanıklık kontrolüne benzer bir mekanizma kullanır

Genel FaaS ile karşılaştırma (AWS Lambda, Google Cloud Functions, Azure Functions)

• Public cloud FaaS, fonksiyon yürütmesini tek bir veri merkezi bölgesiyle sınırlandırırken XFaaS, fonksiyon çağrılarını dünya geneline dağıtarak load balancing'i iyileştirebilir
• FaaS platformları, donanım kullanımını göz ardı ederek öncelikle gecikmeyi azaltmaya odaklanır. XFaaS ise donanım kullanımına ve fonksiyon çağrılarının throughput'una odaklanır
• Public cloud için yararlı olabilecek XFaaS teknikleri
  • Çağıranın fonksiyon yürütmesinin başlangıç zamanını belirlemesine izin vermek
  • Fonksiyon sahibinin tamamlanma süresiyle ilgili hizmet seviyesi hedefleri (SLO) tanımlayabilmesi (SLO düşükse daha iyi çalışma süresi için gecikme tolere edilebilir)
  • Fonksiyon sahibinin fonksiyon için önem seviyesi belirleyebilmesine izin vermek
• Public cloud, XFaaS gibi birden çok kullanıcının işlevlerini aynı süreçte çalıştıramaz; ancak büyük ölçekli bulut müşterileri, sanal özel bulutta XFaaS yaklaşımını benimseyebilir
• Az sayıda Meta ekibi, XFaaS kapasitesinin önemli bir bölümünü tüketiyor. Public cloud kullanan benzer büyük ölçekli müşteriler de XFaaS stratejisinden fayda sağlayabilir

Background: varsayımlar ve gereksinimler

• Varsayımlar
  • Temel içgörü, XFaaS işlevlerinin çoğunun otomatik iş akışları tarafından tetiklendiği ve gecikmenin kabul edilebilir olduğu
  • Bu sayede XFaaS, yükü zaman boyunca (işlevleri geciktirerek) ve mekân boyunca (daha az yüklü veri merkezlerine göndererek) dağıtabilir
  • XFaaS; PHP, Python, Erlang, Haskell çalışma zamanlarını ve tüm diller için genel konteyner tabanlı bir çalışma zamanını destekler
  • Fonksiyonlar; fonksiyon adı, argümanlar, runtime, önem derecesi, yürütme başlangıç zamanı, yürütmenin tamamlanma son tarihi, kaynak kotası, eşzamanlılık sınırı ve yeniden deneme politikası gibi geliştiricinin belirleyebildiği çeşitli özelliklere sahiptir; tamamlanma son tarihi saniyelerden 24 saate kadar ayarlanabilir
  • XFaaS'te donanım kapasitesi bölgeden bölgeye değiştiği için load balancing bunu hesaba katmalıdır
• İş yükü türleri
  • Meta, XFaaS üzerinde üç tür iş yükünü destekliyor
    • Kuyruk tetiklemeli fonksiyonlar
    • Olay tetiklemeli fonksiyonlar (veri ambarı ve veri akışı sistemlerindeki veri değişiklik olayları)
    • Zamanlayıcı tetiklemeli fonksiyonlar (önceden belirlenmiş zamanda otomatik çalışanlar)
  • XFaaS, kullanıcıya görünmeyen; asenkron öneri sistemleri, loglama, üretkenlik botları ve bildirimler gibi işlevlerde kullanılıyor

Genel mimari

(Bu bölüm çok uzun ve makalenin içeriğini neredeyse olduğu gibi aktardığı için atlanmıştır.)