AWS – Economize com as instâncias reservadas!

Para quem usa AWS existem algumas estratégias para gerar economia ao usar instâncias do EC2 (Elastic Computing Cloud):

Continuar lendo

Anúncios

Aprenda mais sobre AWS no AWSHUB

Não é a primeira vez que falamos de AWS aqui neste blog. Portanto que fica claro que utilizamos este serviço de nuvem para hospedagem de uma série aplicativos.

Sendo a provedor que dispõe de uma gama enorme de serviços, denota que seus usuários precisam entender a fundo a motivação e as indicações de cada um deles.

Existe muita documentação disponível já nos meios oficiais da própria amazon, mas é sempre bom ter uma comunidade de apoio para que consigamos tirar dúvidas e claro, ter o aconselhamento de experts e demais usuários que já enfrentaram problemas parecidos com os nossos.

É para suprir este objeto dentro da comunidade brasileira que existe o AWSHUB.

O AWSHUB é um portal de informações sobre Amazon Web Services voltado para a comunidade brasileira.

Nele podemos encontrar mais documentação, tutoriais, videos e webinars e um fórum cheio de gente competente e disposta a ajudar a resolver nossos problemas. Tem ainda um programa de reconhecimento sob exame que permite que você teste seus conhecimentos sobre AWS nas diversas áreas a que ela se propõe.

Se você tem interesse sobre o assunto, não deixe de participar.

Até mais

Escalando Horizontalmente – AWS Auto Scaling – Parte#1

Finalmente depois de alguns aprendizados e experiências chegou a hora de compartilharmos um pouco sobre Amazon Web Services. Vamos então falar sobre  escalar de forma horizontal utilizando o serviço Auto Scaling da AWS. Para aqueles que não conhecem o AWS Auto Scaling indico fortemente dar uma boa leitura na vasta documentação do serviço que aborda desde conceitos básicos de utilização até mesmo referencias da API.

Outra dica também é assistir a palestra realizada no uMov.Me Labs Summit realizado em Abril 🙂

Para interagirmos com os serviços web services da Amazon relacionados a política de Auto Scaling podemos escolher basicamente entre:

  • SDK – Utilizando a API de desenvolvimento da AWS disponível hoje para as principais linguagens de programação como Java, .Net, Ruby, PHP, Node.JS e também plataformas móveis como Android, iOS. Através da API de desenvolvimento é possível interagir diretamente com os web services da Amazon, manipulando grande parte dos serviços oferecidos via console de gerenciamento.
  • Command Line Tools – Grande amigo dos SysAdmins, o Command Line Tools, veio para facilitar a interação com os principais serviços disponíveis pela AWS, onde sem precisar desenvolver nenhuma linha de código ou instanciar nem objeto é possível gerenciar sua infraestrutura usando apenas o terminal.

Neste primeiro exemplo iremos adotar o Command Line Tools como ferramenta para criarmos uma política de auto scaling. Nesta abordagem iremos fazer com que nossa infraestrutura esteja preparada para escalar de forma horizontal. É possível utilizando o serviço Auto Scaling prever períodos de grande utilização de uma determinada aplicação ou serviço, mas também simplesmente reduzir o número de instancias durante os períodos de inatividade das mesmas, impactando diretamente assim nos custos com infraestrutura.

Através de alguns poucos passos utilizando o Command Line Tools você poderá obter significativa redução no seu bolso ao final do mês. Então chega de bla bla bla e vamos ao que interessa: Setup:

  1. Para iniciar realize o download da ferramenta Command Line Tools de Auto Scaling;
  2. Uma vez descompactado o arquivo, será criada a pasta ‘AutoScaling-xxx’. Iremos seguir os passos descritos na seção “Installation” do arquivo README.TXT situado dentro da pasta descompactada, setando assim todas as variáveis de ambiente necessárias para rodarmos os scripts;
  3. Agora é a vez de obter suas chaves de segurança da AWS para conseguirmos interagir com a API da AWS. Para obter as suas credenciais basta acessar as configurações da sua conta e obter as duas chaves(Chave de acesso, Chave de acesso secreta).
  4. Com as chaves em mãos, basta seguir a seção “Using AWS Keys” do arquivo README.TXT situado dentro da pasta descompactada.
  5. Para ter certeza de que tudo está funcionando corretamente digite no terminal o comando “as-cmd”. Se todos os passos foram seguidos corretamente você verá uma lista com os comando disponíveis da ferramente de auto scaling via Command Line Tools.
  6. Dúvidas?

Escalando:

  1. O primeiro passo a ser realizado basicamente irá identificar qual AMI(Amazon Machine Images) servirá de base para criar novas VMs quando necessário. Para isso basta executar o comando abaixo:  
    as-create-launch-config my_config --image-id ami-xxxxxxxx --instance-type m1.micro
  2. Uma vez criada a configuração de inicialização de novas VMs, precisamos informar agora através da criação de um novo grupo de auto scaling em quais zonas estas VMs devem ser criadas. Algumas outras informações importantes são número mínimo e máximo de VMs bem como para qual ELB(Elastic Load Balancer) estas VMs devem ser atribuídas. Crie um novo grupo executando:
    as-create-auto-scaling-group my_as_group --launch-configuration my_config --availability-zones us-east-1a us-east-1b --min-size 2 --max-size 20 --load-balancers MyLB
  3. Para que possamos iniciar uma nova VM e desta forma escalar horizontalmente é necessário a criação de políticas de auto scaling. Desta forma criaremos uma política para adicionar novas VMs respondendo ao load balancer associado. Para isso precisamos executar o comando:
    as-put-scaling-policy scale_up --auto-scaling-group my_as_group --adjustment=1 --type ChangeInCapacity --cooldown 300
  4. Uma vez incrementado o número de VMs e satisfeito o aumento na demanda das aplicações, você também pode ter uma política de auto scaling para desligar VMs uma vez identificado baixo tráfego de requisições através do ELB em questão. Semelhantemente ao passo 3 iremos criar uma nova política, porém agora estaremos subtraindo uma VM de modo a economizar recursos não utilizadas executando o comando:
    as-put-scaling-policy scale_down --auto-scaling-group my_as_group --adjustment=-1 --type ChangeInCapacity  --cooldown 300

    Você ainda pode resolver diminuir o número de VMs após o horário comercial onde o volume de acessos diminui consideravelmente e através do monitoramento de memória ou CPU indicam inatividade de algumas VMs. Mas este é um assunto para o próximo post, AWS Auto Scaling – Parte#2 🙂

  5. Vamos testar? Uma vez que não atrelamos nenhuma rotina de monitoramento onde poderíamos criar e remover instancias automáticamente, podemos criar e remover instancias manualmente através do comando “as-execute-policy“.
  • Baseado na política para criar VMs podemos executa-la assim:
    as-execute-policy --name scale_up --auto-scaling-group my_as_group
  • Baseado na política para remover VMs podemos executa-la assim:
    as-execute-policy --name scale_down --auto-scaling-group my_as_group

Desta forma temos uma primeira política de auto scaling! Em um próximo post estaremos explicando como automatizar a criação e remoção de VMs utilizando o serviço AWS CloudWatch. #ficadica

Aumentar capacidade de processamento sem aumentar memória ou adicionar servidores? Processamento assíncrono!

Quando desenvolvemos uma solução de software, queremos que ela tenha desempenho, seja escalável, tenha disponibilidade, e que principalmente que ela consiga garantir qualidade na experiência que o usuário vai ter usando o produto em questão.

Aí alguns já parquem para a parte técnica, querendo usar resquehornetQamazon sqs,msmq, entre outros. Mas antes precisamos entender contexto, e saber qual é a solução que melhor pode nos atender neste contexto. Uma simples simulação de fila de jobs em banco de dados pode ser uma solução útil e funcional. O ponto é que quando começamos a falar de mensageria, e processamento assíncrono, não é apenas o processamento de filas que aparece.

Temos uma série de operações que podemos realizar com filas, sejam em processos de transformação, tradução, redirecionamento, quebrando grandes mensagens em pequenos batches de processamento, enfim. Entram os Enterprise Architecture Patterns. Que são importantíssimos quando estamos pensando em requisitos não funcionais de aplicações.

Quero abrir o assunto mensageria neste post, e falar de algumas soluções que estamos colocando em teste dentro do time. O processamento de jobs e novos testes de escalabilidade. Queremos ganhar em desempenho, mas sem nos preocupar com infra estrutura. Apesar de podermos ser elásticos ou ganhar em escala horizontal com novos nós de processamento, queremos poder continuar com a mesma infra estrutura e otimizar recursos computacionais.Note o uso correto da palavra recurso. 🙂

Então nós próximos posts, eu vou tratar de dois tópicos:

  • Processamento de Jobs e formas de tratar isto em um aplicativo web. Neste caso vou brincar com o Quartz. A galera da Caelum já fez um post bem legal sobre o assunto.
  • Amazon SQS, que é o serviço de filas da Amazon. Também vou falar de soluções mais tradicionais para isto, exemplo HornetQ da JBoss.

Para entender um pouquinho do quanto é difícil 🙂 usar o SQS, depois de fazer download doClient Java da Amazon, eu tive que fazer o seguinte para testar:

  1. criar uma instância do AmazonSQSClient.
  2. criar uma fila. Depois de criar uma fila, recebemos de volta uma URL para poder acessar a fila em questão. Duas linhas de código são necessárias para isto.
  3. enviar uma mensagem, usando um comando sendMessage, passando por parâmetro a URL da fila em questão, e o texto. Passe o que você quiser, mas normalmente enviamos um documento XML ou JSON para servir de idioma da fila. Cada fila possui uma expectativa de conteúdo, e cada aplicativo cliente sabe o que esperar dentro da fila.
  4. receber a mensagem, e neste caso importante garantir a questão de escala. Podemos fazer uma requisição indicando o número máximo de mensagens que queremos recuperar da fila em questão. Exemplo, no máximo 10. Imaginando que você tem muito trabalho para fazer em várias filas diferentes, esta abordagem permite que possamos realizar um pouco de processamento, mas sem ficar “trancado”.
  5. excluir a mensagem da fila depois de processar. Toda mensagem possui um ID e é através dele que podemos requisitar que a mensagem seja removida da fila. Funciona como um “ack”.
  6. depois de “limpar” a fila, consumindo todas mensagens, no meu exemplo eu removo a própria fila, criada no passo 2. Para isto tem um comando deleteQueue, onde passo a URL da fila que desejo remover.

Então é por aí. Em 6 passos, e algumas linhas de código podemos fazer um exemplo bem legal brincando com o SQS. Lembrando que sempre que você trabalhar com Amazon Web Services, remova o que você criar para não ser tarifado.

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

Armazenando arquivos no AWS/S3

Um dos serviços legais que o AWS possui é o S3 (Simple Storage Service), o serviço de armazenamento. 

O S3 é focado e ideal quando precisamos gravar um arquivo apenas 1 vez, e ler várias vezes. Ele não garante que se você atualizar um objeto com a mesma chave, que ao ler, a última versão será recuperada.

O benefício é que pagamos por Gb hospedado nos servidores da Amazon. 

Ainda podemos escolher o tipo de redundância que queremos ter. Se o dado que você armazena por lá é uma cópia de uma informação que você possui em outros servidores, e pode facilmente “recriar”, é possível armazenar os documentos usando Reduced Redundancy Storage (RRS), e os preços neste caso são diferentes.

Estou testando algumas bibliotecas Java para acessar o S3. Uma que vou testar JetS3t.

O legal é que todo serviço da Amazon possui uma API, então tudo o que podemos fazer manualmente, podemos fazer programando. E para alguns serviços certar funcionalidades só vão aparecer se estivermos programando. Então mão na massa. 

Para começar, no melhor estilo observar, copiar e criar, comecei testando uma API biblioteca de apoio que me chamou a atenção por poder rodar tanto em JavaSE como JavaME. Esta lib é bem legal, mas possui algumas limitações, como não poder escolher a região do S3 onde se quer armazenar a informação (ele sempre vai no Standard) e não estar pronto para tornar o objeto público. Nada que um pequeno hacking no fonte não resolva. Ainda assim o exemplo é importante para aprender o básico das requisições. 

O que se precisa para poder programar este exemplo? Bom, (a) de uma conta no AWS, e (b) access keys para poder chamar as requisições. 

Neste meu exemplo faço um upload e um download de uma imagem, fazendo a operação completa… criar bucket, enviar arquivo, baixar arquivo, remover arquivo, remover bucket. 

Bucket… é o nome que o AWS dá para a nossa área. Um bucket possui um nome único e único em todo o S3. Verifiquei isto quando fui criar um bucket “teste” e ele já existia. 🙂

Aqui se tem uma ideia meu exemplo, que usei para testar a história toda. 

 

String accessKeyId = “access-key-da-aws-da-sua-conta”;
String secretKey = “secret-key-da-aws-da-sua-conta”;
S3 s3 = new S3(S3.HTTPS_URL, accessKeyId, secretKey);
String bucketName = “danielwildt” + System.currentTimeMillis();
s3.createBucket(bucketName);
String fileName = “/users/dwildt/pasta/arquivo-para-teste.jpg”;
String fileNameDecode = “/users/dwildt/pasta/arquivo-para-teste-back.jpg”;
String key = “pasta/nome-arquivo-no-aws.jpg”;
String data = readFileAsString(fileName);
s3.putObjectInline(bucketName, key, data);
S3Object s3Image = s3.getObject(bucketName, key);
saveImageFromString(s3Image.getData(), fileNameDecode);
s3.deleteObject(bucketName, key);
s3.deleteBucket(bucketName);

 

Então esta lib que testei é capaz de fazer estas operações. Ela também consegue listar objetos. O S3 tem uma regra que ele apenas lista 1000 objetos por vez, e funciona em um processo de paginação. Esta biblioteca não tem este poder. No meu caso eu não tenho este “problema”, pois eu preciso apenas enviar e recuperar objetos. E eu sempre sei o nome do objeto que quero buscar. 

Bom, próximos passos? Faça download da biblioteca de exemplo. Ainda não parei para subir este meu fonte de teste, mas em breve coloco ele no github. Uma dica é que para fazer a chamada do “putObjectInline” é necessário fazer um encode dos dados do arquivo. Teste enviar sem fazer isto para ver o erro. Isto é importante para qualquer situação futura. No exemplo abaixo tem um pedaço de código que faz isto. 

 

private String readFileAsString(String filePath) {
  //… tratamento de exceções e etc… 
  byte[] buffer = new byte[(int) new File(filePath).length()];
  FileInputStream f = new FileInputStream(filePath);
  f.read(buffer);
  String encodedImage = Base64.encodeBytes(buffer);
  //… tratamento de exceções e etc… 
  return encodedImage;
}

 

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

Conectando em instâncias AWS/EC2 – erro “Permission Denied (public key)”

E vamos para mais um artigo sobre Amazon Web Services! A propósito, já viu que tem um fórum em português de AWS? 

Quando queremos conectar em uma instância EC2 que criamos, acessamos o console do EC2, e selecionamos a instância que queremos conectar (na área Instances). Com isto nas ações da instância (Instance Actions), aparece o menu “Connect”. Ao fazer isto vai aparecer algo como:

ssh -i nome-arquivo.pem root@id-da-instancia.compute-1.amazonaws.com

O arquivo .pem é da chave de acesso. Você fez download dele quando criou a sua instância. 

O usuário de login pode modificar. Exemplo, usando os AMIs padrões da Amazon o usuário será ec2-user, se você usar uma AMI Ubuntu, normalmente o usuário será ubuntu, se usar alguma AMI da Bitnami, o usuário será bitnami. Nas Red Hat AMIs, normalmente será usado root. 

Depois o endereço da instância é o endereço atual da mesma. Lembre que sempre que você para e inicia uma instância ela ganha um novo endereço. Para manter sempre o mesmo endereço você precisa ter um Elastic IP associado. 

Bom, vamos a situação… quando fiz acesso via SSH recebi um “Permission Denied (public key)“. Revisei tudo que tinha feito, olhei na internet e depois voltei a revisar o meu passo a passo. 

O ponto é que sempre que criamos uma instância, temos que selecionar um Security Group.

Manualmente eu sempre tomei cuidado de criar security groups separados para cada tipo de instância. Só que neste teste que acabou “gerando” a mensagem de erro, eu criei a instância usando o ec2 console tools.

O ponto foi que o security group que estava sendo usado pela instância criada, não estava com a porta 22 liberada! Como eu sempre liberei a porta nos security groups, nunca tinha visto esta mensagem de erro. Por isto que eu sempre falo da importância do Test First, onde podemos ver uma falha, aprender e evoluir.  

Então qual foi a solução? Adicionar a porta de SSH, no caso a porta 22. E também aproveitei para adicionar a porta 80 que eu iria precisar usar. Este teste envolvia um servidor LAMP (Linux, Apache, MySql, PHP). Coloquei uma imagem com as configurações do security group. Com isto garanto que apenas o acesso via SSH e o acesso HTTP está funcionando para a instância em teste. 

Security-group

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

Amazon Web Services (aws) – Criando um storage usando Red Hat Enterprise Linux (RHEL)

Fizemos um post falando sobre como usar storages na Amazon. Naquele teste usamos o Linux da Amazon. Fazendo um novo teste usando Red Hat Enterprise Linux (RHEL), o resultado não foi o mesmo. Mostro aqui alguns detalhes para podermos fazer o attachment corretamente.

Ao ver os filesystems disponíveis não temos nada disponível:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            5.7G  1.9G  3.8G  34% /
none                  296M     0  296M   0% /dev/shm

 

No teste foi feito um attachment em /dev/sdj, mas ao buscar nas partições ou através de um fdisk, ela não aparece.

# cat /proc/partitions
major minor  #blocks  name
 202       65    6291456 xvde1
 202      464    1048576 xvdad

Como comentado, o mesmo no fdisk:

# fdisk -l
Disk /dev/xvde1: 6442 MB, 6442450944 bytes

Disk /dev/xvdad: 1073 MB, 1073741824 bytes

A diferença em questão é que aparece um filesystem com 1GB que foi o espaço que tinha alocado para fins de teste. Então o /dev/xvdad é o que estamos procurando. Vamos seguir nos passos do post anterior, agora com a identificação que encontramos.

mkfs -t ext3 /dev/xvdad
echo “/dev/xvdad  /bkp  ext3     noatime  0 0” >> /etc/fstab
mkdir /bkp
mount /bkp

E para fechar executamos um df para ver o que temos definido:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            5.7G  1.9G  3.8G  34% /
none                  296M     0  296M   0% /dev/shm
/dev/xvdad           1008M   34M  924M   4% /bkp

Era isto. O filesystem /dev/xvdad está montado em /bkp. 

Este ponto de dúvida eu tinha levantado no fórum da AWS, que já deixo como dica para trocar ideias com a comunidade. Aproveitei para explicar por lá o que eu tinha feito.  

E para fechar, fica a dica deste artigo do José Papo sobre o que é cloud computing. Neste post achei uma referência muito legal, sobre o que realmente precisamos estar atentos! Em saber diferenciar virtualização de cloud computing. Até a próxima! 

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.