La settimana scorsa sono andato alla conferenza DUMP IT (https://dump-ekb.ru/) a Ekaterinburg e voglio raccontarvi cosa è stato discusso nelle sezioni Backend e Devops e se meritano attenzione le conferenze IT regionali.
Nikolay Sverchkov di Evil Martians su Serverless
Cosa c'era comunque?
In totale, la conferenza aveva 8 sezioni: Backend, Frontend, Mobile, Testing e QA, Devops, Design, Scienza e Management.
Le sale più grandi, tra l'altro, sono presso Science and Management)) Per circa 350 persone ciascuna. Backend e Frontend non sono molto più piccoli. La sala Devops era la più piccola, ma attiva.
Ho ascoltato i resoconti nelle sezioni Devops e Backend e ho parlato un po' con i relatori. Vorrei parlare degli argomenti trattati e rivedere queste sezioni durante la conferenza.
I rappresentanti di SKB-Kontur, DataArt, Evil Martians, studio web Ekaterinburg Flag, Miro (RealTimeBoard) hanno parlato nelle sezioni Devops e Backend. Gli argomenti trattati sono stati CI/CD, lavoro con i servizi di coda, registrazione; gli argomenti serverless e il lavoro con PostgreSQL in Go sono stati ben trattati.
C'erano anche segnalazioni di Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ma non ho avuto il tempo di assistervi fisicamente (le registrazioni video e le diapositive delle segnalazioni non sono ancora disponibili, promettono di pubblicarle entro 2 settimane su dump-ekb.ru).
Sezione Devops
La cosa sorprendente è che la sezione si è tenuta nella sala più piccola, circa 50 posti. C'era gente anche nei corridoi :) Ti parlerò dei rapporti che sono riuscito ad ascoltare.
Elastico del peso di un petabyte
La sezione è iniziata con un rapporto di Vladimir Lil (SKB-Kontur) su Elasticsearch a Kontur. Hanno un elastico abbastanza grande e carico (~800 TB di dati, ~1.3 petabyte tenendo conto della ridondanza). Elasticsearch per tutti i servizi Kontur è unico, è composto da 2 cluster (di 7 e 9 server) ed è così importante che Kontur ha uno speciale ingegnere Elasticsearch (in realtà, lo stesso Vladimir).
Vladimir ha anche condiviso i suoi pensieri sui vantaggi di Elasticsearch e sui problemi che comporta.
vantaggi:
- Tutti i registri sono in un unico posto, facilmente accessibili
- Memorizzare i registri per un anno e analizzarli facilmente
- Alta velocità di lavoro con i log
- Fantastica visualizzazione dei dati pronta all'uso
Problemi:
- il message broker è un must (per Kontur il suo ruolo è svolto da Kafka)
- funzionalità di lavoro con Elasticsearch Curator (caricamento creato periodicamente da attività regolari in Curator)
- nessuna autorizzazione integrata (solo per denaro separato, piuttosto elevato o come plug-in open source con vari gradi di preparazione per la produzione)
Ci sono state solo recensioni positive su Open Distro per Elasticsearch :) Lo stesso problema di autorizzazione è stato risolto lì.
Da dove viene il petabyte?I loro nodi sono costituiti da server con 12*8 Tb SATA + 2*2 Tb SSD. Cold storage su SATA, SSD solo per hot cache (hot storage).
7+9 server, (7 + 9) * 12 * 8 = 1536 TB.
Parte dello spazio è di riserva, destinata alla ridondanza, ecc.
I log di circa 90 applicazioni vengono inviati a Elasticsearch, inclusi tutti i servizi di reporting di Kontur, Elba, ecc.
Funzionalità di sviluppo su Serverless
Segue un rapporto di Ruslan Serkin di DataArt su Serverless.
Ruslan ha parlato di cosa sia in generale lo sviluppo con l'approccio Serverless e di quali siano le sue caratteristiche.
Serverless è un approccio allo sviluppo in cui gli sviluppatori non toccano in alcun modo 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 a un provider Serverless attraverso uno speciale gateway API. Un microservizio ideale, mentre AWS Lambda supporta anche un gran numero di linguaggi di programmazione moderni. Il costo di manutenzione e implementazione dell'infrastruttura diventa zero nel caso dei fornitori di servizi cloud, anche il supporto di piccole applicazioni sarà molto economico (AWS Lambda - 0.2 dollari / 1 milione di richieste semplici).
La scalabilità di un sistema del genere è quasi ideale: il fornitore di servizi cloud se ne occupa da solo, Kubeless si adatta automaticamente all'interno del cluster Kubernetes.
Ci sono degli svantaggi:
- lo sviluppo di applicazioni di grandi dimensioni sta diventando sempre più difficile
- c'è difficoltà con le applicazioni di profilazione (sono disponibili solo i log, ma non la profilazione nel senso comune del termine)
- nessun controllo delle versioni
Ad essere sincero, ho sentito parlare di Serverless qualche anno fa, ma in tutti questi anni non mi era chiaro come usarlo correttamente. Dopo il rapporto di Ruslan, è apparsa la comprensione e, dopo il rapporto di Nikolai Sverchkov (Evil Martians) dalla sezione Backend, si è consolidata. Non è stato invano che sono andato alla conferenza :)
La CI è per i poveri o vale la pena scrivere la propria CI per uno studio web?
Mikhail Radionov, capo dello studio web Flag di Ekaterinburg, ha parlato del CI/CD autoprodotto.
Il suo studio è passato da "CI/CD manuale" (accedere al server tramite SSH, eseguire un git pull, ripetere 100 volte al giorno) a Jenkins e a uno strumento autoprodotto che consente di monitorare il codice ed eseguire rilasci chiamati Pullkins .
Perché Jenkins non ha funzionato? Per impostazione predefinita non forniva sufficiente flessibilità ed era troppo difficile da personalizzare.
“Flag” si sviluppa in Laravel (framework PHP). Durante lo sviluppo di un server CI/CD, Mikhail e i suoi colleghi hanno utilizzato i meccanismi integrati di Laravel chiamati Telescope ed Envoy. Il risultato è un server in PHP (nota) che elabora le richieste webhook in arrivo, può creare frontend e backend, distribuirle su server diversi e riferire a Slack.
Quindi, per poter eseguire la distribuzione blu/verde e avere impostazioni uniformi negli ambienti di fase di sviluppo e produzione, sono passati a Docker. I vantaggi sono rimasti gli stessi, sono state aggiunte le possibilità di omogeneizzazione dell'ambiente e di implementazione senza soluzione di continuità, nonché la necessità di imparare a utilizzare Docker correttamente.
Come abbiamo ridotto del 99% il numero di rollback delle versioni dei server
L'ultimo rapporto nella sezione Devops è stato di Viktor Eremchenko, ingegnere capo devops presso Miro.com (ex RealTimeBoard).
RealTimeBoard, il prodotto di punta del team Miro, si basa su un'applicazione Java monolitica. Raccoglierlo, testarlo e distribuirlo senza tempi di inattività è un compito difficile. In questo caso, è importante distribuire tale versione del codice in modo che non sia necessario eseguirne il rollback (è un monolite pesante).
Nel tentativo di costruire un sistema che consentisse di fare ciò, Miro ha seguito un percorso che prevedeva il lavoro sull'architettura, gli strumenti utilizzati (Atlassian Bamboo, Ansible, ecc.) e il lavoro sulla struttura dei team (ora hanno un team Devops dedicato + molti team Scrum separati da sviluppatori di diversi profili).
Il percorso si è rivelato difficile e spinoso e Victor ha condiviso il dolore e l'ottimismo accumulati che non sono finiti qui.
Ha vinto un libro per aver posto domande
Sezione back-end
Sono riuscito a partecipare a 2 rapporti: di Nikolay Sverchkov (Evil Martians), anch'esso su Serverless, e di Grigory Koshelev (società Kontur) sulla telemetria.
Serverless per semplici mortali
Se Ruslan Sirkin ha parlato di cos'è Serverless, Nikolay ha mostrato semplici applicazioni che utilizzano Serverless e ha parlato dei dettagli che influiscono sul costo e sulla velocità delle applicazioni in AWS Lambda.
Un dettaglio interessante: l'elemento minimo pagato è 128 Mb di memoria e 100 ms di CPU, costa $ 0,000000208. Inoltre, 1 milione di richieste di questo tipo al mese sono gratuite.
Alcune funzioni di Nikolai superavano spesso il limite di 100 ms (l'applicazione principale era scritta in Ruby), quindi riscriverle in Go ha consentito un ottimo risparmio.
Vostok Hercules: rendi di nuovo eccezionale la telemetria!
L'ultimo rapporto della sezione Backend di Grigory Koshelev (società Kontur) sulla telemetria. Telemetria significa log, metriche, tracce delle applicazioni.
A questo scopo, Contour utilizza strumenti autoprodotti pubblicati su Github. Strumento dal rapporto: Ercole, , viene utilizzato per fornire dati di telemetria.
Il rapporto di Vladimir Lila nella sezione Devops ha discusso dell’archiviazione e dell’elaborazione dei log in Elasticsearch, ma c’è ancora il compito di fornire log da molte migliaia di dispositivi e applicazioni e strumenti come Vostok Hercules li risolvono.
Il circuito ha seguito un percorso noto a molti: da RabbitMQ ad Apache Kafka, ma non tutto è così semplice)) Hanno dovuto aggiungere Zookeeper, Cassandra e Graphite al circuito. Non divulgherò integralmente le informazioni su questa relazione (non sul mio profilo), se sei interessato puoi attendere le diapositive e i video sul sito della conferenza.
Come si confronta con le altre conferenze?
Non posso paragonarlo alle conferenze di Mosca e San Pietroburgo, posso paragonarlo ad altri eventi negli Urali e al 404fest a Samara.
DAMP si svolge in 8 sezioni, questo è un record per le conferenze degli Urali. Sezioni scientifiche e gestionali molto grandi, anche questo è insolito. Il pubblico a Ekaterinburg è abbastanza strutturato: la città ha grandi dipartimenti di sviluppo per Yandex, Kontur, Tinkoff, e questo lascia il segno nei rapporti.
Un altro punto interessante è che molte aziende hanno 3-4 relatori contemporaneamente alla conferenza (questo è stato il caso di Kontur, Evil Martians, Tinkoff). Molti di loro erano sponsor, ma i rapporti sono abbastanza alla pari con gli altri, questi non sono rapporti pubblicitari.
andare o non andare? Se vivi negli Urali o nelle vicinanze, hai l'opportunità e sei interessato agli argomenti - sì, certo. Se stai pensando a un lungo viaggio, esaminerei gli argomenti dei reportage e dei videoreport degli anni precedenti e ho preso una decisione.
Un altro vantaggio delle conferenze nelle regioni, di regola, è che è facile comunicare con l'oratore dopo le relazioni, semplicemente ci sono meno candidati per tale comunicazione.
Grazie a Dump ed Ekaterinburg! )
Fonte: habr.com