O documento discute a evolução da arquitetura de aplicações e como escalá-las para um grande volume de usuários na nuvem. Ele descreve as mudanças nas arquiteturas de aplicações ao longo do tempo, desde terminais remotos até a computação em nuvem, e fornece exemplos de como projetar aplicações para serem resilientes e suportar altos volumes de tráfego.

1. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Escalandoaplicações
degrandevolumenanuvem

2. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
Sobre
• Fernando Lemes da Silva
• Formado em Ciências da Computação pelo IME-USP;
• Engenheiro de Software na HP Brasil – R&D Team;
• 7 anos de experiência em desenvolvimento de software;
• Iniciou na área em meados de 1990 com TK85, Apple II e PC XT;
• Foi micro-empresário fornecendo soluções na sistema operacional GNU/Linux.

3. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.3
Evolução das aplicações
• Arquitetura das aplicações
• Terminais remotos
• Cliente – Servidor
• Aplicações na web
• Computação na nuvem
• Quantidade de usuários
• Computadores pessoais
• Internet
• Smartphones
• Wearables / Internet of Things

4. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.4
Evolução das aplicações
• Terminal remoto (Mainframe, BBS, etc..)
• De dezenas a alguns milhares de usuários;
• Processamento e armazenamento realizados no servidor;
• Interface através de um terminal.
• Cliente – Servidor
• De dezenas a alguns milhares de usuários;
• Processamento realizado no cliente;
• Armazenamento realizado no servidor;
• Interface executando na máquina do usuário.

5. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.5
Evolução das aplicações
• Aplicações na web
• De centenas a dezenas de milhares de usuários;
• Processamento e armazenamento realizados no servidor;
• Interface através de um navegadores web.
• Computação na nuvem
• De alguns milhares a vários milhões de usuários;
• Processamento e armazenamento de dados distribuído;
• Acesso através de aplicações diversas:
i. Navegador web;
ii. Aplicativos desktop e mobile;
iii. MFP, appliances, smart watches, etc.

6. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.6
Exemplo simples
• Aplicativo de táxi
• Aplicação do solicitante;
• Aplicação do prestador de serviço;
• Serviços adicionais ao aplicativo.

7. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.7
Exemplo simples
• Aplicativo de táxi
• Aplicação do solicitante;
• Aplicação do prestador de serviço;
• Serviços adicionais ao aplicativo.
Táxis na cidade de São Paulo: ~30.000 táxis (2013)
5% -> 1.500 aplicações executando
1 atualização a cada 15s -> ~100 requisições por segundo
Cada requisição tem cerca de 10ms para tratar a requisição web e
provavelmente atualizar um banco de dados distribuído.

8. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.8
De startups a grandes empresas
• Início
• Prova de conceito.
• Estrutura básica
• Foco no serviço principal;
• Análise constante da necessidade para atender mais usuários.

9. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.9
Arquitetura da aplicação
• Estrutura básica
• Um servidor de páginas web;
• Um banco de dados.
Database
Web Server

10. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.10
Arquitetura da aplicação
• Ampliando a estrutura básica
• Um servidor de páginas web mais robusto;
• Um banco de dados.
Database
Web Server

11. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.11
Extinção de sessões
• O uso das sessões
• Sessões são utilizadas para armazenar o estado de um cliente acessando uma aplicação;
• Permite uma abordagem mais natural no planejamento de iterações;
• Depende do cliente enviar o ID da sessão a cada requisição (cookies).
• Porque e como não depender do estado?
• Leva tempo para carregar e armazenar;
• Requer o compartilhamento de recurso entre máquinas de um cluster;
• As requisições devem ser planejadas para enviar os dados de uma só vez e informações
anteriores que precisarem de garantia de origem devem ser assinadas digitalmente.

12. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.12
Aumentando a resiliência da aplicação
• Balanceadores de carga
• Permite a distribuição de carga para vários servidores web.
• Múltiplos servidores web
• Permite elasticidade para tratar demandas pontuais;
• Falhas em um servidor não impactam a aplicação.

13. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.13
Arquitetura da aplicação
• Aumentando a capacidade
• Aplicando o balanceamento de carga;
• Ganhando elasticidade nos servidores de páginas web.
Database
Web ServerWeb Server
Load Balancer
…

14. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.14
Aumentando a resiliência da aplicação
• Pontos de falha
• É necessário extinguir pontos únicos de falha.
• Espalhamento em data centers distintos
• Garante que uma falha em um data center não interrompa a aplicação.
• Calculando falhas
• Um provedor de IaaS garante por exemplo 99,95% de disponibilidade.

15. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.15
Aumentando a resiliência da aplicação
• Pontos de falha
• É necessário extinguir pontos únicos de falha.
• Espalhamento em data centers distintos
• Garante que uma falha em um data center não interrompa a aplicação.
• Calculando falhas
• Um provedor de IaaS garante por exemplo 99,95% de disponibilidade.
1 instância  21min 36s por mês

16. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.16
Aumentando a resiliência da aplicação
• Pontos de falha
• É necessário extinguir pontos únicos de falha.
• Espalhamento em data centers distintos
• Garante que uma falha em um data center não interrompa a aplicação.
• Calculando falhas
• Um provedor de IaaS garante por exemplo 99,95% de disponibilidade.
1 instância  21min 36s por mês
2 instâncias  1min 5s por mês

17. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.17
Aumentando a resiliência da aplicação
• Pontos de falha
• É necessário extinguir pontos únicos de falha.
• Espalhamento em data centers distintos
• Garante que uma falha em um data center não interrompa a aplicação.
• Calculando falhas
• Um provedor de IaaS garante por exemplo 99,95% de disponibilidade.
1 instância  21min 36s por mês
2 instâncias  1min 5s por mês
100 reqs/seg  6.500 falhas!

18. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.18
Aumentando a resiliência da aplicação
• Banco de dados em cluster
• Garante a disponibilidade dos dados mesmo em caso de falhas.

19. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.19
Arquitetura da aplicação
• Aumentando a resiliência da aplicação
• Vários balanceadores de carga e servidores web;
• Banco de dados em cluster (mestre/escravo).
Database
Web Server Web ServerWeb Server
Load Balancer Load Balancer
Database

20. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.20
Arquitetura da aplicação
• Aumentando a resiliência da aplicação
• Vários balanceadores de carga e servidores web;
• Banco de dados em cluster (mestre/escravo);
• Particionamento em data centers distintos.
Database
Master
Web Server Web ServerWeb Server
Load Balancer Load Balancer
Database
Slave
Web Server
Datacenter #1 Datacenter #2

21. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.21
Performance de banco de dados
• Divisão/espalhamento dos dados armazenados
• “Locks” em tabelas afetam menos registros;
• Menos dados devem implicar em menos problemas.

22. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.22
Arquitetura da aplicação
• Performance em banco de dados
• Informações são particionadas em mais de um cluster de banco de dados;
• Clusters são tipicamente espalhados em data centers distintos.
Database
Web Server Web ServerWeb Server
Load Balancer Load Balancer
Database Database Database

23. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.23
Arquitetura da aplicação
• Exemplo com MongoDB
• Servidores de “sharding” são responsáveis por distribuir os dados;
• Servidores de configuração armazenam como os dados são distribuídos;
• Vários conjuntos de banco de dados são criados em modo cluster (réplicas).
Mongo Sharding Server Mongo Sharding ServerMongo Sharding Server
Web Server Web Server Web Server
Mongo DB
Primary
Mongo DB
Secondary
Mongo DB
Secondary
Mongo DB
Primary
Mongo DB
Secondary
Mongo DB
Secondary
Mongo DB
Primary
Mongo DB
Secondary
Mongo DB
Secondary
Mongo Config
Server
Mongo Config
Server
Mongo Config
Server

24. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.24
Número de máquinas
• Clusters envolvem dezenas de máquinas
• Infraestrutura como serviço (IaaS);
• Infraestrutura privada.

25. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.25
Micro-serviços
• Divisão de responsabilidades
• Utilizando uma arquitetura de micro-serviços é possível separar o
funcionamento do sistema em partes;
• Com um sistema modular é possível estudar a performance de cada componente
e dedicar mais ou menos recursos conforme a necessidade.
• Orquestração de serviços
• Dado que os serviços estão separados é necessário uma camada adicional para
orquestrar a execução destes.

26. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.26
Arquitetura da aplicação
• Micro-serviços
• A aplicação é dividida em vários serviços (escopos distintos);
• Requer a orquestração destes serviços em uma nova camada.
DB
Web
Server
Web Server
Web
Server
Load Balancer
Load Balancer
DB DB
Web
Server
Web
Server
Load Balancer
DB DB
Web
Server
Web
Server
Load Balancer
DB
Web Server Web Server
Load Balancer
Service 1 Service 2 Service 3

27. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.27
Gerenciamento de falhas
• As falhas sempre ocorrem mas devem ser contidas
• Podem existir limites de uso entre serviços;
• Um serviço não deve entrar em colapso por falha em outro.

28. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.28
Arquitetura da aplicação
• Sistemas “disjuntores”
• Um serviço que começa a falhar ou não responde mais não deve impactar na aplicação como um todo;
• Processos que não dependem do serviço fora do ar devem continuar funcionando.
DB
Web
Server
Web Server
Web
Server
Load Balancer
Load Balancer
DB DB
Web
Server
Web
Server
Load Balancer
DB DB
Web
Server
Web
Server
Load Balancer
DB
Web Server Web Server
Load Balancer
Service 1 Service 2 Service 3

29. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.29
Múltiplas regiões e/ou versões
• Restrição de região
• Dados de usuários de uma aplicação podem ter restrições sobre onde seus
dados são armazenados;
• A escolha da região deve garantir a menor latência e maior velocidade.
• Mais de uma versão da aplicação
• Mudanças de versão são processos delicados;
• Migração de dados é custoso.

30. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.30
Arquitetura da aplicação
• Múltiplas regiões e/ou versões
• O serviço de “Discovery Service” informa para onde uma requisição deve ser encaminhada;
• O servidor proxy encaminha a requisição para o data center adequado.
DB
Web
Server
Web
Server
Load Balancer
Proxy Server
DB DB
Web
Server
Web
Server
Load Balancer
DB DB
Web
Server
Web
Server
Load Balancer
DB
Proxy Server
Service A – Version 1.0 – US Service A – Version 2.1 – US Service A – Version 2.0 – Europe
Discovery
Service

31. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31
HP Web Platform
• Aplicações projetadas para escalar
• Os usuários são aplicações ou equipamentos HP;
• Serviços podem iniciar com dezenas de usuários e atingir rapidamente milhões;
• Bateria de testes para garantir o produto:
• Unitários;
• Integração;
• Funcionais;
• Não funcionais.
• Arquitetura já pensada para ser escalada horizontalmente, em todos os níveis;
• Gerência de falhas: problemas irão surgir e é necessário ter ferramentas para ser responsivo;
• Antecipação: o desenvolvimento atual visa os próximos anos da aplicação.

32. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.32
Conclusão
• Não existe uma fórmula mágica
• Cada projeto tem suas particularidades e as necessidades para atender o crescimento variam.
• Mudanças em código e/ou arquitetura são sempre necessárias
• Durante o desenvolvimento de um projeto as necessidades mudam;
• Novas ferramentas, dependências e serviços surgem.

33. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Focoeminovação!
Antecipeastendênciase
atençãoàsnovastecnologias!
Brazil R&D

34. © Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Obrigado!
Contato:
Fernando Lemes da Silva
fernando.lemes@hp.com