Shopify: pods e flash sales da Black Friday

01 · CONTEXTO

Quando comprar um banco maior deixa de ser opção

Em 2015 a Shopify chegou ao ponto em que não era mais possível comprar um servidor de banco de dados maior. A saída foi dividir o banco em shards, o que permitiu escalar na horizontal e continuar crescendo.

O preço foi a resiliência: o que se ganhou em desempenho e escala se perdeu em tolerância a falhas. O motivo estava no código, que em vários pontos executava uma ação em cada shard. Se qualquer shard caísse, a ação inteira ficava indisponível na plataforma toda, e a equipe previu que isso viraria um problema grave conforme o número de shards crescesse.

1. Compradores de lojas diferentes chegam aos mesmos servidores de aplicação.

2. Uma ação que percorre todos os shards consulta cada um deles antes de responder.

3. Um shard cai: a ação inteira fica indisponível para toda a plataforma, mesmo com os outros shards saudáveis.

02 · PODS

Isolar o shard inteiro, não só o banco

Só dividir o banco não bastava: era preciso isolar cada fatia para que uma falha não virasse uma queda geral. A resposta foram os pods, nome que a Shopify pede para não confundir com pods do Kubernetes. Um pod é um conjunto de lojas que vivem em datastores totalmente isolados.

Fora dos datastores, o pod usa recursos compartilhados, como workers de jobs, servidores de aplicação e balanceadores. A regra é que cada um deles só fala com um pod por vez, e nenhuma ação alcança outro pod. Na palestra posterior, a Shopify explica que os datastores são isolados enquanto os workers stateless são compartilhados, o que permite redistribuir carga quando uma loja faz uma flash sale.

Como não há comunicação entre pods, criar um pod novo não interfere nos existentes, e isso dá escala horizontal. Para a disponibilidade, cada unidade de trabalho, seja requisição web ou job, vai para um único pod, de modo que atender uma requisição exige apenas um pod no ar.

1. O pedido de uma loja chega ao balanceador, onde roda o Sorting Hat.

2. O Sorting Hat aplica uma lista de regras, descobre a qual pod a loja pertence e marca o pedido com um cabeçalho.

3. O servidor de aplicação lê o cabeçalho e conecta apenas ao datastore do pod indicado.

4. Se o datastore de outro pod cai, só as lojas daquele pod são afetadas; as lojas do primeiro pod seguem atendidas.

Na palestra, o Sorting Hat aparece como um módulo Lua que procura o domínio da loja na tabela de roteamento. Ele roda numa camada OpenResty, antes do Rails, que também bloqueia bots. Na versão do artigo de 2018, ele é descrito como parte dos balanceadores.

03 · RECUPERAÇÃO

O pod como átomo de recuperação de desastre

A Shopify já tinha um data center de recuperação antes de dividir o sistema em pods, e levou a ideia para cada pod. Cada pod recebeu um par de data centers: um ativo e outro de recuperação. A palestra posterior descreve o mesmo desenho em regiões, com o pod ativo em uma região por vez e replicação da ativa para a outra.

Com a recuperação feita pod a pod, a promessa de que a falha de um pod não derruba a plataforma se mantém. Para mover um pod, a equipe criou o Pod Mover, que o leva ao data center de recuperação em cerca de um minuto, sem perder requisições nem jobs. Evacuar um data center inteiro é evacuar, um a um, os pods ativos nele.

1. O pod atende no data center ativo, e suas mudanças chegam ao data center de recuperação por replicação.

2. Quando é preciso mudar, o Pod Mover leva o pod para o data center de recuperação.

3. Concluída a mudança, os pedidos passam a ser atendidos pelo outro data center.

4. O data center antigo passa a ser o de recuperação desse pod.

04 · BLACK FRIDAY

Escala, rebalanceamento e lojas gigantes

A Black Friday e a Cyber Monday (BFCM) são o maior evento do ano da Shopify. No ano anterior à palestra, a plataforma somou 6,3 bilhões de dólares em vendas, com picos de 32 milhões de requisições por minuto.

Para crescer sem pensar em pods no código, vale a regra de que toda unidade de trabalho opera sobre uma única loja. Assim é fácil acrescentar pods, e os comerciantes crescem em ritmos diferentes. Por isso a Shopify precisa rebalancear, movendo lojas para espalhar carga e uso de disco. Novos comerciantes entram em um pod disponível em rodízio, e um deles pode se revelar um grande vendedor de flash sales.

1. O Ghostferry copia para o pod de destino todas as linhas cujo identificador de loja corresponde à loja movida.

2. As escritas novas continuam chegando; o binlog do MySQL as replica até as duas pontas ficarem quase em sincronia.

3. A loja é travada para escrita, e as escritas ficam em fila enquanto os jobs no Redis são copiados.

4. A tabela de roteamento aponta a loja para o novo pod, o lock sai e o destino passa a atender.

5. Os dados antigos no pod de origem são apagados depois, de forma assíncrona, para recuperar espaço.

Em resumo, a troca copia as linhas da loja, acompanha o que muda pelo log do banco, trava a escrita por instantes, copia os jobs no Redis, atualiza a rota e só depois apaga o dado antigo, de forma assíncrona. O tempo de indisponibilidade é pequeno: para muitas lojas, menos de 10 segundos, e para as maiores, menos de 20.

Também há comerciantes tão grandes que ocupam um pod inteiro sozinhos. Para os grandes comuns, a Shopify diz ter outros mecanismos para que uma flash sale não monopolize a capacidade do pod e deixe os vizinhos menores sem atender.

05 · SOBRECARGA

Controle de sobrecarga: bots, circuit breakers e teste em produção

A vitrine e o checkout têm perfis diferentes. A vitrine é sobretudo leitura, enquanto o checkout escreve muito e fala com sistemas externos. Por isso o isolamento por pod não resolve tudo: cada parte precisa de proteção própria contra picos.

Um primeiro filtro é barrar bots, que sobrecarregam os sistemas mais do que compradores reais. Um segundo é o circuit breaker: quando um recurso externo falha repetidamente, a chamada passa a falhar de imediato, e isso permite oferecer uma alternativa. A Shopify observa que um serviço degradado é melhor que um serviço fora do ar. Se o Redis das sessões cair, por exemplo, ela pode mostrar a loja como visitante em vez de devolver um erro HTTP 500.

O terceiro elemento é testar antes do pico. A Shopify faz testes de carga em produção contra lojas de benchmark, ao menos uma por pod, e roda esses testes pelo menos semanalmente. A meta é descobrir os gargalos antes que uma flash sale de um grande comerciante os revele.

06 · TRADE-OFFS

O que se ganha e o que se paga

O custo da regra de que nada cruza pods está nas funções que precisam olhar várias lojas. Elas viram aplicações separadas ou usam o data warehouse para análise. Esse isolamento também combina com um monolito modular: a palestra descreve um aplicativo Rails único, replicado em pods, e não microsserviços.

O desenho serve de modelo de arquitetura em células: uma unidade completa e independente, replicável, com um roteador na frente. Essa leitura é do curso, não da fonte, que usa o nome pod.