do 1º usuário a 10 mil requests/seg com o microsoft azure

Do 1º usuário a

10 mil requests/segCom o Microsoft Azure

2

Em apresentações e textos na internet, conseguimos ver apenas o resultado final de experiências. A proposta dessa conversa não é mostrar o resultado e sim o caminho!

O mundo real!Entre erros e acertos

Mundo real Nem tudo sai como o planejado

AprendizadoO que aprendi e como isso influenciou tudo que fiz depois…

Erros cometidosDurante a trajetória muitos erros são cometidos, o que importa é aprender com eles.

PráticasAlgumas boas práticas e outras não tão boas assim…

3

www.companyname.com© 2015 Planner PowerPoint Template. All Rights Reserved.

AgendaQuanto tempo vai durar esse sofrimento?

Quem é esse

maluco?

Lançamos o produto

Ficou lento, vai

cair!

Redesenhando

Nosso mundo

Medir e agir!

Microsoft Azure

salvando o dia!

Lições aprendid

asConstruindo estratégias

João Bosco SeixasProgramador, Empreendedor, Curioso e viciado em cafeína.

Tentando abandonar o vício da cafeína

Programador de sistemas web desde 2005. Maior parte do tempo com Stack Microsoft. Mas acredito que para todo problema existe uma ferramenta ideal

Empreendedor, seja lá o que isso quer dizer. Sócio do Push Questões, plataforma de educação que funciona no Azure

Consultor e Arquiteto de software na 2PC

Formado em computação e MBA em Gestão Empresarial pela FGV


5De que estamos falando?Aplicação no setor de Ticketing

Vendas de ingressos on-line e controle de acesso para eventos de grandes públicos no Brasil.

SETORTodos os concorrentes na época tinham dificuldades com vendas de grandes eventos por conta do volume de acessos

REALIDADE

1ª Versão MonolíticaO objetivo era colocar a aplicação no ar – Afinal somos umas startup!

Compromisso com a entregaVou gerar valor, vou entregar software funcionando!

Eu faço rápido, sistemas rápidos!Fazer um sistema que ninguém usa ser rápido, é relativamente simples...

Respondendo as demandasTodo mundo fica feliz quando o software começa a funcionar e os primeiros clientes começam a comprar.

Lançamos!!Tudo começa quando o software vai ao ar! #SQN

7


ProduçãoAmbiente Local

Tudo era tão simplesEra só codificar e jogar no servidor

Maquina do desenvolvedor

Síndrome do “Na minha máquina funciona”

Problemas de sincronia de deploy de código x deploy da base de dados

Deploy não automatizado

Servidor único

Aplicação + Database na mesma maquina

Maquina super dimensionada para não correr o risco de “cair”

8


Catracas Geração de Ingressos

MobileNovas

funcionalidades

A arvore cresceuE eu achando que estava tudo sob controle

Logística

Custo de Servidor

aumentando

Manutenções

Dividir para ConquistarPrimeira lição aprendida

10


WebBackOffice

Pagamentos

Logística

Suporte

“Micro Services” não era um termo muito difundido em 2011 e toda a mudança de identificação e limitação dos contextos de cada aplicação foi guiado por algum conhecimento de DDD, intuição e muita tentativa e erro.

Percebendo nossos mundosAmadurecendo uma visão sobre micro serviços

11


Eu já conhecia as responsabilidadesMas mesmo assim a implementação foi feita sem a separação física ideal, o que levou a uma serie de problemas de efeitos colaterais quando existia alguma mudança em algum contexto especifico do software.

Mas não sabia que as coisas não tem o mesmo significadoCada “coisa” tem um significado diferente a depender do contexto onde se encontra e é manipulada. É assim na vida, é assim com sistemas...

Errando ao separar contextosEfeitos colaterais por todos os lados

12


A situaçãoO que tinhamos no momento

S WO T

Forças• Sistema atendia a

demanda• Sistema era “estável”

Fraqueza• Qualquer problema

afetava todo o sistema

• Sistema não era tão rápido

Oportunidades• Carta branca dos

gestores para mudança de arquitetura e infraestrutura

Ameaças• Crescimento de

demanda• Inclusão de novas

funcionalidades

Medir para dimensionar corretamenteSegunda lição aprendida

14


Entendendo o que é importanteComo entender a aplicação pode levar a construção de serviços melhores

< 10% dos usuários que navegam pelo site,entram no fluxo de compra

Qualquer inconsistência no fluxo de pagamento geramuitos pedidos de suporte

Pagamentos feitos com cartões de crédito e celulares eram críticos com relação a integração com catracas

O “fluxo de pagamento” é o rei do nosso sistema,ele nunca pode parar!

15


Escalar de forma

programada

Estratégia de diferenciação

dos concorrentes

Economia de recursos

Proteção para as

tempestades.

Primeira vez na nuvem

Microsoft Azure

O Azure era a solução dos nossos problemas

17


A empresa passava por um momento decisivo e desempenhar bem na venda de grande eventos poderia ser a diferença entre continuar crescendo e ser apenas mais um no mercado

Previsão de crescimentoAzure

Cloud Services

EscalávelEsse foi o argumento definitivo para mudarmos a arquitetura do sistema. Ser escalável naquele momento significava continuar crescer

100GB 80GB

18

Web

1

API para serviços

remotos e Pagament

o

3

Bilheterias remotas

4

Banco de Dados

Fila de Processament

o

Catracas5

Processador de fila de atendiment

o

2

Foi surgindo uma nova ordem

19


A nuvem não resolveu todos os problemasMuitos outros problemas surgiram

Algumas dores de cabeça ainda vinham das demandas dos clientes. Como relatórios “Real Time”

ClientesQuando a fila cresce o que fazer?

A FilaUma estratégia de cache ruim prejudica a capacidade do sistema de responder rapidamente

Cadê o Cache?Serviços externos continuavam a consumir uma API localizada no servidor de pagamento.

Serviços Ext.Se já existiam problemas em um cenário monolítico, imagina em um cenário distribuído

Release

20


O que estava por virEventos promovidos pela plataforma

21Turbulência a vista!!!

22

Momento nostalgia – Primeiro portal do Azure

(feito em Silverlight)

Azure salvando o dia!Facilidades de um PaaS

23


V1.1

Green – Blue DeploymentQuando achávamos que estava tudo pronto, era só virar a chave

V1.1

V1.0

V1.0

http://1e3ds31.cloudapp,net

http://meuapp.cloudapp,net

25

Webescalabilidade

quase dinâmica

APP Pagament

o

Bilheterias remotas

*

Banco de Dados

Fila de Processament

o

Catracas*

Múltiplos processador

es

Mudando novamente

Cache

APP BackOffic

e

Mantenedor do cache

invalida/atualiza

26

Permitindo suportar o trafego crescente, com possibilidade de escalar dinamicamente

Múltiplas instâncias Web Para suportar esse cenário foi

preciso fazer algumas modificações para que a operação de processamento da fila fosse idempotente e com isso eliminasse o risco de concorrência de recursos na fila

Múltiplos Workers para vazão da fila

Criação de worker responsável por gerir a estratégia de cache. Hidratação, invalidação e atualização.

Gerenciamento de Cache Divisão de

responsabilidades e separação física de APIs e Aplicações

Separação de APIs

Aumentando o grau de maturidade

27


Boa parte dos Releases ainda tinha problema

Ter um ambiente de testes refletindo o ambiente de produção, não era o suficiente, pois não conseguíamos pegar todos os erros no processo de teste

40%

WEB.

DatabasePayment

CDNDifícil planejar hora exata da Troca de versão

Definitivamentenão era uma intervenção cirúrgica

Os usuários descobriam os problemas antesdo time

Rollback nem sempreera tão suave

Se já estava difícil antes, imagina agora As estratégias de release anteriores ajudaram, mas não solucionaram o

problema

29Na verdade a gente não era tão esperto assim

Mais uma vez, fomos guiados pela intuição e pela vontade de resolver o problema

Nem sabíamos o que era Canary Release

FrontController

Medição da quantidade de requisições direcionadas para cada implantação e possibilidade de rollback caso algo saísse do controle

Ficávamos de olho no painel monitorando quantidade de usuários de cada implantação e possíveis alertas de erro

A liberação de vazão e rollback eram manuais

30

CPU, tamanho de filas, latencia, tempo de resposta, perfil de uso dos clientes, funil de venda. Monitore TUDO! Seja obsessivo com isso.

Monitore – seja obsessivo Quando a carga é realmente imprevista, nem

sempre se consegue dimensionar servidores a tempo. Colocar novas threads ou processos para fazer o trabalho em maquinas que já estão prontas pode salvar o seu dia.

Pense em escalabilidade em diversos níveis

Faça de tudo para ter um sistema de escalabilidade eficiente. Essa pode ser a diferença entre boas noites de sono ou muitas xicaras de café.

Escalabilidade dinâmica Não é porque a propaganda do seu celular fala

que você pode usar ele na agua que você deve tomar banho todo dia com ele

Capacidade ociosa ainda é preciso

Finalizando...Porque ninguém aguenta mais e eu provavelmente já estourei o tempo

31


Cloud depois do HypeLições para a vida

Modele seu sistema desde o inicio para ser distribuído

Estude os pontos vitais do seu sistemae proteja eles

Pense na forma de publicação o maiscedo possível

O mundo muda, e seu sistema tem que mudarpara acompanhar

Ninguém faz um bom sistema de primeira, sistemas são organismos evolutivos/adaptativos

Desenvolver sistemas pensando em Cloud leva todas as disciplinas ao extremo – Arquitetura,DevOps, Performance... Por isso é tão excitante!

Ainda é importante conhecer como as infraestruturas de Cloud funcionam. Não é porque sua empresa não tem limitação de recursos financeiros que você

deve deixar de se preocupar com consumo e recursos.

32


Agradecimentos especiais

Camilo Telles Michel Borges Danilo Delgado

33


Contato [email protected]

[email protected]

facebook.com/joao.bosco.t.seixastwitter.com/joaoboscoseixaslinkedin.com/in/joaoboscoseixas

Entre em contatoEstou a disposição

mailto:[email protected]

mailto:[email protected]

do 1º usuário a 10 mil requests/seg com o microsoft azure

Documents