I sidste uge var jeg til DUMP IT-konferencen (https://dump-ekb.ru/) i Jekaterinburg, og jeg vil gerne fortælle dig, hvad der blev diskuteret i Backend- og Devops-sektionerne, og om regionale IT-konferencer er værd at være opmærksomme på.
Nikolay Sverchkov fra Evil Martians om Serverless
Hvad var der overhovedet?
I alt havde konferencen 8 sektioner: Backend, Frontend, Mobil, Test og QA, Devops, Design, Science og Management.
De største haller er i øvrigt på Science and Management)) Til ~350 personer hver. Backend og Frontend er ikke meget mindre. Devops-rummet var det mindste, men aktivt.
Jeg lyttede til rapporterne i Devops- og Backend-sektionerne og snakkede lidt med højttalerne. Jeg vil gerne tale om de behandlede emner og gennemgå disse afsnit på konferencen.
Repræsentanter for SKB-Kontur, DataArt, Evil Martians, Ekaterinburg webstudiet Flag, Miro (RealTimeBoard) talte i Devops- og Backend-sektionerne. Emner dækket CI/CD, arbejde med køtjenester, logning; Serverløse emner og arbejde med PostgreSQL in Go var godt dækket.
Der var også rapporter fra Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, men jeg havde ikke tid til fysisk at deltage i dem (videooptagelser og dias af rapporterne er endnu ikke tilgængelige, de lover at sende dem inden for 2 uger på dump-ekb.ru).
Devops sektion
Det overraskende var, at afdelingen blev holdt i den mindste sal, omkring 50 pladser. Folk stod endda i gangene :) Jeg vil fortælle dig om de rapporter, som jeg nåede at lytte til.
Elastik vejer en petabyte
Afsnittet begyndte med en rapport af Vladimir Lil (SKB-Kontur) om Elasticsearch i Kontur. De har en ret stor og indlæst elastik (~800 TB data, ~1.3 petabyte under hensyntagen til redundans). Elasticsearch for alle Kontur-tjenester er enkeltstående, består af 2 klynger (på 7 og 9 servere), og er så vigtig, at Kontur har en særlig Elasticsearch-ingeniør (faktisk Vladimir selv).
Vladimir delte også sine tanker om fordelene ved Elasticsearch og de problemer, det medfører.
fordele:
- Alle logfiler er samlet ét sted, let adgang til dem
- Lagring af logs i et år og let analyse af dem
- Høj hastighed af arbejde med logs
- Fed datavisualisering ud af kassen
Problemerne:
- beskedmægler er et must have (for Kontur spilles dens rolle af Kafka)
- funktioner ved at arbejde med Elasticsearch Curator (periodisk skabt høj belastning fra almindelige opgaver i Curator)
- ingen indbygget autorisation (kun for separate, ret store penge eller som open source-plugins af varierende grad af klarhed til produktion)
Der var kun positive anmeldelser om Open Distro for Elasticsearch :) Det samme spørgsmål om autorisation er blevet løst der.
Hvor kommer petabyten fra?Deres noder består af servere med 12*8 Tb SATA + 2*2 Tb SSD. Kold lagring på SATA, SSD kun til hot cache (hot storage).
7+9 servere, (7 + 9) * 12 * 8 = 1536 Tb.
En del af pladsen er i reserve, afsat til afskedigelse mv.
Logs fra omkring 90 ansøgninger sendes til Elasticsearch, herunder alle rapporteringstjenester fra Kontur, Elba mv.
Funktioner ved udvikling på serverløs
Dernæst er en rapport af Ruslan Serkin fra DataArt om Serverless.
Ruslan talte om, hvad udvikling med Serverless-tilgangen generelt er, og hvad dens funktioner er.
Serverløs er en tilgang til udvikling, hvor udviklere ikke rører infrastrukturen på nogen måde. Eksempel - AWS Lambda Serverless, Kubeless.io (Serverless inde i Kubernetes), Google Cloud Functions.
En ideel serverløs applikation er simpelthen en funktion, der sender en anmodning til en serverløs udbyder gennem en speciel API-gateway. En ideel mikroservice, mens AWS Lambda også understøtter en lang række moderne programmeringssprog. Omkostningerne ved at vedligeholde og implementere infrastruktur bliver nul i tilfælde af cloud-udbydere, at understøtte små applikationer vil også være meget billige (AWS Lambda - $0.2 / 1 million simple anmodninger).
Skalerbarheden af sådan et system er næsten ideel - cloud-udbyderen sørger selv for dette, Kubeless skalerer automatisk inden for Kubernetes-klyngen.
Der er ulemper:
- at udvikle store applikationer bliver sværere
- der er problemer med profileringsapplikationer (kun logfiler er tilgængelige for dig, men ikke profilering i sædvanlig forstand)
- ingen versionering
For at være ærlig hørte jeg om Serverless for et par år siden, men i alle disse år var det ikke klart for mig, hvordan jeg skulle bruge det korrekt. Efter Ruslans rapport dukkede forståelse op, og efter rapporten fra Nikolai Sverchkov (Evil Martians) fra Backend-sektionen blev den konsolideret. Det var ikke forgæves, at jeg tog til konferencen :)
CI er for de fattige, eller er det værd at skrive dit eget CI til et webstudie?
Mikhail Radionov, leder af Flag-webstudiet fra Jekaterinburg, talte om selvskrevet CI/CD.
Hans studie er gået fra "manuel CI/CD" (log ind på serveren via SSH, lav et git pull, gentag 100 gange om dagen) til Jenkins og til et selvskrevet værktøj, der giver dig mulighed for at overvåge kode og udføre udgivelser kaldet Pullkins .
Hvorfor arbejdede Jenkins ikke? Det gav som standard ikke tilstrækkelig fleksibilitet og var for svært at tilpasse.
"Flag" udvikles i Laravel (PHP-ramme). Da Mikhail og hans kolleger udviklede en CI/CD-server, brugte han Laravels indbyggede mekanismer kaldet Telescope and Envoy. Resultatet er en server i PHP (bemærk venligst), der behandler indkommende webhook-anmodninger, kan bygge frontend og backend, implementere til forskellige servere og rapportere til Slack.
Derefter skiftede de til Docker for at kunne udføre blå/grøn implementering og have ensartede indstillinger i dev-stage-prod-miljøer. Fordelene forblev de samme, mulighederne for at homogenisere miljøet og problemfri implementering blev tilføjet, og behovet for at lære Docker at arbejde med det korrekt blev tilføjet.
Hvordan vi reducerede antallet af serverudgivelser rollbacks med 99 %
Den sidste rapport i Devops-sektionen var fra Viktor Eremchenko, Lead devops-ingeniør hos Miro.com (tidligere RealTimeBoard).
RealTimeBoard, Miro-teamets flagskibsprodukt, er baseret på en monolitisk Java-applikation. At indsamle, teste og implementere det uden nedetid er en vanskelig opgave. I dette tilfælde er det vigtigt at implementere en sådan version af koden, så den ikke skal rulles tilbage (det er en tung monolit).
På vej til at bygge et system, der giver dig mulighed for at gøre dette, gik Miro gennem en sti, der omfattede arbejde med arkitekturen, de anvendte værktøjer (Atlassian Bamboo, Ansible osv.) og arbejdet med strukturen af holdene (de har nu et dedikeret Devops-team + mange separate Scrum-teams fra udviklere med forskellige profiler).
Vejen viste sig at være svær og tornet, og Victor delte den ophobede smerte og optimisme, der ikke sluttede der.
Vandt en bog for at stille spørgsmål
Backend sektion
Jeg nåede at deltage i 2 rapporter - fra Nikolay Sverchkov (Evil Martians), også om Serverless, og fra Grigory Koshelev (Kontur-firmaet) om telemetri.
Serverløs for rene dødelige
Hvis Ruslan Sirkin talte om, hvad Serverless er, viste Nikolay simple applikationer ved hjælp af Serverless, og talte om detaljerne, der påvirker omkostningerne og hastigheden af applikationer i AWS Lambda.
En interessant detalje: det mindste betalte element er 128 Mb hukommelse og 100 ms CPU, det koster $0,000000208. Desuden er 1 million sådanne anmodninger om måneden gratis.
Nogle af Nikolais funktioner overskred ofte grænsen på 100 ms (hovedapplikationen blev skrevet i Ruby), så omskrivning af dem i Go gav fremragende besparelser.
Vostok Hercules — gør telemetri fantastisk igen!
Den seneste rapport fra Backend-sektionen fra Grigory Koshelev (Kontur-virksomheden) om telemetri. Telemetri betyder logfiler, metrikker, applikationsspor.
Til dette formål bruger Contour selvskrevne værktøjer udgivet på Github. Værktøj fra rapporten - Hercules, , bruges til at levere telemetridata.
Vladimir Lilas rapport i Devops-sektionen diskuterede lagring og behandling af logfiler i Elasticsearch, men der er stadig opgaven med at levere logfiler fra mange tusinde enheder og applikationer, og værktøjer som Vostok Hercules løser dem.
Kredsløbet fulgte en vej kendt af mange - fra RabbitMQ til Apache Kafka, men ikke alt er så simpelt)) De var nødt til at tilføje Zookeeper, Cassandra og Graphite til kredsløbet. Jeg vil ikke afsløre oplysningerne om denne rapport fuldt ud (ikke min profil), hvis du er interesseret, kan du vente på slides og videoer på konferencens hjemmeside.
Hvordan er det sammenlignet med andre konferencer?
Jeg kan ikke sammenligne det med konferencer i Moskva og St. Petersborg, jeg kan sammenligne det med andre begivenheder i Ural og med 404fest i Samara.
DAMP afholdes i 8 sektioner, dette er rekord for Ural-konferencer. Meget store Science and Management sektioner, dette er også usædvanligt. Publikum i Jekaterinburg er ret struktureret – byen har store udviklingsafdelinger for Yandex, Kontur, Tinkoff, og det sætter sit præg på rapporterne.
En anden interessant pointe er, at mange virksomheder har 3-4 talere på konferencen på én gang (det var tilfældet med Kontur, Evil Martians, Tinkoff). Mange af dem var sponsorer, men rapporterne er helt på niveau med andre, det er ikke reklamerapporter.
At gå eller ikke at gå? Bor du i Ural eller i nærheden, har du muligheden og interesserer dig for emnerne – ja, selvfølgelig. Hvis du tænker på en lang tur, vil jeg se på emnerne rapporter og videoreportager fra tidligere år og tog en beslutning.
En anden fordel ved konferencer i regionerne er som udgangspunkt, at det er nemt at kommunikere med oplægsholderen efter rapporterne, der er simpelthen færre ansøgere til sådan kommunikation.
Tak til Dump og Ekaterinburg! )
Kilde: www.habr.com