Webstore Reloaded. A arquitetura do walmart.com.br remodelada

Transcrição

1 Webstore Reloaded A arquitetura do walmart.com.br remodelada

2 Agenda Mudança de Filosofia. Missão Problemas Premissas Estratégia Sacadas Solução Eventos e Lições Resultados e Rumos Futuros

3 Mudança de Filosofia

4 Missão Criar uma nova plataforma de delivery para as páginas do Walmart.com.br.

5

6 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.

7 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.

8

9 Premissas Picos Usuários Simultâneos: 300K Consumo de Rede: 1Gb. Disponibilidade 99,9% Tempo de resposta T < 500 Milisegundos. Escalabilidade Horizontal Near Linear

10 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.

11

12 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.

13 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.

14 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.

15

16 Overview SOLR.Net DB Akamai Load Balancer Redis Varnish Render Services

17 Cache Browser Akamai Varnish Redis

18 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.

19 Cache - Akamai Prós: CDN Diminui o tráfego à nossa infra. Contras: Lento. Às vezes, vai pelo exterior. Menor controle do cache.

20 Cache - Varnish Maior controle do cache. Desonera a renderização. Cache de fragmentos da página (ESIs). Cada fragmento tem um TTL específico.

21 Cache - Varnish ttl: 1d ttl: 1h ttl: 5m ttl: 1m

22 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.

23 Cache - Redis

24 Renderização - Overview Cache Orquestração Controlador Data Fetcher Template Engine Renderização Repositório Templates

25 Renderização - Template Engine Javascript Linguagem natural dos webdevs. Executada no cliente e no servidor. Muito flexível. Dust JS Alta performance. Herança de templates, partials, subtemplates, etc. Operações assíncronas. Streaming = baixo consumo de memória. Fácil customização.

26 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

27 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

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

29 Serviços REST Controller Web Service Domain Model Business Object Import Job Repository Data Object

30 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.

31

32 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.

33 Eventos Segunda Promoção: Crash! Too many open files! OMG Teste de carga inadequado.

34 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

35 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.

36

37 Resultados Renderização: Página de Produto Antiga > 2.4s Nova > 143ms

38 Resultados Renderização: Produtos Sustentáveis Antiga > 5s Nova 250ms

39 Resultados Teste de Carga Blazemeter.com Até usuários simultâneos. Sem passar pela Akamai. Página de departamento. Páginas dos produtos possibilidades para cálculo de preço. 15 segundos de thinking time. Todos os cookies da requisição.

40 Resultados

41 Resultados

42 Resultados

43 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

44

45 That s all jorge.filho@wal-mart.com jwalendowsky.blogspot.com.br