A conferência Habr não é uma história de estreia. Anteriormente, realizávamos eventos Toaster bastante grandes para 300-400 pessoas, mas agora decidimos que seriam relevantes pequenas reuniões temáticas, cuja direção você pode definir, por exemplo, nos comentários. A primeira conferência deste formato foi realizada em julho e foi dedicada ao desenvolvimento backend. Os participantes ouviram relatos sobre as características da transição do backend para o ML e sobre o desenho do serviço Quadrupel no portal dos Serviços do Estado, e também participaram numa mesa redonda dedicada ao Serverless. Para quem não pôde comparecer pessoalmente ao evento, neste post contamos o mais interessante.
Do desenvolvimento de back-end ao aprendizado de máquina
O que os engenheiros de dados fazem em ML? Como as tarefas de um desenvolvedor back-end e de um engenheiro de ML são semelhantes e diferentes? Que caminho você precisa seguir para mudar a sua primeira profissão para a segunda? Isto foi contado por Alexander Parinov, que ingressou no aprendizado de máquina após 10 anos de trabalho de back-end.
Alexandre Parinov
Hoje Alexander trabalha como arquiteto de sistemas de visão computacional no X5 Retail Group e contribui para projetos de código aberto relacionados à visão computacional e aprendizado profundo (github.com/creafz). Suas habilidades são confirmadas pela participação no top 100 do ranking mundial do Kaggle Master (kaggle.com/creafz), a plataforma mais popular para competições de aprendizado de máquina.
Por que mudar para o aprendizado de máquina
Há um ano e meio, Jeff Dean, chefe do Google Brain, o projeto de pesquisa de inteligência artificial baseado em aprendizagem profunda do Google, descreveu como meio milhão de linhas de código no Google Translate foram substituídas por uma rede neural Tensor Flow composta por apenas 500 linhas. Após o treinamento da rede, a qualidade dos dados aumentou e a infraestrutura ficou mais simples. Parece que este é o nosso futuro brilhante: não precisamos mais escrever código, basta fazer neurônios e preenchê-los com dados. Mas na prática tudo é muito mais complicado.
Infraestrutura de ML no Google
As redes neurais são apenas uma pequena parte da infraestrutura (o pequeno quadrado preto na imagem acima). Muitos mais sistemas auxiliares são necessários para receber dados, processá-los, armazená-los, verificar a qualidade, etc., precisamos de infraestrutura para treinamento, implantação de código de aprendizado de máquina na produção e teste desse código. Todas essas tarefas são exatamente semelhantes às que os desenvolvedores de back-end fazem.
Processo de aprendizado de máquina
Qual é a diferença entre ML e back-end?
Na programação clássica, escrevemos código e este dita o comportamento do programa. No ML, temos um pequeno código de modelo e muitos dados que lançamos no modelo. Os dados em ML são muito importantes: o mesmo modelo treinado em dados diferentes pode mostrar resultados completamente diferentes. O problema é que os dados quase sempre ficam dispersos e armazenados em diferentes sistemas (bancos de dados relacionais, bancos de dados NoSQL, logs, arquivos).
Versionamento de dados
O ML requer versionamento não só do código, como no desenvolvimento clássico, mas também dos dados: é necessário entender claramente em que o modelo foi treinado. Para fazer isso, você pode usar a popular biblioteca Data Science Version Control (dvc.org).
Marcação de dados
A próxima tarefa é a rotulagem de dados. Por exemplo, marque todos os objetos da imagem ou diga a qual classe ele pertence. Isso é feito por serviços especiais como Yandex.Toloka, cujo trabalho é bastante simplificado pela presença de uma API. As dificuldades surgem devido ao “fator humano”: você pode melhorar a qualidade dos dados e reduzir os erros ao mínimo confiando a mesma tarefa a vários executores.
Visualização no Tensor Board
O registro de experimentos é necessário para comparar resultados e selecionar o melhor modelo com base em algumas métricas. Existe um grande conjunto de ferramentas para visualização - por exemplo, Tensor Board. Mas não existem formas ideais de armazenar experimentos. As pequenas empresas costumam se contentar com uma planilha Excel, enquanto as grandes usam plataformas especiais para armazenar os resultados em um banco de dados.
Existem muitas plataformas de aprendizado de máquina, mas nenhuma delas cobre 70% das necessidades
O primeiro problema que se enfrenta ao colocar um modelo treinado em produção está relacionado à ferramenta favorita dos cientistas de dados - Jupyter Notebook. Não há modularidade nele, ou seja, a saída é uma “rodapé” de código que não é dividida em peças lógicas - módulos. Está tudo misturado: classes, funções, configurações, etc. Este código é difícil de versionar e testar.
Como lidar com isso? Você pode se resignar, como o Netflix, e criar sua própria plataforma que permite lançar esses laptops diretamente na produção, transferir dados para eles como entrada e obter resultados. Você pode forçar os desenvolvedores que estão colocando o modelo em produção a reescrever o código normalmente, dividindo-o em módulos. Mas com esta abordagem é fácil cometer um erro e o modelo não funcionará conforme pretendido. Portanto, a opção ideal é proibir o uso do Jupyter Notebook para código do modelo. Se, é claro, os cientistas de dados concordarem com isso.
Modelo como uma caixa preta
A maneira mais fácil de colocar um modelo em produção é usá-lo como uma caixa preta. Você tem algum tipo de classe de modelo, recebeu os pesos do modelo (parâmetros dos neurônios da rede treinada), e se você inicializar essa classe (chamar o método de previsão, alimentá-lo com uma imagem), você obterá um certo previsão como saída. O que acontece lá dentro não importa.
Processo de servidor separado com modelo
Você também pode criar um determinado processo separado e enviá-lo através de uma fila RPC (com imagens ou outros dados de origem. Receberemos previsões na saída.
Um exemplo de uso de um modelo no Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
O problema com essa abordagem é a limitação de desempenho. Digamos que temos um código Phyton escrito por cientistas de dados que é lento e queremos extrair o máximo desempenho. Para isso, você pode utilizar ferramentas que convertam o código em nativo ou convertam-no em outro framework sob medida para produção. Existem essas ferramentas para todos os frameworks, mas não existem ferramentas ideais; você mesmo terá que adicioná-las.
A infraestrutura no ML é a mesma de um back-end normal. Existem Docker e Kubernetes, apenas para Docker é necessário instalar o runtime da NVIDIA, que permite que processos dentro do contêiner acessem placas de vídeo no host. O Kubernetes precisa de um plugin para poder gerenciar servidores com placas de vídeo.
Ao contrário da programação clássica, no caso do ML existem muitos elementos móveis diferentes na infraestrutura que precisam ser verificados e testados - por exemplo, código de processamento de dados, pipeline de treinamento de modelo e produção (veja o diagrama acima). É importante testar o código que conecta diferentes partes dos pipelines: há muitas peças e muitas vezes surgem problemas nos limites dos módulos.
Como funciona o AutoML
Os serviços AutoML prometem selecionar o modelo ideal para seus propósitos e treiná-lo. Mas é preciso entender: os dados são muito importantes no ML, o resultado depende da sua preparação. A marcação é feita por pessoas, o que está repleto de erros. Sem um controle rigoroso, o resultado pode ser lixo e ainda não é possível automatizar o processo, sendo necessária a verificação por especialistas - cientistas de dados. É aqui que o AutoML falha. Mas pode ser útil para selecionar uma arquitetura – quando você já preparou os dados e deseja executar uma série de experimentos para encontrar o melhor modelo.
Como entrar no aprendizado de máquina
A maneira mais fácil de entrar no ML é desenvolver em Python, que é usado em todas as estruturas de aprendizado profundo (e estruturas regulares). Esta linguagem é praticamente obrigatória para este ramo de atividade. C++ é usado para algumas tarefas de visão computacional, por exemplo, em sistemas de controle para carros autônomos. JavaScript e Shell - para visualização e coisas estranhas como executar um neurônio no navegador. Java e Scala são usados ao trabalhar com Big Data e para aprendizado de máquina. R e Julia são amados por pessoas que estudam estatística matemática.
A maneira mais conveniente de obter experiência prática para começar é no Kaggle; a participação em uma das competições da plataforma dá mais de um ano de estudo teórico. Nesta plataforma você pode pegar o código postado e comentado de outra pessoa e tentar melhorá-lo, otimizá-lo para seus propósitos. Bônus – sua classificação no Kaggle afeta seu salário.
Outra opção é ingressar na equipe de ML como desenvolvedor backend. Existem muitas startups de aprendizado de máquina onde você pode ganhar experiência ajudando seus colegas a resolver seus problemas. Finalmente, você pode ingressar em uma das comunidades de cientistas de dados - Open Data Science (ods.ai) e outras.
O palestrante postou informações adicionais sobre o tema no link
“Quadrupel” - um serviço de notificações direcionadas do portal “Serviços do Estado”
Evgeny Smirnov
O próximo palestrante foi o chefe do departamento de desenvolvimento de infraestrutura do governo eletrônico, Evgeny Smirnov, que falou sobre o Quádruplo. Este é um serviço de notificação direcionado para o portal Gosuslugi (gosuslugi.ru), o recurso governamental mais visitado em Runet. A audiência diária é de 2,6 milhões, no total são 90 milhões de usuários cadastrados no site, dos quais 60 milhões estão confirmados. A carga na API do portal é de 30 mil RPS.
Tecnologias utilizadas no backend dos Serviços do Estado
“Quadrupel” é um serviço de notificação direcionado, com o qual o utilizador recebe uma oferta de serviço no momento que lhe for mais adequado, estabelecendo regras especiais de notificação. Os principais requisitos para o desenvolvimento do serviço foram configurações flexíveis e tempo adequado para envios.
Como funciona o Quadrupel?
O diagrama acima mostra uma das regras de funcionamento do Quadrupel usando como exemplo uma situação com necessidade de substituição da carteira de habilitação. Primeiro, o serviço procura usuários cujo prazo de validade expira em um mês. É mostrado um banner com a oferta de recebimento do serviço adequado e uma mensagem é enviada por e-mail. Para aqueles usuários cujo prazo já expirou, o banner e o e-mail mudam. Após uma troca de direitos bem-sucedida, o usuário recebe outras notificações - com uma proposta para atualizar os dados da identidade.
Do ponto de vista técnico, esses são scripts interessantes nos quais o código é escrito. A entrada são dados, a saída é verdadeiro/falso, correspondente/não correspondente. São mais de 50 regras no total – desde a determinação do aniversário do usuário (a data atual é igual à data de nascimento do usuário) até situações complexas. Todos os dias, essas regras identificam cerca de um milhão de correspondências – pessoas que precisam ser notificadas.
Canais de notificação Quadrupel
Sob o capô do Quadrupel há um banco de dados no qual os dados do usuário são armazenados e três aplicativos:
- Trabalhador destinado à atualização de dados.
- API de descanso coleta e entrega os banners no portal e no aplicativo mobile.
- Scheduler lança trabalho de recálculo de banners ou mailings em massa.
Para atualizar dados, o back-end é orientado a eventos. Duas interfaces - rest ou JMS. São muitos eventos, antes de salvar e processar eles são agregados para não fazer solicitações desnecessárias. O próprio banco de dados, a tabela na qual os dados são armazenados, parece um armazenamento de valores-chave - a chave do usuário e o próprio valor: sinalizadores que indicam a presença ou ausência de documentos relevantes, seu período de validade, estatísticas agregadas sobre a ordem de serviços por este usuário e assim por diante.
Após salvar os dados, é definida uma tarefa no JMS para que os banners sejam imediatamente recalculados – isso deve ser exibido imediatamente na web. O sistema inicia à noite: as tarefas são lançadas no JMS em intervalos do usuário, de acordo com os quais as regras precisam ser recalculadas. Isso é captado pelos processadores envolvidos no recálculo. Em seguida, os resultados do processamento vão para a próxima fila, que salva os banners no banco de dados ou envia tarefas de notificação do usuário para o serviço. O processo leva de 5 a 7 horas e é facilmente escalonável devido ao fato de que você sempre pode adicionar manipuladores ou aumentar instâncias com novos manipuladores.
O serviço funciona muito bem. Mas o volume de dados está crescendo à medida que há mais usuários. Isso leva a um aumento na carga do banco de dados - mesmo levando em consideração o fato de que a API Rest analisa a réplica. O segundo ponto é o JMS, que, como se viu, não é muito adequado devido ao seu alto consumo de memória. Há um alto risco de estouro da fila, causando falha no JMS e interrupção do processamento. É impossível aumentar o JMS depois disso sem limpar os logs.
Está prevista a solução dos problemas por meio de sharding, o que permitirá balancear a carga no banco de dados. Também há planos para alterar o esquema de armazenamento de dados e mudar o JMS para Kafka – uma solução mais tolerante a falhas que resolverá problemas de memória.
Back-end como serviço vs. Sem servidor
Da esquerda para a direita: Alexander Borgart, Andrey Tomilenko, Nikolay Markov, Ara Israelyan
Back-end como serviço ou solução sem servidor? Os participantes na discussão desta questão urgente na mesa redonda foram:
- Ara Israelyan, CTO CTO e fundador do Scorocode.
- Nikolay Markov, engenheiro de dados sênior do Aligned Research Group.
- Andrey Tomilenko, chefe do departamento de desenvolvimento RUVDS.
A conversa foi moderada pelo desenvolvedor sênior Alexander Borgart. Apresentamos os debates em que os ouvintes também participaram em versão abreviada.
— O que é Serverless no seu entendimento?
Andrew: Este é um modelo de computação - uma função Lambda que deve processar dados para que o resultado dependa apenas dos dados. O termo veio do Google ou da Amazon e seu serviço AWS Lambda. É mais fácil para um provedor lidar com tal função alocando um conjunto de capacidade para ela. Diferentes usuários podem ser contabilizados de forma independente nos mesmos servidores.
Nicholas: Simplificando, estamos transferindo parte de nossa infraestrutura de TI e lógica de negócios para a nuvem, para a terceirização.
Arara: Por parte dos desenvolvedores - uma boa tentativa de economizar recursos, por parte dos profissionais de marketing - para ganhar mais dinheiro.
— Serverless é o mesmo que microsserviços?
Nicholas: Não, Serverless é mais uma organização de arquitetura. Um microsserviço é uma unidade atômica de alguma lógica. Serverless é uma abordagem, não uma “entidade separada”.
Arara: uma função Serverless pode ser empacotada em um microsserviço, mas não será mais Serverless, deixará de ser uma função Lambda. No Serverless, uma função só começa a funcionar no momento em que é solicitada.
Andrew: Eles diferem em sua vida útil. Lançamos a função Lambda e esquecemos. Funcionou por alguns segundos e o próximo cliente pode processar sua solicitação em outra máquina física.
— Qual escala melhor?
Arara: ao escalar horizontalmente, as funções do Lambda se comportam exatamente da mesma forma que os microsserviços.
Nicholas: qualquer que seja o número de réplicas que você definir, haverá o mesmo número delas; o Serverless não tem problemas de dimensionamento. Fiz um conjunto de réplicas no Kubernetes, lancei 20 instâncias “em algum lugar” e 20 links anônimos foram retornados para você. Avançar!
— É possível escrever um backend em Serverless?
Andrew: Teoricamente, mas não faz sentido. As funções Lambda dependerão de um único repositório – precisamos garantir a garantia. Por exemplo, se um usuário realizou uma determinada transação, na próxima vez que entrar em contato deverá ver: a transação foi realizada, os fundos foram creditados. Todas as funções do Lambda serão bloqueadas nesta chamada. Na verdade, um monte de funções sem servidor se transformarão em um único serviço com um ponto de gargalo de acesso ao banco de dados.
— Em que situações faz sentido usar arquitetura serverless?
Andrew: Tarefas que não requerem armazenamento compartilhado - a mesma mineração, blockchain. Onde você precisa fazer muitas contas. Se você tiver muito poder computacional, então você pode definir uma função como “calcular o hash de algo ali...” Mas você pode resolver o problema com armazenamento de dados usando, por exemplo, funções Lambda da Amazon e seu armazenamento distribuído. . E acontece que você está escrevendo um serviço regular. As funções Lambda acessarão o armazenamento e fornecerão algum tipo de resposta ao usuário.
Nicholas: os contêineres executados em Serverless são extremamente limitados em recursos. Há pouca memória e tudo mais. Mas se toda a sua infraestrutura estiver implantada inteiramente em alguma nuvem - Google, Amazon - e você tiver um contrato permanente com eles, há orçamento para tudo isso, então para algumas tarefas você pode usar contêineres Serverless. É preciso estar dentro dessa infraestrutura, pois tudo é feito sob medida para uso em um ambiente específico. Ou seja, se você estiver pronto para vincular tudo à infraestrutura em nuvem, poderá experimentar. A vantagem é que você não precisa gerenciar essa infraestrutura.
Arara: O fato de o Serverless não exigir que você gerencie Kubernetes, Docker, instale Kafka e assim por diante é um autoengano. A mesma Amazon e Google estão instalando isso. Outra coisa é que você tem um SLA. Você também pode terceirizar tudo em vez de codificá-lo sozinho.
Andrew: Serverless em si é barato, mas você tem que pagar muito por outros serviços da Amazon - por exemplo, o banco de dados. As pessoas já os processaram porque cobraram quantias absurdas de dinheiro pelo portão da API.
Arara: Se falamos de dinheiro, então é preciso levar em consideração este ponto: você terá que girar 180 graus toda a metodologia de desenvolvimento da empresa para transferir todo o código para Serverless. Isso exigirá muito tempo e dinheiro.
— Existem alternativas válidas para o Serverless pago da Amazon e do Google?
Nicholas: No Kubernetes, você inicia algum tipo de trabalho, ele é executado e morre - isso é bastante sem servidor do ponto de vista arquitetônico. Se você deseja criar uma lógica de negócios realmente interessante com filas e bancos de dados, então você precisa pensar um pouco mais sobre isso. Tudo isso pode ser resolvido sem sair do Kubernetes. Eu não me incomodaria em arrastar implementações adicionais.
— Quão importante é monitorar o que está acontecendo no Serverless?
Arara: Depende da arquitetura do sistema e dos requisitos de negócios. Essencialmente, o provedor deve fornecer relatórios que ajudem a equipe Devops a compreender possíveis problemas.
Nicholas: A Amazon possui o CloudWatch, onde todos os logs são transmitidos, inclusive os do Lambda. Integre o encaminhamento de log e use uma ferramenta separada para visualização, alertas e assim por diante. Você pode colocar agentes nos contêineres que iniciar.
- Vamos resumir.
Andrew: É útil pensar nas funções do Lambda. Se você criar um serviço por conta própria - não um microsserviço, mas um que escreve uma solicitação, acessa o banco de dados e envia uma resposta - a função Lambda resolve vários problemas: com multithreading, escalabilidade e assim por diante. Se sua lógica for construída dessa forma, no futuro você poderá transferir esses Lambdas para microsserviços ou usar serviços de terceiros como Amazon. A tecnologia é útil, a ideia é interessante. Até que ponto isso é justificado para os negócios ainda é uma questão em aberto.
Nikolay: Serverless é melhor usado para tarefas operacionais do que para calcular alguma lógica de negócios. Sempre penso nisso como processamento de eventos. Se você tiver na Amazon, se estiver no Kubernetes, sim. Caso contrário, você terá que se esforçar muito para colocar o Serverless em funcionamento por conta própria. É necessário analisar um caso de negócio específico. Por exemplo, uma das minhas tarefas agora é: quando os arquivos aparecem no disco em um determinado formato, preciso carregá-los no Kafka. Posso usar WatchDog ou Lambda. Do ponto de vista lógico, ambas as opções são adequadas, mas em termos de implementação, Serverless é mais complicado, e prefiro a forma mais simples, sem Lambda.
Arara: Serverless é uma ideia interessante, aplicável e tecnicamente muito bonita. Mais cedo ou mais tarde, a tecnologia chegará ao ponto em que qualquer função será lançada em menos de 100 milissegundos. Então, em princípio, não haverá dúvida se o tempo de espera é crítico para o usuário. Ao mesmo tempo, a aplicabilidade do Serverless, como os colegas já disseram, depende completamente do problema do negócio.
Agradecemos aos nossos patrocinadores que muito nos ajudaram:
- Espaço para conferências de TI «» para o local da conferência.
- Calendário de eventos de TI e publicação "» para suporte de informações e notícias.
- «"para presentes.
- para cocriação.
- "Associação para as Comunicações Eletrónicas" para envolvimento e experiência.
- Principal patrocinador - para todos!
Fonte: habr.com