Mongúz méretezése: Mennyire méretezhető a MongooseIM XMPP szerver?

Hogyan skálázza a MongooseIM?

Ha szerverekről beszélünk, ezt a kérdést újra és újra felteszik, és a MongooseIM sem kivétel. Hogyan skálázódik? Jól skálázódik, ezt tudjuk. Sok terhelési tesztet végeztünk különböző környezetekben, több gyártási fürtöt hoztunk létre, amelyek közül néhány jelentős terhelést kezel. De, pontosabban, hogyan skálázódik?

Nehéz kérdés, és alapos átlátást igényel (soha ne mondd, hogy egy tévéinterjúban ez a lehető legrosszabb válasz). De valójában az. Olyan sok tényezőtől függ - mögöttes hardver, használati minta, engedélyezett kiterjesztések, adatbázis háttér, integrációk ... Szeretnénk, ha határozott választ adnánk a kérdésre, de ez még lehetséges is?

215 km/h
Ez az, amit az autóm specifikációja szerint a maximális sebessége jelent. Ez azt jelenti, hogy ilyen gyorsan képes vagyok vezetni? Először is nem, mert nem fogom megpróbálni. Még akkor is, ha sikerülne, különféle okokból biztosan nem fogok eljutni - az autó nem teljesen új, a vezetési körülmények soha nem tökéletesek, rendszeres gumiabroncsaim vannak, amelyeket a biztonság és nem a gyorshajtás stb. A gyártó valóban azt állítja, hogy (a) ennél gyorsabban nem megy, bármit is csinál, és (b) valami 180 km/h teljesen rendben van (ha törvényes).

Kövessük tehát ezt a megközelítést, és derítsük ki, mi a MongooseIM „végsebessége”. Útközben azt is megvizsgáljuk, hogyan viselkedik, amikor kibővítjük a hardvert vízszintesen és függőlegesen, mi korlátozza a növekedést, és néhány más érdekes szempontot.

Beállít

Tesztjeinket AWS-en futtattuk - ez a leggyakrabban használt általános célú felhőkörnyezet. Az onnan származó eredmények referenciaértékként szolgálhatnak. Egy választható szkriptkészlet biztosított egy EC2 példányt, telepítette és konfigurálta a MongooseIM-et. Ezután egyenként elindítottuk az „ügyfél” EC2 példányokat, mindegyik létrehozott egy sor XMPP kapcsolatot, úgy hogy valós ügyfeleknek tettette ki magát. Addig folytattuk, amíg az új kapcsolatok meghibásodtak, vagy a kézbesítés vége-vége fel nem merült, majd az egész tesztet leállítottuk.

A MongooseIM szerver „sima vanília” volt - a cél csak a főbb funkciók tesztelése volt, például a kapcsolatok kezelése és az üzenetek továbbítása. Ha egy kiszolgálófürtöt használnak, az ügyfelek véletlenszerűen csatlakoznak bármelyik elérhető csomóponthoz - nem volt terheléselosztó, amely akadályozta.
Az ügyfelek viselkedése szintén kezdetleges volt - egyetlen „kliens” létrehozta az adatfolyamot, hitelesítette, majd nyitva tartotta a kapcsolatokat, percenként egy rövid üzenetet küldött és megkapta a beérkezett üzeneteket. Az üzenetek időbélyegeket tartalmaztak, hogy végponttól végig nyomon kövessük szállítási idő.

Az első eredmények

Példánytípusok

Miután számos példánytípussal kísérleteztünk, kiderült, hogy a c5 vonal tökéletes egyensúly. Feltételezett használati mintázatunkkal ez a hardverprofil a memória és a CPU teljesítményének megfelelő kombinációját biztosítja. A memóriára optimalizált, hasonló méretű példányok hasonló teljesítményt kínálnak, ugyanakkor sokkal drágábbak - a memória növelésével nem lehet sokat nyerni. Emellett a memóriára optimalizált példányok futtatásának eredményei instabilak voltak, mivel a MongooseIM CPU-használatának sok csúcsa volt, ami bármikor megszakíthatja a teszteket. Íme néhány példa:

Üzenetek gyakorisága

Képzeletbeli átlagos felhasználónk percenként egy üzenetet küld - 137 ezer kapcsolattal a c5.l nagy példányon, ez azt jelenti, hogy a MongooseIM körülbelül 2,3k üzenetet irányít másodpercenként. Mi van, ha a felhasználóink aktívabbá vagy kevésbé aktívvá válnak - hogyan változtatja meg a maximálisan terhelhető terhelést?

A kevesebb üzenet azt jelenti, hogy a CPU-nak kevesebb munkája van, de a memória nyomása ugyanaz marad. Az elvárás tehát az, hogy amikor alacsony a forgalom, a kapcsolatok maximális száma nem függhet a forgalomtól. Ugyanis ebben a forgatókönyvben a memória a korlátozó tényező. Másrészt, ha a terhelés növekszik, akkor valamikor meg kell terhelnie a CPU-t, és a kapcsolatok maximális száma csökkenni kezd.

Tesztjeink ezt megerősítették, és azt is bebizonyították, hogy a percenként egy üzenet alapértelmezett használati mintája csak a töréspontról szól. Alatta a határ ugyanaz marad. Menjen kissé fölé, és a határ csökkenni kezd.

A méretezhetőség tesztelése két dimenzión

Függőleges

Most, hogy tudjuk, hogy a c5 vonal tökéletes egyensúlyt biztosít, hogyan segíthet egy erősebb változat használata? Megint lineáris? Vajon az „x” betű előtti szám duplázása valóban megduplázza-e a terhelést? Van-e rajta korlát?

Ez bonyolult volt, mert sok operációs rendszer-korlátozás és Erlang virtuális gép-beállítás létezik, amelyek megakadályozhatják a csomópont további kapcsolatok elfogadását. A szerverek konfigurálásával kapcsolatos részletekért tekintse meg az online elérhető MongooseIM dokumentációt.

Tesztünket nagyobb példánytípusokon futtattuk, c5.9xlarge-ig. Ezen a szinten a MongooseIM csaknem 2,5 millió kapcsolatot tudott kezelni, másodpercenként 45 ezer üzenetet továbbítva. És nem találtak problémát, ezért úgy tűnik, hogy nincs igazi kemény határ. Mivel azonban ez már jóval több volt, mint amire törekedtünk, és ezeknek a teszteknek a lefuttatása jelentős költségekkel jár, mind idő, mind pénz tekintetében, úgy döntöttünk, hogy itt állunk meg. Ez még nem a vége, de valószínű, hogy valamikor megpróbáljuk még tovább tolni.

Vízszintes

Hogyan skálázódik vízszintesen a MongooseIM? Lineáris, és ha igen, hány felhasználót tud kezelni egy új csomópont? Skálázhatunk végtelenül, vagy van-e olyan határ, amely felett csökkenő hozamok vagy akár kudarcok vannak? Meg akartuk tudni, és ez volt a legidőigényesebb része az egész kutatásnak.

A MongooseIM klasztereket c5.nagy példányokon állítottuk össze és stresszteszteltük őket, amíg kudarcot vallottak. Folytattuk és folytattuk, és a méretezés szinte lineáris volt, a vonal meredeksége körülbelül 51 ezerrel ingadozott (vagyis minden új csomópont 51 ezer kapcsolattal növelte a klaszter képességét, a lehallgatás körülbelül 80 ezer).

És így ment, amíg el nem értünk tizenöt csomópontot, több mint 1,2 millió felhasználóval és másodpercenként 22 ezer üzenettel, korlát nem volt látható. Ezen a ponton úgy döntöttünk, hogy előreugrunk és megpróbálunk húsz csomópontot. Ez túl soknak bizonyult. A csomópontok közötti kapcsolatok időnként időzítettek voltak, ami hálókat és inkonzisztenciákat okozott a Mnesia adatbázisban, és a klaszter alapvetően nem működött.

Ennek oka a Mnesia és általánosabban az Erlang terjesztés működése. Minden fürtözött Erlang-csomópont aktív kapcsolatokat tart fenn az összes többi csomóponttal, így a kapcsolatok száma egyre nagyobb ütemben növekszik. Húsz csomópont mellett már 190 kapcsolat volt az adatok fenntartására és cseréjére.

A MongooseIM felhasználói munkameneteit a Mnesia adatbázisban tárolják, amelyet az összes csomópontra replikálnak, hogy mindig szigorú konzisztenciát biztosítsanak. Ezután minden új kapcsolat elindít egy replikációs mechanizmust, amely átfogja az összes csomópontot és esetleg az összes internódus kapcsolatot. Ennyi csomópont esetén a forgalom meglehetősen jelentőssé válhat, nem csoda, ha instabillá válik.

Miért nem mindkettő?

Mivel a függőleges skálázhatóságban nem találtunk korlátot, és a vízszintes fürtözés lineáris (ésszerű számú csomópontig), akkor a kettő kombinálásával számíthattunk arra, hogy valóban nagy számokat tudunk kezelni - abból, amit tudunk eddig tízmillió jól elérhető. A költségeket figyelembe véve úgy döntöttünk, hogy ezen a ponton leállítjuk a terhelési teszteket. Ennek az útnak a feltárása a jövő egyik lehetősége.

Végül, de nem utolsósorban mennyibe kerül egy MongooseIM futtatása, és hogyan működnek költségesen a különféle klaszterezési stratégiák? Mivel a vízszintes méretezés lineáris egy rögzített alkatrésszel, egy kisebb fürt futtatása valamivel költséghatékonyabb, mint a csomópontok számának bővítése.

A vertikális méretezés viszont majdnem pontosan arányos - az AWS árlistája úgy van kialakítva, hogy egy kétszer drágább példány szinte pontosan kétszer több kliens kapcsolatot kezelhet.

A gazdasági klaszterek alapszabálya a következő lenne: készítsen négy vagy öt csomópontból álló klasztert, és szükség esetén függőlegesen méretezzen. És itt meg kell ismételnünk, hogy a testreszabott szerver tényleges eredményei a saját felhasználási szokásaik szerint nagyban eltérhetnek. Ne feledje azt is, hogy a való életben nem csak a MongooseIM-et kell méreteznie. Az adatbázis-háttérképeknek vagy más külső szolgáltatásoknak, amelyeket általában az összes példány megoszt, saját méretezési mintázatuk és árazásuk van.

Harmadik dimenzió - szövetség

Ha a terhelést nehéz kezelni egyetlen fürtnél, akkor ezen túl is léphet - nincs olyan szabály, amely szerint minden felhasználónak ugyanazt az adatközpontot kell használnia. Az összevonással több adatközpontot hozhat létre, mindegyiket a saját tartományuk alatt, így megsokszorozva az egész rendszer által kezelhető lehetséges terhelést. Ez azt is jelentené, hogy a szervereit közelebb hozza a földrajzilag elosztott felhasználásához. A Föderációnak is megvannak a sajátosságai, de ez meghaladja a cikk kereteit (valószínű, hogy a jövőben visszatérünk rá a jövőben).