Introdução a Sistemas Distribuídos

Introdução a AWS

Eduardo de Lucena Falcão

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.

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.

Histórico

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.

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.

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

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.

Armazenamento Infinito

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

Armazenamento Infinito

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

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

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.

Amazon S3

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

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.

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.

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

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.

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.

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

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.

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.

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

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.

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

Referências

● Vliet, J., and Paganelli, F.; Programming Amazon EC2. O'Reilly.

● Amazon Web Services. http://aws.amazon.com/pt/ (Acesso: abril/2013).

Dúvidas

https://sites.google.com/site/introsistemasdistribuidos/

Eduardo de Lucena Falcão

eduardolfalcao@gmail.com

@dudufalcao