Meta Serverless qanday ishlaydi

Bu darsda nima o‘rganasiz

Instagram’ga rasm yukladingiz. Ekranda u bir soniyada paydo bo‘ladi, lekin orqada ish endigina boshlanadi: rasmni bir necha o‘lchamda siqish, obunachilarga bildirishnoma tayyorlash, qidiruv indeksini yangilash, nomaqbul kontentni tekshirish, tavsiya tizimi uchun belgilarni hisoblash, statistikani yangilash. Bularning hech biri sizning “Yuklash” tugmangizni kutib turmaydi — ular fonda, keyinroq bajariladi.

Meta’da bunday fon ishlarini minglab muhandis yozadi. Ular server sotib olmaydi, ishga tushirmaydi va kuzatmaydi — faqat funksiya yozadi: “rasm yuklanganda shu kodni ishga tushir”. Qolgan hamma ishni ichki platforma — XFaaS — qiladi. 2023-yilda SOSP konferensiyasida chop etilgan maqolaga ko‘ra, XFaaS kuniga trillionlab funksiya chaqiruvini 100 000 dan ortiq serverda bajaradi.

Bu darsning savoli — tezlik emas, samaradorlik. Funksiya platformalari odatda serverlarni yomon band qiladi: ko‘p vaqt ular bo‘sh turadi va eng og‘ir daqiqani kutadi. XFaaS esa o‘rtacha 66% CPU bandligiga erishgan — maqola mualliflari fikricha, bu odatiy FaaS platformalaridan bir necha barobar yuqori. Dars bunga olib kelgan to‘rtta g‘oyani ochadi:

1. Sovuq startni yo‘qotish. Funksiya birinchi marta ishga tushganda kod yuklanadi, kompilyatsiya qilinadi, keshlar to‘ladi — soniyalar ketadi. XFaaS “har ishchi har funksiyani darhol bajara oladi” degan holatga yaqinlashadi.

2. Ishni vaqt va makon bo‘yicha surish. Chaqiruvlar oqimi kun davomida 4 barobardan ko‘proq o‘zgaradi. Kutishi mumkin bo‘lgan ishlar tunga va bo‘sh hududlarga suriladi — serverlar cho‘qqi uchun emas, o‘rtacha uchun sotib olinadi.

3. Muddat va kvota bilan rejalashtirish. Minglab jamoa bitta hovuzni bo‘lishadi: kim birinchi, kim kutadi, kim qanchadan oshmasligi kerak.

4. Boshqa xizmatlarni himoya qilish. Million funksiya bir vaqtda bitta ma’lumotlar bazasiga yopirilsa — baza yiqiladi. XFaaS internetdagi TCP kabi “tirbandlik nazorati” ishlatadi.

Har yangi tushuncha avval oddiy tilda, keyin mexanizm sifatida, oxirida raqam bilan beriladi. Dars oxirida — butun darsning o‘n gaplik xulosasi. Oldingi darslardan foydali: Kafka darsidagi navbat va lag, fond birjasi darsidagi muddat va ustuvorlik, YouTube darsidagi transkodlash (fon ishining klassik misoli) va Amazon S3 darsidagi “cho‘qqi uchun rejalashtirish”.

1. Muammo: minglab jamoa, milliardlab fon vazifasi

1.1 Serverless oddiy tilda

Oddiy tilda: siz restoranda ovqat buyurasiz, oshxonani qurmaysiz, oshpaz yollamaysiz, gaz uchun to‘lamaysiz. Faqat “nima kerak”ni aytasiz. Serverless (“serversiz”) — dasturchi uchun xuddi shu: u faqat funksiya yozadi — qaysi hodisada nima qilish kerak. Server qayerda, nechta, qachon yoqiladi — platformaning ishi.

Albatta, serverlar baribir bor — ular shunchaki dasturchiga ko‘rinmaydi. Platforma uchun esa savollar ko‘payadi: qaysi funksiyani qaysi serverda, qachon, qancha resurs bilan bajarish; kodni qanday yetkazish; xato bo‘lsa nima qilish.

1.2 Talablar

Ikkinchi va uchinchi qator — darsning asosiy ziddiyati. Yuqori bandlik uchun serverlar doim to‘la ishlashi kerak; muddatlar uchun esa doim bo‘sh joy bo‘lishi kerak. XFaaS bu ziddiyatni muddatlar har xilligi orqali hal qiladi: shoshilinch ishlar darhol bajariladi, kutishi mumkinlar esa bo‘sh joyni to‘ldiradi.

1.3 Konvert orqasidagi hisob

2. Nol nuqta: funksiya, chaqiruv va navbat

2.1 Sinxron va asinxron

Oddiy tilda: telefon qo‘ng‘irog‘i — siz javobni kutasiz, suhbatdosh hozir band bo‘lsa, qo‘ng‘iroq bo‘lmaydi. Xat — siz yuborasiz va o‘z ishingizga qaytasiz; javob keyinroq keladi, qabul qiluvchi o‘zi qulay paytda o‘qiydi.

Ko‘pchilik ommaviy FaaS xizmatlari asosan “telefon” — HTTP so‘rovga sinxron javob. XFaaS esa asosan “xat” — asinxron chaqiruvlar: chaqiruvchi funksiyani navbatga qo‘yadi va kutmaydi. Bu bitta farq rejalashtirishga erkinlik beradi: chaqiruvni qachon bajarishni platforma tanlaydi — muddat ichida.

2.2 Uch xil ishga tushirish va ularning ulushi

XFaaS’da funksiya uch yo‘l bilan chaqiriladi, va ularning ulushlari juda turlicha (maqoladagi ma’lumot):

Jadval qiziq manzara beradi. Chaqiruvlarning ko‘pi — hodisa bilan ishga tushadigan, qisqa funksiyalar. Hisoblashning ko‘pi esa navbatdagi funksiyalarda: ular kamroq chaqiriladi, lekin har biri og‘ir. Aynan shu og‘ir, navbatdagi ishlar ko‘pincha kechiktirishga chidamli — va vaqt bo‘yicha surishning asosiy “xomashyosi” (9-qadam).

2.3 Kamida bir marta va idempotentlik

Navbatga qo‘yilgan chaqiruv yo‘qolmasligi kerak: platforma uni bardoshli saqlaydi va bajarilganini tasdiqlamaguncha o‘chirmaydi. Ishchi bajarish o‘rtasida o‘lsa — chaqiruv boshqa ishchiga beriladi. Natija: har chaqiruv kamida bir marta bajariladi, ba’zan esa ikki marta (ishchi bajarib bo‘lgan, lekin tasdiq yetib bormagan).

Shuning uchun funksiyalar idempotent bo‘lishi kerak: ikki marta bajarish bir marta bajarish bilan bir xil natija bersin. “Rasmning kichik nusxasini yasab, shu nom bilan saqla” — idempotent. “Hisoblagichni 1 ga oshir” — idempotent emas, unga chaqiruv identifikatori bo‘yicha “allaqachon qilinganmi?” tekshiruvi kerak (Airbnb darsidagi idempotentlik kalitlari).

2.4 To‘rt rol bitta rasmda

Darsning qolgan qismida to‘rtta rol doim uchraydi. Ularni bitta katta oshxona bilan eslab qolish oson:

Chaqiruvchi — ofitsiant: buyurtmani yozib, oshxonaga beradi va zalga qaytadi. U ovqat pishishini kutib turmaydi.

Navbat — buyurtmalar taxtasi: har buyurtma unda yozilgan, “shoshilinch” yoki “ertagacha” belgisi bilan. Taxta yonib ketmasligi uchun uning nusxasi boshqa xonada ham bor.

Rejalashtiruvchi — bosh oshpaz: taxtaga qarab, kim nimani qachon pishirishini hal qiladi. Har bo‘limning kunlik limiti va ombor holatini ham hisobga oladi.

Ishchilar — oshpazlar: berilgan buyurtmani bajaradi. Ular qancha retseptni yoddan bilsa (issiq kesh), shuncha tez.

Va beshinchi, ko‘pincha unutiladigan rol — downstream: ombor va masalliq yetkazuvchilar. Oshpazlar qanchalik tez bo‘lmasin, ombor sekundiga faqat bir necha qop bera oladi. Yaxshi bosh oshpaz omborni ham “yiqitmaydi”.

3. v0: har jamoaning o‘z serverlari va cron

Platformasiz eng sodda yo‘l: har jamoa o‘z fon ishlari uchun bir necha server oladi va ishchi jarayon yozadi. Navbat — ma’lumotlar bazasidagi jadval:

import time

def worker_loop(db, handler, team):
    while True:
        job = db.query_one(
            "SELECT * FROM jobs WHERE team = %s AND state = 'new' "
            "ORDER BY created LIMIT 1 FOR UPDATE SKIP LOCKED", team)
        if job is None:
            time.sleep(1)              # navbat bo'sh — kutamiz
            continue
        try:
            handler(job.payload)       # jamoaning kodi
            db.execute("UPDATE jobs SET state = 'done' WHERE id = %s", job.id)
        except Exception:
            db.execute("UPDATE jobs SET state = 'new', tries = tries + 1 WHERE id = %s", job.id)

Taymerli ishlar uchun — cron. Bu v0 ishlaydi: kichik kompaniyada o‘nlab jamoa shunday yashaydi. Muammolar jamoalar soni, yuklama tebranishi va umumiy resurslar bilan chiqadi — 4-bo‘lim.

Bu kod yomon emas: FOR UPDATE SKIP LOCKED bir nechta ishchining bitta ishni olmasligini ta’minlaydi, xato bo‘lsa — ish qayta navbatga qaytadi. Lekin unda platformaning har bir qismi har jamoada qayta yozilgan va kichik holda:

4. Nima sindi

v0 ga 1-bo‘limdagi talablarni qo‘yamiz: minglab jamoa, kuniga trillionlab chaqiruv, umumiy bazalar va keshlar. Har muammo 5-bo‘limdagi bir yoki bir nechta qadamga olib keladi.

4.1 Har jamoa — o‘z cho‘qqisi

Oddiy tilda: har oila o‘z to‘yi uchun alohida to‘yxona quradi va yilning qolgan kunlari u bo‘sh turadi.

4.2 Butun kompaniya cho‘qqisi

Umumiy hovuz ham yetarli emas: odamlar kunduzi faol, tunda — kam. Chaqiruvlar oqimi kun davomida 4 barobardan ko‘proq o‘zgaradi (1.3). Har chaqiruv kelgan zahoti bajarilsa, hovuz baribir cho‘qqiga mo‘ljallanadi, tunda esa yarmi bo‘sh turadi. Kerak: ishni vaqt bo‘yicha surish (9-qadam).

4.3 Sovuq start

v0 da har jamoaning ishchisi doim yoqiq — sovuq start yo‘q, lekin bandlik past. Umumiy hovuzda esa ishchi “bugun kimning funksiyasini” bajarishini oldindan bilmaydi: kodni yuklash, runtime’ni ishga tushirish, JIT kompilyatorni isitish — har safar soniyalar (1.3). Kerak: kod oldindan hamma joyda, keshlar issiq (4–6-qadamlar).

4.4 Bazani bosib ketish

Bir jamoa yangi funksiya chiqardi: “har foydalanuvchi uchun statistikani qayta hisobla”. Navbatda 500 million chaqiruv. Bo‘sh hovuz ularni darhol bajara boshlaydi — va hammasi bitta ma’lumotlar bazasiga yopiriladi.

4.5 Shovqinli qo‘shni

Umumiy hovuzda bitta jamoaning xatoli funksiyasi (cheksiz qayta urinish, xotira oqishi, juda uzun bajarilish) boshqalarning resursini yeydi. Kerak: har funksiya uchun kvota va resurs chegaralari (8, 13-qadamlar).

4.6 Takrorlar bo‘roni

v0 da xato bo‘lsa — chaqiruv darhol qayta navbatga qo‘yiladi. Agar xato sababi bazaning ortiqcha yuklanishi bo‘lsa, qayta urinishlar yukni oshiradi va baza hech qachon tiklanmaydi. Kerak: kechikish bilan qayta urinish, urinishlar budjeti va tirbandlik nazorati (11–12-qadamlar).

4.7 Butun hudud ishdan chiqadi

v0 navbati bitta bazada, ishchilar bitta ma’lumot markazida. Markaz o‘chsa — hammasi to‘xtaydi; boshqa markazlarda esa bo‘sh serverlar turibdi. Kerak: navbat va ishchilar bir nechta hududda, va hududlar orasida yukni almashish (2, 10-qadamlar).

4.8 Muammolar ro‘yxati

5. Evolyutsiya: o‘n to‘rt qadam

Qadamlar mantiqiy tartibda: 1–3 — funksiya, navbat va umumiy hovuz; 4–6 — sovuq startga qarshi kurash; 7–10 — nimani, qachon va qayerda bajarish; 11–12 — boshqalarni himoya qilish; 13–14 — xavfsizlik va kod yetkazish.

har funksiya f va har ishchi w uchun: ball(f, w) = xesh(f, w)
f ning guruhi = ball eng yuqori bo'lgan G ta ishchi

Ishchi qo'shildi:  f ning guruhi faqat yangi ishchi f uchun top-G ga
                   kirsa o'zgaradi -> ehtimol ~ G / (N + 1)
Ishchi olindi:     faqat shu ishchi guruhida bo'lgan funksiyalar ta'sirlanadi

Kooperativ usulsiz (har server o'zi):
  yangi versiya -> har server: profillash (daqiqalar, sekin) -> kompilyatsiya -> tez
  10 000 server x bir necha daqiqa sekin ishlash = katta yo'qotish har chiqarishda

Kooperativ JIT:
  bitta (yoki bir nechta) server yangi versiyani profillaydi
  profil ma'lumotlari boshqa serverlarga yuboriladi
  qolganlari darhol optimallashtirilgan kodni oldindan kompilyatsiya qiladi

Sig'im: tikiga 2 ta. Ishlar (kelish, muddat):
  a(0, 0)  b(0, 2)  c(0, 1)  d(1, 1)
FIFO (kelish tartibi): t=0: a, b    t=1: c, d    -> hammasi o'z vaqtida (omad)
  lekin d(1,1) o'rniga d(0,0) bo'lsa: t=0: a, b -> d kechikdi
EDF: t=0: a(0), d(0)   t=1: c(1), b(2)  -> hammasi o'z vaqtida

signal yo'q va chegara to'liq ishlatilgan:  limit = limit + 1
ortiqcha yuklama signali:                    limit = limit x 0.5

6. Bitta chaqiruvning hayoti

6.1 Qadam-baqadam

Instagram’ga rasm yuklandi. Serverdagi kod “bu rasmning kichik nusxalarini yasa” degan funksiyani chaqiradi (navbat triggeri, muddat — 1 daqiqa, kritiklik — yuqori):

1. Chaqiruvchi (veb-server kodi) funksiyani navbatga qo‘yadi va darhol javob oladi: “qabul qilindi”.
2. Yuboruvchi funksiya kvotasini tekshiradi.
3. QueueLB chaqiruvni bardoshli navbatga (DurableQ) yozadi — endi u yo‘qolmaydi.
4. Rejalashtiruvchi navbatdan chaqiruvlarni kritiklik va muddat bo‘yicha oladi, kvota va downstream chegaralarini hisobga olib.
5. Global Traffic Conductor matritsasi bo‘yicha chaqiruv shu hududda yoki boshqa hududda bajariladi.
6. Ishchi — funksiyaning lokallik guruhidan, kodi va JIT keshi issiq — funksiyani bajaradi.
7. Funksiya o‘z ishini qiladi: rasm omboridan o‘qiydi, kichik nusxalarni yozadi, TAO’dagi yozuvni yangilaydi.
8. Muvaffaqiyat — chaqiruv navbatdan o‘chiriladi; xato — qayta urinish siyosati bo‘yicha (12-qadam).

6.2 Chaqiruv holatlari

YUBORILDI --> NAVBATDA --> REJALASHTIRILDI --> BAJARILMOQDA --> MUVAFFAQIYAT
                 ^                                  |
                 |                                  +--> XATO --(urinishlar qolgan)--+
                 +---------- kutish bilan qayta (12-qadam) <-------------------------+
                                                    |
                                                    +--> XATO (urinishlar tugadi) --> O'LIK XATLAR
NAVBATDA --(muddat o'tdi)--> MUDDATI O'TDI (hisobotda, ogohlantirish)

Ikki holat alohida e’tiborga loyiq. Muddati o‘tdi — bu kechikish emas, xato: chaqiruv endi bajarilmaydi, va bu funksiya egasiga hisobot sifatida boradi. O‘lik xatlar — qayta urinishlar tugagan chaqiruvlar: ularni odam ko‘rib chiqadi yoki tuzatilgan kod bilan qayta yuboradi (Kafka darsidagi zaharli xabarlar kabi).

6.3 Hodisa triggeri: ma’lumot o‘zgardi — funksiya ishga tushdi

Chaqiruvlarning 85% i hodisa bilan ishga tushadi (2.2). Hodisa — ma’lumotlar bazasidagi o‘zgarish: yangi izoh yozildi, foydalanuvchi profilini o‘zgartirdi, do‘stlik qo‘shildi. Funksiya egasi “shu turdagi o‘zgarish bo‘lganda meni chaqir” deb obuna bo‘ladi, va platforma o‘zgarishlar oqimini o‘qib, har mos hodisa uchun chaqiruv yaratadi.

Bu Kafka darsidagi “jurnal — haqiqat, iste’molchilar — hosila” g‘oyasining boshqa ko‘rinishi: baza o‘z o‘zgarishlar jurnalini e’lon qiladi (Airbnb darsidagi CDC kabi), funksiyalar esa uning iste’molchilari. Hodisa funksiyalari odatda qisqa (hisoblashning atigi 14% i), lekin juda ko‘p.

Ikki nozik joy. Takrorlar: jurnal o‘quvchisi qayta ishga tushsa, hodisalarni ikkinchi marta o‘qishi mumkin — funksiya idempotent bo‘lishi kerak. Tartib: bitta obyektga ikki o‘zgarish (masalan, “profil o‘zgardi” ikki marta) navbatda turli ishchilarga tushsa, kech kelgani oldin bajarilishi mumkin. Shuning uchun hodisa funksiyalari odatda hodisadagi qiymatga emas, joriy holatga qarab ishlaydi: “profil o‘zgardi — joriy profilni o‘qib, indeksni yangila” (11-bo‘limdagi “niyat, qaror emas” qoidasi).

7. Sovuq start anatomiyasi

7.1 Sovuq chaqiruv nimaga vaqt sarflaydi

“Sovuq start” — funksiya yangi joyda birinchi marta bajarilganda qo‘shimcha ish. Ommaviy FaaS’da u ko‘p bosqichli; XFaaS ularning ko‘pini oldindan bajarib qo‘yadi:

7.2 Nega ommaviy bulut buni qila olmaydi

                        Ommaviy FaaS                Ichki FaaS (XFaaS)
kod egasi               millionlab begona mijoz     bitta kompaniya xodimlari
ishonch                 hech kimga                  kod ko'rib chiqilgan, bitta repo
kodni oldindan tarqatish mumkin emas (maxfiylik,    mumkin: til bo'yicha hamma kod
                        hajm)                       hamma serverda
izolyatsiya             qattiq (VM)                 yengil (runtime, jarayon)
tillar                  istalgan, istalgan versiya  asosan bir necha, markazlashgan
narx modeli             mijoz har ms uchun to'laydi kompaniya umumiy samaradorlikni o'ylaydi

7.3 Sovuq startni qanday o‘lchash kerak

“Sovuq start ulushi” oddiy ko‘rinadi, lekin uni aniq ta’riflash kerak. Amaliyotdagi simulyatsiyada ta’rif sodda: chaqiruv kelgan ishchining keshida funksiya yo‘q edi — sovuq. Haqiqiy tizimda bir nechta daraja bor:

daraja                       qanday aniqlanadi                    narxi
kod diskda yo'q              (universal ishchida bo'lmaydi)       soniyalar
runtime ishga tushmagan      (universal ishchida bo'lmaydi)       soniyalar
JIT kodi yo'q                profil/kompilyatsiya hisoblagichi    yuzlab ms - soniyalar
xotira keshlari sovuq        birinchi chaqiruv vs keyingilar      ms lar

To‘g‘ri metrika — nafaqat ulush, balki qo‘shimcha vaqt: har funksiya uchun birinchi va keyingi chaqiruvlarning o‘rtacha bajarilish vaqti farqi, chaqiruvlar soniga ko‘paytirilgan. Shu son “sovuqlik” ning haqiqiy narxini yadro-soatlarda beradi va qaysi funksiyalar uchun guruhni kattalashtirish yoki kichraytirish kerakligini ko‘rsatadi.

8. Yuklama shakli va vaqt bo‘yicha surish

8.1 Boshqaruv halqasi

Vaqt bo‘yicha surish — doimiy ishlaydigan boshqaruv halqasi: o‘lchash, qaror, ta’sir.

8.2 Nega Meta’da kechiktiriladigan ish ko‘p

"hozir" kerak (soniyalar):         "bugun" yetarli (soatlar):
  rasm kichik nusxalari              tavsiya modellari uchun belgilar
  bildirishnoma yuborish             statistika va hisobotlar
  izoh moderatsiyasi (oldindan)      eski ma'lumotlarni ko'chirish
  qidiruv indeksiga qo'shish         spam hisoblarini qayta tekshirish
                                     zaxira nusxalar, tozalash ishlari

9. Bugungi arxitektura

Rasmning asosiy g‘oyasi — qaror qatlami (rejalashtirish) va bajarish qatlami (ishchilar) ajratilgani. Ishchilar sodda va universal; barcha “aql” — kvotalar, muddatlar, surish, himoya — rejalashtirishda. Fond birjasi darsidagi sekvenser va matching engine ajratilishiga o‘xshash: tartib va qaror bir joyda, bajarish boshqa joyda.

Kafka darsi bilan solishtirish foydali — ikkalasi ham navbat va iste’molchilar, lekin maqsad boshqacha:

Kafka’da tartib — kafolat, XFaaS’da esa erkinlik manbai: tartib shart bo‘lmagani uchun har chaqiruvni istalgan ishchiga, istalgan paytda (muddat ichida) berish mumkin.

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

10.2 Bitta hodisa: ma’lumotlar bazasi sekinlashdi

Quyidagi — soddalashtirilgan stsenariy, maqoladagi umumiy tavsifga (“TAO nosozliklarida unga murojaat qiluvchi funksiyalar sekinlashtirildi”) asoslangan, raqamlar o‘ylab topilgan:

11. Xavfsizlik va ma’lumot himoyasi

11.1 Kim nimani chaqira oladi

Funksiya — ma’lumotga kirish eshigi: u foydalanuvchilar ma’lumotlarini o‘qiydi va yozadi. Shuning uchun har funksiya uchun: kim uni chaqira oladi (qaysi xizmatlar, qaysi jamoalar kodi), nima qila oladi (qaysi bazalar, qaysi jadvallar, qaysi API lar), va kimning nomidan ishlaydi (foydalanuvchi kontekstini ko‘chirish, maxfiylik qoidalarini qo‘llash). Huquqlar spetsifikatsiyada (1-qadam) yoziladi va bajarish paytida tekshiriladi.

Xavfli:  enqueue(send_digest, user_id=42)
         -> funksiya: barcha postlarni o'qiydi, 42 ga ko'rsatishga ruxsat
            tekshirilmaydi -> maxfiy post dayjestga tushadi

Xavfsiz: enqueue(send_digest, user_id=42, viewer_context=42)
         -> funksiya: har postni "42 ko'ra oladimi?" qoidasi bilan o'qiydi
            platforma: viewer_context ni chaqiruv bilan birga saqlaydi

11.2 Resurs chegaralari: qachon to‘xtatish kerak

Har chaqiruvga uchta chegara qo‘yiladi: vaqt (masalan, 10 daqiqa — oshsa, chaqiruv to‘xtatiladi va xato sifatida qayd etiladi), xotira (oshsa — jarayon o‘ldiriladi, aks holda butun ishchi xotirasiz qoladi) va CPU (adolatli ulush). Chegaralar spetsifikatsiyada va funksiya egasi ularni oshirishni so‘rashi mumkin — lekin oshirish kvotadan “to‘lanadi”.

Nega bu xavfsizlik masalasi? Chunki cheklovsiz funksiya mavjudlik hujumi bo‘lishi mumkin — ataylab yoki xato bilan: cheksiz sikl ishchini abadiy band qiladi, xotira oqishi qo‘shni chaqiruvlarni o‘ldiradi. Umumiy hovuzda bitta bunday funksiya minglab chaqiruv bilan butun guruhni egallaydi. Chegaralar shovqinli qo‘shni muammosining (4.5) oxirgi himoya qatlami.

12. Iqtisod: bandlik — pul

12.1 Bir million chaqiruvning narxi

12.2 Kechiktirish chegirmasi

Xizmat darajasi                     Ichki narx (nisbiy)   Kim uchun
kafolatlangan, sekundlar            1.0 (yoki ko'proq)   foydalanuvchi kutadigan ishlar
kafolatlangan, daqiqalar            ~0.7                 tez, lekin shoshilinch emas
opportunistik, 24 soat              ~0.2-0.3             fon hisob-kitoblari, migratsiyalar

12.3 Nega 66%, 100% emas

Agar bandlik pul bo‘lsa, nega 100% ga intilmaslik kerak? Uchta sabab:

Shoshilinch ishlar uchun zaxira. Yangilik yoki to‘satdan portlash paytida shoshilinch chaqiruvlar darhol joy topishi kerak. Kechiktiriladigan ishlar bu joyni bo‘shatadi — lekin bir zumda emas, bandlik nazoratchisi halqasi orqali (8.1): o‘nlab soniyalar.

Nosozliklar uchun zaxira. Hudud yoki ishchilar guruhi ishdan chiqsa, qolganlar uning ishini oladi (10-qadam). 100% band hovuzda buning uchun joy yo‘q.

Navbat nazariyasi. Bandlik 100% ga yaqinlashganda kutish vaqti chiziqli emas, portlovchi o‘sadi (fond birjasi darsi, 13-bo‘lim). Shoshilinch ishlarning kutish vaqti barqaror bo‘lishi uchun hovuz “to‘la” bo‘lmasligi kerak.

Shuning uchun 66% — “past” emas, balki muddatlar va ishonchlilik cheklovlari ostida juda yuqori natija. Odatiy ommaviy FaaS bandligi bundan bir necha barobar past ekanini eslang (1.3).

13. Sig‘im rejalashtirish

13.1 Hovuz va navbat hajmi

14. Kuzatuv

14.1 Nima o‘lchanadi

14.2 Uchidan-uchiga tekshiruv

Har qatlam metrikalari alohida “yaxshi” bo‘lishi mumkin, lekin zanjir buzilgan. Shuning uchun sintetik funksiya: platforma jamoasining o‘zi yozgan kichik funksiya har daqiqada har hududda chaqiriladi — har kritiklik va muddat turi bilan. U yozilgan vaqtni, bajarilgan vaqtni, ishchini va hududni qayd etadi. Natija: “shoshilinch chaqiruv navbatdan ishchigacha qancha kutdi” degan haqiqiy, uchidan-uchiga raqam; va “kechiktiriladigan chaqiruv haqiqatan 24 soat ichida bajarildimi”.

Bundan tashqari, downstream sintetikasi: sintetik funksiya har downstream xizmatga bitta yengil so‘rov yuboradi — AIMD chegarasi pastga tushganda bu so‘rovlarning kechikishi “xizmat haqiqatan sekinmi yoki signal noto‘g‘rimi” degan savolga javob beradi.

15. Antinaqshlar

Platforma zimmasida:                 Funksiya egasi zimmasida:
  serverlar, OS, runtime, kod tarqatish  idempotentlik
  navbat va yetkazish kafolati           to'g'ri muddat va kritiklik
  rejalashtirish, kvotalar, surish       resurs iste'moli (CPU, xotira)
  downstream himoyasi (umumiy)           downstream'ga murojaat naqshi
  izolyatsiya, huquqlarni tekshirish     maxfiylik qoidalarini qo'llash
  kuzatuv infratuzilmasi                 o'z funksiyasining metrikalari

16. Trade-off‘lar

Butun dars o‘nta gapda

1. Serverless — mas’uliyat taqsimoti: dasturchi funksiya va qoidalarni yozadi, platforma serverlar, navbat, rejalashtirish va himoyani oladi (1-bo‘lim, 15 Deep).
2. Bandlik — pul: 20% va 66% farqi bir xil ish uchun ~3 barobar server (1.3, 12-bo‘lim).
3. Asinxron chaqiruv — erkinlik: navbat va muddat platformaga “qachon, qayerda, qanchalik tez” degan tanlovni beradi (2-bo‘lim).
4. Kamida bir marta — idempotentlik shart: bardoshli navbat yo‘qotmaydi, lekin takrorlaydi (2.3, 2-qadam).
5. Sovuq start — pul muammosi: universal ishchi, kooperativ JIT va lokallik guruhlari birgalikda uni deyarli yo‘qotadi (4–6-qadamlar, 7-bo‘lim).
6. Kritiklik va eng yaqin muddat birinchi: ortiqcha yuklamada nima kechikishi oldindan aniq (7-qadam).
7. Kvotalar — ikki xil: kafolatlangan va imkoniyatga qarab (24 soat); ichki narx jamoalarni to‘g‘ri tanlovga undaydi (8-qadam, 12-bo‘lim).
8. Vaqt va makon bo‘yicha surish: 4.3x chaqiruv cho‘qqisi — 1.4x bandlik tebranishiga (9–10-qadamlar).
9. Downstream — TCP kabi himoya: asta oshir, keskin kamaytir; fon ishi birinchi bo‘lib chekinadi (11-qadam, 10.2).
10. Navbat — vaqt mashinasi: niyatni saqlang, qarorni emas; formatlar orqaga mos; kechiktirilgan navbat yoshi — sig‘im signali (11, 13, 14-qadam).

Darslik oxirida: o‘n yetti darsning umumiy saboqlari

Bu — darslikning oxirgi darsi. ChatGPT’dan boshlab Meta Serverless’gacha o‘n yetti tizimni ko‘rdik. Ular juda turlicha ko‘rinadi, lekin bir xil g‘oyalar qayta-qayta uchradi:

1. Jurnal — haqiqat, qolgani — hosila. Kafka’ning commit log’i, fond birjasining deterministik jurnali, Bluesky’ning firehose’i, Google Docs’ning operatsiyalar tarixi, Airbnb’ning CDC oqimi — hammasida holat o‘zgarishlar ketma-ketligidan quriladi va qayta quriladi.
2. Takror — norma, idempotentlik — majburiyat. URL qisqartiruvchidagi kalitlar, Airbnb to‘lovlari, Kafka producer’i, birja ClOrdID si, XFaaS chaqiruvlari — tarmoq ikki marta yetkazadi, tizim bir marta bajarishi kerak.
3. Tartib — raqam bilan, soat bilan emas. Sekvenser, offset, rev, seq — “kim birinchi” degan savolga har doim raqam javob beradi.
4. Cho‘qqi uchun emas, o‘rtacha uchun quring — agar ishni surish mumkin bo‘lsa. YouTube transkodlashi, S3 ning fon tekshiruvlari, XFaaS’ning kechiktiriladigan ishlari.
5. Kesh va lokallik. Redis, CDN, Spotify keshlari, lokallik guruhlari — eng tez so‘rov — umuman bajarilmagan so‘rov.
6. Barqaror xeshlash. URL qisqartiruvchi va Google Docs’dagi izchil xeshlash, bu darsdagi rendezvous guruhlari — server qo‘shilganda hamma narsa ko‘chmasin.
7. Dum va bo‘sh sig‘im. O‘rtacha yolg‘on gapiradi: p99, p99.99 va “90% band — allaqachon muammo” birja, ChatGPT va Slack darslarida bir xil.
8. Boshqalarni himoya qiling. AIMD, kvotalar, qayta urinish budjeti, tezlik chegaralari — katta tizim o‘z tezligi bilan boshqalarni yiqitmasin.
9. Raqam bilan qaror. Har darsdagi “konvert orqasidagi hisob” — dizayn munozarasini fikrdan dalilga aylantirish usuli.
10. Har tanlovning narxi bor. Har qadamda “Yutuq” va “Narx” — tizim dizaynida bepul yechim yo‘q, faqat ongli tanlov bor.

Bu o‘nta g‘oyani yangi tizimda — intervyuda yoki ishda — topib, nomlay olsangiz, darslik o‘z vazifasini bajargan bo‘ladi.

17. Intervyu savollari

17.1 Asoslar

17.2 Rejalashtirish va resurslar

17.3 Ishonchlilik, xavfsizlik va loyihalash

18. Amaliyot

To‘rt daraja. Ikkinchi daraja uchun kod docs/amaliyot/meta-serverless/ da: scheduler.py — rejalashtiruvchi (kritiklik, muddat, kvota, downstream), uchta usul TODO; concurrency.py — AIMD, bitta usul TODO; router.py — lokallik guruhlari va to‘kilish, ikkita usul TODO; model.py — tayyor Call, Fn va barqaror xesh; check.py — 17 ta tekshiruv, taxminan 5 soniya. Faqat Python standart kutubxonasi.

har tik t va har slot uchun (85% ehtimol bilan):
  ish: kelish = t - tasodifiy(0..20), muddat = t + tasodifiy(0..15)
-> kamida bitta jadval (asl jadval) hamma muddatni bajaradi
-> EDF ham bajarishi SHART (7-qadam Deep)

chegara
 K+1 |      /|      /|      /|
     |     / |     / |     / |
     |    /  |    /  |    /  |
 K/2 |   /   |   /   |   /   |
     +-------------------------- vaqt
     davr uzunligi ~K/2 tik, har davrda 1 ta "ortiqcha" tik

1 tik = 1 daqiqa, 2 kun (ikkinchi kun — faqat qarzlarni bajarish)
sig'im: 300 chaqiruv/daqiqa
kiruvchi oqim: sinusoida, cho'qqisi sig'imning 1.5x i
  30% shoshilinch (muddat 0-2 daqiqa, HIGH)
  70% kechiktiriladigan (muddat 24 soat, LOW)
40 funksiya, har 8-si "tao" downstream'ga murojaat qiladi
tao sig'imi: 60/daqiqa, kunduzi 1 soat davomida 15 (nosozlik)
har daqiqa: AIMD chegarasi -> pick(..., limits={"tao": chegara}) -> AIMD yangilanadi

19. Lug‘at

20. Raqamlar manbasi

Chaqiruvlarning aniq kunlik soni va o‘rtacha CPU vaqti, server va yadro narxlari, sovuq start bosqichlari davomiyligi, navbat hajmlari, kvota va AIMD parametrlari, kod hajmi, izolyatsiya narxi, hududlar misollari, 10.2 dagi hodisa vaqtlari — illyustratsiya uchun taxminiy yoki soddalashtirilgan. XFaaS ichki tizim: maqola uning arxitekturasi va asosiy natijalarini ochadi, lekin har tafsilotni emas; darsdagi mexanizmlar maqolaga, uning sharhlariga va taqsimlangan tizimlarning umumiy tamoyillariga asoslangan. Asosiy xulosalar — bandlik pul ekanligi, asinxronlik va muddat rejalashtirishga erkinlik berishi, sovuq startni oldindan tayyorlash bilan yo‘qotish, downstream’ni AIMD bilan himoya qilish — bu raqamlarning bir necha barobarlik xatosiga ham chidamli.

21. Manbalar

• Alireza Sahraei va boshq. (2023), “XFaaS: Hyperscale and Low Cost Serverless Functions at Meta”, SOSP
• Dah-Ming Chiu, Raj Jain (1989), “Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks”, Computer Networks and ISDN Systems
• Van Jacobson (1988), “Congestion Avoidance and Control”, SIGCOMM
• C. L. Liu, James W. Layland (1973), “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment”, Journal of the ACM (EDF)
• David G. Thaler, Chinya V. Ravishankar (1998), “Using Name-Based Mappings to Increase Hit Rates”, IEEE/ACM Transactions on Networking (rendezvous xeshlash)
• Michael Mitzenmacher (2001), “The Power of Two Choices in Randomized Load Balancing”, IEEE Transactions on Parallel and Distributed Systems
• Guilherme Ottoni (2018), “HHVM JIT: A Profile-Guided, Region-Based Compiler for PHP and Hack”, PLDI
• Mohammad Shahrad va boshq. (2020), “Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider”, USENIX ATC
• Alexandru Agache va boshq. (2020), “Firecracker: Lightweight Virtualization for Serverless Applications”, NSDI
• Eric Jonas va boshq. (2019), “Cloud Programming Simplified: A Berkeley View on Serverless Computing”, Berkeley texnik hisoboti