Uplynulé mesiace sa nepretržite venujeme zlepšovaniu kvality služieb. Každý väčší míľnik sa vám snažíme sprostredkovať prostredníctvom blogu. Bolo tomu tak pri informovaní o stave, nainštalovaní cache, zmene webovej infra, záložnom pripojení a je tomu tak aj teraz pri inovácii databázových serverov.

Po rade optimalizácií na strane webových serverov sme sa pustili do odstránenia ďalšieho “bottlenecku” v rýchlosti odozvy webstránok – vzali sme si na mušku databázy. Takmer každá webová stránka využíva minimálne jednu databázu, pre redakčné systémy ako WordPress alebo Joomla sú neodmysliteľnou súčasťou. Avšak práve databáza mnohokrát patrí ku najčastejším spomaľovačom načítavania stránky.

Proces optimalizácie sa odohrával na viacerých úrovniach, od zvýšenia verzie databázových serverov, nákup čisto-SSD serverov až po zmenu virtualizačnej technológie, na ktorej databázové servery bežia. Databázové servery sme ladili aj po konfiguračnej stránke, pričom sme brali do úvahy aj záťažový vzor, ktorý je na ne kladený.

Upgrade hardvéru

Upustili sme od idey mať všetky dáta uložené na centrálnom redundantnom diskovom poli – čas ukázal, že záťaž spôsobená niektorými časťami infraštruktúry má príliš vysoký dosah na celý zvyšok systému. Ako sme spomínali v komentároch k nedávnemu článku, webové stránky už nejaký čas presúvame na čisto-SSD infraštruktúru. Teraz sme podobný hardvér dopriali aj databázovým serverom:

image00

Okrem niekoľkonásobne nižšej latencie pri zápise na disk majú výhodu v tom, že neovplyvňujú svojou záťažou iné časti infraštruktúry – ako napríklad webové stránky alebo virtuálne servery klientov. O to prísnejší sme však museli byť pri zálohovaní – databázy sa zálohujú jednak na aplikačnej úrovni (MySQL dumpy prístupné pre klientov), jednak na úrovni diskových blokov na geograficky oddelený server (pre prípad disaster-recovery).

Zmena virtualizačnej technológie

Doposiaľ sme databázové servery vytvárali ako virtuálne stroje na platforme KVM, ktorá predstavuje tzv. “plnú virtualizáciu”. Táto technológia umožňuje pomerne efektívne využitie procesora fyzického servera, keďže však ide o plnú virtualizáciu, disk musel byť vytvorený ako jeden veľký súbor uložený na zdieľanom diskovom poli (kvôli dostupnosti). A práve tu dochádzalo k vyšším odozvám pri komunikácii s databázou. Zdieľané diskové pole muselo počas tejto práce zároveň obsluhovať desaťtisíce webov a mailových schránok a stovky virtuálnych serverov. Aj pri použití lokálneho disku má však KVM virtuálny server určitý postih výkonu oproti fyzickému serveru.

Naopak, kontajnerizácia (alebo kontajnerová virtualizácia), pod ktorú patria napríklad Docker a LXC, dosahuje výborné výsledky pri komunikácii s lokálnym diskom. Výpočtový výkon CPU je takmer identický s fyzickým strojom, na ktorom kontajner beží – kombinácia týchto dvoch vlastností databázovým serverom značne prospela. Ako virtualizačnú platformu pre nové databázové servery sme teda zvolili LXC.

Bonusom pri používaní kontajnerov namiesto jedného veľkého fyzického servera je lepšie využitie vstavaných vlastností MySQL. Ak je napríklad potrebné reštartovať mysql proces, pri štarte sa vykonáva kontrola integrity dát, ktorá je nad 1000 tabuľkami omnoho rýchlejšia ako nad 10 000 :). Navyše, “nezbedné” databázy, ktoré z akéhokoľvek dôvodu extrémne vyťažujú server, majú dopad na menší počet susedných databáz.

Poslednou malou výhodou je aj využívanie “query cache”. Ak z databázy iba čítate dáta bez zápisov, po prvom prečítaní sa uložia do cache a ďalší dopyt je omnoho rýchlejší. Avšak akýkoľvek zápis dát do ktorejkoľvek databázy na rovnakom serveri vedie ku invalidácii tejto cache. V priemere tvoria zápisy do databáz iba 10,75% dopytov, preto má zmysel optimalizovať a merať najmä operácie čítania. Rozdelením databáz medzi viacero kontajnerov sa pre každý dopyt zvyšuje pravdepodobnosť, že bude prečítaný z query cache.

Detailné porovnanie parametrov KVM virtualizácie a kontajnerov nájdete v tomto (.pdf) dokumente od IBM .

Porovnanie pôvodných a nových DB serverov

Po nasadení novej databázovej infraštruktúry sme boli zvedaví, o koľko sa nám podarilo zlepšiť odozvu dopytov a počet dopytov za sekundu. Meranie sme teda vykonali na štyroch databázových serveroch – šlo o kombinácie MySQL 5.1 a MariaDB 5.5 s virtualizačnými technológiami KVM a LXC.

Nešlo nám o vyťaženie databázového CPU, preto sme nevykonávali dopyty, ktoré vedia v SQL vyriešiť Sudoku, iba jednoduchý SHOW TABLES. Zamerali sme sa na počet dopytov, ktoré je webstránka schopná vykonať za 1 sekundu, čo priamo odráža latenciu databázy voči webovému serveru – práve to je podľa nás tá najdôležitejšia metrika. Medzi sériami dopytov sme vždy počkali niekoľko sekúnd, aby sme dali šancu zápisovým operáciám zmazať query cache.

image01

Na grafe je zobrazené percento databázových dopytov v závislosti od rýchlosti, akou boli získané od DB servera. Pre MySQL 5.1 pod KVM napríklad vidíme, že priemerná rýchlosť je cca 1000 dopytov za sekundu. Keďže MariaDB 5.5 servery na KVM architektúre sú pod vyššou záťažou, ich odozva má široké spektrum.

Najdôležitejší je však posun oboch kriviek znázorňujúcich LXC virtualizáciu. Priemerná rýchlosť dopytov za sekundu je v hodnotách, aké dosahujú KVM servery už iba zriedka – na testovacom dopyte je rýchlosť vyššia cca o 35%. Minimálna a maximálna priepustnosť sú taktiež vyššie – v zónach, kde pôvodné servery s KVM dosahujú priemer, sa nový hardvér s LXC iba prebúdza.

Na nové databázové servery je v súčasnosti presunutá asi polovica databáz, no do Vianoc plánujeme mať presunuté všetky. Veríme, že aj tento krok ku zrýchleniu webov bude mať pozitívny dopad na kvalitu našich služieb v budúcnosti.

Sledujte nás aj naďalej, s vylepšeniami určite nekončíme. Pracujeme na ďalších inováciach smerujúcich k vyššej kvalite, ktorú si zaslúžite.

TIP: Prečítajte si článok o tom, ako sme nasadili novú verziu Open vSwitch, zrelizovali záložné pripojenie do Cogentu, prešli z CFEngine na SaltStack a presunuli sme hostingy na dedikáče.

[mc4wp_form]

Komentáre