Fontos: a skálázódás nem azt jelenti, hogy az oldalad minél kevesebb milliszekundum alatt szolgálódjon ki, nem arról van szó, hogy minél gyorsabb legyen. Egy csak teljesítményre optimalizált oldalnál óhatatlanul lesz egy plafon, aminél több látogatót egy időben nem fogsz tudni kiszolgálni.

A skálázódás azt jelenti, hogy egy ésszerű, de nagyon tág határon belül bármilyen terhelést képes vagy kezelni és kb. ugyanolyan (gyors) válaszidőket produkálni. Sok az átfedés a teljesítményre (gyorsaságra) optimalizálással, de nem teljesen ugyanaz.

Ökölszabályként azt javaslom, hogyha eléred a "szempillantás" sebességet (> 0.1s), akkor utána gondolj a skálázódásra és csak aztán próbálj meg még lejjebb menni (jellemzően > 0.01s lenne ideális), hogy minél kevesebb legyen a szerverköltség.

Természetesen mindig gondolj a célcsoportra és így a várható terhelésre, ahhoz lődd be az ügyet. Pölö hazai projekteknél általában elég teljesítményre gyúrni, nem kell skálázgatni.

Ma

Ma ott tartunk, hogy a proci, tárhely és memória költsége nagyon olcsó, újabb és újabb (jellemzően virtuális) szervereket olcsón lehet indítani. A legtöbb területen viszonylag egyszerű, kész megoldások állnak rendelkezésre, például:

Alkalmazás-kiszolgálókat (PHP, Rails, satöbbi) könnyű indítani és nincs skálázódási gond, hiszen mind ugyanazt csinálja. A terhelés-elosztásra egész jó load-balancerek vannak. Statikus fájlokat könnyű kiszolgálni, gondoljunk csak az S3-ra az Amazontól.

A legnagyobb problémák: adatbázis-kezelés és live video stream kiszolgálás.

Adatbázis-kezelésnél az olvasásokra megoldást kínál a replikáció és az elosztott cache, írásra viszont csak a sharding marad. Ezek bonyolult ügyek, nincs "mindenre jó" trükk, alkalmazásonként külön-külön kell megoldani. Az egy szem "mindenre jó" Oracle cluster borzasztó drága és azért az sem egyszerű.

A kulcs-érték "adatbázisok" (pl. BigTable, Google AppEngine DataStore, HBase, Memcachedb) nem relációs elven mennek, óriási gond a rugalmasság: ezekkel sokkal nehezebb új funkciókat kitalálni és beépíteni az alkalmazásodba, pedig a weben állandóan kell valami mozgás.

Live video stream-nél gond a stream elosztása a kiszolgáló szerverek között. Elvileg megoldást kínál a Flash Media Server, de aranyáron. Van még néhány hasonlóan drága fizetős termék, de a weben nehéz ezeket a pénzeket az üzleti modellbe illeszteni, műszakilag pedig szintén nem hipp-hopp dolog.

Jövő

A live video szervereknél látom a leggyorsabb megoldást, hiszen a gát elsősorban üzleti. Előbb-utóbb úgyis esik az áruk és az open-source megoldások (pl. Red5) is felnőnek.

Az adatbázis-kezelésnél viszont úgy tartják, hogy a hagyományos relációs modellt túl kell haladni, ezzel egyetértek. De. A kulcs-érték modellt személy szerint nem tudom elfogadni megoldásként, több rugalmasság kell. Szerintem itt még sok-sok (több, mint három) évet kell várnunk, addig is figyeljük az eseményeket.

Végül itt van néhány skálázódással összefüggő termék és technika, Google-n rá lehet keresni, ezen a blogon is írtam már jónéhányról (van kereső!), lehet tanulni if you like:

• Többszintű cache-ing, elosztott cache (pl. Memcached). Erről hamarosan bő cikket írok.
  
• Adatbázis replikáció, fürtözés, particionálás, sharding.
  
• Kulcs-érték adatbázisok (lásd fent).
  
• Elosztott fájlrendszerek (pl. GFS, HDFS) és elosztott számítás (pl.
• MapReduce, Hadoop).
  
• Load-balancer (pl. HAProxy [hot!], Pound, Nginx).
  
• Cloud computing.

5 hozzászólás

1. idézem 2008.06.12. 10:42
   • Hodicska Gergely
   Lenne egy kérdésem, meg pár pontatlanság javítása.
   
   Mekkora volt a legnagyobb terhelésű oldal, amit fejlesztettél?
   
   FMS-nek nincs igazából megoldása terhelés elosztásra, pl. Ustreamet nem lehetne az ő edge-origin megoldásukkal megcsinálni (de ezt említettem is Neked ;)).
   
   És persze így egyenlőre nincs mihez felnőni. Még azt se mtriviális megcsinálni, hogy ne külön szervereid legyenek, hanem mondjuk egy adott, loadbalance-olt IP alatt oszd el a kéréseket.
   
   Nginx nem loadbalancer, hanem egy elég gyors kis webszerver.
   
   Üdv,
   Felhő
2. idézem 2008.06.12. 10:50
   • Gábor
   Legnagyobb terhelés: nem sok, napi 60-70e unique egy angol projektben.
   
   Ellenben most készítek ótómatikus cloud computing farmokat Amazonra. Webcsatornát pedig most kellett felkészíteni egy nagy lórúgásnyi terhelésre, ezért vagyunk most a többszintű cache-nek köszönhetően átlagosan 0 query - > 0.01s szinten. A statisztikákat pl. már "kishardoltuk".
   
   Az edge-origin-nél csak a márketinget olvastam, ezek szerint hazudnak mint a vízfolyás? Erről nagyon szívesen olvasnék, ha ráérsz.
   
   Az Nginx valóban webszerver IS. Naggyon pöpec load-balancert is lehet belőle konfigurálni, nagyon ügyes beállításai vannak erre a célra!
3. idézem 2008.06.12. 15:24
   • Hodicska Gergely
   "Edge-origin": FMS nem az én asztalom túlzottan, flashesek mesélték, hogy komoly terhelés mellett nem szabad használni, mint ahogy shared objectet sem.
   
   "Nginx": a wordpress-es esettanulmányt olvastam, de nem nagyon szoktam látni, hogy ilyesmire használnák. Mondjuk az elég impresszív volt, de mégis többnyire inkább hardveres load balancert szoktak használni, ha belefér a költségvetésbe.
   
   Üdv,
   Felhő
4. idézem 2008.06.12. 23:34
   • Gábor
   @felho Érdekes ez az edge-origin tapasztalat, majd utánanézek, mit írnak róla.
   
   Egyre-másra terjed az "írjuk meg az alkalmazást olcsó vasra" ügy, ezért sokan kezdtek pl. az Amazonra írni. Itt nem tudsz hardveres balancert használni, muszáj szoftolni. Egy év múlva már ki fog kristályosodni, hogy sikerül-e jól használható "sok lúd disznót győz" praktikákat találni. Olyan ez, mint a RAID: olcsó szerverek redundáns tömbje. :-)
5. idézem 2008.06.13. 13:10
   • Hodicska Gergely
   "Érdekes ez az edge-origin tapasztalat, majd utánanézek, mit írnak róla."
   
   Majd helyre rakatom a fejemben az infót erről. Ami viszont még érdekes lehet, hogy általában élsebb módon használjuk az FMS-t, mint mondjuk az Adobe. Már Jasminnál is előfordult (ott még anekdóta szinten halottam), hogy ment a kérdés az Adobehoz, hogy mit lehetne csinálni, mert ennyi meg ennyi kapcsolatnál ez meg ez történik, és végül ők kérdeztek vissza, mert hogy ők még sose préseltek ki ennyit belőle. Hasonlók mostanában is történtek, Adobe support nincs mindig a helyzet magaslatán.
   
   Üdv,
   Felhő

Legutolsó hozzászólások

Veoh.com: szánalmas!: zola2000: Megtaláltam a legegyszerűbb megoldást veohra: használjatok operát, és kapcsoljátok be az opera turbot, ekkor az opera norvégiai jön be a...

Végre IKEA!: Ági: Heló bárkinek, aki idetéved! A weboldalunk domain-je - a kedvenc áruházunk ügyvédjének nyumására :) - megváltozott: Az új cím: is...

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...