Párhuzamosítás Docker és Redis segítségével

Pár évvel ezelőtt szembejött egy pici belsős projekt, ahol jó lett volna párhuzamosítani a feladatokat. Gondoltam megnézem, hogyan lehet ezt megoldani Docker segítségével és meglepően gyorsan és könnyedén sikerült. Ezt szeretném most bemutatni nektek.

Feladat

Azt kellett megoldani, hogy a megadott URL-en található weboldalról megtudjuk, milyen verziójú Drupal-t használ és az mennyire elavult. Ezt a legtöbb Drupalos oldalnál egy egyszerű curl hívás és némi parancssori mágia segítségével meg lehet oldani.

Probléma

Ami a problémát jelenti, hogy meg kell várni azt a viszonylag hosszú időt, amíg az adott oldal betöltődik, vagyis a TCP csomagok megérkeznek. Ezalatt a várakozás alatt a gép processzora nem csinál semmit, az adott process gyakorlatilag alszik. Ekkor egy weboldal feldolgozás 2-3 másodperc, amiből a tényleges munka, amíg a processzor dolgozik az csak 2-3 századmásodperc.

Ha 100 processzt indítunk el, akkor 2-300 másodperc lesz az összes várakozás és 2-3 másodperc a tényleges processzor idő. Ha ezeket egymás után indítjuk el, akkor 2-300 másodpercig fog futni a feldolgozás, de ha párhuzamosítjuk ezeket, akkor csak a processzor időkkel kell számolnunk és hozzá kell adnunk az első hálózati időt, így 4-5 másodperc alatt végezni fog a scriptünk.

Megoldás a párhuzamosítás

Egy nem párhuzamosított feldolgozás úgy fog kinézni, hogy vesszük az URL-ek listáját és végigmegyünk rajta egy ciklussal, amiben URL-enként meghívjuk a feldolgozást.

A párhuzamosításnál pedig lesznek workereink, amik figyelnek egy várakozási sort, egy job queue-t. Amennyiben abba új URL érkezik, akkor feldolgozzák az előbb is használt feldolgozó függvénnyel. Az eredeti ciklusunk pedig nem a feldolgozást hívja meg ciklikusan, hanem bedobálja az URL-eket a várakozási sorba.

Ha csak egy workerünk van, akkor ugyanott vagyunk ahol az első megoldásnál, csak lassabbak és bonyolultabbak leszünk. Vagyis nem egészen, mert lehetőségünk lesz könnyedén skálázni a rendszert. Ha sok URL van a várakozási sorban, akkor csak el kell indítunk még egy pár workert és máris előbb végzünk.

Természetesen nem minden feladatot lehet ilyen egyszerűen skálázni egy gépen, de hogy miket lehet és hogyan arra majd egy másik blogbejegyzésben szeretnénk kitérni.

A teszt alatt 200 párhuzamos processz dolgozott egy MacBook Air gépen.

Egy jobnak három állapota lehet: vagy vár a feldolgozásra, vagy éppen dolgozunk vele, vagy már készen van. A jobok állapotát három lista segítségével tesszük követhetővé, amiknek a neve: queue, run, done. A queue, ahova az elvégzendő job-ok kerülnek. Ez lesz a fentebb említett várakozási lista. A run, ahol az éppen feldolgozás alatt álló feladatok vannak. Ebben lesznek azok a job-ok is amik valamiért elhaltak. A done, amibe azok a jobok kerülnek amik elkészülnek. A run és done listák nem feltétlenül szükségesek, azokat azért hoztam létre, hogy lehessen látni, hogy a jobok milyen állapotban vannak.

Figyelem!

Az itt bemutatott megoldás nem alkalmas az éles környezetben való használatra!. A példáknak kizárólag a párhuzamosítás bemutatása a célja, az itt található kódok írásakor nem foglalkoztam biztonsági kérdésekkel ezért csak saját felelősségre használjátok!

Architektúra

Három konténeres környezetet építünk. A feladatokat egy Redis szerverben fogjuk nyilvántartani, mivel az kész megoldást ad, többek között erre is.

Lesz egy worker nevű konténer, ami a feladatokat fogja végrehajtani, ez az amit majd több példányban is elindítunk.

És végül indítunk egy monitor konténert, ami egyrészt mutatja a feladatok állapotát, másrészt itt kap helyet az a script amivel újabb és újabb feladatokat dobhatunk be.

Ugyan a dockeres kialakítás miatt lehetőségünk lenne több gépen is skálázni a megoldást Kubernetes vagy Swarm segítségével, most mégis egy egygépes megoldást mutatok docker-compose segítségével.

Fontos tudni, hogy a docker-compose.yml mindkét, 2.x és 3.x verziója is használható. Azok egymás mellett élnek, fejlődnek. A kettő között az a különbség, hogy a 2.x verzióban található beállítási lehetőségek inkább a fejlesztői vagy lokális környezetben való futtatáshoz jók, míg a 3.x verzió inkább a többgépes rendszerekhez alkalmasak.

A fenti architektúrát a docker-compose.yml írja le

  1. version: "2.4"
  2. services:
  3. redis:
  4. image: redis
  5. healthcheck:
  6. test: ["CMD", "redis-cli", "ping"]
  7. interval: 1s
  8. timeout: 3s
  9. retries: 30
  10. monitor:
  11. build: monitor
  12. depends_on:
  13. redis:
  14. condition: service_healthy
  15. worker:
  16. build: worker
  17. depends_on:
  18. redis:
  19. condition: service_healthy

A három szervízről fentebb írtam. Mint látszik a redis konténerhez a hivatalos Redis imaget használom, kiegészítve egy healtcheck-el. A másik két konténert külön építjük meg, mivel azokat saját kóddal egészítjük ki.

Monitor

Nézzük mi van a monitor Dockerfile-jában:

  1. FROM ubuntu
  2. RUN apt-get update && apt-get install -y redis-tools
  3. COPY init.sh /init.sh
  4. COPY monitor.sh /monitor.sh
  5. COPY add.sh /add.sh
  6. ENTRYPOINT ["/init.sh"]

A második sorban telepítjük a redis-cli parancssoros redis klienst tartalmazó csomagot, majd bemásolunk pár bash scriptet és beállítjuk egyiket a belépési pontnak:

init.sh

  1. #!/bin/bash
  2. REDIS_CLI="redis-cli -h redis"
  3.  
  4. $REDIS_CLI DEL queue
  5. $REDIS_CLI DEL run
  6. $REDIS_CLI DEL done
  7.  
  8. exec /monitor.sh

A script semmi mást nem csinál, mint törli a három listát, hogy az esetleges korábbi futások eredménye ne okozzon problémát. Ezután elindítja a monitort. Mint látszik a redis szerver elérhetősége bele van drótozva a rendszerbe, de mivel ezek a szkriptek egy zárt, külön az alkalmazás részére létrehozott hálózaton fognak üzemelni, ezzel nem foglalkozunk.

montior.sh

A monitor a célja, hogy időről-időre követni tudjuk, hogyan áll a teljes folyamat. Erre itt azt a megoldást választottam, hogy 2 másodpercenként lekérem a három redis által kezelt lista hosszát, és kiírom az konzolra. Így:

  1. #!/bin/bash
  2. REDIS_CLI="redis-cli -h redis"
  3.  
  4. while true; do
  5. QUEUE=$($REDIS_CLI LLEN queue)
  6. RUN=$($REDIS_CLI LLEN run)
  7. DONE=$($REDIS_CLI LLEN done)
  8. echo "Queue: $QUEUE, run: $RUN, done: $DONE"
  9. done

Azért, hogy könnyedén tudjunk újabb feladatot hozzáadni a rendszerhez elhelyeztem egy add.sh-t is:

  1. #!/bin/bash
  2. REDIS_CLI="redis-cli -h redis"
  3.  
  4. for JOB in "$@"
  5. do
  6. $REDIS_CLI LPUSH queue $JOB
  7. done

Ennek csak annyi dolga van, hogy a parancssorban kapott értékeket betegye az elvégzendő feladatok közé. Ez az egyik pont, amit semmilyen körülmények között nem engednék futtatni éles környezetben. Mint látjátok, a kapott argumentumokat escape-elése nincs megoldva, így a feladat nem tartalmazhat idézőjelet ("), valamint jelen formájában könnyedén tudunk bármilyen parancsot futtatni a segítségével. Ettől függetlenül a job bármi lehet. A fent tárgyalt példában sima url-ek voltak a job-ok

Worker

Dockerfile

  1. FROM ubuntu
  2. RUN apt-get update && apt-get install -y redis-tools
  3. COPY worker.sh /worker.sh
  4. COPY script.sh /script.sh
  5. ENTRYPOINT ["/worker.sh"]

Nagy különbség nincs az előzőhöz képest, csak mási két fájlt használ.

worker.sh

  1. #!/bin/bash
  2. REDIS_CLI="redis-cli -h redis"
  3.  
  4. while true; do
  5.  
  6. JOB=$($REDIS_CLI BRPOPLPUSH queue run 0)
  7.  
  8. /script.sh $JOB
  9.  
  10. $REDIS_CLI LREM run 1 $JOB
  11. $REDIS_CLI RPUSH done $JOB
  12.  
  13. done

Ez a bash script is egy végtelen ciklusban ismétli a következőket. Első körben lekéri a job-ot a redisből. Ehhez a BRPOPLPUSH parancsot használja, ami kiveszi a queue-ból a következő feladatot és egyből átteszi a run sorba. Fontos, hogy ez egy atomi művelet, így nem fordulhat elő az, hogy egyszerre két worker kezd el dolgozni ugyanazon a feladaton. További előnye ennek a megoldásnak, hogy ha üres a lista, automatikusan várakoztatja a workert, így ezzel a problémával sem kell külön foglalkoznunk.,

Ezután a feladatot átadja a tényleges feldolgozást végző script.sh-nak majd, ha az végzett törli a job-ot a run sorból és átrakja a done sorba. Itt, szemben az előbbi esettel nem a következő tetszőleges feladattal kell foglalkoznom, hanem egy konkrét éppen a worker által feldolgozott jobbal dolgozom. Azt törlöm ki a run listából és teszem át a done listába.

A worker.sh nem foglalkozik hibakezeléssel, így a beragadt, elhalt vagy hibára futó jobokat a végén a run sorban fogjuk megtalálni.

Végezetül nézzük a script.sh-t

  1. #!/bin/bash
  2. # This is only a dummy example
  3.  
  4. echo "Start processing $1"
  5. echo "Finish processing $1"

Még egyszer: ez egy minta alkalmazás, nem csinál semmit. Így itt csak kiírja, hogy elkezdődött a feldolgozás, alszik 5 másodpercet majd kiírja, hogy végzett. Amikor tartalommal kezdjük feltölteni, csak arra kell figyelni, hogy a keletkező adatokat valamilyen külső helyen tároljuk, ne ebben az eldobható konténerben. Ez lehet egy külső SQL, vagy valamilyen megosztott tároló, amilyen az S3. Vagy akár egy olyan Redis szerverre, amiben meg van oldva az adatok mentése és visszaállítása, szemben a példánkban használt megoldással. Mondjuk egy a felhő szolgáltató által biztosított hosted Redis megoldásra.

Használat

Az indításhoz adjuk ki a következő parancsot:

docker-compose up -d

Ha szeretnénk látni mi történik a motorháztető alatt két terminál ablakra lesz szükségünk. Az egyikbe "indítsuk el" a monitort:

docker-compose logs -f

A másikban pedig bátra adjunk hozzá két-három job-ot:

docker-compose exec monitor /add.sh alma korte barack

Ha mindent jól csináltunk valami ilyen eredményt kell látnunk:

Két ablakot látunk. Az egyikben a fenti add parancs, míg a másikban a log látszik, ahogyan a monitor üzenetei között megjelennek a worker üzenetei a feldolgozásról.

A korábban említett skálázást a docker-compose scale kapcsolójával tudjuk hangolni. Például, ha három workert szeretnénk indítani

docker-compose up -d --scale worker=3

Ha ismét csak egy workerre van szükség, akkor:

docker-compose up -d --scale worker=1

Figyeljük meg, ha volt job amin "dolgozott" egy worker, akkor az a run sorban marad, valamint azzal is kell majd valamit kezdenünk, hogy ne olyan lassan álljanak le a workerek. Mindkettő forrása az, hogy a jelenlegi megoldás nem foglalkozik a signálokkal, pedig a Docker alapból lehetővé teszi, hogy graceful shutdown-t hajtsunk végre, vagyis leállításkor visszategyük a feldolgozatlan jobot a queue sorba. Ez azonban már egy másik cikk témája.

Amennyiben befejeztük a játékot, akkor adjuk ki a következő parancsot:

docker-compose down

Összefoglalás

Mint látható a Docker segítségével könnyedén tudjuk skálázni az alkalmazásunkat. Természetesen erre a futtatni kívánt alkalmazást is fel kell készíteni, de ezzel a cikkel csak az a célom, hogy bemutassam, egy ilyen architektúrát felépíteni viszonylag egyszerű a Docker és a Redis segítségével.

Egy következő cikkben működő példát is szeretnék összerakni, hogy lássátok az általatok használt eszközökkel, hogyan lehet ezt megtenni. Amennyiben van konkrét projekt amit szeretnél párhuzamosítani, keress meg nyugodtan az istvan at palocz pont hu email címen, vagy a fészen.

Ha érdekel hogyan tudod fejelsztőcégedet teljesen átállítani a Docker használatára nézd meg a "Konténerizált fejlesztői környezet kialakítása" c. kurzusom.

Címkék: 

Új hozzászólás