Барлығына сәлем, менің атым Александр, мен CIAN-да инженер болып жұмыс істеймін және жүйелік әкімшілендірумен және инфрақұрылымдық процестерді автоматтандырумен айналысамын. Алдыңғы мақалалардың біріне түсініктемелерде біз күніне 4 ТБ журналды қайдан алатынымызды және олармен не істейтінімізді айтуды сұрады. Иә, бізде көптеген журналдар бар және оларды өңдеу үшін жеке инфрақұрылымдық кластер құрылды, бұл бізге мәселелерді жылдам шешуге мүмкіндік береді. Бұл мақалада мен оны бір жыл ішінде үнемі өсіп келе жатқан деректер ағынымен жұмыс істеу үшін қалай бейімдегеніміз туралы айтатын боламын.
Біз неден бастадық?
Соңғы бірнеше жылда cian.ru-ға жүктеме өте тез өсті, ал 2018 жылдың үшінші тоқсанында ресурс трафигі айына 11.2 миллион бірегей пайдаланушыға жетті. Ол кезде сыни сәттерде бөренелердің 40%-на дейін жоғалттық, сондықтан біз оқыс оқиғаларды тез шеше алмадық және оларды шешуге көп уақыт пен күш жұмсадық. Біз де жиі мәселенің себебін таба алмадық, ол біраз уақыттан кейін қайталанатын. Бұл тозақ болды және бұл туралы бірдеңе істеу керек болды.
Ол кезде журналдарды сақтау үшін стандартты индекс параметрлері бар ElasticSearch 10 нұсқасы бар 5.5.2 деректер түйінінен тұратын кластерді пайдаландық. Ол бір жылдан астам уақыт бұрын танымал және қолжетімді шешім ретінде енгізілді: содан кейін журналдар ағыны соншалықты үлкен емес еді, стандартты емес конфигурацияларды ойлап табудың қажеті жоқ еді.
Кіріс журналдарын өңдеуді Logstash бес ElasticSearch үйлестірушісінің әртүрлі порттарында қамтамасыз етті. Бір көрсеткіш көлеміне қарамастан бес шұңқырдан тұрды. Сағаттық және күнделікті айналым ұйымдастырылды, нәтижесінде кластерде сағат сайын 100-ге жуық жаңа сынықтар пайда болды. Журналдар көп болмаса да, кластер жақсы жұмыс істеді және оның параметрлеріне ешкім назар аудармады.
Жылдам өсудің қиындықтары
Жасалған журналдардың көлемі өте тез өсті, өйткені екі процесс бір-бірімен қабаттасып жатты. Бір жағынан сервисті пайдаланушылар саны өсті. Екінші жағынан, біз C# және Python тіліндегі ескі монолиттерді аралап, микросервис архитектурасына белсенді түрде ауыса бастадық. Монолит бөліктерін ауыстырған бірнеше ондаған жаңа микросервис инфрақұрылымдық кластер үшін айтарлықтай көбірек журналдарды жасады.
Бұл масштабтау бізді кластерді іс жүзінде басқаруға болмайтын деңгейге әкелді. Журналдар секундына 20 мың хабарлама жылдамдығымен келе бастағанда, жиі пайдасыз айналу сынықтар санын 6 мыңға дейін арттырды және бір түйінде 600-ден астам сынықтар болды.
Бұл ЖЖҚ бөлу проблемаларына әкелді және түйін бұзылған кезде барлық сынықтар бір уақытта қозғала бастады, трафикті көбейтіп, басқа түйіндерді жүктейді, бұл кластерге деректерді жазуды дерлік мүмкін болмады. Ал осы кезеңде бөренесіз қалдық. Ал егер серверде ақау болса, біз кластердің 1/10 бөлігін жоғалттық. Кішкентай индекстердің үлкен саны күрделілікті арттырды.
Бөренелерсіз біз оқиғаның себептерін түсінбедік және ерте ме, кеш пе сол тырмаға қайтадан басуға болады, және біздің команданың идеологиясында бұл мүмкін емес еді, өйткені біздің барлық жұмыс тетіктері керісінше жасауға арналған - ешқашан қайталанбаңыз. бірдей проблемалар. Мұны істеу үшін бізге журналдардың толық көлемі және оларды нақты уақыт режимінде жеткізу қажет болды, өйткені кезекші инженерлер тобы ескертулерді тек метрикадан ғана емес, журналдардан да бақылап отырды. Мәселенің ауқымын түсіну үшін сол кезде журналдардың жалпы көлемі күніне шамамен 2 ТБ құрады.
Біз журналдардың жоғалуын толығымен жоюды және форс-мажорлық жағдайлар кезінде оларды ELK кластеріне жеткізу уақытын максимум 15 минутқа дейін қысқартуды мақсат етіп қойдық (кейін біз бұл көрсеткішке ішкі KPI ретінде сүйендік).
Жаңа айналу механизмі және ыстық-жылы түйіндер
Біз кластерді түрлендіруді ElasticSearch нұсқасын 5.5.2-ден 6.4.3-ке дейін жаңарту арқылы бастадық. Тағы да біздің 5-нұсқа кластері өлді, біз оны өшіріп, оны толығымен жаңартуды шештік - әлі де журналдар жоқ. Сондықтан біз бұл ауысуды небәрі бір-екі сағатта жасадық.
Осы кезеңдегі ең ауқымды трансформация Apache Kafka-ны аралық буфер ретінде координаторы бар үш түйінде жүзеге асыру болды. Хабарлама брокері бізді ElasticSearch ақаулары кезінде журналдарды жоғалтудан құтқарды. Сонымен бірге біз кластерге 2 түйін қостық және деректер орталығында әртүрлі сөрелерде орналасқан үш «ыстық» түйіні бар ыстық-жылы архитектураға көштік. Біз оларға журналдарды ешбір жағдайда жоғалтпау керек маска арқылы қайта бағыттадық - nginx, сондай-ақ қолданба қателері журналдары. Қалған түйіндерге шағын журналдар жіберілді - жөндеу, ескерту және т.б., ал 24 сағаттан кейін «ыстық» түйіндерден «маңызды» журналдар тасымалданды.
Шағын индекстер санын көбейтпеу үшін біз уақытты айналдырудан айналдыру механизміне көштік. Форумдарда индекс өлшемі бойынша айналдыру өте сенімсіз екендігі туралы көптеген ақпарат болды, сондықтан біз индекстегі құжаттар саны бойынша айналдыруды пайдалануды шештік. Біз әрбір индексті талдап, ротация жұмыс істейтін құжаттардың санын жазып алдық. Осылайша, біз оңтайлы сынық өлшеміне жеттік - 50 ГБ аспайды.
Кластерді оңтайландыру
Дегенмен, проблемалардан толық арыла қойған жоқпыз. Өкінішке орай, шағын индекстер әлі де пайда болды: олар көрсетілген көлемге жетпеді, айналдырылмады және үш күннен асқан индекстерді жаһандық тазалау арқылы жойылды, өйткені біз айналдыруды күні бойынша алып тастадық. Бұл деректердің жоғалуына әкелді, себебі кластердегі индекс толығымен жоғалып кетті және жоқ индекске жазу әрекеті біз басқару үшін пайдаланған куратор логикасын бұзды. Жазуға арналған бүркеншік ат индекске айналдырылды және ауысу логикасын бұзды, бұл кейбір индекстердің 600 ГБ дейін бақыланбайтын өсуіне әкелді.
Мысалы, айналу конфигурациясы үшін:
с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-compose арқылы іске қосатын докерге орналастырдық, сонымен қатар журнал ағынын жедел бақылау үшін Prometheus-ке метрика жіберетін logstash-exporter-ді орналастырдық. Осылайша, біз өзімізге журналдың әрбір түрін өңдеуге жауапты логсташ даналарының санын оңай өзгерту мүмкіндігін бердік.
Біз кластерді жетілдіріп жатқан кезде, cian.ru трафигі айына 12,8 миллион бірегей пайдаланушыға дейін өсті. Нәтижесінде, біздің трансформацияларымыз өндірістегі өзгерістерден сәл артта қалды және біз «жылы» түйіндердің жүктемені көтере алмайтындығы және бөренелер жеткізілімін баяулататыны анықталды. Біз «ыстық» деректерді сәтсіз алдық, бірақ индекстерді біркелкі тарату үшін қалғанын жеткізуге араласып, қолмен айналдыруға тура келді.
Сонымен қатар, кластердегі логсташ даналарының параметрлерін масштабтау және өзгерту оның жергілікті докер-құрастырушы болғандықтан қиын болды және барлық әрекеттер қолмен орындалды (жаңа ұштарды қосу үшін барлық әрекеттерді қолмен өту қажет болды. серверлер мен docker-compose up -d барлық жерде).
Журналды қайта бөлу
Биылғы жылдың қыркүйек айында біз әлі де монолитті кесіп жатырмыз, кластерге жүктеме артып, журналдар ағыны секундына 30 мың хабарламаға жақындады.
Біз келесі итерацияны аппараттық жаңартудан бастадық. Біз бес үйлестірушіден үшке ауыстық, деректер түйіндерін ауыстырдық және ақша мен сақтау орны бойынша жеңдік. Түйіндер үшін біз екі конфигурацияны қолданамыз:
- «Ыстық» түйіндер үшін: E3-1270 v6 / 960Gb SSD / 32 Гб x 3 x 2 (Hot3 үшін 1 және Hot3 үшін 2).
- «Жылы» түйіндер үшін: E3-1230 v6 / 4Tb SSD / 32 Гб x 4.
Бұл итерацияда біз алдыңғы қатардағы nginx журналдарымен бірдей орынды алатын микросервистердің кіру журналдары бар индексті үш «ыстық» түйіннің екінші тобына ауыстырдық. Енді біз деректерді «ыстық» түйіндерде 20 сағат бойы сақтаймыз, содан кейін оларды журналдардың қалған бөлігіне «жылы» түйіндерге тасымалдаймыз.
Біз олардың айналуын қайта конфигурациялау арқылы шағын индекстердің жойылу мәселесін шештік. Енді индекстер кез келген жағдайда, тіпті аз деректер болса да, әрбір 23 сағат сайын айналдырылады. Бұл сынықтар санын аздап көбейтті (олардың шамамен 800-і болды), бірақ кластерлік өнімділік тұрғысынан бұл төзімді.
Нәтижесінде кластерде алты «ыстық» және тек төрт «жылы» түйін болды. Бұл ұзақ уақыт аралықтарында сұраулардың аздап кешігуін тудырады, бірақ болашақта түйіндер санын көбейту бұл мәселені шешеді.
Бұл итерация жартылай автоматты масштабтаудың жоқтығы мәселесін де шешті. Ол үшін біз Nomad кластерін өндіріске енгізгенге ұқсас инфрақұрылымды орналастырдық. Әзірге Logstash мөлшері жүктемеге байланысты автоматты түрде өзгермейді, бірақ біз бұған келеміз.
Болашақ жоспарлары
Орындалған конфигурация мінсіз масштабталады және қазір біз 13,3 ТБ деректерді сақтаймыз - барлық журналдар 4 күн бойы, бұл ескертулерді төтенше талдау үшін қажет. Біз кейбір журналдарды Графитке қосатын көрсеткіштерге түрлендіреміз. Инженерлердің жұмысын жеңілдету үшін бізде инфрақұрылым кластеріне арналған көрсеткіштер және жалпы ақауларды жартылай автоматты жөндеуге арналған сценарийлер бар. Келесі жылға жоспарланған деректер түйіндерінің санын ұлғайтқаннан кейін біз деректерді сақтауға 4 күннен 7 күнге дейін көшеміз. Бұл жедел жұмыс үшін жеткілікті болады, өйткені біз әрқашан оқиғаларды мүмкіндігінше тезірек тексеруге тырысамыз, ал ұзақ мерзімді зерттеулер үшін телеметриялық деректер бар.
2019 жылдың қазан айында cian.ru сайтындағы трафик айына 15,3 миллион бірегей пайдаланушыға дейін өсті. Бұл бөренелерді жеткізуге арналған архитектуралық шешімнің маңызды сынағы болды.
Қазір біз ElasticSearch-ті 7-нұсқаға жаңартуға дайындалып жатырмыз. Дегенмен, бұл үшін ElasticSearch-тегі көптеген индекстердің салыстыруын жаңартуға тура келеді, өйткені олар 5.5 нұсқасынан көшіп, 6-нұсқада ескірген деп жарияланған (олар жай нұсқада жоқ) 7). Бұл жаңарту процесі кезінде мәселе шешілген кезде бізді журналдарсыз қалдыратын қандай да бір форс-мажорлық жағдайлардың болатынын білдіреді. 7-нұсқадан біз жақсартылған интерфейсі мен жаңа сүзгілері бар Kibana-ны асыға күтеміз.
Біз басты мақсатымызға қол жеткіздік: біз журналдарды жоғалтуды тоқтаттық және инфрақұрылымдық кластердің тоқтау уақытын аптасына 2-3 апаттан айына бірнеше сағаттық жөндеу жұмыстарына дейін қысқарттық. Өндірістегі бұл жұмыстардың барлығы дерлік көрінбейді. Дегенмен, қазір біз қызметімізбен не болып жатқанын нақты анықтай аламыз, біз оны тыныш режимде жылдам жасай аламыз және журналдар жоғалады деп алаңдамаймыз. Жалпы, біз қанағаттандық, қуаныштымыз және жаңа ерліктерге дайындалып жатырмыз, ол туралы кейінірек айтамыз.
Ақпарат көзі: www.habr.com