Săptămâna trecută am fost la conferința DUMP IT (https://dump-ekb.ru/) din Ekaterinburg și vreau să vă spun despre ce s-a discutat în secțiunile Backend și Devops și dacă conferințele IT regionale merită atenție.
Nikolay Sverchkov de la Evil Martians despre Serverless
Oricum ce era acolo?
În total, conferința a avut 8 secțiuni: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Cele mai mari săli, apropo, sunt la Science and Management)) Pentru ~350 de persoane fiecare. Backend și Frontend nu sunt mult mai mici. Sala Devops era cea mai mică, dar activă.
Am ascultat rapoartele din secțiunile Devops și Backend și am vorbit puțin cu vorbitorii. Aș dori să vorbesc despre subiectele abordate și să revizuiesc aceste secțiuni în cadrul conferinței.
Reprezentanții SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) au vorbit în secțiunile Devops și Backend. Au fost bine acoperite subiectele CI/CD, lucrul cu serviciile de coadă, înregistrarea subiectelor fără server și lucrul cu PostgreSQL în Go.
Au existat și rapoarte de la Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, dar nu am avut timp să le asist fizic (înregistrările video și diapozitivele rapoartelor nu sunt încă disponibile, promit să le posteze pe dump- ekb.ru în termen de 2 săptămâni).
Secțiunea Devops
Ceea ce a fost surprinzător a fost că secția s-a desfășurat în cea mai mică sală, aproximativ 50 de locuri. Oamenii stăteau chiar pe culoar :) Vă spun despre reportajele pe care am reușit să le ascult.
Elastic cântărind un petabyte
Secțiunea a început cu un raport al lui Vladimir Lil (SKB-Kontur) despre Elasticsearch în Kontur. Au un Elastic destul de mare și încărcat (~800 TB de date, ~1.3 petaocteți ținând cont de redundanță). Elasticsearch pentru toate serviciile Kontur este unic, este format din 2 clustere (din 7 și 9 servere) și este atât de important încât Kontur are un inginer special Elasticsearch (de fapt, Vladimir însuși).
Vladimir și-a împărtășit gândurile despre beneficiile Elasticsearch și problemele pe care le aduce.
beneficii:
- Toate jurnalele sunt într-un singur loc, acces ușor la ele
- Stocarea jurnalelor timp de un an și analizarea cu ușurință a acestora
- Viteză mare de lucru cu bușteni
- Vizualizare excelentă a datelor din cutie
Probleme:
- brokerul de mesaje este obligatoriu (pentru Kontur rolul său este jucat de Kafka)
- caracteristici de lucru cu Elasticsearch Curator (încărcare mare creată periodic din sarcinile obișnuite în Curator)
- fără autorizare încorporată (doar pentru bani separati, destul de mari sau ca pluginuri open source cu diferite grade de pregătire pentru producție)
Au existat doar recenzii pozitive despre Open Distro pentru Elasticsearch :) Aceeași problemă de autorizare a fost rezolvată acolo.
De unde provine petabyte?Nodurile lor constau din servere cu 12*8 Tb SATA + 2*2 Tb SSD. Stocare la rece pe SATA, SSD numai pentru cache la cald (stocare la cald).
7+9 servere, (7 + 9) * 12 * 8 = 1536 Tb.
O parte din spațiu este în rezervă, rezervată pentru redundanță etc.
Jurnalele de la aproximativ 90 de aplicații sunt trimise către Elasticsearch, inclusiv toate serviciile de raportare ale Kontur, Elba etc.
Caracteristici de dezvoltare pe Serverless
Urmează un raport al lui Ruslan Serkin de la DataArt despre Serverless.
Ruslan a vorbit despre ce este dezvoltarea cu abordarea Serverless în general și care sunt caracteristicile acesteia.
Serverless este o abordare a dezvoltării în care dezvoltatorii nu ating infrastructura în niciun fel. Exemplu - AWS Lambda Serverless, Kubeless.io (Fără server în interiorul Kubernetes), Google Cloud Functions.
O aplicație fără server ideală este pur și simplu o funcție care trimite o solicitare către un furnizor fără server printr-un gateway API special. Un microserviciu ideal, în timp ce AWS Lambda acceptă și un număr mare de limbaje de programare moderne. Costul de întreținere și implementare a infrastructurii devine zero în cazul furnizorilor de cloud, suportarea aplicațiilor mici va fi și foarte ieftină (AWS Lambda - 0.2 USD / 1 milion de cereri simple).
Scalabilitatea unui astfel de sistem este aproape ideală - furnizorul de cloud se ocupă singur de acest lucru, Kubeless scalează automat în clusterul Kubernetes.
Există dezavantaje:
- dezvoltarea de aplicații mari devine din ce în ce mai dificilă
- există dificultăți cu aplicațiile de profilare (doar jurnalele sunt disponibile pentru dvs., dar nu profilarea în sensul obișnuit)
- fără versiuni
Sincer să fiu, am auzit de Serverless în urmă cu câțiva ani, dar în toți acești ani nu mi-a fost clar cum să-l folosesc corect. După raportul lui Ruslan, a apărut înțelegerea, iar după raportul lui Nikolai Sverchkov (Marțienii răi) din secțiunea Backend, s-a consolidat. Nu degeaba am fost la conferinta :)
CI este pentru săraci sau merită să-ți scrii propriul CI pentru un studio web?
Mikhail Radionov, șeful studioului web Flag din Ekaterinburg, a vorbit despre CI/CD auto-scris.
Studioul său a trecut de la „manual CI/CD” (conectați-vă la server prin SSH, faceți un git pull, repetați de 100 de ori pe zi) la Jenkins și la un instrument auto-scris care vă permite să monitorizați codul și să efectuați lansări numite Pullkins .
De ce nu a lucrat Jenkins? Nu a oferit suficientă flexibilitate în mod implicit și a fost prea dificil de personalizat.
„Flag” se dezvoltă în Laravel (cadru PHP). Când au dezvoltat un server CI/CD, Mikhail și colegii săi au folosit mecanismele încorporate ale lui Laravel numite Telescope and Envoy. Rezultatul este un server în PHP (vă rugăm să rețineți) care procesează cererile webhook primite, poate construi front-end și backend, poate implementa pe diferite servere și poate raporta la Slack.
Apoi, pentru a putea realiza implementarea albastru/verde și pentru a avea setări uniforme în mediile dev-stage-prod, au trecut la Docker. Avantajele au rămas aceleași, s-au adăugat posibilitățile de omogenizare a mediului și de desfășurare fără întreruperi și s-a adăugat nevoia de a învăța Docker să lucreze corect cu el.
Cum am redus cu 99% numărul de retrocedări ale lansărilor de server
Ultimul raport din secțiunea Devops a fost de la Viktor Eremchenko, inginer principal devops la Miro.com (fost RealTimeBoard).
RealTimeBoard, produsul emblematic al echipei Miro, se bazează pe o aplicație Java monolitică. Colectarea, testarea și implementarea acestuia fără timp de nefuncționare este o sarcină dificilă. În acest caz, este important să implementați o astfel de versiune a codului, astfel încât să nu fie necesară derularea înapoi (este un monolit greu).
Pe drumul spre construirea unui sistem care să-ți permită acest lucru, Miro a parcurs o cale care a inclus lucrul la arhitectură, instrumentele folosite (Atlassian Bamboo, Ansible etc.) și lucrul la structura echipelor (au acum o echipă Devops dedicată + multe echipe Scrum separate de la dezvoltatori de profiluri diferite).
Drumul s-a dovedit a fi dificil și spinos, iar Victor a împărtășit durerea și optimismul acumulat care nu s-au terminat aici.
A câștigat o carte pentru a pune întrebări
Secțiunea de backend
Am reușit să particip la 2 reportaje - de la Nikolay Sverchkov (Evil Martians), tot despre Serverless, și de la Grigory Koshelev (compania Kontur) despre telemetrie.
Fără server pentru simplii muritori
Dacă Ruslan Sirkin a vorbit despre ce este Serverless, Nikolay a arătat aplicații simple care folosesc Serverless și a vorbit despre detaliile care afectează costul și viteza aplicațiilor în AWS Lambda.
Un detaliu interesant: elementul minim plătit este de 128 Mb de memorie și 100 ms CPU, costă 0,000000208 USD. Mai mult, 1 milion de astfel de solicitări pe lună sunt gratuite.
Unele dintre funcțiile lui Nikolai au depășit adesea limita de 100 ms (aplicația principală a fost scrisă în Ruby), așa că rescrierea lor în Go a oferit economii excelente.
Vostok Hercules — face telemetria excelentă din nou!
Cel mai recent raport al secțiunii Backend de la Grigory Koshelev (compania Kontur) despre telemetrie. Telemetria înseamnă jurnalele, valorile, urmele aplicației.
În acest scop, Contour folosește instrumente auto-scrise postate pe Github. Instrument din raport - Hercules, , este folosit pentru a furniza date de telemetrie.
Raportul lui Vladimir Lila din secțiunea Devops a discutat despre stocarea și procesarea jurnalelor în Elasticsearch, dar există încă sarcina de a livra jurnale de la multe mii de dispozitive și aplicații, iar instrumente precum Vostok Hercules le rezolvă.
Circuitul a urmat o cale cunoscută de mulți - de la RabbitMQ la Apache Kafka, dar nu totul este atât de simplu)) Au trebuit să adauge în circuit Zookeeper, Cassandra și Graphite. Nu voi dezvălui pe deplin informațiile din acest raport (nu profilul meu), dacă sunteți interesat, puteți aștepta slide-urile și videoclipurile pe site-ul conferinței.
Cum se compară cu alte conferințe?
Nu îl pot compara cu conferințele de la Moscova și Sankt Petersburg, îl pot compara cu alte evenimente din Urali și cu 404fest din Samara.
DAMP se desfășoară în 8 secțiuni, acesta este un record pentru conferințele din Ural. Secțiuni foarte mari de Știință și Management, acest lucru este, de asemenea, neobișnuit. Publicul din Ekaterinburg este destul de structurat - orașul are departamente mari de dezvoltare pentru Yandex, Kontur, Tinkoff, iar acest lucru își lasă amprenta pe rapoarte.
Un alt punct interesant este că multe companii au 3-4 vorbitori la conferință deodată (a fost cazul Kontur, Evil Martians, Tinkoff). Mulți dintre ei au fost sponsori, dar reportajele sunt destul de la egalitate cu altele, acestea nu sunt reportaje publicitare.
A merge sau a nu merge? Dacă locuiți în Urali sau în apropiere, aveți ocazia și sunteți interesat de subiecte - da, desigur. Dacă te gândești la o călătorie lungă, m-aș uita la subiectele reportajelor și reportajelor video din anii precedenți și a luat o decizie.
Un alt avantaj al conferințelor din regiuni, de regulă, este că este ușor să comunicați cu vorbitorul după rapoarte, pur și simplu sunt mai puțini solicitanți pentru o astfel de comunicare.
Mulțumim lui Dump și Ekaterinburg! )
Sursa: www.habr.com
