Milhões de notícias são publicadas na internet todos os dias. Elas estão disponíveis em diferentes sites e em vários idiomas. Elas também precisam ser acessadas tão logo se tornem públicas devido à sua característica de expressar algo novo. Ter fácil acesso a elas em um único local facilita o trabalho de quem as usa no dia a dia. Captura-las, no entanto, requer o uso de tecnologia, de um tipo que saiba visitar sites, saltando de uma página para outra. Esse tipo de software é chamado de crawler, mas também é conhecido como robô. É ele quem caminha pelos links que vai encontrando à medida que navega na internet.
Um crawler foi o primeiro sistema que desenvolvemos quando fundamos a Knewin, em 2011. A sua primeira versão só coletava notícias de alguns sites. E cada site precisava ser configurado manualmente. Era necessário definir regras para ele navegar nos sites e entender quando havia encontrado uma notícia. Também era preciso codificar passo-a-passo de como extrair os dados de uma notícia — seu título, o autor, a data de publicação, o seu conteúdo, etc.
Tínhamos que utilizar infraestrutura que coubesse em nosso orçamento enxuto. Como startup, os recursos precisavam ser utilizados a sua exaustão. Um crawler demanda vasto poderio computacional, por isso tivemos que ser criativos ao desenvolver cada função. Usar o mínimo de memória, evitar sobrecarga nos processadores, controlar o consumo de banda da internet, armazenar apenas dados essenciais são alguns exemplos.
Além disso, o crawler precisava capturar uma notícia assim que ela era publicada. E encontrar novas notícias demandava acessar os sites com frequência. Havia o risco de ser bloqueado pelos administradores dos sites por que tínhamos que fazer requisições o tempo todo. Para minimizar esse risco, o crawler navegava em paralelo em vários sites, garantindo intervalos irregulares nos acessos aos sites.
O crawler foi hospedado em um ambiente de cloud computing, porém ele ainda não usava características desse tipo de ambiente (ex., escalabilidade, elasticidade, etc.). Como coletávamos notícias de poucos sites, não fazia sentido investir o nosso tempo para adaptar o crawler às funcionalidades da cloud — em uma startup o tempo dos empreendedores é o recurso mais significativo. Todavia, nos beneficiamos por hospedar na cloud quando precisamos escalar a solução.
Diversos problemas foram aparecendo à medida que fomos adicionando novos sites ao crawler. Tivemos uma situação onde um site permitia navegar nas suas páginas por meio de um calendário. Bastava selecionar um dia qualquer no calendário e o site apresentava a lista de notícias daquele dia. Foi exatamente assim que configuramos o crawler para capturar as suas notícias. No entanto, o crawler se caracteriza por navegar exaustivamente nas páginas de um site, entrando em cada link que ele encontra. No calendário do site não havia limite para anos futuros e não tínhamos configurado uma regra específica para isso. Quando o crawler entrava nesse site acabava caindo nessa armadilha e ficava tentando encontrar notícias selecionando datas futuras.
Nós sabíamos que o crawler poderia encontrar situações onde não tínhamos definido um comportamento específico e, obviamente, havíamos codificado regras genéricas de controle. No entanto, ainda assim tínhamos ineficiência no uso dos recursos computacionais. O servidor ficava ocupado, havia consumo desnecessário da banda de internet e, consequentemente, maior demora na coleta das notícias. Fomos amadurecendo a tecnologia à medida que situações não previstas foram aparecendo e refinando continuamente os mecanismos do crawler.
Com a adição constante de novos sites ficou claro, alguns meses após essa primeira versão, que o crawler não seria capaz de coletar maior volume de notícias sem gerar lentidão nas coletas (i.e., no máximo 10 minutos após a publicação). O crawler precisava evoluir e a nova solução precisaria ser distribuída, usando o conceito dividir para conquistar.
O crawler deveria executar em vários servidores, navegando paralelamente nos sites. Para implementar essa nova arquitetura precisávamos de uma tecnologia mais robusta e escalável. A tecnologia na época era o Hadoop, que estava sendo usado por grandes empresas. Hadoop é um framework que permite o processamento distribuído de grandes volumes de dados por meio de vários servidores. Conceitualmente, essa era a tecnologia que estávamos precisando, pois abstrai a comunicação entre os servidores, o que facilita a utilização de uma arquitetura distribuída — a interação entre os servidores é transparente para quem o utiliza.
A parte central do nosso crawler pôde ser aproveitada, o que nos economizou um bom tempo de desenvolvimento. Como já estávamos em um ambiente cloud ficou mais fácil a sua administração, uma vez que iniciar e encerrar servidores consistia apenas em alguns cliques. Tínhamos, contudo, que instalar e configurar o Hadoop manualmente por que naquela época não havia um serviço disponível na cloud.
Assim, nosso crawler passou de um servidor para cinco servidores; de dezenas de sites sendo coletados em paralelo para centenas. A nossa solução ficou apta a aumentar a quantidade de sites a serem coletados sem gerar lentidão na velocidade da captura das notícias. Conseguíamos adicionar novos servidores à medida em que acrescentávamos mais veículos. A nossa tecnologia passou a ser escalável.
O volume de notícias capturadas crescia consistentemente e centenas de novos sites eram adicionados por semana. O crawler capturava e armazenava as notícias em um banco de dados relacional. Todo fluxo de coleta estava sincronizado e atendendo aos nossos requisitos. Até que em um determinado momento, o desempenho geral começou a degradar e nossos alarmes começaram a disparar. O vilão da vez foi o banco de dados. Ele já não suportava armazenar as notícias com a velocidade esperada. Tivemos, novamente, que intervir e repensar a tecnologia para armazenar as notícias.
A vantagem de estarmos em um ambiente cloud desde o primeiro dia (reforço esse ponto, pois tivemos inúmeras vantagens quando tomamos essa decisão) nos permitiu evoluir nossos sistemas à medida que novos serviços eram disponibilizados pelo respectivo fornecedor da cloud. A tecnologia NO-SQL ganhava corpo justamente para dar suporte ao conceito de big data, com estrutura computacional capaz de armazenar grandes massas de dados com alta performance.
Movemos parte das estruturas que estavam no banco de dados relacional para essa base NO-SQL e alteramos o fluxo de processamento do crawler para enviar as notícias capturadas para essa nova estrutura. Com isso, obtivemos maior velocidade para armazenar e recuperar as notícias. Também podíamos usufruir da capacidade ilimitada de armazenamento e pagar apenas por aquilo que estávamos consumindo. Mais um passo de maturidade na arquitetura, maior robustez na solução, maior controle sobre o custo de armazenamento, melhor experiência de uso das nossas ferramentas e mais segurança para os nossos clientes.
Por mais que tivéssemos uma série de vantagens em estarmos na cloud, a conta estava subindo a cada mês. Nossa solução era robusta e escalável, mas a dimensão custo estava impactando nosso orçamento de infraestrutura. A principal causa eram os novos servidores que tínhamos que acrescentar à medida que novas fontes eram adicionadas ao crawler. A necessidade de recorrência em capturar as notícias dos sites, com a pressão de coletarmos as notícias com o mínimo de tempo após a publicação nos forçou, novamente, a repensar a arquitetura ou, pelo menos, parte dela.
Hadoop ainda estava na crista da onda do big data, mas algumas tecnologias com propósito similares já estavam aparecendo e o principal diferencial consistia em maior leveza — arquiteturas que demandavam menor poder computacional. Naturalmente, inúmeras dúvidas apareciam quando discutíamos uma eventual saída do Hadoop, pois toda a arquitetura do crawler havia sido estabilizada e havíamos definido um procedimento simples e facilmente escalável. O problema é que a conta não parava de subir.
Havia mais de três anos que lidávamos com Hadoop em nosso dia-a-dia e o conhecimento adquirido nesse período nos permitiu entender no detalhe a sua arquitetura. Uma coisa estava clara: apenas servidores de média ou alta configuração para obter bom desempenho. Isso nos limitava em usar servidores menores e mais em conta ou, até mesmo, a combinação de servidores com diferentes configurações. O cenário de coleta e a arquitetura de navegação do crawler nos permitia usar servidores menores, mas estávamos travados por que o Hadoop não se comportava bem. Além disso, tínhamos o cenário em que o volume de matérias publicadas era reduzido em determinados horários e podíamos, assim, reduzir o nosso custo (ex., alguns servidores poderiam ser parados durante à noite). Fomos obrigados a estudar alternativas, inclusive cenários onde tínhamos que implementar toda a distribuição e interação entre os servidores por nossa conta.
Por fim, a arquitetura definida para a nova versão do crawler foi uma mescla de bibliotecas open source e sistemas desenvolvidos por nós. Também utilizamos alguns serviços oferecidos pela infraestrutura de cloud onde hospedamos nossa solução. Saímos de um ambiente com ingerência, onde estávamos tendo pouco controle, para um cenário flexível que nos permitia uma dinâmica de crescimento com custo adequado. Com essa nova arquitetura, implementamos regras para ampliação e redução do poderio computacional de forma a garantir que as variáveis velocidade na coleta, abrangência (i.e., maior volume de sites monitorados) e custo ficassem sintonizadas e previsíveis.
Tínhamos, então, uma arquitetura de crawler que implementava a elasticidade similar aos ambientes cloud. Automatizamos o acréscimo e redução de servidores em tempo real. Em questão de minutos o mecanismo de decisão do crawler acrescentava ou removia centenas de servidores. A decisão de sairmos de um ambiente “fechado” como o Hadoop para uma arquitetura mais flexível nos permitiu evoluir vários pontos de gargalos na solução.
Hoje, essa arquitetura é muito mais complexa e implementa uma série de novas funcionalidades. As variáveis de abrangência, velocidade e custo ainda são verdades absolutas e têm tanta importância que temos alarmes que disparam em caso de qualquer comportamento anormal. Com o volume de notícias crescendo a cada dia — coletamos mais de um milhão de notícias por dia atualmente — e novas fontes noticiosas sendo adicionadas aos milhares, tivemos que ser criativos nas soluções para os diferentes cenários que fomos nos deparando.
Não temos apenas um crawler, mas uma plataforma com múltiplas soluções de coleta de notícias que levam em consideração, por exemplo, a natureza da fonte a ser coletada, a frequência com que as notícias são publicadas, os modelos de estruturação de conteúdo, a localização geográfica dos veículos, além de outros tantos requisitos funcionais e não-funcionais. Nossa infraestrutura mescla recursos computacionais hospedados em diferentes fornecedores (cloud e tradicional) além de um conjunto de servidores que ficam em nossa própria infraestrutura.
Além disso, temos a habilidade de utilizar servidores com “qualquer” sistema operacional, pois desenvolvemos a maioria dos nossos componentes na linguagem Java. Enfim, essa plataforma é o resultado da soma do aprendizado desses anos focados em coletar informações e torna-las acessíveis para os nossos clientes.
Os desafios ainda são inúmeros. Há muito de inteligência que iremos adicionar aos mecanismos de coleta, uma série de automatizações que já temos detalhadamente descritas e outras tantas melhorias que já identificamos — algumas delas estão em andamento. Por exemplo, faremos o uso massivo de inteligência artificial, mais especificamente dos algoritmos de machine learning, em todas as etapas de coleta.
Com isso, a nossa solução terá maior eficiência ao navegar entre as páginas dos sites e conseguirá estruturar e extrair as informações com maior precisão e velocidade. Também conseguirá melhor aproveitar os recursos computacionais assim como otimizar a troca de dados entre os diversos mecanismos da plataforma. Ademais, o custo total da solução será avaliado a cada segundo e mecanismos inteligentes tomarão decisões em tempo real para garantir o melhor desempenho com o menor custo.
Para nossa sorte, o backlog de inovações a serem desenvolvidas compreende uma lista considerável. Só conseguimos identificar essas “deficiências”, obviamente, por que temos anos de experiência e conhecimentos adquiridos em muitas horas de trabalho. Nós construímos a Knewin reforçando o interesse contínuo em novidades científicas e tecnológicas. Como uma empresa de tecnologia, está em nosso DNA buscar continuamente melhorias e novos desafios. Há muito a inovar e isso é um grande motivador.
Novas postagens no endereço fbeppler.com.