DoorDash Sibyl (serviço de predição)

01 · CONTEXTO

Um serviço de predição para toda a plataforma

A plataforma do DoorDash usa dados para alimentar modelos que curam resultados de busca, atribuem entregadores e reconhecem fraude. Esses modelos servem vários microsserviços que dependem de previsões orientadas a dados, o que exige um serviço de predição robusto.

O Sibyl foi desenhado para cuidar de todas as predições em tempo real e focar em prever. Cálculo de features, pipelines de treino e armazenamento de features e modelos ficam em outros serviços e repositórios.

A expectativa era de centenas de milhares de predições por segundo. Além disso, para convencer outros serviços a chamá-lo, o Sibyl precisava ser tão rápido que chamá-lo fosse melhor do que cada serviço fazer suas próprias predições.

02 · ARQUITETURA

O ciclo de vida de uma requisição

Os clientes falam com o Sibyl por gRPC. O serviço obtém modelos e features de repositórios independentes e pode, opcionalmente, enviar as predições ao Snowflake para avaliação offline. O percurso abaixo segue uma requisição típica.

1. Um serviço cliente envia a requisição por gRPC, com um ou mais conjuntos de features para prever.

2. Para cada modelo da requisição, o Sibyl pega o modelo e a configuração dele (features exigidas, valores padrão e tipo) num cache em memória, carregado quando o serviço iniciou.

3. O serviço procura valores de features que não vieram na requisição, para todos os modelos e conjuntos de uma só vez.

4. Cada feature ausente é buscada no feature store, um cache Redis; se ainda assim não existir, vale o valor padrão da configuração do modelo.

5. Com todas as features reunidas, o Sibyl faz uma predição assíncrona por conjunto e dispara uma corrotina por modelo shadow, sem esperar o término delas.

6. Por fim, monta o objeto protobuf com as predições e o devolve ao cliente.

O post menciona ainda, como expansão futura possível, um avaliador de modelos separado para o cálculo de predição de modelos complexos; na versão inicial, essa função ficaria dentro do próprio Sibyl.

03 · DECISÕES DE IMPLEMENTAÇÃO

Velocidade vem de código nativo, paralelismo e cache

Para otimizar a velocidade, os modelos são guardados no formato nativo e as chamadas de predição aos frameworks são feitas em C++. O serviço, escrito em Kotlin, usa a Java Native Interface (JNI) para chamar as predições de LightGBM e PyTorch implementadas em C++.

Outra prioridade era que as predições rodassem em paralelo e que, enquanto as features eram buscadas, as threads estivessem fazendo cálculos. As corrotinas do Kotlin ajudam nisso: não ficam presas a uma thread e se suspendem enquanto esperam, liberando a thread para outro trabalho.

Os modelos são buscados quando o serviço inicia e mantidos em cache em memória, sem precisar ser carregados a cada requisição. As features, ao contrário, são buscadas a cada predição.

04 · LOTES E SHADOW

Predições em lote e modelos candidatos

Cada requisição pode trazer um número variável de conjuntos de features. Predições em lote permitem enviar e receber de 1 a N predições de uma vez, o que reduz muito o número de chamadas.

Com shadow predictions, uma equipe usa um modelo para as predições oficiais e, de forma assíncrona, prevê os mesmos dados com outros modelos. Assim dá para analisar a eficácia dos candidatos sem trocar o modelo oficial.

Para o teste, o time dividiu a requisição com todas as lojas em lotes de tamanho razoável. O tamanho ótimo ficou em torno de 100 a 200 lojas, e lotes de 10 e 20 lojas pioraram a latência. A comparação abaixo resume o que o post observou e as hipóteses do time.

O time também avaliou comprimir as requisições, para reduzir o número de pacotes na rede.

05 · ROLLOUT

Do teste de carga à produção

No serviço de busca, todo restaurante exibido precisa ser pontuado e ranqueado antes. O post usa esse serviço, um dos mais demandados da empresa, como base do teste de carga.

1. No teste de carga, quando o serviço de busca ia ranquear um restaurante com sua lógica própria, disparava também uma thread assíncrona que chamava o Sibyl.

2. As chamadas assíncronas não deixavam lentos os endpoints da busca, e o resultado devolvido pelo Sibyl nunca era usado.

3. Nesse teste, o Sibyl tratou mais de 100.000 predições por segundo.

4. A produção começou por modelos de fraude e de pagamento de entregadores, com QPS estimado menor e latência menos estrita.

5. A busca não foi das primeiras a migrar: seus modelos exigiriam ainda migrar os valores de features para o feature store do Sibyl.

O post foi publicado em 29 de junho de 2020 e diz que, desde março daquele ano, os modelos de fraude e de pagamento de entregadores usam oficialmente o Sibyl. Após a adoção, o time observou queda de latência de 3x em relação ao serviço de predição antigo.

Segundo o post, a migração estava perto de terminar: todos os modelos, exceto cinco, já chamavam o Sibyl. O time continuava adicionando suporte a diferentes tipos de features e de modelos, como embedded features, usadas principalmente em redes neurais, e modelos compostos, que são cadeias de submodelos e expressões chamadas compute nodes.