Recommended
More Related Content
What's hot
What's hot (15)
Viewers also liked
Viewers also liked (17)
Similar to Zmrakování pružné včely
Similar to Zmrakování pružné včely (20)
Zmrakování pružné včely
- 1. Zmrakování pružné včely Petr Ferschmann FlexiBee Systems s.r.o.
- 7. Co je to cloud? • Poskytování služeb přes internet na požádání • Náklady
- 11. IaaS, PaaS, SaaS • Software jako služba • Platforma jako služba • Infrastruktura jako služba
- 12. Co na to klienti? • Kolik to stojí? • Bude to bezpečné? • Bude to fungovat?
- 13. Úpravy aplikace
- 14. Úpravy aplikace
- 15. CouchDB
- 16. Load balancer
- 17. Mnoho malých serverů • Malé servery • Role serveru • Automatická instalace (puppet)
- 18. class postgresql-common { package { 'postgresql-9.1': ensure => installed, } file { '/etc/sysctl.conf': source => 'puppet://server/files/postgresql/sysctl.conf', owner => 'root', group => 'root', mode => '644', notify => Exec["sysctl -p /etc/sysctl.conf"], } exec { "sysctl -p /etc/sysctl.conf": path => "/usr/bin:/usr/sbin:/bin:/sbin", } service { 'postgresql': ensure => running, enable => true, hasstatus => true, hasrestart => true, } }
- 20. Je cloud levnější? • Kdy je cloud levnější a spolehlivější?
- 21. Bezpečnost
- 23. API
- 24. Cloudové služby • Load balancing • Content Delivery Network • Auto Scaling • Monitoring • Cloud API (delta cloud)
- 25. Co na to klienti? • Kolik to stojí? • Bude to bezpečné? • Bude to fungovat?
Editor's Notes
- jak jsme měli produkt - desktopovou aplikaci a převedli jsme ji do cloudu. Zdá se to jasné, ale my jsme v oblasti, která je nejvíce konzervativní. Dokonce i bankovní úředníci jsou progresivnější. Účetním se v noci ještě zdá o DOSovských aplikacích. Toto je návod jak převádět aplikace do cloudu.
- Než začneme řeknu něco o FlexiBee. Je to účetnictví: - pro Linux, Windows a Mac OS X - umí sklady, mzdy, majetek, apod. - má desktopovou aplikaci, mobilní přístup a webový přístup - má otevřené programátorské rozhraní REST API. - umí fungovat přes internet. Ještě jednou zopakuji – aplikace už uměla komunikovat přes internet.
- Protože naše aplikace podporuje přístup přes internet, začali jsme ji provozovat na našich serverech. Prostě nám běží aplikační a SQL server a klient se připojuje. Vytvořili jsme tedy aplikaci, která má desktopového klienta, aplikační server a SQL server. S tímto aplikačním serverem umí komunikovat přes internet. Používá k tomu interní protokol.
- Bohužel nebo naštěstí jsme si nevystačili s jedním zákazníkem a začali jsme provozovat více aplikačních serverů a SQL serverů. Sice virtualizovaně, ale i tak nám to způsobovalo problémy. Narazili jsme na několik problémů: - mnoho uživatelů a hodně z nich je pasivních. To jsou uživatelé, kteří systém právě teď nepoužívají, ale aplikační server jim musí běžet. Máme mnoho testovacích uživatelů a ti to zkouší a nepoužívají denně. - nutnost schvalovat testovací licence – jinak nám někdo vytvoří stovky nebo tisíce nových instalací a zahltí nás. - škálovatelnost a robustnost – do jednoho serveru narveme desítky GB RAM. Když nasadíme záložní servery, všechno spotřebujeme několikrát. Rozhodli jsme se, že musíme změnit architekturu aplikace.
- lineární vs logaritmická složitost lineární na disku (ten je levný) lineární na počet současných požadavků (každý trvá 5 vteřin). logaritmická na počet instalací, počet klientů cloud má nedostatek aktuálního výkonu, ale hodně výkonu celkem - optimalizace pro odloženou realizaci - selhání je standard - klientské aplikace s tím musí počítat - OBRÁZEK: průměr za 5 minut vs průměr za 5 vteřin
- To je změna za posledních několik let. Co to je: porovnání s poštou. Cloud je vlastně návrat k sálovým počítačům.
- Jak jsme chtěli platformu. Problém se vzáleností.
- Klienti mají tři problémy: - bude to fungovat? - je to bezpečné? - kolik to stojí Konkurentem pro nás nejsou terminálové služby (stojí cca 1000,- Kč za uživatele měsíčně), ale to, že si data nechají na svém notebooku. Konkurencí je také vlastní VPS server za pár stovek korun měsíčně. Naštěstí normálně fungující firma si to nemůže dovolit riskovat. Aktuálně přibližně 30% uživatelů používá přístup přes internet. Tak 25% přímo cloud. Zbytek si to hostuje na vlastních serverech. Klienti se bojí dávat data k cizí firmě. Někdy jim to brání i legislativa – např. Zbrojní firmy či veřejně obchodovatelné firmy. V některých zemích existuje třeba zákon (myslím, že Slovensko), který zakazuje export personálních dat do zahraničí. Když ale server běží v zahraničí, tento zákon porušujete. Příkladem toho, že uživatelé o to mají zájem jsou různé online fakturace. To už je skoro jako slevomaty. I my jsme spustili službu Účtujte s Podnikatel.cz, která je postavená na FlexiBee a přináší zjednodušenou fakturaci i se základní verzí zdarma.
- Když jsme připravovali změny naší aplikace pro cloud, první problém byl SQL server. V podstatě žádný SQL server neškáluje na více než 8 serverů. Uvažovali jsme zda neopustit PostgreSQL, ale nebylo to možné: SQL je velmi vhodné pro typ naší aplikace a přepis by byl příliš drahý. Na druhou stranu jsme si uvědomili, že mi nikdy nepotřebujeme dotazy přes všechny firmy (zákazníky). Nám stačí vždy jen jedna firma. Takže se lze dívat na databáze jako na oddělené soubory. Tímto faktem je vlastně škálovatelnost vysoká. Potřebujeme sjednotit aplikační servery (a mít jich více) a také sjednotit databázové instance (pořád platí, že pro každého klienta je jedna databáze).
- Uvažovali jsme zda nepoužít nějakou platformu. Bohužel zatím žádná z nich nepodporuje PostreSQL. A současně běží daleko. Naše specializovaná aplikace je citlivá na latenci (provádí mnoho volání). Proto je i irsko příliš daleko. Museli jsme proto zatím aplikaci provozovat jen na vlastní infrastruktuře. Na tomto obrázku je vidět, že máme vždy tři repliky (jedna z nich je master) pro databázové úložiště. Těch databázových úložišť je více. Každé úložiště je v RAIDu. Takže od každých dat máme 6 kopií. A to nepočítám zálohy. Každý megabajt máme cca desetkrát. Dále máme více aplikačních serverů. Každý z nich se může napojit na libovolné databázové úložiště dle firmy. Před tím jsou postaveny dva loadbalancery, které rozhazují zátěž na aplikační servery a sledují jejich životnost. Je zde maximální snaha, aby vždy stejný klient šel stejnou cestou. Tím můžeme cachovat některá data. První věc a nejzásadnější byla úprava aplikace tak, aby mohlo na jednom serveru běžet více klientů. Znamená to načtení dat o firmě při prvním požadavku a jen její krátké cachování. Nemůžeme si tedy moc věcí přednačítat a musíme tomu podvolit vývoj. Prostě si nemůže aplikační server nahrát pár megabajtů dat a ty pak držet dlouho. Museli jsme také upravit všechny části tak, aby byly maximálně bezstavové. Přepsali jsme třeba ochranu proti CSRF a je kompletně bezstavová – používá cookie.
- Říkal jsem, že se sice jednotlivé firmy chovají jako oddělené soubory, ale stále zde existují data, která jsou sdílená. A to je databáze uživatelů, databáze firem a přístupů. Potřebovali jsme databázi, která bude mít maximální podporu pro multimaster a která bude schopná provozovat desítky až stovky uzlů v tomto režimu. Zvolili jsem couchdb, která běží v podstatě na každém uzlu. Změn zde není moc (při založení firmy, při přihlášení uživatele apod.). Snažili jsme se upravit návrh struktury tak, abychom eliminovali kolize při zpoždění replikace. Zatím to funguje a počet operací není tak velký takže zatím jsme na žádné problémy nenarazili.
- Klíčovou vlastností architektury je router. Ten určuje, který aplikační server se postará o požadavek. Hlídá si dostupnost aplikačních serverů (seznam si čte z couchdb). Chvíli jsme používali varnish, ale tam je problém s tou dynamickou změnou. Node.js si prostě každou chvíli přenačte couchdb (mohl by i reagovat na změny v databázi, ale to zatím neděláme) a zareaguje. Umožňuje nám např. Rezervaci pro klienta.
- Máme mnoho malých serverů. Základem je název server. Ten určuje jeho roli a zařadí jej. Pro konfiguraci používáme puppet. Ten umožni snadno dědit konfiguraci a mít vše přehledně. Reinstalace webového serveru je otázka na 5 minut (nejvíce času si checkoutuje zdrojáky webů). U databázového to tak snadné není. Tam se dlouho kopíruje replika. U primáru je to rychlé.
- Napsal jsem článek na zdroják.cz a tam vyplynulo, že je některým lidem nejasná hranice mezi cloudem a hostingem. Cloud vždy poskytuje službu, která je stejná jako u hostingu. Když třeba nahrajete soubor na Content Delivery Network a na hosting, vše se zdá podobné. Rozdíl je v tom, že když ten soubor pak začnete stahovat milionkrát, výkon hostingu nenaroste dle potřeby a uvaří se. CDN rozloží soubor na mnohem více serverů. A taky při tom trochu vysaje peněženku.
- Jeden z omylů je, že je cloud levnější než klasické řešení. Pokud si spočtete minutu běhu jednoho serveru v cloudu a u sebe, zjistíte, že cloud je dražší. Kdy je tedy levnější? Při změnách. Potřebujete tisíc serverů teď? Rychle? Budete je potřebovat i za měsíc? Potřebujete je jen přes den a v noci jich stačí 5? V případě platformy nebo služby to může být trochu jinak. To samé platí i u spolehlivosti. Nedávný výpadek Amazonu ukazuje, že i cloudová řešení mohou vypadnout a na dlouho. To co zvyšuje spolehlivost je, že vše navrhujete pro velké množství serverů a tak je vysoká redundance.
- - Oddělená autorizace od informací o uživatelých (login server) - jak řešit DDoS - bezpečnost disků - interní šifrování v clusteru - hacknutí je významnější -
- Nejvěší slabinou cloudového přístupu je autorizace uživatele. Banka vs účetnictví - lidem na tom nezáleží. Někdy ani majitelům firem. Lze nastavit kvalitu hesel. Chce to sebekázeň a heslo mít kvalitní. Neměla by být jeho sdílená znalost. Uvažovali jsme nad posílání SMS apod. Zvolili jsme stejnou technologii, kterou používá google - OTP. Je to standard. - Google Authenticator - TOTP c200 - cena cca 200 Kč bez DPH Použití OTP je dobrovolné a lze je nastavit i pouze pro klíčové lidi (např. mzdová účetní)
- Jedině REST API Bez toho to nejde. Připravit již hotové integrace (u nás autorizace na google, kontakty na google, ...)
- Poskytovatelé cloudu poskytují mnoho služeb. Od content delivery network až po sofistikované monitoringy a automatické řízení spotřeby (promiňte výkonu). Je zde velký prostor pro různé dodavatele. Současně i nebezpečí lockinu, kdy nebudete moci opustit poskytovatele cloudu jen proto, že neexistuje cesta jak to udělat. To je také důvod proč umožňujeme udělat si zálohu i z cloudu k sobě.
- Klienti mají tři problémy: - bude to fungovat? - je to bezpečné? - kolik to stojí Konkurentem pro nás nejsou terminálové služby (stojí cca 1000,- Kč za uživatele měsíčně), ale to, že si data nechají na svém notebooku. Konkurencí je také vlastní VPS server za pár stovek korun měsíčně. Naštěstí normálně fungující firma si to nemůže dovolit riskovat. Aktuálně přibližně 30% uživatelů používá přístup přes internet. Tak 25% přímo cloud. Zbytek si to hostuje na vlastních serverech. Klienti se bojí dávat data k cizí firmě. Někdy jim to brání i legislativa – např. Zbrojní firmy či veřejně obchodovatelné firmy. V některých zemích existuje třeba zákon (myslím, že Slovensko), který zakazuje export personálních dat do zahraničí. Když ale server běží v zahraničí, tento zákon porušujete. Příkladem toho, že uživatelé o to mají zájem jsou různé online fakturace. To už je skoro jako slevomaty. I my jsme spustili službu Účtujte s Podnikatel.cz, která je postavená na FlexiBee a přináší zjednodušenou fakturaci i se základní verzí zdarma.
- Klienti mají cloud rádi. Nebojte se jim jej nabízet. Mají jen tři obavy: - aby to fungovalo. Pro nás je problém s - bezpečnost – cesta do afriky - cena – ve skutečnosti je cena trápí nejvíce.