Ferline wike gie ik nei de DUMP IT-konferinsje (https://dump-ekb.ru/) yn Jekaterinburg en ik wol jo fertelle wat besprutsen waard yn 'e Backend en Devops-seksjes, en oft regionale IT-konferinsjes oandacht wurdich binne.
Nikolay Sverchkov út Evil Martians oer Serverless
Wat wie der dochs?
Yn totaal hie de konferinsje 8 seksjes: Backend, Frontend, Mobile, Testen en QA, Devops, Untwerp, Wittenskip en Management.
De grutste sealen binne trouwens by Science and Management)) Foar elk ~350 minsken. Backend en Frontend binne net folle lytser. De Devops keamer wie de lytste, mar aktyf.
Ik harke nei de ferslaggen yn 'e Devops- en Backend-seksjes en praat in bytsje mei de sprekkers. Ik wol graach prate oer de behannele ûnderwerpen en dizze seksjes besjen op 'e konferinsje.
Fertsjintwurdigers fan SKB-Kontur, DataArt, Evil Martians, Ekaterinburg webstudio Flag, Miro (RealTimeBoard) sprieken yn 'e Devops- en Backend-seksjes. Underwerpen behannele CI / CD, wurkje mei wachtrige tsjinsten, logging; Serverless ûnderwerpen en wurkje mei PostgreSQL in Go waarden goed behannele.
D'r wiene ek rapporten fan Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mar ik hie gjin tiid om se fysyk by te wenjen (fideo-opnames en dia's fan 'e rapporten binne noch net beskikber, se tasizze se binnen 2 wiken te pleatsen op dump-ekb.ru).
Devops seksje
Wat ferrassend wie, wie dat de seksje hâlden waard yn de lytste seal, sa'n 50 sitten. Minsken stiene sels yn 'e gongen :) Ik sil jo fertelle oer de reportaazjes dy't ik slagge om te harkjen.
Elastysk gewicht in petabyte
De seksje begon mei in rapport fan Vladimir Lil (SKB-Kontur) oer Elasticsearch yn Kontur. Se hawwe in frij grutte en laden Elastic (~ 800 TB oan gegevens, ~ 1.3 petabytes rekken hâldend mei redundancy). Elasticsearch foar alle Kontur tsjinsten is single, bestiet út 2 klusters (fan 7 en 9 tsjinners), en is sa wichtich dat Kontur hat in spesjale Elasticsearch yngenieur (yn feite, Vladimir sels).
Vladimir dielde ek syn gedachten oer de foardielen fan Elasticsearch en de problemen dy't it bringt.
Foardiel:
- Alle logs binne op ien plak, maklike tagong ta harren
- It opslaan fan logs foar in jier en maklik analysearje se
- Hoge snelheid fan wurkjen mei logs
- Coole gegevensfisualisaasje út it fak
Problemen:
- berjochtmakelaar is in must-have (foar Kontur wurdt syn rol spile troch Kafka)
- funksjes fan wurkjen mei Elasticsearch Curator (periodyk makke hege lading fan reguliere taken yn Curator)
- gjin ynboude autorisaasje (allinich foar apart, frij grut jild, of as iepen boarne plugins fan ferskate graden fan reewilligens foar produksje)
D'r wiene allinich positive resinsjes oer Open Distro foar Elasticsearch :) Itselde kwestje fan autorisaasje is dêr oplost.
Wêr komt de petabyte wei?Harren knopen besteane út servers mei 12 * 8 Tb SATA + 2 * 2 Tb SSD. Kâlde opslach op SATA, SSD allinich foar hot cache (hot opslach).
7+9 tsjinners, (7 + 9) * 12 * 8 = 1536 Tb.
In part fan de romte is yn reserve, ôfset foar ûntslach, ensfh.
Logs fan sa'n 90 applikaasjes wurde stjoerd nei Elasticsearch, ynklusyf alle rapportaazjetsjinsten fan Kontur, Elba, ensfh.
Funksjes fan ûntwikkeling op Serverless
Folgjende is in rapport fan Ruslan Serkin fan DataArt oer Serverless.
Ruslan spruts oer wat ûntwikkeling mei de Serverless-oanpak yn 't algemien is, en wat de funksjes binne.
Serverless is in oanpak foar ûntwikkeling wêryn ûntwikkelders de ynfrastruktuer op gjin inkelde manier oanreitsje. Foarbyld - AWS Lambda Serverless, Kubeless.io (Serverless binnen Kubernetes), Google Cloud Functions.
In ideale Serverless applikaasje is gewoan in funksje dy't stjoert in fersyk nei in Serverless provider fia in spesjale API Gateway. In ideale mikrotsjinst, wylst AWS Lambda ek in grut oantal moderne programmeartalen stipet. De kosten foar it ûnderhâlden en ynsetten fan ynfrastruktuer wurde nul yn it gefal fan wolkproviders, it stypjen fan lytse applikaasjes sil ek heul goedkeap wêze (AWS Lambda - $ 0.2 / 1 miljoen ienfâldige oanfragen).
De skaalberens fan sa'n systeem is hast ideaal - de wolkprovider soarget der sels foar, Kubeless skaalt automatysk binnen it Kubernetes-kluster.
Der binne neidielen:
- it ûntwikkeljen fan grutte applikaasjes wurdt dreger
- d'r is muoite mei profilearjen fan applikaasjes (allinich logs binne foar jo beskikber, mar net profilearjen yn 'e gewoane sin)
- gjin ferzje
Om earlik te wêzen, hearde ik in pear jier lyn oer Serverless, mar al dy jierren wie it my net dúdlik hoe't ik it korrekt brûkte. Nei it rapport fan Ruslan ferskynde begryp, en nei it rapport fan Nikolai Sverchkov (Evil Martians) fan 'e Backend-seksje, waard it konsolidearre. It wie net om 'e nocht dat ik nei de konferinsje gie :)
CI is foar de earmen, of is it wurdich om jo eigen CI te skriuwen foar in webstudio?
Mikhail Radionov, haad fan 'e Flag-webstudio út Jekaterinburg, spruts oer selsskreaune CI / CD.
Syn studio is gien fan "manual CI / CD" (oanmelde by de tsjinner fia SSH, doch in git pull, werhelje 100 kear deis) nei Jenkins en nei in selsskreaun ark wêrmei jo koade kinne kontrolearje en releases útfiere neamd Pullkins .
Wêrom wurke Jenkins net? It levere standert net genôch fleksibiliteit en wie te lestich om oan te passen.
"Flagge" ûntwikkelet yn Laravel (PHP-ramt). By it ûntwikkeljen fan in CI / CD-tsjinner brûkten Mikhail en syn kollega's Laravel's ynboude meganismen neamd Telescope and Envoy. It resultaat is in server yn PHP (notysje asjebleaft) dy't ynkommende webhook-oanfragen ferwurket, de frontend en backend kin bouwe, ynsette nei ferskate servers, en rapportearje oan Slack.
Dan, om blau / grien ynset te kinnen en unifoarme ynstellingen te hawwen yn dev-stage-prod-omjouwings, skeakelen se oer nei Docker. De foardielen bleaunen itselde, de mooglikheden fan homogenisearjen fan it miljeu en naadleaze ynset waarden tafoege, en de needsaak om Docker te learen om der goed mei te wurkjen waard tafoege.
Hoe't wy it oantal weromsette serverreleases mei 99% fermindere
It lêste rapport yn 'e Devops-seksje wie fan Viktor Eremchenko, Lead devops-yngenieur by Miro.com (earder RealTimeBoard).
RealTimeBoard, it flaggeskipprodukt fan it Miro-team, is basearre op in monolityske Java-applikaasje. It sammelje, testen en ynsette sûnder downtime is in drege taak. Yn dit gefal is it wichtich om sa'n ferzje fan 'e koade yn te setten sadat it net werom hoecht te rôljen (it is in swiere monolith).
Underweis nei it bouwen fan in systeem wêrmei jo dit kinne dwaan, gie Miro troch in paad dat wurke oan 'e arsjitektuer, de brûkte ark (Atlassian Bamboo, Ansible, ensfh.) in tawijd Devops-team + in protte aparte Scrum-teams fan ûntwikkelders fan ferskate profilen).
It paad blykte lestich en steklik te wêzen, en Victor dielde de opboude pine en optimisme dat dêr net einige.
In boek wûn foar it stellen fan fragen
Backend seksje
Ik slagge 2 rapporten by te wenjen - fan Nikolay Sverchkov (Evil Martians), ek oer Serverless, en fan Grigory Koshelev (Kontur bedriuw) oer telemetry.
Serverless foar gewoane stjerliken
As Ruslan Sirkin praat oer wat Serverless is, liet Nikolay ienfâldige applikaasjes sjen mei Serverless, en spruts oer de details dy't de kosten en snelheid fan applikaasjes yn AWS Lambda beynfloedzje.
In nijsgjirrich detail: it minimum betelle elemint is 128 Mb ûnthâld en 100 ms CPU, it kostet $ 0,000000208. Boppedat binne 1 miljoen sokke oanfragen per moanne fergees.
Guon fan Nikolai's funksjes hawwe faaks de limyt fan 100 ms oertroffen (de haadapplikaasje waard skreaun yn Ruby), dus it oerskriuwen fan se yn Go levere poerbêste besparring.
Vostok Hercules - meitsje telemetry wer geweldich!
It lêste rapport fan 'e Backend-seksje fan Grigory Koshelev (Kontur-bedriuw) oer telemetry. Telemetry betsjut logs, metriken, applikaasjespoaren.
Foar dit doel brûkt Contour sels skreaune ark pleatst op Github. Tool út it rapport - Hercules, , wurdt brûkt om telemetrygegevens te leverjen.
Vladimir Lila's rapport yn 'e Devops-seksje besprutsen it opslaan en ferwurkjen fan logs yn Elasticsearch, mar d'r is noch altyd de taak om logs te leverjen fan in protte tûzenen apparaten en applikaasjes, en ark lykas Vostok Hercules oplosse se.
It circuit folge in paad bekend foar in protte - fan RabbitMQ oant Apache Kafka, mar net alles is sa ienfâldich)) Se moasten Zookeeper, Cassandra en Graphite tafoegje oan it circuit. Ik sil de ynformaasje oer dit rapport net folslein iepenbierje (net myn profyl), as jo ynteressearre binne, kinne jo wachtsje op de dia's en fideo's op 'e konferinsjewebside.
Hoe fergeliket it mei oare konferinsjes?
Ik kin it net fergelykje mei konferinsjes yn Moskou en Sint-Petersburch, ik kin it fergelykje mei oare eveneminten yn 'e Oeral en mei 404fest yn Samara.
DAMP wurdt hâlden yn 8 seksjes, dit is in rekord foar Oeral-konferinsjes. Hiel grutte wittenskip en behear seksjes, dit is ek ûngewoan. It publyk yn Jekaterinburg is frij strukturearre - de stêd hat grutte ûntwikkeling ôfdielings foar Yandex, Kontur, Tinkoff, en dit lit syn mark op 'e rapporten.
In oar nijsgjirrich punt is dat in protte bedriuwen tagelyk 3-4 sprekkers hawwe op 'e konferinsje (dit wie it gefal mei Kontur, Evil Martians, Tinkoff). In protte fan harren wiene sponsors, mar de rapporten binne frij op par mei oaren, dit binne gjin reklame rapporten.
Gean of net gean? As jo yn 'e Oeral wenje of yn' e buert, hawwe jo de kâns en binne jo ynteressearre yn 'e ûnderwerpen - ja, fansels. As jo tinke oan in lange reis, soe ik sjen nei de ûnderwerpen fan rapporten en fideoferslaggen fan eardere jierren en makke in beslút.
In oar foardiel fan konferinsjes yn 'e regio's, yn' e regel, is dat it maklik is om te kommunisearjen mei de sprekker nei de rapporten; d'r binne gewoan minder oanfregers foar sokke kommunikaasje.
Mei tank oan Dump en Ekaterinburg! )
Boarne: www.habr.com