Ke zprovoznění vlastní databáze už dnes člověku stačí pár šikovných rukou a dobrý návod z internetu. V obstojné kvalitě se ji podaří nastavit a nasadit do ostrého provozu. Už po pár týdnech se ale mohou objevit první problémy, které databázi zpomalí nebo způsobí její úplné selhání. Když už se ji podaří znovu zprovoznit, nastává nekonečný boj s nekonzistentními daty.
Příčinou přetížení a selhání přitom nejčastěji bývá kromě nekvalitního hardware především chybně navržená architektura databáze. „Běžně se setkáváme s výkonnostními problémy, které mnohdy mohou vyřešit v zásadě i časově a finančně nenáročné změny systému, kde databáze běží,“ říká Jan Hrnčíř, solution architekt v MasterDC.
Vlivem nedostatečného know-how však firmy často přistupují spíše k přímočarému vertikálnímu škálování. To je nejenže stojí další náklady, ale v řadě případů ani nevyřeší jejich problémy, které souvisí se špatnou konfigurací databázového systému.
Optimalizace databáze v praxi
S nárazovým zpomalením odezvy aplikace a čím dal častější nedostupností databáze se setkal i jeden ze zákazníků MasterDC. „Firma se na nás obrátila s prosbou o analýzu databázového systému, z níž vyplynulo, že se potýká s problémy hned na několika úrovních,“ uvádí Hrnčíř s tím, že nejzásadnější nedostatky představovala hlavně zastaralost a nevhodná konfigurace systému, absence analýzy rychlosti dotazů a systému, chybně nastavené zálohování a nedostatečné zabezpečení.
I tady se ukázalo, že se v minulosti podobná situace řešila navýšením výkonu. To už ale dále nebylo možné, protože firma v rámci sdíleného serveru dosáhla limitu pro vertikální škálování. Optimalizace výkonu si proto vyžádala kompletní redesign databáze.
Prvním krokem k novému funkčnímu systému bylo omezení práv a hostů, z nichž bylo možné se k databázi přihlásit. Následně došlo k rekonfiguraci zálohování, které způsobovalo pravidelnou nedostupnost z pohledu aplikace.
Posledním krokem měly být změny v samotné konfiguraci databázového systému. Zákazník se ale nakonec vzhledem k jejich rozsahu a nezbytným nákladům na nový hardware rozhodl přejít na plně spravovanou platformu DBaaS (Database as a Service), čímž získal plnohodnotnou vysokou dostupnost na třech aktivních instancích.
Po otestování funkčnosti aplikace a ostré migraci tak zákazník dosáhl při nižších nákladech na vysoce dostupnou databázi s násobně rychlejší odezvou dotazů i vyšší I/O výkon dedikovaných instancí. K tomu přispělo zejména individuální nastavení databázového systému, jeho modernizace a změna storage engine.
Proč vůbec zákazník upřednostnil DBaaS řešení? Nákup minimálně 3 nových serverů, konfigurace systému a zajištění kapacit a know-how na údržbu a monitoring by výrazně převýšily stanovený rozpočet. DBaaS mu zpřístupnila požadovaný výkon a kapacitu storage za měsíční poplatek, pohybující se v řádech nižších jednotek tisíců (v závislosti na konkrétních parametrech databáze).
Co je DBaaS a jak funguje
V rámci DBaaS si necháte zprovoznit databázi třetí stranou a využíváte ji jako službu. Outsourcujete tím starost o hardware a celou platformu právě na dodavatele a sami se staráte už jen o samotná data.
Co přesně u DBaaS zajistí poskytovatel:
- platformu pro provoz databáze ve vysoké dostupnosti
- údržbu hardware, na němž platforma běží
- pravidelnou instalaci updatů
- nastavení zálohování
- automatické denní zálohy 7 dní zpětně
- 24/7 monitoring hardware
Šíře služeb nabízených v rámci DBaaS se vždy odvíjí od konkrétního poskytovatele. V MasterDC například tvoří výše zmíněné body základ služby. Zákazník si zkrátka vybere instanci, která splňuje jeho nároky, a administrátoři se postarají o zprovoznění databáze podle best practice a dalších individuálních požadavků.
Každá zákaznická instance má dedikované zdroje, které zajišťují její stabilní výkon. Pokud se zákazníkovy požadavky na výkon a kapacitu databáze změní, může operativně přejít na jinou instanci s vyššími parametry bez nutnosti pořizovat nový hardware.
Služba je provozována na několika nezávislých nodech, a tak eliminuje jakékoli narušení výkonu. Synchronní replikace a technologie Keepalived totiž automaticky přesměrují provoz na další aktivní uzel. To platí i během údržby systému, takže zákazníci během ní nepociťují žádnou změnu v provozu služby.
Uživatel k databázi vždy dostane root přístup, dedikovanou IP adresu a porty, přes něž se bude připojovat k jednotlivým databázovým nodům. Součástí je i přístup do nástroje Grafana, kde lze sledovat dostupnost prostředků, vytížení jednotlivých nodů a přehledy požadavků.
Zákazník získá k DBaaS přístup do nástroje Grafana, odkud může sledovat vytíženost prostředků.
Stěžejní výhodou DBaaS je vedle úspory na nákladech také to, že zákazník nepotřebuje žádný hlubší vhled do problematiky databází. A pokud by se přece jen setkal s problémem na úrovni dat, má 30 minut debuggingu měsíčně zdarma.
Otázka bezpečnosti: častá obava z DBaaS
Jestli se lidé něčeho u DBaaS obávají, pak je to bezpečnost dat. V tomto ohledu se rozhodně vyplatí mít se na pozoru a dobře vybírat poskytovatele takové služby. Přece jen vkládáte data svých zákazníků do rukou třetí strany.
Základem dobrého zabezpečení DBaaS je právě omezení práv uživatelů a přístupů k databázi. Následkem nedodržení těchto postupů bývají četné brute force útoky, s nimi spojená nedostupnost a kompromitace zákaznických dat.
Při výběru dodavatele DBaaS si proto ověřte, jestli platforma běží v interní síti a jakým způsobem se k ní budete moct připojovat. „Ideální je třeba přístup přes povolené IP adresy, tzv. whitelisting. Samozřejmostí by mělo být šifrování vstupních a výstupních dat i záruka vysoké dostupnosti ve výši 99,99 %,“ uzavírá solution architekt a specialista na databáze.
PŘEDPLATNÉ
ČLÁNKY DO MAILU