Amikor a skálázás nem a megoldás

A csapat a horizontális skálázást tekintette a következő logikus lépésnek. A rendszert skálázott környezetben még nem üzemeltették, és az alaparchitektúrát sem ellenőrizték ilyen terhelésre. Teljesítménymérnöki szempontból ez visszatérő aggály: egy nem kellően megértett rendszer skálázása inkább felerősíti a problémákat, mint megoldja őket.

Az első javaslat ezért egyszerű volt. Ne a horizontális skálázással kezdjenek. Ha egyáltalán kell skálázni, a vertikális skálázás általában a biztonságosabb és kontrolláltabb lépés, különösen akkor, ha a rendszer viselkedését még nem értik teljesen. A megbízás lényege azonban nem ez volt, hanem annak megértése, hogyan viselkedik a rendszer már mérsékelt terhelésnél is.

Egy rövid, célzott egyeztetés és az első elemzés után kiderült, hogy a probléma nem a párhuzamosságban vagy az infrastruktúra kapacitásában rejlik. A rendszer már alacsony terhelésen is teljesítményproblémát mutatott. A PostgreSQL-adatbázisban szűk keresztmetszetek voltak. A lekérdezések viselkedését nem értették kellően, az éles observability pedig gyakorlatilag hiányzott: a csapatnak csak részleges naplózás állt rendelkezésére. Ilyen korlátozott láthatóság mellett nem látták tisztán, mi történik a rendszer belsejében.

A közelebbi vizsgálat során kiderült, hogy a kiváltó ok az adatelérésben rejlik, nem a párhuzamos felhasználók számában. Több lekérdezés nem volt jól megírva, az indexeket nem használták ki megfelelően, és egyes adatbázis-interakciók egyszerűen nem voltak hatékonyak. Egyszerű eszközök segítettek megérteni, hogyan futnak le a lekérdezések, így viszonylag kis erőfeszítéssel kiderültek a problémás SQL-minták és a szűk keresztmetszetek. A gond nem a skálázás volt, hanem a nem hatékony működés és a láthatóság hiánya.

A skálázási stratégiák vitatása helyett a rendszer viselkedésének megértésére tereltük az egyeztetést. Azonnali betekintést adó gyakorlati lépés volt az alapvető tracing és az adatbázisszintű láthatóság bevezetése, valamint a PostgreSQL-ből közvetlenül kinyerhető teljesítményinformáció használata. Megbeszéltük a későbbi tesztelési lehetőségeket is, például a kontrollált benchmarkolást (pl. a pgbench segítségével). Hamar kiderült, hogy mélyebb, lekérdezésszintű elemzésre van szükség, mielőtt bármilyen infrastruktúra-módosítás indokolt lenne.

Ez a szemléletváltás azért fontos, mert sok csapat bizonyítékok híján a kapacitás növeléséhez nyúl. Ha nem válaszolunk néhány alapkérdésre, a skálázás gyakran drága találgatás. Ilyen kérdés, hogyan viselkedik a rendszer terhelés alatt, hol telik el valójában az idő, és mi a valódi szűk keresztmetszet.

Az egyeztetés természetes módon terelődött az azonnali javításról a hosszabb távú képességek kialakítására. Megbeszéltük, hogyan építhető be a teljesítménymérnökség korábban és következetesebben a fejlesztési folyamatba. Szóba kerültek a teljesítménnyel kapcsolatos minőségi kapuk, a teljesítmény ellenőrzése egyfelhasználós szinten a fejlesztés elején, az egyszerű profilozás és elemzés a skálázási döntések előtt, valamint a teljesítmény közös felelőssége a csapatok között. A cél nem egy bonyolult új folyamat bevezetése volt, hanem az, hogy a jobb döntések korábban szülessenek meg, és a következő „skáláznunk kell” vita bizonyítékokból induljon ki, ne feltevésekből.

Az egész megbízás csak néhány órát vett igénybe, a hatása mégis jelentős volt. A csapat elkerülte az idő előtti és potenciálisan költséges skálázást. Azonosította a valódi műszaki szűk keresztmetszeteket, jobban megértette a rendszer viselkedését, és világos, megvalósítható következő lépéseket határozott meg.

Az eset egy gyakran visszatérő mintát mutat: sok teljesítményprobléma valójában nem skálázási, hanem megértési probléma. A teljesítménymérnökség nemcsak eszközökről, terhelésről vagy infrastruktúráról szól. Arról is szól, hogy a rendszer alaposabb megértésével jobb döntések szülessenek. Sok esetben egy rövid, célzott tanácsadói egyeztetés is elég ehhez a megértéshez. Ez később sokkal nagyobb problémáktól is megóvhat.