Webstore Reloaded - qconsp.com · Missão “Criar uma nova plataforma de delivery para as páginas do Walmart.com.br.”

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

That’s all folks!

§ @jwalendowsky § [email protected] § jwalendowsky.blogspot.com.br