Reestruturação da plataforma Querido Diário

[jvanz]

Nas últimas semanas tenho conversado com algumas pessoas sobre a intenção de reestruturar a plataforma de processamento e disponibilização dos diários cobertos pelo Querido Diário. Estou abrindo essa discussão para demais membros da comunidade terem a oportunidade para trazer ideias e encontrar falhas.

Metas

Uma plataforma que fornece os meios necessários para rodar os apps no processamento dos diários oficiais do Querido Diário. Para isso vamos começar com o objetivo final e depois traçar o caminho para chegar até ele (a.k.a. backcasting).

O objetivo é ter uma plataforma que seja fácil de manutenção, alteração e ampliação. Englobando:

• Maneiras automatizadas para expandir ou diminuir a infra estrutura para rodar toda a plataforma.
• Disponibilizar uma plataforma unificada onde os apps de processamento dos diários oficiais não precisem se preocupar onde serão rodados ou, pelo menos, abstraindo boa parte da complexidade de colocar o app em produção.
• Fornecer infraestrutura para comunicação entre app diferentes. Facilitando assim a criação de pipelines de processamento de dados ou criação de outros tipo dos applicações sobre a mesma infraestrutura.

A seguinte imagen é um exemplo do que poderiamos tentar criar. Lembre-se, é apenas um exemplo para começar a conversa. Não tem detalhes.

Propostas iniciais de alterações

Raspadores

• Associar link para página inicial do site de publicação de diários (fonte) aos itens baixados (talvez usar os dados do censo?)
• Fazer deploy automático

API

• Acredito que devemos colocar para rodar no K8s
• Integrar com os dados do Censo em uma base de dados decente (remover aquela gambi do CSV)
• Migrar a base de dados atual que roda no PostgreSQL do Serenata para o banco do serviço da Digital Ocean
• Teste de carga.
• Disponibilizar link para fonte dos dados

Processamento de dados

• Definir qual plataforma será utilizada para gerenciar os app de processamento de texto. Iremos utilizar algo como Apache Airflow ou semelhante? Podemos, por exemplo, usar puramente k8s com kafka para criar as apps e etc. Mas acredito que esse tipo de ferramenta (Airflow) pode ser utilizada em pipeline mais complexos e pode ajudar a dar visibilidade ao pipeline como um todo. Por isso, acredito que devemos utilizar esse tipo de ferramentas.
• Colocar um Apache Kafka para rodar em nossa infra. Podendo ser utilizado na comunicação entre app que processem os dados sem acoplar essas app entre si. Podemos criar uma arquitetura de pub/sub no processamento dos dados.
• Ter um bom sistema de monitoramento do pipeline. Saber quando um documento começou a ser processado, todo os processos que passou durante o processamento e os dados finais gerados.
• Definir procedimento de como fazer o deploy dos jobs/app em produção de maneira mais automatizada possível.

Plataforma de busca

• Precisamos pensar mais sobre acessibilidade
• Por hora, utilizar o máximo de features possível disponíveis no ElasticSearch.

Infraestrutura

O resumo aqui é: minizar o máximo possível o tempo gasto para resolver coisas simples que máquinas podem fazer por conta própria. Por exemplo, fazer ssh em um máquina para subir algo que caiu. Devemos utilizar o tempo dos nossos contribuidores em coisas que gerem valor para o projeto.

• Toda a infra deve ser gerenciada por scripts. Permitindo assim uma fácil reprodução do ambiente, automação e facilidade de alteração.

• Utilizar Terraform para subir toda a infra para rodar nossos apps. Outras sugestões de ferramentas? Se a ferramenta de escolha for mesmo Terraform, precisamos definir onde iremos guardar o estado da infraestrutura. Dessa maneira, permitimos que múltiplas pessoas trabalhem nisso juntas. Possíveis soluções são o Digital Ocean Spaces ou uma base PostgreSQL. É necessário analisar quais as vantagens e desvantagens de cada opção.

• Utilizar o máximo de serviços da Digital Ocean para facilitar a manutenção da plataforma do QD. Esses serviços também devem ser criados utilizando Terraform ou script que sejam automatizados. Sugestões de serviços a serem utilizados:

  • Kubernetes
  • PostgreSQL
  • DIgital Ocean Spaces (já em uso)
  • Load balancer (creio que vai ser obrigatório, já que vamos utilizar o Kubernetes)
  • DNS: podemos gerenciar nossos domínios de maneira automatizada.

• Utilizar scripts/terraform para gerenciar serviços que possamos disponibilizar para nossos apps. Por exemplo, Kafka, RabbitMQ, Apache Spark, Elasticsearch, ou qualquer outro app que não seja desenvolvido por nosso time diretamente.

[rennerocha]

@jvanz
Sobre a execução dos raspadores, eu fiz o merge de okfn-brasil/querido-diario#388 hoje e com uma configuração extra aqui no Github já será possível o deploy automático dos spiders na Scrapy Cloud, removendo a necessidade de intervenção manual. Ainda está pendente a configuração do agendamento das execuções. Com isso, acho que a parte da execução deles fica resolvida e facilmente escalável se necessário, já que não precisamos manter a infra para rodar eles. Como já temos os pipelines de dados, onde eles serão processados em seguida é indiferente de onde eles foram extraídos.

Sobre o restante da arquitetura não vou opiniar pq não estou envolvido nessas discussões e não estou conseguindo tempo para me inteirar :-)

[jvanz]

Criei uma projeto para agruparmos as tarefas relacionadas a essa reestruturação: https://github.com/orgs/okfn-brasil/projects/2

[jvanz]

Esse board foi fechado. Vamos dar prioridade para o novo board disponivel no github. https://github.com/orgs/okfn-brasil/projects/3/views/1

[ogecece]

Eu acho que por enquanto esse tipo de board ainda não consegue ficar público @jvanz