Zpracování dat v AVG backendech Antonín Karásek <antonin.karasek@avg.com> Jarek Jarcec Čecho <jaroslav.cecho@avg.com>
Backend systémy Co je od nás vyžadováno zpracování uživatelských dat vytváření reportů pro management generování životně důležitých dat pro samotné klienty Dva hlavní projekty IDP Firewall Nejsme sami: PrevCar Aktivní diplomové a dizertační práce
IDP Váš ochránce identity Behavior detekce na straně klienta heuristické identifikování podezřelého chování velké množství false alarmů IDP Backend naše práce možnost klienta zkontrolovat si validitu detekce snižuje false alarmy generuje krásné flashové grafy vhodné pro management
IDP Backend Rozdělen na dvě hlavní části: web facing servery zautomativoné zpracování vzorků Web facing servery umožnují verifikovat klientskou detekci Tati je to dobře? v případě nového nálezu umožnují posílat vzorky Nevím, pošli mi to nezbytná služba pro IDP klienta
IDP Backend II Zautomatizované zpracování vzorků přijímá dosud neznámé nálezy od klientů provádí na nich automatizované analýzy rozhoduje zda-li se opravdu jedná o malware či nikoliv automatizace není dokonalá Některé klasifikace provádí až člověk
Firewall Další komponenta AVG (stejně jako IDP) Vyžaduje pozornost uživatele Přejete si aplikaci skype.exe povolit přístup na Internet? Velice nežádoucí Sbírá a sumarizuje statistiky provozu: jaká aplikace z jakého lokálního portu na jaký vzdálený port anonymní, žádné IP Posílá tyto informace backendu Backend: sumarizuje data přes všechny uživatele pracovníci firewall teamu na jeho základě generují whitelisty opět generuje krásné flashové grafy
Provozování backend systémů Konečně ta zajímavá část Naše praktické zkušenosti AVG má 100 000 000 uživatelů world wide všichni pořád něco chtějí vysoká zátež nezbytnost udržet systémy v high availability běhu celý svět najednou nikdy nespí
Ext3 i-node problém Problém: klient posílá sumarizované XML s daty Přímočará implementace 250 000 souborů za hodinu: Potřeba uložit a následně zpracovat Kam s tím mkfs.ext3 vyhrazuje bloky pro i-nody vnitřní fragmentace Výsledek: opticky 50% volného místa nemožnost vytvořit nový soubor
Ext3 i-node problém Řešením je jiný filesystém Zajimavé XFS, raiserfs (řeší vnitřní fragmentaci) XFS je úděsné pomalé pro práci s malými soubory cca 3x zpomalení v našich testech Skončili jsme na raiserfs Stále neřeší probém s velkými a pomalými adresáři Konečné řešení: balit soubory na vstupu do tarů 100 XML na jeden tar archív výrazné zlepšení výkonu
Sumarizace statistik Jaká aplikace je mezi uživateli nejvíce reportovaná...patří na whitelist Přímočará implementace: data ukládat do MySQL Za den cca 500 000 000 řádků odpověd na úvodní otázku zabere více než 24 hodin generování statistik na denní bází navíc ani nestíhá ukládat všechna příchozí data těch otázek je krapánek více
Sumarizace statistik Naivní řešení: ukládat do CSV souborů UNIX utility: sort, uniq výsledek na všechny otázky za 3 hodiny Problémy: CSV neukládá sémantiku, problematické změny není schopno odpovídat na nově vzniklé dotazy Budoucí postup: Hadoop
Fronta úloh Potřeba distribuovat úlohy pro workery Analyzuj tento soubor Hloupá implementace: by MIT fronta úloh v MySQL databázi 10 000 úloh za hodinu Vytvořit (insert), zabrat (update), dokončit (update) 30 000 DB operací za hodinu MySQL nemá rádo velké tabulky (snižuje se výkon) nulová možnost distribuovatelnosti Fronta úloh byla součástí centrální databáze ještě nižší výkon
Fronta úloh Řešení: Použít specializované a optimalizované nástroje Gearman plně distribuované řešení úlohy v paměti (volitelně i trvalejší uložiště) Problémy úlohy v paměti nemáme turingovy stroje, paměť může dojít možnost řešit ještě více gearman servery (distribuovat)
Konec Omlouváme se mnoho textu pro tuto pokročilou hodinu Dotazy? Náměty? Připomínky? Žádosti o zaměstnání?