Qcon 2013 - Walmart Frontend Solution using Node.js

Webstore ReloadedWebstore Reloaded
A arquitetura do walmart.com.brA 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

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
Picos
Usuários Simultâneos: 300K
Consumo de Rede: 1Gb.
Disponibilidade
99,9%
Tempo de resposta
T < 500 Milisegundos.
Escalabilidade
Horizontal
Near Linear

Premissas
Utilização de Recursos
Desonerar Banco de Dados.
Desonerar SOLR.
Diminuir número de servidores.
Código
Facilidade 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.

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:
CDN
Diminui 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ção
Cache 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.

Renderização - Template Engine
Javascript
Linguagem natural dos webdevs.
Executada no cliente e no servidor.
Muito flexível.
Dust JS
http://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ções
sku
offers
buy_button
Id
11
Template
ecommerce/sku_price_buy

Renderização - Fluxo
{
"sku": {
...
},
"offers": {
...
},
"buy_button": {
...
}
} Max-age:
60s

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! OMG
Teste de carga inadequado.

Lições Aprendidas
Feature rollout.
Replicação de Tráfego + Teste Longo.
Memory leaks.
Condições de produção.
NodeJS
Cenários de muitas chamadas remotas.
Orquestrador, API gateway.
Pouco processamento.
Muita flexibilidade.
Javascript rules! :D

Lições Aprendidas
Twemproxy + Redis
Espalhar as chaves entre vários servidores.
Diminuir riscos ao perder um servidor.
Web Socket Services
Throughput mais de 2X maior!
Backoffice
Fundamental 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
Nova
250ms

Resultados
Teste de Carga
Blazemeter.com
Até 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.

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

Qcon 2013 - Walmart Frontend Solution using Node.js

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Qcon 2013 - Walmart Frontend Solution using Node.js (20)

Último (7)

Qcon 2013 - Walmart Frontend Solution using Node.js