Как ние в CIAN опитомихме терабайти от регистрационни файлове

Здравейте на всички, казвам се Александър, работя в CIAN като инженер и се занимавам със системно администриране и автоматизация на инфраструктурни процеси. В коментарите към една от предишните статии бяхме помолени да кажем откъде получаваме 4 TB регистрационни файлове на ден и какво правим с тях. Да, имаме много регистрационни файлове и е създаден отделен инфраструктурен клъстер за тяхната обработка, което ни позволява бързо да решаваме проблемите. В тази статия ще говоря за това как го адаптирахме в продължение на една година, за да работи с непрекъснато нарастващ поток от данни.

Откъде започнахме

През последните няколко години натоварването на cian.ru нарасна много бързо и до третото тримесечие на 2018 г. трафикът на ресурсите достигна 11.2 милиона уникални потребители на месец. По това време в критични моменти загубихме до 40% от регистрационните файлове, поради което не успяхме бързо да се справим с инцидентите и отделихме много време и усилия за разрешаването им. Също така често не можехме да открием причината за проблема и той се появяваше отново след известно време. Беше ад и трябваше да се направи нещо по въпроса.

По това време използвахме клъстер от 10 възела за данни с ElasticSearch версия 5.5.2 със стандартни настройки на индекса за съхраняване на регистрационни файлове. Той беше представен преди повече от година като популярно и достъпно решение: тогава потокът от трупи не беше толкова голям, нямаше смисъл да се измислят нестандартни конфигурации. 

Обработката на входящи регистрационни файлове беше осигурена от Logstash на различни портове на пет координатора на ElasticSearch. Един индекс, независимо от размера, се състоеше от пет фрагмента. Организирана е почасова и ежедневна ротация, в резултат на което около 100 нови фрагмента се появяват в клъстера на всеки час. Въпреки че нямаше много регистрационни файлове, клъстерът се справи добре и никой не обърна внимание на настройките му. 

Предизвикателствата на бързия растеж

Обемът на генерираните регистрационни файлове нараства много бързо, тъй като два процеса се припокриват. От една страна, броят на потребителите на услугата нараства. От друга страна, започнахме активно да преминаваме към архитектура на микросервизи, разрязвайки старите си монолити в C# и Python. Няколко дузини нови микроуслуги, които замениха части от монолита, генерираха значително повече регистрационни файлове за инфраструктурния клъстер. 

Мащабирането ни доведе до точката, в която клъстерът стана практически неуправляем. Когато регистрационните файлове започнаха да пристигат със скорост от 20 хиляди съобщения в секунда, честата безполезна ротация увеличи броя на фрагментите до 6 хиляди и имаше повече от 600 фрагмента на възел. 

Това доведе до проблеми с разпределението на RAM и когато възел се срине, всички шардове започват да се движат едновременно, умножавайки трафика и зареждайки други възли, което прави почти невъзможно записването на данни в клъстера. И през този период останахме без трупи. И ако имаше проблем със сървъра, ние всъщност загубихме 1/10 от клъстера. Голям брой малки индекси добавиха сложност.

Без трупи не разбрахме причините за инцидента и можехме рано или късно да стъпим отново на същото гребло, а в идеологията на нашия екип това беше неприемливо, тъй като всичките ни работни механизми са проектирани да правят точно обратното - никога да не се повтаря същите проблеми. За да направим това, се нуждаехме от пълния обем регистрационни файлове и тяхната доставка почти в реално време, тъй като екип от дежурни инженери наблюдаваше сигнали не само от показатели, но и от регистрационни файлове. За да разберем мащаба на проблема, по това време общият обем на регистрационните файлове беше около 2 TB на ден. 

Поставихме си за цел напълно да премахнем загубата на регистрационни файлове и да намалим времето за доставката им до клъстера ELK до максимум 15 минути по време на форсмажорни обстоятелства (по-късно разчитахме на тази цифра като вътрешен KPI).

Нов ротационен механизъм и горещо-топло възли

Започнахме преобразуването на клъстера, като актуализирахме версията на ElasticSearch от 5.5.2 на 6.4.3. За пореден път нашият клъстер версия 5 умря и решихме да го изключим и напълно да го актуализираме - все още няма регистрационни файлове. Така че направихме този преход само за няколко часа.

Най-мащабната трансформация на този етап беше внедряването на Apache Kafka на три възела с координатор като междинен буфер. Брокерът на съобщения ни спаси от загуба на регистрационни файлове по време на проблеми с ElasticSearch. В същото време добавихме 2 възела към клъстера и преминахме към горещо-топла архитектура с три „горещи“ възела, разположени в различни стелажи в центъра за данни. Пренасочвахме логовете към тях с помощта на маска, която не бива да се губи при никакви обстоятелства – nginx, както и логовете за грешки на приложението. До останалите възли бяха изпратени незначителни регистрационни файлове - отстраняване на грешки, предупреждение и т.н., а след 24 часа бяха прехвърлени „важни“ регистрационни файлове от „горещи“ възли.

За да не увеличаваме броя на малките индекси, преминахме от ротация на времето към механизма за преобръщане. Във форумите имаше много информация, че ротацията по размер на индекса е много ненадеждна, затова решихме да използваме ротация по броя на документите в индекса. Анализирахме всеки индекс и записахме броя на документите, след които ротацията трябва да работи. Така достигнахме оптималния размер на шарда - не повече от 50 GB. 

Клъстерна оптимизация

Въпреки това не сме се отървали напълно от проблемите. За съжаление все още се появяват малки индекси: те не достигнаха определения обем, не бяха ротирани и бяха изтрити чрез глобално почистване на индекси, по-стари от три дни, тъй като премахнахме ротацията по дата. Това доведе до загуба на данни поради факта, че индексът от клъстера изчезна напълно и опитът за запис в несъществуващ индекс наруши логиката на куратора, който използвахме за управление. Псевдонимът за писане беше преобразуван в индекс и наруши логиката на преобръщане, причинявайки неконтролиран растеж на някои индекси до 600 GB. 

Например за конфигурацията на ротация:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

Ако нямаше псевдоним за преобръщане, възникна грешка:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

Оставихме решението на този проблем за следващата итерация и се заехме с друг проблем: превключихме към логиката на изтегляне на Logstash, която обработва входящите регистрационни файлове (премахвайки ненужната информация и обогатявайки). Поставихме го в docker, който стартираме чрез docker-compose, и също поставихме logstash-exporter там, който изпраща показатели на Prometheus за оперативен мониторинг на потока от журнали. По този начин си дадохме възможност плавно да променим броя на инстанциите на logstash, отговорни за обработката на всеки тип журнал.

Докато подобрявахме клъстера, трафикът на cian.ru се увеличи до 12,8 милиона уникални потребители на месец. В резултат на това се оказа, че нашите трансформации са малко зад промените в производството и бяхме изправени пред факта, че „топлите“ възли не могат да се справят с товара и забавят цялата доставка на трупи. Получихме „горещи“ данни без грешки, но трябваше да се намесим в доставката на останалите и да направим ръчно преобръщане, за да разпределим равномерно индексите. 

В същото време мащабирането и промяната на настройките на екземплярите на logstash в клъстера беше усложнено от факта, че това беше локално докер композиране и всички действия бяха извършени ръчно (за да се добавят нови краища, беше необходимо ръчно да се премине през всички сървърите и направете docker-compose up -d навсякъде).

Преразпределение на регистрационните файлове

През септември тази година все още разрязвахме монолита, натоварването на клъстера се увеличаваше и потокът от трупи наближаваше 30 хиляди съобщения в секунда. 

Започнахме следващата итерация с хардуерна актуализация. Преминахме от пет координатора на трима, заменихме възли за данни и спечелихме по отношение на пари и място за съхранение. За възли използваме две конфигурации: 

• За „горещи“ възли: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 за Hot1 и 3 за Hot2).
• За „топли“ възли: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

При тази итерация преместихме индекса с регистрационни файлове за достъп на микроуслуги, който заема същото място като логовете на nginx от първа линия, към втората група от три „горещи“ възела. Сега съхраняваме данни на „горещи“ възли за 20 часа и след това ги прехвърляме на „топли“ възли към останалите регистрационни файлове. 

Решихме проблема с изчезването на малки индекси, като преконфигурирахме ротацията им. Сега индексите се сменят на всеки 23 часа във всеки случай, дори ако там има малко данни. Това леко увеличи броя на фрагментите (имаше около 800 от тях), но от гледна точка на производителността на клъстера е поносимо. 

В резултат на това имаше шест „горещи“ и само четири „топли“ възела в клъстера. Това причинява леко забавяне на заявките за дълги интервали от време, но увеличаването на броя на възлите в бъдеще ще реши този проблем.

Тази итерация също коригира проблема с липсата на полуавтоматично мащабиране. За да направим това, внедрихме инфраструктурен клъстер Nomad - подобно на това, което вече сме внедрили в производството. Засега количеството Logstash не се променя автоматично в зависимост от натоварването, но ще стигнем до това.

Планове за бъдещето

Внедрената конфигурация се мащабира перфектно и сега съхраняваме 13,3 TB данни - всички логове за 4 дни, което е необходимо за спешен анализ на сигнали. Преобразуваме някои от регистрационните файлове в показатели, които добавяме към Graphite. За да улесним работата на инженерите, имаме метрики за инфраструктурния клъстер и скриптове за полуавтоматично отстраняване на често срещани проблеми. След увеличаване на броя на възлите за данни, което е планирано за следващата година, ще преминем към съхранение на данни от 4 на 7 дни. Това ще бъде достатъчно за оперативна работа, тъй като винаги се опитваме да разследваме инциденти възможно най-скоро, а за дългосрочни разследвания има телеметрични данни. 

През октомври 2019 г. трафикът към cian.ru вече е нараснал до 15,3 милиона уникални потребители на месец. Това се превърна в сериозен тест за архитектурното решение за доставка на трупи. 

Сега се подготвяме да актуализираме ElasticSearch до версия 7. За целта обаче ще трябва да актуализираме картографирането на много индекси в ElasticSearch, тъй като те са преместени от версия 5.5 и са декларирани като остарели във версия 6 (те просто не съществуват във версия 7). Това означава, че по време на процеса на актуализиране определено ще има някакъв вид непреодолима сила, която ще ни остави без регистрационни файлове, докато проблемът бъде решен. От версия 7 най-много очакваме Kibana с подобрен интерфейс и нови филтри. 

Постигнахме основната си цел: спряхме да губим регистрационни файлове и намалихме времето на престой на инфраструктурния клъстер от 2-3 срива на седмица до няколко часа работа по поддръжка на месец. Цялата тази работа в производството е почти невидима. Сега обаче можем да определим точно какво се случва с нашата услуга, можем бързо да го направим в тих режим и да не се притесняваме, че регистрационните файлове ще бъдат загубени. Като цяло сме доволни, щастливи и се готвим за нови подвизи, за които ще говорим по-късно.

Източник: www.habr.com