Kumusta sa tanan, ang akong ngalan mao si Alexander, nagtrabaho ko sa CIAN isip usa ka inhenyero ug nalambigit sa pagdumala sa sistema ug automation sa mga proseso sa imprastraktura. Sa mga komento sa usa sa miaging mga artikulo, gihangyo kami nga isulti kung diin kami makakuha 4 TB nga mga troso matag adlaw ug kung unsa ang among gibuhat niini. Oo, kami adunay daghang mga troso, ug usa ka bulag nga cluster sa imprastraktura ang gihimo aron maproseso kini, nga nagtugot kanamo nga dali nga masulbad ang mga problema. Niining artikuloha akong hisgutan kung giunsa namo kini gipahiangay sa dagan sa usa ka tuig aron magtrabaho uban ang kanunay nga nagtubo nga dagan sa datos.
Asa ta nagsugod?
Sa milabay nga pipila ka tuig, ang load sa cian.ru paspas nga mitubo, ug sa ikatulo nga kwarter sa 2018, ang trapiko sa kapanguhaan miabot sa 11.2 milyon nga talagsaon nga mga tiggamit matag bulan. Nianang panahona, sa mga kritikal nga mga gutlo nawad-an kami hangtod sa 40% sa mga troso, mao nga dili kami dali nga makasagubang sa mga insidente ug migahin og daghang oras ug paningkamot sa pagsulbad niini. Kanunay usab namo nga dili makit-an ang hinungdan sa problema, ug kini mobalik paglabay sa pipila ka panahon. Kini mao ang impyerno ug adunay kinahanglan nga buhaton mahitungod niini.
Nianang panahona, migamit kami og cluster sa 10 ka data nodes nga adunay ElasticSearch nga bersyon 5.5.2 nga adunay standard nga mga setting sa index aron sa pagtipig sa mga troso. Gipaila kini labaw pa sa usa ka tuig ang milabay isip usa ka popular ug barato nga solusyon: unya ang dagan sa mga troso dili kaayo dako, walay punto sa pag-abut sa dili standard nga mga pag-configure.
Ang pagproseso sa mga umaabot nga mga troso gihatag sa Logstash sa lainlaing mga pantalan sa lima ka mga coordinator sa ElasticSearch. Ang usa ka indeks, bisan unsa pa ang gidak-on, naglangkob sa lima ka shards. Usa ka oras-oras ug adlaw-adlaw nga rotation ang giorganisar, isip resulta, mga 100 ka bag-ong shards ang nagpakita sa cluster kada oras. Samtang wala kaayoy daghang mga troso, ang cluster nakasagubang og maayo ug walay usa nga nagtagad sa mga setting niini.
Ang mga hagit sa paspas nga pagtubo
Ang gidaghanon sa namugna nga mga troso dali kaayong mitubo, tungod kay ang duha ka proseso nagsapaw sa usag usa. Sa usa ka bahin, ang gidaghanon sa mga tiggamit sa serbisyo mitubo. Sa laing bahin, nagsugod kami sa aktibong pagbalhin sa usa ka microservice nga arkitektura, nga giputol ang among mga daan nga monolith sa C # ug Python. Daghang dosena nga mga bag-ong microservice nga nag-ilis sa mga bahin sa monolith nakamugna og daghang mga troso alang sa cluster sa imprastraktura.
Ang pag-scale nga nagdala kanamo sa punto diin ang cluster nahimong halos dili madumala. Sa diha nga ang mga troso nagsugod sa pag-abot sa gikusgon nga 20 ka libo nga mga mensahe kada segundo, ang kanunay nga walay pulos nga pagtuyok nagdugang sa gidaghanon sa mga shards ngadto sa 6 ka libo, ug adunay labaw pa sa 600 ka mga shards matag node.
Kini misangpot sa mga problema sa alokasyon sa RAM, ug sa diha nga ang usa ka node nahagsa, ang tanan nga mga shards nagsugod sa paglihok nga dungan, pagpadaghan sa trapiko ug pag-load sa ubang mga node, nga naghimo niini nga hapit imposible nga isulat ang datos sa cluster. Ug niining panahona kami gibiyaan nga walay mga troso. Ug kung adunay problema sa server, kasagaran nawala ang 1/10 sa cluster. Ang usa ka dako nga gidaghanon sa gagmay nga mga indeks nagdugang pagkakomplikado.
Kung wala ang mga troso, wala kami makasabut sa mga hinungdan sa insidente ug mahimoβg sa madugay o madali makatunob sa parehas nga rake pag-usab, ug sa ideolohiya sa among team dili kini madawat, tungod kay ang tanan namon nga mga mekanismo sa pagtrabaho gilaraw nga buhaton ang kaatbang - dili na masubli. parehas nga mga problema. Aron mahimo kini, kinahanglan namon ang tibuuk nga gidaghanon sa mga troso ug ang ilang paghatud hapit sa tinuud nga oras, tungod kay ang usa ka grupo sa mga on-duty nga mga inhenyero nagmonitor sa mga alerto dili lamang gikan sa mga sukatan, apan gikan usab sa mga troso. Aron masabtan ang sukod sa problema, niadtong panahona ang kinatibuk-ang gidaghanon sa mga troso maoy mga 2 TB kada adlaw.
Naghimo kami usa ka katuyoan nga hingpit nga mapapas ang pagkawala sa mga troso ug makunhuran ang oras sa ilang paghatud sa cluster sa ELK hangtod sa labing taas nga 15 minuto sa panahon sa force majeure (sa ulahi kami nagsalig niini nga numero ingon usa ka internal nga KPI).
Bag-ong mekanismo sa rotation ug init-init nga mga node
Among gisugdan ang cluster conversion pinaagi sa pag-update sa ElasticSearch nga bersyon gikan sa 5.5.2 ngadto sa 6.4.3. Sa makausa pa ang among bersyon 5 nga cluster namatay, ug kami nakahukom nga i-off kini ug hingpit nga i-update kini - wala pa'y mga troso. Busa gihimo namo kini nga transisyon sulod lang sa pipila ka oras.
Ang labing dako nga pagbag-o sa kini nga yugto mao ang pagpatuman sa Apache Kafka sa tulo ka mga node nga adunay usa ka coordinator ingon usa ka intermediate buffer. Ang mensahe broker nagluwas kanamo gikan sa pagkawala sa mga troso sa panahon sa mga problema sa ElasticSearch. Sa parehas nga oras, gidugang namon ang 2 nga mga node sa cluster ug gibalhin sa usa ka mainit-init nga arkitektura nga adunay tulo nga "init" nga mga node nga nahimutang sa lainlaing mga rack sa data center. Gi-redirect namo ang mga troso ngadto kanila gamit ang maskara nga dili angayng mawala sa bisan unsang mga kahimtang - nginx, ingon man mga log sa error sa aplikasyon. Ang mga menor de edad nga mga log gipadala sa nahabilin nga mga node - debug, pasidaan, ug uban pa, ug pagkahuman sa 24 ka oras, ang "importante" nga mga log gikan sa "mainit" nga mga node gibalhin.
Aron dili madugangan ang gidaghanon sa gagmay nga mga indeks, mibalhin kami gikan sa rotation sa oras ngadto sa mekanismo sa rollover. Adunay daghang impormasyon sa mga forum nga ang rotation sa index size dili kaayo kasaligan, mao nga nakahukom kami nga gamiton ang rotation sa gidaghanon sa mga dokumento sa index. Among gi-analisa ang matag indeks ug girekord ang gidaghanon sa mga dokumento nga human niana ang rotation kinahanglang molihok. Sa ingon, nakab-ot namon ang kamalaumon nga gidak-on sa shard - dili molapas sa 50 GB.
Pag-optimize sa cluster
Bisan pa, wala pa naton hingpit nga nawala ang mga problema. Ikasubo, ang gagmay nga mga indeks nagpakita gihapon: wala sila makaabot sa gitakda nga gidaghanon, wala gipatuyok, ug gipapas sa tibuok kalibutan nga paglimpyo sa mga indeks nga mas tigulang kay sa tulo ka adlaw, tungod kay gitangtang namo ang rotation sa petsa. Misangpot kini sa pagkawala sa datos tungod sa kamatuoran nga ang index gikan sa cluster nawala sa hingpit, ug ang pagsulay sa pagsulat sa usa ka wala'y index nga nagbungkag sa lohika sa curator nga among gigamit alang sa pagdumala. Ang mga alyas alang sa pagsulat nahimo nga indeks ug gibuak ang rollover logic, hinungdan sa dili makontrol nga pagtubo sa pipila nga mga indeks hangtod sa 600 GB.
Pananglitan, alang sa rotation config:
Ρ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
Kung walay alyas nga rollover, usa ka sayup ang nahitabo:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Gibiyaan namon ang solusyon sa kini nga problema alang sa sunod nga pag-uli ug gikuha ang lain nga isyu: gibalhin namon ang pull logic sa Logstash, nga nagproseso sa umaabot nga mga troso (pagtangtang sa wala kinahanglana nga kasayuran ug pagpauswag). Gibutang namo kini sa docker, nga among gilusad pinaagi sa docker-compose, ug gibutang usab namo ang logstash-exporter didto, nga nagpadala sa metrics ngadto sa Prometheus alang sa operational monitoring sa log stream. Niining paagiha gihatagan namo ang among kaugalingon og higayon sa hapsay nga pagbag-o sa gidaghanon sa mga instance sa logstash nga responsable sa pagproseso sa matag matang sa log.
Samtang gipauswag namo ang cluster, ang trapiko sa cian.ru misaka ngadto sa 12,8 ka milyon nga talagsaon nga tiggamit matag bulan. Ingon usa ka sangputanan, nahimo nga ang among mga pagbag-o usa ka gamay sa luyo sa mga pagbag-o sa produksiyon, ug nag-atubang kami sa kamatuoran nga ang "mainit" nga mga node dili makasagubang sa pagkarga ug gipahinay ang tibuuk nga paghatud sa mga troso. Nakadawat kami og "init" nga datos nga walay mga kapakyasan, apan kinahanglan kaming mangilabot sa paghatud sa uban ug maghimo usa ka manual rollover aron parehas nga maapod-apod ang mga indeks.
Sa parehas nga oras, ang pag-scale ug pagbag-o sa mga setting sa mga kaso sa logstash sa cluster komplikado sa kamatuoran nga kini usa ka lokal nga docker-compose, ug ang tanan nga mga aksyon gihimo nga mano-mano (aron makadugang bag-ong mga tumoy, kinahanglan nga mano-mano nga moagi sa tanan. ang mga server ug docker-compose up -d bisan asa).
Pag-apod-apod sa log
Niadtong Septembre ning tuiga, giputol pa namo ang monolith, nagkadaghan ang load sa cluster, ug ang dagan sa mga troso nagkaduol sa 30 ka libo nga mga mensahe kada segundo.
Gisugdan namon ang sunod nga pag-uli sa usa ka pag-update sa hardware. Nagbalhin kami gikan sa lima ka mga coordinator ngadto sa tulo, gipulihan ang mga node sa datos ug nakadaog sa mga termino sa salapi ug espasyo sa pagtipig. Alang sa mga node gigamit namon ang duha nga mga pag-configure:
- Alang sa "init" nga mga node: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 alang sa Hot1 ug 3 alang sa Hot2).
- Para sa "mainit" nga mga node: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Sa kini nga pag-uli, gibalhin namon ang indeks nga adunay mga log sa pag-access sa mga microservice, nga adunay parehas nga wanang sa mga front-line nginx log, sa ikaduhang grupo sa tulo nga "init" nga mga node. Gitipigan namo karon ang mga datos sa "init" nga mga node sulod sa 20 ka oras, ug dayon ibalhin kini ngadto sa "mainit" nga mga node ngadto sa ubang mga troso.
Nasulbad namo ang problema sa gagmay nga mga index nga nawala pinaagi sa pag-reconfigure sa ilang rotation. Karon ang mga indeks gituyok matag 23 ka oras sa bisan unsang kaso, bisan kung adunay gamay nga datos didto. Kini gamay nga nagdugang sa gidaghanon sa mga shards (adunay mga 800 niini), apan gikan sa punto sa panglantaw sa cluster performance kini maagwanta.
Ingon nga resulta, adunay unom ka "init" ug upat lamang ka "mainit" nga mga buko sa cluster. Kini hinungdan sa usa ka gamay nga paglangan sa mga hangyo sa taas nga mga agwat sa panahon, apan ang pagdugang sa gidaghanon sa mga node sa umaabot makasulbad niini nga problema.
Giayo usab sa kini nga pag-uli ang problema sa kakulang sa semi-awtomatikong pag-scale. Aron mahimo kini, nag-deploy kami usa ka cluster sa imprastraktura nga Nomad - parehas sa na-deploy na namon sa produksiyon. Sa pagkakaron, ang kantidad sa Logstash dili awtomatikong mausab depende sa load, apan kita moabut niini.
Mga plano alang sa umaabot
Ang gipatuman nga mga timbangan sa pag-configure hingpit, ug karon nagtipig kami og 13,3 TB nga datos - tanan nga mga troso sulod sa 4 ka adlaw, nga gikinahanglan alang sa emerhensya nga pagtuki sa mga alerto. Among gi-convert ang pipila sa mga log ngadto sa metrics, nga among idugang sa Graphite. Aron mapasayon ββang trabaho sa mga inhenyero, aduna kami mga sukdanan para sa cluster sa imprastraktura ug mga script para sa semi-awtomatikong pag-ayo sa kasagarang mga problema. Human sa pagdugang sa gidaghanon sa mga data node, nga giplano alang sa sunod nga tuig, kita mobalhin ngadto sa data storage gikan sa 4 ngadto sa 7 ka adlaw. Igo na kini alang sa operasyon nga trabaho, tungod kay kanunay namon nga gisulayan ang pag-imbestiga sa mga insidente sa labing dali nga panahon, ug alang sa dugay nga mga imbestigasyon adunay datos sa telemetry.
Niadtong Oktubre 2019, ang trapiko sa cian.ru mitubo na ngadto sa 15,3 ka milyon nga talagsaon nga tiggamit matag bulan. Nahimo kini nga seryoso nga pagsulay sa solusyon sa arkitektura alang sa paghatud sa mga troso.
Karon nangandam kami sa pag-update sa ElasticSearch ngadto sa bersyon 7. Apan, tungod niini kinahanglan namong i-update ang pagmapa sa daghang mga index sa ElasticSearch, tungod kay mibalhin sila gikan sa bersyon 5.5 ug gideklarar nga wala na magamit sa bersyon 6 (kini wala na sa bersyon. 7). Kini nagpasabot nga sa panahon sa proseso sa pag-update adunay siguradong usa ka matang sa force majeure, nga magbilin kanato nga walay mga troso samtang ang isyu masulbad. Sa bersyon 7, gipaabut namon ang Kibana nga adunay gipaayo nga interface ug bag-ong mga pagsala.
Nakab-ot namo ang among nag-unang tumong: mihunong kami sa pagkawala sa mga troso ug gipakubsan ang downtime sa cluster sa imprastraktura gikan sa 2-3 nga pag-crash kada semana ngadto sa duha ka oras nga maintenance work kada bulan. Ang tanan nga kini nga trabaho sa produksiyon halos dili makita. Bisan pa, karon mahibal-an namon kung unsa gyud ang nahitabo sa among serbisyo, mahimo namon kini dayon sa usa ka hilum nga mode ug dili mabalaka nga mawala ang mga troso. Sa kinatibuk-an, kami natagbaw, malipayon ug nangandam alang sa bag-ong mga pagpahimulos, nga atong hisgutan sa ulahi.
Source: www.habr.com