Joan den astean Ekaterinburgeko DUMP IT konferentziara (https://dump-ekb.ru/) joan nintzen eta Backend eta Devops ataletan eztabaidatu zena esan nahi dizuet, eta eskualdeko IT kongresuek arreta merezi duten ala ez.
Evil Martians-eko Nikolay Sverchkov Serverless-i buruz
Zer zegoen hala ere?
Guztira, jardunaldiak 8 atal izan zituen: Backend, Frontend, Mugikorra, Testing eta QA, Devops, Diseinua, Zientzia eta Kudeaketa.
Areto handienak, bide batez, Zientzian eta Kudeaketan daude)) ~ 350 lagunentzat. Backend eta Frontend ez dira askoz txikiagoak. Devops gela txikiena zen, baina aktiboa.
Devops eta Backend ataletako erreportajeak entzun eta hizlariekin pixka bat hitz egin nuen. Jardunaldian landutako gaiei buruz hitz egin eta atal hauek berrikusi nahiko nituzke.
SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web estudioko Flag, Miro (RealTimeBoard) ordezkariek hitz egin zuten Devops eta Backend ataletan. Gaiak landu zituzten CI/CDa, ilara zerbitzuekin lan egitea, erregistroa; Zerbitzaririk gabeko gaiak eta PostgreSQL-rekin Go-n lan egitea ondo landu ziren.
Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank-en txostenak ere egon ziren, baina ez nuen fisikoki bertaratzeko denborarik izan (erreportajeen bideo-grabaketak eta diapositibak oraindik ez daude eskuragarri, 2 aste barru argitaratuko dituztela agintzen dute. dump-ekb.ru-n).
Devops atala
Harrigarria zen atala areto txikienean egin izana, 50 bat eserleku. Jendea korridoreetan ere zutik zegoen :) Entzutea lortu nuen erreportajeen berri emango dizuet.
Petabyte bat pisatzen duen elastikoa
Vladimir Lilek (SKB-Kontur) Elasticsearch Kontur-en egindako erreportajearekin hasi zen atala. Elastiko nahiko handia eta kargatua dute (~800 TB datu, ~1.3 petabyte erredundantzia kontuan hartuta). Kontur zerbitzu guztietarako Elasticsearch bakarra da, 2 klusterrez osatuta dago (7 eta 9 zerbitzariz), eta hain da garrantzitsua, non Konturrek Elasticsearch ingeniari berezi bat duela (hain zuzen ere, Vladimir bera).
Vladimir-ek Elasticsearch-en onurei eta ekartzen dituen arazoei buruzko gogoetak ere partekatu zituen.
onurak:
- Erregistro guztiak leku bakarrean daude, haietara sarbide erraza
- Erregistroak urtebetez gordetzea eta erraz aztertzea
- Erregistroekin lan egiteko abiadura handia
- Datuen bistaratzea kutxatik kanpo
Arazoak:
- mezu-artekaria ezinbestekoa da (Konturrentzat bere papera Kafkak betetzen du)
- Elasticsearch Curator-ekin lan egiteko ezaugarriak (Aldian behin karga handia sortzen da Curator-en ohiko zereginetatik)
- ez dago baimen txertaturik (diru bereizi, nahiko handirako edo ekoizpenerako prest dauden kode irekiko plugin gisa soilik)
Open Distro-ri buruzko iritzi positiboak baino ez ziren izan Elasticsearch-erako :) Baimenaren arazo bera konpondu da bertan.
Nondik dator petabytea?Beren nodoek 12*8 Tb SATA + 2*2 Tb SSD duten zerbitzariek osatzen dute. Biltegiratze hotza SATA-n, SSD cache berorako soilik (biltegiratze beroa).
7+9 zerbitzari, (7 + 9) * 12 * 8 = 1536 Tb.
Espazioaren zati bat erreserban dago, erredundantziarako jarria, etab.
90 aplikazio ingururen erregistroak Elasticsearch-era bidaltzen dira, Kontur, Elba, etab.
Zerbitzaririk gabeko garapenaren ezaugarriak
Hurrengoa DataArt-eko Ruslan Serkinek Serverless-i buruz egindako txostena da.
Ruslanek Serverless ikuspegiarekin garapena zer den orokorrean eta zer ezaugarri dituen hitz egin zuen.
Zerbitzaririk gabeko garapenaren ikuspegi bat da, non garatzaileek ez dute azpiegitura inola ere ukitzen. Adibidea - AWS Lambda Serverless, Kubeless.io (Kubernetes barruan zerbitzaririk gabea), Google Cloud Functions.
Zerbitzaririk gabeko aplikazio ideal bat zerbitzaririk gabeko hornitzaile bati eskaera bat bidaltzen dion funtzio bat besterik ez da API Gateway berezi baten bidez. Mikrozerbitzu aproposa, AWS Lambdak programazio-lengoaia moderno ugari ere onartzen dituen bitartean. Azpiegitura mantentzeko eta zabaltzeko kostua zero bihurtzen da hodeiko hornitzaileen kasuan, aplikazio txikiei eustea ere oso merkea izango da (AWS Lambda - 0.2 $ / milioi 1 eskaera sinple).
Sistema horren eskalagarritasuna ia ezin hobea da - hodeiko hornitzaileak berak arduratzen du hori, Kubeless automatikoki eskalatzen du Kubernetes kluster barruan.
Desabantailak daude:
- aplikazio handiak garatzea gero eta zailagoa da
- zailtasunak daude profilak egiteko aplikazioekin (erregistroak bakarrik daude eskuragarri, baina ez profilak ohiko zentzuan)
- bertsiorik ez
Egia esateko, Serverless-en berri izan nuen duela urte batzuk, baina urte hauetan guztietan ez nuen argi nola erabili behar bezala. Ruslanen txostenaren ondoren, ulermena agertu zen, eta Backend ataleko Nikolai Sverchkov-en (Martians gaiztoak) txostenaren ondoren, sendotu egin zen. Ez zen alferrik joan hitzaldira :)
CI pobreentzako da, edo merezi al du zure CI idaztea web estudio baterako?
Mikhail Radionov, Ekaterinburgeko Flag web estudioko buruak, norberak idatzitako CI/CDari buruz hitz egin zuen.
Bere estudioa "eskuzko CI/CD"tik (sartu zerbitzarian SSH bidez, egin git pull bat, errepikatu egunean 100 aldiz) Jenkins-era eta auto-idatzitako tresna batera joan da, kodea kontrolatzeko eta Pullkins izeneko bertsioak egiteko aukera ematen duena. .
Zergatik ez zuen Jenkinsek lanik egin? Lehenespenez ez zuen behar adina malgutasun ematen eta pertsonalizatzeko zailaegia zen.
"Flag" Laravel-en garatzen da (PHP esparrua). CI/CD zerbitzari bat garatzerakoan, Mikhailek eta bere lankideek Telescope and Envoy izeneko Laravel-en barneko mekanismoak erabili zituzten. Emaitza PHP-ko zerbitzari bat da (kontuan izan) sarrerako webhook eskaerak prozesatzen dituena, frontend-a eta backend-a eraiki dezakeena, zerbitzari desberdinetara zabaldu eta Slack-i jakinarazi.
Ondoren, inplementazio urdina/berdea egin ahal izateko eta ezarpen uniformeak izateko dev-stage-prod inguruneetan, Docker-era aldatu ziren. Abantailek bere horretan jarraitzen zuten, ingurunea homogeneizatzeko eta doikuntzarik gabeko hedapen aukerak gehitu ziren eta Docker-ek behar bezala lan egiten ikasteko beharra gehitu zen.
Nola murriztu genuen zerbitzariaren kaleratzeen itzulera kopurua %99an
Devops ataleko azken txostena Viktor Eremchenkorena izan zen, Miro.com-eko devops ingeniari nagusia (lehen RealTimeBoard zena).
RealTimeBoard, Miro taldearen produktu enblematikoena, Java aplikazio monolitiko batean oinarritzen da. Biltzea, probatzea eta inplementatzea geldialdirik gabe lan zaila da. Kasu honetan, garrantzitsua da kodearen bertsio hori zabaltzea, atzera egin behar ez dadin (monolito astuna da).
Hori egiteko aukera ematen duen sistema eraikitzeko bidean, Mirok arkitektura, erabilitako tresnak (Atlassian Bamboo, Ansible...) eta taldeen egitura lantzea barne hartzen zituen bidetik (orain daukate). Devops talde dedikatu bat + profil ezberdinetako garatzaileen Scrum talde ezberdin asko).
Bidea zaila eta arantzatsua izan zen, eta hor amaitu ez zen pilatutako mina eta baikortasuna partekatu zuen Victorrek.
Galderak egiteagatik liburu bat irabazi zuen
Backend atala
2 txostenetara joatea lortu nuen: Nikolay Sverchkov-ena (Martians gaiztoak), Serverless-i buruzkoa ere, eta Grigory Koshelev-ena (Kontur konpainia) telemetriari buruzkoa.
Zerbitzaririk gabeko hilkor soilentzat
Ruslan Sirkinek Serverless zer den hitz egiten bazuen, Nikolayk aplikazio sinpleak erakutsi zituen Serverless erabiliz, eta AWS Lambda-n aplikazioen kostuan eta abiaduran eragina duten xehetasunei buruz hitz egin zuen.
Xehetasun interesgarri bat: ordaindutako gutxieneko elementua 128 Mb-ko memoria eta 100 ms-ko CPUa da, 0,000000208 $ balio du. Gainera, hilero halako milioi bat eskaera doan dira.
Nikolairen funtzio batzuek 100 ms-ko muga gainditzen zuten sarri (aplikazio nagusia Ruby-n idatzita zegoen), beraz, Go-n berridazteak aurrezpen bikaina izan zuen.
Vostok Hercules - egin telemetria berriro bikaina!
Grigory Kosheleven (Kontur konpainia) Backend ataleko azken txostena telemetriari buruz. Telemetria erregistroak, metrikak, aplikazioen arrastoak esan nahi du.
Horretarako, Contour-ek Github-en argitaratutako norberak idatzitako tresnak erabiltzen ditu. Txosteneko tresna - Hercules, , telemetria datuak emateko erabiltzen da.
Vladimir Lilak Devops atalean egindako txostenak Elasticsearch-en erregistroak gordetzea eta prozesatzea eztabaidatu zuen, baina oraindik milaka gailu eta aplikaziotako erregistroak entregatzeko zeregina dago, eta Vostok Hercules bezalako tresnek konpontzen dituzte.
Zirkuitua askorentzat ezaguna den bidea jarraitu zuen: RabbitMQ-tik Apache Kafkaraino, baina dena ez da hain erraza)) Zookeeper, Cassandra eta Graphite gehitu behar izan zituzten zirkuituan. Ez dut txosten honetako informazioa guztiz zabalduko (ez nire profila), interesa baduzu, hitzaldiaren webgunean diapositibak eta bideoak itxaron ditzakezu.
Nola alderatzen da beste kongresuekin?
Ezin dut alderatu Mosku eta San Petersburgoko kongresuekin, Uraletako beste ekitaldiekin eta Samarako 404festekin alderatu dezaket.
DAMP 8 ataletan egiten da, hau Ural kongresuetarako errekorra da. Zientzia eta Kudeaketa atal oso handiak, hori ere ezohikoa da. Ekaterinburgeko audientzia nahiko egituratuta dago - hiriak Yandex, Kontur, Tinkoff-en garapen sail handiak ditu eta horrek bere arrastoa uzten du txostenetan.
Beste puntu interesgarri bat da enpresa askok 3-4 hizlari dituztela aldi berean hitzaldian (Kontur, Evil Martians, Tinkoff-en kasua izan zen). Horietako asko babesleak ziren, baina erreportajeak besteen nahiko parekoak dira, hauek ez dira publizitate txostenak.
Joan ala ez joan? Uraletan edo inguruan bizi bazara, aukera duzu eta gaiak interesatzen bazaizkizu –bai, noski–. Bidaia luze batean pentsatzen ari bazara, aurreko urteetako erreportajeen eta bideo erreportajeen gaiak aztertuko nituzke eta erabaki bat hartu zuen.
Eskualdeetako kongresuen beste abantaila bat, oro har, txostenen ondoren hizlariarekin komunikatzea erraza da; besterik gabe, eskatzaile gutxiago daude komunikazio hori egiteko.
Eskerrik asko Dump eta Ekaterinburg-i! )
Iturria: www.habr.com