Săptămâna trecută am participat la conferința IT DUMP (https://dump-ekb.ru/) din Ekaterinburg și vreau să vă povestesc despre ce s-a discutat în secțiunile Backend și DevOps, și dacă merită atenția conferințele regionale IT.
Nikolai Svirchkov de la Evil Martians despre Serverless
Ce s-a întâmplat acolo de fapt?
La conferință au fost 8 secțiuni: Backend, Frontend, Mobile, Testare și QA, DevOps, Design, Știință și Management.
Cele mai mari săli, de altfel, erau de la Știință și Management )) Fiecare cu ~350 de locuri. Backend și Frontend erau puțin mai mici. Sala de DevOps a fost cea mai mică, dar activă.
Am ascultat prezentări în secțiunile DevOps și Backend și am discutat puțin cu vorbitorii. Vreau să vă povestesc despre temele abordate și să fac o recenzie a acestor secțiuni la conferință.
În secțiunile DevOps și Backend au vorbit reprezentanți de la SKB-Kontur, DataArt, Evil Martians, studioul web din Ekaterinburg Flag, Miro (RealTimeBoard). Temele au abordat CI/CD, lucrul cu servicii de cozi, logare, au fost bine discutate temele Serverless și lucrul cu PostgreSQL în Go.
De asemenea, au fost prezentări de la Avito, Tinkoff, Yandex, Jetstyle, MegaFon, banca Ak Bars, dar nu am reușit să le vizionez în persoană (înregistrările video și diapozitivele prezentărilor nu sunt încă disponibile, promite să fie postate în termen de 2 săptămâni pe dump-ekb.ru).
Secțiunea DevOps
Ce m-a uimit — secțiunea s-a desfășurat în cea mai mică sală, cu aproximativ 50 de locuri. Oamenii stăteau chiar și în pasaje 🙂 Voi povesti despre prezentările pe care am reușit să le ascult.
Elastic cu greutatea de un petabyte
Secțiunea a început cu prezentarea lui Vladimir Lila (SKB-Kontur) despre Elasticsearch la Contur. Au un Elastic destul de mare și solicitat (~800 TB de date, ~1.3 petabytes având în vedere redundanța). Elasticsearch pentru toate serviciile Contur este unic, constând din 2 clustere (de 7 și 9 servere), și este atât de important încât în Contur există un inginer specializat în Elasticsearch (de fapt, Vladimir însuși).
Vladimir a împărtășit, de asemenea, gânduri despre utilitatea Elasticsearch și problemele pe care le generează.
Utilitate:
- Toate jurnalizările într-un singur loc, acces ușor la ele
- Stocarea jurnalizărilor timp de un an și analiza lor ușoară
- Viteza mare de lucru cu jurnalizările
- Vizualizare excelentă a datelor "din cutie"
Probleme:
- broker de mesaje — must have (în Contur, Kafka îndeplinește acest rol)
- particularitățile lucrului cu Elasticsearch Curator (încărcare mare periodică din sarcinile regulate în Curator)
- nu există autorizare încorporată (doar pentru bani destul de mulți, sau ca pluginuri open-source de diferite grade de pregătire pentru producție)
Despre Open Distro for Elasticsearch, recenziile au fost doar pozitive 🙂 Aceleași probleme de autentificare sunt rezolvate acolo.
De unde provine petabyte-ul?Nodurile lor constau din servere cu 12*8 Tb SATA + 2*2 Tb SSD. Stocare la rece pe SATA, SSD doar pentru cache-ul cald (hot storage).
7+9 servere, (7 + 9) * 12 * 8 = 1536 Tb.
O parte din spațiu este rezervat, alocat pentru redundanță și altele.
În Elasticsearch sunt trimise jurnalele a aproximativ 90 de aplicații, inclusiv toate serviciile de raportare ale Contur, Elba și altele.
Particularitățile dezvoltării pe Serverless
Următoarea prezentare este a lui Ruslan Serkin de la DataArt despre Serverless.
Ruslan a vorbit despre ce înseamnă dezvoltarea cu abordarea Serverless și care sunt caracteristicile acesteia.
Serverless este o abordare de dezvoltare în care dezvoltatorii nu se ocupă deloc de infrastructură. Un exemplu este AWS Lambda Serverless, Kubeless.io (Serverless în interiorul Kubernetes), Google Cloud Functions.
Aplicația Serverless ideală este pur și simplu o funcție care trimite o cerere furnizorului Serverless printr-un Gateway API special. Un microserviciu ideal, în același timp AWS Lambda suportă un număr mare de limbaje moderne de programare. Costul de susținere și desfășurare a infrastructurii devine zero în cazul furnizorilor de cloud, iar susținerea aplicațiilor mici va fi de asemenea foarte ieftină (AWS Lambda — 0.2$ / 1 milion cereri simple).
Scalabilitatea unui astfel de sistem este practic ideală — furnizorul de cloud se ocupă de aceasta, Kubeless scalează automat în interiorul clusterului Kubernetes.
Există dezavantaje:
- dezvoltarea aplicațiilor mari devine mai complicată.
- există dificultăți în profilarea aplicațiilor (aveți acces doar la jurnale, nu și la profilare în sensul obișnuit).
- nu există versiuni.
Voi fi sincer, despre Serverless am auzit pentru prima dată acum câțiva ani, dar în toți acești ani nu am înțeles cum să-l aplic corect. După prezentarea lui Ruslan am înțeles, iar după prezentarea lui Nikolai Sverchkov (Evil Martians) din secțiunea Backend s-a consolidat. Nu am venit degeaba la conferință 🙂
CI pentru cei săraci, sau merită să scrii propriul CI pentru agenția de web
Mihail Radionov, directorul agenției de web Flag din Ekaterinburg, a vorbit despre CI/CD personalizat.
Agenția sa a trecut de la „CI/CD manual” (s-a conectat la server prin SSH, a făcut git pull, repetă de 100 de ori pe zi) la Jenkins și la un instrument personalizat, care permite controlul codului și desfășurarea denumit Pullkins.
De ce Jenkins nu a fost satisfăcător? Nu oferea suficientă flexibilitate din start și era prea complicat în personalizare.
„Flag” dezvoltă pe Laravel (cadru PHP). Când a dezvoltat serverul CI/CD, Mihail și colegii săi au folosit mecanismele încorporate ale Laravel numite Telescope și Envoy. Ca rezultat, a rezultat un server PHP (observați) care procesează cereri webhook incoming, poate efectua construcții pentru frontend, backend, desfășura pe diferite servere și raporta în Slack.
Ulterior, pentru a putea efectua desfășurări blue/green și pentru a avea setări uniforme în medii dev-stage-prod, au trecut la Docker. Avantajele au rămas aceleași, iar acum au apărut posibilități de omogenizare a mediului și desfășurare fără întreruperi, precum și necesitatea de a studia Docker pentru a lucra corect cu acesta.
Cum am redus numărul de rollback-uri de versiuni server pe 99%
Ultimul raport din secțiunea Devops a fost de la Viktor Eremcenko, lead devops engineer la Miro.com (fost RealTimeBoard).
La baza RealTimeBoard, produsul principal al echipei Miro, se află o aplicație monolitică pe Java. A o construi, testa și desfășura fără downtime este o sarcină dificilă. Este important să desfășori o versiune de cod care să nu necesite rollback (fiind un monolit greu).
Pe drumul către construirea unui sistem care permite acest lucru, Miro a parcurs un traseu care includea lucrul la arhitectură, instrumentele folosite (Atlassian Bamboo, Ansible etc.) și construirea echipelor (acum au o echipă Devops dedicată + multe echipe Scrum separate din dezvoltatori de diferite profiluri).
Calea s-a dovedit a fi dificilă și plină de obstacole, iar Viktor a împărtășit durerea acumulată și optimismul care nu a dispărut.
Am câștigat o carte pentru întrebări
Secțiunea Backend
Am reușit să ajung la 2 prezentări — de la Nikolai Sverchkov (Evil Martians), de asemenea despre Serverless, și de la Grigori Koșolev (compania Kontur) despre telemetrie.
Serverless pentru muritorii de rând
Dacă Ruslan Sirkin a vorbit despre ce este Serverless, Nikolai a arătat aplicații simple folosind Serverless și a discutat despre detaliile care influențează costul și viteza de lucru a aplicațiilor în AWS Lambda.
Un detaliu interesant: elementul minim plătit este de 128 Mb memorie și 100 ms CPU, costă 0,000000208$. Totuși, 1 milion de asemenea cereri pe lună este gratuit.
Anumite funcții ale lui Nikolai depășeau adesea limita de 100 ms (aplicația principală a fost scrisă în Ruby), așa că rescrierea lor în Go a adus economii excelente.
Vostok Hercules — să facem telemetria grozavă din nou!
Ultimul raport al secțiunii Backend de la Grigori Koșeleva (compania Kontur) despre telemetrie. Telemetria include jurnale, metrici și trasabilitatea aplicațiilor.
Kontur folosește pentru aceasta instrumente scrise manual, disponibile pe Github. Instrumentul din raport — Hercules, , este utilizat pentru livrarea datelor de telemetrie.
În raportul lui Vladimir Lila din secțiunea DevOps a fost discutată stocarea și procesarea jurnalele în Elasticsearch, dar mai există și problema livrării jurnalele de la mii de dispozitive și aplicații, iar aceste instrumente ca Vostok Hercules le rezolvă.
Kontur a parcurs calea cunoscută pentru mulți — de la RabbitMQ la Apache Kafka, dar nu a fost atât de simplu )) Au fost nevoiți să adauge în schemă Zookeeper, Cassandra și Graphite. Informațiile din acest raport nu le voi detalia complet (nu este profilul meu), dacă ești interesat — poți aștepta slide-urile și videoclipul pe site-ul conferinței.
Cum ar fi în comparație cu alte conferințe?
Nu pot compara cu conferințele din Moscova și Sankt Petersburg, dar pot compara cu alte evenimente din Ural și cu 404fest din Samara.
DUMP se desfășoară în 8 secțiuni, un record pentru conferințele din Ural. Secțiunile Science și Management sunt foarte mari, ceea ce este neobișnuit. Publicul din Ekaterinburg este destul de structurat — în oraș există mari departamente de dezvoltare de la Yandex, Kontur, Tinkoff, ceea ce influențează și prezentările.
Un alt aspect interesant — multe companii au imediat 3–4 prezentatori la conferință (așa a fost la Kontur, Evil Martians, Tinkoff). Mulți dintre ei au fost sponsori, dar prezentările au fost la un nivel similar cu altele, nu sunt prezentări publicitare.
Să mergi sau nu? Dacă locuiești în Ural sau în apropiere, ai ocazia și temele sunt interesante — da, cu siguranță. Dacă te gândești la o călătorie mai lungă — aș verifica temele prezentărilor și videoclipurile din anii anteriori și aș lua o decizie.
Un alt avantaj al conferințelor regionale, de obicei — este ușor să discuți cu vorbitorii după prezentări, pur și simplu pentru că sunt mai puțini candidați pentru o astfel de discuție.
Mulțumesc DUMP și Ekaterinburgului! )
Sursa: habr.com
