Como oito pessoas escalam um projeto de alta carga. Experiência Unsplash

Foto: Alex Smith | Unsplash

Boa tarde

Meu nome é Victor Pryazhnikov, trabalho no departamento de Recursos do Badoo . A principal tarefa do nosso departamento é desenvolver a funcionalidade que os usuários do nosso site e aplicativos veem. Quando me deparei com um artigo do co-fundador da Unsplash, Luke Chesser, ela me intrigou com o fato de eles conseguirem desenvolver um projeto relativamente grande com uma equipe muito pequena. A abordagem do autor me impressiona com seu pragmatismo e, de alguma forma, lembrei que você não é o Google , então decidi traduzi-lo.

Uma das coisas mais engraçadas do desenvolvimento do Unsplash é a enorme escala e popularidade do produto.

Em um dia típico, nossa API processa mais de 10 milhões de solicitações do unsplash.com e milhares de aplicativos de terceiros, milhões de eventos passam pelo nosso pipeline de processamento de dados, 60 milhões de atualizações são adicionadas aos nossos feeds e servimos 60 milhões de imagens.

Ao mesmo tempo, nossa equipe é relativamente pequena: dois designers, três pessoas trabalhando com o front-end, dois com o back-end e um engenheiro de dados. Não temos um engenheiro de DevOps separado, e cada membro da equipe passa a maior parte do tempo experimentando e desenvolvendo novos recursos para garantir o desenvolvimento do produto.

Embora já tenhamos conseguido muito com a Unsplash, ainda estamos no começo de sua jornada como produto e negócio. Ainda temos algo a provar, e isso significa que toda a equipe precisa se concentrar na solução de problemas exclusivos do Unsplash, e não nos de qualquer outra empresa, como organização de cálculos, segurança de rede, infraestrutura de construção, gerenciamento dependências etc.

Nos últimos três anos, desenvolvemos um conjunto de princípios que nos permitem focar no crescimento e evitar problemas de escala. Infelizmente para quem procura uma bala de prata, ela não estará aqui: é apenas senso comum e um conjunto de princípios que emprestamos de outras pessoas.

1. Use soluções óbvias chatas

Ou seja pragmático.

Antes de iniciar a introdução de uma nova ferramenta, um banco de dados (RethinkDB, RocksDB, etc.), um novo padrão ("tudo está funcional!") Ou uma nova arquitetura ("microsserviços, ajuda!"), Tente todas as opções óbvias.

No lado de back-end, existem pouquíssimos problemas que não podem ser resolvidos com eficácia usando ferramentas padrão e conhecidas e padrões comprovados, como cache, processamento em lote, processamento assíncrono e preparação preliminar dos dados necessários.

2. Foco na resolução de problemas do usuário, não na tecnologia

Unsplash é um produto, não uma empresa de tecnologia. Recebemos muito dinheiro dos investidores para focar na solução dos problemas de nosso produto e mercado, em vez de tentar obter uma redução de três por cento nos custos operacionais para o uso de tecnologias comuns.
Nós gastamos nosso tempo usando tecnologias prontas de uma maneira que ajude a resolver os problemas de nossos usuários e a aumentar a comunidade Unsplash. Essas são tarefas exclusivas da Unsplash e, se conseguirmos criar algo novo e valioso, podemos adiar a otimização para uma data posterior, quando essas otimizações de 3% puderem se tornar a principal fonte de crescimento.

Nossos colegas em potencial que ouviram falar da escala do Unsplash e de uma pequena equipe, o uso de imagens e inteligência artificial, recursos futuros, podem ficar confusos pelo fato de usarmos muitas tecnologias, serviços e estruturas prontas para o uso. Isso nos faz pagar um pouco mais agora, mas nos permite adiar o desenvolvimento interno dessas tecnologias por algum tempo e transferi-lo para os ombros de nossos futuros colegas.

O processo de organização do código, configuração de servidores, dependências do sistema, processamento e análise de dados, processamento e personalização de imagens são exemplos de áreas que optamos por não focar em nossos recursos de engenharia, mas em usar serviços de terceiros prontos para cada um deles.

3. Gastar dinheiro na solução de problemas tecnológicos

O outro lado do foco em questões de produto é o custo adicional de acesso a tecnologias prontas para uso e serviços de terceiros.

Isso se tornou uma piada dentro da nossa equipe. Dizem que minha primeira reação a qualquer problema será a pergunta: "Você tentou resolvê-lo com dinheiro?". Mas isso não é uma piada, mas uma das minhas abordagens favoritas para resolver problemas.

A otimização dos custos associados à infraestrutura e à tecnologia é um problema tão comum em soluções simples e repetitivas que nenhuma empresa de produtos com investidores deve cuidar disso até sentir que o crescimento da métrica principal deixou de ser sua prioridade.

Quando gastamos dinheiro na solução de problemas tecnológicos, desamarramos as mãos da equipe, permitindo que ela se concentre em problemas complexos recorrentes, como encontrar uma maneira de aumentar o tamanho da base de usuários em 40% no trimestre atual.

---

Portanto, esses são três princípios bastante simples, mas abstratos que seguimos.

Mas como eles se parecem na prática?

Se você observar a arquitetura Unsplash, verá que ela é muito simples e quase chata (pelo menos para os padrões de 2017).


Um diagrama simplificado das principais partes que compõem o Unsplash

Utilizamos o Heroku sempre que possível para simplificar o layout, a configuração, os testes, o suporte e o dimensionamento de nossos aplicativos principais. Heroku é um tipo de mágica que separa as partes do aplicativo e do processo de desenvolvimento, para que os membros da nossa equipe não precisem se familiarizar com ele para desenvolver e apresentar experimentos.

Minimizamos agressivamente a quantidade de código que escrevemos para a lógica comercial do aplicativo (áreas roxas na imagem). Ao escrevê-lo, usamos ativamente estruturas criadas por outras pessoas que, como especialistas em suas áreas, desenvolveram soluções que funcionam com sucesso em 95% de nossos casos de uso.

Utilizamos ativamente Redis, Elasticsearch e Postgres na produção. No passado, tentamos outros bancos de dados, mas sempre retornamos a esses três, porque temos certeza de que entendemos como eles se comportam sob carga.

Também usamos ativamente filas de tarefas, processando de forma assíncrona muitas operações, como atualização, agregação e sincronização de dados entre diferentes fontes.

Para o processamento de dados, usamos o Snowplow , uma estrutura integrada aberta escrita em Scala, que elimina a necessidade de nossa equipe pensar em organizar entradas e saídas, e não no próprio processamento.

Também usamos todo um conjunto de serviços de monitoramento em nuvem, como Datadog , New Relic , Sentry e Logentries , em vez de implantar e manter nossa própria pilha StatsD ou ELK.

Terceirizamos a hospedagem e a infraestrutura para entregar nossas imagens à imgix , uma empresa líder no trabalho com imagens dinâmicas. Se eles adicionarem uma nova funcionalidade, nossa equipe fará uma alteração no URL - e nossos usuários também terão acesso a essa funcionalidade.

Registramos todas as ações de nossos usuários no serviço Stream , usando sua experiência na criação e otimização de fitas pessoais altamente carregadas. O Stream simplifica o processamento de bilhões de ações para nós e fornece uma API simples para entrada e saída, que funciona com tanta produtividade que nossa equipe gastaria meses ou até anos para criar por conta própria.

Nós não treinamos os algoritmos de reconhecimento de imagem, mas usamos o TinEye para pesquisas reversas de imagens e o Google Vision para reconhecimento e classificação de imagens.

Registramos todos os eventos comportamentais no Vero , uma plataforma para trabalhar com notificações e listas de discussão, o que nos permite transferir o trabalho com eles para as mãos de nossos colegas que não são desenvolvedores. Eles mesmos podem criar cartas com um alto nível de personalização, com base no uso complexo dos dados disponíveis sobre o comportamento do usuário.

---

Ao mesmo tempo, estamos nos concentrando nas partes do Unsplash que podem fornecer uma melhoria em nossa competência principal.

No ano passado, dividimos nosso único aplicativo Ruby on Rails na API Rails, o aplicativo web Node.js. + React, e criamos um aplicativo de dados separado que coleta e processa todas as nossas métricas internas e de produtos.

Isso permitiu à nossa equipe criar funcionalidades que pareciam quase impossíveis em nossa pilha antiga, consistindo apenas em Rails. Tendo compartilhado os problemas e tecnologias de nossos aplicativos, nossa equipe também teve a oportunidade de usar as melhores ferramentas em cada uma das áreas:

• No front-end, usamos o React e o Webpack junto com um pequeno servidor Express para suportar solicitações de API de renderização e proxy de servidor. Intencionalmente, não vinculamos as ferramentas de nossa equipe de front-end ao back-end com hacks temporários, como react -rails ou webpacker . A comunidade JavaScript, sem dúvida, lança as melhores ferramentas para trabalhar com o front-end, portanto, trabalhar diretamente com JavaScript permite que nossa equipe entregue rapidamente aos usuários uma funcionalidade de alta qualidade.
  
• No back-end, nossa equipe continua usando a melhor estrutura para o desenvolvimento de aplicativos Web simples: Rails. O ecossistema Ruby on Rails oferece as melhores ferramentas para a funcionalidade no back-end e, como essa estrutura é amplamente usada, qualquer problema com ela já foi encontrado por alguém, documentado e com um alto grau de probabilidade, já existe uma solução para ela.
  
• No lado dos dados, nossa equipe usa um pequeno servidor Express para coletar e organizar o processamento de dados. O próprio processamento ocorre no Snowplow, que é executado no cluster da AWS, onde há imagens prontas para ele que simplificam a configuração e a implantação. Isso permite que nosso único engenheiro de dados, Tim, passe a maior parte do tempo transferindo dados para o Snowplow e obtendo os resultados a partir de uma maneira que facilite a compreensão e a compreensão de outros membros da equipe.
  

Estamos ativamente envolvidos em escrever testes , medindo o desempenho usando ferramentas como Scientist e Datadog, estabelecendo mudanças na forma de experimentos e automatizando o trabalho com nossa infraestrutura , tanto quanto possível.

Estamos desenvolvendo uma nova API interna baseada no GraphQL para acelerar iterações de experimentos, novos recursos e produtos que não dependem um do outro, desde que percebemos que nossa API baseada em REST falha sem um alto nível de coordenação entre as equipes de dados, design, front-end e back-end - melhor gastaremos esse tempo em recursos, não em alterações JSON.

Embora seja interessante trabalhar nessas alterações, não as fazemos porque queremos atenuar a coceira do programador, mas porque resolve nossos problemas reais que nos impedem de fornecer funcionalidade e desenvolvimento rapidamente.

Eu acho que a maioria das pessoas que leu esse lugar tem uma de três conclusões:

1. A remoção da mancha é muito simples, portanto você pode usar essa abordagem. O que eu faço é muito mais complicado, então somos forçados a fazer as coisas de maneira diferente.
   
2. Eu sou desenvolvedor. Parece muito chato - eu quero criar um novo sistema de reconhecimento de imagens de alta carga!
   
3. Legal! Não me importo, apenas me dê lindas fotos gratuitas que eu possa usar.
   

Pessoas com a conclusão número 1, você está certo: existem empresas que fazem coisas muito mais complexas do que nós. Mas não há muitos deles. Todos criamos os mesmos sistemas, mas focados em algumas outras coisas, e é por isso que as soluções usadas podem ser abstraídas na forma de frameworks e reutilizadas em diferentes projetos (portanto, a maioria das postagens sobre contratação é muito parecida).

Pessoas com a conclusão número 2, depende do que você achar interessante. Se você deseja ultrapassar os limites da tecnologia, trabalhe para uma empresa cuja missão é fazer isso. Não existem muitos, mas a maioria das outras empresas simplesmente não faz isso.

Para as pessoas com a conclusão número 3, direi: "Sim, está certo!" No final, é para isso que estamos fazendo tudo isso.

O Badoo está próximo dos princípios sobre os quais o autor fala. A principal diferença é que nosso projeto é muito maior e o uso de serviços externos para nós geralmente é muito caro. Além disso, muitas de nossas soluções são muito simples e tentamos abordar cuidadosamente suas alterações comparando o custo de introdução e operação de uma nova tecnologia com os benefícios que receberemos dela. Algumas de nossas soluções são bastante antiquadas, desde que foram criadas há algum tempo, mas mudar para novas similares apenas por uma questão de moda não pagará pelos recursos gastos nela. Ao mesmo tempo, estamos prontos para introduzir novas tecnologias, se entendermos que elas podem trazer benefícios reais (por exemplo, PHP 7 , Go , Cassandra , Tarantool , Exasol ).