háttér
a Nextdoor-nál sok ütemezett munkát futtatunk különböző fontos célokra, például napi tízmillió digest e-mailt küldünk felhasználóinknak, belső jelentéseket készítünk növekedésünkről és néhány operatív feladatról. Mint sok más internetes vállalat (például az Airbnb és a Quora), a Cron-nal kezdtük, és végül saját cron-cserét építettünk, amelyet Nextdoor Schedulernek hívtunk.
több mint 18 hónapja használjuk a Nextdoor Schedulert, és rendkívül elégedettek vagyunk vele.
Szóval, mi a probléma a Cron-nal?
négy fő probléma van a Cron – val.
először is, a Cron használatának módja nem volt skálázható. Az összes Cron feladatot egy húsos ütemező gépen futtattuk (c3.8xlarge). Ahogy tapadást szereztünk, a Cron jobs a számítási erőforrás-felhasználás szempontjából a határáig tolta a gépet.
másodszor, az egyszerű szöveges crontab szerkesztése hibára hajlamos a feladatok kezelésére, például a feladatok hozzáadására, a feladatok törlésére vagy a feladatok szüneteltetésére. Például, egy extra csillag megakadályozta az összes termelési feladat futtatását a minap:
1 * * * * * /opt/nextdoor/some_job.sh
harmadszor, mi felmerült egy csomó működési rezsi a Cron. Közel kétszáz termelési munkánk van, amelyek naponta több ezer alkalommal futnak, különböző gyakorisággal (például aprólékosan, óránként, hetente). A munkahelyi kudarc gyakori. Az oncall személynek manuálisan kellett újraindítania a sikertelen munkákat naponta többször, néha éjfél után. Íme egy példa egy tipikus oncall tapasztalat: 1) get lapozott a parancssor a sikertelen munkát; 2) ssh az ütemező gép; 3) copy & illessze be a parancssort, hogy futtassa újra a sikertelen munkát. Ez természetesen nem jó a mérnöki boldogsághoz-igen, törődünk munkatársaink boldogságával!
negyedszer, kevés láthatóságunk volt a termelési munkákra futásidőben. Nem volt könnyű módja annak, hogy megtudja, milyen munkahelyek futnak, vagy sikerrel jártak-e.
határozat
elég elég. Úgy döntöttünk, hogy építünk egy cron-csere. De miért nem használunk nyílt forráskódú megoldásokat? Csak nem találtunk megfelelőt. Beszélünk python. Ki akartuk használni a vállalat meglévő infrastrukturális elemeit. Meg akartuk építeni, megérteni és birtokolni.
a skálázhatóság problémájának megoldása érdekében minden feladatot aszinkron feladatként hoztunk létre, amely Taskworker gépek csoportján futtatható. Könnyen konfigurálhatjuk a Taskworker-en futó feladatokat, hogy automatikusan újrapróbálják, ha kudarcot vallanak, ami csak egyetlen soros kódmódosítást igényel. Oncall mérnökeink szeretik ezt az automatikus újrapróbálkozási funkciót!
a Cron helyett a kiváló apscheduler python modult használtuk a feladatok ütemezéséhez, amely lehetővé tette számunkra a feladatok programozható kezelését — REST API-kat, parancssori eszközöket és emberbarát webes felhasználói felületet építettünk.
architektúra
az alábbi kép az ütemező rendszer architektúráját mutatja.
Nextdoor Scheduler végre Python / Tornado. Egyetlen démon folyamatként (ütemező folyamat) fut egyetlen gépen, amely három összetevőből áll.
- ütemező (vagy Core ütemező). Ez helyettesíti a cron-t, és ütemezi a futási feladatokat. Amikor egy feladat futtatásra kerül, az ütemező folyamat egyszerűen közzéteszi a feladat üzenetét az Amazon SQS – nek. A Taskworker gépek egy csoportja megragadja az Amazon SQS üzeneteit, és futtatja a megfelelő feladatokat. Mint fentebb említettük, az APScheduler-t használjuk a core scheduler megvalósításához.
- ütemező API. Rest felületet biztosít a feladatok kezeléséhez, pl. munkahelyek hozzáadása, a munka szüneteltetése/folytatása, a feladatok eltávolítása, a feladatok módosítása és a munka kézi indítása. A parancssori eszközöket az ütemező API tetejére építettük, hogy megkönnyítsük a műveleteket, például egyszerre szüneteltessük a feladatok egy csoportját.
- webes felhasználói felület. Ez egy egyoldalas alkalmazás, amely az ütemező API-val beszél. Gerincet használtunk.JS és Bootstrap a webes felhasználói felület megvalósításához. Az emberi operátorok elsősorban a webes felhasználói felületet használják a Nextdoor ütemezővel való interakcióhoz.
az összes feladat és feladat végrehajtása egy adattárban tárolódik. A Postgres-t elsősorban itt, a Nextdoor-nál használjuk.
Web UI
a mérnökök szeretik a Nextdoor Scheduler webes felhasználói felületét, amely intuitív módon kezeli a feladatokat, ahelyett, hogy a régi időkben a blackbox-szerű Cron-nal foglalkozna.
Állásoldal
ezen az oldalon láthatjuk, hogy milyen munkáink vannak, és mikor fognak futni legközelebb. Az “egyéni Futtatás” gombra kattintva manuálisan elindíthatjuk a munkát.
munka szerkesztése
könnyedén szerkeszthetünk egy munkát, pl. módosíthatjuk az ütemezését, és szüneteltethetjük egy gombnyomással! Ez sokkal jobb, mint a sima szöveges crontab módosítása a régi időkben.
kivégzések oldal
végül, nagy láthatósággal rendelkezünk arról, hogy milyen munkahelyek futnak, és hogy sikeresek-e vagy sem.
a
bevezetése a kód írása egyszerű. A termelés nehéz. Mire befejeztük a Nextdoor Scheduler megvalósítását, közel 200 termelési Cron feladatunk volt, amelyeknek át kellett költözniük az új rendszerre.
a Taskworker projektből tanultakat alkalmaztuk a Nextdoor Scheduler rendszer bevezetésére. Négy lépés:
- a We dark elindította a Nextdoor Schedulert a gyártáshoz — az új rendszerrel még nem futottak gyártási munkák.
- hozzáadtunk egy funkciókapcsolót az összes feladat alaposztályához.
- két hét alatt lassan és óvatosan bekapcsoltuk a funkciókapcsolókat minden munkához.
- leállítottuk a régi húsos ütemezőgépet, amely a Cron-t futtatta.
Happy End
az új Nextdoor Scheduler, képesek vagyunk futtatni egy sokkal olcsóbb scheduler EC2 például (c3.2xlarge), mint korábban (c3.8xlarge), miközben a terhelés szuper alacsony, mint mi tehermentesíti feladatok futtatni elosztott Taskworker gépek.
itt látható a régi ütemező gép (felső grafikon) és az új ütemező gép (alsó grafikon)CPU-használatának összehasonlítása:
több mint 18 hónapja használjuk az ütemező munkákat. Eddig boldogok vagyunk. Ha érdekli az ilyen típusú problémák és más érdekes infrastrukturális kihívások kezelése,felveszünk!