DUMP konferanse | grep 'backend|devops'

Forrige uke dro jeg til DUMP IT-konferansen (https://dump-ekb.ru/) i Jekaterinburg, og jeg vil fortelle deg hva som ble diskutert i Backend- og Devops-delene, og om regionale IT-konferanser er verdt oppmerksomhet.

Nikolay Sverchkov fra Evil Martians om serverløs

Hva var det likevel?

Totalt hadde konferansen 8 seksjoner: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.

De største salene er forresten på Science and Management)) For ~350 personer hver. Backend og Frontend er ikke mye mindre. Devops-rommet var det minste, men aktive.

Jeg lyttet til rapportene i Devops- og Backend-delene og snakket litt med høyttalerne. Jeg vil gjerne snakke om temaene som dekkes og gjennomgå disse delene på konferansen.

Representanter for SKB-Kontur, DataArt, Evil Martians, Ekaterinburg webstudio Flag, Miro (RealTimeBoard) snakket i Devops- og Backend-seksjonene. Emner dekket CI/CD, arbeid med køtjenester, logging; Serverløse emner og arbeid med PostgreSQL in Go ble godt dekket.

Det var også rapporter fra Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, men jeg hadde ikke tid til å delta fysisk på dem (videoopptak og lysbilder av rapportene er ennå ikke tilgjengelige, de lover å legge dem ut innen 2 uker på dump-ekb.ru).

Devops-delen

Det overraskende var at seksjonen ble holdt i den minste salen, ca 50 plasser. Folk sto til og med i gangene :) Jeg skal fortelle deg om rapportene jeg klarte å lytte til.

Elastikk som veier en petabyte

Avsnittet startet med en rapport av Vladimir Lil (SKB-Kontur) om Elasticsearch i Kontur. De har en ganske stor og lastet elastikk (~800 TB med data, ~1.3 petabyte tatt i betraktning redundans). Elasticsearch for alle Kontur-tjenester er singel, består av 2 klynger (av 7 og 9 servere), og er så viktig at Kontur har en spesiell Elasticsearch-ingeniør (faktisk Vladimir selv).

Vladimir delte også sine tanker om fordelene med Elasticsearch og problemene det medfører.

fordeler:

• Alle logger er på ett sted, enkel tilgang til dem
• Lagre logger i et år og enkelt analysere dem
• Høy hastighet på arbeid med tømmerstokker
• Kul datavisualisering rett ut av esken

problemer:

• meldingsmegler er et must (for Kontur spilles rollen av Kafka)
• funksjoner ved å jobbe med Elasticsearch Curator (skapte periodisk høy belastning fra vanlige oppgaver i Curator)
• ingen innebygd autorisasjon (bare for separate, ganske store penger, eller som åpen kildekode-plugins med varierende grad av klarhet for produksjon)

Det var bare positive anmeldelser om Open Distro for Elasticsearch :) Det samme problemet med autorisasjon har blitt løst der.

Hvor kommer petabyten fra?Nodene deres består av servere med 12*8 Tb SATA + 2*2 Tb SSD. Kaldlagring på SATA, SSD kun for hot cache (hot storage).
7+9 servere, (7 + 9) * 12 * 8 = 1536 Tb.
En del av plassen er i reserve, avsatt til overtallighet mv.
Logger fra ca 90 søknader sendes til Elasticsearch, inkludert alle rapporteringstjenester til Kontur, Elba, etc.

Funksjoner ved utvikling på serverløs

Neste er en rapport av Ruslan Serkin fra DataArt om Serverless.

Ruslan snakket om hva utvikling med Serverless-tilnærmingen er generelt, og hva dens funksjoner er.

Serverløs er en tilnærming til utvikling der utviklere ikke berører infrastrukturen på noen måte. Eksempel – AWS Lambda Serverless, Kubeless.io (Serverless inside Kubernetes), Google Cloud Functions.

En ideell serverløs applikasjon er ganske enkelt en funksjon som sender en forespørsel til en serverløs leverandør gjennom en spesiell API-gateway. En ideell mikrotjeneste, mens AWS Lambda også støtter et stort antall moderne programmeringsspråk. Kostnaden for å vedlikeholde og distribuere infrastruktur blir null når det gjelder skyleverandører, støtte for små applikasjoner vil også være veldig billig (AWS Lambda - $0.2 / 1 million enkle forespørsler).

Skalerbarheten til et slikt system er nesten ideell – skyleverandøren tar seg av dette selv, Kubeless skalerer automatisk innenfor Kubernetes-klyngen.

Det er ulemper:

• utvikle store applikasjoner blir vanskeligere
• det er problemer med profileringsapplikasjoner (du har bare tilgang til logger, men ikke profilering i vanlig forstand)
• ingen versjonskontroll

For å være ærlig hørte jeg om Serverless for noen år siden, men i alle disse årene var det ikke klart for meg hvordan jeg skulle bruke det riktig. Etter Ruslans rapport dukket det opp forståelse, og etter rapporten til Nikolai Sverchkov (Evil Martians) fra Backend-seksjonen, ble den konsolidert. Det var ikke forgjeves jeg dro på konferansen :)

CI er for de fattige, eller er det verdt å skrive din egen CI for et webstudio?

Mikhail Radionov, leder av Flag webstudio fra Jekaterinburg, snakket om selvskreven CI/CD.

Studioet hans har gått fra "manuell CI/CD" (logg inn på serveren via SSH, gjør en git pull, gjenta 100 ganger om dagen) til Jenkins og til et selvskrevet verktøy som lar deg overvåke kode og utføre utgivelser kalt Pullkins .

Hvorfor jobbet ikke Jenkins? Det ga ikke nok fleksibilitet som standard og var for vanskelig å tilpasse.

"Flagg" utvikler seg i Laravel (PHP-rammeverket). Da Mikhail og kollegene utviklet en CI/CD-server, brukte Laravels innebygde mekanismer kalt Telescope and Envoy. Resultatet er en server i PHP (merk) som behandler innkommende webhook-forespørsler, kan bygge frontend og backend, distribuere til forskjellige servere og rapportere til Slack.

Deretter, for å kunne utføre blå/grønn distribusjon og ha enhetlige innstillinger i dev-stage-prod-miljøer, byttet de til Docker. Fordelene forble de samme, mulighetene for å homogenisere miljøet og sømløs distribusjon ble lagt til, og behovet for å lære Docker å jobbe med det riktig ble lagt til.

Prosjektet er på Github

Hvordan vi reduserte antall tilbakeføringer av serverutgivelser med 99 %

Den siste rapporten i Devops-delen var fra Viktor Eremchenko, Lead devops-ingeniør hos Miro.com (tidligere RealTimeBoard).

RealTimeBoard, Miro-teamets flaggskipprodukt, er basert på en monolitisk Java-applikasjon. Å samle, teste og distribuere det uten nedetid er en vanskelig oppgave. I dette tilfellet er det viktig å distribuere en slik versjon av koden slik at den ikke må rulles tilbake (det er en tung monolitt).

På vei til å bygge et system som lar deg gjøre dette, gikk Miro gjennom en vei som inkluderte å jobbe med arkitekturen, verktøyene som ble brukt (Atlassian Bamboo, Ansible, osv.), og arbeidet med strukturen til teamene (de har nå et dedikert Devops-team + mange separate Scrum-team fra utviklere med forskjellige profiler).

Veien viste seg å være vanskelig og tornefull, og Victor delte den oppsamlede smerten og optimismen som ikke tok slutt.

Vant en bok for å stille spørsmål

Backend-seksjon

Jeg klarte å delta på 2 rapporter - fra Nikolay Sverchkov (Evil Martians), også om Serverless, og fra Grigory Koshelev (Kontur-selskapet) om telemetri.

Serverløs for rene dødelige

Hvis Ruslan Sirkin snakket om hva Serverless er, viste Nikolay enkle applikasjoner som bruker Serverless, og snakket om detaljene som påvirker kostnadene og hastigheten til applikasjoner i AWS Lambda.

En interessant detalj: minimumsbetalt element er 128 Mb minne og 100 ms CPU, det koster $0,000000208. Dessuten er 1 million slike forespørsler per måned gratis.

Noen av Nikolais funksjoner overskred ofte grensen på 100 ms (hovedapplikasjonen ble skrevet i Ruby), så å omskrive dem i Go ga utmerkede besparelser.

Vostok Hercules — gjør telemetri flott igjen!

Den siste rapporten fra Backend-delen fra Grigory Koshelev (Kontur-selskapet) om telemetri. Telemetri betyr logger, beregninger, applikasjonsspor.

Til dette formålet bruker Contour selvskrevne verktøy lagt ut på Github. Verktøy fra rapporten - Hercules, github.com/vostok/hercules, brukes til å levere telemetridata.

Vladimir Lilas rapport i Devops-delen diskuterte lagring og behandling av logger i Elasticsearch, men det er fortsatt oppgaven med å levere logger fra mange tusen enheter og applikasjoner, og verktøy som Vostok Hercules løser dem.

Kretsen fulgte en vei kjent for mange - fra RabbitMQ til Apache Kafka, men ikke alt er så enkelt)) De måtte legge til Zookeeper, Cassandra og Graphite til kretsen. Jeg vil ikke avsløre informasjonen om denne rapporten (ikke min profil), hvis du er interessert, kan du vente på lysbildene og videoene på konferansens nettside.

Hvordan er det sammenlignet med andre konferanser?

Jeg kan ikke sammenligne det med konferanser i Moskva og St. Petersburg, jeg kan sammenligne det med andre arrangementer i Ural og med 404fest i Samara.

DAMP holdes i 8 seksjoner, dette er rekord for Ural-konferanser. Svært store Science and Management-seksjoner, dette er også uvanlig. Publikum i Jekaterinburg er ganske strukturert – byen har store utviklingsavdelinger for Yandex, Kontur, Tinkoff, og dette setter sitt preg på rapportene.

Et annet interessant poeng er at mange bedrifter har 3-4 foredragsholdere på konferansen samtidig (dette var tilfellet med Kontur, Evil Martians, Tinkoff). Mange av dem var sponsorer, men rapportene er ganske på høyde med andre, dette er ikke reklamereportasjer.

Å gå eller ikke gå? Bor du i Ural eller i nærheten har du muligheten og er interessert i temaene – ja, selvfølgelig. Hvis du tenker på en langtur, vil jeg se på temaene rapporter og videoreportasjer fra tidligere år www.youtube.com/user/videoitpeople/videos og tok en avgjørelse.
En annen fordel med konferanser i regionene er som regel at det er enkelt å kommunisere med foredragsholderen etter rapportene, det er rett og slett færre søkere til slik kommunikasjon.

Takk til Dump og Ekaterinburg! )

Kilde: www.habr.com