Webstore ReloadedWebstore ReloadedA arquitetura do walmart.com.br A arquitetura do walmart.com.br

remodeladaremodelada

Agenda

Mudança de Filosofia.

Missão

Problemas

Premissas

Estratégia

Sacadas

Solução

Eventos e Lições

Resultados e Rumos Futuros

Mudança de Filosofia

Missão

“Criar uma nova plataforma de delivery para as páginas do Walmart.com.br.”

Problemas

Tempo de resposta muito alto (segundos).Experiência de usuário comprometida.Evasão de usuários.Ciclo Vicioso: + lento = + reloads = + carga.

Baixa escalabilidade.Aplicação “aguenta lenta”.

Imprevisibilidade.

Problemas

Baixa reutilização.Difícil de criar novas plataformas.

Código difícil de manter.

Alto consumo de recursos.SOLR usado como search engine e cache.Banco de dados com picos de 100% de utilização.

Pouco controle do web cache.Difícil de expurgar objetos.Difícil de mudar tempo de vida.

Premissas

PicosUsuários Simultâneos: 300K Consumo de Rede: 1Gb.

Disponibilidade99,9%

Tempo de respostaT < 500 Milisegundos.

EscalabilidadeHorizontalNear Linear

Premissas

Utilização de RecursosDesonerar Banco de Dados.Desonerar SOLR.Diminuir número de servidores.

CódigoFacilidade de desenvolver.Alto grau de reutilização.

Usar soluções Open Source.

Estratégia

Objetivo 1: Página de Detalhe de Produto.Maioria dos serviços usados pelo catálogo.

• Preço, parcelamento, disponibilidade, etc.Conseguimos validar toda a solução.Análise de cada componente.

• De onde recuperamos essas informações?

• Quanto tempo elas podem ficar em cache?

Objetivos seguintes: Demais Páginas.

Sacadas

Fazer o básico: expor tudo como serviços.Reutilização e “RESTificação” ao extremo.Business as a Service.Render as a Service.Search as a Service.

Criar modelo de domínio independente.Anteparo às mudanças.Jobs de alimentação do modelo.Idas ao banco de dados como exceção.

Sacadas

Caches mais inteligentes.Mais níveis de cache.Controles mais granulares.Inteligência nos tempos de vida.

Melhor Distribuição das Tarefas.Dados.Negócio.Renderização.

Overview

Cache

Cache - Browser

Quando possível, o browser resolve localmente.

Response Headers (max-age, etc.).

Recursos estáticos com TTL alto. Melhor se for infinito.

Requisições Ajax com TTL mais baixo.

Diminui custos com CDN.

Cache - Akamai

Prós:CDNDiminui o tráfego à nossa infra.

Contras:Lento.Às vezes, vai pelo exterior.Menor controle do cache.

Cache - Varnish

Maior controle do cache.

Desonera a renderização.

Cache de fragmentos da página (ESIs).

Cada fragmento tem um TTL específico.

Cache - Varnish ttl: 1d

ttl: 1h

ttl: 5m

ttl: 1m

Cache - Redis

UtilizaçãoCache dos resultados das chamadas aos serviços.Modelo de dados desacoplado.

Desonera o banco de dados.

Por quê?Armazenamento em memória.Aguenta muita porrada.Tempo de resposta muito baixo.Pode persistir.Independe das linguagens usadas.

Cache - Redis

Renderização - Overview

Renderização - Template Engine

JavascriptLinguagem natural dos webdevs.Executada no cliente e no servidor.Muito flexível.

Dust JShttp://linkedin.github.io/dustjs/Alta performance.Herança de templates, partials, subtemplates, etc.Operações assíncronas.Streaming = baixo consumo de memória.Fácil customização.

Renderização - Nodejs

Javascript server side.

Orientado a eventos.

Alta performance.

Baixo consumo de recursos.

Comunidade forte (NPM).

Vários pacotes: ExpressJS, Redis, SOLR, Socket I.O

Renderização - Fluxo

/render/sku,offers,buy_button/11/ecommerce__sku_price_buy

Projeçõesskuoffersbuy_button

Id11

Templateecommerce/sku_price_buy

Renderização - Fluxo

{ "sku": { ... }, "offers": { ... }, "buy_button": { ... }} Max-age:

60s

Serviços

Serviços - Tecnologias

Spring on Jetty.Security, Data, Scheduler, Jedis.

Resteasy.Exposição dos serviços REST.Documentação com Wsdocs ou Swagger.

REST e Web Socket Services

In-memory caches.

Eventos

Primeiro Release: Rollback!ESIs em branco.keep-alive no ExpresJs.

Segundo Release: Memory leak!Node Cluster como paleativo.NodeTime para ajudar.Appender syslog no NodeJS.

Primeira Promoção: Crash!TTL infinito para objetos inaquedos.Redis irresponsivo.

Eventos

Segunda Promoção: Crash!Too many open files! OMGTeste de carga inadequado.

Lições Aprendidas

Feature rollout.

Replicação de Tráfego + Teste Longo.Memory leaks.Condições de produção.

NodeJSCenários de muitas chamadas remotas.

Orquestrador, API gateway.Pouco processamento.Muita flexibilidade.Javascript rules! :D

Lições Aprendidas

Twemproxy + RedisEspalhar as chaves entre vários servidores.Diminuir riscos ao perder um servidor.

Web Socket ServicesThroughput mais de 2X maior!

BackofficeFundamental para alimentar o modelo independente.

Resultados

Renderização: Página de Produto

Antiga> 2.4s

Nova> 143ms

Resultados

Renderização: Produtos Sustentáveis

Antiga> 5s

Nova250ms

Resultados

Teste de CargaBlazemeter.comAté 45.000 usuários simultâneos.Sem passar pela Akamai.Página de departamento.Páginas dos produtos.10.000 possibilidades para cálculo de preço.15 segundos de thinking time.Todos os cookies da requisição.

Resultados

Resultados

Resultados

O que vem por aí…

Controle total do cache.

API Server.

Web Socket Services.

In-Memory Caches.Infinispan.Big Memory.

Client Side Render.

Muitas surpresas… :D

That’s all folks!

@jwalendowsky

jorge.filho@wal-mart.com

jwalendowsky.blogspot.com.br