Escalando sua infraestrutura com o tamanho do seu negócio

Transcrição

1 amazon_ Escalando sua infraestrutura com o tamanho do seu negócio com Amazon Web Services Usando a Amazon para montar e escalar uma infraestrutura robusta de acordo com as métricas do negócio e sem investimentos iniciais, pagando só pelo uso Bruno bruno@rivendel.com.br é sócio-diretor da Rivendel Tecnologia e engenheiro de Computação pela UFRJ. Tem 11 anos de experiência na área, com principal background em Java, com as certificações SCJA, SCJP, SCWCD e SCEA. Trabalha há 6 anos com desenvolvimento ágil e inovação em startups e grandes corporações. Trabalha há 4 anos com Amazon Web Services, com mais de 50 clientes atendidos. Autor de livro sobre AWS pela Casa do Código. Vamos supor que você é founder e CTO de uma startup no segmento de comércio eletrônico, ainda em fase de investimento anjo ou seed, com fôlego para rodar a empresa por alguns meses até conseguir evidências de que seu negócio ganhou tração e merece rodadas adicionais de investimentos. Ser minimalista é a única forma de sobreviver, tanto em decisões quanto ao espaço físico como em gastos com equipamentos, servidores, licenças de software e outras coisas. Você precisar concentrar suas despesas nas pessoas que compõem o time e no inbound marketing [1]. Baseado nestas premissas, você decidiu construir seu negócio com Cloud Computing e Open Source, usando uma plataforma sem CAPEX[2] e com diversos profissionais de primeira linha capazes de compor seu time. Porém, ser minimalista não pode implicar em ser menos robusto. O segmento de comércio eletrônico no Brasil é muito competitivo e o custo de aquisição de clientes[3] é muitas vezes o principal fator de sucesso ou fracasso de uma startup. Quando uma campanha acertar na mosca e seu negócio experimentar um crescimento acelerado de clientes e vendas, sua aplicação e sua infraestrutura precisam estar / 22

2 A Amazon revolucionou o mercado de infraestrutura de servidores ao lançar sua plataforma Amazon Web Services (AWS) em Com a AWS veio o conceito de nuvem de fato, onde você não se preocupa com a localização e com a capacidade de expansão dos recursos. Veio também uma mentalidade bem diferente de lidar com infraestrutura e serviços. Os problemas clássicos de adivinhar o volume de acessos e o tempo enorme para compra de servidores físicos parecem um passado longínquo. Na pegada de startups, a habilidade de conduzir experimentos e rapidamente ajustar a direção de acordo com as métricas obtidas só é possível em sua plenitude com uso de algum tipo de nuvem. Neste artigo mostraremos como usar a Amazon para ter todo este poder em mãos. prontas para comportar as visitas e transações que surgirem. As perdas financeiras e de marca quando seu produto fica indisponível são muito sensíveis e podem arruinar meses de trabalho bem-feito. O segmento de varejo tem uma sazonalidade bem conhecida, e datas como Dia das Mães, Natal e Black Friday certamente trarão picos de acesso até 100 vezes maior que sua média, ou até mais que isso. Nosso objetivo no artigo é mostrar como ter uma infraestrutura muito eficiente em custo e mesmo assim conseguir responder a todas as demandas dos seus clientes. 23 \

3 Criando do zero a sua infraestrutura na Amazon De acordo com suas premissas, você escolheu usar o Magento como sua plataforma de comércio eletrônico inicial. Para chegar ao nosso Minimum Viable Product[4], vamos começar com uma loja beta bem enxuta, capaz de apresentar os produtos e o seu diferencial, mas ainda não com os refinamentos para operação em larga escala. Para uma instalação atual mínima do Magento na Amazon, precisamos de:» Servidor Linux no mínimo Small (é possível fazê-lo rodar numa instância Micro, mas de forma instável, não recomendada)» Servidor Apache a partir da versão 1.3 ou Nginx» Php 5.2 ou 5.3 (a 5.4 funciona, mas não é suportada oficialmente ainda)» MySql ou superior O ponto de partida para criar sua infraestrutura na Amazon é criar uma conta, em com. Na caixa Formas de Cobrança na Amazon descrevemos brevemente as opções, mas a mais rápida para testes é o cadastro de um cartão de crédito internacional. Tendo uma conta válida, vamos acessar a console da Amazon e entrar na opção EC2 (Elastic Compute Cloud), onde fica a Dashboard de administração das instâncias (servidores virtuais da Amazon). Por padrão em contas novas somos encaminhados para a região US-East (North Virginia). No canto superior direito da tela podemos ver o nome do usuário e uma caixa de seleção com a região atual. Figura 1. Nome do usuário e caixa de seleção de regiões. Para muitas aplicações a latência para acesso aos Estados Unidos não é tão relevante a ponto de impactar a experiência de uso, e hospedar a infraestrutura em uma região nos Estados Unidos é geralmente a opção mais barata e interessante para uma startup. Porém, isto deve ser avaliado em cada cenário e comparado de forma objetiva com testes. A Amazon possui quatro regiões nos Estados Unidos (uma exclusiva para Governo), uma na Europa, três na Ásia/Pacífico e uma na América do Sul (São Paulo). Primeira Topologia É muito comum começarmos a usar o Magento com todos os componentes instalados no mesmo servidor, conforme a figura 2. Há duas formas de cobrança diretamente com a Amazon: cartão de crédito internacional ou wire transfer (transferência bancária direta para os Estados Unidos). Para clientes que desejam ou precisam de uma fatura em R$ a única opção é a contratação dos serviços da Amazon através de um parceiro, como a Rivendel tecnologia. Figura 2. Topologia inicial do Magento na Amazon. Para chegar nesta topologia, passamos pelas seguintes etapas: 1. Escolha da AMI (algo como um template pré- -configurado) do servidor 2. Escolha do tipo da instância e zona de disponibilidade 3. Escolha dos dispositivos de armazenamento 4. Chaves de acesso e grupos de segurança 5. Associação de um Elastic IP e apontamento DNS No modelo On-Demand esta infraestrutura custaria aproximadamente US$ 0,06 por hora, e sem nenhum contrato ou compromisso de permanência. Podemos ver a facilidade e baixo custo para vários experimentos e a possibilidade de começar sem nenhum investimento pesado em infraestrutura. Caso fique ligado em tempo integral, o custo da infraestrutura inicial ficaria em cerca de US$ 45 mensais, considerando um volume de acesso ainda moderado. Definições sobre a infraestrutura até agora ami (amazon machine Image): é um template usado para criar novas instâncias. Podemos usar imagens públicas mantidas por vários fornecedores / 24

4 ou também criar nossas próprias AMIs com ambientes previamente configurados e prontos para serem inicializados. Tipos de instância: a Amazon trabalha com tipos de instância padrão, com quantidades de recursos bem definidas. Há atualmente 18 tipos de instância e cada um deles possui diferenças quanto à quantidade de memória, capacidade de processamento e desempenho de storage e de rede. Na Amazon todos os recursos são compartilhados entre instâncias e em linhas gerais quanto maior o tamanho da instância, mais prioridade ela tem nos recursos compartilhados, especialmente quanto ao storage e à rede. Regiões e Zonas de Disponibilidade: a Amazon possui nove regiões e cada uma delas se divide em algumas Zonas de Disponibilidade. Cada zona de disponibilidade é o equivalente a um datacenter, com estrutura física, alimentação elétrica e links de rede/internet totalmente independentes em relação às outras zonas. Todos os recursos que criamos em uma determinada região são conhecidos e compartilhados somente dentro da mesma região, incluindo instâncias, bancos de dados, configurações de segurança, chaves de acesso, entre outras coisas. É muito comum vermos topologias multizona, com aplicações rodando em múltiplos datacenters de uma região. Topologias multirregião já são bem mais raras e mais complexas de implementar. Chaves de acesso: cada instância fica associada a uma determinada chave de acesso no momento da criação. Com instâncias Linux, estas chaves servem diretamente para conexão SSH às instâncias. Nas instâncias Windows as chaves servem para obter a senha descriptografada do usuário Administrator, para permitir as conexões Remote Desktop. Não é possível alterar a chave de acesso de uma instância após a sua criação. Grupos de segurança: cada instância fica também associada a um grupo de segurança no momento da criação. Estes grupos de segurança servem para definir as regras de acesso a portas e protocolos em cada instância do grupo. Podemos definir regras para os protocolos TCP, UDP e ICMP, definindo a partir de quais IPs ou quais grupos de segurança é liberado o acesso ao protocolo/porta em questão. Na figura 3 temos um exemplo de definição de regras de acesso. Os grupos de segurança são semelhantes a Firewalls, porém eles permitem apenas a definição de regras de entrada (inbound) nas instâncias. Para definir regras de saída das instâncias é necessário usar Firewalls dentro das mesmas. Elastic IPs: são endereços de IP públicos que podem ser associados às instâncias em execução. Dispositivos de armazenamento: há alguns tipos de armazenamento disponíveis na Amazon, mas o mais comumente usado em instâncias EC2 é o Elastic Block Store (EBS), um storage de rede que fica anexado a uma instância e montado localmente. Refinando a infraestrutura Nossa primeira topologia concentra todos os componentes em uma única instância, o que deixa a arquitetura bastante vulnerável a falhas. À medida que nosso negócio vai crescendo e ficando mais valioso, uma etapa bem comum é segregar o servidor web do servidor de banco de dados. Podemos criar uma nova instância EC2 para o banco de dados, mas no caso do MySql é muito interessante criar uma instância RDS (Relational Database Service). O RDS é um serviço de banco de dados escalável e eficiente em custo, que permite o uso de um banco de dados bem gerenciado sem investir tempo em tarefas de administração de banco de dados. A Amazon oferece o RDS para MySql, Oracle e Sql Server. A EnterpriseDB oferece um serviço muito semelhante para o Postgresql. A topologia com a inclusão do RDS pode ser vista na figura 4. Figura 3. Definição de regras de acesso de um grupo de segurança. 25 \

5 que o negócio realmente ganhou tração e as indisponibilidades deixarem de ser algo aceitável. Tanto nosso servidor web como nosso servidor de banco de dados são pontos únicos de falha, e qualquer indisponibilidade em um dos componentes nos deixará sem vender. A Amazon simplificou muito o trabalho de construir uma arquitetura realmente robusta, com o uso de topologias com múltiplas zonas de disponibilidade, ou multizona. Todas as regiões da Amazon possuem pelo menos duas zonas de disponibilidade, então a abordagem que vamos descrever aqui funciona na Amazon como um todo. Figura 4. Topologia com o servidor de BD usando RDS, segregado do servidor web. A introdução de uma instância Micro do RDS MySql aumenta o custo da infraestrutura em cerca de US$ 0,025 por hora, ou US$ 18 mensais, e alivia a carga do servidor web que antes continha toda a infraestrutura. Uma característica interessante desta nossa infraestrutura é que ela começa bem enxuta e eficiente, mas é bem fácil e rápido crescer verticalmente os componentes que escolhemos até agora. Na figura 5 podemos ver a opção Change instance type, que permite que façamos upgrade (ou downgrade) do tamanho do servidor de forma quase imediata (porém é necessário parar o servidor para fazer a alteração). Isto é muito mais fácil do que migrações convencionais em servidores físicos e até mesmo em servidores virtualizados, onde os limites do que pode ser feito aparecem bem mais rápido. Com esta revisão nossa infraestrutura custará cerca de US$ 65, ainda bem suave. Alta disponibilidade A etapa seguinte de refinamento da arquitetura/ infraestrutura é essencial a partir do momento em Introduzindo um balanceador de carga Para trazer maior redundância e disponibilidade ao servidor web, vamos colocar entre ele e os usuários finais um balanceador de carga, que é um elemento comum em infraestruturas de Produção e distribui os acessos de usuários finais em 1 ou mais servidores. No caso da Amazon há o Elastic Load Balancer, um balanceador via software que escala automaticamente sua capacidade de acordo com a demanda e também é pago somente pelo tráfego, sendo muito econômico. Nosso objetivo é ter pelo menos duas instâncias ativas do servidor web, e usando uma topologia multizona, para que eventuais instabilidades em uma das instâncias ou mesmo em uma zona de disponibilidade inteira não tragam indisponibilidade para nosso produto. Para ter uma segunda instância em execução, vamos primeiro criar uma AMI da nossa instância original, para poder usá-la na criação de novas instâncias. Isto é feito selecionando a instância desejada e clicando na opção Create Image (EBS AMI). A figura 6 mostra a caixa de opções para geração da AMI. Costumo nomear as AMIs de acordo com o nome da instância e a data/hora, ou então um nome referente a alguma versão importante. Após a criação da AMI, podemos criar novos ser- Figura 5. Opção Change instance type, que permite upgrade e downgrade de instâncias. / 26

6 Figura 6. Criando uma AMI a partir de uma instância. Figura 7. Criando novos servidores a partir de uma AMI que criamos. Figura 8. Elastic Load Balancer e as instâncias configuradas. vidores a partir da mesma, como na figura 7. Já com as duas instâncias criadas, vamos criar o Elastic Load Balancer e colocá-lo para encaminhar os acessos para as duas instâncias. Na figura 8 temos uma visão das instâncias configuradas para acesso através do Load Balancer e uma informação sobre sua disponibilidade. O balanceador também traz uma informação sobre as zonas de disponibilidade que contêm as instâncias atrás do balanceador. Além da possibilidade de encaminhar requisições para múltiplas instâncias, o Elastic Load Balancer traz outras vantagens, incluindo: Health check das instâncias para não encaminhar requisições para instâncias que estejam indisponíveis Capacidade de balancear usando sticky sessions, para que nas aplicações com sessão um determinado usuário seja sempre encaminha- 27 \

7 Figura 9. Ativar topologia multizona no RDS. do para o mesmo servidor durante toda a sessão Possibilidade de instalar um único certificado SSL para atender a múltiplos servidores Configurando o RDS MySql também em multizona Após conseguir a alta disponibilidade dos servidores web, precisamos ter o mesmo para o servidor de banco de dados. O RDS possui uma configuração bem simples para habilitar a topologia multizona, como podemos ver na figura 9. Além disso também é possível aumentar ou diminuir o tamanho da instância sem indisponibilidades para usuários finais. A topologia revisada após estas modificações pode ser vista na figura 10. Com esta arquitetura já temos uma proteção significativa contra falhas em componentes individuais, com redundâncias na camada web e na camada de banco de dados. Não vamos entrar em detalhes sobre outras possibilidades, mas é muito comum também o uso de uma CDN como o Cloudfront para cachear páginas estáticas e conseguir sustentar os sites para leitura mesmo em períodos de indisponibilidade dos servidores web. Além disso, é bem comum o uso de camadas de cache de dados internos na aplicação, como o Memcached e outros, que podem trazer proteção adicional contra falhas no banco de dados. Supondo que tenhamos mantido os tamanhos de instância do servidor web e do banco de dados, esta infraestrutura custará cerca de US$ 140 mensais e é capaz de comportar um volume expressivo de visitas e transações. Elasticidade Tudo que discutimos até agora é muito interessante sob o ponto de vista de robustez e também de flexibilidade. Porém, uma característica muito diferenciada da Amazon é a infraestrutura elástica. Em infraestruturas mais tradicionais, a ideia de um negócio sazonal como o varejo é desesperadora. As empresas precisavam chutar com semanas de antecedência a quantidade de visitas e transações e torcer para conseguir servidores temporários para poder atender às demandas sem acumular um custo fixo balizado pelo pico e não pela média. Figura 10. Topologia com alta disponibilidade do servidor web e do banco de dados. A Amazon é a maior varejista on-line do mundo, então ela já vive este tipo de dilema desde A plataforma AWS têm diversos componentes dotados de características elásticas, aumentando ou diminuindo sua capacidade de acordo com a demanda. Nossa topologia já estava usando o Elastic Load Balancer e o Relational Database Service, e vamos introduzir também o AutoScaling, que vai trazer a escalabilidade horizontal aos nossos servidores web. Auto Scaling resumidamente Configurando um grupo de Auto Scaling, definimos algumas coisas como: Imagem (AMI) utilizada para criar automaticamente novos servidores Tamanho das novas instâncias que serão criadas Tamanho mínimo e máximo do grupo Políticas de Scale Up (criação de novos servidores) e Scale Down (desligamento de servidores) Já criamos anteriormente uma AMI com a versão atualizada da nossa aplicação para configuração da topologia multizona e já configuramos também um Load Balancer para encaminhar as requisições para as duas instâncias de servidor web. Para configuração do Auto Scaling é necessário usar a API da Amazon para executar os comandos, pois ainda não há as configurações de Auto Scaling disponíveis no console de administração. A instalação é bem simples: precisamos ter o JDK 1.5 ou superior, baixar a Command Line Interface (CLI) do Auto Scaling Tools e configurar algumas variáveis de ambiente. O vínculo da CLI com a conta / 28

8 da Amazon é feito através de um arquivo no qual preenchemos nossa Access Key ID e a Secret Access Key, que farão a autenticação e autorização da conta na API da Amazon. Na Listagem 1 temos um exemplo de comando para criar uma Launch Config, e na Listagem 2 temos um exemplo de comando para criar o grupo de Auto Scaling. Para finalizar, na Listagem 3 colocamos exemplos de definições das políticas de Scale Up e Scale Down. Após a criação dos grupos de Auto Scaling e das políticas de Scale Up e Scale Down, a última etapa é configurarmos os gatilhos que vão disparar a criação e desligamento de servidores. Estes gatilhos são criados através de Alarmes do CloudWatch, usando métricas do tipo AutoScaling. Em linhas gerais as políticas de criação e desligamento de servidores seguem o seguinte exemplo hipotético: Após 3 minutos com os servidores acima de 80% de CPU, adicione 1 novo servidor ao grupo e distribua os acessos entre eles Após 3 minutos com os servidores abaixo de 30% de CPU, desligue 1 dos servidores do grupo e redistribua os acessos dentro do grupo Esta abordagem nos permite monitorar continuamente os servidores e tomar ações automáticas dentro de nossas políticas quando o volume crescer ou diminuir. Além disso, configuramos curvas suaves de subida e descida de servidores, para garantir que nossa infraestrutura não vai crescer ou diminuir abruptamente devido a picos de poucos segundos. Esta abordagem claramente aborda sazonalidade de um jeito bem eficiente, pois a infraestrutura e os custos crescem ou diminuem de acordo com a demanda dos clientes, e não precisaremos pagar por um parque ocioso a maior parte do tempo. A Amazon cobra por hora de uso dos servidores e com isso podemos pagar um valor bem suave por uma quantidade adicional de servidores que ficam ligados por curtos intervalos de tempo, de forma sazonal. A topologia final com a introdução do Auto Scaling está na figura 11. Listagem 1. Criação da Launch Config. as-create-launch-config --image-id ami-b754c687 --instance-type m1.small --group magento --region useast-1 --launch-config magento-small-config Listagem 2. Criação do grupo de Auto Scaling. as-create-auto-scaling-group magento-as --launch-configuration magento-small-config --min-size 2 --max-size 4 --availability-zones ua-east-1a,us-east-1b,us-east-1d --load-balancers LoadBalancerMagento --region us-east-1 Listagem 3. Definição de políticas de Scale Up e Scale Down. as-put-scaling-policy MagentoScaleUpPolicy --autoscaling-group magento-as --adjustment=1 --type ChangeInCapacity --cooldown 300 as-put-scaling-policy MagentoScaleDownPolicy --autoscaling-group magento-as --adjustment=-1 --type ChangeInCapacity --cooldown 300 Figura 11. Topologia com Auto Scaling. Algumas observações sobre o Auto Scaling O Auto Scaling faz uso da escalabilidade horizontal, não vertical. Portanto um trabalho importante de arquitetura e infraestrutura é encontrar o tamanho ótimo de cada instância para que tenhamos o melhor cenário em termos de robustez e custo. Embora o tempo de resposta do auto scaling seja relativamente rápido, recomendamos que os grupos tenham no mínimo dois servidores e usem topologia multizona. Assim manteremos a alta disponibilidade O fato de usar AMIs padrão e poder a qualquer momento ligar ou desligar servidores traz à tona as preocupações quanto à persistência de dados/arquivos das aplicações. Idealmente a topologia deve ser construída de forma que as instâncias compartilhem alguns recursos e que seja possível ter 2 ou 20 servidores em paralelo sem intervenções manuais. Isto tem implicações típicas sobre uploads de arquivos, bancos 29 \

9 de dados, índices em disco e outros componentes, que devem ser desenhados permitindo a escalabilidade horizontal. Comparação com outras opções de nuvem Neste artigo descrevemos abordagens comuns para construir um novo negócio com a Amazon, que é a plataforma de nuvem mais popular, com mais de 50% de market share. Porém, há outras opções que oferecem alguns dos benefícios que a Amazon oferece e algumas vantagens e desvantagens, dependendo do seu contexto. Heroku O Heroku é uma plataforma de aplicações que dá um acesso bem fácil para que desenvolvedores publiquem suas aplicações na nuvem sem a necessidade de profissionais de infraestrutura. Isto certamente é conveniente e agiliza muito a condução de experimentos, especialmente por startups. O Heroku usa por baixo a plataforma da Amazon, então muitas das vantagens que a Amazon oferece, o Heroku também, além de recursos adicionais. Porém, o Heroku acrescenta um custo considerável depois que sua plataforma começa a crescer e ter um volume mais intenso. Com isso, é muito comum as empresas saírem do Heroku para o uso direto da Amazon após um amadurecimento do negócio. Google App Engine O Google App Engine é também uma opção muito interessante de nuvem, porém numa categoria diferente da Amazon, pois o App Engine é uma Plataforma como Serviço (PaaS). Isto implica que você tem uma série de componentes prontos para o uso e paga sob demanda, tendo também a elasticidade de forma automática, mais fácil que na Amazon. Porém, sendo uma plataforma como serviço, você precisa construir sua aplicação pensando especificamente nos componentes do App Engine, o que te dá bem menos flexibilidade do que opções de infraestrutura como Serviço (IaaS), nas quais praticamente qualquer aplicação que funcione em um servidor físico pode ser usada praticamente sem modificações. A decisão de usar uma Plataforma como Serviço ou Infraestrutura como Serviço depende mais de aspectos de negócio e parcerias que a empresa deseja firmar do que de possibilidades que as duas modalidades oferecem. Ambas permitem que você cresça em investimentos de acordo com o crescimento do negócio e sem CAPEX, então a avaliação depende de muitos critérios importantes para o futuro da empresa. O Rackspace e o Windows Azure são os concorrentes mais similares à plataforma da Amazon, e um comparativo entre estas plataformas provavelmente geraria artigos completos, dada a quantidade de opções e riqueza de detalhes das plataformas. Ambos oferecem servidores Windows e Linux de vários tamanhos, cobrança sob demanda por hora e serviços de aplicação, como banco de dados, envio de , entre outros. Considero a Amazon como uma opção mais completa e madura, além de ter uma comunidade de usuários e clientes maior. Porém, esta é uma preferência pessoal que pode não ser a realidade para o seu negócio e a sua situação. Há uma competição enorme entre os provedores de Cloud e isto sempre traz inovações e incentivos para o uso que podem se encaixar muito bem no seu produto ou negócio. Portanto, em vez de fazer uma escolha com pouca informação, recomendamos a avaliação de alternativas ao provedor que for sua escolha inicial. Considerações Finais Neste artigo buscamos ilustrar de forma objetiva como começar um negócio usando a Amazon e ter a infraestrutura cada vez mais robusta e refinada à medida que os clientes vão aumentando e com isso as visitas e transações. Mostramos etapas comuns em uma operação que vai crescendo e as abordagens para conseguir alta disponibilidade e capacidade elástica de forma bem simples e eficiente em custo. Em um contexto de Lean Startups, esse poder e flexibilidade são ferramentas valiosíssimas, e recomendo a todos que no mínimo avaliem bem o que a plataforma Amazon Web Services tem a oferecer para seu produto. Você não gastará mais que alguns trocados para isso, e os retorno para seu negócio pode ser fantástico. /referências > [1] > Inbound Marketing: Inbound_marketing > [2] > Capex: expenditure > [3] > Custo de aquisição de clientes: org/wiki/customer_acquisition_cost > [4] > Minimum Viable Product: wiki/minimum_viable_product Rackspace/Windows Azure / 30