Како ние во CIAN скротивме терабајти трупци

Здраво на сите, јас се викам Александар, работам во CIAN како инженер и сум вклучен во системска администрација и автоматизација на инфраструктурните процеси. Во коментарите на една од претходните написи, од нас беше побарано да кажеме каде добиваме 4 ТБ дневници дневно и што правиме со нив. Да, имаме многу логови, а создаден е посебен инфраструктурен кластер за нивна обработка, што ни овозможува брзо решавање на проблемите. Во оваа статија ќе зборувам за тоа како го приспособивме во текот на една година за да работиме со постојано растечки проток на податоци.

Каде почнавме?

Во текот на изминатите неколку години, оптоварувањето на cian.ru порасна многу брзо, а до третиот квартал од 2018 година, сообраќајот на ресурси достигна 11.2 милиони уникатни корисници месечно. Во тоа време, во критичните моменти изгубивме и до 40% од трупците, поради што не можевме брзо да се справиме со инцидентите и потрошивме многу време и труд за нивно решавање. Исто така, често не можевме да ја најдеме причината за проблемот, а тој се повторуваше по некое време. Беше пекол и мораше нешто да се преземе во врска со тоа.

Во тоа време, користевме кластер од 10 јазли на податоци со ElasticSearch верзија 5.5.2 со стандардни поставки за индекси за складирање на дневници. Беше воведен пред повеќе од една година како популарно и достапно решение: тогаш протокот на трупци не беше толку голем, немаше смисла да се дојде до нестандардни конфигурации. 

Обработката на дојдовните дневници беше обезбедена од Logstash на различни порти на пет координатори на ElasticSearch. Еден индекс, без разлика на големината, се состоеше од пет парчиња. Беше организирана часовна и дневна ротација, како резултат на тоа, на секој час во кластерот се појавуваа околу 100 нови парчиња. Иако немаше многу логови, кластерот добро се справи и никој не обрнуваше внимание на неговите поставки. 

Предизвиците на брзиот раст

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

Тоа беше скалирање што нè доведе до точка каде што кластерот стана практично неуправлив. Кога дневниците почнаа да пристигнуваат со брзина од 20 илјади пораки во секунда, честото бескорисно ротирање го зголеми бројот на парчиња на 6 илјади, а имаше повеќе од 600 парчиња по јазол. 

Ова доведе до проблеми со распределбата на RAM меморијата, а кога се сруши јазолот, сите делови почнаа да се движат истовремено, множејќи го сообраќајот и вчитувајќи други јазли, што го оневозможи запишувањето податоци во кластерот. И периодов останавме без трупци. И ако имаше проблем со серверот, во основа изгубивме 1/10 од кластерот. Голем број на мали индекси додадоа сложеност.

Без логови, не ги разбравме причините за инцидентот и можевме порано или подоцна повторно да стапнеме на истото гребло, а во идеологијата на нашиот тим тоа беше неприфатливо, бидејќи сите наши механизми за работа се дизајнирани да го прават токму спротивното - никогаш да не се повторува истите проблеми. За да го направиме ова, ни требаше целосен обем на дневници и нивна испорака речиси во реално време, бидејќи тим од дежурни инженери ги следеа предупредувањата не само од метрика, туку и од дневници. За да се разбере размерот на проблемот, во тоа време вкупниот волумен на трупци беше околу 2 ТБ дневно. 

Поставивме цел целосно да го елиминираме губењето на дневниците и да го намалиме времето на нивно доставување до кластерот 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 / 960 Gb SSD / 32 Gb x 3 x 2 (3 за Hot1 и 3 за Hot2).
• За „топли“ јазли: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

При ова повторување, го преместивме индексот со дневници за пристап на микросервиси, кои зафаќаат ист простор како логовите на nginx од предната линија, во втората група од три „жешки“ јазли. Сега ги складираме податоците на „жешките“ јазли 20 часа, а потоа ги пренесуваме во „топли“ јазли во остатокот од дневниците. 

Го решивме проблемот со исчезнувањето на малите индекси со реконфигурирање на нивната ротација. Сега индексите се ротираат на секои 23 часа во секој случај, дури и ако има малку податоци таму. Ова малку го зголеми бројот на парчиња (имаше околу 800), но од гледна точка на перформансите на кластерот тоа е толерантно. 

Како резултат на тоа, имаше шест „жешки“ и само четири „топли“ јазли во кластерот. Ова предизвикува мало одложување на барањата во долги временски интервали, но зголемувањето на бројот на јазли во иднина ќе го реши овој проблем.

Оваа повторување го реши и проблемот со недостатокот на полуавтоматско скалирање. За да го направите ова, распоредивме инфраструктурен кластер Номад - слично на она што веќе го имаме распоредено во производството. Засега количината на Logstash не се менува автоматски во зависност од оптоварувањето, но ќе дојдеме до ова.

Планови за иднината

Имплементираната конфигурација се скали совршено, и сега складираме 13,3 TB податоци - сите дневници за 4 дена, што е неопходно за итна анализа на предупредувањата. Некои од логовите ги претвораме во метрика, кои ги додаваме во Графит. За да им ја олесниме работата на инженерите, имаме метрика за инфраструктурниот кластер и скрипти за полуавтоматска поправка на вообичаени проблеми. По зголемувањето на бројот на податочни јазли, што е планирано за следната година, ќе преминеме на складирање податоци од 4 на 7 дена. Ова ќе биде доволно за оперативна работа, бидејќи секогаш се трудиме да ги истражиме инцидентите што е можно поскоро, а за долгорочни истраги има телеметриски податоци. 

Во октомври 2019 година, сообраќајот до cian.ru веќе порасна на 15,3 милиони уникатни корисници месечно. Ова стана сериозен тест на архитектонското решение за испорака на трупци. 

Сега се подготвуваме да го ажурираме ElasticSearch на верзијата 7. Сепак, за ова ќе треба да го ажурираме мапирањето на многу индекси во ElasticSearch, бидејќи тие се префрлија од верзијата 5.5 и беа декларирани како застарени во верзијата 6 (тие едноставно не постојат во верзијата 7). Ова значи дека за време на процесот на ажурирање дефинитивно ќе има некаква виша сила, која ќе не остави без логови додека проблемот е решен. Од верзијата 7, најмногу ја очекуваме Kibana со подобрен интерфејс и нови филтри. 

Ја постигнавме нашата главна цел: престанавме да губиме дневници и го намаливме времето на застој на инфраструктурниот кластер од 2-3 несреќи неделно на неколку часа работа за одржување месечно. Целата оваа работа во производството е речиси невидлива. Сепак, сега можеме да утврдиме што точно се случува со нашата услуга, можеме брзо да го направиме тоа во тивок режим и да не се грижиме дека дневниците ќе се изгубат. Генерално, задоволни сме, среќни и се подготвуваме за нови подвизи, за кои ќе зборуваме подоцна.

Извор: www.habr.com