Migre seu aplicativo Linux à nuvem Amazon – Parte 01

A computação em nuvem e Infrastructure as a Service (IaaS) são bem
documentadas, mas o que não é frequentemente discutido é como
fazer com que um aplicativo seja executado em um ambiente de
nuvem. Nesta primeira parte da série, vamos começar a acompanhar as etapas para uma migração direta de um servidor
físico para um servidor em nuvem.

Infrastructure as a Service (IaaS) é um excelente conceito:
Você usa recursos de computações; você paga por
eles. Você deseja mais poder de computação; você
paga mais. A desvantagem desse modelo é que você
trabalha com computadores que nunca verá ou
conhecerá muito bem. Uma vez que isso tenha sido
superado, no entanto, há muito a ganhar usando IaaS.

Como o modelo IaaS é tão diferente do modelo tradicional de
aquisição de servidores, a forma de gerenciamento de
seus computadores virtuais é diferente. A forma como
você executa seu aplicativo na nuvem também é
diferente. Coisas que eram consideradas constantes,
como latência insignificante entre servidores, não
são mais certas.

Trabalhando com Amazon EC2

O Amazon EC2 permite que qualquer pessoa com um cartão de
crédito pague por servidores por hora, ligando-os ou
desligando-os por meio de um application programming
interface (API). Você tem uma variedade de tipos de
servidores entre os quais escolher
dependendo se sua preocupação principal for memória,
disco ou poder de CPU juntamente com um
pacote de complementos, de discos persistentes a
balanceadores de carga. Você paga somente pelo que
usar.

Além da oferta do Amazon EC2, existem outras que lhe dão,
entre outras coisas, processamento de pagamentos,
bancos de dados e enfileiramento de mensagens. Nesta
série de artigos, você usará o Amazon Simple Storage
Service (Amazon S3), que dá acesso a espaço em disco
com pagamento pelo uso.

O exemplo de aplicativo

O aplicativo da web que esta série usa como exemplo é um
serviço de folha de pagamento chamado
SmallPayroll.ca, escrito com a estrutura
Ruby on Rails e um backend PostgreSQL. É típico de
muitos aplicativos da web: tem uma camada de banco
de dados, uma camada de aplicativos e um conjunto de
arquivos estáticos, como arquivos de cascading style
sheet (CSS) e JavaScript. Os usuários navegam por
vários formulários para inserir e manipular dados
além de gerar relatórios.

Os vários componentes em uso são:

• Nginx. O servidor web front-end para
  arquivos estáticos e balanceador para camada
  intermediária.
• Mongrel. O servidor de aplicativos
  propriamente dito.
• Ruby. A linguagem em que o aplicativo é
  escrito.
• Gems. Plug-ins e bibliotecas de terceiros
  para tudo, de criptografia de banco de dados a
  monitoração em nível de aplicativo.
• PostgreSQL. O mecanismo de banco de dados
  Structured Query Language.

O uso do site excedeu a capacidade do único servidor que o
armazena no momento. Portanto, é preciso uma
migração para um novo ambiente, e essa é uma
oportunidade excelente para mover-se para a nuvem.

Melhorias desejadas

Mas simplesmente mover-se de um servidor para um pequeno número
de servidores com base na nuvem não tiraria vantagem
do que pode ser feito na nuvem, nem resultaria em
uma leitura emocionante. Portanto, durante a
movimentação, você fará algumas melhorias, algumas
das quais só são possíveis em um ambiente de nuvem:

• Maior confiabilidade. Como você pode
  escolher o tamanho do servidor a executar na
  nuvem, é possível executar vários servidores
  menores para obter redundância.
• Capacidade para escalamento para baixo e para
  cima. Servidores são adicionados de forma
  incremental ao conjunto à medida que o serviço
  cresce. No entanto, o número de servidores também
  pode ser aumentado para acomodar picos de curto
  prazo em tráfego ou diminuído durante períodos de
  baixo movimento.
• Armazenamento em nuvem. Backups dos dados
  do aplicativo serão feitos no Amazon S3,
  eliminando a necessidade de armazenamento em fita.
• Automação. Tudo no ambiente Amazon
  dos servidores ao armazenamento e aos
  balanceadores de carga pode ser
  automatizado. menos tempo gerenciando um
  aplicativo significa mais tempo para outras coisas
  mais produtivas.

Estratégias de teste e migração

Ao implementar um aplicativo pela primeira vez, geralmente
você pode se dar ao luxo de poder testá-lo e
ajustá-lo sem o peso do tráfego de produção. Em
contraste, ao migrar um aplicativo, você tem o
desafio de usuários que colocam uma carga no site.
Uma vez que o novo ambiente recebe tráfego de
produção, os usuários esperarão que tudo funcione
adequadamente.

Uma migração não significa necessariamente tempo de
inatividade zero. É muito mais fácil se você puder
colocar o serviço off-line por um período de tempo. Ainda é possível usar essa janela de inatividade para
realizar sincronizações finais de dados e permitir
que quaisquer mudanças na rede se estabilizem.

A
janela não deverá ser usada para realizar a
implementação inicial para o novo ambiente
ou seja, o novo ambiente deverá estar em um estado
operacional antes que a migração do aplicativo
inicie. Com isso em mente, os pontos-chave são a
sincronização de dados entre os ambientes e as
mudanças na rede.

Ao planejar sua estratégia de migração, ajuda iniciar com um
detalhamento de seu ambiente atual. Responda às
seguintes perguntas:

• Que software uso em meus servidores para
  executar o aplicativo?
• Que software uso em meus servidores para
  gerenciar e monitorar os recursos do servidor e do
  aplicativo?
• Onde são mantidos todos os dados dos usuários?
  Em bancos de dados? Em arquivos?
• São ativos estáticos, como imagens, CSS e
  arquivos JavaScript, armazenados em outro local?
• De que pontos de contato com outros sistemas o
  aplicativo precisa?
• Fiz backup de tudo recentemente?

Notificando os usuários

Em geral, notificar seus usuários é uma coisa boa, mesmo que
não antecipe qualquer tempo de indisponibilidade. No
caso do aplicativo SmallPayroll.ca, os usuários
tendem a usar o site em um intervalo consistente,
correspondente a seu ciclo de folha de pagamento de
duas semanas. Portanto, um aviso com antecedência de
duas semanas seria um período razoável.

Sites como o
Google AdWords, que é a interface administrativa da
plataforma de publicidade do Google, avisam com
cerca de uma semana de antecedência. Se seu site for
mais um site de notícias, cuja retirada do ar por
uma hora não prejudicaria tanto os usuários, você
poderá escolher notificar no dia da
indisponibilidade.

A forma da notificação também varia dependendo da natureza de
seu site e como você se comunica atualmente com seus
usuários. Para o SmallPayroll.ca, uma mensagem
destacada quando o usuário efetuar login será
suficiente. Por exemplo, uma mensagem parecida com
“O sistema estará indisponível entre 0h01 e 1h,
horário do Leste dos EUA, em 24 de junho de 2010.
Todas as informações inseridas antes desse horário
serão salvas. Para obter mais informações, clique
aqui.” Essa mensagem fornece três informações chave
que os usuários precisam saber:

• Quando a indisponibilidade ocorrerá, incluindo o
  fuso horário
• Tranquilização de que seus dados estarão a
  salvo
• Indicação do local de informações
  adicionais

Se possível, evite usar 0h ou 12h, incluindo o termo
meia-noite. Eles tendem a confundir as
pessoas, pois muitos não têm certeza se meia-noite
do dia 17 de junho refere-se ao início do dia (0h01)
ou tarde da noite (23h59). De forma similar, muitos
não têm certeza se meio-dia significa 0h ou 12h. É
muito mais fácil adicionar um minuto e tornar o
horário não ambíguo.

Seus detalhes poderão ser diferentes, especialmente se
antecipar funcionalidade parcial durante a
indisponibilidade. Se você decidir que colocará a
notícia somente durante a indisponibilidade (como
para um site de notícias), as mesmas informações
ainda serão úteis. Minha tela favorita de
indisponibilidade de site era algo parecido com “O
site está fora do ar para manutenção; retornará por
volta de 15h. EST. Jogue Asteroids enquanto
espera!”

Não negligencie também seus usuários internos. Se tiver
representantes de contas, será preciso avisá-los
caso seus clientes façam perguntas.

Considerações sobre DNS

O sistema de nome de domínio (DNS) encarrega-se de traduzir
um nome como www.example.com em um endereço
IP como 192.0.32.10. Seu computador conecta-se a
endereços IP, portanto essa tradução é importante.
Ao migrar de um ambiente para outro, é quase certo
que você usará um endereço IP diferente (a exceção
seria se permanecesse no mesmo prédio físico).

Computadores armazenam em cache o mapeamento nome-para-IP por
um certo período de tempo, conhecido como time
to live (TTL), para reduzir o tempo de
resposta geral. Ao trocar de um ambiente para o
outro e, portanto, de um endereço IP para
outro, pessoas que tenham a entrada de DNS
armazenada em cache continuarão a tentar usar o
ambiente antigo. A entrada de DNS para o aplicativo
e seu TTL associado deverão ser gerenciados
cuidadosamente.

TTLs são tipicamente entre uma hora e um dia. Como preparação
para a migração, no entanto, é melhor que a TTL seja
um tempo curto, como 5 minutos. Essa alteração
deverá ser feita pelo menos um período de TTL antes
do horário previsto para alteração do endereço, pois
os computadores obtêm o TTL juntamente com o
mapeamento nome-para-IP. Por exemplo, se o TTL para
www.example.com estivesse definido para 86.400
segundos (um dia), seria preciso redefinir o TTL
para 5 minutos pelo menos um dia antes da migração.

Desacoplando os ambientes novo e antigo

É essencial testar completamente seu novo ambiente antes da
migração. Todos os testes deverão ocorrer em
isolamento do ambiente de produção, preferivelmente
com uma captura instantânea dos dados de produção
para que possa exercitar melhor o novo ambiente.

Realizar um teste completo com uma captura instantânea dos
dados de produção serve a dois propósitos. O
primeiro é que é mais provável de encontrar erros se
estiver usando dados do mundo real, pois são mais
imprevisíveis do que dados de teste usados durante o
desenvolvimento. Dados do mundo real
poderão fazer referência a arquivos que você se
esqueceu de copiar ou que requeiram certas
configurações que foram esquecidas durante o
detalhamento.

O segundo motivo para usar dados de produção é que você
poderá praticar a migração ao mesmo tempo em que
carrega dados. Você deverá ser capaz de provar a
maioria dos aspectos de seu plano de migração,
exceto pela troca real dos ambientes.

Mesmo que esteja trabalhando em seu novo ambiente como se
fosse produção, somente um ambiente pode ser
associado com o nome de host do aplicativo. A forma
mais fácil de resolver esse requisito é fazer uma
substituição de DNS em seu arquivo hosts. No
UNIX, esse arquivo reside em /etc/hosts; no
Windows, ele reside em
C:\windows\system32\drivers\etc\hosts.

Simplesmente
siga o formato das linhas existentes e adicione uma
entrada apontando o nome de host do aplicativo para
seu futuro endereço IP. Não se esqueça de fazer o
mesmo para quaisquer servidores de imagem ou
qualquer outra coisa que vá mover. Provavelmente
será necessário reiniciar seu navegador, mas, depois
disso, poderá inserir sua URL de produção e ser
levado a seu novo ambiente.

Uma base do Amazon EC2

O serviço Amazon EC2 permite pagar por uma máquina virtual
(VM) por hora. O Amazon oferece diferentes tipos de
máquinas e as classifica por perfis de CPU, memória
e disco. O Amazon também mede memória e disco em termos de
gigabytes e CPU em termos de Amazon EC2 Compute
Units (ECU), onde 1 ECU é, aproximadamente, um
processador AMD Opteron ou Intel® Xeon® de
1.0 a 1.2GHz (era 2007).

Por exemplo, a instância
pequena padrão oferece 1,7 GB de memória, 160 GB de
espaço em disco e 1 ECU de CPU. No momento em que
este artigo foi escrito, a maior máquina era
High-memory Quadruple Extra Large, com 68,4 GB de
memória, 1,7 TB de espaço em disco e 26 ECUs
divididas em oito núcleos virtuais. Os preços variam
de 8,5 centavos de dólar por hora para o menor e
2,40 dólares por hora para o maior.

Uma instância do Amazon EC2 começa como uma Amazon Machine
Image (AMI), que é um modelo que você usa para
construir qualquer número de VMs. O Amazon publica
algumas AMIs, e é possível fazer sua própria e
compartilhá-la com outros. Algumas das AMIs criadas
por usuários estão disponíveis sem custo; algumas
incorrem em cobrança por hora, além da cobrança por
hora do Amazon. Por exemplo, a IBM publica várias
AMIs pagas que permitem o pagamento da licença por
hora.

Quando quiser inicializar uma VM, você escolhe o tipo de
máquina e uma AMI. A AMI é armazenada no Amazon S3 e
copiada para a partição raiz de sua VM ao iniciar a
instância. A partição raiz é sempre de 10 GB. O
espaço de armazenamento associado com o tipo da
máquina é chamado de armazenamento da
instância ou armazenamento efêmero e
é apresentado em sua VM como uma unidade separada.

O
armazenamento é chamado de efêmero porque,
ao desligar sua instância, as informações são
perdidas para sempre. É preciso fazer backup
periodicamente de seus dados para proteger-se contra
perda. Isso também significa que, se o host físico
executando sua instância travar, sua instância é
desligada e o disco efêmero é perdido.

A Amazon Machine Image

Todas as AMIs têm um identificador atribuído pelo Amazon,
como ami-0bbd5462. O Amazon fornece algumas
AMIs públicas e outras pessoas tornaram suas
próprias AMIs públicas. É possível escolher começar
com uma AMI pública e fazer suas próprias
modificações ou pode começar do zero. A qualquer
momento que fizer alterações no sistema de arquivos
raiz de uma AMI, é possível salvá-la como uma nova
AMI, o que é chamado de
reempacotamento.

Nesta série, você começará com uma imagem do CentOS
publicamente disponível, mas é possível escolher uma
imagem diferente. É bom gastar algum tempo
verificando qualquer imagem que usar para
assegurar-se de que não existam contas extras e de
que os pacotes estejam atualizados. Também é
possível montar sua própria AMI do zero, mas isso abordaremos mais adiante.

Confira no próximo artigo a continuação do assunto, com todas as funcionalidades necessárias para iniciar, parar e
usar a nuvem do Amazon EC2, com o passo a passo completo das configurações para API além de todos os recursos necessários para sua implementação. Até a próxima!

artigo publicado originalmente em developerWorks Brasil, por Sean Walberg

Sean Walberg trabalha com Linux e UNIX desde 1994 em ambientes
acadêmicos, corporativos e de provedores de serviço de Internet.
Escreveu muito sobre administração de sistemas nos últimos anos. Entre em contato com o autor através do email: sean@ertw.com.