ugrás a tartalomhoz

Egyszerű skálázódás

Hidvégi Gábor · 2017. Júl. 23. (V), 10.22
Már korábban is felmerült, de A frontend állapota 2017-ben című fórumtémában az egyik fő érv az állapot szerveroldalon történő kezelése ellen az volt, hogy ez jelentősen megnehezíti a backend munkáját, legrosszabb esetben az egész szolgáltatás jelentős lelassulását, leállását okozhatja. Mivel a téma fontos, ezért érdemes külön foglalkozni vele.

Elmélet

A skálázódás egy szolgáltatás fontos tulajdonsága, amely azt a képességét adja meg, hogy nagy terhelés esetén a rendszer hogyan viselkedik, mekkora válaszidők várhatóak. Ez utóbbi sokmindentől függ, külsőleg a kliens szerverhez való kapcsolódási sebességétől (például mobiltelefonon befolyásolja az időjárás, a térerő, az adott cellán lévő más felhasználók száma), valamint az egyes rendszerkomponensektől (milyen programkörnyezetet választottunk, mennyi adattal kell dolgoznunk, milyen kapcsolat van a részegységek között, mekkora a terhelésük stb.). Egy alkalmazás bármelyik összetevője lehet szűk keresztmetszet, ami kihatással van az egészre, így fontos a megfelelő tervezés.

Gyakorlat

Az első és legfontosabb, hogy folyamatosan mérni kell az egyes részek teljesítményét. Ha van hozzáférésünk, az operációs rendszer feladatkezelőjében láthatjuk, hogy az egyes processzek mekkora CPU terhelést okoznak és mennyi memóriát foglalnak, de lehetőség van szoftverből is figyelni az erőforrásokat, például a Nagios segítségével.

Sokszor a legegyszerűbb lehet a szerveroldalon a hardverelemek jobbra, gyorsabbra cserélése, a memória bővítése például jótékony hatással van mindenre: az operációs rendszer vagy az adatbázisszerver többmindent tud gyorsítótárazni, de ugyanígy a merevlemezek cseréje SSD-re is jelentősen javíthat a válaszidőkön.

Ha egy szerver már nem bírja, a legkönnyebb az adatbázist egy másik (virtuális) gépre áttenni. Előtte viszont érdemes összegyűjteni a lassú lekérdezéseket, MySQL alatt a Slow query log bekapcsolásával. Ha ezek megvannak, tudjuk őket elemezni az EXPLAIN SELECT ... paranccsal, amely megmondja, melyik rész teljesít gyatrán, amit felgyorsíthatunk néhány jól elhelyezett index-szel.

A replikációval legtöbbször az olvasási teljesítményt lehet elosztani több szerver között, például a Postgres-XL nevű program a nevéből adódóan PostgreSQL alatt valósítja meg ezt a funkciót, komoly, több rétegű alkalmazás saját terheléselosztóval. Ez akkor jöhet jól, ha az adatbázisainkat nem tudjuk több részre bontani.

Szilánkok

Az egymással össze nem függő komponenseket ún. shardokba tudjuk szervezni, ami több szintű lehet. Ilyen az, amikor az adatbázis másik szerverre kerül, és ezt is bonthatjuk több részre, például az adatok egyik részét az egyik, a többit egy másik szolgálja ki.

A használt programozási nyelv is adhat szilánkolásra lehetőséget, a PHP is tud szolgáltatásként futni (PHP-FPM), amit akár több szerverre is kioszthatunk. Itt is fontos a mérés, hogy tudjuk, alkalmazásunk egyes funkciói közül melyik teljesít a legrosszabbul.

Szoftverarchitektúra

A bevezetőben említett cikkében janoszen felteszi a kérdést: Mi történik akkor, ha egy felhasználó párhuzamosan két lekérdezést indít? Az ott kifejtett indokok miatt valóban csak sorosan lehet kiszolgálni a válaszokat, viszont ez több dolgot is felvet. Egyrészt komolyabb oldal, ahol pénzügyi adatokkal dolgoznak (például számlázás), nem is működhet másként, mert csak így lehet biztosítani a konzisztenciát. Másrészt az ember egyszerre csak egy dologra tud figyelni, hiába van két szeme – miért indítana el több kérést? Harmadrészt a számítógépen vagy mobilon is a beviteli eszközökkel is egy időben csak egy inputot lehet adni: egy helyre lehet kattintani, egy beviteli mezőbe lehet írni, egyvalamit lehet simogatni.

A párhuzamosan elindított kérések a zárolás mellett több erőforrást is igényelnek, mert – főleg régebbi böngészőkön – annyi külön handshake műveletet kell elvégezni, HTTP fejléceket küldözgetni, külön elvégezni az azonosítást, jogosultságokat ellenőrizni stb.

A fentiek miatt célszerű egymással összefüggő, tipikusan scripttel előállított erőforrások esetében egy felhasználói interakciónál egy kérést indítani, így
  • összességében mindenképp hamarabb fog végződni a művelet,
  • hamarabb és egyszerre tudjuk kirajzolni a képernyőre az adatokat,
  • tehát jobb lesz a felhasználói élmény,
  • alacsonyabb szerverterhelés,
  • egyszerűbb lesz az alkalmazás, olcsóbb fejlesztés és karbantartás,
  • kombinálva a szilánkokkal a rendszer sokkal jobban fog skálázódni.

Kit érint?

A legfontosabb kérdés a témában, hogy kell-e vele kiemelten foglalkozni? Ugyanis a rendszer összetevőit kifejezetten skálázhatóra tervezni és implementálni sok idő és erőforrás, viszont nem mindenkit érint. Nagyon sok weboldal vagy alkalmazás csak rétegtermék, egy viszonylag szűk körnek szól, például az adott környéknek vagy egy bizonyos szakmának, így nem várható számottevő forgalom. Nem szabad figyelmen kívül hagyni, hogy piacgazdaságban élünk, ahol a termékek egymással versenyeznek, azaz mindig lesz egy legjobb, néhány jó, a többiek pedig kevésbé vonzó paraméterekkel rendelkeznek, vagy akár sikertelenek lesznek. Ebből következik, hogy célszerű mindig csak épp annyit megcsinálni, amire szükség van, és a finomhangolással csak akkor foglalkozni, amikor a megfigyeléseink alapján, belátható időn belül problémák várhatóak a rendszer sebességével. Egy szolgáltatás általában úgysem egyik pillanatról a másikra lesz népszerű, így szokott lenni idő a módosításokra. És, mint a tapasztalatok mutatják, az idő előtti optimalizáció minden rút gonoszság megidézője.
‹ VPS Hosting Google Drive: feltöltés helyett áttöltés ›
 ■
1

Na ez egy hasznosabb cikk

BlaZe · 2017. Júl. 23. (V), 11.25
Na ez egy hasznosabb cikk (tudom fórum téma). A shardoknál érdemes beleírni a hátrányait is, ha gondolod.

Egyrészt komolyabb oldal, ahol pénzügyi adatokkal dolgoznak (például számlázás), nem is működhet másként, mert csak így lehet biztosítani a konzisztenciát.
Nagyobb, teljesítménykritikus elosztott rendszereknél ez így nem igaz, ott szóba se jöhet a lockolás. Nincs is mondjuk csak eventual consistency.

Bár egyetértek vele, hogy "premature optimisation is the root of all evil", egy architektúra megtervezésénél a skálázhatóság (nem skálázás) számításba vétele nem premature optimisation. De az egy tulajdonsága egy rendszernek, hogy mennyi erőforrással lehet később skálázni.

Továbbá egy rendszer nem baj, ha képes elviselni a mindenkori legnagyobb loadjának a dupláját.
8

Úgy érted, hogyha eleve egy

inf · 2017. Aug. 2. (Sze), 16.29
Úgy érted, hogyha eleve egy jól skálázódó rendszert írsz, akkor később a skálázással kevesebbet fogsz szívni, amikor befut az app, és már nem bírja a szerver a forgalmat? :-)
9

Ilyesmi, de nem azt mondom,

BlaZe · 2017. Aug. 2. (Sze), 21.40
Ilyesmi, de nem azt mondom, hogy egy induló webshop adminjához egy globálisan elosztott architektúrában kell gondolkodni :)

Az IT rendszerek kiszolgálói egy cég céljainak. Egy cég kifejezett célja pedig a növekedés. Ezért a lefejlesztett rendszerek képesek kell legyenek ésszerű határokon belül (pénzügyi és időbeli) a bővülésre. Ez a bővülés lehet akár (hirtelen és átmeneti, vagy tartós) terhelés növekedés, akár feature-ök hozzáadása. Ezért ha már előre és menet közben is gondolnak erre a fejlesztők, akkor az lehet komoly spórolás a megrendelőnek hosszabb távon. Ezek szerintem szinte minden rendszerre igazak. Ami a kérdés - és gondolom HG is inkább erre gondolt az írásában -, hogy nem minden rendszernek kell felkészülnie a masszív (horizontális) skálázódásra a 0. napon.
11

Tervezés

Hidvégi Gábor · 2017. Aug. 3. (Cs), 10.52
A startupok 90%-a pár éven belül megbukik. Vagy vegyünk pár nagy magyar webshopot vagy kapcsolódó szolgáltatást: edigital, 220volt, emag, arukereso. Tudunk párat említeni, a többiek kishalak. Egy cég felfutása általában nem robbanásszerű, hanem fokozatos.

Nemzetközi piacon ugyanígy nehéz labdába rúgni a multik mellett.

Ezek miatt direkt skálázásra tervezni egyszerűen pazarlás, és nem szolgálja a megrendelők érdekeit.
12

Szerintem olvasd el még

BlaZe · 2017. Aug. 3. (Cs), 11.12
Szerintem olvasd el még egyszer, amit írtam. Még azt is, amit janoszen írt. Valaminek az átgondolása és megfelelő patternek, technológiák választása nem feltétlenül kell lassítsa a fejlesztést, sőt. Következő körben pedig kimondottan csökkenti a költségeket.
13

Átlag

Hidvégi Gábor · 2017. Aug. 3. (Cs), 12.26
Olvastam. Egy átlag webfejlesztő, aki nem kifejezetten dinamikusan növő céghez megy el dolgozni, tíz projektből egyszer fog olyannal találkozni, ahol a skálázódással foglalkozni kell, kilencszer pedig nem releváns a dolog. Így nem érdemes energiát fektetni ilyen technológiák, minták kutatásába, hacsak nem kifejezetten érdeklődik irántuk, akkor viszont nem feltétlenül a legjobb munkahelyet választotta.

Egy átlag weboldalnak teljesen megfelelő egy keretrendszer használata, vagy akár saját fejlesztés. Ahol pedig már kicsit is fontos adatokkal dolgoznak, például pénzügyekkel, a munkamenetekhez járó beépített zárolás kifejezetten fontos a konzisztens működés érdekében, és biztonságosabb is, mint a tokenes megoldás.

János is és te is nagy cégeknek dolgoztok, ahol egyszerűen mások a követelmények minden szempontból.
14

Szerintem kicsit

BlaZe · 2017. Aug. 3. (Cs), 22.54
Szerintem kicsit leegyszerűsíted az átlag webfejlesztőt a pici, szinte teljesen statikus weboldalakat kalapáló PHP-ban makogó kezdőre. Ha így deklarálod a webfejlesztőt, akkor igazad van. Ha nem, akkor beletartoznak a komoly PHP, Java, C#, node.js és egyéb backend fejlesztők is, ahol ez a probléma egészen biztosan nem 10%-ban kerül elő, hanem inkább 10%-ban nem kerül elő. Érdemes megnézni az álláshirdetéseket, hogy miket keresnek manapság. Mindenhol magas rendelkezésre állású, elosztott, integrációs, cloud, big data stb rendszereket kell fejleszteni, és ezek fölé webes megjelenést. Ott pedig ezekkel a problémákkal bizony kell foglalkozni. Az ügyfelek már nem igazán fogadják el a belassulást, a leállást stb és igazuk is van. A felhasználók se fogadják el. Minden technológia adott hozzá, hogy ne kelljen elfogadják.

Így nem érdemes energiát fektetni ilyen technológiák, minták kutatásába
Ugye most csak viccelsz???

Ahol pedig már kicsit is fontos adatokkal dolgoznak, például pénzügyekkel, a munkamenetekhez járó beépített zárolás kifejezetten fontos a konzisztens működés érdekében, és biztonságosabb is, mint a tokenes megoldás.
Aki bármennyire is függővé tenné pénzügyi tranzakciók feldolgozását egy http session lockolásától, azt konkrétan szakmailag felelősségre kéne vonni. Egy pénzügyi tranzakciónak és egy webes requestnek semmi köze nincs egymáshoz. Ilyet le se írjunk.

Továbbá janoszen is és én is leírtuk már, hogy pont a nagy pénzmozgásokat kezelő rendszereknél nem feltétlenül jellemző a lockolás. Mi pl igen nagy pénzmozgással dolgozunk, de nem hogy lockolás nincs, de még tranzakció, sőt, szinkron DB írás sincsen.

Amit viszont én valójában írtam - csak megint valami más lett belelátva -, hogy ha egy rendszer kapacitása az aktuális üzleti igények kiszolgálásának határán mozog (annál nem képes többre), akkor valójában gátja a megrendelő növekedésének. Legyen szó akár teljesítményről, akár üzleti funkciók bevezetéséről. Ezért hoztam múltkor példának a pénzügyi kereskedő cégek számára hamarosan kötelezővé váló skálázódási képességet (a mindenkori legnagyobb loadjuk dupláját kell tudják kezelni mindenféle probléma nélkül).

A masszív horizontális skálázódás egy tök másik dolog. Olyannyira nem arra gondoltam, hogy még explicit le is írtam, hogy nem arra gondolok :)
15

Érdemes megnézni az

Hidvégi Gábor · 2017. Aug. 4. (P), 08.48
Érdemes megnézni az álláshirdetéseket, hogy miket keresnek manapság. Mindenhol magas rendelkezésre állású, elosztott, integrációs, cloud, big data stb rendszereket kell fejleszteni
Kíváncsiságból megnéztem a weblabor munka rovatát, abból is az első tizenötben egyben volt említve, hogy a "Cloud" ismerete előny. És most vonatkoztassunk el attól, hogy 1, március 31 óta nem volt frissítve a lista, azóta annyit nem változtak az elvárások, 2, az, hogy téged LinkedIn-en az általad leírt cégek keresnek meg, nem azt jelenti, hogy mindenki mást is.

A saját tapasztalataim pedig azok, hogy a cégek csórók, jobb híján megelégszenek egy Facebook weboldallal, mert erre van keret, az eggyel jobbak már használnak Excelt, hogya folyamataikat kezeljék, de ez független a kommunikációtól, a számlázástól stb.

Szóval itthon erre van igény és kereslet, az átlag cégnek fogalma sincs arról, mi a big data vagy a felhő.

Az ügyfelek már nem igazán fogadják el a belassulást
Ez a kijelentés megalapozatlan, ha az átlagot vesszük figyelembe. Nézd meg az edigital, a tesco, az emag, az index stb. weboldalát, akár mobilon, és számold ki, mennyi idő alatt jutsz a tartalomhoz: több másodperces válaszidők vannak. Ha valóban fontos lenne az átlagember számára a válaszidő, akkor ezeket az oldalakat nem használnák. És ezek a nagy cégek, ahol van pénz arra, hogy a legjobb fejlesztőket (akik itthon maradtak) megfizessék, mégsem gyorsak az oldalaik.

Én elhiszem, hogy vannak olyan szolgáltatások, ahol fontos a minél gyorsabb válaszidő, de akkor most visszautalnék a korábbi vitára, ahol a frontend keretrendszerek, mint az angular meg a react: ezekkel igencsak jól le lehet rontani a teljesítményt. Hoztam is példát, a mi rendszerünk ugyanazt az ezervalahányszáz elemből álló űrlapot tízszer gyorsabban renderelte le, mint a React, vagy például Pepitáék részére készítettem egy demót, amit a MiniCRM egy másodperc alatt jelenített meg, az nekem 30-35ms körül volt.

Aki bármennyire is függővé tenné pénzügyi tranzakciók feldolgozását egy http session lockolásától, azt konkrétan szakmailag felelősségre kéne vonni. Egy pénzügyi tranzakciónak és egy webes requestnek semmi köze nincs egymáshoz. Ilyet le se írjunk.
Egy szóval sem említettem pénzügyi tranzakciókat. Egy átlag webfejlesztő miért foglalkozna pénzügyi tranzakciókkal? Ezek tudtommal csak pénzintézetek között zajlanak, ami nem egy átlagos munkahely. Bankból Magyarországon van tízes nagyságrendű, kis- és középvállalkozásból meg tízezres. Most akkor melyiknek az igényeire készüljön fel az átlag programozó?

Az átlag cégek pénzügyei kimerülnek abban, hogy számláznak, nyilvántartják a termékeiket, például raktárban, van esetleg egy webshopjuk, ahonnan lehet rendelni, esetleg egy banki API-n keresztül tudják kezelni a bankszámláikat. Ezekre a feladatokra teljesen megfelel a http munkamenethez járó zárolás.

Továbbá janoszen is és én is leírtuk már, hogy pont a nagy pénzmozgásokat kezelő rendszereknél nem feltétlenül jellemző a lockolás. Mi pl igen nagy pénzmozgással dolgozunk, de nem hogy lockolás nincs, de még tranzakció, sőt, szinkron DB írás sincsen.
Értem én, csak ez az információ teljesen irreleváns. A legtöbb fejlesztő nem fog ilyen tranzakciókkal foglalkozni, mert a megrendelőknek nincsen rá igénye.

ha egy rendszer kapacitása az aktuális üzleti igények kiszolgálásának határán mozog (annál nem képes többre), akkor valójában gátja a megrendelő növekedésének
Ebben tökéletesen igazad van, és nem is vitatkoztam vele. De ha nincs a rendszer kapacitása azon a határon, márpedig tízből nyolc-kilenc cégnél nincs, akkor a téma legfeljebb érdekes, de nem feltétlenül aktuális.
22

Kíváncsiságból megnéztem a

inf · 2017. Aug. 4. (P), 22.42
Kíváncsiságból megnéztem a weblabor munka rovatát, abból is az első tizenötben egyben volt említve, hogy a "Cloud" ismerete előny.


http://www.tankonyvtar.hu/hu/tartalom/tamop425/2011-0001-526_margitay_az_erveles/ch11s03.html
26

A weblaboron hirdetők

BlaZe · 2017. Aug. 5. (Szo), 00.57
A weblaboron hirdetők semennyire sem reprezentatív minta. Nézz fel azokra a helyekre, amit írtam: profession és egyéb magyar állásközvetítő oldalak, linkedin, flexjobs stb. Teljesen más igények vannak, mint amit az a pár hirdető ír, akinek itt kikerült a hirdetése.

Nálunk van pl kb 1500 ember, akik mind komolyan megfinanszírozott projecteken dolgoznak, jó eszközökkel, megtervezett architektúrákon. Csak Magyarországon. És ok, nem mind fejlesztő, vagy tesztelő, de akkor is jelentős szám. És saját fülemmel hallottam, hogy többszáz fejlesztőnek tudnánk akár holnap munkát adni. Ha lennének... És ilyen cégből van itthon még egy pár. A lényeg, hogy többezer fejlesztő és tesztelő dolgozik Magyarországon olyan ügyfeleknek, akik áldoznak az IT-ra, és szükségük van minőségi (jellemzően skálázódó is) megoldásokra.

Egy dolog igaz: ezek jellemzően nem magyar ügyfelek, de főleg nem kkv-k. De ha fejlesztői szemmel nézzük, nagyon komoly lehetőségek vannak már itthon is azoknak, akik erre nyitottak.

Egy szóval sem említettem pénzügyi tranzakciókat. [...] esetleg egy banki API-n keresztül tudják kezelni a bankszámláikat.
Tehát akkor hajtanak végre (harmadik féllel) pénzügyi tranzakciókat.

Bankból Magyarországon van tízes nagyságrendű, kis- és középvállalkozásból meg tízezres. Most akkor melyiknek az igényeire készüljön fel az átlag programozó?
A programozó fejlődjön, és akarjon komolyabb helyre bejutni dolgozni. Amikor kijött a Hayes IT fizetési felmérése, tele lett a net picsogó fejlesztőkkel, hogy hát szinte lehetetlen egy seniornak annyit keresni, amennyi oda le van írva. Arra kell felkészülni az átlag programozónak, hogy fejlődni és tanulni kell.

Értem én, csak ez az információ teljesen irreleváns. A legtöbb fejlesztő nem fog ilyen tranzakciókkal foglalkozni, mert a megrendelőknek nincsen rá igénye.
Én csak az állításodra reagáltam :)

Ebben tökéletesen igazad van, és nem is vitatkoztam vele. De ha nincs a rendszer kapacitása azon a határon, márpedig tízből nyolc-kilenc cégnél nincs, akkor a téma legfeljebb érdekes, de nem feltétlenül aktuális.
Én nem is állítottam az ellenkezőjét. A tízből nyolc-kilencet azért kétségbe vonnám, de teljesen mindegy a téma szempontjából.
29

Nem tudom, miért lenne a

Hidvégi Gábor · 2017. Aug. 5. (Szo), 09.31
Nem tudom, miért lenne a Weblabor irreleváns munkák szempontjából, de sebaj, átnéztem a profession.hu első húsz találatát a témában, egynél kerestek felhőhöz programozót, egynél projektmenedzsert, a többiben szó sem volt big datáról meg magas rendelkezésreállásról.

Biztos van ilyenekre is szükség, de az átlag cégnek nem.

»esetleg egy banki API-n keresztül tudják kezelni a bankszámláikat.«
Tehát akkor hajtanak végre (harmadik féllel) pénzügyi tranzakciókat.
Esetleg. De miért is fontos ez? Miben másabb egy külső API-t meghívni, mint mondjuk egy adatbázis lekérdezést?

Arra kell felkészülni az átlag programozónak, hogy fejlődni és tanulni kell.
Ez így van. De miben is tud fejlődni a programozó, aki mondjuk keretrendszert használ, azaz keretek közé van szorítva?
32

Nem tudom, miért lenne a

BlaZe · 2017. Aug. 5. (Szo), 12.29
Nem tudom, miért lenne a Weblabor irreleváns munkák szempontjából
Azért, mert legjobb időkben is kb 10 pozíció volt itt hirdetve a piacon nyitott ezres nagyságrendből, és mert néhány kivétellel inkább pistikéket kerestek, nem képzett fejlesztőket.

Miben másabb egy külső API-t meghívni, mint mondjuk egy adatbázis lekérdezést?
Az online fizetés aszinkron, és semmi dolga nincs a webshop sessionjével.

De miben is tud fejlődni a programozó, aki mondjuk keretrendszert használ, azaz keretek közé van szorítva?
Nem értem a kérdést. Miért ne tudna fejlődni? Egy keretrendszer nem egy béklyó. Ugye nem gondolod, hogy komplex rendszert lehet keretrendszer (szakértő kódbázis) nélkül készíteni? Ha ez megvan, ugye nem gondolod, hogy az azt használók nem fejlődnek? Egy keretrendszer feladata a technikai komplexitás elrejtése, és a fejlesztők támogatása, MIUTÁN az architektúra meg lett tervezve. Amihez meg tanulni kell, hogy működjön...
16

Igaza van

janoszen · 2017. Aug. 4. (P), 09.34
Nem gyakran mondok ilyet, de ebben igaza van. Az átlag PHP és Java fejlesztő nem találkozik skálázós technológiával. Még a nagy állami és corporate rendszereket is agyonverik azzal hoyg tesznek alá egy 24 core-os gépet 96 giga rammal. Vagy, ha már nagyon gurul a szopóroller, rálőcsölik a rendszergazdára hogy oldja meg, amiből az lesz hogy rosszabb esetben tol alájuk egy NFS-t, jobb esetben ceph-et, vagy Java esetén megveszik a kígyóolajat hogy az XY appserver majd megoldja.

Azok találkoznak a skálázás problematikájával akik nagy terhelésű webes rendszereken dolgoznak, mert havi pár millió felhasználótól kezdve a "rendszergazda megoldja" csak korlátozottan megoldás, de még így is rengeteg startupot látok amelyek infrastuktúrája dölöngél, mert össze vissza van tákolva csak hogy valahogy működjön. Ehhez természetesen társul a 22 éves "CTO" megfelelően nagy arca, aki mindenféle javítási és stabilizálási javaslatra személyes támadással reagál.
17

Kérdések

Hidvégi Gábor · 2017. Aug. 4. (P), 10.10
A kérdés az, hogy a huszonnégy magos gép kilencvenhat gigabájt ramra való bővítés olcsóbb vagy drágább, mint a háttérben lévő technológiával varázsolni? Mennyire triviális az általad használt eszközökkel dolgozni? Mennyibe kerül az olyan programozó, aki ért is hozzájuk?

Ezek tényleg fontos kérdések.

Egy ismerősöm például egy Közép-európai szolgáltatás fejlesztésén dolgozik, rengeteg ügyféllel és hatalmas adatforgalommal, náluk például minden adatbázisírást egy MySQL szerver végez (az olvasás pedig replikálva van).

De ami engem igazán izgat, amire még nem kaptam választ (vagy nem voltam figyelmes), hogy mondjuk nálunk (vállalatirányítási rendszer) létfontosságú az adatok zárolása a kérés idejére, mert véletlenül sem fordulhat elő, hogy két, párhuzamosan indított kérés inkonzisztens állapotot hozzon létre, ezt a PHP beépített munkamenetkezelőjén kívül milyen alternatívával lehet megoldani? Mik a kulcsszavak, amin el lehet indulni?

Mi a munkamenetben akár megabájtos méretben is tárolunk adatokat. A tokenes cikked hatására viszont elkezdtem kiszervezni a dolgokat, ami szimulált terheléstesztnél növelte a reszponzivitást, de jelenleg egyébként nem okoz problémát.
18

Teljesen

janoszen · 2017. Aug. 4. (P), 10.11
Mennyire triviális az általad használt eszközökkel dolgozni? Mennyibe kerül az olyan programozó, aki ért is hozzájuk?


Az altalam hasznalt (Javas) technologiat szandekosan ugy terveztuk, hogy OOP-s kodot olvasni tudo PHP vagy Java programozo minden tovabbi nelkul bele tud vagni. Olyannyira, hogy a fonokom, aki csak nagyon korlatozott muszaki tudassal rendelkezik, kepes elolvasni es megerteni a kodot. Itt meg kell emlitenem, hogy szandekosan nem hasznaltam olyan Java-specifikus technologiakat amik egy PHP programozonak pl. idegenek, mert a cel az volt, hogy akar a Javas, akar a PHPs vilagbol is tudjunk felvenni embereket anelkul, hogy massziv problemakba utkoznenk.

Mutatok peldat az egyik sajat projektembol:
@API(
    name = "Authenticate",
    description = "Authenticate with username and password, and then return an access token that can be used in subsequent API Calls.",
    endpoint = "/access-tokens",
    method = "POST"
)
public AccessTokenApiCreateResponse authenticate(
    @APIField(name = "email") String email,
    @APIField(name = "password") String password,
    @APIField(name = "accept_tos") Boolean acceptTos
) throws AuthenticationFailedException, FieldValidationFailedException {
    ApiValidator apiValidator = new ApiValidator();
    apiValidator.validateRequired("email", email);
    apiValidator.validateEmail("email", email);
    apiValidator.validateRequired("password", password);
    apiValidator.validateMinimumLength(8, "password", password);
    apiValidator.validateRequired("accept_tos", acceptTos);
    apiValidator.process();

    User user = userBusinessLogic.authenticate(email, password);
    return new AccessTokenApiCreateResponse(
        user,
        accessTokenBusinessLogic.create(
            user.getId(),
            LocalDateTime.now().plus(24, ChronoUnit.HOURS)
        )
    );
}
Ez ele aztan tehetsz controllert ha szerver oldali renderelest szeretnel, de az annotaciok nyoman ez egy REST API-t biztosit, tehat JavaScriptbol kozvetlenul is hasznalhatod.

Adattarolasilag van egy egyszeru ORM mogotte, szoval ha van egy uj valami amit tarolni kell azt eleg konnyen meg lehet valositani. (Itt ORM alatt ne a Doctrine szintu overkillre gondolj, hanem inkabb query builder + betolto.)

A frontendesunk ettol a rendszertol nagyon boldog, mert egyreszt kap egy automatikusan generalt API doksit, masreszt nincs implicit state a szerver oldalon amit figyelembe kell vennie. Meghivja az API-t, ami a maga reszerol csak azt engedi meg ami uzletileg kivanatos es validalja neki az adatokat (a FieldValidationFailedException egy ertelmes, strukturalt hibaobjektumot ad vissza). Neki meg csak az urlap validaciot sem kell megepitenie, mert a szerver 30-60 ms-en belul ugyis valaszol. Sajat bevallasa szerint ritkan lat ennyire atlathatoan strukturalt rendszert.

Szerintem itt a megertes kulcsa az, hogy API-ket gondolsz az alkalmazasodra es nem MVC-kent, mert MVC strukturabol en eddig csak kuszasagot lattam kisulni.

Egy ismerősöm például egy Közép-európai szolgáltatás fejlesztésén dolgozik, rengeteg ügyféllel és hatalmas adatforgalommal, náluk például minden adatbázisírást egy MySQL szerver végez (az olvasás pedig replikálva van).


Ez esetben az ismerosod es csapata ugye tisztaban van azzal, hogy az olvasas adott esetben regi adatokat olvas? Ha igen, es ez nem problema, akkor nagyobb terheles eseten meg lehet nezni a CAP haromszogbol a CP helyett egy AP rendszert is, hiszen olvasasra igy is AP. (Eventual consistency)

De ami engem igazán izgat, amire még nem kaptam választ (vagy nem voltam figyelmes), hogy mondjuk nálunk (vállalatirányítási rendszer) létfontosságú az adatok zárolása a kérés idejére, mert véletlenül sem fordulhat elő, hogy két, párhuzamosan indított kérés inkonzisztens állapotot hozzon létre, ezt a PHP beépített munkamenetkezelőjén kívül milyen alternatívával lehet megoldani? Mik a kulcsszavak, amin el lehet indulni?


Nagyon nehez altalanossagban valaszolni, ez mindig a feladattol es a konkret uzleti kovetelmenyektol fugg. A zarolast bizonyos esetekben nem lehet elkerulni, de pl. a tranzakciok helyes hasznalata mar sokat tud javitani a helyzeten, illetve ez lehetove teszi azt, hogy ne csak egy gepen az adatbazis szerver (pl. Galera clusterrel). Itt erdemes figyelni arra, hogy milyen izolacios szintet hasznalsz az adatbazisnal. Ezen felul erdemes lehet bizonyos feladatokat queue-ba kiszervezni, nem kozvetlenul a request kapcsan feldolgozni.

Nezzunk egy konkret peldat. Legyen egy elszamolasi rendszer, ahol semmikeppen nem szeretnenk ha negativba menne a felhasznalo egyenlege (noha nagyon sok rendszer ezt nem teszi). Ez esetben hasznalhatsz pl. Galera clustert. A Galera cluster allhat 3 gepbol, es a tranzakcioban updatelheted a user egyenleget. Itt fontos az, hogy tenyleg ugyanaz a sor legyen updatelve. Az update soran ha parhuzamosan hajtodik vegre, a commit kiadasakor egy deadlock hibat fogsz kapni. Ezt ha kodbol lekezeled, ujra tudod futtatni a feldolgozast, vagy vissza tudod dobni a felhasznalonak a hibat. Ezen modszer elonye az, hogy van 3 geped, es a MySQL replikacioval ellentetben mindig konzisztensek lesznek az adataid.

Ez persze nem idealis, sokkal jobb ha az uzleti logikat meg lehet egy kicsit hajlitani.

Egyebkent nekem a szemelyes tapasztalatom az, hogy meg akik hasznalnak is tranzakciokat, ritnak tudjak fejbol felemlegetni az izolacios szinteket, szoval lehet hogy nem is volt olyan fontos az abszolut es 1000%-os lockolas. Sok esetben az is elegendo, ha az olyan adatokat amiket egyutt updatelunk egy helyen tarolunk, es azokat amiket kulon updatelunk, kulon tarolunk.
28

létfontosságú az adatok

BlaZe · 2017. Aug. 5. (Szo), 08.58
létfontosságú az adatok zárolása a kérés idejére, mert véletlenül sem fordulhat elő, hogy két, párhuzamosan indított kérés inkonzisztens állapotot hozzon létre, ezt a PHP beépített munkamenetkezelőjén kívül milyen alternatívával lehet megoldani? Mik a kulcsszavak, amin el lehet indulni?
A leírás alapján 2 dolgot fontolnék meg:
1) A lock granularitásának csökkentése (nem az egész request sorosítása, lásd critical section fogalma)
2) Requestek particionálása pl userid alapján workerekre, dedikált 1 consumeres queue-n keresztül. Így egyáltalán nincs szükség lockolásra a business logicban, mert a design nem enged konkurens hozzáférést.

A kettes jobb párhuzamosíthatóságot biztosít, valamivel komplexebb infrastruktúra mellett, alacsonyabb (megoldástól függően) válaszidőkkel, főleg a tail latency értékekre (hisz nincs contention, illetve csak minimális a queue-ba írásnál).

Az egyes megoldás meg egyszerűbb, csak egy distributed lock kell jó helyre, vagy ha 1 gépről van szó, akkor valami gépen belüli shared lock is működhet. Ha csak a request végén írtok az outputra, ezt utóbbi esetben megteheti a session_start hátrább mozgatása csak a business logic köré. De én arra nem építenék, mert a session lockolása valójában nem egy contractja a sessionnek.

Esetedben inkább az egyest választanám. Akkor is akár, ha nincs teljesítmény gondotok, mert segít pl a kódszervezésben is.

Kicsit bővebben írtam az alapokról a cikkben, ami itt végül nem jelent meg. Ha úgy gondolod janoszen, eldobom neked. Ha úgy találod, menjen refaktorra, ha még foglalkozol az oldallal. Vagy kirakom ide fórum témának. Guglidocsban írtam (bruttó 19 oldal), de bbcode-ba beszerkesztve is megvan.
30

Johet

janoszen · 2017. Aug. 5. (Szo), 09.33
Hatalmas +1.

Cikk: Johet minden content, a beszerkesztes nem tul nagy melo, azt megcsinalom en. Ha hosszu, max tobb reszre bontjuk. Sztem folytassuk privatban ;)
31

Ment

BlaZe · 2017. Aug. 5. (Szo), 12.02
Eldobtam refaktor szerkre.
36

Második

Hidvégi Gábor · 2017. Aug. 6. (V), 18.22
Oké, át kell gondolnom a dolgokat. A mi rendszerünkben, már más céllal, de a kettes pont van megvalósítva.

Viszont, mivel nálunk a rendszer alapvető működése az, hogy egy felhasználótól egyszerre csak egy kérés érkezik, igazából nem tudom, milyen problémát tud okozni az, hogy az adott felhasználó miatt egy darab egyedi fájl ötven - négyszáz ezredmásodpercre le van zárolva? Nincsenek hosszú folyamatok, a feldolgozási idő nagy része az adatbázisra való várással megy el.
37

Semmit

janoszen · 2017. Aug. 6. (V), 21.06
Semmilyen problemat nem okoz HA a zarolas jol van megvalositva. Viszont kockazat van benne, hiszen most a te fejedben megvan, hogy erre a lockolasra szukseg van. Ha te egyszer elmesz a cegtol, vagy elfelejted, mas valaki atallitja a sessionoket mondjuk memcache-re, akkor jonnek a meglepetesek. Eppen ezert a lockolas jobb ha explicit modon benne van a kodban. Itt eleg ha a session kezeloben megfeleloen el vannak nevezve a dolgok (pl. saveAndReleaseLock), es explicit modon benne van a kodban a lockolas a PHP-ba beepitett implicit lockolas helyett. Az sem feltetlenul baj, ha a lockolas es a session nem file-alapon van megvalositva, hiszen ha egy rendszergazda a jovoben ugy gondolja hogy egy lockolas nelkuli filerendszert rak ala, ne tortenjenek debugolhatatlan fura hibak.
38

Dokumentáció

Hidvégi Gábor · 2017. Aug. 7. (H), 09.32
Utánajárok majd az adatbázis alapú munkameneteknek, de egyelőre ez jó így. Igazad van, a zárolást beleveszem a dokumentációba, hogy ne forduljon elő, amit írtál.

Viszont ezek után felmerülhet a kérdés, hogy ha nekünk sikerült megoldani, hogy a zárolás ne okozzon gondot a skálázódásnál, akkor azt mások is meg tudják-e valósítani? Mert szerintem az esetek túlnyomó többségében ez kivitelezhető.
39

Bele fogsz futni

janoszen · 2017. Aug. 7. (H), 10.08
O, nagyon sokaig eleg lesz a zarolos megoldas. Ha csak a kapacitas novelese a cel, akkor ezzel el tudsz menni akar par tucat gepig is akar.

Akkor lesznek problemaid ha redundans setupot szeretnel automatikus failoverrel. Jatszhatsz master-masterrel elotte levo load balancerrel, de ott failoverkor keletkezhet key clashing, ami miatt leallhat a replikacio, illetve failoverkor elveszik a lock. Ha ezzel szemben pl. Galerat szeretnel hasznalni, ott azonnal dobhatod ki a lockolos mokat mert a Galera nem tamogatja a SELECT..FOR UPDATE mukodest.

Vagy ha filerendszer alapu sessionoket hasznalsz, akkor kulon kuzdes lesz az egesz ala tenni performans cluster filerendszert ami irasra es olvasasra is ertelmes sebesseget produkal. A filerendszer lassusaga mindenfele nehezen debugolhato performance issue-t tud okozni, es a cluster filerendszerek karbanartasa, kulonosen nagyobb terheles eseten, nem trivialis.

Persze hasznalhatsz a load balancerben sticky sessionoket is hogy mindig egy backendre menjen egy adott session, de ennek megvannak a sajat problemai, mint pl. hogy konnyen elofordulhat a "feloldalas" terheles, illetve ha leallitod az egyik backendet, az azon levo sessionok repulnek.
40

Messze

Hidvégi Gábor · 2017. Aug. 7. (H), 10.31
Bár itt tartanánk! De ezektől annyira nem félek, mert a rendszerünk jellegéből adódóan rendkívül könnyen shardolható minden szempontból, külön php/adatbázisszervert tudunk rendelni akár minden egyes előfizetőhöz (egy-egy előfizetőnek akárhány egyéni felhasználója lehet). Szolgálunk ki fájlokat is, de elenyésző mennyiségben, ez sem lesz probléma.

Egyébként postgresql-t használunk a licensze miatt, és ha szükséges, áttérünk postgresql XL-re.

A redundáns setup automatikus failoverrel érdekes téma, majd utánaolvasok. Jobban belegondolva itt jöhet elő a probléma a fájlrendszer alapú munkamenetekkel.
19

Dehogynem találkoznak. A JMS,

BlaZe · 2017. Aug. 4. (P), 13.30
Dehogynem találkoznak. A JMS, a Remote EJB az EE-ben, az ESB-k stb mind találkozik a (horizontális) skálázással. Ezeket pedig a legtöbb Javas fejlesztő használja, használta már. Még ha ennek nincsenek is a fejlesztők tudatában. Vagy ami még rosszabb, az architect sincs, ahogy írod is. De még egy layered architektúra esetén is előkerül a téma, amin a legtöbb Java fejlesztő dolgozik. Nyilván van kivétel, én is tudnék hozni. De érdemes felmenni professionre, linkedinre, flexjobsra stb, hogy milyen skillekkel keresnek embereket. Jelentős százalékban nem kilóra mért Java fejlesztőt keresnek.

Úgy általánosságban szerintem kicsit félre van értve a skálázás fogalma ebben a szálban. Ha 2 gépen tudsz tolni valamit, akkor azt skáláztad 2 gépre. Vagy tudod 1000 gépre skálázni. Nyilván a 2 dolog teljesen más architekturát igényel. Én kimondottan nem a másodikra gondoltam.

Ha alá raksz egy nagyobb vasat, akkor is skáláztad (már ha az segít).

De még egyszer, ami az én eredeti állításom volt: a rendszernek mindig többet kell bírjon, mint amit kap. Ha nem így van, akkor jön a dőlés-borulás a 22 éves CTO-val együtt, amit írtál is.

Valamint a scalability és a load tolerance tulajdonságai egy architektúrának, aminek megfontolásával érdemes architektúrát választani. A lényeg, hogy ennek tudatosnak kell legyen, és a businesst kell támogassa (itt kell figyelembe venni a business goalokat), nem a fejlesztőt/architectet.

Egy szó mint száz, nem ugyanarról beszéltünk szerintem.
20

JMS,...

janoszen · 2017. Aug. 4. (P), 16.03
Sztem mi nagyon eltero fajta fejlesztokkel talalkozunk. Azokra a rendszerekre amit en latok jellemzoen a "dumpsterfire" a legjobb kifejezes. Ha hasznal is JMS-t, Remote EJB-t vagy egyeb fancy technologiat, a rendszert maximum egy gepen fejleszti, soha meg sem fordul a fejeben hogy ezt utana uzemeltetni is kell valakinek, es siman ugy irja meg a kodot hogy a synchronized az egyetlen lockolas, ha egyaltalan. Ha utana jelzed a problemat az illeto "fejlesztonek", akkor Te vagy a hibas uzemeltetesi oldalrol mert neki helyben mukodik es marpedig oldd meg. A legtobb rendszer amit latok az viszont default telepitesu Spring csomo kokannyal, nyers servletek, JSP, Symfony agyontakolva modulokkal vagy CodeIgniter (yay) es tobbnyire senki nem tudja hogy hogyan mukodik vagy mi az elvaras uzleti oldalrol a mukodes tekinteteben.
23

Jól hangzik. :D

inf · 2017. Aug. 4. (P), 22.53
Jól hangzik. :D
24

Valóban, nagyon szerencsés

BlaZe · 2017. Aug. 5. (Szo), 00.29
Valóban, nagyon szerencsés vagyok a kollégáimmal szakmailag és emberileg egyaránt :) De amit írtál, abban teljesen egyetértünk. Én se azt mondtam, hogy tisztában vannak vele a fejlesztők, hanem hogy találkoznak vele (max nem ismerik fel).

Szoktam én is elképedni interjúkon, amikor azt mondják, hogy a fejlesztői gép után mehet prodra, mert tesztelve volt. De persze, nincs minden cégnek kerete fenntartani párhuzamos rendszereket tesztelésre. Az tény, hogy ebben pl nagyon nem mindegy milyen helyen dolgozik az ember. Nálunk pl több szintű dev, qa, perf, uat stb rendszereken megy át minden, mielőtt kiérne prodra. Plusz komolyan monitorozzák és supportálják a devek is a rendszerünket ezeken a környezeteken, hogy egyrészt elkapjuk az esetleges bugokat, másrészt hogy megtanuljuk hogy néz ki üzemeltetői oldalról a rendszerünk. De ez persze nem általános, ilyen szinten ezt én se láttam korábbi projetjeimen. Csak 1-2 környezet volt, vagy az sem. Ez nyilvánvalóan nagyon nincs ingyen. Meg nem is mindenki szereti, sokan a falra másznak a devopsos munkától. Pedig belenevel az emberbe egy kis fegyelmet :)
25

Tök jó, szerintem legalább

inf · 2017. Aug. 5. (Szo), 00.56
Tök jó, szerintem legalább alap szinten azért érteni kellene minden backend-esnek az üzemeltetéshez. Én is most tanulgatom önszorgalomból.
27

Jelen allas

janoszen · 2017. Aug. 5. (Szo), 02.05
Jelen allas szerint az uzemeltetok egy jelentos resze sem ert az uzemelteteshez. Just sayin' :)
33

Mindenhol azt sulykolják,

inf · 2017. Aug. 5. (Szo), 15.41
Mindenhol azt sulykolják, hogy az a siker titka, ha szakosodsz valamire, aztán abból olyan szintig képzed magad, ami fizikailag lehetséges, semmi mással meg nem szabad foglalkozni, mert azzal csak az energiádat pazarlod. Nekem valahogy nem jön be ez a fajta szűk látókörűséget propagáló filozófia, meg szerintem káros is a társadalomra hosszú távon, mert hátráltatja a kommunikációt a szakemberek között.
34

Alapvetően arról van szó,

BlaZe · 2017. Aug. 5. (Szo), 21.12
Alapvetően arról van szó, hogy megoldást szállítunk megrendelőknek a problémáikra. Ha éles határokat szabunk funkciók között (pl tesztelő-programozó, üzemeltető-programozó, programozó-BA), akkor lesz, ami a két világ között reked. Ezért működő megoldás szállításához muszáj kicsit több sapkával is megnézni egy feladatot.

Szoktam olvasni, hallani itt-ott, hogy a megrendelő motivációjának és a folyamatoknak a megértése a BA feladata. Hát... a BA írja a kódot? Ki fog döntést hozni az implementációval kapcsolatban? Hogy ismerné fel a BA, hogy épp csúszik félre egy feature implementációja?

De ugyanez üzemeltetésnél is. Az egyik legjobb példa, ami nálunk előkerül, az a logolás, alertelés. Megírjuk az üzenetet, kódból nézve értelmes. Aztán meglátjuk a monitoring toolban, vagy nyomozunk valamit... és akkor vissza kell menni javítani :)
35

Én is így látom, ha két ember

inf · 2017. Aug. 6. (V), 04.03
Én is így látom, ha két ember nem érti egymás szakterületét, akkor nem fog menni a kommunikáció közöttük, és a projekt vagy kudarcba fullad, vagy selejtes eredményt fog adni. Egyébként az ilyen jellegű problémákat elég jól jelzik az ilyen határterületi szakok, mint pl: műszaki menedzser. Tulképp ezek a szakok nem is feltétlen arról szólnak, hogy egyik vagy másik szakterületen a tudást a legkomolyabb szintig elvigyék, hanem inkább arról, hogy biztosítsák a kommunikációt a két szakterület nagyobb tudású tagjai között. Ha kisebb a hézag, akkor persze nem feltétlen kell külön ember az áthidalására.
21

(Az emag tudtommal román.)

inf · 2017. Aug. 4. (P), 22.36
(Az emag tudtommal román.)
10

Attol fugg

janoszen · 2017. Aug. 2. (Sze), 21.48
Attol fugg. En eleve ugy epitem meg az alkalmazasaimat mert pont ugyanannyi energiaba kerul NEKEM. Viszont olyannak aki meg soha nem csinalt ilyet, rengeteg energia. Ilyenkor szokott az lenni, hogy jol megtervezik elore hogy mit hogy fognak clusterezni, milyen csoda failover rendszer lesz, de azert szeretnenek lockolni es sessionoket hasznalni es lehetoleg FTP hozzaferest a szerverhez.
2

Skálázódás

janoszen · 2017. Júl. 23. (V), 17.26
Ha PHP-t használsz, a több szerverre skálázódásnak van néhány alapvető szabálya. Ha betartod őket, akkor meglepően nagy méretekre nőhet a rendszer.

- Ne tárolj fájlokat helyi fájlrendszeren. Ez annyira meg tud szivatni, hogy még. Az S3 és társai filléres összegekbe kerülnek.
- Ha sessionöket használsz, írd DB-be őket.
- Ha DB-t használsz, készülj fel arra, hogy más szerverről olvasol mint írsz.
- Legyen egy tisztességes deploy rendszered (pl. deployer-rel).
- Ha lehet, kerüld el a soktáblás SQL queryket és a vastag ORM-eket, mert ezek meg fogják akadályozni, hogy bizonyos feladatokra átállj nem relációs adatbázisokra.

Ezek szinte triviális dolgok, ha idejében gondolsz rá, de hihetetlen szívás mennyiség ha nem gondolsz rá.
3

Továbbiak

Hidvégi Gábor · 2017. Júl. 24. (H), 09.32
A fájlok problémáját kicsit jobban is kifejthetnéd. A munkamenetek adatbázisban való tárolása esetén pedig a zárolást kézzel kell lefejleszteni, ami nem feltétlenül triviális feladat.
4

Fájlok

janoszen · 2017. Júl. 24. (H), 14.00
OK, szóval a fájlok problémája:

Ha több mint egy gépen fut a rendszered, akkor nincs jelenleg olyan technológia ami egy mappát automatikusan minden gépen láthatóvá tesz és úgy működik mint egy helyi fájlrendszer. Vagyis még ha használsz is valamilyen cluster filerendszert, ami önmagában problémás, nehezen konfigurálható és monitorozható, stb., akkor is bele fogsz futni olyan problémákba, mint hogy nem lesz zárolás, stb. A cluster filerendszerek, mint olyan, kerülendő technológia, hacsak nincs az embernek egy 4-5 fős üzemeltetői csapata 0-24 ügyeletre, de még akkor is érdemes jól megfontolni.

Sokkal egyszerűbb az adatokat egy objektum adatbázisba tenni, ezek ugyanis nem támogatják a klasszikus fájlrendszer szemantikákat (részleges olvasás, stb), ezek sokkal egyszerűbb, kevésbé hibaérzékeny rendszerek.

Ami a munkameneteket illeti, igen, igazad van, éppen ezért érdemes megfontolni a teljes elfelejtésüket és nem mindent belepakolni egy zsákba. Erről itt írtam: http://weblabor.hu/cikkek/sessionmentes-weboldalak Ez persze gondolkodást és odafigyelést igényel, nem lehet "főtesszük a szimfonit és majd két hét alatt készen leszünk" módszerrel fejleszteni.
6

clusterFS?

hóhér · 2017. Júl. 25. (K), 08.24
Ezen kiakadtam... a mai napig nincs linuxra normálisan használható clusteres fájlrendszer?? A Tru64 kimaradt az életemből, nem tudom, oda a VMS clusterből mennyit portoltak, de életem első VMS-én, ami úgy rémlik, 5.5-2H1 vagy H4 volt, már tökéletesen működő, lokálisnak látszó fájlrendszer volt. (Min. húsz éve, de már akkor sem volt újdonság)
Ennyire nincs rá szükség?
Vagy ennyire le van maradva a világ ezen része a VMS mögött?
7

Nem

janoszen · 2017. Júl. 25. (K), 10.28
Nem arrol van szo, hogy nincs normalis cluster filerendszer, mert van. GlusterFS, CEPH, stb. eleg jol mukodik. A problema az, hogy KIBA bonyolult a konfiguralasuk, rengeteg eroforrast esznek es egy nativ SSD-hez kepest lassuak. Ennek az az oka, hogy olyan POSIX szemantikakat kell biztositaniuk, hogy pl. ket folyamat ket kulonbozo szerveren tudjon ugyanabba a fileba irni es ez ugy mukodjon mintha helyben lenne. Vagyis blokk-szinten szinkronizalni kell a storage backenddel, es nem ez az egyetlen problema.

Nem mennek bele az osszes reszletbe, mert akkor itt ulunk holnapig. A lenyeg az, hogy alkalmazas fejlesztokent sok fajdalomtol tudod megkimelni magad, ha nem arra apellalsz hogy majd lesz egy POSIX-compliant filerendszer alattad.
5

Sokszor a legegyszerűbb lehet

smokey · 2017. Júl. 24. (H), 18.18
Sokszor a legegyszerűbb lehet a szerveroldalon a hardverelemek jobbra, gyorsabbra cserélése, a memória bővítése például jótékony hatással van mindenre: az operációs rendszer vagy az adatbázisszerver többmindent tud gyorsítótárazni, de ugyanígy a merevlemezek cseréje SSD-re is jelentősen javíthat a válaszidőkön.


Az a gond, hogy a vertikális skálázódással nagyon nehéz azonnal reagálni egy pillanatnyi túlterheltségre. Most kell, 64 mag és 1 tb memória, holnap már nem.

Horizontálisan, felhőben, megfelelő konfig mellett simán észre sem kéne venni, hogy 10 000 helyett 500 000 kliens kéreget.