A settimana passata aghju andatu à a cunferenza di DUMP IT (https://dump-ekb.ru/) in Ekaterinburg è vogliu dì ciò chì hè statu discutitu in e sezioni Backend è Devops, è se e cunferenze IT regiunale valenu l'attenzione.
Nikolay Sverchkov da Evil Martians about Serverless
Chì ci era in ogni modu ?
In totale, a cunferenza avia 8 sezioni: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
I più grandi saloni, per via, sò in Science and Management)) Per ~ 350 persone ognunu. Backend è Frontend ùn sò micca assai più chjuchi. A sala Devops era a più chjuca, ma attiva.
Aghju intesu i rapporti in e sezioni Devops è Backend è hà parlatu un pocu cù i parlanti. Vogliu parlà di i temi trattati è rivede queste sezioni in a cunferenza.
I rapprisentanti di SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) parlavanu in e sezioni Devops è Backend. I temi coperti CI / CD, travagliendu cù servizii di fila, logu; I temi senza server è u travagliu cù PostgreSQL in Go sò stati ben coperti.
Ci era ancu rapporti di Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ma ùn aghju micca avutu u tempu di assistisce fisicamente à elli (registrazioni video è diapositive di i rapporti ùn sò ancu dispunibili, prumettenu di pubblicà in 2 settimane. nantu à dump-ekb.ru).
Sezione Devops
Ciò chì era surprisante hè chì a sezione hè stata in a sala più chjuca, circa 50 posti. A ghjente stava ancu in i corridoi :) Vi cuntaraghju di i rapporti chì aghju sappiutu à sente.
Elasticu chì pesa un petabyte
A rùbbrica cuminciò cù un rapportu di Vladimir Lil (SKB-Kontur) nantu à Elasticsearch in Kontur. Hanu un Elastic abbastanza grande è carricu (~ 800 TB di dati, ~ 1.3 petabytes tenendu in contu a redundanza). Elasticsearch per tutti i servizii di Kontur hè unicu, custituitu da 2 clusters (di 7 è 9 servitori), è hè cusì impurtante chì Kontur hà un ingegnere speciale Elasticsearch (in fattu, Vladimir stessu).
Vladimir hà ancu sparte i so pinsamenti nantu à i benefici di Elasticsearch è i prublemi chì porta.
Beneficiu:
- Tutti i logs sò in un locu, accessu faciule à elli
- Immagazzinate logs per un annu è analizà facilmente
- Alta velocità di travaglià cù logs
- Visualizazione di dati cool fora di a scatula
Prublemi:
- u broker di messagi hè un must have (per Kontur u so rolu hè ghjucatu da Kafka)
- caratteristiche di travaglià cù Elasticsearch Curator (creatu periodicamente una carica alta da i travaglii regulari in Curator)
- senza autorizazione integrata (solu per soldi separati, abbastanza grande, o cum'è plugins open source di vari gradi di prontezza per a produzzione)
Ci era solu recensioni pusitivi nantu à Open Distro for Elasticsearch :) U listessu prublema di l'autorizazione hè stata risolta quì.
Da induve vene u petabyte?I so nodi sò custituiti da servitori cù 12 * 8 Tb SATA + 2 * 2 Tb SSD. Cold storage on SATA, SSD only for hot cache (hot storage).
7 + 9 servitori, (7 + 9) * 12 * 8 = 1536 Tb.
Una parte di u spaziu hè in riserva, riservata per a redundanza, etc.
I logs da circa 90 applicazioni sò mandati à Elasticsearch, cumprese tutti i servizii di rapportu di Kontur, Elba, etc.
Funzioni di sviluppu nantu à Serverless
Dopu hè un rapportu di Ruslan Serkin da DataArt nantu à Serverless.
Ruslan hà parlatu di ciò chì u sviluppu cù l'approcciu Serverless hè in generale, è ciò chì e so caratteristiche sò.
Serverless hè un approcciu à u sviluppu in quale i sviluppatori ùn toccanu micca l'infrastruttura in ogni modu. Esempiu - AWS Lambda Serverless, Kubeless.io (Serverless in Kubernetes), Google Cloud Functions.
Una applicazione Serverless ideale hè solu una funzione chì manda una dumanda à un fornitore Serverless attraversu un Gateway API speciale. Un microserviziu ideale, mentri AWS Lambda sustene ancu un gran numaru di linguaggi di prugrammazione muderni. U costu di mantene è di implementazione di l'infrastruttura diventa zero in u casu di i fornitori di nuvola, u sustegnu di e piccule applicazioni serà ancu assai prezzu (AWS Lambda - $ 0.2 / 1 million requests simple).
A scalabilità di un tali sistema hè quasi ideale - u fornitore di nuvola si cura di questu stessu, Kubeless scala automaticamente in u cluster Kubernetes.
Ci sò svantaghji:
- u sviluppu di grandi applicazioni hè diventatu più difficiule
- ci hè difficultà cù l'applicazioni di prufilu (solu i logs sò dispunibuli per voi, ma micca u prufilu in u sensu di solitu)
- senza versione
Per esse onesto, aghju intesu parlà di Serverless uni pochi d'anni fà, ma tutti questi anni ùn era micca chjaru per mè cumu aduprà bè. Dopu à u rapportu di Ruslan, a cunniscenza apparsu, è dopu à u rapportu di Nikolai Sverchkov (Evil Martians) da a sezione Backend, hè stata cunsulidata. Ùn era micca in vanu chì sò andatu à a cunferenza :)
CI hè per i poveri, o vale a pena scrive u vostru propiu CI per un studiu web?
Mikhail Radionov, capu di u studiu web Flag da Ekaterinburg, hà parlatu di CI / CD auto-scrittu.
U so studiu hè passatu da "manuale CI / CD" (accede à u servitore via SSH, fate un git pull, ripetite 100 volte à ghjornu) à Jenkins è à un strumentu auto-scrittu chì vi permette di monitorà u codice è eseguisce versioni chjamati Pullkins. .
Perchè Jenkins ùn hà micca travagliatu? Ùn hà micca furnitu abbastanza flessibilità per difettu è era troppu difficiule di persunalizà.
"Flag" si sviluppa in Laravel (frame PHP). Quandu hà sviluppatu un servitore CI / CD, Mikhail è i so culleghi anu utilizatu i meccanismi integrati di Laravel chjamati Telescope and Envoy. U risultatu hè un servitore in PHP (per piacè nutate) chì processa e richieste di webhook entranti, pò custruisce u frontend è u backend, implementà à diversi servitori, è rapportu à Slack.
Dopu, per pudè eseguisce implementazione blu / verde è avè paràmetri uniformi in ambienti dev-stage-prod, anu cambiatu à Docker. I vantaghji sò stati listessi, e pussibulità di homogenizà l'ambiente è di implementazione senza saldatura sò state aghjunte, è a necessità di amparà Docker per travaglià cun ellu currettamente hè stata aghjunta.
Cumu avemu riduciutu u numeru di rollbacks di liberazione di u servitore di 99%
L'ultimu rapportu in a sezione Devops era da Viktor Eremchenko, Ingegnere di Devops Capu à Miro.com (ex RealTimeBoard).
RealTimeBoard, u pruduttu di punta di a squadra Miro, hè basatu annantu à una applicazione Java monolitica. A cullizzioni, a prova è a implementazione senza tempi di inattività hè un compitu difficiule. In questu casu, hè impurtante implementà una tale versione di u codice in modu chì ùn deve micca esse ritruvatu (hè un monolitu pisanti).
In a strada di custruisce un sistema chì vi permette di fà questu, Miro hà passatu per un percorsu chì includeva u travagliu nantu à l'architettura, l'arnesi utilizati (Atlassian Bamboo, Ansible, etc.), è u travagliu nantu à a struttura di e squadre (oghji anu. una squadra Devops dedicata + parechje squadre Scrum separate da sviluppatori di profili differenti).
A strada hè stata difficiule è spinosa, è Victor hà spartutu u dulore accumulatu è l'ottimisimu chì ùn hè micca finitu quì.
Ha vintu un libru per fà dumande
Sezione backend
Aghju riesciutu à assistisce à 2 rapporti - da Nikolay Sverchkov (Evil Martians), ancu nantu à Serverless, è da Grigory Koshelev (cumpagnia Kontur) nantu à a telemetria.
Serverless per i semplici mortali
Se Ruslan Sirkin hà parlatu di ciò chì Serverless hè, Nikolay hà dimustratu l'applicazioni simplici chì utilizanu Serverless, è hà parlatu di i dettagli chì afectanu u costu è a velocità di l'applicazioni in AWS Lambda.
Un dettagliu interessante: l'elementu minimu pagatu hè 128 Mb di memoria è 100 ms CPU, custa $ 0,000000208. Inoltre, 1 milione di tali richieste per mese sò gratuiti.
Alcune di e funzioni di Nikolai spessu superanu u limitu di 100 ms (l'applicazione principale hè stata scritta in Ruby), cusì a riscrittura in Go hà furnitu un risparmiu eccellente.
Vostok Hercules - rende a telemetria grande di novu!
L'ultimu rapportu di a sezione Backend da Grigory Koshelev (cumpagnia Kontur) nantu à a telemetria. Telemetria significa logs, metriche, tracce di l'applicazione.
Per questu scopu, Contour usa strumenti scritti da sè pubblicati nantu à Github. Strumenta da u rapportu - Hercules, , hè utilizatu per furnisce dati di telemetria.
U rapportu di Vladimir Lila in a rùbbrica Devops hà discututu l'almacenamiento è u processu di logs in Elasticsearch, ma ci hè sempre u compitu di furnisce logs da parechji millaie di dispusitivi è applicazioni, è arnesi cum'è Vostok Hercules risolve.
U circuitu hà seguitu una strada cunnisciuta da parechji - da RabbitMQ à Apache Kafka, ma micca tuttu hè cusì simplice)) Avianu à aghjunghje Zookeeper, Cassandra è Graphite à u circuitu. Ùn divulgaraghju micca cumplettamente l'infurmazioni nantu à stu rapportu (micca u mo prufilu), se site interessatu, pudete aspittà per i slides è i video nantu à u situ web di a cunferenza.
Cume si paraguna cù altre cunferenze?
Ùn possu micca paragunà cù cunferenze in Mosca è San Petruburgu, ponu paragunà cù altri avvenimenti in l'Urali è cù 404fest in Samara.
DAMP hè tenutu in 8 sezioni, questu hè un record per e cunferenze Urali. Sezioni assai grande di Scienza è Gestione, questu hè ancu inusual. L'audienza in Ekaterinburg hè abbastanza strutturata - a cità hà grandi dipartimenti di sviluppu per Yandex, Kontur, Tinkoff, è questu lascia a so marca nantu à i rapporti.
Un altru puntu interessante hè chì parechje cumpagnie anu 3-4 parlanti à a cunferenza in una volta (questu era u casu cù Kontur, Evil Martians, Tinkoff). Parechji di elli eranu sponsors, ma i rapporti sò abbastanza à parità cù l'altri, ùn sò micca rapporti di publicità.
Andà o micca ? Sè vo campate in l'Urali o vicinu, avete l'uppurtunità è sò interessati à i temi - iè, sicuru. Sè vo site à pensà à un viaghju longu, aghju guardatu i temi di rapporti è video di l'anni precedenti è hà fattu una decisione.
Un altru vantaghju di e cunferenze in e regioni, in regula, hè chì hè faciule di cumunicà cù u parlante dopu i rapporti; ci sò solu menu candidati per una tale cumunicazione.
Grazie à Dump è Ekaterinburg! )
Source: www.habr.com