Na semana passada fui à conferência DUMP IT (https://dump-ekb.ru/) em Yekaterinburg e quero contar a vocês o que foi discutido nas seções Backend e Devops e se as conferências regionais de TI merecem atenção.
Nikolay Sverchkov de Evil Martians sobre Serverless
O que havia, afinal?
No total, a conferência teve 8 seções: Backend, Frontend, Mobile, Testes e QA, Devops, Design, Ciência e Gestão.
Os maiores salões, aliás, ficam no Science and Management)) Para cerca de 350 pessoas cada. Backend e Frontend não são muito menores. A sala Devops era a menor, mas ativa.
Ouvi os relatórios nas seções Devops e Backend e conversei um pouco com os palestrantes. Gostaria de falar sobre os tópicos abordados e revisar essas seções na conferência.
Representantes de SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) falaram nas seções Devops e Backend. Os tópicos abordados CI/CD, trabalho com serviços de fila, registro; tópicos sem servidor e trabalho com PostgreSQL em Go foram bem abordados.
Também houve reportagens de Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mas não tive tempo de atendê-los fisicamente (as gravações de vídeo e slides dos reportagens ainda não estão disponíveis, prometem publicá-los em 2 semanas em dump-ekb.ru).
Seção Devops
O que surpreendeu foi que a seção foi realizada no menor salão, com cerca de 50 lugares. As pessoas estavam até paradas nos corredores :) Vou contar para vocês as reportagens que consegui ouvir.
Elástico pesando um petabyte
A seção começou com um relatório de Vladimir Lil (SKB-Kontur) sobre o Elasticsearch no Kontur. Eles têm um Elastic bastante grande e carregado (~800 TB de dados, ~1.3 petabytes levando em consideração a redundância). O Elasticsearch para todos os serviços do Kontur é único, consiste em 2 clusters (de 7 e 9 servidores) e é tão importante que o Kontur possui um engenheiro especial do Elasticsearch (na verdade, o próprio Vladimir).
Vladimir também compartilhou suas idéias sobre os benefícios do Elasticsearch e os problemas que ele traz.
Benefícios:
- Todos os registros estão em um só lugar, fácil acesso a eles
- Armazenar registros por um ano e analisá-los facilmente
- Alta velocidade de trabalho com logs
- Visualização de dados incrível pronta para uso
Problemas:
- o corretor de mensagens é obrigatório (para Kontur seu papel é desempenhado por Kafka)
- recursos de trabalho com Elasticsearch Curator (alta carga criada periodicamente a partir de tarefas regulares no Curator)
- sem autorização integrada (apenas por dinheiro separado e muito grande ou como plug-ins de código aberto com vários graus de prontidão para produção)
Houve apenas comentários positivos sobre o Open Distro for Elasticsearch :) O mesmo problema de autorização foi resolvido lá.
De onde vem o petabyte?Seus nós consistem em servidores com SATA de 12*8 Tb + SSD de 2*2 Tb. Armazenamento frio em SATA, SSD apenas para cache quente (armazenamento quente).
7+9 servidores, (7 + 9) * 12 * 8 = 1536 Tb.
Parte do espaço está em reserva, reservada para redundância, etc.
Logs de cerca de 90 aplicativos são enviados para o Elasticsearch, incluindo todos os serviços de relatórios do Kontur, Elba, etc.
Recursos de desenvolvimento em Serverless
A seguir está um relatório de Ruslan Serkin da DataArt sobre Serverless.
Ruslan falou sobre o que é o desenvolvimento com a abordagem Serverless em geral e quais são seus recursos.
Serverless é uma abordagem de desenvolvimento em que os desenvolvedores não alteram a infraestrutura de forma alguma. Exemplo - AWS Lambda Serverless, Kubeless.io (Serverless dentro do Kubernetes), Google Cloud Functions.
Um aplicativo Serverless ideal é simplesmente uma função que envia uma solicitação a um provedor Serverless por meio de um API Gateway especial. Um microsserviço ideal, enquanto o AWS Lambda também oferece suporte a um grande número de linguagens de programação modernas. O custo de manutenção e implantação de infraestrutura torna-se zero no caso de provedores de nuvem, suportar pequenas aplicações também será muito barato (AWS Lambda - US$ 0.2/1 milhão de solicitações simples).
A escalabilidade de tal sistema é quase ideal - o provedor de nuvem cuida disso sozinho, o Kubeless é dimensionado automaticamente dentro do cluster Kubernetes.
Existem desvantagens:
- desenvolver grandes aplicações está se tornando mais difícil
- há dificuldade com a criação de perfil de aplicativos (apenas registros estão disponíveis para você, mas não a criação de perfil no sentido usual)
- sem versionamento
Para ser sincero, ouvi falar do Serverless há alguns anos, mas durante todos esses anos não estava claro para mim como usá-lo corretamente. Após o relatório de Ruslan, o entendimento apareceu, e após o relatório de Nikolai Sverchkov (Evil Martians) da seção Backend, ele foi consolidado. Não foi em vão que fui à conferência :)
CI é para os pobres ou vale a pena escrever seu próprio CI para um estúdio web?
Mikhail Radionov, chefe do estúdio web Flag de Yekaterinburg, falou sobre CI/CD escrito por ele mesmo.
Seu estúdio passou de “CI/CD manual” (faça login no servidor via SSH, faça um git pull, repita 100 vezes por dia) para Jenkins e para uma ferramenta autoescrita que permite monitorar código e realizar lançamentos chamada Pullkins .
Por que Jenkins não funcionou? Ele não fornecia flexibilidade suficiente por padrão e era muito difícil de personalizar.
“Flag” é desenvolvido em Laravel (framework PHP). Ao desenvolver um servidor CI/CD, Mikhail e seus colegas usaram os mecanismos integrados do Laravel chamados Telescope e Envoy. O resultado é um servidor em PHP (observe) que processa solicitações de webhook recebidas, pode construir o front-end e o back-end, implantar em servidores diferentes e reportar ao Slack.
Então, para poder realizar a implantação azul/verde e ter configurações uniformes em ambientes dev-stage-prod, eles mudaram para o Docker. As vantagens permaneceram as mesmas, foram acrescentadas as possibilidades de homogeneização do ambiente e implantação contínua, e foi acrescentada a necessidade de aprender o Docker para trabalhar com ele corretamente.
Como reduzimos o número de reversões de lançamento de servidores em 99%
O último relatório na seção Devops foi de Viktor Eremchenko, engenheiro-chefe de devops da Miro.com (anteriormente RealTimeBoard).
O RealTimeBoard, principal produto da equipe Miro, é baseado em um aplicativo Java monolítico. Coletá-lo, testá-lo e implantá-lo sem tempo de inatividade é uma tarefa difícil. Nesse caso, é importante implantar essa versão do código para que não precise ser revertido (é um monólito pesado).
No caminho para construir um sistema que permita fazer isso, Miro percorreu um caminho que incluiu trabalhar na arquitetura, nas ferramentas utilizadas (Atlassian Bamboo, Ansible, etc), e trabalhar na estrutura das equipes (agora têm uma equipe Devops dedicada + muitas equipes Scrum separadas de desenvolvedores de perfis diferentes).
O caminho revelou-se difícil e espinhoso, e Victor compartilhou a dor acumulada e o otimismo que não terminou aí.
Ganhei um livro por tirar dúvidas
Seção de back-end
Consegui assistir a 2 relatórios - de Nikolay Sverchkov (Evil Martians), também sobre Serverless, e de Grigory Koshelev (empresa Kontur) sobre telemetria.
Sem servidor para meros mortais
Se Ruslan Sirkin falou sobre o que é Serverless, Nikolay mostrou aplicativos simples usando Serverless e falou sobre os detalhes que afetam o custo e a velocidade dos aplicativos no AWS Lambda.
Um detalhe interessante: o elemento mínimo pago é de 128 Mb de memória e 100 ms de CPU, custa $0,000000208. Além disso, 1 milhão dessas solicitações por mês são gratuitas.
Algumas das funções de Nikolai frequentemente excediam o limite de 100 ms (a aplicação principal foi escrita em Ruby), portanto, reescrevê-las em Go proporcionou excelentes economias.
Vostok Hercules — torne a telemetria excelente novamente!
O último relatório da seção Backend de Grigory Koshelev (empresa Kontur) sobre telemetria. Telemetria significa logs, métricas, rastreamentos de aplicativos.
Para isso, o Contour utiliza ferramentas de autoria própria publicadas no Github. Ferramenta do relatório - Hércules, , é usado para entregar dados de telemetria.
O relatório de Vladimir Lila na seção Devops discutiu o armazenamento e processamento de logs no Elasticsearch, mas ainda há a tarefa de entregar logs de milhares de dispositivos e aplicativos, e ferramentas como Vostok Hercules resolvem isso.
O circuito seguiu um caminho conhecido por muitos - do RabbitMQ ao Apache Kafka, mas nem tudo é tão simples)) Eles tiveram que adicionar Zookeeper, Cassandra e Graphite ao circuito. Não divulgarei integralmente as informações deste relatório (não meu perfil), caso tenha interesse pode aguardar os slides e vídeos no site da conferência.
Como isso se compara a outras conferências?
Não posso compará-lo com conferências em Moscou e São Petersburgo, posso compará-lo com outros eventos nos Urais e com o 404fest em Samara.
O DAMP é realizado em 8 seções, este é um recorde para as conferências dos Urais. Seções de Ciência e Gestão muito grandes, isso também é incomum. O público em Yekaterinburg é bastante estruturado - a cidade possui grandes departamentos de desenvolvimento de Yandex, Kontur, Tinkoff, e isso deixa sua marca nas reportagens.
Outro ponto interessante é que muitas empresas têm de 3 a 4 palestrantes ao mesmo tempo na conferência (este foi o caso de Kontur, Evil Martians, Tinkoff). Muitos deles eram patrocinadores, mas as reportagens estão no mesmo nível de outras, não são reportagens publicitárias.
Ir ou não ir? Se você mora nos Urais ou nas proximidades, tem oportunidade e se interessa pelos temas - sim, claro. Se você está pensando em uma viagem longa, eu daria uma olhada nos tópicos de reportagens e reportagens em vídeo de anos anteriores e tomou uma decisão.
Outra vantagem das conferências nas regiões, via de regra, é a facilidade de comunicação com o palestrante após os relatórios, simplesmente há menos candidatos para tal comunicação.
Obrigado a Dump e Ekaterinburg! )
Fonte: habr.com