O SpiderDuck, é um novo serviço do Twitter para gerenciar e otimizar o processamento em tempo real de URLs inseridos em tweets. Foi projetado com 6 componentes principais, distribuindo a responsabilidade de consultar, processar e armazenar as informações das URLs. A arquitetura do sistema tem o foco em reduzir o tempo de resposta e a latência do tráfego de dados, além de permitir o aumento em escala conforme o crescimento da demanda.
Links em tweets devem ser processados pelo Twitter quanto ao tipo e a relevância do conteúdo referenciado. Caso a URL aponte para uma foto ou vídeo, por exemplo os aplicativos do lado do cliente (web, mobile etc.) precisam apresentar a mídia correspondente junto ao texto do tweet. Os links também são processados pelo módulo de segurança, que verifica a presença de malware no endereço referenciado, entre outras coisas, e os "Tweet Buttons" contabilizam o número de compartilhamentos de cada link.
Antes do SpiderDuck o Twitter usava um serviço mais simples para análise de URLs compartilhadas, fazendo requisições via HEAD e eventuais redirecionamentos. Mas essa solução apresentava algumas limitações:
- O serviço resolvia o endereçamento da URL, mas não realizava o download do conteúdo. As informações sobre a resolução da URL não eram persistidas em disco, permanecendo apenas em memória, no cache. Caso uma instância do cache ficasse fora do ar, os dados seriam perdidos.
- O serviço também não leva em conta regras para bots modernos, como limitação da taxa de transferência; também não seguia diretivas do controlador de buscas de robots (robots.txt).
O time de engenheiros do Twitter chegou à conclusão que seria necessário desenvolver um serviço mais sofisticado para processamento de URLs, que atendesse à necessidade da empresa no longo prazo:
Nossa primeira ideia foi construir o sistema em cima de um crawler existente, que fosse open source. Mas percebemos que todos os crawlers disponíveis possuem duas características de que não precisávamos: os crawlers realizam a leitura de URLs de forma recursiva o que aumenta sua complexidade; além disso, são otimizados para a leitura em grande escala, e precisávamos de algo mais leve, capaz de fazer a leitura de URLs em tempo real. Decidimos então criar um novo sistema que atendesse às necessidades específicas do Twitter.
O SpiderDuck utiliza algumas soluções open source já adotadas em outros serviços do Twitter, como o agregador de conteúdo Scribe; o Finagle, um protocolo RPC criado para realizar o tráfego intenso de dados; e o Twitter Commons, um conjunto de bibliotecas que opera sobre a JVM.
Arquitetura
A arquitetura do SpiderDuck é modular (veja a figura), o que contribui para a escalabilidade do serviço.
Componentes do SpiderDuck (fonte: Twitter)
O SpiderDuck é composto por seis módulos principais:
- Kestrel. Sistema de mensageria utilizado no Twitter para enfileiramento dos tweets mais recentes. O Kestrel é o ponto de partida do SpiderDuck, assim que recebe um tweet contendo uma URL, solicita a busca das informações dessa URL para outro módulo, o Scheduler.
- Schedulers. Determinam se a busca do conteúdo da URL deve ser agendada ou não, e caso necessário faz o redirecionamento da URL. Esse módulo realiza o parse e o download do conteúdo, extrai os metadados e armazena toda essa informação em duas estruturas de armazenamento do sistema, o Metadata Store e o Content Store. Cada schedule trabalha de forma independente, permitindo que novos schedulers sejam adicionados, favorecendo a escalabilidade horizontal do sistema.
- Fetchers. Componente que realiza a requisição HTTP em busca do conteúdo da URL. São implementados com servidores Thrift, com inteligência para tratar os limites de taxa de transferência e reconhecer as diretivas do controlador de buscas via bots, resolvendo umas das principais limitações da solução anteriormente usada.
- Memcached. Um cache distribuído utilizado pelo Fetcher para armazenar temporariamente as informações dos arquivos robots.txt.
- Metadata Store. Distribuição customizada do Cassandra que permite armazenar informações sobre a resolução e os metadados da URL. Essas informações são mantidas em uma tabela de hash, utilizando a URL como chave. O repositório é utilizado pelos aplicativos cliente do Twitter, para consumir informações da URL em tempo real.
- Content Store. Um cluster com Hadoop Distributed File System (HDFS), um sistema para replicação de dados distribuídos extremamente rápido, que formam o repositório com o conteúdo de todas as URLs processadas.
Performance
A separação entre o Schedulers e os Fetchers permite que múltiplos tweets com a mesma URL sejam processados somente uma vez. Isso reduz a latência e aumenta a velocidade no processamento. Veja o que dizem sobre isso os engenheiros do projeto:
O SpiderDuck processa centenas de URLs a cada segundo, e o Metadata Store trata perto de 10 mil requisições por segundo. Normalmente cada requisição é realizada para uma URL especifica, sendo possível uma requisição para um lote de até 300 URLs ao mesmo tempo.
Para processar uma nova URL, que ainda não foi armazenada pelo SpiderDuck, partindo da criação do tweet e indo até a requisição externa e o armazenamento dos dados, o sistema gasta em média cinco segundos de processamento. A maior parte desse tempo é consumida no Fetcher, no momento em que o sistema extrai as informações da URL em um site externo.
Quando um novo tweet menciona uma URL que foi armazenada pelo SpiderDuck, o tempo para processar as informações da URL se reduz para dois segundos em média. Ou seja, uma aplicação cliente do Twitter tem de esperar por dois segundos para obter todas as informações da URL. E boa parte das 10 mil requisições por segundo recebidas pelo Metadata Store trata de consultas que em média, levam de quatro a cinco milissegundos de processamento.
Integração
Os serviços do Twitter consomem dados do SpiderDuck de várias maneiras; a mais frequente é a busca de informações complementares (metadados e resolução) da URL no Metadata Store. Outros serviços acessam os logs do SpiderDuck no HDFS para agregar informações utilizadas pelos sistemas de analise e métricas internas, o dashboard do Twitter.
No SpiderDuck serviços não solicitam o processamento de uma URL. O próprio sistema resolve e processa o conteúdo das URLs de tweets recentes. Após processar as URLs o sistema disponibiliza as informações para consumo dos serviços.
Conclusões
Uma forma efetiva para gerenciar URLs é apenas um dos desafios da do Twitter, que vem fazendo muanças constantes em arquitetura e tecnologias (como já reportamos aqui). Através do blog de engenharia do Twitter e da conta @twittereng, os engenheiros do Twitter compartilham um pouco sobre esses desafios, apresentando informações e estratégias relacionadas a arquitetura do serviço.