webstore reloaded - qconsp.com · missão “criar uma nova plataforma de delivery para as páginas...
TRANSCRIPT
Webstore Reloaded A arquitetura do walmart.com.br
remodelada
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
§ 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.
Overview
Akamai Load ���Balancer
Varnish
.Net
SOLR
DB
Render Services
Redis
Cache
Browser
Akamai
Varnish
Redis
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.
Cache - Redis
Renderização - Overview
Controlador
Orquestração
Renderização
Cache
Data Fetcher
Template Engine
Repositório Templates
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
REST Controller
Web Service
Business Object
Data Object Repository
Import Job
Domain Model
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.
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
