Introdução rápidas

1. Introdução a Sistemas Distribuídos
Introdução a AWS
Eduardo de Lucena Falcão

2. Histórico
● Como surgiu a AWS?
– O tamanho do website da Amazon estava grande
demais para utilizar técnicas de desenvolvimento de
uma aplicação (web) convencional;
– Em 2004 a equipe da AWS começou a trabalhar
fortemente nesse objetivo;
– O problema de tamanho foi resolvido, e a Amazon foi
gradualmente se transformando de um “simples” site
de compras em uma infraestrutura de cloud.

3. As 2 Principais Vantagens da AWS
1.Não custa muito pra começar a usufruir de seus
serviços. Por exemplo, não será preciso comprar um
servidor físico e instalar na sua casa.
2.Mesmo escalonando ainda se mantém a um baixo custo.
Por exemplo, você irá escalonar de maneira elástica e
pagar apenas pelo que você precisa.

4. Histórico

5. Biggest Problem First
● Se nosso sistema fica muito grande, a maneira mais
fácil (e talvez a única) de solucionar este problema é
quebrando-o em partes menores que tenha a menor
quantidade de dependências possível.
(Desacoplamento);
● Primeiros problemas reais: aplicações para grande
corporações como bancos e linhas aéreas;
● Solução: ferramentas como CORBA e o conceito de
Engenharia de Software baseada em Componentes.

6. Comunicação entre os Componentes
● A grande maioria dos sistemas baseados em
componentes precisam se comunicar para as mais
diversas tarefas, e muitas das vezes a ordem com que
as mensagens são transmitidas é importante;
● A maneira mais simples de organizar um sistema de
passagem de mensagens é por meio de uma fila.
● E esse foi exatamente o primeiro serviço fornecido pela
Amazon em 2004: Simple Queue Service or SQS.

7. SQS
● Desenvolvedores podem simplesmente mover dados entre componentes
distribuídos que executam diferentes tarefas sem perder mensagens ou precisar
obrigatoriamente que todos os componentes estejam disponíveis;
– Exatamente o que a Amazon precisava pra começar a poder desacoplar seu sistema
“monolítico”.
● É possível trabalhar com ela como se ela fosse um buffer, e de forma elástica.
– Quando nosso sistema tiver grandes picos, uma opção seria processá-las a medida em
que nosso sistema pudesse (sem escalonamento). Seria possível que seu componente
de processamento pudesse trabalhar nas requisições o dia inteiro.
– 0,50 USD por cada 1 milhão de solicitações do Amazon SQS

8. Armazenamento Infinito
● A medida em que a tecnologia evolui, nós cada vez mais
continuamos a ultrapassar o limite de nosso hardware.
– Para armazenamento não é diferente;
– Se por um lado os cientistas da computação estão cada
vez mais engajados com tecnologia verde e a necessidade
de compressão de dados, etc.
– Por outro lado existem vertentes acadêmicas nas quais é
muito difícil diminuir o uso de armazenamento.

9. Armazenamento Infinito
● Ex.: Resolução de Vídeo.

10. Armazenamento Infinito
● Ex.: Resolução de Vídeo.

11. Armazenamento Infinito
● Continhas de padaria:
– AVI = ~700 MB
– MKV (720p) = 6.1 GB
– MKV (1080p) = 10.1 GB
– MKV (4K) = 40.4 GB
– MKV (8K) = 80.8 GB
– 100.000 filmes AVI = 70TB
– 100.000 filme 8K = 8000TB

12. Amazon S3
● Para esse problema a Amazon criou (2006) o Amazon Simple
Storage Service (S3);
● “Designed to provide 99.999999999% durability and 99.99%
availability of objects over a given year.”
– De acordo com o Evangelista Amazon Jeff Barr, esses vários
9's querem dizer que, “If you store 10,000 objects with us, on
average we may lose one of them every 10 million years or so.”
● Alguns valores:
– 1 TB / mês is $0.095 por GB;
– 500 TB / mês is $0.065 por GB;
– Transferência de dados até 10 TB / mês é $0.120 por GB.

13. Amazon S3

14. Computing per Hour
● O serviço mais importante/impactante criado pela Amazon
(2006): Amazon Elastic Cloud Computing (EC2);
● Nova categoria de cloud: IaaS;
– Apesar de virtualização de servidores já existir por um
tempo, não existia a ideia de se comprar uma hora de poder
de computação em servidores Linux/Windows.
● O EC2 era a principal peça do quebra-cabeça que faltava.
Com o EC2 torna-se possível segmentar o desenvolvimento de
software, ou seja, pequenas equipes de desenvolvedores pode
não apenas desenvolver seus componentes, mas testá-los.
– “You build it, you run it.”

15. Amazon EC2
●
Desta forma a AWS acaba de oferecer infraestrutura elástica para o
desenvolvedor de aplicações;
● Quando a AWS torna fácil a criação de novos servidores (instâncias), uma
nova gama de aplicações se torna disponível para inúmeras pessoas:
– Websites dirigidos a eventos podem ampliar (scaling up) sua
capacidade momentos antes do evento, e rodar em baixa capacidade
no resto do tempo;
– Aplicações com processamento computacional intensivo (previsão do
tempo) podem ser desenvolvidas mais facilmente, e se tornarem mais
baratas.
● Alguns valores:
– Instâncias On-Demand Micro $0.020 por hora.

16. Armazenamento de Dados
Altamente Escalável (RDS)
● Muitas aplicações precisam de algo além do S3 para
armazenamento, precisam de Bancos de Dados
compartilhados;
● Bancos de Dados Relacionais não são muito eficientes
para escalonar, pelo menos em componentes de
hardware:
– Amazon criou o Relational Database Server (RDS)
ou Relational Database as a Service, mas para o
problema do escalonamento era preciso algo
diferente.

17. SimpleDB
● Apesar da normalização de dados ser uma das melhores maneira de lidar
com a informação, não é a única
● Uma das maneiras de alcançar a escalabilidade em Bancos de Dados foi
limitá-los a uma lista de registros estruturados. Apesar de perder alguma
velocidade, pois será preciso executar operações adicionais, se ganha
escalabilidade infinita. Torna possível a execução de muito mais transações
simultâneas.
● Essa é a ideia do SimpleDB.
– A falta de joins limita seriamente a usabilidade de um BD. Não queremos
perguntar ao mainframe 7 questões ao invés de apenas uma. Contudo,
os browsers são otimizados para requisitar múltiplos recursos de uma
única vez. Com um serviço especializado para várias consultas
simultâneas, podemos através do ID do cliente recuperar sua wish-list,
cartão de compras, e buscas recentes, de uma vez só.

18. Otimizando ainda mais (ELB)
● O maior princípio da AWS é otimização, medido em
utilização de hardware:
– O principal objetivo é gerar economias de escalas;
● Uma tarefa comum em ambientes da Web é
balanceamento de carga. Seria interessante ter algo que
pudesse escalonar para mais ou menos infinitamente:
– Essa é a ideia do Elastic Load Balancing.

19. Otimizando ainda mais (Auto Scaling)
● Quando a carga de trabalho está muito acima do que uma instância pode
aguentar, o que fazer?
– Normalmente, mas nem sempre, um grupo de instâncias que fazem o
mesmo tipo de trabalho tem sua carga balanceada pelo ELB.
● Para gerenciar grupos como esse, o ideal é aliar o ELB ao Auto Scaling.
– Com o Auto Scaling é possível definir um conjunto de regras para
aumentar ou diminuir o grupo de instâncias;
– É possível lançar automaticamente um número de novas instâncias
quando a utilização do CPU, ou tráfego da rede exceder alguns
limites, ou diminuir o número de instâncias baseadas em outros
triggers.

20. Otimizando ainda mais (CloudWatch)
● Para otimizar o uso, é preciso saber o que está acontecendo, saber
como os componentes de nossa infraestrutura estão se
comportando:
– Para tal, a AWS introduziu a CloudWatch para monitorar os
vários aspectos da nossa nuvem;
– É possível medir utilização de CPU, I/O de rede, I/O de disco,
em diferentes dimensões (podemos medir apenas uma
instância, ou uma região).

21. Regiões e Zonas de Disponibilidade
● Primeira região a abrigar uma infraestrutura da AWS: Northern Virginia;
– No início, as regiões foram projetadas pensando em possíveis falhas.
● Uma região é composta por zonas de disponibilidade (availability zones):
– A grande feature das zonas é tornar nossa aplicação mais tolerante a falhas e estável.;
– Elas são independentes: o fato de uma falhar, não afeta as outras.

22. Regiões e Zonas de Disponibilidade
● Permite você escolher localizações que mais se adequem a seu problema:
– Ex.: você pode querer lançar instâncias na Europa, pra ficar mais próximo de seus
consumidores europeus, ou então devido as sanções legais impostas por aquele
país/região;
● Os recursos só são atrelados a uma região:
– As regiões são isoladas uma das outras e não existem recursos replicados entre regiões
automaticamente.

23. A quick beginning
● “Does the application have to be highly available?” YES!
● Com a AWS você tem todo o recurso que quiser na hora que quiser!
– Iniciando 5 servidores:
– Se o tráfego aumentar, adicionamos mais instâncias para balancear a carga!
● É claro que é preciso reestruturar a aplicação para que ela passe a suportar e se
utilizar dos novos recursos. (Middleware + AWS)
● Scaling Out (criando mais instâncias):
● tornamos nosso serviço altamente disponível (aumenta capacidade de tráfego e
de carga);
● tornamos nosso serviço mais resiliente (menos suscetível a falhas). Uma falha não
compromete mais o nosso sistema.
$ ec2-run-instances ami-480df921 -n 5

24. Outros Serviços AWS
● Não menos importantes do que os anteriores!
● Elastic IP adresses: um IP estático que se adéqua
perfeitamente às nuvens dinâmicas;
– Se uma instância morre nós a substituímos e
reatribuímos um IP Elástico a ela.
● Elastic Block Storage (EBS): volumes que podem ser
montados para armazenamento na instância;
– É possível criar “snapshots” do volume e replicá-los
em outras instâncias.

25. “You build it, you run it!”
● Não é preciso distinção entre desenvolver e rodar, e de acordo com
Werner Vogels (CTO da Amazon) é bem melhor que isso:
– “Prover responsabilidades operacionais tem aumentado bastante a qualidade
dos serviços, tanto do ponto de vista do consumidor como do ponto de vista da
tecnologia. É como se no modelo tradicional existisse uma parede entre a
equipe de desenvolvimento e a de operações, uma vez que os
desenvolvedores terminam a implementação do software, jogam nas mãos da
equipe operacional de implantação e perdem o contato com o software. Não
na Amazon. You build it, you run it. Isso faz com que os desenvolvedores
tenha contato com o seu software dia-a-dia, vendo como ele se comporta.
Também os traz para um contato dia-a-dia com os seus clientes. Esse loop do
feedback do consumidor é essencial para melhorar a qualidade do serviço.”

26. Referências
● Vliet, J., and Paganelli, F.; Programming Amazon EC2.
O'Reilly.
● Amazon Web Services. http://aws.amazon.com/pt/
(Acesso: abril/2013).

27. Dúvidas
https://sites.google.com/site/introsistemasdistribuidos/
Eduardo de Lucena Falcão
eduardolfalcao@gmail.com
@dudufalcao