La settimana scorsa sono andato alla conferenza IT DUMP (https://dump-ekb.ru/) a Ekaterinburg e voglio raccontare di cosa si è parlato nelle sezioni Backend e Devops, e se vale la pena prestare attenzione alle conferenze IT regionali.
Nikolay Sverchkov di Evil Martians su Serverless
Che cosa è successo lì?
Alla conferenza ci sono state in totale 8 sezioni: Backend, Frontend, Mobile, Testing e QA, Devops, Design, Science e Management.
Le sale più grandi, tra l'altro, erano quelle di Science e Management, con circa 350 posti ciascuna. Backend e Frontend non erano molto più piccoli. La sala Devops era la più piccola, ma molto attiva.
Ho ascoltato le relazioni nelle sezioni Devops e Backend e ho interagito un po' con i relatori. Voglio raccontare degli argomenti trattati e fare una panoramica su queste sezioni della conferenza.
Nelle sezioni Devops e Backend hanno parlato rappresentanti di SKB Kontur, DataArt, Evil Martians, della web agency di Ekaterinburg Flag, e di Miro (ex RealTimeBoard). Gli argomenti riguardavano CI/CD, il lavoro con i servizi di coda, la registrazione, e sono stati trattati bene i temi del Serverless e del lavoro con PostgreSQL in Go.
Ci sono state anche relazioni di Avito, Tinkoff, Yandex, Jetstyle, Megafon, e della banca Ak Bars, ma non sono riuscito a partecipare fisicamente a queste (i video e le slide delle relazioni non sono ancora disponibili, promettono di caricarli entro 2 settimane su dump-ekb.ru).
Sezione Devops
Ciò che sorprende è che la sezione si è svolta nella sala più piccola, con circa 50 posti. Le persone stavano anche in piedi nei corridoi 🙂 Racconterò delle relazioni che sono riuscito ad ascoltare.
Elasticsearch di un petabyte
La sezione è iniziata con la relazione di Vladimir Lila (SKB Kontur) su Elasticsearch in Kontur. Hanno un Elasticsearch piuttosto grande e carico (~800 TB di dati, ~1.3 petabyte includendo la ridondanza). Elasticsearch per tutti i servizi di Kontur è unico, composto da 2 cluster (di 7 e 9 server), ed è così importante che in Kontur c'è un ingegnere dedicato a Elasticsearch (proprio Vladimir).
Vladimir ha anche condiviso i suoi pensieri sui benefici di Elasticsearch e sui problemi che comporta.
Benefici:
- Tutti i log in un unico posto, facile accesso a essi
- Conservazione dei log per un anno e analisi facile
- Alta velocità di lavoro con i log
- Ottima visualizzazione dei dati 'out of the box'
Problemi:
- broker di messaggi – must have (per Kontur questo ruolo è ricoperto da Kafka)
- particolarità del lavoro con Elasticsearch Curator (carico regolare elevato dovuto ai compiti programmati in Curator)
- non c'è autenticazione integrata (solo per denaro separato, piuttosto considerevole, o come plugin open source di vario grado di prontezza per la produzione)
Le recensioni su Open Distro for Elasticsearch sono state esclusivamente positive 🙂 La stessa questione dell'autenticazione è stata risolta lì.
Da dove viene il petabyte?I loro nodi sono costituiti da server con 12*8 Tb SATA + 2*2 Tb SSD. Lo storage a freddo è su SATA, SSD solo per la cache calda (hot storage).
7+9 server, (7 + 9) * 12 * 8 = 1536 Tb.
Parte dello spazio è riservato, destinato a ridondanza e simili.
In Elasticsearch vengono inviati i log di circa 90 applicazioni, tra cui tutti i servizi di reportistica di Kontur, Elba e altri.
Caratteristiche dello sviluppo in Serverless
Di seguito la presentazione di Ruslan Serkin di DataArt su Serverless.
Ruslan ha parlato di cosa significhi sviluppare con un approccio Serverless e quali siano le sue peculiarità.
Serverless è un approccio allo sviluppo in cui gli sviluppatori non toccano affatto l'infrastruttura. Esempio: AWS Lambda Serverless, Kubeless.io (Serverless all'interno di Kubernetes), Google Cloud Functions.
Un'applicazione Serverless ideale è semplicemente una funzione che invia una richiesta al fornitore Serverless tramite un apposito API Gateway. È un microservizio ideale, mentre in AWS Lambda è supportato un ampio numero di linguaggi di programmazione moderni. Il costo di supporto e distribuzione dell'infrastruttura diventa nullo nel caso di fornitori cloud, il supporto per piccole applicazioni sarà comunque molto economico (AWS Lambda — 0,2$ per 1 milione di richieste semplici).
La scalabilità di tale sistema è praticamente perfetta: il fornitore cloud se ne occupa autonomamente, Kubeless si scalda automaticamente all'interno del cluster Kubernetes.
Ci sono degli svantaggi:
- lo sviluppo di grandi applicazioni diventa più complesso
- c'è complessità nella profilazione delle applicazioni (hai solo accesso ai log, ma non alla profilazione nel senso tradizionale)
- non c'è versioning
Dico la verità, ho sentito parlare di Serverless alcuni anni fa, ma per tutti questi anni non mi è stato chiaro come applicarlo correttamente. Dopo la presentazione di Ruslan, la mia comprensione è migliorata e, dopo la presentazione di Nikolay Sverchkov (Evil Martians) nella sezione Backend, si è consolidata. Già non è stato invano partecipare alla conferenza 🙂
CI per poveri, o vale la pena scrivere il proprio CI per uno studio web
Mikhail Radionov, responsabile dello studio web Flag di Ekaterinburg, ha parlato di un CI/CD personalizzato.
Il suo studio ha fatto il percorso da “CI/CD manuale” (accesso al server via SSH, esecuzione di git pull, ripetere 100 volte al giorno) a Jenkins e a uno strumento personalizzato che consente di controllare il codice e di eseguire rilasci chiamato Pullkins.
Perché Jenkins non ha soddisfatto? Non offriva abbastanza flessibilità di default ed era troppo complicato da personalizzare.
Il “Flag” è sviluppato su Laravel (framework PHP). Durante lo sviluppo del server CI/CD, Mikhail e i suoi colleghi hanno utilizzato i meccanismi integrati di Laravel chiamati Telescope ed Envoy. Ne è risultato un server in PHP (notate bene) che gestisce richieste webhook in entrata, esegue build del frontend e del backend, distribuisce su diversi server e comunica su Slack.
In seguito, per poter eseguire il deploy blue/green e avere impostazioni uniformi negli ambienti dev-stage-prod, sono passati a Docker. I vantaggi sono rimasti gli stessi, ma si sono aggiunte possibilità di omogeneizzazione dell'ambiente e distribuzione senza soluzione di continuità, oltre alla necessità di studiare Docker per poter lavorare correttamente con esso.
Come abbiamo ridotto il numero di rollback delle versioni server del 99%
L'ultimo intervento nella sezione DevOps è stato di Viktor Yeremchenko, Lead DevOps Engineer presso Miro.com (ex RealTimeBoard).
Alla base di RealTimeBoard, il principale prodotto del team Miro, c'è un'applicazione monolitica in Java. Compilare, testare e distribuire senza downtime è una sfida complessa. È importante eseguire il deploy di una versione del codice che non debba essere ripristinata (d'altronde si tratta di un pesante monolite).
Sulla strada per costruire un sistema che consenta di farlo, Miro ha seguito un percorso che ha incluso il lavoro sull'architettura, sugli strumenti utilizzati (Atlassian Bamboo, Ansible, ecc.) e sulla formazione dei team (hanno attualmente un team DevOps dedicato e molti team Scrum separati di sviluppatori di vari profili).
Il percorso si è rivelato difficile e tortuoso, e Viktor ha condiviso il dolore accumulato e l'ottimismo che non è svanito.
Ho vinto un libro per le domande
Sezione Backend
Sono riuscito ad assistere a 2 interventi: quello di Nikolai Sверчков (Evil Martians), ancora su Serverless, e quello di Grigory Koshelev (azienda Kontur) sulla telemetria.
Serverless per i comuni mortali
Se Ruslan Sirkin parlava di cosa sia Serverless, Nikolai ha mostrato applicazioni semplici utilizzando Serverless e ha parlato dei dettagli che influenzano il costo e la velocità delle applicazioni in AWS Lambda.
Un dettaglio interessante: il minimo elemento pagato è composto da 128 Mb di memoria e 100 ms di CPU, con un costo di 0,000000208$. Inoltre, 1 milione di tali richieste al mese è gratuito.
Alcune funzioni di Nikolai spesso superavano il limite di 100 ms (l'applicazione principale era scritta in Ruby), quindi la riscrittura in Go ha portato a un'ottima economia.
Vostok Hercules — fa tornare grande la telemetria!
L'ultimo intervento della sezione Backend di Grigori Koshelev (azienda Kontur) sulla telemetria. La telemetria consiste in log, metriche e tracciamenti delle applicazioni.
Kontur utilizza strumenti scritti a mano, pubblicati su Github. Lo strumento presentato è Hercules, , utilizzato per la consegna dei dati di telemetria.
Nell'intervento di Vladimir Lila nella sezione Devops, è stato esaminato lo storage e l'elaborazione dei log in Elasticsearch, ma c'è anche la questione di consegnare i log da migliaia di dispositivi e applicazioni, e questo è risolto con strumenti come Vostok Hercules.
Kontur ha seguito un percorso noto a molti — da RabbitMQ a Apache Kafka, ma non è tutto così semplice. Hanno dovuto aggiungere nello schema Zookeeper, Cassandra e Graphite. Non svelerò completamente le informazioni su questo intervento (non è il mio profilo), se siete interessati — puoi attendere le slide e il video sul sito della conferenza.
Com'è rispetto ad altre conferenze?
Non posso paragonarla alle conferenze di Mosca e San Pietroburgo, posso confrontarla con altri eventi negli Urali e con il 404fest a Samara.
Il DAMP si svolge in 8 sezioni, un record per le conferenze urali. Le sezioni Science e Management sono molto grandi, anche questo è insolito. Il pubblico a Ekaterinburg è abbastanza strutturato: nella città ci sono grandi reparti di sviluppo di Yandex, Kontur, Tinkoff, e questo influisce anche sulle presentazioni.
Un altro punto interessante è che molte aziende hanno 3–4 relatori alla conferenza (è successo a Kontur, Evil Martians, Tinkoff). Molti di loro erano sponsor, ma le presentazioni sono comunque di buon livello, non sono colloqui promozionali.
Andare o non andare? Se vivi negli Urali o nelle vicinanze, hai l'opportunità e i temi ti interessano — sì, certo. Se pensi di un viaggio più lungo — darei un'occhiata ai temi delle presentazioni e ai video degli anni passati. e prendere una decisione.
Un altro vantaggio delle conferenze nelle regioni è che di solito è facile parlare con il relatore dopo le presentazioni, ci sono semplicemente meno candidati per questa interazione.
Grazie a DAMP e a Ekaterinburg! )
Fonte: habr.com
