Tag: AWS

Recent Posts
AWS, DEVOPS

Reformulação do Seja.Cloud

Pedido de desculpas e Certificação AWS

Pessoal, sei que estou há muito tempo sem postar (iria completar 1 ano), mas estou num período de muitos estudos e muito trabalho.

Estamos em um processo forte de migração de algumas plataformas para a AWS, onde estou coordenando uma equipe de Cloud e DevSecOps responsável por toda definição e gestão da Núvem Pública, ou seja, você criar um “datacenter” do zero não é fácil e nada muito rápido, mas em um post mais para frente comentarei sobre a experiência.

Recentemente tirei minha certificação em AWS Architect (Associate) e iniciei o meu estudo para partir para a AWS Architect Professional. Como a certificação do professional exige MUITO tempo de prática e MUITO estudo, resolvi reformular todo o meu site para praticar um pouco alguns conceitos. O Resultado ficou show, e principalmente: BARATO.

No ínicio um monolitico.

No lançamento do meu site, por questão de praticidade para mim e querer fazer o lançamento rápido, eu criei uma estrutura muito simples, mas com bastante falhas (só que me atendia bem).

Eu tinha um Route53 para gerenciar meu DNS, uma VPC Default e uma instancia EC2 T2.micro com um WordPress e um MySQL juntos (desenho abaixo).

Esta configuração é muito amadora, básica, mas para um site que não tinha muitos acessos e eu queria utilizar somente para fazer meus posts estava me atendendo bem.

O problema é que em dias de picos o Apache matava o processo do SQL buscando memória, pois a instancia era pequena, e diversas vezes eu tinha que reiniciar a máquina (por ser mais rápido) para voltar ao normal.

Ou seja, para um ambiente onde só eu utilizava e poucos amigos acessavam estava ótimo, mas de fato, precisava dar um upgrade.

Estudos certificação e hora da 2a versão.

Como eu estava estudando para a certificação da Architect Associate, eu resolvi juntar o útil ao agradável e fazer uma segunda versão melhorada e que pudesse parar de derrubar meu site.

Fui para a seguinte configuração:

  • Criei uma VPC customizada (deixei de usar a Default) – Aqui é uma dica importante para o exame, é importante você saber criar a VPC da tua memória, com todos os passos necessários. Eu vou fazer um post mais para frente sobre a certificação e comentarei sobre isso.
  • Route53 gerenciando o DNS.
  • Criei duas subnets – 1 publica e 1 privada – Esta configuração permite com que você não exponha os teus dados à internet. E pode fazer o controle de segurança via ACL.
  • Criei duas instancias t2.nano (o meu periodo de instancias free já havia terminado), uma instância na subnet pública com abertura da porta 80 via security group e uma instancia na subnet privada para ser banco de dados. Também fiz o ajuste abaixo no /etc/my.conf a fim de deixar o mysql mais light para rodar em uma t2.nano
    • [mysqld]
    • skip-external-locking
      key_buffer_size = 16K
      max_allowed_packet = 1M
      table_open_cache = 4
      sort_buffer_size = 64K
      read_buffer_size = 256K
      read_rnd_buffer_size = 256K
      net_buffer_length = 2K
      thread_stack = 128K
  • Criei um Nat Gateway na subnet publica e uma rota da instancia da subnet privada para o Nat Gateway: Isto permite com que você consiga que a instancia da subnet privada possa acessar a internet sem expor ela para a internet (ela tem somente um ip privado) e é útil para rodar o yum update entre outras coisas mais, mantendo segurança.
  • Criei um internet gateway na minha subnet publica: É isto que caracteriza uma subnet publica. Ter um internet gateway libera a subnet para a internet.

Neste meu case ainda faltou algumas configurações por exemplo ACL para restringir o tráfego a nivel de subnet, o que deixaria mais seguro (é uma segurança além do security group), também poderia ter criado um servidor para servir de bastion host, e somente este servidor eu liberaria a porta SSH (22) para meu ip de casa, mas, como não é um ambiente corporativo, deixei a configuração do jeito que descrevi acima (e foto abaixo) pois me atendia bem em termos de segurança e em termos de estabilidade.

Pontos de falha:

  • Não há instancias em multi AZ, ou seja, em caso de picos e a instancia parar (a t2 nano até que aguenta bem o tráfego do meu site) o meu site ficaria indisponivel,
  • Não há nenhum anti DDoS ou outro tipo de mitigador de ataques
  • Não há escalonamento automático das instancias para crescer conforme demanda.

Vendo estes pontos de falhas e buscando redução de custo , pois meu blog estava com um custo de aproximadamente 8 USD (sim é pouco mas se dá para reduzir….) eu fui para a nova versão dele.

Auto escalavel, baixissimo custo e super protegido – SERVERLESS!!!!

Pessoal, o grande benefício de você seguir para uma Cloud Pública, sem sombra de dúvidas é você aproveitar as plataformas da núvem (no meu caso AWS) e deixar de usar como hosting. Existem diversos artigos pela internet (recomendo você buscar pelo site http://acloud.guru que tem bastante informação) falando sobre soluções serverless e foi por aí que eu parti.

O meu blog não tinha nenhuma funcionalidade dinâmica, exceto os comentários. Então se eu encontrasse alguma solução onde os comentários pudessem ser escritos via javascript eu poderia muito bem armazenar meu site em um bucket S3 e marcar o bucket como webhost. Além disto, eu precisaria de algum programa que pudesse varrer meu site e converte-lo em .html;

Procurando pela internet encontrei o plugin DISQUS (http://disqus.com). Ele permite que você substitua os comentários do wordpress por posts em javascript. Eis a solução para meu problema!

Além do Disqus encontrei o programa Win HTTrack Website Copier (https://www.httrack.com/) este programa é fantastico, ele varre teu site e links e cria ele em paginas estaticas (html), também respeitando CSS e javascript.

Pronto, consegui converter meu site inteiro em wordpress php para html!

Feito isto parti para a criação do meu bucket S3 com webhost, fiz o upload do meu site e configurei o Route 53 para apontar  para o bucket. Aqui um ponto de atenção: o seu bucket precisa ter o mesmo nome do dominio (no meu caso: seja.cloud (http://seja.cloud.s3-website-us-west-2.amazonaws.com) e quando você for configurar o Record Set “A” deve setar a opção ALIAS. Automaticamente teu bucket irá aparecer na lista.

Logo, meu site ficou na seguinte configuração:

Porquê Bucket S3?

O S3 é uma plataforma da AWS com altissima disponibilidade, escalabilidade e durabilidade.

Ele garante uma durabilidade de 99,999999999%, ou seja, se você armazenar 10.000 objetos com o Amazon S3, você pode esperar que em média ocorrerá a perda de somente um objeto a cada 10.000.000 anos. Ele também armazena os objetos em multiplos equipamentos em várias instalações em uma região, ou seja, altamente tolerante a falhas.

Ele tem 3 tipos de storage que podem baratear o custo: S3 Standard (custo padrão), S3 IA (Acessos menos frequentes) e S3-RRS (Reduced Redundancy Storage) no meu caso, como o meu site não é tão acessado assim, eu criei meu bucket em um S3 IA mas que está me garantindo uma latencia muito boa, não estou sentindo problemas de velocidade.

Outra coisa interessante dele é quanto aos acessos, no meu caso, eu criei uma ACL onde somente meu usuário pode efetuar algum tipo de alteração no bucket, ou seja, ninguem conseguirá hackear meu site. Para acessar meu usuário é necessário MFA (Multi Factor Autenticator), ou seja, somente se roubarem meu celular e tiverem minha senha conseguem acessar meu site.

Também não tem banco de dados, ou seja, não é possivel me atacar com SQL Injection, etc.

O Custo é irrisório!! Na região que estou, ele custa os primeiros 50 TB mês U$ 0.0125 por GB. Meu site esta com 3 MB, ou seja, não custará mais que U$ 0.54 USD (já considerando o Route 53). Uma redução de 93% no custo.

Criei um WAMP (Windows + apache + mysql + php) na minha máquina pessoal e repliquei meu blog nele, desta forma, quando eu quero atualizar um post (como este) eu atualizo na minha máquina, rodo o HTTrack e faço upload dos arquivos no bucket. Desta forma, consegui desativar todas minhas instancias, elastic ip, natgateway, internet gateway, etc.

Conclusão

Utilizar os benefícios da Cloud Publica com certeza reduz muito o custo, deixe de utilizar a Cloud como hosting e passe a utilizar ela em seus recursos. Você ganhará muito em segurança, escalabilidade e custo.

Esta versão do meu site agora está altamente escalavel, segura (se você achar forma de hackear me avise, pois eu não encontro) e baixissimo custo.

 

Proximos posts

Planejo fazer os seguintes posts, acompanhe:

Eu palestrei no AWS Summit 2017 sobre Como escalar com segurança na Núvem, irei fazer um post sobre ele.

Também irei escrever um post sobre como passei na certificação da AWS Architect Associate e darei dicas.

Escreverei um pouco mais sobre alguns serviços da AWS, principalmente sobre os que tive utilizando no meu SITE e explicarei como montar um website como o meu.

Eu no AWS Summit 2017 com meu grande amigo Rozzati (Arquiteto SR da AWS)

Abraços.

Marcos.