Cloudová infrastruktura aplikace: co spustit a co vynechat

Aplikace v testu odpovídá. První týden v produkci ukáže něco jiného. Soubory zmizí s novým nasazením, protože ležely na disku kontejneru. Databáze má veřejnou adresu. Na faktuře běží staging, prostředí na zkoušky, které nikdo měsíc neotevřel.

Nejdřív čtyři fakta, potom katalog

Než se otevře ceník poskytovatele, potřebujete čtyři fakta. Kolik lidí je ve špičce v systému. Jak velká je největší operace: import, export, hromadné oznámení. Jaká data v tom jsou: platby, osobní údaje, smlouvy, soubory. Jak dlouhý výpadek a jakou ztrátu dat firma unese.

U většiny nových B2B produktů z toho vyjde střídmý začátek. Jeden backend, kód za obrazovkou, který bere požadavky a vykonává je. K němu spravovaný Postgres, bucket na soubory a automatické nasazení. Bucket je úložiště u poskytovatele: soubor v něm přežije nové nasazení, na disku serveru ne. Frontu a druhou instanci přidejte, až nějaká operace drží uživatele nebo databázi. Oddělit v kódu zpracování souborů a dlouhých úloh má smysl dřív než samostatná služba. Ta se vyplatí, až když ji umíte nasadit, hlídat a shodit nezávisle na zbytku.

Co aplikace dělá	Co spustit	Co nechat na později
Interní systém, desítky uživatelů, krátké požadavky	Jeden backend, spravovaný Postgres v privátní síti, bucket na soubory, menší staging	Kubernetes, druhý region, mikroslužby
SaaS, soubory, importy, víc firem v jedné databázi	Totéž, plus fronta a proces na pozadí, cache na opakovaná čtení, záloha s vyzkoušenou obnovou	Automatické přidávání instancí, kopie databáze pro čtení bez naměřeného důvodu
Osobní údaje nebo výpadek v řádu minut	Přístupy na jméno, databáze bez veřejné adresy, záznam citlivých akcí, změřená obnova	Druhý region, dokud neznáte cenu hodiny výpadku

Co v provozu opravdu běží

Backend bere požadavky a vykonává obchodní logiku. Spravovaná platforma nebo kontejnerová služba ubere práci se servery. Vlastní virtuální server nechá kontrolu nad systémem a zároveň aktualizace, disky a obnovu na vás. Kubernetes k tomu přidá vlastní provoz: aktualizace, síť a servery, na kterých kontejnery běží. U jednoho produktu s malým týmem ta práce obvykle stojí víc než samotná aplikace.

Databáze je část, kterou po ztrátě nesložíte z gitu. Spravovaný Postgres bere aktualizace systému, automatické zálohy a volitelně záložní instanci v druhé zóně. Schéma, dotazy, přístupy a zkouška obnovy zůstávají na týmu. Databáze nemá mít veřejnou adresu. Aplikace k ní chodí po privátní síti.

Na tenhle start sedí Scaleway. Francouzský poskytovatel, regiony v Paříži, Amsterdamu, Varšavě a Miláně. Backend jako malá virtuální instance, Managed Database for PostgreSQL a bucket v Object Storage. Jejich Serverless Containers při minimu nula v klidu zmizí a první uživatel čeká, než kontejner naběhne. Na provoz přes den nechte běžet aspoň jednu instanci.

Backend a databázi dejte do jedné Private Network, jejich oddělené sítě, a u databáze vypněte veřejnou adresu. Samotné připojení do privátní sítě internet neodřízne, dokud veřejná adresa zůstane zapnutá. Záložní uzel vysoké dostupnosti je pořád stejný region. Výchozí záloha je jednou denně a drží se sedm dní. Zkouška obnovy je pořád na vás. Adresy uvnitř té sítě omezit nejde, takže v ní nechte jen backend, který k databázi chodí.

U komunitního Postgresu je výchozí strop typicky 100 souběžných spojení. Aplikace, která si na každý požadavek otevře nové, ten strop vybere, zatímco procesor ještě zahálí. Aplikace proto drží malou sadu otevřených spojení a požadavky si je půjčují. Víc instancí, z nichž každá otvírá spojení bez stropu, položí databázi samotným přihlašováním.

Přílohy, exporty a dokumenty patří do bucketu, ne na disk backendu. Disk kontejneru se při nasazení zahodí. U bucketu se nastaví, kdo soubor smí číst, jak dlouho zůstane a jestli je v něm osobní údaj. Veřejný bucket s odhadnutelným názvem souboru je únik.

E-mail, vyhledávání a cache jsou další služby, každá s vlastním výpadkem a vlastní položkou na účtu. Fronta má jedno jasné použití. Uživatel nemá čekat na export, import nebo dávku oznámení. Aplikace uloží úlohu, vrátí stav a proces na pozadí ji dodělá. Úloha musí jít spustit podruhé bez druhého efektu, protože zpráva se občas doručí znovu. Fronta přidaná jen proto, že ji mají velké firmy, je další místo, kde se úloha ztratí.

Nasazení se musí umět zopakovat a vrátit

Ruční nahrání souborů na server vydrží do první chyby v pátek. Potřebujete verzovaný kód, nasazení, které stejné prostředí postaví znovu, a cestu zpět na předchozí verzi. Automatické testy se vyplatí na tocích, kde se chyba opakuje draze: přihlášení, platba, změna oprávnění, export. U zbytku obrazovek je krátká ruční kontrola užitečnější než rozsáhlá sada testů, kterou nikdo neudržuje.

Hesla, klíče a adresy cizích služeb nepatří do repozitáře ani do chatu. Patří do úložiště tajemství, kam se chodí na jméno. Twelve-Factor to říká přímo: konfigurace patří do prostředí, ne do kódu. Při převzetí cizího projektu je to pořád jeden z prvních nálezů.

Migrace databáze je součást nasazení, ne skript puštěný ručně až potom. Přidání sloupce za běhu obvykle projde. Přejmenování sloupce nebo rozdělení tabulky, zatímco stará verze aplikace ještě běží, potřebuje chvíli obě podoby dat. Tohle se řeší, dokud produkt nemá víc platících firem a každé nasazení není zásah do jejich práce.

Staging má být menší než produkce a bez jejích osobních údajů. Kopie produkce do stagingu je druhé úložiště, často s volnějším přístupem. Stačí anonymizovaný vzorek nebo vygenerovaná data. Staging, do kterého nikdo měsíc nepřišel, se vypne. Zůstane popis, podle kterého ho postavíte znovu.

Bezpečnost je kdo kam smí

Při převzetí aplikace škoda málokdy začíná složitým útokem. Široká oprávnění, jedno sdílené heslo do produkce, neaktualizovaná knihovna, veřejné úložiště. Přístup do produkce má být na jméno, aby šlo dohledat, kdo se přihlásil. Produkční databáze není pracovní nástroj pro každého, kdo píše kód. Změna bankovního účtu, smazání a export osobních údajů mají kontrolu na serveru a záznam: kdo, co, kdy.

Evropský region neříká, co se s údajem děje. Potřebujete vědět, kde vznikne, kam se uloží, kdo ho čte, jak dlouho zůstane a jak se smaže. Z toho vyplyne, jestli smí do logu, do stagingu, do e-mailové služby nebo k dodavateli. Až potom jde audit nebo požadavek zákazníka vyřešit bez přestavby. Jak ta pravidla vypadají v kódu, je v aplikační bezpečnosti. Když systém přebíráte a nevíte, co je veřejně dostupné, začátek je audit bezpečnosti aplikace.

Pomalou obrazovku neřeší větší server

Seznam při každém otevření spojí několik tabulek, v cyklu se ptá na každý řádek a znovu načte stejný číselník a stejná oprávnění. V testovacích datech to projde. Na produkčním objemu se čekání násobí. Větší server pošle stejnou práci rychlejšímu stroji.

Pořadí zásahů:

1. Přestat se ptát na to, co obrazovka nepotřebuje. Stránkování, jen použité sloupce, jeden dotaz místo desítek, součty předpočítané tam, kde se s každým otevřením nemění.
2. Index na sloupec, podle kterého se opravdu filtruje a řadí, a jen když měření ukáže, že dotaz čte zbytečně velkou část tabulky. Index to čtení zrychlí a zápis zpomalí, protože ho Postgres musí udržovat. Index bez dotazu, který ho použije, je další práce při každém uložení. Běžné vytvoření indexu navíc blokuje zápis do tabulky, dokud není hotový. Na velké tabulce v produkci se staví souběžně, aby zápisy mohly pokračovat.
3. Cache na data, která se čtou pořád a mění zřídka: relace, oprávnění, číselníky. U jedné instance stačí paměť procesu. Ta zmizí s nasazením a mezi instancemi se nesdílí. Redis se vyplatí, když instancí běží víc, nebo když po nasazení nechcete, aby všichni najednou sáhli do Postgresu pro stejný číselník. Cache nespraví dotaz, který prochází celou tabulku. Po vypršení se vrátí, a když vyprší všem najednou, databáze dostane náraz. Do cache patří jen údaj, u kterého je jasné, kdy zastará, a nepatří tam data jiné firmy.
4. Teprve potom větší databáze, další instance aplikace nebo kopie pro čtení. Další instance při pomalé databázi zátěž zhorší. Víc procesů sahá do stejného Postgresu stejným způsobem.

Jak to vypadá v datovém modelu a v kódu, je v článku jak připravit aplikaci na škálování.

Automatické škálování má místo u zátěže, která přijde a zase spadne, třeba u nárazového exportu. U předvídatelného B2B provozu je levnější kapacitu hlídat a zvednout ji vědomě. Platíte za výkon a za každou část, kterou musíte v noci umět přečíst.

Od začátku proto sbírejte chyby aplikace, dobu odezvy důležitých obrazovek, pomalé dotazy, délku fronty a neúspěšné úlohy. Z nich musí jít říct, co se stalo, která verze to spustila a jestli to postihlo jeden účet, nebo všechny. Co z toho hlídat po spuštění, popisuje správa SaaS platformy po spuštění.

Účet ukáže, co nikdo nehlídá

Na faktuře aplikace sama vidět není. Vidět je databáze ve stagingu ve stejné velikosti jako produkce, logy bez doby uchování, staré snímky disků a zapomenuté soubory. A přenos. Na AWS se NAT gateway účtuje za každou hodinu, kdy existuje, a za každý gigabajt, který přes ni projde, i když už nikdo neví, proč vznikla. Mezi zónami dostupnosti se platí i provoz, který mohl zůstat v jedné. U Scaleway je stejný typ položky Public Gateway: dokud běží, účtuje se za hodinu. Odchozí data jsou u ní v ceně, gigabajty navíc jako u NAT gateway ne. Na cestu z backendu k Postgresu ji nepotřebujete. Tu řeší Private Network.

Vývoj má vidět, která volba účet hýbe. Pomáhají hlášky na rozpočet, oddělený projekt pro produkci a pro staging a občasný průchod služeb, které produkt opravdu používá. Levnější provoz bez monitoringu nebo bez vyzkoušené zálohy ten účet jen přesune do výpadku.

Záloha, kterou nikdo neobnovil, je soubor. Obnova se zkouší na kopii: jak dlouho trvá, kolik dat chybí, jestli aplikace potom naběhne. Záložní instance v druhé zóně kryje pád serveru. Nekryje příkaz, kterým někdo smaže tabulku. Na to je obnova k času před tím smazáním. Druhý region kryje výpadek celého regionu a znamená druhou sadu služeb plus postup, který musí někdo občas projet. Dokud firma neřekne, kolik stojí hodina výpadku a kolik dat smí zmizet, stačí jeden region, automatická záloha a vyzkoušená obnova. AWS Well-Architected bere periodickou zkoušku obnovy jako samostatný požadavek, ne jako dodatek k zapnutým zálohám.

Kdy infrastrukturu měnit

Signál je opakovaný konkrétní problém. Pomalé dávky. Nasazení, které pravidelně končí ručním zásahem. Databáze na stropu spojení nebo disku. Požadavek oddělit data zákazníků. Nová integrace, která padá jinak než zbytek systému. Jeden zásah, změřený výsledek, další vrstva až potom.

V Nextrey bereme infrastrukturu jako součást provozu produktu. Kód, databáze, nasazení a dohled mají sedět na to, co aplikace dělá teď, a nemají blokovat další změnu.

Časté otázky

Stačí na začátek Kubernetes?

U jednoho produktu s malým týmem skoro nikdy. Spravovaný backend a spravovaný Postgres pokryjí nasazení i základní obnovu. Kubernetes se začne vyplácet, až když máte víc služeb s různým rytmem vydání a někoho, kdo ho provozuje.

Nahradí spravovaná databáze práci s daty?

Bere aktualizace systému, zálohy a volitelně přepnutí na záložní instanci. Schéma, dotazy, indexy, přístupy a zkouška obnovy zůstávají na týmu, který aplikaci píše.

Kdy má smysl Redis?

Když stejná data čte víc instancí, mění se zřídka a umíte říct, kdy jsou neplatná. Relace, oprávnění, číselníky. Redis nespraví dotaz, který prochází celou tabulku. U jedné instance často stačí cache v paměti procesu.

Potřebujeme dva regiony?

Až když znáte cenu hodiny výpadku a přijatelnou ztrátu dat, a jeden region s vyzkoušenou obnovou na to nestačí. Do té doby druhý region zdvojí služby a postupy.

Zdroje

• PostgreSQL: Indexes. Index zrychlí čtení konkrétních řádků a přidá režii při změnách dat. Má se používat s rozumem.
• PostgreSQL: CREATE INDEX. Běžné vytvoření indexu blokuje zápis, dokud neskončí. CONCURRENTLY zápis pustí dál.
• PostgreSQL: max_connections. Výchozí strop je typicky 100 souběžných spojení.
• The Twelve-Factor App: Config. Konfigurace a tajemství patří mimo repozitář, do prostředí.
• AWS Well-Architected, REL09-BP04. Záloha se periodicky obnovuje a ověřuje. Zapnutá záloha sama o sobě obnovu nedokazuje.
• Amazon VPC pricing. NAT gateway se účtuje za hodinu, kdy běží, a za zpracovaná data.
• Scaleway: Managed Database for PostgreSQL. Záložní uzel vysoké dostupnosti, výchozí záloha jednou denně po sedm dní. Veřejnou adresu je potřeba vypnout zvlášť.
• Scaleway: Network pricing. Public Gateway se účtuje za hodinu, kdy běží.
• GDPR, nařízení 2016/679. Článek 5 (omezení uložení) a článek 32 (zabezpečení zpracování). Samotný region tok údajů nepopisuje.