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 valga la pena partecipare a conferenze IT regionali.
Nikolai Sverchkov di Evil Martians su Serverless
Cosa è successo lì?
In totale c'erano 8 sezioni alla conferenza: Backend, Frontend, Mobile, Test e QA, Devops, Design, Scienza e Management.
Le sale più grandi, peraltro, erano per Scienza e Management, ognuna con circa 350 posti. Backend e Frontend erano solo leggermente più piccole. La sala Devops era la più piccola, ma molto attiva.
Ho seguito delle relazioni nelle sezioni Devops e Backend e ho parlato un po' con i relatori. Voglio raccontare le tematiche trattate e fare una panoramica di queste sezioni alla conferenza.
Nelle sezioni Devops e Backend hanno partecipato rappresentanti di SKB Kontur, DataArt, Evil Martians, della web studio di Ekaterinburg Flag, e Miro (RealTimeBoard). Le tematiche includevano CI/CD, gestione dei servizi di code queue, logging, oltre ai temi di Serverless e lavoro con PostgreSQL in Go.
Ci sono stati anche i relatori di Avito, Tinkoff, Yandex, Jetstyle, Megafon, della banca Ak Bars, ma non ho potuto partecipare fisicamente (le registrazioni video e le slide non sono ancora disponibili, promettono di pubblicarle entro 2 settimane su dump-ekb.ru).
Sezione Devops
Ciò che sorprende è che la sezione si è tenuta nella sala più piccola, con circa 50 posti. Le persone stavano in piedi anche nei corridoi 🙂 Racconterò delle relazioni che sono riuscito a seguire.
Un Elasticsearch da 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 considerando 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 ad Elasticsearch (proprio Vladimir).
Vladimir ha inoltre condiviso riflessioni sui benefici di Elasticsearch e i problemi che comporta.
Benefici:
- Tutti i log in un unico posto, accesso facile a essi
- Conservazione dei log per un anno e facile analisi
- Alta velocità di accesso ai log
- Ottima visualizzazione dei dati “out of the box”
Problemi:
- messaging broker - un must (in Kontur, questo compito è svolto da Kafka)
- caratteristiche di lavoro con Elasticsearch Curator (carico elevato periodico causato da attività regolari in Curator)
- assenza di autenticazione integrata (solo a pagamento, piuttosto elevato, o come plugin open-source di varia prontezza alla produzione)
Le recensioni su Open Distro for Elasticsearch erano solo positive 🙂 Anche il problema dell'autenticazione è stato risolto lì.
Da dove arriva il petabyte?Le loro nodi consistono in server con 12*8 TB SATA + 2*2 TB SSD. Cold storage su SATA, SSD solo per caching caldo (hot storage).
7+9 server, (7 + 9) * 12 * 8 = 1536 TB.
Una parte dello spazio è riservata, calcolata per la ridondanza, e così via.
In Elasticsearch vengono inviati i log di circa 90 applicazioni, inclusi tutti i servizi di report di Kontur, Elba e altri.
Caratteristiche dello sviluppo su Serverless
Poi la relazione di Ruslan Serkin di DataArt su Serverless.
Ruslan ha parlato di cosa significhi sviluppare con un approccio Serverless e quali siano le sue caratteristiche.
Serverless è un approccio allo sviluppo in cui gli sviluppatori non si occupano affatto dell'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'API Gateway speciale. Un microservizio ideale, e in AWS Lambda supporta un gran numero di linguaggi di programmazione moderni. Il costo di supporto e distribuzione dell'infrastruttura diventa nullo nel caso di fornitori di servizi cloud, e il supporto per piccole applicazioni sarà anche molto economico (AWS Lambda - 0.2$ / 1 milione di semplici richieste).
La scalabilità di un tale sistema è praticamente ideale - il fornitore di servizi cloud se ne occupa autonomamente, Kubeless si scala automaticamente all'interno del cluster Kubernetes.
Ci sono degli svantaggi:
- lo sviluppo di grandi applicazioni diventa più complesso
- c'è difficoltà nel profilo delle applicazioni (hai solo accesso ai log, ma non al profiling tradizionale)
- nessuna gestione delle versioni
Dico francamente, ho sentito parlare di Serverless diversi anni fa, ma per tutti questi anni non ho capito come applicarlo correttamente. Dopo la relazione di Ruslan, la comprensione è arrivata, e dopo la relazione di Nikolai Sverchkov (Evil Martians) dalla sezione Backend si è consolidata. Non sono andato alla conferenza per niente 🙂
CI per i poveri, o vale la pena scrivere il proprio CI per la web studio
Mikhail Radionov, il direttore della web studio Flag di Ekaterinburg, ha parlato del CI/CD personalizzato.
Il suo studio ha fatto il percorso dal 'CI/CD manuale' (sono entrato nel server tramite SSH, ho fatto git pull, ripetuto 100 volte al giorno) a Jenkins e a uno strumento personalizzato che consente di controllare il codice e svolgere le release chiamato Pullkins.
Perché Jenkins non ha funzionato? Non offriva abbastanza flessibilità di default ed era troppo complesso da personalizzare.
“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. Così è stato realizzato un server in PHP (si noti) in grado di gestire le richieste webhook in arrivo, eseguire il build del frontend e del backend, effettuare il deployment su diversi server e riportare le informazioni su Slack.
In seguito, per poter effettuare il blue/green deploy e avere impostazioni uniformi negli ambienti dev-stage-prod, sono passati a Docker. I vantaggi sono rimasti gli stessi, sono state aggiunte possibilità di omogeneizzazione dell'ambiente e di deployment senza soluzione di continuità, e si è aggiunta la necessità di studiare Docker per lavorarci correttamente.
Come abbiamo ridotto del 99% il numero di rollback dei rilasci server
L'ultimo intervento nella sezione Devops è stato tenuto da Viktor Yeremchenko, Lead devops engineer in Miro.com (ex RealTimeBoard).
Alla base di RealTimeBoard, prodotto principale del team Miro, c'è un'applicazione monolitica in Java. Assemblare, testare e distribuire senza downtime è una sfida complessa. È importante eseguire il deploy di una versione del codice in modo tale da non doverla ripristinare (è pur sempre un pesante monolite).
Nel percorso verso la costruzione di un sistema che permetta di fare ciò, Miro ha affrontato un cammino che ha incluso il lavoro sull'architettura, sugli strumenti utilizzati (Atlassian Bamboo, Ansible, ecc.) e sulla formazione delle squadre (attualmente hanno un team Devops dedicato e molte squadre Scrum separate di sviluppatori di vari profili).
Il percorso si è rivelato difficile e irto di ostacoli, e Viktor ha condiviso il dolore accumulato e un ottimismo mai concluso.
Ha vinto un libro per le domande
Sezione Backend
Sono riuscito a seguire 2 interventi — da Nikolai Sverchkov (Evil Martians), sempre su Serverless, e da Grigory Koshelev (azienda Kontur) sulla telemetria.
Serverless per i comuni mortali
Se Ruslan Sirkin parlava di cosa sia Serverless, Nikolai ha mostrato semplici applicazioni utilizzando Serverless e ha spiegato i dettagli che influenzano il costo e la velocità delle applicazioni in AWS Lambda.
Un dettaglio interessante: l'elemento minimo pagabile — 128 Mb di memoria e 100 ms di CPU, costa 0,000000208$. Inoltre, 1 milione di tali richieste al mese è gratuito.
Alcune funzioni di Nikolai spesso superavano il limite di 100 ms (l'app principale era scritta in Ruby), quindi riscriverle in Go ha portato a un'ottima economia.
Vostok Hercules — rendiamo grande la telemetria di nuovo!
L'ultimo intervento della sezione Backend è stato tenuto da Grigory Koshelev (azienda Kontur) sulla telemetria. La telemetria riguarda log, metriche, e tracciamenti delle applicazioni.
Kontur utilizza strumenti scritti a mano, pubblicati su Github. Lo strumento dell'intervento è Hercules, , utilizzato per la consegna dei dati di telemetria.
Nell'intervento di Vladimir Lila nella sezione Devops si trattava della memorizzazione e elaborazione dei log in Elasticsearch, ma c'è anche la sfida di consegnare i log da migliaia di dispositivi e applicazioni, e questi problemi vengono risolti con strumenti come Vostok Hercules.
Kontur ha seguito un percorso noto a molti — da RabbitMQ ad Apache Kafka, ma non è stato semplice )) Hanno dovuto aggiungere Zookeeper, Cassandra e Graphite nello schema. Non rivelerò tutte le informazioni su questo intervento (non è il mio profilo), se sei interessato, puoi aspettare le slide e i video sul sito della conferenza.
Com'è rispetto ad altre conferenze?
Non posso confrontarla con conferenze a Mosca e San Pietroburgo, posso paragonarla ad altri eventi negli Urali e al 404fest a Samara.
DAMP si svolge in 8 sezioni, un record per le conferenze urali. Le sezioni Science e Management sono molto grandi, il che è insolito. Il pubblico a Ekaterinburg è abbastanza strutturato — in città ci sono grandi dipartimenti di sviluppo come Yandex, Kontur, Tinkoff, il che ha un impatto anche sugli interventi.
Un altro punto interessante è che molte aziende hanno immediatamente 3-4 relatori alla conferenza (è successo con Kontur, Evil Martians, Tinkoff). Molti di loro erano sponsor, ma gli interventi erano di livello adeguato rispetto agli altri, non erano relazioni promozionali.
Andare o non andare? Se vivi negli Urali o nei dintorni, hai la possibilità e le tematiche ti interessano — sì, certamente. Se stai pensando a un viaggio più lungo — darei un'occhiata ai temi degli interventi e ai video delle edizioni passate e prendere una decisione.
Un altro vantaggio delle conferenze nelle regioni è che generalmente è facile parlare con i relatori dopo gli interventi, ci sono semplicemente meno candidati per questo tipo di interazione.
Grazie a DAMP e a Ekaterinburg! )
Fonte: habr.com
