Názory k článku Databáze pro 900 milionů obrázků aneb pořádný cluster v Seznamu

Nevim jak je to u seznamu, ale ve spouste firem se setkavam s tim, ze zaplatit kvalitni adminy nikdo nechce takze to obvykle konci stylem devops kde se ignoruje security a developer ma operations v ramci 5% sve pracovni naplne. Obecne to pak stoji za prd ale firmy pry usetri.

Dobrý DevOps je ještě o dost dražší než dobrý programátor protože lidí, co by to chtěli dělat je málo a tak je jich málo i na trhu. A programátoři to dost často víceméně zvládají. Natolik, aby to fungovalo. Na druhou stranu vývojáři, co si umí infrastrukturu nějak rozumně spravovat jsou taky podstatně dražší i když ne o tolik. A pochopitelně, jak píší ostatní, to nikdy neudělají tak kvalitně.

Obecně mě to ale u Seznamu moc neudivuje. Znám až podezřele hodně lidí, co u Seznamu pracovali a už nepracují. Možná mám jen smůlu, ale obecně tam řada týmů (i když určitě jsou lepší a horší) poněkud působí jako průtokový ohřívač vývojářů.

Prosím ano, je to tak docela často. To je takovej korporátní mindset, že se tím něco ušetří. Ve výsledku potom dělají všichni všechno a nikdo nic pořádně.

V Seznamu tihle věci drží srdcaři a spousta času, který tomu věnují, minimum znalostí si importují (přes nábor, nákupem), ale vytváří si vlastní.

Opačný přístup je hodně unikátní, administrátoři mají zpravidla plné ruce práce a právě devops je způsob, jak se programátoři mohou zapojit do administrace a hlavně tomu dát nový nádech automatizace.

No, zase z mé zkušenosti se mnou i s kolegy: programátoři si sice to, co vyvíjí administrují celkem rádi a nedá se říci, že by nechtěli, naopak, ale nemají na to chronicky čas a automatizaci toho celého nechce řešit/programovat už vůbec nikdo protože to je vyloženě otrava a tomu, kdo vás platí se to navíc prodává fakt blbě.

Ano, automatizacia na strane administratorov to je velka bolacka. A este co take dnes administruju? Vsetko je v cloude, maju za robotu uz iba automatizovat nasadzovanie.

tak jestli delate taky devops, tak musite videt ty bolesti celeho SRE. paradoxne je nasazeni na skutecne zelezo naprosta trivka oproti cloudu

ano, zlatý železo :).

Jen třeba k AWS a službám, které u jednoho projektu používáme mám asi 5 000 řádků poznámek.

Každá služba se chová lehce jinak, všechno potřebuje poměrně složité a nedetermistické nastavení (a to ještě je jinak řešené v cli, api a web ui), špatná testovatelnost a ověřitelnost, logy (systémové a aplikační) bez contextu k dané změně nebo stavu atd.

K tomu časté změny v čase, potřeba restrukturovat a validovat řešení z pohledu bezpečnosti, nákladů, spolehlivosti, ten proces je neustálý.

Vždyť dnes infrastrukturní kód pro běžné enterprise systémy je složen ze stovek tisíc řádků kódu (kombinace terraform, helm chart, ansible, bash a jiná zvířátka). Tohle není rozhodně jednodušší než fyzický HW.

Je mi příjemnější stavět projekty na vlastním HW.

“Na serveru byl ve výchozím stavu povolený, ale z nějakého důvodu nefungoval. Proto jej explicitně zakázali a od té doby to funguje.”
Z nejakeho duvodu? Nebylo by lepsi najit ten duvod misto vytvareni dalsich session?

V okamžiku, kdy vám DevOps dělají vývojáři na to, ze zkušenosti, prostě není čas protože máte co dělat, abyste stíhal i svou vlastní primární práci a infrastruktura nějak fungovala.

... Záznamy v DNS sice mají nějaký TTL, ale v prostředí k8s se IP mohou měnit velmi často. ...

A to je nutnost, ta změna IP?? Bez ní by to nešlo??

Hadam, ze to bude vyhnuti se micromanagementu ip adres, ono kdyz se to dela pres milion lokalit, tak uz je to trochu jine kafe. Sam to vidim u nas, zkousime rozjet druhou lokalitu a kdybych tu VM prehodil do druhe lokality, tak umre na nedostupnost site, ktera je pouze v puvodni lokalite...

A pak ti vyvojari ze Seznamu utekli, protoze s takovymi znalostmi K8s muzou delat za lepsi penize v zahranici :-)

Ale z jineho pohledu. Ja treba v playbooku vytvareni/for­matovani disku radeji ani nemam. Tolik serveru nespravuji a to riziko je vysoke. Tolik redundanci nemam, programovat veskere ochranne body neumim. Ano, mozna bych mohl pouzit referencni playbooky misto kompletne vlastnorucne napsanych, takze bych mohl mit rovnou integrovane nektere ochrany.

Kazdopadne zajimavy clanek. Mozna by se hodilo i zhruba pripsat, jak velky tym to byl a kolik mandays na tom stravili.

U nas se nekteri vyvojari uci zautomatizovat vytvareni jednoho typu kontejneru. Predstava, ze by dokazali treba cely frontendovy stack (nginx,php,etc), je zatim hodne vzdalena. Pri vyvoji hlavniho produktu nestihaji treba zmodernizovat stare veci.

Jednak ty "lepší peníze" v Evropě moc nedostanete, často spíš naopak, a druhak tam, kde ano jsou zase úplně jinde životní náklady, zvlášť pokud máte rodinu. Zrovna co se peněz týká se IT v ČR za posledních deset let dost srovnalo s okolím a zhusta jsme na to zvlášť při započítání životnách nákladů lépe. A to nemluvím o ceně bídné existence expata nebo práce na dálku. Ani jedno opravdu není pro každého.

Smysl má pracovat možná ve Švýcarsku v daňově výhodných kantonech nebo v SAE. Protože ten rozdíl ve výsledku dělá v podstatě jen zdanění. Což je ale dost peněz.

Seznam platí málo. Na "lepší peníze" dosáhnete kdekoliv jinde a to i v ČR.

a přitom, když projdeš porodními bolestmi, už to nechceš nikdy dělat ručně. Díky automatizaci disků se zavedou automatické zálohy, redundance, restory, snapshoty, narovná se to, kde je vlastně persistentní stav a je je pouze dočasný, flexibilnějši se to celé rozšiřuje a pak můžeš mít i jednotlivé datasety pro aplikace, víš kolik ti přesně jaká bere a snadno můžeš odmazávat ty staré. Snadněji pak tu práci předáš někomu jinému, nemusíš vše kontrolovat, protože máš proces, jak s chybami pracovat a vyřešit je.

U jednoho projektu nám teď odpadlo celé DC (cca 120 serverů, cca 2000 disků) a třetinu bylo potřeba přeisntalovat úplně, obnova nám zabrala pár hodiny, protože jsme to mohli spustit vše najednou, přesně jsme věděli, která data nemáme ani v jedné replice a mohli jsme je vytáhnout cíleně z pásek ještě dřív než se zbytek obnovil. Zatímco u jiných systémů tam admini lítají doteď, instalují, spouští rsync, porovnávají výstup ls.

Pekne. Ale logicky predpokladam, ze takovahle IaaC neni prace jednoho cloveka a cena sw licenci taky bude <> 0.

špatný předpoklad, práce jednoho člověk a vše nad open source (výjma platby za Oracle linux podporu). Trvalo to asi dva roky než se to celé poskládalo a vyladilo, vše ale za produkčního provozu.

Proc?

Proc vubec delat novy cluster? Proc ted? Proc TiDB? Proc vlastni cluster? Proc 8 clusteru? Proc se bavit o 3k rps? Proc, proc, proc...?

Clanky od seznamaku moc nechapu. Na rootu jsem jich zkouknul v poslednich letech celou radu. Dlouze popisuji "co" a zadne "proc". I to "co" ktere clanky popisuji vyvolava vic otazek nec odpovedi. Jak ten konkretni tym premysli, jak funguje a jake ma priority? A co Seznam jako celek, jako firma?

BTW: Jaka je vlastne Vase role Honzo? O adminech i vyvojarich mluvite ve treti osobe.

Obávám se, že tu všichni zapomínáte, že to je produkt internetové korporace. Ve skutečnosti to není DB obrázků, ale sběr a analýza osobních dat. Na to je tak 3/4 té technologie, protože to je ten byznys...

8. 12. 2023, 07:32 editováno autorem komentáře

Protože Seznam. Každý dnes dělá storage S3 kompatibilní, ale v Seznamu přemýšlejí jinak.

Nebylo by jednodušší použít třeba ScyllaDB či Cassandru a nad to dát jen frontend?
Nebo CEPH a ukládat to jako objekty. Klidně jako S3 compatible API ať je to univerzálnější?

Či je nějaký zásadní důvod, proč zvolit tohle řešení?

tipuji, že právěže ne. Scylladb si sebou nese velká omezení, které má CQL, škálování také nic moc, failover peklíčko, občas chyby v kódu, divná komunita, se nedivím, že to nepoužili.

Ceph a 900m souborů? Nebude z toho nadšený, on to uloží, ale jakákoliv správa té haldy zanořených složek bude peklíčko, hlavně budeš muset udržovat stejně někde jinde metadata k souborům, shardovat to do složek podle checksumů a jiné voloviny, ta obrovská fragmentace ti Ceph prostě zatíží.

Object gateway (ala s3) ti problém správy řeší jen částečně, ale jakékoliv skenování, retence, validace je bolest, zejména v takovémhle množství, opět budeš muset mít nějaký storage na metadata. To se nevyplatí pro malé objekty.

Prijde mi to jako softwarove peklo, tam mit tolik vrstev :D

Skoda ze se nezminuje konfigurace jednotlivych nodu po hw strance - kolik jich tam bylo, v jake cpu/ram/disk konfiguraci a tak.. a zda se treba meni pocet nodu podle zateze, nebo se spoleha na to ze je zatez konstantni behem 24h a ze to servery uhrajou na idle. Pripadne kolik % je load a kolik to ma rezervu do budoucna.

Prijde mi to jako softwarove peklo, tam mit tolik vrstev

Asi tak.

Jde v podstatě o 30TB DB, průměrná velikost záznamu je 33kB, ve špičce 90MB/s velmi snadno cachovatelných záznamů. (Vše je z tohoto článku.) Takže v podstatě o nic nejde.

Na druhou stranu pokud jsi omezený na použití kubernetu, moc jiných cest nemáš, Seznam to tlačí dost na sílu, TiDB je jedna z mála SQL databází (really), které dobře v takovém prostředí fungují.

Tlačí to teď všichni, co nám ve fyzickém světlě zvládá cluster o 6 serverech najednou musíme dávat do k8s na 200 podů a ještě pořád řešíme IOPS problémy, lagy a latence.

Ano, když to člověk porovná, rozdíl je zatím propastný, dnes máme DB nody s 20 - 100 TB dat, které saturují 40GbE síť, stojí 1 - 2 míče v korunách, to je něco co zvládne obsloužit provoz kdekoho a spíše než výkon tak se řeší dostupnost a latence. Problém je, že abys to vybudoval, potřebuješ spousty specializovaných lidí (síťaři, admini, devops, programátoři), zatímco systémv v kubernetu dokáží celý postavit, spravovat a připravit jenom chytřejší programátor, což je asi i tenhle případ.

Rozumím výhodám, je to daleko flexibilnější, ale přináší to nové výzvy a hlavně to posouvá zase výkonnostní efektivutu někam dozadu.

Co by jste navrhoval dela delat a proc?

Precetl jsem si vsechny komentare. Mate nejvice prispevku a vypada to, ze i zkusenosti. Trohu se v tom ale ztracim. Vic "zelezo"? Obnova "z pasek"? IOPS?

Co by jste doporucil firme, ktera by chtela pouzivat vlastni fyzicke servery, a dala vam volnou ruku? Rekneme 100 serveru (jak zminujete) nebo treba seznam s 10k (?) servery?

Je super, že takové články vznikají, ale chtělo by to zapracovat na jasnosti a struktuře sdělovaných informací.

Seznam má tři datacentra, která dále (spíše už logicky a ne jako např. AWS) dělí na tři AZ. A teď jsou celkově tři repliky dat rozdělené na všechny datacentra, nebo AZ? Ten diagram mi to nijak dál neosvětluje, autor mě diagramem neprovedl a mě tak výmluvný nepřijde.

Jak už bylo poznamenáno v diskuzi, 30 TB dat a 900 Mio. souborů a 3 000 req./s není zas až tak moc. Zdá se, že převládá čtení. Co v tomto případě přesně Kubernetes přináší např. oproti původnímu systému a obecně? Jak vypadá třeba vytížení v čase? Jak se testovaly patologické souhry (viz např. https://jepsen.io/ : "Together with PingCAP, we tested TiDB 2.1.7 through 3.0.0-rc.2, and found that by default, TiDB violated snapshot isolation, allowing read skew, lost updates, and incompatible orders, thanks to two separate auto-retry mechanisms which blindly re-applied conflicting writes. 3.0.0-rc.2 changed the default settings to provide snapshot isolation by default, as well as fixing a race condition in table creation, and some crashes on startup.")?

Moje zkušenost je, že rozkládat věci náročné/ější na IOPS a současně synchronizaci do co nejvíce uzlů je vysoce kontraproduktivní, protože mě často režie stojí kalhoty.

Proč se nehodily jiné prominentní produkty, např.: https://www.cockroachlabs.com/docs/stable/why-cockroachdb
Pro porovnání TiDB: https://docs.pingcap.com/tidb/stable/overview
Nějakou diskuzi by člověk mohl najít třeba zde: https://news.ycombinator.com/item?id=15499404

Proč ne Min.IO: https://min.io/docs/minio/kubernetes/upstream/ nebo Garage: https://garagehq.deuxfleurs.fr/documentation/cookbook/real-world/, když jde vlastně jen o to ukládat obrázky a replikovat je všude možně? Případně co Ceph Object Gateway?

On švábDB na tom není o moc lépe pokud jde o transakce, izolace, spolehlivost.

TiDB ukládá data do velkých souborů a postupně si je kompaktuje, FS pod tím nemusí spravovat 900 mio souborů. MinIO jede striktně erasure coding a každý block je jeden soubor na disku, tj. tohle mi udělá pětinásobek souborů na FS, což zrovna není sranda na správu (jeden náš český operátor tohle ladí už dva roky). Garaga je moc pěkný projekt (používám), ale chybí tomu spousty věci, třeba schopnost ověřit zapsaná data, snapshoty, má problémy s připojením více klientům (protože interně třeba thread pool a frontování požadavků přidali nedávno a ještě to není ono).

A důvodem je nejspíš opravdu to, že Seznam se rozhodl vše mít primárně na kubernetu a tlačí všechny projekty do použití kubernetu, stejně jako jinde. Ty pak těch alternative tolik nemáš, protože tě na HW přímo nepustí, jen ti dají přístupy a endpointy, podobné schéma zažívám i na jiných projektech a zrovna jak píšeš, dělat jakoukoliv databázi na spoustě uzlů je zlo, shardering postupně kupodivu mizí a objevují se tyhle mesh projekty, s kterými je buď dost práce nebo vlastně netuším, jestli tam jsou data uložena správně. Tady to mají jako storage pro obrázky, snapshot isolation je jim asi putna, stejně to jedou asynchronně a nepotřebují aktualizaci in time všude.

Ano a podla mna je to cele prearchitektovane. Dame tam tuto DB ta je teraz IN. A pouzijeme mikroservisy (z toho mam uz vyrazky) lebo ... je to moderne.
Pritom sa zasadne zabuda ze najvacsia bolacka v kubernetes je storage. Bud si sluzby napinujete na server a pouzijete nativny storage alebo pouzite nejaky cloud storage a ten je pomaly pokial do toho nenahadzate fakt VELKEEEE peniaze.

ano a když už použiji nějaký silný cloud storage, tak narazím na to, že z kubernetu horko těžko vytáhnu něco víc než 10GbE z nodu, a i to znamená nemalé úsilí toho dosáhnout (děláme storage servery s 4 x 56GbE pro srovnání)

Ne, dnešní kubernet není vhodný na cokoliv, co je diskově intenzivní (iops nebo velikost), stejně ta není vhodný pro cokoliv, co potřebuje extrémně moc výpočetní zdrojů (trénování AI) nebo extrémní síťový provoz.

Snaha mít vše nad jedné technologii je logická a člověk to chce mít jednotné, bohužel ne vše se pak dá provozovat. Zatím nejvíce času s kubernetem trávíme právě ohejbáním ho pro nestandardní situaci a nikoliv provozování těch standardních, pak to paradoxně práci přidává a ne naopak. Ono si to ale v podstatě děláme sami.

Mě přijde, že je důležité dívat se na celkové úsilí a výsledek. Mě by asi nebavilo provozovat spousty strojů, které něco stojí na pořízení a na provoz, jenom protože je někdo umanutý z pohledu technologie.

To je asi jako prohlížeče, kde převládá mýtus, jak jsou strašně dobře udělané a rychleji to nejde. Potom zjistíte, že je problém i jen rozumný rendering písma, nedej že někdo chce animovat pár boxíků a dokonce stínů. V roce 2023 je asi problém rozpoznat, že hýbu nějakým výsekem obrazu, který se nemění, nebo je třeba mimo viewport.

Kubernetes jsem zatím řešit nemusel. Myslím, že to neřeší podstatu problému v IT, která pramení z toho, že se stavem se v drtivé většině programovacích jazyků a asi i hardwaru pracuje poměrně špatně a je to náchylné na chyby. Že se většina softwaru nedá spolehlivě updatovat za běhu a že se systematicky nezjednodušuje/ neuklízí, ale spíše nabaluje.
Tak se vymýšlí po 150té izolace, virtualizace, nějaký management/ accounting toho všeho. Nikdo už nerozumí věcem nějak víc napříč a vytrácí se nadhled.

A přijde mi, že hysterie jako blockchain a dnes AI tomu všemu nepomohly. Hodně chytrých lidí řeší něco, co je postavené na příliš vratkých základech. Místo aby se šlo, a ty základy se udělaly robustnější, tak se to celé radši zalije dalšími miliony řádků kódu.

"Nikdo už nerozumí věcem nějak víc napříč a vytrácí se nadhled."

Typicky vyvojar cehokoli je lepic kodu, ktery pouziva horu vsemoznych knihoven, o kterych ani nevi, co vlastne delaji. Vysledky tomu dokonale odpovidaji ... mam zaznam z konfery jednoho dodavatele, kde jejich vlastni zamestnanec oznacil jejich vlastni aplikaci za ''s.cku' ;D. A legranda na tom bylo predevsim to, ze z presne stejneho duvodu jsem ji takhle pred 15 lety oznacil ja (coz kdyz sem mu dohledal tak nechapal, proc to uz davno neni predelany).

Pokud pujdes niz k HW, tak typicky nikdo netusi ani teoreticky jak to funguje. Takze se pak nediv, ze se ti generujou treba hromady IO na disky tam, kde by se krasne dala pouzit cache ... atd atd atd.

Update za behu? Neblazni, tohle sem delal na 8mibitech ... to je doslova vesmirna hypertechnologie.

Jak asi ukládá obrázky třeba Facebook? Někde jsem četl že to celé běžá na MySQL nakonfigurované jako NoSQL DB..
https://engineering.fb.com/2016/08/31/core-infra/myrocks-a-space-and-write-optimized-mysql-database/

No, ale tam se taky dočtete, že storage engine mají kompletně vlastní.