I sidste uge deltog jeg i IT-konferencen DUMP (https://dump-ekb.ru/) i Jekaterinburg og vil gerne fortælle, hvad der blev diskuteret i sektionerne Backend og Devops, samt om regionale IT-konferencer er værd at besøge.
Nikolaj Sverchkov fra Evil Martians om Serverless
Hvad skete der overhovedet?
Der var i alt 8 sektioner på konferencen: Backend, Frontend, Mobile, Test og QA, Devops, Design, Science og Management.
De største sale var faktisk Science og Management med ca. 350 personer hver. Backend og Frontend var lidt mindre. Devops-salen var den mindste, men meget aktiv.
Jeg lyttede til præsentationer i sektionerne Devops og Backend og snakkede lidt med talerne. Jeg vil gerne fortælle om de emner, der blev præsenteret, og give et overblik over disse sektioner på konferencen.
I sektionerne Devops og Backend præsenterede repræsentanter fra SKB-Kontur, DataArt, Evil Martians, den jekaterinburgske webstudio Flag, Miro (RealTimeBoard). Emnerne omhandlede CI/CD, arbejde med køtjenester, logning, og emnerne Serverless og arbejde med PostgreSQL i Go blev også godt præsenteret.
Der var også præsentationer fra Avito, Tinkoff, Yandex, Jetstyle, MegaFon, bank Ak Bars, men jeg nåede ikke at besøge dem fysisk (videooptagelser og præsentationer er endnu ikke tilgængelige, de lover at offentliggøre dem inden for 2 uger på dump-ekb.ru).
Devops-sektion
Det, der overraskede, var, at sektionen fandt sted i den mindste sal, cirka 50 pladser. Folk stod endda i gangene 🙂 Jeg vil fortælle om de præsentationer, jeg nåede at høre.
Elasticsearch med en vægt på petabyte
Sektionen begyndte med en præsentation af Vladimir Lila (SKB-Kontur) om Elasticsearch i Kontur. De har en temmelig stor og belastet Elasticsearch (~800 TB data, ~1,3 petabyte med redundans). Elasticsearch for alle Kontur-tjenester er en enhed, som består af 2 klynger (med 7 og 9 servere), og det er så vigtigt, at Kontur har en speciel Elasticsearch-ingeniør (faktisk Vladimir selv).
Vladimir delte også sine tanker om fordelene ved Elasticsearch og de problemer, det medfører.
Fordele:
- Alle logs på ét sted, let adgang til dem
- Opbevaring af logs i et år og nem analyse af dem
- Høj hastighed ved arbejde med logs
- Fremragende datavisualisering 'out of the box'
Problemer:
- meldingsbroker — must have (i Kontur udfylder Kafka denne rolle)
- specifikke aspekter ved arbejdet med Elasticsearch Curator (periodisk høj belastning fra regelmæssige opgaver i Curator)
- ingen indbygget autorisation (kun for separate, ret dyre penge, eller som open source-plugins af forskellig grad af klarhed til produktion)
Om Open Distro for Elasticsearch har anmeldelser der kun er positive 🙂 Samme spørgsmål om autentifikation er løst der.
Hvor kommer petabyte fra?Deres noder består af servere med 12*8 Tb SATA + 2*2 Tb SSD. Kold opbevaring på SATA, SSD kun til varmt cache (hot storage).
7+9 servere, (7 + 9) * 12 * 8 = 1536 Tb.
En del plads er reserveret, afsat til redundans osv.
Logfiler fra ca. 90 applikationer sendes til Elasticsearch, herunder alle rapporteringstjenester fra Kontur, Elba osv.
Særligheder ved udvikling på Serverless
Følgende er et oplæg af Ruslan Serkin fra DataArt om Serverless.
Ruslan forklarede, hvad udvikling med Serverless-tilgangen egentlig er, og hvad dens særlige kendetegn er.
Serverless er en tilgang til udvikling, hvor udviklerne på ingen måde rører infrastrukturen. Eksempel - AWS Lambda Serverless, Kubeless.io (Serverless inden for Kubernetes), Google Cloud Functions.
En ideel Serverless-applikation er simpelthen en funktion, der sender en forespørgsel til Serverless-udbyderen gennem en speciel API Gateway. En ideel mikrotjeneste, mens der i AWS Lambda understøttes et stort antal moderne programmeringssprog. Omkostningerne ved at vedligeholde og implementere infrastrukturen bliver nul ifølge cloud-udbydere, og vedligeholdelsen af små applikationer vil også være meget billig (AWS Lambda - 0.2$ / 1 million simple forespørgsler).
Skalérbarheden af et sådant system er praktisk talt ideel - cloud-udbyderen tager sig selv af det, Kubeless skalerer automatisk inden for Kubernetes-klusteret.
Der er ulemper:
- udvikling af store applikationer bliver mere kompleks
- der er vanskeligheder med profilering af applikationer (du har kun adgang til logs, men ikke profilering i den kendte betydning)
- der er ingen versionering
Jeg må være ærlig, jeg hørte om Serverless for flere år siden, men i alle disse år var det uklart for mig, hvordan man korrekt anvender det. Efter Ruslans oplæg fik jeg forståelse, og efter Nikolaj Sverchkovs (Evil Martians) oplæg fra Backend-sektionen blev det bekræftet. Det var ikke forgæves, at jeg gik til konferencen 🙂
CI for de fattige, eller er det værd at skrive sin egen CI for et webbureau
Mikhail Radionov, leder af webbureauet Flag i Jekaterinburg, fortalte om deres egen CI/CD.
Hans bureau er gået fra 'manuelt CI/CD' (logget ind på serveren via SSH, lavet git pull, gentaget 100 gange om dagen) til Jenkins og et skræddersyet værktøj, der gør det muligt at kontrollere koden og udføre udgivelser ved navn Pullkins.
Hvorfor var Jenkins ikke tilfredsstillende? Det gav ikke tilstrækkelig fleksibilitet som standard og var for komplekst at tilpasse.
“Flag” udvikler på Laravel (PHP framework). Under udviklingen af CI/CD-serveren benyttede Mikhail og hans kolleger de indbyggede mekanismer i Laravel kaldet Telescope og Envoy. Resultatet blev en server på PHP (vær opmærksom), der behandler indkommende webhook-forespørgsler, kan udføre bygninger af frontend og backend, deploye til forskellige servere og rapportere til Slack.
Dernæst, for at kunne udføre blue/green deployment og have ensartede indstillinger i dev-stage-prod miljøer, skiftede de til Docker. Fordelene forblev de samme, men der kom muligheder for homogenisering af miljøet og sømløs deployment, og der blev et behov for at lære Docker for at arbejde korrekt med det.
Hvordan vi reducerede antallet af tilbagerulninger af serverudgivelser med 99%
Den sidste præsentation i DevOps-sektionen blev givet af Viktor Eremenko, Lead DevOps-ingeniør hos Miro.com (tidligere RealTimeBoard).
Kernen af RealTimeBoard, hovedproduktet fra Miro-teamet, er en monolitisk applikation på Java. At bygge, teste og deploye det uden nedetid er en udfordring. Det er vigtigt at deploye en version af koden, som ikke kræver tilbagerulning (det er jo en tung monolit).
For at opbygge et system, der gør dette muligt, har Miro gennemgået en rejse, der inkluderer arbejde med arkitekturen, de anvendte værktøjer (Atlassian Bamboo, Ansible osv.) og opbygning af teams (de har i øjeblikket et dedikeret DevOps-team + mange separate Scrum-teams af udviklere med forskellige profiler).
Rejsen viste sig at være svær og besværlig, og Viktor delte sin opsamlede smerte og den uafsluttede optimisme.
Vandt en bog for spørgsmål
Backend-sektionen
Jeg nåede to præsentationer - fra Nikolai Svirchkov (Evil Martians), også om Serverless, og fra Grigory Koshelev (Kontur-virksomheden) om telemetry.
Serverless for almindelige dødelige
Hvis Ruslan Sirkin talte om, hvad Serverless er, viste Nikolai enkle applikationer ved hjælp af Serverless, og fortalte om detaljer, der påvirker omkostningerne og hastigheden af applikationer i AWS Lambda.
En interessant detalje: det mindste betalte element - 128 Mb hukommelse og 100 ms CPU, koster 0,000000208$. Desuden er 1 million sådanne forespørgsler gratis om måneden.
Nogle af Nikolajs funktioner oversteg ofte grænsen på 100 ms (det primære program var skrevet i Ruby), så omskrivningen af dem til Go gav en fremragende besparelse.
Vostok Hercules — få telemetri tilbage på sporet!
Den seneste præsentation fra Backend-sektionen af Grigory Koshelev (firmaet Kontur) om telemetri. Telemetri er logs, metrikker, og applikationstraceringer.
Kontur bruger deres egne værktøjer, som er offentliggjort på Github. Værktøjet fra præsentationen — Hercules, , bruges til at levere telemetridata.
I Vladimir Lilas præsentation i DevOps-sektionen blev opbevaring og behandling af logs i Elasticsearch drøftet, men der er også opgaven med at levere logs fra mange tusinde enheder og applikationer, som tackles med værktøjer som Vostok Hercules.
Kontur har gennemgået en velkendt rute — fra RabbitMQ til Apache Kafka, men det var ikke så ligetil)) De måtte tilføje Zookeeper, Cassandra og Graphite til skemaet. Jeg vil ikke afsløre alle detaljer fra denne præsentation (det er ikke mit område), men hvis det er interessant, kan man vente på slides og video på konferencens hjemmeside.
Hvordan sammenlignet det sig med andre konferencer?
Jeg kan ikke sammenligne med konferencer i Moskva og Skt. Petersborg, men jeg kan sammenligne med andre arrangementer i Ural og 404fest i Samara.
DAMP afholdes i 8 sektioner, hvilket er rekord for Ural konferencer. Meget store sektioner som Science og Management, det er også usædvanligt. Publikum i Jekaterinburg er ret struktureret — byen har store udviklingsafdelinger som Yandex, Kontur og Tinkoff, hvilket også afspejles i præsentationerne.
En anden interessant pointe — mange virksomheder har straks 3-4 talere på konferencen (sådan var det med Kontur, Evil Martians, Tinkoff). Mange af dem var sponsorer, men præsentationerne var på niveau med de andre; de var ikke reklamepræsentationer.
Skal man tage af sted eller ej? Hvis du bor i Ural eller i nærheden, og du har mulighed for at deltage og emnerne interesserer dig — ja, selvfølgelig. Hvis du overvejer at rejse langt — ville jeg se på emnerne for præsentationerne og tidligere videoer. og træffe en beslutning.
En anden fordel ved konferencer i regionerne er, at man som regel nemt kan tale med taleren efter præsentationerne, da der simpelthen er færre, der ønsker dette.
Tak til DAMP og Jekaterinburg! )
Kilde: habr.com
