Förra veckan gick jag till DUMP IT-konferensen (https://dump-ekb.ru/) i Jekaterinburg och jag vill berätta vad som diskuterades i Backend- och Devops-sektionerna och om regionala IT-konferenser är värda uppmärksamhet.
Nikolay Sverchkov från Evil Martians om Serverless
Vad fanns det förresten?
Totalt hade konferensen 8 sektioner: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
De största salarna finns förresten på Science and Management)) För ~350 personer vardera. Backend och Frontend är inte mycket mindre. Devops-rummet var det minsta, men aktivt.
Jag lyssnade på rapporterna i Devops- och Backend-sektionerna och pratade lite med högtalarna. Jag skulle vilja prata om de ämnen som behandlas och granska dessa avsnitt på konferensen.
Representanter för SKB-Kontur, DataArt, Evil Martians, Ekaterinburg webbstudio Flag, Miro (RealTimeBoard) talade i Devops- och Backend-sektionerna. Ämnen täckte CI/CD, arbete med kötjänster, loggning, Serverlösa ämnen och arbete med PostgreSQL in Go täcktes väl.
Det fanns också rapporter från Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, men jag hade inte tid att fysiskt delta i dem (videoinspelningar och bilder av rapporterna är ännu inte tillgängliga, de lovar att lägga upp dem inom 2 veckor på dump-ekb.ru).
Devops avsnitt
Det som överraskade var att sektionen hölls i den minsta salen, cirka 50 sittplatser. Folk stod till och med i gångarna :) Jag ska berätta om rapporterna som jag lyckades lyssna på.
Resår som väger en petabyte
Avsnittet inleddes med en rapport av Vladimir Lil (SKB-Kontur) om Elasticsearch i Kontur. De har en ganska stor och laddad Elastic (~800 TB data, ~1.3 petabyte med hänsyn till redundans). Elasticsearch för alla Kontur-tjänster är singel, består av 2 kluster (av 7 och 9 servrar), och är så viktig att Kontur har en speciell Elasticsearch-ingenjör (i själva verket Vladimir själv).
Vladimir delade också med sig av sina tankar om fördelarna med Elasticsearch och de problem det medför.
fördelar:
- Alla loggar finns på ett ställe, enkel åtkomst till dem
- Lagra stockar i ett år och enkelt analysera dem
- Hög hastighet att arbeta med stockar
- Cool datavisualisering ur lådan
Problem:
- meddelandeförmedlare är ett måste (för Kontur spelas dess roll av Kafka)
- funktioner för att arbeta med Elasticsearch Curator (skapade periodvis hög belastning från vanliga uppgifter i Curator)
- ingen inbyggd auktorisering (endast för separata, ganska stora pengar, eller som plugins med öppen källkod med varierande grad av beredskap för produktion)
Det fanns bara positiva recensioner om Open Distro för Elasticsearch :) Samma behörighetsfråga har lösts där.
Var kommer petabyten ifrån?Deras noder består av servrar med 12*8 Tb SATA + 2*2 Tb SSD. Kalllagring på SATA, SSD endast för hot cache (hot storage).
7+9 servrar, (7 + 9) * 12 * 8 = 1536 Tb.
En del av utrymmet är i reserv, avsatt för övertalighet m.m.
Loggar från ett 90-tal ansökningar skickas till Elasticsearch, inklusive alla rapporteringstjänster av Kontur, Elba m.fl.
Funktioner för utveckling på Serverless
Nästa är en rapport av Ruslan Serkin från DataArt om Serverless.
Ruslan pratade om vad utveckling med det serverlösa tillvägagångssättet är i allmänhet, och vad dess funktioner är.
Serverless är ett tillvägagångssätt för utveckling där utvecklare inte rör infrastrukturen på något sätt. Exempel - AWS Lambda Serverless, Kubeless.io (Serverless inuti Kubernetes), Google Cloud Functions.
En idealisk serverlös applikation är helt enkelt en funktion som skickar en förfrågan till en serverlös leverantör via en speciell API-gateway. En idealisk mikrotjänst, medan AWS Lambda också stöder ett stort antal moderna programmeringsspråk. Kostnaden för att underhålla och distribuera infrastruktur blir noll i fallet med molnleverantörer, att stödja små applikationer kommer också att vara mycket billigt (AWS Lambda - $0.2 / 1 miljon enkla förfrågningar).
Skalbarheten för ett sådant system är nästan idealisk - molnleverantören sköter detta själv, Kubeless skalar automatiskt inom Kubernetes-klustret.
Det finns nackdelar:
- att utveckla stora applikationer blir svårare
- det är svårt med profileringsapplikationer (du har bara tillgång till loggar, men inte profilering i vanlig mening)
- ingen versionshantering
För att vara ärlig så hörde jag talas om Serverless för några år sedan, men under alla dessa år var det inte klart för mig hur jag skulle använda det på rätt sätt. Efter Ruslans rapport dök förståelse upp, och efter rapporten från Nikolai Sverchkov (Evil Martians) från Backend-sektionen, konsoliderades den. Det var inte förgäves att jag gick på konferensen :)
CI är för de fattiga, eller är det värt att skriva ett eget CI för en webbstudio?
Mikhail Radionov, chef för webbstudion Flag från Jekaterinburg, talade om självskriven CI/CD.
Hans studio har gått från "manuell CI/CD" (logga in på servern via SSH, gör en git pull, upprepa 100 gånger om dagen) till Jenkins och till ett självskrivet verktyg som låter dig övervaka kod och utföra releaser som kallas Pullkins .
Varför jobbade inte Jenkins? Det gav inte tillräckligt med flexibilitet som standard och var för svårt att anpassa.
"Flagga" utvecklas i Laravel (PHP-ramverket). När Mikhail och hans kollegor utvecklade en CI/CD-server använde han Laravels inbyggda mekanismer som kallas Telescope and Envoy. Resultatet är en server i PHP (observera) som behandlar inkommande webhook-förfrågningar, kan bygga frontend och backend, distribuera till olika servrar och rapportera till Slack.
Sedan, för att kunna utföra blå/grön driftsättning och ha enhetliga inställningar i dev-stage-prod-miljöer, bytte de till Docker. Fördelarna förblev desamma, möjligheterna att homogenisera miljön och sömlös driftsättning lades till, och behovet av att lära sig Docker att arbeta med det korrekt tillkom.
Hur vi minskade antalet återförda serverversioner med 99 %
Den sista rapporten i Devops-sektionen kom från Viktor Eremchenko, Lead devops-ingenjör på Miro.com (tidigare RealTimeBoard).
RealTimeBoard, Miro-teamets flaggskeppsprodukt, är baserad på en monolitisk Java-applikation. Att samla in, testa och distribuera det utan stillestånd är en svår uppgift. I det här fallet är det viktigt att distribuera en sådan version av koden så att den inte behöver rullas tillbaka (det är en tung monolit).
På vägen till att bygga ett system som låter dig göra detta gick Miro igenom en väg som inkluderade att arbeta med arkitekturen, de verktyg som användes (Atlassian Bamboo, Ansible, etc) och arbeta med strukturen för teamen (de har nu ett dedikerat Devops-team + många separata Scrum-team från utvecklare med olika profiler).
Vägen visade sig vara svår och taggig och Victor delade den samlade smärtan och optimismen som inte slutade där.
Vann en bok för att ställa frågor
Backend-sektion
Jag lyckades närvara vid 2 rapporter - från Nikolay Sverchkov (Evil Martians), också om Serverless, och från Grigory Koshelev (Kontur-företaget) om telemetri.
Serverlös för bara dödliga
Om Ruslan Sirkin pratade om vad Serverless är, visade Nikolay enkla applikationer som använder Serverless, och pratade om detaljerna som påverkar kostnaden och hastigheten för applikationer i AWS Lambda.
En intressant detalj: det minsta betalda elementet är 128 Mb minne och 100 ms CPU, det kostar $0,000000208. Dessutom är 1 miljon sådana förfrågningar per månad gratis.
Vissa av Nikolais funktioner överskred ofta gränsen på 100 ms (huvudapplikationen skrevs i Ruby), så att skriva om dem i Go gav utmärkta besparingar.
Vostok Hercules — gör telemetri bra igen!
Den senaste rapporten från Backend-sektionen från Grigory Koshelev (Kontur-företaget) om telemetri. Telemetri betyder loggar, mätvärden, applikationsspår.
För detta ändamål använder Contour självskrivna verktyg som publicerats på Github. Verktyg från rapporten - Hercules, , används för att leverera telemetridata.
Vladimir Lilas rapport i avsnittet Devops diskuterade lagring och bearbetning av loggar i Elasticsearch, men det finns fortfarande uppgiften att leverera loggar från många tusen enheter och applikationer, och verktyg som Vostok Hercules löser dem.
Kretsen följde en väg känd för många - från RabbitMQ till Apache Kafka, men allt är inte så enkelt)) De var tvungna att lägga till Zookeeper, Cassandra och Graphite till kretsen. Jag kommer inte att avslöja informationen om denna rapport (inte min profil), om du är intresserad kan du vänta på bilderna och videorna på konferensens webbplats.
Hur är det jämfört med andra konferenser?
Jag kan inte jämföra det med konferenser i Moskva och St. Petersburg, jag kan jämföra det med andra evenemang i Ural och med 404fest i Samara.
DAMP hålls i 8 sektioner, detta är rekord för Uralkonferenser. Mycket stora Science and Management-sektioner, detta är också ovanligt. Publiken i Jekaterinburg är ganska strukturerad – staden har stora utvecklingsavdelningar för Yandex, Kontur, Tinkoff, och detta sätter sin prägel på rapporterna.
En annan intressant poäng är att många företag har 3-4 talare på konferensen på en gång (så var fallet med Kontur, Evil Martians, Tinkoff). Många av dem var sponsorer, men rapporterna är ganska i nivå med andra, det är inga reklamrapporter.
Att gå eller inte gå? Om du bor i Ural eller i närheten har du möjlighet och är intresserad av ämnena – ja, självklart. Om du funderar på en lång resa, skulle jag titta på ämnena för rapporter och videoreportage från tidigare år och fattade ett beslut.
En annan fördel med konferenser i regionerna är som regel att det är lätt att kommunicera med talaren efter rapporterna, det är helt enkelt färre sökande till sådan kommunikation.
Tack vare Dump och Ekaterinburg! )
Källa: will.com