A semana pasada acudín á conferencia de TI DUMP (https://dump-ekb.ru/) en Ekaterimburgo e quero contarvos o que se falou nas seccións Backend e Devops, e se merecen a pena prestar atención as conferencias rexionais de TI.
Nikolay Sverchkov de Evil Martians sobre Serverless
Que había de todos os xeitos?
En total, a conferencia contou con 8 seccións: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
As salas máis grandes, por certo, están en Science and Management)) Para ~ 350 persoas cada unha. Backend e Frontend non son moito máis pequenos. A sala Devops era a máis pequena, pero activa.
Escoitei os informes nas seccións Devops e Backend e falei un pouco cos altofalantes. Gustaríame falar dos temas tratados e revisar estas seccións na conferencia.
Representantes de SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) falaron nas seccións Devops e Backend. Os temas tratados sobre CI/CD, traballo con servizos de fila, rexistro; temas sen servidor e traballo con PostgreSQL en Go foron ben tratados.
Tamén houbo informes de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, pero non tiven tempo para asistir fisicamente a eles (as gravacións de vídeo e as diapositivas dos informes aínda non están dispoñibles, prometen publicalas nun prazo de 2 semanas). en dump-ekb.ru).
Sección Devops
O sorprendente foi que a sección se celebrase no salón máis pequeno, cunhas 50 prazas. A xente ata estaba de pé nos corredores :) Vouvos contar as reportaxes que conseguín escoitar.
Elástico que pesa un petabyte
A sección comezou cun informe de Vladimir Lil (SKB-Kontur) sobre Elasticsearch en Kontur. Teñen un Elastic bastante grande e cargado (~800 TB de datos, ~1.3 petabytes tendo en conta a redundancia). Elasticsearch para todos os servizos de Kontur é único, consta de 2 clústeres (de 7 e 9 servidores) e é tan importante que Kontur ten un enxeñeiro especial de Elasticsearch (de feito, o propio Vladimir).
Vladimir tamén compartiu os seus pensamentos sobre os beneficios de Elasticsearch e os problemas que trae.
Beneficio:
- Todos os rexistros están nun só lugar, fácil acceso a eles
- Almacenar rexistros durante un ano e analizalos facilmente
- Alta velocidade de traballo con rexistros
- Visualización de datos xenial fóra da caixa
Problemas:
- O intermediario de mensaxes é imprescindible (para Kontur o seu papel é desempeñado por Kafka)
- características de traballar con Elasticsearch Curator (carga elevada creada periódicamente a partir de tarefas habituais en Curator)
- sen autorización integrada (só para diñeiro separado, bastante grande ou como complementos de código aberto con distintos graos de preparación para a produción)
Só houbo críticas positivas sobre Open Distro para Elasticsearch :) Alí resolveuse o mesmo problema de autorización.
De onde vén o petabyte?Os seus nodos consisten en servidores con 12*8 Tb SATA + 2*2 Tb SSD. Almacenamento en frío en SATA, SSD só para caché quente (almacenamento en quente).
7+9 servidores, (7 + 9) * 12 * 8 = 1536 Tb.
Parte do espazo está en reserva, reservado para o despedimento, etc.
Os rexistros dunhas 90 aplicacións son enviados a Elasticsearch, incluíndo todos os servizos de informes de Kontur, Elba, etc.
Características de desenvolvemento en Serverless
O seguinte é un informe de Ruslan Serkin de DataArt sobre Serverless.
Ruslan falou sobre o que é o desenvolvemento co enfoque sen servidor en xeral e cales son as súas características.
Sen servidor é un enfoque de desenvolvemento no que os desenvolvedores non tocan a infraestrutura de ningún xeito. Exemplo: AWS Lambda Serverless, Kubeless.io (sen servidor dentro de Kubernetes), Google Cloud Functions.
Unha aplicación sen servidor ideal é simplemente unha función que envía unha solicitude a un provedor sen servidor a través dunha pasarela API especial. Un microservizo ideal, mentres que AWS Lambda tamén admite un gran número de linguaxes de programación modernas. O custo de mantemento e implantación da infraestrutura pasa a ser cero no caso dos provedores de nube, o soporte de pequenas aplicacións tamén será moi barato (AWS Lambda - $ 0.2 / 1 millón de solicitudes simples).
A escalabilidade deste sistema é case ideal: o provedor de nube encárgase diso, Kubeless escala automaticamente dentro do clúster de Kubernetes.
Hai desvantaxes:
- desenvolver grandes aplicacións é cada vez máis difícil
- hai dificultades coas aplicacións de creación de perfiles (só tes dispoñibles os rexistros, pero non a creación de perfiles no sentido habitual)
- sen versións
Para ser honesto, escoitei falar de Serverless hai uns anos, pero todos estes anos non me quedou claro como usalo correctamente. Despois do informe de Ruslan, apareceu o entendemento, e despois do informe de Nikolai Sverchkov (Evil Martians) da sección Backend, consolidouse. Non foi en balde que fun á conferencia :)
O CI é para os pobres, ou paga a pena escribir o teu propio CI para un estudo web?
Mikhail Radionov, xefe do estudo web Flag de Ekaterimburgo, falou sobre CI/CD autoescrito.
O seu estudo pasou de "CI/CD manual" (iniciar sesión no servidor a través de SSH, facer un git pull, repetir 100 veces ao día) a Jenkins e a unha ferramenta autoescrita que che permite supervisar o código e realizar versións chamadas Pullkins. .
Por que Jenkins non traballou? Non proporcionaba suficiente flexibilidade por defecto e era demasiado difícil de personalizar.
"Flag" desenvólvese en Laravel (marco PHP). Ao desenvolver un servidor CI/CD, Mikhail e os seus colegas utilizaron os mecanismos integrados de Laravel chamados Telescope and Envoy. O resultado é un servidor en PHP (teña en conta) que procesa as solicitudes de webhook entrantes, pode construír o frontend e o backend, implementarse en diferentes servidores e informar a Slack.
Despois, para poder realizar unha implementación azul/verde e ter unha configuración uniforme en ambientes de fase de desenvolvemento, cambiaron a Docker. As vantaxes seguían sendo as mesmas, engadíronse as posibilidades de homoxeneizar o ambiente e de implantación sen problemas, e engadiuse a necesidade de aprender Docker a traballar con el correctamente.
Como reducimos nun 99 % o número de retrocesos do servidor
O último informe da sección Devops foi de Viktor Eremchenko, enxeñeiro principal de devops en Miro.com (anteriormente RealTimeBoard).
RealTimeBoard, o produto insignia do equipo Miro, baséase nunha aplicación Java monolítica. Recopilalo, probalo e despregalo sen tempo de inactividade é unha tarefa difícil. Neste caso, é importante implementar tal versión do código para que non teña que ser revertida (é un monólito pesado).
No camiño de construír un sistema que permita facelo, Miro pasou por un camiño que incluía traballar a arquitectura, as ferramentas empregadas (Atlassian Bamboo, Ansible, etc.), e traballar na estrutura dos equipos (agora teñen un equipo Devops dedicado + moitos equipos Scrum separados de desenvolvedores de diferentes perfís).
O camiño resultou difícil e espiñento, e Víctor compartiu a dor e o optimismo acumulados que non remataron aí.
Gañou un libro por facer preguntas
Sección de backend
Conseguín asistir a 2 informes: de Nikolay Sverchkov (Evil Martians), tamén sobre Serverless, e de Grigory Koshelev (empresa Kontur) sobre telemetría.
Sen servidor para simples mortais
Se Ruslan Sirkin falou sobre o que é Serverless, Nikolay mostrou aplicacións sinxelas usando Serverless e falou sobre os detalles que afectan o custo e a velocidade das aplicacións en AWS Lambda.
Un detalle interesante: o elemento mínimo de pago é de 128 Mb de memoria e 100 ms de CPU, custa 0,000000208 $. Ademais, 1 millón de solicitudes deste tipo ao mes son gratuítas.
Algunhas das funcións de Nikolai adoitaban superar o límite de 100 ms (a aplicación principal estaba escrita en Ruby), polo que reescribilas en Go proporcionou un excelente aforro.
Vostok Hercules: fai que a telemetría sexa xenial de novo!
O último informe da sección Backend de Grigory Koshelev (empresa Kontur) sobre telemetría. Telemetría significa rexistros, métricas, rastros de aplicacións.
Para este fin, Contour usa ferramentas autoescritas publicadas en Github. Ferramenta do informe - Hércules, , úsase para entregar datos de telemetría.
O informe de Vladimir Lila na sección Devops discutiu sobre o almacenamento e procesamento de rexistros en Elasticsearch, pero aínda queda a tarefa de entregar rexistros de moitos miles de dispositivos e aplicacións, e ferramentas como Vostok Hercules solucionalos.
O circuíto seguiu un camiño coñecido por moitos: desde RabbitMQ ata Apache Kafka, pero non todo é tan sinxelo)) Tiveron que engadir Zookeeper, Cassandra e Graphite ao circuíto. Non divulgarei completamente a información deste informe (non o meu perfil), se estás interesado, podes esperar ás diapositivas e vídeos na páxina web da conferencia.
Como se compara con outras conferencias?
Non o podo comparar con conferencias de Moscova e San Petersburgo, podo comparalo con outros eventos nos Urais e co 404fest en Samara.
DAMP celébrase en 8 seccións, este é un récord para as conferencias dos Urais. Seccións de Ciencia e Xestión moi grandes, isto tamén é inusual. A audiencia en Ekaterimburgo está bastante estruturada: a cidade ten grandes departamentos de desenvolvemento para Yandex, Kontur, Tinkoff, e isto deixa a súa pegada nos informes.
Outro punto interesante é que moitas empresas teñen 3-4 relatores á vez na conferencia (este foi o caso de Kontur, Evil Martians, Tinkoff). Moitos deles foron patrocinadores, pero as reportaxes están bastante á par con outras, non son reportaxes publicitarios.
Ir ou non ir? Se vives nos Urais ou nas proximidades, tes a oportunidade e estás interesado nos temas - si, por suposto. Se estás a pensar nunha viaxe longa, miraríame aos temas de reportaxes e reportaxes en vídeo de anos anteriores e tomou unha decisión.
Outra vantaxe das conferencias nas rexións, por regra xeral, é que é fácil comunicarse co orador despois dos informes; simplemente hai menos solicitantes para esta comunicación.
Grazas a Dump e Ekaterinburg! )
Fonte: www.habr.com