Nõuandeid mastaapsema veebiteenuse käivitajale
Antud blogipostitus on 150 kuud vana ning ei pruugi olla enam ajakohane.
Aegade jooksul on meile olnud rõõm teenindada väga suurt hulka kliente ja elada kaasa mitmete uute veebiteenuste käivitamisele. Väga paljudel juhtudel on need edukad, kuid sekka sattub ka selliseid, mille tegijad ühel hetkel hea meelega aja tagasi keeraks ja stardijoone taha tagasi vantsiks.
Nimelt on teenuste käivitamise puhul tihti probleemiks see, et edukale tulevikule minnakse vastu puudulike vahenditega, mis meie valdkonnas tähendab enamasti aladimensioneeritud riistvararessursse või kehvasti kirjutatud rakendusi.
Kuna ma ise tarkvaraarenduses end väga koduselt ei tunne, siis heietan siinkohal eelkõige sel teemal, kuidas vältida enamlevinud riistvaralisi pudelikaelu, mille taha tihtilugu toppama jäädakse.
Vähene mälu hulk
Minu esmane soovitus on, et teenust käitavale serverile tuleb kindlasti eralda mõistlikus koguses põhimälu (RAM). Rusikareegliks on “mida rohkem, seda uhkem”. Suur põhimälu hulk võimaldab märgatavalt vähenda aeglasemate sisend-väljund (I/O) seadmete poole pöördumisest tingitud viivitusi. Tänapäevased operatsiooni- ja andmebaasisüsteemid on “mihklid “ enamkasutatavaid andmeid erinevatesse puhvritesse koguma ja ühel hetkel on tõenäosus, et teenuse poolt päritavad andmed leitakse kettasüsteemi asemel serveri mälus asetsevast puhvrist, väga suur.
Seda, kui suur on kiiruste vahe mälu ja kettasüsteemi vahel, iseloomustavad ehk järgmised arvud: süsteemis, kus on kasutusel 45 nm Intel Nehalem-EP protsessor võib põhimälu latentsusaeg olla näiteks 50 nanosekundit, samas kettasüsteemi poole pöördumise puhul mõõdetakse latentsusaega juba millisekundites. Üks nanosekund on miljardik sekundist, millisekund aga juba tuhandik, seega vahe mälu ja kettasüsteemi latentsi vahel on miljonikordne. Reaalsete rakenduste kontekstis miljonikordsetest vahedest rääkimine oleks selge liialdus, kuid drastiline number aitab ehk lihtsamini kohale toimetada sõnumi, et põhimälu on harva liiga palju.
Kettasüsteemi kiirus ja läbilaskevõime
Kui kettasüsteemist rääkida, siis on lahendusi, mille puhul vale kettasüsteemi valik võib väga valusalt kätte maksta.
Tüüpiliselt on tegu kas failisüsteemis suurt hulka infosõlmi (inode) tarbivate rakenduste või mahukate online-tehingutöötlusele (On-line Transaction Processing) orienteeritud andmebaasidega, mida iseloomustavad INSERT, UPDATE, ja DELETE käsude suur hulk ja/või ressursinõudlikud relatsioonide liitmised (join).
Sellistel juhtudel hakkavad probleeme põhjustama faktorid nagu aeglane kõvaketta lugemispea liikumiskiirus andmete otsimisel, mis limiteerib sekundis teostatavate sisend-väljund operatsioonide arvu (IOPS) ja ketta pöörlemisega seotud latentsusaeg, mis piirab läbilaskevõimet (MB/s).
Väikestes serverites, kus kettasüsteemile pole suurt koormust, võib küll kasutada 7200 RPM või 10 000 RPM SATA kõvakettaid, kuid parima jõudluse tagab tänapäeval 10 000 RPM või 15 000 RPM SAS (Serial Attached SCSI) ketaste kasutamine. Iseenesestmõistetavalt on enamasti ka need kasulik ühendada veakindlasse ja jõudlust lisavasse RAID konfiguratsiooni nagu RAID 10 või RAID 6.
Protsessor
Protsessoritega on õnneks veidi lihtsam, enamus veebiteenuste käivitajaid tundub tänaseks olevat aru saanud, et korraliku vahemälu ja kõrge taktsagedusega Inteli Xeon seeria E (mainstream) ja X (performance) tähisega protsessoriga pole kriitilisema serveri puhul väga võimalik puusse panna. Loomulikult, mida paremat protsessorit eelarve kannatab, seda parem. 
Kuuldavasti on Inteli päris värsketel protsessoritel uus tähistussüsteem, see ehk võib mõneks ajaks taas vett segasemaks muuta, aga küll me harjume 🙂
Kuidas probleeme ennetada?
Ressursside hulga suhtes mõtestud otse tegemiseks ja probleemide eos välistamiseks on üks läbiproovitud meetod – veebirakenduse vajaduste eelnev mõõdistamine.
Testimaks ressursivajadust tuleks korraldada test, mille käigus mõõdetakse rakenduse, seda teenindava süsteemi ja komponentide jõudlust ning reaktsiooniaega eelnevalt määratletud tingimustel, näiteks kindlaks arvu paralleelsete kasutajate korral.
Sellise testi käigus on lisaks ressursinõudlikkusele võimalik tuvastada ka olulisi pudelikaelu, ja märkida maha süsteemi normaalse toimimisega seotud näitajaid.
Elementaarne test ei pea kindlasti olema väga kulukas või keerukas protseduur, selleks on vaja pealehakkamist, platvormi millel test läbi viia, võimalust ressurikasutust jälgida ja vahendit, millega testida.
Lihtsama veebirakenduse testi saab läbi viia näiteks Apache veebiserveri “tööriistakasti” kuuluva ab nimelise töövahendiga. See on kättesaadav pea kõigile Linuxi ja Windowsi kasutajatele. Ab dokumentatsiooni leiate aadressilt http://httpd.apache.org/docs/2.2/programs/ab.html.
Lisaks on loomulikult tänapäeva veebiteenuste keskses maailmas olemas vastavad pilveteenused. Omalt osalt oleme kuulnud palju häid sõnu lausutavat LoadStorm nimelise teenuse kohta, millel abil on elementaarsed testid võimalik läbi viia ka tasuta.
Testimiseks vajaliku serveriteenuse võite võtta Zonest, oleme üritanud võimalikult paljudele sooviavaldajatele korraldada testperioode nii erinevates privaatserverites kui ka VPS serverites. VPS server, mis pakub võimaluse kättesaadavate ressurside hulka kiirelt muuta, on selleks otstarbeks muidugi pea ideaalne.
Milliseid nõuandeid on aga teil värske missioonikriitilise veebiteenuse käivitajale?
Populaarsed postitused
Nutikas Pilveserver: tark lahendus e-poe ja nõudlike veebiprojektide jaoks
Hallatud või halduseta platvorm: kumb vastab paremini sinu vajadustele?
Zone Veebiakadeemia - lihtsad tööriistad kodulehega alustamiseks
Kommentaarid
2 kommentaariLisaks riistvarale tasub kindlasti jälgida ka rakenduse poolt kasutatavaid tarkvaralisi vahendeid – absoluutselt kõigeks PHP’d ja MySQL’i kasutada võib osutuda üsna kulukaks, st. tuleb rakendada rohkem ja kallimat riistvara, kui tegelikult vaja oleks.
Näiteks kui on tarvis teha väga palju kirjutamisi andmebaasi, samas kui need andmed pole otseselt kriitilise väärtusega (näiteks veebikaunteri teenus, kus on vaja lugeda külastuste ja lehevaatamiste arvu), siis tasuks kaaluda MySQL asendamist Redisega, mis ka väga tagasihoidlike parameetritega serveritel suudab saavutada (kümneid)tuhendeid kirjutamisi sekundis. Ning alles päeva kokkuvõtted teha taustatööna ja salvestada juba kuhugi kindlamasse kohta.
Kui on väga palju tegemist erineva IO’ga, olgu selleks siis näiteks ketastelt lugemine või üle võrgu väliste (nii kohalike kui ka kaugete) serverite poole pöördumine, siis tasuks PHP asemel kasutada Node.JS’i, mis suudab seda teha nii, et ei blokeeri teiste rakenduste/paralleelsete päringute tööd. Kui aga tegu on rohkelt CPUd koormava tegevusega, siis Javat või Pythonit või veel parem C’d.
Kui aga on vaja lisada suuremahulisele (tekstihulga mõttes) lehele otsingu võimalus, siis MySQL FULLTEXT indeksi – või mis veel halvem, LIKE % tekstiotsingu asemel tasub kaaluda Lucenet või sellest mugavamat Elasticsearch’i.
Ühesõnaga, enne kui minna RAM’i juurde tellima (kuigi RAM’i peaks alati olema võimalikult palju) või protsessorit vahetama, tasub ka üle vaadata rakenduse tarkvaraline arhitektuur üldisemalt. Võibolla saab mõne suurema pudelikaela ära likvideerida lihtsalt väikese programmijupi vahetamisega. Heaks näiteks on hiljutine LinkedIn’i mobiilse rakenduse uuendamine, kus suudeti 15 rakendust teenindavat serverit tarkvaralise platvormi vahetamisega vahetada ainult 4 serveri vastu, nii et rakendus ise muutus kaks korda kiiremaks.
Mainitud ElasticSearch ongi Lucene peale tehtud. Eeliseks veel see, et ta on skaleeritav. On saavutatud väga häid tulemusi ka mitmetesse gigabaitidesse ulatuvate indeksitega.
Tõsi on see, et andmebaasi natuke ümber kohendades (tihti tähendab see normaalkujudest loobumist) saab imesid teha. Näiteks kui vähegi võimalik, siis agregatsioonid teha ära siis, kui info muutub, mitte siis kui on vaja seda välja kuvada jms.
Mainida võib veel Memcached’i, sisuliselt sama mis Redis, ainult ei kirjuta asju kettale.
Kommentaarid suletud.