NoSQL e AWS DynamoDB

NoSQL tem sido um dos assuntos mais badalados ultimamente no meio de arquitetura de software. Existem discussões calorosas dos novos apaixonados em contraponto aos que acreditam que o uso desse tipo de abordagem se limita a casos extremos, e que estes não estão presentes na maioria dos cenários do dia-a-dia.

Independente de minha opinião sobre isso, acima de tudo, acredito que devemos conhecer as características deste tipo de estratégia e claro, entender o que cada uma destas ferramentas pode nos oferecer. Afim de tomar boas decisões no que diz respeito a melhor solução para cada situação.

Entendendo isso, e com objetivo de propor soluções para alguns dos desafios que temos na uMov.me, fiz um estudo sobre o DynamoDB, o banco de dados NoSQL disposto como serviço pela Amazon Web Services.

Vou deixar parte deste estudo aqui registrado para quem tiver interesse.

Este é o um projeto de exemplos que construí, consumindo o DynamoDB utilizando sua API Java.

Abaixo os slides que apresentei para o time uMov.me durante uma de nossas sessões de aprendizado continuo. Eles abordam desde uma breve explanação sobre o que é e pra que existem as soluções NoSQL, e acaba com uma análise do DynamoDB como solução de storage. Aproveite.

NoSQL and AWS Dynamodb from Eduardo Bohrer

Por hoje é só, até mais pessoal.

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:

Para iniciar realize o download da ferramenta Command Line Tools de Auto Scaling;
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;
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).
Com as chaves em mãos, basta seguir a seção “Using AWS Keys” do arquivo README.TXT situado dentro da pasta descompactada.
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.
Dúvidas?

AWS auto scaling from Guilherme Elias

Escalando:

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
```
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
```
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
```
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 🙂
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 resque, hornetQ, amazon 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:

criar uma instância do AmazonSQSClient.
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.
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.
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”.
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”.
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.

—

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.

Montando uma área de storage no Amazon Web Services (AWS) EC2

Aqui vai um tutorial bem simples, caso você queira criar uma área de storage extra para uma instância EC2. Cada instância é inicializada com uma área padrão, tipo 6Gb/8Gb no caso de um Linux ou 35Gb no caso de um Windows. Aqui vão os passos:

1. Criar uma instância, a dica é sempre nos testes criar instâncias micro. Se quiser gastar menos, é sempre legal também criar em US East (Virginia). Lembre sempre de dar um nome a sua instância, assim fica fácil de “localizar” a mesma quando você tiver várias.

2. Criar um storage, lembre que o storage é cobrado por tamanho, então para fins de teste, brinque com 1Gb. Coloquei como “/dev/sdf” ou a próxima entrada disponível.

3. Faça o attachment, ligando o storage a sua instância. Aqui a importância de ter definido um nome no passo 1.

Feito? Não…

Agora é preciso preparar este storage para poder ser usado.

Fiz estes testes usando uma uma instância micro, com o Linux padrão da Amazon.

Os passos para preparar a instância são os seguintes:

4. Execute o comando “mkfs -t ext3 /dev/sdf” para criar o file system.

5. O comando “df -h” não vai mostrar ainda a instância. Mas se você executar um comando como “cat /proc/partitions“, já vai ser capaz de ver as áreas de storage, com seus nomes internos (estilo xvda1 e xvdf).

6. Agora vamos adicionar e associar a nossa nova área, e montar.

echo “/dev/sdf /bkp ext3 noatime 0 0” >> /etc/fstab

mkdir /bkp

mount /bkp

7. Executando um “df -h” já faz um resultado diferente:

Filesystem Size Used Avail Use% Mounted on

/dev/xvda1 7.9G 921M 6.9G 12% /

tmpfs 299M 0 299M 0% /dev/shm

/dev/xvdf 1008M 34M 924M 4% /bkp

Estes testes foram executados usando uma Micro Instance do EC2, lembre-se de nos seus testes usar tudo o que facilitar e que seja gratuito!

Amazon Web Services (AWS) – Um novo mundo

Começamos a fazer alguns testes com o Amazon WebServices. O pessoal da Caelum já lançou um post fazendo um “alô mundo”, então fica a dica de olhar por lá o post deles.

Neste início estamos brincando muito com o Amazon EC2 – Elastic Compute Cloud (onde podemos criar instâncias) e com o EBS (serviço de storage).

Vou deixar de cara alguns links que são importantes de se ler logo. Um primeiro, para entender todos os serviços disponíveis, em um artigo que funciona como um resumo. Está em inglês: http://www.codeproject.com/KB/IP/UnderstandingAWS.aspx.

Para quem está começando, sempre é bom entender o que se pode fazer de graça. Sim, durante um tempo temos acesso a testar serviços. E é sempre importante lembrar que tudo é cobrado pelo uso. Então se você deixar uma máquina ligada, mas sem necessidade, é como deixar uma torneira aberta. Seu cartão de crédito vai sentir. 🙂

O blog do AWS é legal para saber das novidades, no http://aws.typepad.com/. E claro, atualizando aqui a versão brasileira do blog, no http://aws.typepad.com/brasil/. Quem tem ajudado a comunidade brasileira é o José Papo.

E uma que ouvi no JavaOne Latin America foi sobre o Rain Toolkit, que tem uma série de facilidades para manipular os recursos do AWS. Note o uso correto da palavra recursos. Obrigado. 🙂

Tá, então o negócio é ficar bom em arquitetura de cloud? É estudar muito sobre DevOps? Na verdade, eu tenho ficado muito bom em calcular quanto se vai gastar com serviços.

Nas próximas semanas vamos ir postando algumas novidades e testes que estamos fazendo.

O que dá para dizer é que é um novo mundo, onde realmente podemos entender como otimizar recursos dos nossos servidores de banco, aplicação, desenvolvimento, teste e por aí vai. Note outra vez o uso correto da palavra recurso. Obrigado novamente.

uMov.me Labs

People, Technology, Products, Community, Code!

Arquivos de Tag para aws

NoSQL e AWS DynamoDB