Pasintsemajne mi iris al la DUMP IT-konferenco (https://dump-ekb.ru/) en Jekaterinburg kaj mi volas diri al vi, kio estis diskutita en la sekcioj Backend kaj Devops, kaj ĉu regionaj IT-konferencoj valoras atenton.
Nikolay Sverchkov de Malicaj Marsanoj pri Serverless
Kio estis tie ĉiuokaze?
Entute, la konferenco havis 8 sekciojn: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
La plej grandaj salonoj, cetere, estas ĉe Scienco kaj Administrado)) Por ~350 homoj ĉiu. Backend kaj Frontend ne estas multe pli malgrandaj. La ĉambro Devops estis la plej malgranda, sed aktiva.
Mi aŭskultis la raportojn en la sekcioj Devops kaj Backend kaj parolis iomete kun la parolantoj. Mi ŝatus paroli pri la temoj pritraktitaj kaj revizii ĉi tiujn sekciojn ĉe la konferenco.
Reprezentantoj de SKB-Kontur, DataArt, Evil Martians, Jekaterinburg retstudio Flag, Miro (RealTimeBoard) parolis en la Devops kaj Backend sekcioj. Temoj kovritaj CI/KD, laborado kun atendovicservoj, protokolado; Senservilaj temoj kaj laborado kun PostgreSQL en Go estis bone kovritaj.
Estis ankaŭ raportoj de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, sed mi ne havis tempon por fizike ĉeesti ilin (videoregistraĵoj kaj lumbildoj de la raportoj ankoraŭ ne haveblas, ili promesas afiŝi ilin ene de 2 semajnoj. sur dump-ekb.ru).
Devops-sekcio
Kio estis surpriza estis ke la sekcio estis okazigita en la plej malgranda salono, proksimume 50 sidlokoj. Homoj eĉ staris en la koridoroj :) Mi rakontos al vi pri la raportoj, kiujn mi sukcesis aŭskulti.
Elasto pezanta petabajton
La sekcio komenciĝis per raporto de Vladimir Lil (SKB-Kontur) pri Elasticsearch en Kontur. Ili havas sufiĉe grandan kaj ŝarĝitan elaston (~800 TB da datumoj, ~1.3 petabajtoj konsiderante redundon). Elasticsearch por ĉiuj Kontur-servoj estas unuopa, konsistas el 2 aretoj (el 7 kaj 9 serviloj), kaj estas tiel grava ke Kontur havas specialan Elasticsearch-inĝenieron (fakte, Vladimiro mem).
Vladimir ankaŭ dividis siajn pensojn pri la avantaĝoj de Elasticsearch kaj la problemoj kiujn ĝi alportas.
Profito:
- Ĉiuj ŝtipoj estas en unu loko, facila aliro al ili
- Stokante ŝtipojn dum jaro kaj facile analizante ilin
- Alta rapido labori kun ŝtipoj
- Malvarmeta datuma bildigo el la skatolo
Problemoj:
- mesaĝperanto estas nepra (por Kontur ĝia rolo estas ludata de Kafka)
- funkcioj de laborado kun Elasticsearch Curator (periode kreita alta ŝarĝo de regulaj taskoj en Curator)
- neniu enkonstruita rajtigo (nur por aparta, sufiĉe granda mono, aŭ kiel malfermfontaj aldonaĵoj de diversaj gradoj de preteco por produktado)
Estis nur pozitivaj recenzoj pri Open Distro por Elasticsearch :) La sama afero de rajtigo estis solvita tie.
De kie venas la petabajto?Iliaj nodoj konsistas el serviloj kun 12*8 Tb SATA + 2*2 Tb SSD. Malvarma konservado sur SATA, SSD nur por varma kaŝmemoro (varma stokado).
7+9 serviloj, (7 + 9) * 12 * 8 = 1536 Tb.
Parto de la spaco estas en rezervo, rezervita por redundo, ktp.
Registroj de ĉirkaŭ 90 aplikaĵoj estas senditaj al Elasticsearch, inkluzive de ĉiuj raportservoj de Kontur, Elba, ktp.
Trajtoj de evoluo sur Serverless
Poste estas raporto de Ruslan Serkin de DataArt pri Serverless.
Ruslan parolis pri kio ĝenerale estas evoluo kun la Serverless-aliro, kaj kiaj estas ĝiaj trajtoj.
Senservilo estas aliro al evoluo en kiu programistoj neniel tuŝas la infrastrukturon. Ekzemplo - AWS Lambda Serverless, Kubeless.io (Senservilo ene de Kubernetes), Google Cloud Functions.
Ideala Senservila aplikaĵo estas simple funkcio, kiu sendas peton al Senservila provizanto per speciala API-Enirejo. Ideala mikroservo, dum AWS Lambda ankaŭ subtenas grandan nombron da modernaj programlingvoj. La kosto de bontenado kaj deplojado de infrastrukturo fariĝas nulo en la kazo de nubaj provizantoj, subteni malgrandajn aplikojn ankaŭ estos tre malmultekosta (AWS Lambda - $ 0.2 / 1 miliono da simplaj petoj).
La skalebleco de tia sistemo estas preskaŭ ideala - la nuba provizanto prizorgas tion mem, Kubeless skalas aŭtomate ene de la Kubernetes-areo.
Estas malavantaĝoj:
- disvolvi grandajn aplikojn fariĝas pli malfacila
- estas malfacileco kun profilado de aplikaĵoj (nur protokoloj disponeblas al vi, sed ne profilado en la kutima signifo)
- neniu versio
Verdire, mi aŭdis pri Serverless antaŭ kelkaj jaroj, sed dum ĉiuj ĉi jaroj ne estis klare al mi kiel ĝuste uzi ĝin. Post la raporto de Ruslan aperis kompreno, kaj post la raporto de Nikolao Sverchkov (Malbonaj Marsanoj) el la sekcio Backend, ĝi firmiĝis. Ne vane mi iris al la konferenco :)
CI estas por malriĉuloj, aŭ ĉu indas verki vian propran CI por retstudio?
Miĥail Radionov, estro de la retejo-studio Flag el Jekaterinburg, parolis pri memskribita CI/KD.
Lia studio iris de "manlibro CI/KD" (ensalutu en la servilon per SSH, faru git-tiron, ripetu 100 fojojn tage) al Jenkins kaj al memskribita ilo, kiu ebligas al vi monitori kodon kaj plenumi eldonojn nomitajn Pullkins. .
Kial Jenkins ne funkciis? Ĝi ne disponigis sufiĉe da fleksebleco defaŭlte kaj estis tro malfacile agordi.
"Flago" evoluas en Laravel (PHP-kadro). Dum evoluigado de CI/CD-servilo, Mikhail kaj liaj kolegoj uzis la enkonstruitajn mekanismojn de Laravel nomitajn Teleskopo kaj Sendito. La rezulto estas servilo en PHP (bonvolu noti), kiu prilaboras alvenantajn rethook-petojn, povas konstrui la fasadon kaj backend, disfaldi al malsamaj serviloj kaj raporti al Slack.
Tiam, por povi plenumi bluan/verdan deplojon kaj havi unuformajn agordojn en dev-stage-prod-medioj, ili ŝanĝis al Docker. La avantaĝoj restis la samaj, la eblecoj homogenigi la medion kaj senjuntan deplojon estis aldonitaj, kaj la bezono lerni Docker por labori kun ĝi ĝuste estis aldonita.
Kiel ni reduktis la nombron da servilaj liberigoj je 99%
La lasta raporto en la sekcio Devops estis de Viktor Eremchenko, Ĉefa devops-inĝeniero ĉe Miro.com (antaŭe RealTimeBoard).
RealTimeBoard, la frontmontra produkto de la teamo Miro, estas bazita sur monolita Java-aplikaĵo. Kolekti, provi kaj deploji ĝin sen malfunkcio estas malfacila tasko. En ĉi tiu kazo, gravas disfaldi tian version de la kodo, por ke ĝi ne devas esti renversita (ĝi estas peza monolito).
Survoje al konstruado de sistemo, kiu permesas vin fari tion, Miro iris tra vojo, kiu inkluzivis labori pri la arkitekturo, la iloj uzataj (Atlassian Bambuo, Ansible, ktp), kaj labori pri la strukturo de la teamoj (ili nun havas dediĉita Devops-teamo + multaj apartaj Scrum-teamoj de programistoj de malsamaj profiloj).
La vojo montriĝis malfacila kaj dorna, kaj Victor dividis la amasigitan doloron kaj optimismon, kiuj ne finiĝis tie.
Gajnis libron pro demandoj
Backend sekcio
Mi sukcesis ĉeesti 2 raportojn - de Nikolaj Sverĉkov (Malbonaj Marsanoj), ankaŭ pri Serverless, kaj de Grigorij Koŝelev (firmao Kontur) pri telemetrio.
Senservilo por nuraj mortontoj
Se Ruslan Sirkin parolis pri tio, kio estas Serverless, Nikolay montris simplajn aplikojn uzante Serverless, kaj parolis pri la detaloj, kiuj influas la koston kaj rapidecon de aplikoj en AWS Lambda.
Interesa detalo: la minimuma pagita elemento estas 128 Mb da memoro kaj 100 ms CPU, ĝi kostas $0,000000208. Krome, 1 miliono da tiaj petoj monate estas senpagaj.
Kelkaj el la funkcioj de Nikolao ofte superis la limon de 100 ms (la ĉefa aplikaĵo estis skribita en Ruby), do reverki ilin en Go disponigis bonegajn ŝparaĵojn.
Vostok Hercules — faru telemetrion bonega denove!
La lasta raporto de la sekcio Backend de Grigory Koshelev (firmao Kontur) pri telemetrio. Telemetrio signifas protokolojn, metrikojn, aplikajn spurojn.
Por ĉi tiu celo, Contour uzas memskribitajn ilojn afiŝitajn sur Github. Ilo el la raporto - Heraklo, , estas uzata por liveri telemetriajn datumojn.
La raporto de Vladimir Lila en la sekcio Devops diskutis pri stokado kaj prilaborado de protokoloj en Elasticsearch, sed ankoraŭ restas la tasko liveri protokolojn de multaj miloj da aparatoj kaj aplikoj, kaj iloj kiel Vostok Hercules solvas ilin.
La cirkvito sekvis vojon konatan de multaj - de RabbitMQ ĝis Apache Kafka, sed ne ĉio estas tiel simpla)) Ili devis aldoni Zookeeper, Cassandra kaj Graphite al la cirkvito. Mi ne plene malkaŝos la informojn pri ĉi tiu raporto (ne mia profilo), se vi interesiĝas, vi povas atendi la lumbildojn kaj filmetojn en la retejo de la konferenco.
Kiel ĝi komparas kun aliaj konferencoj?
Mi ne povas kompari ĝin kun konferencoj en Moskvo kaj Sankt-Peterburgo, mi povas kompari ĝin kun aliaj aranĝoj en Uralo kaj kun 404fest en Samara.
DAMP estas tenita en 8 sekcioj, ĉi tio estas rekordo por Ural-konferencoj. Tre grandaj sekcioj pri Scienco kaj Administrado, tio ankaŭ estas nekutima. La publiko en Jekaterinburg estas sufiĉe strukturita - la urbo havas grandajn disvolvajn fakojn por Yandex, Kontur, Tinkoff, kaj ĉi tio lasas sian markon en la raportoj.
Alia interesa punkto estas, ke multaj kompanioj havas samtempe 3-4 parolantojn ĉe la konferenco (tiel estis la kazo de Kontur, Evil Martians, Tinkoff). Multaj el ili estis sponsoroj, sed la raportoj estas sufiĉe egalaj kun aliaj, ĉi tiuj ne estas reklamaj raportoj.
Iri aŭ ne iri? Se vi loĝas en Uralo aŭ proksime, vi havas la ŝancon kaj interesiĝas pri la temoj - jes, kompreneble. Se vi pensas pri longa vojaĝo, mi rigardus la temojn de raportoj kaj videoraportoj de antaŭaj jaroj kaj faris decidon.
Alia avantaĝo de konferencoj en la regionoj, kutime, estas, ke estas facile komuniki kun la preleganto post la raportoj; simple estas malpli da kandidatoj por tia komunikado.
Dankon al Dump kaj Jekaterinburg! )
fonto: www.habr.com