Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Projetando para a nuvem: prticas recomendadas

Janeiro de 2010
ltima atualizao - Janeiro de 2011

Jinesh Varia
jvaria@amazon.com

Pgina 1 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Introduo
Os arquitetos de software esto h vrios anos descobrindo e implementando vrios conceitos e prticas recomenda
das para criar aplicativos altamente escalveis. Atualmente na era do tera, esses conceitos so ainda mais aplicveis
por causa dos conjuntos de dados em contnuo crescimento, padres de trfego imprevisveis e a procura por tempos
de resposta mais rpidos. Este whitepaper vai reforar e reiterar alguns destes conceitos tradicionais e discutir como
pode evoluir no contexto da computao em nuvem. Tambm sero discutidos alguns conceitos sem precedentes,
como a elasticidade que surgiu devido natureza dinmica da nuvem.
Este artigo direcionado para os arquitetos de nuvem, que esto se preparando para mover um aplicativo empresarial
de um ambiente fsico fixo para um ambiente virtualizado em nuvem. O foco deste whitepaper destacar conceitos,
princpios e prticas recomendadas na criao de novos aplicativos em nuvem ou na migrao de aplicativos existente
para a nuvem.

Histrico
Como um arquiteto de nuvem, importante compreender os benefcios de computao em nuvem. Nesta seo,
voc vai aprender alguns dos benefcios tcnicos e comerciais da computao em nuvem e dos diferentes servios
atualmente disponveis na AWS.

Benefcios comerciais da computao em nuvem

Existem alguns benefcios comerciais claros para a criao de aplicativos na nuvem. Alguns destes so listados aqui:
Quase zero de investimento em infraestrutura adiantada: se voc precisa construir um sistema em grande escala isso
pode custar uma fortuna em investimento em imveis, segurana fsica, hardware (racks, servidores, routers, fontes
de alimentao de backup), gerenciamento de hardware (gerenciamento de energia, resfriamento) e a equipe de
operaes. Devido aos elevados custos iniciais, o projeto normalmente exige vrias etapas de aprovaes de
gerenciamento antes que possa ser iniciado. Agora, com o utilitrio de estilo de computao em nuvem, no h
custo fixo ou custo inicial.
Infraestrutura just-in-time: no passado, se seu aplicativo tornava-se popular e seus sistemas ou sua infraestrutura no
podiam ser dimensionados, voc tornava-se uma vtima do seu prprio sucesso. Por outro lado, se voc investiu pesado
e no alcanou a popularidade, voc tornou-se uma vtima de seu fracasso. Com a implantao de aplicativos na nuvem
com autoprovisionamento just-in-time, voc no precisa se preocupar com a capacidade de pr-aquisio para sistemas
de grande escala. Isso aumenta a agilidade, reduz o risco e os custos operacionais porque voc dimensiona apenas de
acordo com o seu crescimento e paga somente pelo que voc utiliza.
Utilizao de recursos mais eficientes: os administradores de sistema normalmente se preocupam com a aquisio
de hardware (ao serem executados fora da capacidade) e com uma maior utilizao de infraestrutura (quando tm
capacidade ociosa e excessiva). Com a nuvem, eles podem gerenciar recursos de forma mais eficaz e eficiente por
terem os aplicativos para solicitar e renunciar a recursos on demand.
Avaliao de custo baseado no uso: com o utilitrio de estilo de preos, voc ser cobrado apenas pela infraestrutura
que tiver sido utilizada. Voc no est pagando pela infraestrutura alocada mas no utilizada. Isso acrescenta uma
nova dimenso reduo de custos. Voc pode ver uma economia imediata (por vezes, logo na fatura do prximo ms)
quando voc implanta um patch de otimizao para atualizar seu aplicativo de nuvem. Por exemplo, se uma camada
de cache pode reduzir as suas solicitaes de dados em 70%, a economia comea a ser gerada imediatamente e voc
percebe a recompensa na prxima fatura. Alm disso, se voc estiver criando plataformas no topo da nuvem, voc
pode passar sobre a mesma estrutura de custos baseada no uso flexvel, varivel para seus prprios clientes.

Pgina 2 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Reduo do tempo de entrega: a paralelizao uma das grandes maneiras de acelerar o processamento. Se um
trabalho com computao ou dados de uso intensivo que podem ser executados em paralelo podem levar 500 horas
para processar em uma mquina, com as arquiteturas de nuvem [6], seria possvel gerar e iniciar 500 instncias
e processar o mesmo trabalho em 1 hora. Ter uma infraestrutura elstica disponvel fornece o aplicativo com a
capacidade de explorar a paralelizao de forma econmica, reduzindo o tempo de mercado.

Benefcios tcnicos do computao em nuvem

Alguns dos benefcios tcnicos do computao em nuvem inclui:
Automao Infraestrutura programvel: voc pode criar sistemas de compilao e implementao reproduzveis,
aproveitando a infraestrutura programvel (API-driven).
Auto-scaling: voc pode dimensionar os seus aplicativos para diminuir ou expandir para atender a sua demanda
inesperada sem qualquer interveno humana. O dimensionamento automtico incentiva a automao e as
unidades mais eficientes.
Dimensionamento proativo: dimensione o seu aplicativo para diminuir e expandir para atender a sua demanda
antecipada com a adequada compreenso do planejamento de seus padres de trfego para que voc mantenha
seus custos baixos enquanto em est dimensionando.
Ciclo de vida de desenvolvimento mais eficiente: os sistemas de produo podem ser facilmente clonados para uso como
ambientes de teste e desenvolvimento. Ambientes de teste podem ser facilmente promovidos para ambientes de produo.
Melhorar a possibilidade de teste: nunca fique sem hardware para testes. Inserir e automatizar testes em todas as
etapas do processo de desenvolvimento. Voc pode gerar um laboratrio de teste instantneo com ambientes
pr-configurados somente para a durao da fase de testes.
Recuperao de desastres e continuidade de negcios: a nuvem fornece uma opo de menor custo para a manuteno
de uma frota de servidores DR e armazenamento de dados. Com a nuvem, voc pode aproveitar a geo-distribuio e
replicar o ambiente em outro local em poucos minutos.
Excesso de trfego para a nuvem: com alguns cliques e tcnicas de balanceamento de carga efetiva, voc pode
criar um aplicativo completo prova de excesso ao direcionar o excesso de trfego para a nuvem.

Noes bsicas sobre o Amazon Web Services Cloud

A nuvem da Amazon Web Services (AWS) fornece uma infraestrutura altamente confivel e escalvel para a implantao
de solues de escala da web, com o mnimo de custos com suporte e administrao e mais flexibilidade do que se
espera de sua prpria infraestrutura, tanto no local como em uma instalao de datacenter.
Hoje a AWS oferece variedade de servios de infraestrutura. O diagrama abaixo ir apresentar-lhe a terminologia da
AWS para ajud-lo a entender como o seu aplicativo pode interagir com diferentes servios da Amazon Web Services
e como eles interagem uns com os outros.
1

O Amazon Elastic Compute Cloud (Amazon EC2) um servio da Web que fornece uma capacidade de computao
redimensionvel em nuvem. Voc pode agrupar o sistema operacional, o software de aplicativo e as definies de
configurao associadas em uma Amazon Machine Image (AMI). Voc pode utilizar essas AMIs para configurar vrias
instncias virtualizadas, bem como encerr-las utilizando as chamadas simples de servio web para dimensionar a
capacidade de reduzir ou expandir rapidamente, alterando o seu requisito de capacidade. Voc pode comprar as

Mais informaes sobre o Amazon EC2 esto disponveis em http://aws.amazon.com/ec2

Pgina 3 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Instncias On Demand cujo pagamento calculado por hora ou as Instncias Reservadas cujo pagamento efetuado
uma nica vez e de um pequeno valor e receber uma taxa mais baixa de utilizao para executar a instncia do que
para uma instncia On-Demand ou tambm pode comprar as Instncias Spot para as quais possvel solicitar reduo
de valores pela capacidade no utilizada e reduzir ainda mais o seu custo. As instncias podem ser iniciadas em uma
ou mais regies geogrficas. Cada regio tem vrias Zonas de disponibilidade. As Zonas de disponibilidade so as
posies distintas que so projetadas para serem isoladas das falhas em outras Zonas da disponibilidade e fornecem
rede de conectividade acessvel e de baixa latncia para outras Zonas de disponibilidade da mesma regio.

Filas do Amazon SQS

Amazon
RDS

Tpicos do Amazon SNS

Domnios do Amazon SimpleDB

Pagamento: Amazon FPS/ DevPay

Seu aplicativo

Auto
Scaling

Elastic
LB

Definio de fluxo de
trabalho do Amazon
Elastic MapReduce
Nuvem
Watch

Buckets e
objetos do
Amazon S3

Amazon
Cloud
Front

Instncias do Amazon EC2

(on-demand, reservada, spot)
EBS
Volumes

Snapshots

Amazon
Virtual Private Cloud

Infraestrutura fsica e global da Amazon (Regies geogrficas,

Zonas de disponibilidade, Pontos de presena)
Figura 1: Amazon Web Services

Os endereos do Elastic IP permitem que voc atribua um endereo IP esttico de forma programtica a uma instncia.
Voc pode habilitar o monitoramento em uma instncia do Amazon EC2 utilizando o Amazon CloudWatch2 a fim de
ganhar visibilidade na utilizao de recursos, desempenho operacional e padres de demanda global (incluindo mtricas
como a utilizao do CPU, leituras e gravaes de discos e trfego de rede). Voc pode criar um grupo Auto Scaling
utilizando o recurso Auto-scaling3 para dimensionar automaticamente a sua capacidade em determinadas condies
com base em mtricas que o Amazon CloudWatch coleta. Voc tambm pode distribuir o trfego de entrada, criando
um Elastic Load Balancer utilizando o servio Elastic Load Balancing4. Os volumes do Amazon Elastic Block Storage (EBS)5
fornecem armazenamento persistente anexado rede para instncias do Amazon EC2. Snapshots consistentes nos
volumes EBS atuais podem ser criadas e armazenadas no Amazon Simple Storage Service (Amazon S3)6.

Mais informaes sobre o Amazon CloudWatch esto disponveis em http://aws.amazon.com/cloudwatch/

Mais informaes sobre o recurso Auto-scaling esto disponveis em http://aws.amazon.com/auto-scaling
4
Mais informaes sobre o recurso Elastic Load Balancing esto disponveis em http://aws.amazon.com/elasticloadbalancing
5
Mais informaes sobre o Elastic Block Store esto disponveis em http://aws.amazon.com/ebs
6
Mais informaes sobre o Amazon S3 esto disponveis em http://aws.amazon.com/s3
3

Pgina 4 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

O Amazon S3 um armazenamento de dados distribudo e altamente durvel. Com uma interface simples de servios da
web, voc pode armazenar e recuperar grandes quantidades de dados como objetos em buckets (containers) a qualquer
momento, de qualquer lugar na web utilizando verbos HTTP padro. As cpias de objetos podem ser distribudas e
armazenadas em cache em 14 pontos de presena ao redor do mundo, criando uma distribuio utilizando o servio
Amazon CloudFront7 um servio da web para entrega de contedo (esttico ou de streaming). O Amazon SimpleDB8
um servio da web que oferece uma funcionalidade principal de pesquisa de banco de dados em tempo real e de
consulta simples de dados estruturados, sem a complexidade operacional. Voc organiza seus dados estruturados
emdomnios e pode executar consultas em todos os dados armazenados em um domnio especfico. Os domnios so
conjuntos deitens que so descritos por pares de valores de atributos. O servio de banco de dados relacional9 (Amazon
RDS) facilita a configurao, a operao e o dimensionamento de seu banco de dados relacional em nuvem. Voc pode
iniciar uma Instncia de banco de dados e obter acesso a um banco de dados MySQL completo sem se preocupar com
tarefas comuns de administrao de banco de dados como backups, gerenciamento de patch, etc.
O Amazon Simple Queue Service (Amazon SQS)10 oferece uma fila hospedada altamente escalvel e confivel para o
armazenamento de mensagens medida em que elas transitam entre computadores.
O Amazon Simple Notifications Service (Amazon SNS)11 fornece uma maneira simples para notificar aplicativos ou
pessoas a partir da nuvem criando tpicos e utilizando um protocolo de publicao de assinatura.
O Amazon Elastic MapReduce12 fornece uma estrutura Hadoop hospedada sendo executada na infraestrutura de escala
da web do Amazon Elastic Compute Cloud (Amazon EC2) e Amazon Simple Storage Service (Amazon S3) e permite que
voc crie JobFlows personalizados. JobFlow uma sequncia de etapas do MapReduce.
O Amazon Virtual Private Cloud (Amazon VPC)13 permite que voc amplie a sua rede corporativa em uma nuvem privada
contida na AWS. O Amazon VPC utiliza o modo Tunnel IPSec que permite que voc crie uma conexo segura entre um
gateway no seu datacenter e um gateway na AWS.
O Amazon Route53 um servio DNS altamente escalvel que permite que voc gerencie os seus registros DNS, criando
um HostedZone para cada domnio que voc gostaria de gerenciar.
O AWS Identity and Access Management (IAM)14 permite que voc crie mltiplos usurios e gerencie permisses para
cada um desses usurios a partir de sua conta da AWS. O IAM integrado nativamente nos servios AWS. Nenhuma
das APIs de servio foi alterada para suportar a IAM, aplicativos de sada e as ferramentas projetadas a partir de APIs
de servio da AWS continuam a funcionar enquanto a IAM estiver sendo usada.
A AWS tambm oferece diversos servios de pagamento e faturamento15 que aproveitam a infraestrutura de pagamento
da Amazon.

Mais informaes sobre o Amazon CloudFront esto disponveis em http://aws.amazon.com/cloudfront

Mais informaes sobre o Amazon SimpleDB esto disponveis em http://aws.amazon.com/simpledb
9
Mais informaes sobre o Amazon RDS esto disponveis em http://aws.amazon.com/rds
10
Mais informaes sobre o Amazon SQS esto disponveis em http://aws.amazon.com/sqs e
11
Mais informaes sobre o Amazon SNS esto disponveis em http://aws.amazon.com/sns
12
Mais informaes sobre o Amazon ElasticMapReduce esto disponveis em http://aws.amazon.com/sns
13
Mais informaes sobre o Amazon Virtual Private Cloud esto disponveis em http://aws.amazon.com/vpc
14
Mais informaes sobre o Amazon Identity and Access Management esto disponveis em http://aws.amazon.com/iam
15
Mais informaes sobre o Amazon Flexible Payments Service esto disponveis em http://aws.amazon.com/fps e sobre Amazon
DevPay esto disponveis em http://aws.amazon.com/devpay
8

Pgina 5 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Todos os servios de infraestrutura da AWS oferecem um utilitrio de estilo de preos sem exigir contratos ou
compromissos a longo prazo. Por exemplo, voc paga por hora pelo uso da instncia do Amazon EC2 e paga pelo
gigabyte para armazenamento e transferncia de dados no caso do Amazon S3. Mais informaes sobre cada um
desses servios e seus definies de preo pague somente pelo o que usar esto disponveis no site da AWS.
Observe que o uso da nuvem da AWS no requer sacrificar a flexibilidade e o controle a que voc j est acostumado:

Voc livre para utilizar o modelo de programao, linguagem ou sistema operacional (Windows, OpenSolaris
ou qualquer tipo de Linux) de sua escolha.
Voc livre para escolher os produtos da AWS que melhor satisfazem as suas necessidades voc pode utilizar
qualquer um dos servios individualmente ou em qualquer combinao.
A AWS fornece recursos redimensionveis (armazenamento, largura de banda e computao), e por isso voc
est livre para utilizar muito ou pouco e s paga o que voc de fato utilizar.
Voc livre para utilizar as ferramentas de gerenciamento de sistema utilizadas no passado e ampliar o seu
datacenter para dentro da nuvem.

Pgina 6 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Conceitos de nuvem
A nuvem refora alguns conceitos antigos de criao de arquiteturas [13] da Internet altamente escalveis e introduz
alguns novos conceitos que mudam completamente o modo pelo qual os aplicativos so criados e implantados. Assim,
quando voc passar do conceito para a implementao, voc pode obter a sensao de que "Tudo mudou, mas nada
diferente". A nuvem altera vrios processos, padres, prticas, filosofias e refora alguns princpios tradicionais de
arquitetura orientados ao servio que voc aprendeu pois eles so ainda mais importantes do que antes. Nesta seo,
voc ver alguns desses novos conceitos de nuvem e conceitos SOA renovados.
Os aplicativos tradicionais foram projetados com base em alguns paradigmas pr-concebidos que tinham relevncia
econmica e arquitetnica no momento em que foram desenvolvidos. A nuvem traz algumas filosofias novas que
voc precisa entender e que so argumentadas abaixo:

Construo de arquiteturas escalveis

fundamental construir uma arquitetura escalvel, a fim de tirar proveito de uma infraestrutura escalvel.
A nuvem projetada para fornecer escalabilidade infinita de forma conceitual. No entanto, voc no pode aproveitar
todas as escalabilidades em infraestrutura se a sua arquitetura no escalvel. Ambos devem trabalhar juntos. Voc
precisar identificar os componentes monolticos e os afunilamentos em sua arquitetura, identificar as reas onde voc
no pode aproveitar os recursos de provisionamento On-Demand e trabalhar para refatorar o seu aplicativo para
aproveitar a infraestrutura escalvel e tirar proveito da nuvem.
Caractersticas de um aplicativo verdadeiramente escalvel:

O aumento nos recursos gera um aumento proporcial no desempenho

Um servio escalvel capaz de lidar com heterogeneidade
Um servio escalvel operacionalmente eficiente
Um servio escalvel flexvel
Um servio escalvel deve tornar-se mais rentvel quando cresce (custo por unidade diminui com o
aumento do nmero de unidades)

Estas so as informaes que devem se transformar em uma parte inerente do seu aplicativo e se voc projetar a sua
arquitetura com as caractersticas acima em mente, logo em seguida a sua arquitetura e infraestrutura trabalharo
juntas para disponibilizar a voc a escalabilidade que est procurando.

Pgina 7 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Noes bsicas sobre a elasticidade

O grfico abaixo ilustra as diferentes abordagens que um arquiteto de nuvem pode realizar para dimensionar os seus
aplicativos a fim de atender a demanda.
Abordagem de expanso: sem se preocupar com a arquitetura de aplicativo escalvel e investindo fortemente em
computadores maiores e mais poderosos (dimensionamento vertical) para atender a demanda. Essa abordagem
normalmente funciona at certo ponto, mas poderia custar uma fortuna (ver Despesas enormes de capital no
diagrama) ou a demanda poderia aumentar a capacidade antes que seja implantado um novo supercomputador
(ver Voc acaba de perder seus clientes no diagrama).
Abordagem de ampliao tradicional: criando uma arquitetura que se expande horizontalmente e investindo na
infraestrutura em pequenas partes. A maioria das empresas e aplicativos da web em grande escala segue esse padro
para distribuir seus componentes de aplicativos, particionando seus conjuntos de dados e utilizando um projeto
orientado a servios. Esta abordagem muitas vezes mais eficaz do que uma abordagem de expanso. No entanto,
sso requer ainda prever a demanda em intervalos regulares e, em seguida, a implantar um infraestrutura em partes
para atender demanda. Isso muitas vezes leva ao excesso de capacidade (reduo de dinheiro) e um monitoramento
manual constante (reduo de ritmo de trabalho). Alm disso, ele normalmente no funciona se o aplicativo usado
excessivamente (muitas vezes referido como o efeito Slashdot16).
Observao: ambas as abordagens tm custos iniciais e ambas so reativas na natureza.

Custos da infraestrutura USD

Excesso de capacidade
Custo de oportunidade

Grandes despesas
de capital

Voc acabou de perder

seus clientes

Demanda prevista
Demanda real
Abordagem de expanso
Abordagem de
expanso tradicional
Elasticidade automatizada

Elasticidade automatizada + escalabilidade

Figura 2: elasticidade automatizada

16

http://en.wikipedia.org/wiki/Slashdot_effect

Pgina 8 de 23

Tempo t

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

A infraestrutura tradicional geralmente exige uma previso da quantidade de recursos computacionais que o seu
aplicativo utilizar ao longo de um perodo de vrios anos. Se voc subestimar, os seus aplicativos no tero a
potncia suficiente para lidar com o trfego inesperado, resultando potencialmente na insatisfao do cliente.
Se voc superestimar, perder dinheiro com recursos suprfluos.
No entanto, a natureza elstica e on demand da abordagem de nuvem (elasticidade automatizada), permite que a
infraestrutura possa ser alinhada (como ela se expande e reduz) com a demanda real, aumentando assim a utilizao
global e reduzindo os custos.
A elasticidade uma das propriedades fundamentais da nuvem. A elasticidade o poder para dimensionar recursos
computacionais diminuindo ou expandindo facilmente e com o mnimo de atrito. importante compreender que a
elasticidade acabar por conduzir a maioria dos benefcios da nuvem. Como um arquiteto de nuvem, voc precisar
internalizar este conceito e trabalhar em sua arquitetura de aplicativo a fim de aproveitar a nuvem ao mximo.
Tradicionalmente, os aplicativos foram projetados para a infraestrutura fixa, rgida e pr-provisionada. As empresas nunca
tiveram a necessidade de provisionar e instalar servidores em base diria. Como resultado, a maioria das arquiteturas de
software no atendem a implementao rpida ou a reduo de hardware. O tempo de provisionamento e investimento
inicial at a aquisio de novos recursos era demasiadamente elevado, os arquitetos de software nunca investiram tempo
e recursos na otimizao para a utilizao do hardware. Era aceitvel se o hardware no qual o aplicativo estava sendo
executado fosse subutilizado. A noo de elasticidade dentro de uma arquitetura foi esquecida porque a ideia de ter
novos recursos em minutos no foi possvel.
Com a nuvem, essa mentalidade precisa mudar. A computao em nuvem simplifica o processo de aquisio dos
recursos necessrios; no h nenhuma necessidade de fazer pedidos antes do tempo e de manter o hardware no
utilizado em cativeiro. Em vez disso, os arquitetos de nuvem podem solicitar o que precisam poucos minutos antes
de precisarem ou automatizar o processo de aquisio, aproveitando a vasta escala e o tempo de resposta rpida da
nuvem. O mesmo se aplica para liberar os recursos desnecessrios ou subutilizados quando voc no precisa deles.
Se voc no pode abraar a mudana e implementar a elasticidade na sua arquitetura de aplicativo, voc ser incapaz
de aproveitar a nuvem ao mximo. Assim como um arquiteto de nuvem, voc deve pensar de maneira criativa pensando
de que maneiras voc pode implementar a elasticidade no seu aplicativo. Por exemplo, a infraestrutura que costumava
executar compilaes dirias todas as noites e realizar testes de regresso e unidade todas as noites s 2h durante duas
horas (muitas vezes denominadas como Caixa de controle de qualidade da compilao) ficava como ociosa pelo resto
do dia. Agora, com a infraestrutura elstica, pode-se executar compilaes noturnas em caixas que esto ativas e est
sendo pago apenas por 2 horas por noite. Da mesma forma, um problema interno no aplicativo da web de emisso
de tquetes que sempre utilizado para executar em capacidade mxima (5 servidores 24 x 7 x 365) para atender a
demanda durante o dia agora pode ser configurado tambm para ser executado sob demanda (5 servidores das 9h
as 17h e 2 servidores das 17h as 9h) com base no padro de trfego.
Projetar arquiteturas inteligentes de nuvens elsticas, para que a infraestrutura seja executada somente quando voc
precisa dela, uma arte em si. A elasticidade deve ser um dos requisitos do projeto arquitetnico ou uma propriedade
do sistema. Perguntas que voc precisa fazer: quais os componentes ou as camadas em minha arquitetura de aplicativo
podem se tornar elsticas? O que ser necessrio para tornar esse componente elstico? Qual ser o impacto da
implementao da elasticidade minha arquitetura geral do sistema?
Na prxima seo, voc ver tcnicas especficas para implementar a elasticidade em seus aplicativos. Para aproveitar
efetivamente os benefcios da nuvem, importante um arquiteto com essa mentalidade.

Pgina 9 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

No temendo restries
Quando voc decidir mover os seus aplicativos para a nuvem e tentar mapear as suas especificaes de sistema para
aquelas disponveis na nuvem, voc vai notar que a nuvem pode no ter a especificao exata do recurso que voc tem
no local. Por exemplo, a nuvem no fornece um X de memria RAM em um servidor ou Meu banco de dados precisa
ter mais IOPS do que posso obter em uma nica instncia.
Voc deve compreender que a nuvem fornece recursos abstratos e eles se tornam poderosos quando voc os combina com
o modelo de provisionamento on demand. Voc no deve ficar com receio e nem constrangido, quando estiver utilizando
recursos de nuvem porque importante compreender que, mesmo que voc no tenha uma rplica exata do seu hardware
no ambiente da nuvem, voc poder obter mais desses recursos em nuvem para compensar essa necessidade.
Por exemplo, se a nuvem no lhe fornecer RAM com exatido ou maior quantidade em um servidor, tente usar um
cache distribudo do tipo memcached17ou particionar seus dados em vrios servidores. Se seus bancos de dados
precisam de mais E/S por segundo e no mapearem diretamente a da nuvem, h vrias recomendaes que voc
pode escolher de acordo com seu tipo de dados e utilizao. Se for um aplicativo de leitura frequente, voc pode
distribuir a carga de leitura atravs de uma frota de escravos sincronizados. Como alternativa, voc pode usar um
algoritmo de fragmentao [10] que direciona os dados aonde eles precisam estar ou voc pode usar vrias solues
de clustering de bancos de dados.
Recapitulando, quando voc combina os recursos de provisionamento sob demanda com a flexibilidade, voc vai notar
que aparentes restries na verdade podero ser entendidas como formas que realmente iro melhorar a escalabilidade
e o desempenho geral do sistema.

Administrao virtual
O advento da nuvem mudou o papel do administrador do sistema para um "administrador de sistema virtual". Isso
simplesmente significa que tarefas rotineiras realizadas por esses administradores agora tornaram-se ainda mais
interessantes medida que eles aprendem mais os sobre aplicativos e decidem o que melhor para a empresa como
um todo. O administrador do sistema j no tem a necessidade de provisionar servidores, instalar software e conectar
dispositivos de rede j que todo esse trabalho maante substitudo por alguns cliques e linhas de comando. A nuvem
incentiva a automao porque a infraestrutura programvel. Os administradores de sistema precisam mover a roda
da tecnologia e aprender como gerenciar recursos abstratos de nuvem abstrata utilizando scripts.
Da mesma forma, a funo do administrador do banco de dados se altera para administrador de banco de dados virtual
na qual ele/ela gerencia recursos atravs de um console baseado na web, executa scripts que adicionam novas
capacidades por meio de programao no caso dos recursos de hardware de banco de dados se esgotarem e automatiza
os processos de rotina. O DBA virtual deve agora aprender novos mtodos de implantao (imagens de mquina virtual),
adotar novos modelos (paralelizao de consulta, geo-redundncia e replicao assncrona [11]), repensar a arquitetura
de abordagem para dados (fragmentao [9], particionamento horizontal [13], federao [14]) e aproveitamento das
diferentes opes de armazenamento disponveis na nuvem para os diferentes tipos de conjuntos de dados.
Na empresa tradicional, os desenvolvedores de aplicativos podem no trabalhar em estreita colaborao com os
administradores de rede e administradores de rede podem no ter a menor ideia sobre o aplicativo. Como resultado,
possveis otimizaes na camada de rede e na camada de arquitetura do aplicativo podero negligenciadas. Com a
nuvem, as duas funes se fundiram a uma em razovel extenso. Projetando a arquitetura de futuras aplicaes, as
empresas devem encorajar mais polinizao cruzada de conhecimento entre as duas funes e entender que elas esto
em processo de fuso.

17

http://www.danga.com/memcached/

Pgina 10 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Prticas recomendadas em nuvem

Nesta seo, voc conhecer as prticas recomendadas que lhe ajudaro a construir um aplicativo na nuvem.

Se prepare para falhas e nada falhar

Regra de ouro: seja um pessimista ao projetar arquiteturas na nuvem; presuma que tudo ir falhar. Em outras palavras,
sempre projete, implemente e implante para recuperao automatizada de falha.
Principalmente, presuma que seu hardware falhar. Presuma que Pressuponha que algum desastre ir atingir seu
aplicativo. Pressuponha que voc ser solicitado com mais do que o nmero esperado de pedidos por segundo algum
dia. Pressuponha que com o tempo o seu software aplicativo falhar tambm. Sendo um pessimista, voc acaba
refletindo sobre estratgias de recuperao ao longo do tempo de design, o que ajuda na criao de um sistema
melhor como um todo.
Se voc perceber que as coisas falham ao longo do tempo e incorporar esse pensamento na sua arquitetura, crie
mecanismos para lidar com essa falha antes que o desastre chegue para lidar com uma infraestrutura escalvel,
voc vai acabar criando uma arquitetura tolerante a falhas que otimizada para a nuvem.
Questes que voc precisa levantar: o que acontecer se um n em seu sistema falhar? Como voc reconhece esta
falha? Como eu fao para substituir o n? Para quais tipos de cenrios que eu tenho que me planejar? Quais so
meus pontos nicos de falha? Se um balanceador de carga est disposto na frente de uma matriz de servidores de
aplicativos, o que acontecer se o balanceador de carga falhar? Se no houver mestre e escravos em sua arquitetura,
o que acontecer se o n mestre falhar? Como que ocorre o failover e como que um escravo novo instanciado e
colocado em sincronia com o mestre?
Da mesma forma que projetar para falhas de hardware, voc tambm deve projetar para falhas de software. Questes
que voc precisa levantar: O que acontecer com o meu aplicativo se os seus servios dependentes mudarem suas
interfaces? E se o servio de downstream expirar ou retornar uma exceo? E se as chaves de cache crescerem alm
do limite de memria de uma instncia?
Crie mecanismos para lidar com essa falha. Por exemplo, as seguintes estratgias podem ajudar em caso de falha:
1.
2.
3.
4.
5.

Ter um backup coerente e estratgia de restaurao para os seus dados e automatiz-la

Construir linhas de processo que se retomam na reinicializao
Permitir que o estado do sistema se ressincronize atravs de recargas de mensagens de filas
Mantenha imagens virtuais pr-configuradas e pr-otimizadas para suporte (2) e (3) no lanamento/inicializao
Evite sesses in memory ou contexto de monitorao de estado de usurio, mova tudo isso para
armazenamentos de dados.

Boas arquiteturas de nuvem devem ser a prova de reboots e reinicalizaes. Em GrepTheWeb (discutido no artigo Cloud
Architectures [6]), usando uma combinao do Amazon SQS e do Amazon SimpleDB, a arquitetura geral do controlador
muito resistente aos tipos de falhas listados nesta seo. Por exemplo, se a instncia na qual o thread controlador
estava sendo executado for desativada, ela pode ser reativada e retomar o seu estado anterior, como se nada tivesse
acontecido. Isso foi alcanado com a criao de uma Amazon Machine Image (AMI) pr-configurada, que, quando
iniciada, retira da fila todas as mensagens do Amazon SQS e l seus estados a partir de um domnio em reboot do
Amazon SimpleDB.
Projetar com uma suposio de que o hardware subjacente ir falhar, pode prepar-lo para o futuro quando isso
realmente ocorrer.

Pgina 11 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Este princpio de design o ajudar a projetar aplicativos de fcil operao, assim como foi destacado no artigo de
Hamilton [11]. Se voc puder estender este princpio para medir e equilibrar cargas dinamicamente e de forma
proativa, pode ser que voc consiga gerenciar a variao no desempenho de disco e de rede que existe devido
natureza multilocatria da nuvem.
Tticas especficas da AWS para implementar essa prtica recomendada:
1. Enfrente um failover com tranquilidade usando Elastic IPs: Elastic IP um endereo IP esttico que
dinamicamente remapevel. Voc pode rapidamente remapear e fazer um failover para outro
conjunto de servidores para que o seu trfego seja direcionado para os novos servidores. Isso
funciona muito bem quando voc deseja fazer atualizaes para verses mais novas ou em caso
de falhas de hardware
2. Utilize vrias Zonas de disponibilidade: as Zonas de disponibilidade so conceitualmente semelhantes
a datacenters lgicos. Ao implantar sua arquitetura em vrias Zonas de disponibilidade, voc pode
garantir alta disponibilidade. Utilize a funcionalidade de implantao do Amazon RDS Multi-AZ [21]
para replicar automaticamente atualizaes de banco de dados em vrias Zonas de disponibilidade.
3. Mantenha uma Amazon Machine Image para que voc possa facilmente restaurar e clonar
ambientes em uma Zona de disponibilidade diferente; Mantenha vrios bancos de dados
secundrios nas Zonas de disponibilidade e configure uma replicao dinmica.
4. Utilize o Amazon CloudWatch (ou vrias ferramentas de monitoramento em tempo real de cdigo
aberto) para obter mais visibilidade e tomar as medidas apropriadas em caso de degradao de
desempenho ou falha de hardware. Configure um grupo de Auto scaling para manter um tamanho
fixo de frota para que este substitua as instncias com problemas do Amazon EC2 por novas.
5. Utilize o Amazon EBS e configure trabalhos cron para que as snapshots incrementais sejam
automaticamente enviadas para o Amazon S3 e os dados sejam mantidos independentes de
suas instncias.
6. Utilize o Amazon RDS e defina o perodo de reteno para os backups, para que ele possa realizar
backups automatizados.

Separe seus componentes

A nuvem refora o princpio de design SOA de que quanto mais separados estiverem os componentes do sistema, muito
mais e de melhor maneira eles se dimensionaro.
A chave construir componentes que no sejam to dependentes uns dos outros, para que se um componente for
desativado (falhar), estiver suspenso (no responder) ou permanecer ocupado (lento para responder) por algum motivo,
os outros componentes do sistema so construdos, a fim de continuar a trabalhar como se nenhuma falha estivesse
acontecendo. Basicamente, o acoplamento mais solto isola a vrias camadas e componentes do seu aplicativo para que
cada componente interaja de forma assncrona com os outros e os trate como uma caixa preta. Por exemplo, no caso da
arquitetura do aplicativo da web, voc pode isolar o servidor de aplicativo do servidor web e de banco de dados. O servidor
de aplicativo no sabe sobre seu servidor web e vice-versa, isto oferece uma dissociao entre essas camadas e no h
nenhuma dependncia em nvel de cdigo ou de perspectivas funcionais. No caso da arquitetura de processamento em
lote, voc pode criar componentes assncronos que so independentes uns dos outros.
Perguntas que voc precisa fazer: qual componente de negcios ou recurso poderia ser isolado do aplicativo atual
monoltico e pode ser executado de forma autnoma separadamente? E, em seguida, como posso adicionar mais
instncias desse componente sem quebrar meu sistema atual e ao mesmo tempo atender a mais usurios? Quanto
esforo ser necessrio para encapsular o componente para que ele possa interagir com outros componentes de
forma assncrona?

Pgina 12 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

A dissociao entre seus componentes, a construo de sistemas assncronos e o dimensionamento horizontal tornamse muito importantes no contexto da nuvem. Isso no somente permitir que voc amplie seu sistema adicionando
mais instncias do mesmo componente, mas tambm permitir que voc crie modelos hbridos inovadores nos quais
alguns componentes continuam a ser executados no local, enquanto outros componentes podem tirar proveito do
dimensionamento em nuvem e usar a nuvem para potncia de computao adicional e largura de banda. Dessa forma,
com o mnimo esforo, voc pode direcionar "excesso" de trfego para a nuvem atravs da implementao de tticas
de balanceamento de carga inteligente.
possvel criar um sistema de baixo acoplamento usando filas de mensagens. Se uma fila/buffer usada para conectar
quaisquer dois componentes, ser possvel oferecer suporte a simultaneidade, a alta disponibilidade e a picos de
carga. Como resultado, o sistema como um todo continua a ser executado mesmo se partes de componentes esto
temporariamente indisponveis. Se um componente desativado ou fica temporariamente indisponvel, o sistema
armazenar as mensagens em buffer e as processar quando o componente for reativado.
Chamar um mtodo em B
Controlador a partir de A
Controlador

Chamar um mtodo em C
a partir de B
Controlador

Acoplamento rgido (programao processual)

Fila B

Fila A

Controlador
A

Fila C

Controlador
B

Controlador
C

Acoplamento flexvel (fases independentes, utilizando filas)

Figura 3: dissociao entre componentes usando filas

Voc observar um grande uso de filas na arquitetura GrepTheWeb descritas em detalhes no artigo Cloud Architectures
[6]. Em GrepTheWeb, se muitas solicitaes de repente chegam ao servidor (uma situao de sobrecarga induzida pela
Internet) ou o processamento de expresses regulares leva mais tempo do que a mdia (lenta taxa de resposta de um
componente), as filas do Amazon SQS armazenam as solicitaes em buffer de forma durvel para que esses atrasos no
afetem outros componentes.
Tticas especficas da AWS para implementar essa prtica recomendada:
1. Use o Amazon SQS para isolar componentes [18]
2. Use o Amazon SQS como armazenamento em buffers entre componentes [18]
3. Projete cada componente a fim de que exponha uma interface de servio e seja responsvel por
sua prpria capacidade de expanso em todas as dimenses adequadas e para que interaja com
outros componentes de forma assncrona
4. Inclua a construo lgica de um componente em uma Amazon Machine Image para que ele possa
ser implantado com mais frequncia
5. Deixe seus aplicativos o mais sem monitorao de estado possvel. Armazene o estado de sesso
fora do componente (no Amazon SimpleDB, se apropriado)

Pgina 13 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Implemente elasticidade
A nuvem traz um novo conceito de elasticidade para seus aplicativos. A elasticidade pode ser implementada de
trs maneiras:
1. Dimensionamento proativo cclico: dimensionamento peridico que ocorre em intervalo fixo (diria,
semanal, mensal ou trimestralmente)
2. Dimensionamento proativo baseado em evento: executa o dimensionamento apenas quando voc est
esperando uma grande onda de solicitaes de trfego devido a um evento de negcios agendado
(novo lanamento de produto, campanhas de marketing)
3. Auto-scaling baseado em demanda. Usando um servio de monitoramento, seu sistema pode enviar
disparadores para tomar as medidas apropriadas para que ele possa se expandir ou se reduzir com base
em mtricas (utilizao dos servidores ou rede e/s, por exemplo)

Para implementar a "Elasticidade", preciso primeiro automatizar o processo de implantao e simplificar a configurao
e o processo de compilao. Isso assegurar que o sistema pode ser expandido sem qualquer interveno humana.
Isso resultar em benefcios de custo imediato, medida que a utilizao geral aumentada ao garantir que seus recursos
estejam alinhados com a demanda, em vez de sendo executados potencialmente em servidores que so subutilizados.
Automatize sua infraestrutura
Um dos benefcios mais importantes do uso de um ambiente de nuvem a capacidade de usar APIs da nuvem para
automatizar o processo de implantao. recomendvel que voc disponha de tempo para criar um processo
automatizado de implantao no incio durante o processo de migrao e no espere at o final. Criar um processo de
implantao automatizada e repetvel ajudar a reduzir erros e facilitar um processo de atualizao eficiente e escalvel.
Para automatizar o processo de implantao:

Criar uma biblioteca de "receitas" pequenos scripts utilizados frequentemente (para instalao e configurao)
Gerencie a configurao e o processo de implantao usando agentes includos em uma AMI
Inicializao de suas instncias

Inicializao de suas instncias

Faa com que suas instncias lhe faam uma pergunta ao inicializar "quem sou eu e qual a minha funo"? Cada
instncia deveria ter uma funo ("servidor de banco de dados", "servidor de aplicativos", "servidor secundrio" no caso
de um aplicativo da Web) para desempenhar no ambiente. Esta funo pode ser passada como um argumento durante a
inicializao, que instrui a AMI sobre quando instanciar e quais os passos a tomar depois de ser iniciada. Na inicializao,
as instncias devem pegar os recursos necessrios (cdigo, scripts, configurao) com base na funo e "anex-los" para
um cluster para servir a sua funo. Benefcios da inicializao de suas instncias:
1.
2.
3.
4.

Recrie o ambiente (Dev, preparo, produo) em alguns cliques e com um esforo mnimo
Mais controle sobre seus recursos abstratos baseados em nuvem
Reduzir erros de implantao induzidos pelo homem
Crie um ambiente de auto correo e de auto descobrimento que mais resistente a falhas de hardware

Pgina 14 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Tticas especficas da AWS para automatizar sua infraestrutura

1. Defina grupos de Auto-scalling para diferentes clusters usando o recurso de Auto-scaling da Amazon
no Amazon EC2.
2. Monitore suas mtricas de sistema (CPU, memria, E/S de disco, E/S de rede) usando o Amazon
CloudWatch e tome as medidas apropriadas (iniciar novas AMIs dinamicamente usando o servio de
Auto-scaling) ou envie notificaes.
3. Armazene e recupere informaes de configurao de mquina dinamicamente: utilize o Amazon
SimpleDB para buscar dados de configurao durante o tempo de inicializao de uma instncia (eg.
sequncias de conexo de banco de dados). O SimpleDB tambm pode ser usado para armazenar
informaes sobre uma instncia, como seu endereo IP, o nome da mquina e a funo.
4. Crie um processo de compilao que insira as ltimas verses em um bucket no Amazon S3. Faa o
download da verso mais recente de um aplicativo que ocorreu durante a inicializao do sistema.
5. Invista na construo de ferramentas de gerenciamento de recursos (Scripts automatizados, imagens
pr-configuradas) ou use ferramentas de gerenciamento de configurao inteligente de cdigo aberto
como Chef 18, Puppet19, CFEngine20 ou Genome21.
6. Inclua sistema operacional suficiente (JeOS 22) e suas dependncias de software em uma Amazon
Machine Image para que seja mais fcil gerenciar e manter. Passe parmetros ou arquivos de
configurao no momento da inicializao e recupere dados do usurio23 e metadados de instncia
aps a inicializao.
7. Reduza a agregao e o tempo de inicializao ao iniciar a partir de volumes do Amazon EBS24 e
anexar vrios volumes do Amazon EBS a uma instncia. Crie snapshots de volumes comuns e
compartilhe snapshots 25 entre contas, sempre que possvel.
8. Componentes do aplicativo no devem presumir integridade ou localizao do hardware no qual
esto sendo executados. Por exemplo, anexe dinamicamente o endereo IP de um novo n ao cluster.
Faa um failover automaticamente e inicie um novo clone em caso de falha.

Pense paralelo
A nuvem faz a paralelizao sem esforo. Se ela est solicitando dados de nuvem, armazenando dados para a nuvem,
processando dados (ou executando trabalhos) na nuvem, como um arquiteto de nuvem, voc precisar internalizar o
conceito de paralelizao ao projetar arquiteturas na nuvem. aconselhvel no apenas implementar a paralelizao
sempre que possvel, mas tambm automatiz-la pois a nuvem permite que voc crie um processo repetitivo
muito facilmente.

18

Mais informaes sobre o Chef podem ser encontradas em http://wiki.opscode.com/display/chef/Home

Mais informaes sobre o Puppet podem ser encontradas em http://reductivelabs.com/trac/puppet/
20
Mais informaes sobre o CFEngine podem ser encontradas em http://www.cfengine.org/
21
Mais informaes sobre o Genome podem ser encontradas em http://genome.et.redhat.com/
22
http://en.wikipedia.org/wiki/Just_enough_operating_system
23
Metadados de instncia e dados de usurios podem ser encontrados em
http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?AESDG-chapter-instancedata.html
24
Mais informaes sobre o recurso de Iniciar a partir do Amazon EBS podem ser encontradas em
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3121
25
Veja como compartilhar um Snapshot em http://aws.amazon.com/ebs/
19

Pgina 15 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Quando se trata de acesso a dados (recuperando e armazenando), a nuvem projetada para manipular operaes
massivamente paralelas. Para atingir o mximo desempenho e taxa de transferncia, voc deve aproveitar opedido de
paralelizao. Ao realizar o multi-threading de suas solicitaes usando threads simultneos armazenar ou buscar os
dados mais rapidamente do que solicita-los em sequncia. Assim, sempre que possvel, os processos de um aplicativo
em nuvem devem ser feitos de maneira segura para o thread atravs de uma filosofia de no compartilhamento e de
aproveitamento de multi-threading.
Quando se trata de processamento ou de solicitaes em execuo na nuvem, torna-se ainda mais importante aproveitar a
paralelizao. Uma prtica recomendada geral, no caso de um aplicativo da web, distribuir as solicitaes de entrada em
vrios servidores web assncronos usando o balanceador de carga. Em caso de aplicativo de processamento em lote, voc
pode dominar ns que podem gerar vrios ns de trabalho secundrio nessa tarefa de processos em paralelo (como em
estruturas de processamento distribudo como o Hadoop 26)
A beleza da nuvem aparece quando voc combina elasticidade e paralelizao. Seu aplicativo de nuvem pode trazer
um cluster de instncias de computao que provisionado em minutos com apenas algumas chamadas de API,
pode realizar um trabalho, executando tarefas em paralelo, pode armazenar os resultados e pode encerrar todas as
instncias. O aplicativo GrepTheWeb discutido em [6] um exemplo disso.
Tticas especficas da AWS para paralelizao:
1. Realize o lanamento de vrios threads de seu Amazon S3 conforme detalhamento no artigo sobre
Prticas recomendadas [2]
2. Realize o lanamento de vrios threads de suas solicitaes GET e BATCHPUT do Amazon SimpleDB [3]
[4] [5]
3. Crie um JobFlow usando o servio Amazon Elastic MapReduce para cada um dos seus processos dirios
de lote (indexao, anlise de logs, etc.) que calcularo o trabalho em paralelo e economizaro tempo
4. Use o servio do Elastic Load Balancing e distribua sua carga entre vrios servidores de aplicativos
web dinamicamente

Mantenha os dados dinmicos mais prximo da computao e os dados estticos mais

prximos do usurio final
Em geral uma boa prtica manter seus dados o mais prximo possvel para seus elementos de computao ou
processamento a fim de reduzir a latncia. Na nuvem, essa prtica recomendada ainda mais relevante e importante
porque muitas vezes voc tem de lidar com latncias de Internet. Alm disso, na nuvem, voc est pagando pela largura
de banda dentro e fora da nuvem por gigabyte de transferncia de dados e o custo pode aumentar muito rapidamente.
Se uma grande quantidade de dados que precisa ser processada reside fora da nuvem, pode ser mais barato e mais
rpido "enviar" e transferir os dados para a nuvem primeiro e, em seguida, fazer a computao. Por exemplo, no caso
de um aplicativo de armazenamento de dados, aconselhvel mover o conjunto de dados para a nuvem e, em seguida,
executar consultas paralelas com relao ao conjunto de dados. No caso de aplicativos web que armazenam e
recuperam dados de bancos de dados relacionais, aconselhvel mover o banco de dados, bem como o servidor
de aplicativo para a nuvem todos ao mesmo tempo.

26

http://hadoop.apache.org/

Pgina 16 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Se os dados so gerados em nuvem, em seguida, os aplicativos que consomem os dados tambm devem ser
implantados em nuvem para que eles possam aproveitar a transferncia de dados em nuvem e baixa latncia.
Por exemplo, no caso de um aplicativo web de e-commerce que gera logs e dados de sequncia de cliques,
aconselhvel executar o analisador de log e relatrio de motores em nuvem.
Por outro lado, se os dados so estticos e no mudaro com frequncia (por exemplo, imagens, vdeo, udio, PDFs,
JS, arquivos CSS), aconselhvel tirar proveito de um servio de entrega de contedo para que os dados estticos sejam
armazenadas em cache em um local perifrico mais prximo do usurio final (solicitante) diminuindo assim a latncia de
acesso. Devido ao cache, um servio de entrega de contedo fornece acesso mais rpido aos objetos populares.
Tticas especficas da AWS para implementar essa prtica recomendada:
1. Insira seus dados de discos rgidos no Amazon usando o servio de Import/Export27. Pode ser mais
barato e mais rpido para mover grandes quantidades de dados usando o sneakernet28 do que para
carregar usando a Internet
2. Utilize a mesma Zona de disponibilidade para lanar um cluster de mquinas
3. Crie uma distribuio de seu bucket do Amazon S3 e deixe o contedo dos caches do Amazon
CloudFront desse bucket em todos os 14 pontos de presena ao redor do mundo

Prticas recomendadas de segurana

Em um ambiente de multi-locatrio, arquitetos de nuvem frequentemente demonstram preocupaes com a segurana.
A segurana deve ser implementada em cada nvel da sua arquitetura de aplicativo em nuvem.A segurana fsica
normalmente abordada por seu provedor de servios (Whitepaper de segurana [7]), que um benefcio adicional
do uso da nuvem. Segurana de rede e de aplicativo de sua responsabilidade e voc deve implementar as prticas
recomendadas aplicveis ao seu negcio. Neste whitepaper, voc aprender sobre algumas ferramentas especficas,
recursos e orientaes sobre como proteger o seu aplicativo em nuvem no ambiente da AWS. recomendvel
aproveitar essas ferramentas e recursos mencionados para implementar a segurana bsica e ento implementar as
prticas recomendadas de segurana adicional usando os mtodos padro conforme apropriado ou como achar melhor.
Proteja seus dados em trnsito
Se voc precisar trocar informaes confidenciais entre um navegador e um servidor web, configure o SSL em sua
instncia de servidor. Voc precisar de um certificado de uma autoridade de certificao externa como o VeriSign29
ou o Entrust30. A chave pblica includa no certificado autentica o seu servidor para o browser e serve como base para
criar a chave de sesso compartilhada usada para criptografar os dados em ambas as direes.
Crie uma Virtual Private Cloud fazendo algumas chamadas de linha de comando (usando Amazon VPC). Isso permitir
que voc use os seus prprios recursos isolados logicamente dentro da nuvem da AWS e, em seguida, conecte esses
recursos diretamente ao seu prprio datacenter usando as conexes criptografadas IPSec VPN padro do setor.
Voc tambm pode configurar [15] um servidor OpenVPN em uma instncia de Amazon EC2 e instalar o cliente
OpenVPN em todos usurio dos PCs.

27

Mais informaes sobre o Amazon Import Export Services podem ser encontradas em http://aws.amazon.com/importexport
http://en.wikipedia.org/wiki/Sneakernet
29
http://www.verisign.com/ssl/
30
http://www.entrust.net/ssl-products.htm
28

Pgina 17 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Proteja seus dados em repouso

Se voc estiver preocupado sobre como armazenar dados confidenciais em nuvem, voc deve criptografar os dados
(arquivos individuais) antes de envi-los para a nuvem. Por exemplo, criptografar os dados usando qualquer ferramenta
de cdigo aberto31 ou comercial32 baseada em PGP antes de armazen-los como objetos do Amazon S3 e descriptograflo aps o download. Isso geralmente uma boa prtica ao criar aplicativos compatveis com HIPPA [8] que precisam
armazenar Informaes protegidas de sade (PHI).
No Amazon EC2, a criptografia de arquivo depende do sistema operacional. As instncias do Amazon EC2 que executam
o Windows podem usar o recurso interno do Encrypting File System (EFS) [16]. Este recurso abordar a criptografia e a
descriptografia de arquivos e pastas automaticamente e tornar o processo transparente para os usurios [19].
No entanto, apesar do nome, o EFS no criptografa o sistema de arquivos inteiro; em vez disso, ele criptografa arquivos
individuais. Se voc precisa de um volume completamente criptografado, considere o uso do produto de cdigo aberto
TrueCrypt33; ele se integrar muito bem com volumes do EBS formatados pelo NTFS. As instncias do Amazon EC2
executando Linux podem montar volumes do EBS usando sistemas de arquivo criptografado usando uma variedade de
abordagens (EncFS34, Loop-AES35, dm-crypt36, TrueCrypt37). Da mesma forma, as instncias do Amazon EC2 executando
o OpenSolaris podem aproveitar o ZFS38 Encryption Support [20]. Independentemente de qual abordagem voc escolha,
a criptografia de arquivos e volumes no Amazon EC2 ajuda a proteger os arquivos e os dados de log para que somente
os usurios e processos no servidor possam ver os dados em texto descriptografado, mas nada nem ningum fora do
servidor ver apenas os dados criptografados.
No importa qual sistema operacional ou tecnologia voc escolha, a criptografia de dados em repouso apresenta um
desafio: gerenciar as chaves usadas para criptografar os dados. Se voc perder as chaves, perder seus dados para
sempre e se as suas chaves forem comprometidas, os dados podem estar em risco. Portanto, certifique-se de estudar
os recursos de gerenciamento de chaves de qualquer produto que voc escolha e estabelea um procedimento que
minimize o risco de perda de chaves.
Alm de proteger os seus dados contra espionagem, tambm considere como proteg-los contra desastres. Tire
snapshots peridicos dos volumes do Amazon EBS para assegurar que altamente durvel e disponvel. Os snapshots
so incrementados naturalmente e armazenados no Amazon S3 (separar por geo-localizao) e podem ser restaurados
com alguns cliques ou chamadas de linha de comando.
Proteger suas credenciais da AWS
A AWS fornece dois tipos de credenciais de segurana: acessar chaves da AWS e certificados x.509. Sua chave de acesso
da AWS tem duas partes: sua ID de chave de acesso e sua chave de acesso secreta. Ao usar o REST ou a API de consulta,
voc tem que usar sua chave de acesso secreta para calcular uma assinatura para incluir no seu pedido de autenticao.
Para evitar a violao em curso, todas as solicitaes devem ser enviadas por HTTPS.

31

http://www.gnupg.org
http://www.pgp.com/
33
http://www.truecrypt.org/
34
http://www.arg0.net/encfs
35
http://loop-aes.sourceforge.net/loop-AES.README
36
http://www.saout.de/misc/dm-crypt/
37
http://www.truecrypt.org/
38
http://www.opensolaris.org/os/community/zfs/
32

Pgina 18 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Se sua Amazon Machine Image (AMI) est executando processos que precisam se comunicar com outros servios web
da AWS (sondagem a fila do Amazon SQS ou para ler objetos do Amazon S3, por exemplo), um erro de concepo
comum incorporar as credenciais AWS na AMI. Em vez de incorporadas as credenciais devem ser passadas como
argumentos durante o lanamento e a criptografia antes de serem enviados pela conexo [17].
Se sua chave de acesso secreta for comprometida, voc deve obter uma nova girando para uma nova39 ID de chave de
acesso secreta. Como uma boa prtica, recomendvel que voc incorpore um mecanismo de rotao de chaves em
sua arquitetura de aplicativo para que voc possa us-lo em uma base regular ou ocasionalmente (quando o funcionrio
insatisfeito deixa a empresa) para garantir que as chaves comprometidas no possam durar por muito tempo.
Como alternativa, voc pode usar os certificados x.509 para autenticao para determinados servios da AWS. O arquivo
de certificado contm sua chave pblica em um corpo de certificado DER codificado em base64. Um arquivo separado
contm a chave privada correspondente codificado em base64 PKCS#8.
A AWS oferece suporte a autenticao multi-factor40 como um protetor adicional para trabalhar com as informaes
de sua conta em aws.amazon.com e AWS Management Console41.
Gerencie vrios usurios e suas permisses com a IAM
O AWS Identity and Access Management (IAM)42 permite que voc crie vrios usurios e gerencie permisses para
cada um desses usurios a partir de sua conta da AWS. Um usurio uma identidade (dentro de sua conta da AWS)
com credenciais de segurana exclusivas que podem ser usadas para acessar os servios da AWS. O IAM elimina a
necessidade de compartilhar senhas ou chaves de acesso e facilita a ativao e a desativao de acesso de um Usurio,
conforme apropriado.
O IAM permite que voc implemente melhores prticas de segurana, tais como menor privilgio, conceder credenciais
nicas para cada usurio dentro de sua conta AWS e s conceder permisso para acessar os servios e recursos da AWS
necessrios para os usurios realizarem seu trabalho Como padro, o IAM seguro; os novos usurios no devem
acessar os recursos do AWS at que permisses sejam explicitamente concedidas.
A IAM integrada nativamente nos servios da AWS. Nenhuma API de servio foi alterada para oferecer suporte ao IAM
e aplicaes e ferramentas baseadas em APIs de servio da AWS que continuaro a funcionar quando o IAM estiver
sendo usado. Os aplicativos s precisam comear a usar as chaves de acesso geradas para um novo usurio.
Voc deve minimizar o uso de suas credenciais de conta AWS, tanto quanto possveis quando estiver interagindo com
seus servios AWS e aproveitar as credenciais de usurio IAM para acessar recursos e servios da AWS.
Proteja seu aplicativo
Cada instncia do Amazon EC2 est protegida por um ou mais Grupos de segurana43, chamado conjuntos de regras
que especificam em qual ingresso (ou seja, entrada) o trfego de rede deve ser entregue sua instncia. Voc pode
especificar portas TCP e UDP, tipos ICMP, cdigos e endereos de origem. Os grupos de segurana oferecem proteo
bsica com um firewall para instncias em execuo. Por exemplo, as instncias que pertencem a um aplicativo web
podem ter as seguintes configuraes de grupo de segurana:

39

http://aws.amazon.com/about-aws/whats-new/2009/08/31/seamlessly-rotate-your-access-credentials/
Mais informaes sobre o Multi-factor Authentication esto disponveis em http://aws.amazon.com/pt/mfa/
41
AWS Management Console http://aws.amazon.com/console/
42
Mais informaes em http://aws.amazon.com.com/iam
43
Mais informaes sobre o grupo de segurana esto disponveis em http://docs.amazonwebservices.com/AWSEC2/2009-0715/UserGuide/index.html?using-network-security.html
40

Pgina 19 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Figura4: Protegendo seu aplicativo web usando os grupos de segurana do Amazon EC2

Outra forma de restringir o trfego de entrada configurar firewalls baseados em software em suas instncias.
Instncias do Windows podem usar o firewall interno44. As instncias do Linux podem usar o netfilter45 e o iptables.
Ao longo do tempo, erros no software so descobertos e exigem patches de correo. Certifique-se de seguir as
seguintes orientao bsicas para maximizar a segurana do seu aplicativo:

Fazer downloads regularmente dos patches do site do fornecedor e atualizar suas AMIs
Reimplantar instncias de AMIs novas e testar os aplicativos para garantir que os patches no corrompem nada.
Certifique-se de que a AMI mais recente est implantada em todas as instncias
Investa em scripts de teste para que voc possa executar verificaes de segurana periodicamente e
automatizar o processo
Verifique se o software de terceiros est definido com as configuraes mais seguras
Nunca execute seus processos logado como raiz ou Administrador a menos que seja absolutamente necessrio

Toda as prticas segurana padro da era pr-nuvem como a adoo de boas prticas de codificao, isolamento os
dados confidenciais ainda so aplicveis e devem ser implementadas.
Em contrapartida, a nuvem retira a complexidade da segurana fsica e lhe d o controle atravs de ferramentas e
recursos para que voc possa proteger o seu aplicativo.

44
45

http://technet.microsoft.com/en-us/library/cc779199(WS.10).aspx, March 2003

http://www.netfilter.org/

Pgina 20 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Direes para pesquisas futuras

O dia no longe demais quando os aplicativos no esto mais ligados ao hardware fsico. Da mesma forma que para
ligar um microondas no necessrio qualquer conhecimento de electricidade, qualquer um deve ser capaz de conectar
um aplicativo em nuvem para receber a energia que ele precisa para executar, como um utilitrio. Como arquiteto, voc
ir gerir os recursos abstratos de computao, de armazenamento e de rede em vez de servidores fsicos. Os aplicativos
continuaro a funcionar mesmo se o hardware fsico subjacente falhar, for removido ou substitudo. Os aplicativos se
adaptaro aos padres de demanda flutuante por implantao de recursos instantaneamente e automaticamente,
alcanando assim nveis mais altos de utilizao em todos os momentos. Escalabilidade, segurana, alta disponibilidade,
tolerncia a falhas, capacidade de teste e elasticidade sero propriedades configurveis da arquitetura do aplicativo e
sero uma parte intrnseca e automatizada da plataforma na qual so criadas.
No entanto, ns no estamos l ainda. Hoje, voc pode criar aplicativos em nuvem com algumas dessas qualidades
implementando as prticas recomendadas destacadas no artigo. As prticas recomendadas em arquiteturas de
computao em nuvem continuaro a evoluir e como pesquisadores, no devemos apenas nos concentrar no
aprimoramento da nuvem, mas tambm na construo de ferramentas, tecnologias e processos que facilitaro
para desenvolvedores e arquitetos a conexo de aplicativos em nuvem.

Concluso
Este artigo forneceu orientaes prescritivas para arquitetos de nuvem para criar aplicativos de nuvem eficientes.
Concentrando-se em conceitos e prticas recomendadas, como projetar para falha, dissociao entre os componentes
do aplicativo, compreenso e implementao de elasticidade, combinando com a paralelizao e a integrao de
segurana em todos os aspectos da arquitetura do aplicativo, os arquitetos de nuvem podem compreender as
consideraes de design necessrias para criar aplicativos de nuvem altamente escalveis.
A nuvem da AWS oferece servios de infraestrutura altamente confiveis e voc s paga pelo o que usar. As tticas
especficas da AWS destacadas no artigo ajudaro no desenvolvimento de aplicativos em nuvem usando esses servios.
Como pesquisador, aconselhvel que voc utilize estes servios comerciais, aprenda com o trabalho dos outros,
amplie, melhore e invente computao em nuvem.

Agradecimentos
O autor profundamente grato a Jeff Barr, Steve Riley, Paul Horvath, Prashant Sridharan e Marvin Scot por fornecerem
comentrios sobre os primeiros rascunhos do presente artigo. Agradecimento especial a Matt Tavis por fornecer
informaes valiosas. Sem as suas contribuies, o artigo no teria sido possvel.
Parte do contedo deste whitepaper trecho de um captulo escrito pelo mesmo autor que aparece no livro 'Cloud Computing: Paradigms and
Patterns', Copyright 2010 John Wiley & Sons, Inc.

Pgina 21 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

Referncias e leitura complementar

1.

Amazon S3 Team, Prticas recomendadas para uso do Amazon S3,

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1904, 2008-11-26

2.

Amazon S3 Team, Amazon S3 Error Best Practices,

http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ErrorBestPractices.html, 2006-03-01

3.

Amazon SimpleDB Team, Query 201: Tips and Tricks for Amazon SimpleDB Query,
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1232&categoryID=176, 2008-02-07

4.

Amazon SimpleDB Team, Building for Performance and Reliability with Amazon SimpleDB,
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1394&categoryID=176, 2008-04-11

5.

Amazon SimpleDB Team, Query 101: Building Amazon SimpleDB Queries,

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1231&categoryID=176, 2008-02-07

6.

J. Varia, Cloud Architectures,

http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf, 2007-07-01

7.

Amazon Security Team, Overview of Security Processes,

http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf, 2009-06-01

8.

Amazon Web Services Team, Creating HIPPA-Compliant Medical Data Applications With AWS,
http://awsmedia.s3.amazonaws.com/AWS_HIPAA_Whitepaper_Final.pdf, 2009-04-01

9.

D. Obasanjo, Building Scalable Databases: Pros and Cons of Various Database Sharding Schemes,
http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSch
emes.aspx, 2009-01-16

10. D. Pritchett, Shard Lessons, http://www.addsimplicity.com/adding_simplicity_an_engi/2008/08/shard-lessons.html,

2008-08-24
11. J. Hamilton, On Designing and Deploying Internet-Scale Services, 2007, 21st Large Installation System Administration
conference (LISA O7), http://mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf
12. J. Dean and S. Ghemawat, MapReduce: Simplified data processing on large clusters2004-12-01, In Proc. of the 6th OSDI,
http://labs.google.com/papers/mapreduce-osdi04.pdf
13. T. Schlossnagle, Scalable Internet Architectures, Sams Publishing, 2006-07-31,
14. M. Lurie, The Federation: Database Interoperability,
http://www.ibm.com/developerworks/data/library/techarticle/0304lurie/0304lurie.html, 2003-04-23
15. E. Hammond, Escaping Restrictive/Untrusted Networks with OpenVPN on EC2, http://alestic.com/2009/05/openvpn-ec2,
2009-05-02
16. R. Bragg, The Encrypting File System, http://technet.microsoft.com/en-us/library/cc700811.aspx, 2009
17. S. Swidler, How to keep your AWS credentials on an EC2 instance securely,
http://clouddevelopertips.blogspot.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html, 2009-08-31
18. Amazon SQS Team, Building Scalable, Reliable Amazon EC2 Applications with Amazon SQS, http://sqs-publicimages.s3.amazonaws.com/Building_Scalabale_EC2_applications_with_SQS2.pdf, 2008
19. Microsoft Support Team, Best Practices For Encrypting File System (Windows), http://support.microsoft.com/kb/223316,
2009

20. Solaris Security Team, ZFS Encryption Project (OpenSolaris), http://www.opensolaris.org/os/project/zfs-crypto/, 2009-05-01

Pgina 22 de 23

Amazon Web Services Projetando para a nuvem: prticas recomendadas

Janeiro de 2010

21. Amazon RDS Team, Amazon RDS Multi-AZ Deployments,

http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/Concepts.DBInstance.html#Concepts.MultiAZ.
2010-05-15

22. Amazon SimpleDB Team, Amazon SimpleDB Consistency Enhancements

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3572 2010-02-24

Pgina 23 de 23