CRIAÇÃO E ARQUITETURA DE UMA INFRAESTRUTURA NA …
60
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO CRIAÇÃO E ARQUITETURA DE UMA INFRAESTRUTURA NA NUVEM AMAZON WEB SERVICES VOLTADA À HOSPEDAGEM DE UMA APLICAÇÃO MAGENTO MARCO AURÉLIO ALANO GODINHO BLUMENAU 2019
Transcript of CRIAÇÃO E ARQUITETURA DE UMA INFRAESTRUTURA NA …
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
CRIAÇÃO E ARQUITETURA DE UMA INFRAESTRUTURA
NA NUVEM AMAZON WEB SERVICES VOLTADA À
HOSPEDAGEM DE UMA APLICAÇÃO MAGENTO
MARCO AURÉLIO ALANO GODINHO
BLUMENAU
2019
MARCO AURÉLIO ALANO GODINHO
CRIAÇÃO E ARQUITETURA DE UMA INFRAESTRUTURA NA
NUVEM AMAZON WEB SERVICES VOLTADA À
HOSPEDAGEM DE UMA APLICAÇÃO MAGENTO
Trabalho de Conclusão de Curso apresentado ao
curso de graduação em Ciência da Computação do
Centro de Ciências Exatas e Naturais da
Universidade Regional de Blumenau como
requisito parcial para a obtenção do grau de
Bacharel em Ciência da Computação.
Prof. Aurélio Faustino Hoppe, Mestre - Orientador
BLUMENAU
2019
AGRADECIMENTOS
Agradeço ao professor Aurélio Faustino Hoppe por suas incansáveis sugestões de
melhoria na estruturação do texto, ao Tadeu Granemann pela revisão técnica que elevou o
nível da fundamentação e dos resultados deste trabalho e também pela revisão textual de
Armando Leite e de minha esposa, Marina Merini Valcanaia, com sua compreensão sem fim
dos meus momentos de loucura.
RESUMO
Os desafios encontrados no setor de operações são muitas vezes relacionados às
incongruências que se apresentam durante o gerenciamento de um grupo de servidores e de
toda a infraestrutura. Quando há um time trabalhando no mesmo projeto, são grandes as
chances de requisitos similares serem feitos de formas diferentes. Comportamentos como esse
podem impactar a infraestrutura e a aplicações suportadas de forma negativa, o que acaba
sendo especialmente prejudicial ao negócio quando a plataforma suportada está ligada ao
retorno financeiro direto de uma empresa. É esse o caso quando se trata de uma plataforma de
comércio eletrônico como o Magento. Este trabalho apresenta uma solução que utiliza
conceitos de Infraestrutura como Código para criar uma arquitetura na nuvem Amazon Web
Services (AWS) de forma a garantir a consistência do ambiente gerenciado, permitindo que a
nuvem seja abordada como na engenharia de software. Assim, podem ser aplicados fluxos de
avaliação e revisão do código e testes da solução antes de realizar a alteração no ambiente de
produção. Em termos de arquitetura, a infraestrutura criada possui características de tolerância
a falhas de hardware por suportar a perda de uma zona de disponibilidade da AWS e é capaz
de realizar o scale-out dos recursos computacionais automaticamente para atender de forma
adequada ao volume de acessos da loja. Contêineres Docker foram utilizados para executar
serviços fundamentais da operação, como a aplicação Magento em si e a camada de cache
Varnish, que são executados em um Cluster do AWS Elastic Container Service. Outras
tecnologias como a de banco de dados relacional, banco de dados em memória,
balanceamento de carga e recursos de rede são provenientes de serviços específicos da AWS
para estes fins. Os objetivos de resiliência e escalabilidade foram atingidos, uma vez que a
simulação de uma perda de disponibilidade foi realizada manualmente e testes de carga
utilizando Locust mostraram que a infraestrutura criada é capaz de suportar a criação de 415
cotações por minuto na loja.
Palavras-chave: Magento. Infraestrutura como Código. Amazon Web Services. Arquitetura na
nuvem. Docker.
ABSTRACT
The challenges encountered in the operations industry are often related to the inconsistencies
that arise during the management of a clusters and the entire infrastructure. When there are
multiple teams working on the same project, there are high chances of similar requirements
ending up implemented in different ways. Such situations can impact negatively on the
infrastructure and applications supported, which is especially harmful to the business when
the supported platform directly tied to its financial income. This is the case when it comes to
an e-commerce platform like Magento. This work presents a solution that uses Infrastructure
as Code concepts to create an architecture in the Amazon Web Services (AWS) cloud to
ensure the consistency of the cloud environment, allowing the infrastructure to be addressed
with software engineering techniques. Code evaluation, revision and testing can be applied
before making changes to the production environment. In terms of architecture, the
infrastructure created is tolerant to hardware failure because it supports the loss of an AWS
availability zone and is able to scale-out the computational resources automatically to adapt to
demand. Docker containers were used to run fundamental operations services, such as the
Magento application itself and the Varnish cache layer, which run in an AWS Elastic
Container Service cluster. Other technologies such as relational database, in-memory
database, load balancing, and network resources come from AWS-specific services for these
purposes. The resiliency and scalability goals were achieved and tested simulating the loss of
an availability zone manually and load testing the application with Locust. The infrastructure
created is capable of supporting the creation of 415 quotes per minute in the store.
Key-words: Magento. Infrastructure as Code. Amazon Web Services. Cloud Architecture.
Docker.
LISTA DE FIGURAS
Figura 1 – Infraestrutura global da AWS ................................................................................. 18
Figura 2 – Espiral do medo de automação ............................................................................... 21
Figura 3 – Arquitetura geral proposta....................................................................................... 29
Figura 4 – Arquitetura da VPC ................................................................................................. 31
Figura 5 – Bastion hosts na VPC .............................................................................................. 32
Figura 6 – Funcionamento do módulo de bastion hosts ........................................................... 33
Figura 7 – Arquitetura contendo os serviços principais ........................................................... 35
Figura 8 – Pipeline de criação da imagem de contêiner Magento ............................................ 37
Figura 9 – Primeira execução dos testes ................................................................................... 45
Figura 10 – Erros na primeira execução ................................................................................... 45
Figura 11 – Erros na segunda execução ................................................................................... 46
Figura 12 – Execução sem erros do teste de carga ................................................................... 46
Figura 13 – Consumo de CPU .................................................................................................. 48
LISTA DE QUADROS
Quadro 1 – Exemplo de utilização do módulo service em uma task ........................................ 23
Quadro 2 – Definição do provedor AWS e criação de um recurso de instância EC2 ............. 25
Quadro 3 – Requisitos funcionais ............................................................................................. 28
Quadro 4 – Requisitos não funcionais ...................................................................................... 28
Quadro 5 – Arquivo para gerar a imagem de contêiner do Magento ....................................... 38
Quadro 6 – Arquivo para gerar a imagem de contêiner de Varnish ......................................... 39
Quadro 7 – Arquivo principal do Ansible ................................................................................ 40
Quadro 8 – Módulo principal do Terraform ............................................................................. 41
Quadro 9 – Método principal do Locust ................................................................................... 42
Quadro 10 – Dimensionamento da infraestrutura no primeiro teste ........................................ 44
LISTA DE ABREVIATURAS E SIGLAS
AMI – AMAZON MACHINE IMAGE
API – Application Programming Interface
AWS – AMAZON WEB SERVICES
CDN – CONTENT DELIVERY NETWORK
CIDR – CLASSLESS INTER-DOMAIN ROUTING
CMS – CONTENT MANAGEMENT SYSTEM
CPU – CENTRAL PROCESSING UNIT
DNS – DOMAIN NAME SYSTEM
ECR – ELASTIC CONTAINER REGISTRY
ECS – ELASTIC CONTAINER SERVICE
EFS – ELASTIC FILESYSTEM
GB – GIGABYTE
HCL – HASHICORP CONFIGURATION LANGUAGE
HTML – HYPERTEXT MARKUP LANGUAGE
HTTP – HYPERTEXT TRANSFER PROTOCOL
HTTPD - HYPERTEXT TRANSFER PROTOCOL DAEMON
HTTPS – HYPERTEXT TRANSFER PROTOCOL SECURE
IAM – IDENTITY AND ACCESS MANAGEMENT
IP – INTERNET PROTOCOL
JSON – JAVASCRIPT OBJETCT NOTATION
MVC – MODEL-VIEW-CONTROLLER
NACL – NETWORK ACCESS CONTROL LIST
NAT – NETWORK ADDRESS TRANSLATION
PHP – HYPERTEXT PREPROCESSOR
RDS – RELATIONAL DATABASE SERVICE
SDK – SOFTWARE DEVELOPMENT KIT
SSH – SECURE SHELL
TI – TECNOLOGIA DA INFORMAÇÃO
VPC – VIRTUAL PRIVATE CLOUD
WAF – WEB APPLICATION FIREWALL
YAML – YAML AIN’T MARKUP LANGUAGE
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS ...................................................................................................................... 13
1.2 ESTRUTURA.................................................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 MAGENTO ....................................................................................................................... 15
2.2 AMAZON WEB SERVICES ............................................................................................ 16
2.3 GERENCIAMENTO DE CONFIGURAÇÃO E INFRAESTRUTURA COMO CÓDIGO
20
2.4 FERRAMENTAS DE INFRAESTRUTURA COMO CÓDIGO ..................................... 22
2.4.1 Ansible ............................................................................................................................ 22
2.4.2 Terraform ........................................................................................................................ 24
2.5 TRABALHOS CORRELATOS ........................................................................................ 26
2.5.1 Magento na AWS – Quick Start ..................................................................................... 26
2.5.2 Magento Cloud Pro Plan ................................................................................................. 27
2.5.3 Architecture: Magento deployment................................................................................. 27
3 DESENVOLVIMENTO .................................................................................................... 28
3.1 REQUISITOS .................................................................................................................... 28
3.2 ESPECIFICAÇÃO ............................................................................................................ 29
3.2.1 Virtual Private Cloud (VPC) ........................................................................................... 30
3.2.2 Bastion Host .................................................................................................................... 32
3.2.3 Contêineres e serviços principais da arquitetura ............................................................. 34
3.2.4 Pipeline de construção do Magento ................................................................................ 36
3.3 IMPLEMENTAÇÃO ........................................................................................................ 38
3.3.1 Contêineres ...................................................................................................................... 38
3.3.2 Ansible ............................................................................................................................ 39
3.3.3 Terraform ........................................................................................................................ 40
3.3.4 Locust .............................................................................................................................. 41
3.4 ANÁLISE DOS RESULTADOS ...................................................................................... 42
3.4.1 Testes de disponibilidade ................................................................................................ 43
3.4.2 Testes de carga ................................................................................................................ 44
4 CONCLUSÕES .................................................................................................................. 53
4.1 EXTENSÕES .................................................................................................................... 54
REFERÊNCIAS ..................................................................................................................... 55
12
1 INTRODUÇÃO
De acordo com a empresa Nielsen Research (2019), o faturamento com vendas pela
internet no Brasil no ano de 2018 foi de 53,2 bilhões de reais – uma alta de 12% em
comparação com 2017. Foram 123 milhões de pedidos realizados, alta de 10% relativo ao ano
anterior. O crescimento do setor não só apresentou alta como possui uma previsão de
crescimento de 15% para 2019, com um faturamento que deve chegar a 61,2 bilhões de reais
até o final do ano – isto indica uma tendência no comportamento do consumidor em se valer
cada vez mais de meios eletrônicos de compra. Com os valores apresentados, e por conta da
natureza virtual das lojas de comércio eletrônico e sua consequente dependência de serviços
de Tecnologia da Informação (TI), é preciso considerar a necessidade de alta disponibilidade
deste tipo de plataforma (ALTAMEEM; ALAKKI, 2017).
Segundo Altameem e Alakki (2017), a maioria das organizações negligenciam a forma
como o comércio eletrônico é implantado. Eles também afirmam que um dos principais
fatores que levam ao sucesso de uma plataforma de vendas na internet é a sua Infraestrutura
de TI. Além disso, citam alguns requisitos para uma boa infraestrutura tais como certificados
digitais, que garantem a privacidade da informação em trânsito, e uma forma segura de
pagamento eletrônico. No entanto, estes requisitos são focados na parte de segurança e
funcionalidade, e não abrangem os requisitos de disponibilidade da aplicação. Sun (2012)
apresenta o modelo de computação na nuvem como uma forma de arquitetar soluções de
comércio eletrônico que tenham uma alta disponibilidade, afirmando que “a confiabilidade
aumenta se múltiplos sites são usados, o que torna computação na nuvem adequada para
continuidade do negócio e recuperação de desastres”. Ela também apresenta outras vantagens,
como um ágil provisionamento de recursos, constante monitoramento da performance, melhor
segurança e redução de custos.
A Amazon Web Services (2018) aponta que são cinco os pilares de uma boa
arquitetura na nuvem, através do seu Well-Architected framework: excelência operacional,
segurança, confiabilidade, eficiência de desempenho e otimização de custos. O objetivo deste
framework é ajudar a “entender os prós e contras de decisões tomadas quando criando
sistemas na AWS”, e também de esclarecer pontos de balanceamento entre os pilares, isto é, o
possível enfoque em determinado pilar impactando numa menor significância de outro. Os
pilares procuram estabelecer uma série de princípios e práticas que permitam aos arquitetos
suportar, monitorar e melhorar sistemas cruciais para o negócio (excelência operacional),
proteger dados e restringir acessos (segurança), recuperação de estados de falha
13
(confiabilidade), utilização de recursos conforme demanda (eficiência de desempenho) e
gerenciar os custos de forma a equilibrá-los com os objetivos do negócio (otimização de
custos) (AMAZON WEB SERVICES, 2018, tradução nossa).
Segundo Bernstein (2014) outra característica importante da computação em nuvem é
ter contêineres como componentes. O autor compara o uso de máquinas virtuais com o uso de
contêineres comentando as necessidades de cada solução. No caso de máquinas virtuais, um
sistema operacional chamado de host roda uma camada de software chamada de hypervisor,
sobre a qual uma máquina física pode ser virtualizada. No caso de contêineres, o sistema
operacional host não precisa executar um hypervisor nem emular um computador, bastando
executar um motor de contêiner que compartilha o sistema operacional hospedeiro e permite a
execução de aplicações isoladas e encapsuladas com suas dependências - contêineres
(BERNSTEIN, 2014). Por conta de um tamanho reduzido, Bernstein (2014, tradução nossa)
diz ser possível rodar “centenas de contêineres em um hospedeiro físico (contrastando com
um limite estrito de máquinas virtuais)”.
No contexto de plataformas de comércio eletrônico na nuvem, segundo estatísticas
apresentadas por Shahid (2018) o Magento está em terceiro lugar como a mais utilizada, com
mais de 15 mil lojas rodando atualmente. Por se tratar de uma plataforma customizável de
código aberto, logo no início do seu desenvolvimento mais de 225 mil cópias da plataforma
foram requisitadas (MCCOMBS; BANH, 2010). O desenvolvimento só cresceu e a versão
2.3.2 tem 350 contribuições da comunidade que participa ativamente da evolução da
plataforma (MAGENTO, 2019b).
Com base nas informações apresentadas, este trabalho apresenta a criação de uma
infraestrutura na nuvem provida pela Amazon Web Services voltada à hospedagem de uma
aplicação Magento que utiliza alguns princípios dos pilares do Well-Architected Framework.
1.1 OBJETIVOS
O objetivo é criar uma infraestrutura na nuvem provida pela Amazon Web Services
para hospedar uma aplicação Magento que seja resiliente a falhas de hardware e escalável.
a) aplicar conceitos práticos de infraestrutura como código;
b) modelar uma infraestrutura altamente disponível e escalável para execução do
Magento;
c) provisionar os recursos de infraestrutura na nuvem.
14
1.2 ESTRUTURA
O capítulo seguinte inicia com a fundamentação teórica do artigo, incluindo conceitos
sbore computação na nuvem e da nuvem Amazon Web Services, das tecnologias utilizadas e
do Magento. O capítulo posterior apresenta a arquitetura da infraestrutura criada, descrevendo
também a criação das imagens dos contêineres utilizados. O quarto capítulo apresenta o
resultado de testes da solução validando-a frente aos objetivos de resiliência e escalabilidade
esperados, e inclui uma estimativa de custos para manter a operação. Ao final apresentamos
conclusões e sugestões de extensão deste trabalho para o futuro.
15
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda conceitos sobre Magento, computação na nuvem na AWS e
infraestrutura como código. Por fim, são apresentados os trabalhos correlatos.
2.1 MAGENTO
O Magento é uma plataforma completa de comércio eletrônico de código aberto, que
pode ser personalizada tanto em funcionalidades quanto em aparência (MCCOMBS; BANH,
2010). Segundo McCombs e Banh (2010), a implementação da plataforma baseia-se no
modelo de desenvolvimento Model-View-Controller (MVC) que isola os componentes de
forma a permitir a customização. Em 2010 havia duas versões do Magento disponíveis, a
Community Edition, gratuita e a Enterprise Edition, com funcionalidades extras e disponível
por uma uma licença cobrada ao ano (MCCOMBS; BANH, 2010). Nas versões mais recentes
da plataforma estas edições são chamadas de Magento Open Source, gratuito, e Magento
Commerce, pago (BOLLINGER, 2018).
O desenvolvimento da plataforma iniciou em 2007 baseado em uma plataforma já
existente na época, mas a empresa então responsável pelo Magento, Varien, ao fim optou por
desenvolver a plataforma inteira do início. A plataforma se mostrou popular desde o seu
início, com mais de 225.000 aquisições do software antes do lançamento oficial da versão 1.0
em março de 2008. Desde então, o desenvolvimento só avançou com o lançamento das
versões 1.1, 1.2 e por fim 1.3 da plataforma em abril de 2009 (MCCOMBS; BANH, 2010).
Atualmente, o Magento está na versão 2.3.2, que inclui mais de 350 contribuições da
comunidade só nesta liberação, o que revela o valor que o código aberto agrega à ferramenta
(MAGENTO, 2019b). A versão 2.3.2 é uma continuação da versão 2.0, cujo desenvolvimento
iniciou no final de 2011. Naquele tempo, a maior versão da plataforma era a 1.6. O
lançamento da 2.0 ocorreu próximo ao lançamento da 1.9, entre 2014 e 2015 (KHATTAK,
2019). Desde então, os esforços de desenvolvimento concentraram-se na plataforma
repaginada da versão 2.0, com o anúncio em 2018 de que as versões mais antigas da
plataforma deixarão de ser suportadas a partir de junho de 2020 (AYYOUB, 2018).
Segundo Ajzele (2015), a versão 2.0 do Magento é muito diferente da anterior devido a
grandes mudanças estruturais e de código. O Magento depende de um conjunto de tecnologias
para rodar, todas de código aberto. A aplicação é escrita em PHP, uma linguagem de
programação interpretada com suporte a orientação a objeto. Por utilizar PHP, outra
tecnologia que faz parte do conjunto é o Composer, um gerenciador de dependências para a
linguagem - código de terceiros pode ser referenciado e obtido através dele. Os servidores
16
web Apache e Nginx são suportados para comunicação HTTP e HTTPS. O sistema de banco
de dados relacionais utilizado é o MySQL (AJZELE, 2015).
Além dos pontos descritos por Ajzele (2015), o Magento (2019c) recomenda a
utilização de algumas tecnologias opcionais, como Redis, um banco de dados em memória
com suporte a estrutura de dados para armazenamento de sessão e cache (REDIS, 2019). O
Magento (2019d) reforça o uso de Varnish, um acelerador de aplicações Web ou tráfego
HTTP como solução para cache de páginas. O uso das tecnologias Elasticsearch e RabbitMQ
também é opcional, mas funcionam apenas na versão Commerce. Primeiro é utilizado para
buscas no catálogo de forma rápida, com suporte a múltiplas linguagens e sinônimos de
palavras (MAGENTO, 2019e). O RabbitMQ, um agente de filas que permite o
armazenamento e consumo de mensagens através destas estruturas, é utilizado pelo Magento
para realizar algumas operações de forma assíncrona (MAGENTO, 2019f). Outro recurso
disponível somente na versão Commerce é a possibilidade de utilizar múltiplos servidores de
bancos de dados que isolam navegação, processo de compra e gerenciamento de pedidos, com
a possibilidade de utilizar um banco de escrita separado para cada uma dessas áreas
(MAGENTO, 2019g).
A loja acessada pelos clientes é gerenciada através de um painel exclusivo para
administradores, que permite configurações e gerenciamento. Segundo McCombs e Banh
(2010), uma série de seções são expostas. Entre elas estão o gerenciamento dos pedidos,
catálogo de produtos e suas categorias, clientes e grupos de clientes e promoções para
oferecer descontos. Além disso é possível cadastrar listas de novidades, gerenciar as páginas
da loja e configurações específicas da loja, como opções de entrega, forma de pagamento e
gerenciamento de cache (MCCOMBS; BANH, 2010).
2.2 AMAZON WEB SERVICES
Sun (2012) diz que computação na nuvem tira do negócio a responsabilidade sobre
gerenciamento de hardware e software, sem a necessidade de adquirir a infraestrutura física
que garante a capacidade computacional necessária - em vez disso, paga-se pelo que se usa. O
conceito já é bem definido, e a literatura revela consenso. Mell e Grance (2011, p. 2, tradução
nossa) afirmam que “computação na nuvem é um modelo que permite acesso geral,
conveniente e sob demanda através da rede a um conjunto de recursos computacionais
configuráveis [...] que podem ser rapidamente provisionados e liberados com esforço mínimo
de gerenciamento [...]”.
17
A entrega de um serviço de utilização de recursos computacionais sob demanda de
qualquer lugar é possível devido às características essenciais do modelo (MELL; GRANCE,
2011). A primeira delas, segundo Mell e Grance (2011) é a de autoatendimento sob demanda,
que permite aos clientes de um provedor dos serviços na nuvem escolher e iniciar quais e
quantos recursos serão utilizados sem a necessidade de interação com um representante. A
nuvem também é amplamente acessível através da rede e dá ao cliente a possibilidade de
montar uma arquitetura elástica que aumente ou reduza os recursos utilizados de forma a
atender à demanda. Os recursos são agrupados de forma a atender a múltiplos clientes, então
diferentes itens físicos e virtuais são reservados para diferentes clientes de forma dinâmica.
Ambientes na nuvem também são caracterizados por se basearem em serviços mensuráveis na
unidade apropriada para o tipo de serviço, garantindo transparência para o provedor e para o
seu cliente (MELL; GRANCE, 2011).
A Amazon Web Services (AWS) é a plataforma na nuvem mais utilizada no mundo e
oferece mais de 165 serviços de diferentes classes, como serviços de armazenamento, banco
de dados, computação, monitoramento e segurança e serviços de nichos específicos, como
Internet das Coisas, inteligência artificial, robótica e satélites (AMAZON WEB SERVICES,
2019a).
Os gastos com a nuvem são dinâmicos uma vez que dos 165 serviços, 160 são
cobrados somente durante o tempo que eles são utilizados. Não existe a necessidade de um
investimento inicial alto ou contrato de longa duração (AMAZON WEB SERVICES, 2019b).
Além da cobrança conforme o uso, é possível optar por reservar capacidade. No caso de
aplicações cujos requerimentos são bem conhecidos, isto permite que um pagamento
adiantado seja feito, gerando uma economia de até 75% (AMAZON WEB SERVICES,
2019b). Os preços desta nuvem também são inversamente proporcionais ao uso pois quanto
mais é usado, menor o valor cobrado por unidade de um determinado serviço (AMAZON
WEB SERVICES, 2019b). O serviço de armazenamento de dados Simple Storage Service
(S3), por exemplo, é cobrado por GB armazenado. O preço por GB é menor quanto maior o
volume de dados armazenados.
A AWS oferece serviços com preços e recursos similares no mundo inteiro,
disponíveis em 66 zonas de disponibilidade dispersas em 21 regiões geográficas do globo,
tendo planos de expansão para o futuro (AMAZON WEB SERVICES, 2019c). Segundo a
Amazon Web Services (2019d), cada região é independente das outras, abrange uma área
geográfica isolada e zonas de disponibilidade interconectadas. A Figura 1 demonstra um
diagrama de alto nível da infraestrutura.
18
Figura 1 – Infraestrutura global da AWS
Fonte: Amazon Web Services (2019d).
Os recursos na AWS podem ser serviços que operam dentro de contextos específicos.
O Identity and Access Management (IAM), recurso de controle de acesso a cada parte da
AWS, opera num contexto global, que significa que quando uma alteração é realizada os
dados são replicados “de servidor para servidor, de zona para zona e de região para região ao
redor do mundo” (AMAZON WEB SERVICES, 2019f, on-line, tradução nossa). Por isso, ele
utiliza um modelo computacional chamado de consistência eventual, que na prática significa
que mudanças podem levar algum tempo para refletir (AMAZON WEB SERVICES, 2019f).
Serviços como o S3 possuem contexto regional, uma vez que quando um novo
armazenamento é criado, apenas uma região precisa ser especificada e dependendo da classe
de armazenamento escolhida, o serviço replica os dados entre múltiplas zonas de
disponibilidade dentro da região (AMAZON WEB SERVICES, 2019i, p. 1). O serviço
Elastic Compute Cloud (EC2) “disponibiliza capacidade computacional segura e
redimensionável na nuvem”, na forma de instâncias de servidor (AMAZON WEB
SERVICES, 2019i, on-line). Uma instância EC2 tem contexto zonal, uma vez que é
necessário selecionar uma zona de disponibilidade para criá-la e, no evento de uma falha
zonal, ela se tornará indisponível (AMAZON WEB SERVICES, 2019d). A Amazon Web
Services (2019d) sugere a criação de instâncias em múltiplas zonas de disponibilidade para
melhor tolerância a falhas. Instâncias EC2 requerem outros recursos para serem executadas.
Por se tratarem de servidores com sistemas operacionais, elas devem ser adicionadas a uma
rede para que tenham conectividade. Em outros serviços a conectividade é gerenciada pela
AWS, como no caso do S3, onde nenhuma configuração referente à rede precisa ser realizada.
O servidor EC2 (instância) integra-se com uma Virtual Private Cloud (VPC) de forma a
oferecer segurança e capacidade de rede para os recursos computacionais (AMAZON WEB
SERVICES, 2019i).
19
A AWS provê um recurso conhecido como Security Group, que “atua como um
firewall virtual que controla o tráfego para uma ou mais instâncias” (AMAZON WEB
SERVICES, 2019j, on-line). Uma instância pode pertencer a mais de um destes grupos, e
cada um possui regras específicas que podem permitir tráfego de entrada e saída. Apenas
regras que permitem tráfego podem ser criadas, então regras de negação não são possíveis
(AMAZON WEB SERVICES, 2019j).
Além da série de serviços oferecidos pela AWS, há também as diferentes
possibilidades de escala que ela proporciona. Hwang et al. (2014) apresenta duas formas para
escalar um componente da infraestrutura, sendo elas o scale-out, caracterizado pelo uso de
uma quantidade maior de máquinas iguais e o scale-up, caracterizado pelo uso de uma mesma
máquina que tem a quantidade de recursos aumentada.
Segundo a Amazon Web Services (2019k) provisionar recursos na nuvem é uma tarefa
simplificada através do uso de Application Programming Interfaces (APIs), como oferecido
para serviços como o Identity and Access Management (IAM). Esta API permite a realização
de requisições HTTPS a um domínio para consulta e manipulação de dados referentes ao
serviço. Apesar da possibilidade de realizar as requisições diretamente ao domínio da API, a
AWS recomenda a utilização de um Software Development Kit (SDK) para realizar operações
similares, uma vez que este “consiste em bibliotecas e exemplos de código para várias
linguagens de programação e plataformas”, além de prover uma forma “conveniente de prover
acesso programático ao IAM e à AWS. Por exemplo, os SDKs cuidam de tarefas como
assinatura criptográfica de requisições [...], gerenciamento de erros e retentativa de
requisições automaticamente” (AMAZON WEB SERVICES, 2019k, on-line, tradução nossa).
A interação com as APIs fornecidas por um provedor cloud permite a aquisição e
liberação de recursos do provedor (SCHEUNER et al., 2014). A utilização destas APIs
garante a aplicação do conceito de infraestrutura como código, uma forma “estado-da-arte
para definição de infraestrutura de TI de forma reproduzível, bem definida e testável”
(SCHEUNER et al., 2014, p. 246, tradução nossa). Artac et al. (2017, p. 497, tradução nossa)
definem a Infraestrutura como Código como um “diagrama que contém especificações de
implantação prontas para orquestração na nuvem”. A aplicação se dá através da criação e
definição de código que configura e instala aplicações, cria máquinas virtuais e outros
serviços necessários para a execução de uma aplicação, de forma que o gerenciamento do
código necessário para controle de configuração, automação e provisionamento seja
trabalhado da mesma forma que é trabalhado no fluxo de desenvolvimento de software, com
uma linguagem que descreva cada parte do processo (ARTAC et al., 2017).
20
2.3 GERENCIAMENTO DE CONFIGURAÇÃO E INFRAESTRUTURA COMO
CÓDIGO
A prática da infraestrutura como código é caracterizada pela “especificação da
configuração de sistemas computacionais através de código, e o gerenciamento deste através
de práticas tradicionais de engenharia de software” (FRAGKOULIS; SHARMA; SPINELLIS,
2016, p. 189, tradução nossa). Segundo os autores esta prática tem sido cada vez mais
utilizada, e a base de código tem se tornado mais complexa dada a adoção de diversas
ferramentas de gerenciamento de configuração. Entre estas estão Puppet, Chef, CFEngine, e
Ansible, que permitem uma implantação rápida, confiável e repetível automatizando e
abstraindo instalação software. Como o resultado da utilização destas ferramentas é código,
alguns processos da engenharia de software são utilizados para gerenciá-lo. Entre estes estão
“revisão, teste e versionamento” (FRAGKOULIS; SHARMA; SPINELLIS, 2016, p. 189).
Segundo Morris (2016) alguns desafios surgem diante da proposta da infraestrutura
como código. O aumento veloz da quantidade de recursos gerenciados pode tornar a equipe
incapaz de manter todos os servidores atualizados da mesma forma, o que leva a um efeito
que chama de configuration drift. Este conceito está relacionado a mudanças pontuais em um
único sistema após todos serem criados de forma idêntica. Isto leva a imprevisibilidades
quando novas atualizações forem realizadas, uma vez que o impacto das alterações em
determinado servidor pode não ser conhecido. O servidor único, com uma alteração própria
que foge do fluxo de atualizações padrão, é chamado de snowflake server (MORRIS, 2016).
Como a alteração deste servidor não foi levada em conta na criação do código que provisiona
a infraestrutura, ele não pode ser recriado de forma idêntica em caso de falha. Morris (2016)
diz que muitos servidores snowflake em uma infraestrutura a tornam frágil. Alterações
manuais na infraestrutura geram não só snowflake servers como acabam resultando em medo
de utilizar as ferramentas de automação novamente. Segundo Morris (2016), estes cenários
podem ser representados por uma espiral, conforme apresentado na Figura 2. A espiral ilustra
alterações manuais que geram servidores inconsistentes que geram medo de utilizar a
ferramenta de automação e, por não poder utilizá-la, causam mais alterações manuais,
voltando ao estágio inicial do ciclo.
21
Figura 2 – Espiral do medo de automação
Fonte: Morris (2016).
A falha de um sistema após um longo tempo rodando também pode se tornar um
problema. Algumas condições podem causar falha mesmo sem atualizações ou alterações em
uma infraestrutura, como o consumo total do disco de um servidor ou uma falha de hardware
(MORRIS, 2016). Por conta destes desafios, Morris (2016) estabelece princípios na aplicação
da infraestrutura como código.
Os sistemas criados devem ser facilmente reproduzíveis. Cada parte de cada
componente da infraestrutura deve ser codificado de modo a permitir que sejam criados
novamente com esforço mínimo. Além disso, os recursos devem ser descartáveis. Esta
característica auxilia na solução dos snowflake servers uma vez que um recurso descartável,
se alterado manualmente ao invés de código, pode ser perdido. Elementos de uma
infraestrutura que realizem exatamente a mesmas funções devem ser idênticos e para auxiliar
neste ponto, processos devem ser repetíveis. Isto garante que caso uma ação tenha de ser
executada uma única vez, mas no futuro venha a ser necessária novamente, será feita da
mesma forma, consistentemente (MORRIS, 2016).
Morris (2016) separa ferramentas para configuração de servidores e ferramentas para
definição de infraestrutura. Ferramentas de definição de infraestrutura permitem a descrição
dos recursos que serão utilizados, como redes e subredes, balanceadores de carga e servidores.
Essas ferramentas então criam os recursos na plataforma escolhida, como na AWS. As
ferramentas de gerenciamento de configuração de servidores evoluíram a partir de scripts, que
eram utilizados no provisionamento de servidores. Hoje há ferramentas específicas para este
fim, e além da capacidade de gerenciar a configuração também é possível encapsular
aplicações e seus processos e dependências em contêineres Docker (MORRIS, 2016).
No contexto de servidores, Morris (2016) sugere alguns modelos de gerenciamento.
Entre eles estão a infraestrutura imutável e o que chama de containerized services. Uma
infraestrutura imutável baseia cada alteração como uma substituição completa do servidor a
22
partir de um modelo criado, garantido consistência. No caso dos containerized services, “há
uma menor dependência entre configuração do servidor e aquilo que roda no servidor”
(MORRIS, 2016, p. 70, tradução nossa). Neste modelo, semelhante ao primeiro, podem haver
configurações gerenciadas por código no servidor. No entanto, a concentração dos esforços de
teste, execução da aplicação e ajuste de dependências está na camada do contêiner.
Segundo Morris (2016), na definição de infraestrutura é possível pensar de forma
declarativa ou procedural. Quando trabalhando de forma procedural, é preciso descrever como
um objetivo deve ser atingido. No caso da definição declarativa, apenas o objetivo em si
precisa ser descrito, e a ferramenta deve ser capaz de entender como atingir o objetivo. Isto
reduz a preocupação com o estado da aplicação e do que pode ocorrer dependendo deste
estado. Uma linguagem declarativa para definir infraestrutura é idempotente, e assim o estado
será sempre o que foi definido, não importando o estado atual ou quantas vezes a execução for
realizada.
2.4 FERRAMENTAS DE INFRAESTRUTURA COMO CÓDIGO
Nesta seção são descritas as duas principais ferramentas relacionadas a infraestrutura
como código, Ansible e Terraform. A primeira possui uma variedade extensa de casos de uso,
como provisionamento de servidores, gerenciamento de configuração, implantação de
aplicações e orquestração (ANSIBLE, 2019a). Ansible é capaz de entender o estado atual de
um recurso e se necessário alterá-lo para o estado desejado, utilizando uma linguagem que
permite a descrição dos dados desejados da infraestrutura (ANSIBLE, 2019b). O Terraform é
uma ferramenta focada na infraestrutura como código, que permite a manipulação da
infraestrutura, “codificando APIs em uma linguagem de configuração declarativa que pode
ser compartilhada por membros do time, tratada como código, alterada, revisada e
versionada” (TERRAFORM, 2019a, on-line, tradução nossa).
2.4.1 Ansible
Segundo Geerling (2016), o desenvolvimento do Ansible iniciou em 2012 com
Michael DeHaan e teve como influência ferramentas que este havia escrito no passado e sua
experiência prévia com outras ferramentas de gerenciamento de configuração. Em 2013 foi
criada a empresa Ansible, Inc. (GEERLING, 2016). No ano de 2015, esta foi adquirida pela
Red Hat, que hoje é a responsável principal pela manutenção da ferramenta que ainda conta
com contribuições da comunidade (PERILLI, 2015).
23
Ansible é uma tecnologia considerada fácil de se aprender, com uma pequena curva de
aprendizado (ESTEVÃO, 2017, on-line, tradução nossa). Segundo o autor, “em menos de 30
minutos é possível instalar, configurar e executar comandos ad-hoc para múltiplos servidores
a fim de resolver problemas específicos: horário de verão, sincronização de relógio, alteração
de senha do usuário root, atualização de servidores, reiniciar serviços, entre outros”. O motivo
para a facilidade de sua utilização é decorrente da forma como foi arquitetado.
Tecnologias de gerenciamento de configuração como Puppet e Chef utilizam agentes
instalados nos servidores gerenciados para possibilitar sua atualização e dependem de um
servidor mestre que controlará o grupo de máquinas (RAZA, 2016). Segundo Raza (2016),
estas ferramentas também são orientadas a “puxar” configuração em vez de “empurrar” - isto
significa que os agentes buscam a configuração no mestre, mas o mestre não é capaz de enviar
de forma proativa atualizações da configuração. Ansible difere neste quesito por não ter uma
arquitetura mestre-agente, reduzindo a complexidade de gerenciamento da ferramenta, e por
ser pensada como uma ferramenta que “empurra” a configuração para o grupo gerenciado,
embora também ofereça suporte ao outro modelo (RAZA, 2016).
De acordo com Geerling (2016), é comum o gerenciamento de servidores através do
protocolo Secure Shell (SSH), com administradores conectando-se a uma ou mais máquinas
remotamente e realizando alterações que nem sempre são documentadas nem facilmente
replicadas em um grupo grande. Além de configurar e instalar sistemas em servidores, o setor
de operações também precisa lidar com a implantação de novas versões de uma determinada
aplicação e a execução de comandos remotos rodados uma única vez, e o Ansible é capaz de
suprir todas essas necessidades, e inclusive permite a execução de comandos localmente
(GEERLING, 2016).
Ansible utiliza-se de conexões SSH já comuns à rotina de operações para realizar a
execução de comandos remotamente (GEERLING, 2016). Estes comandos são especificados
na forma de tasks que podem ou não ter um nome atrelado a elas, e que são chamadas para
um módulo do Ansible (ANSIBLE, 2019c). Módulos são componentes de código que
recebem argumentos para realização de uma tarefa específica. Por exemplo, o módulo service
espera os parâmetros name e state, e permite que um serviço do sistema operacional seja
reiniciado, conforme mostra o Quadro 1 (ANSIBLE, 2019d).
Quadro 1 – Exemplo de utilização do módulo service em uma task
- name: restart webserver
service:
name: httpd
state: restarted
Fonte: Ansible (2019d).
24
A linguagem utilizada para expressar os componentes lógicos do Ansible é o YAML
Ain't Markup Language (YAML). Através deste, uma lista de tasks caracteriza uma play, que
“mapeia um grupo de servidores a papéis bem definidos”. Por sua vez, arquivos que
contenham plays são chamados de playbooks (ANSIBLE, 2019c, tradução nossa).
2.4.2 Terraform
Segundo Turnbull (2016, p. 222) ferramentas de infraestrutura como código como
Puppet e Chef inicialmente focaram no provisionamento de servidores, “configurando
sistemas operacionais e aplicações. Elas até se ramificaram para a construção de
infraestrutura, mas geralmente de forma limitada”. É também o caso do Ansible, que possui
módulos para criação de arquivos, usuários e grupos e instalação de pacotes em sistemas
operacionais mas também criação de recursos como instâncias EC2 e balanceadores de carga
na AWS (ANSIBLE, 2019e). Segundo Turnbull (2016) era possível configurar os sistemas
operacionais do grupo de servidores gerenciados, mas não criar recursos como o próprio
servidor e rede, que também são parte fundamental do ambiente.
De acordo com Turnbull (2016), no contexto de provisionamento dos elementos
básicos de um ambiente, o Terraform se apresenta como uma ferramenta eficiente para
gerenciamento da infraestrutura. Por se tratar de uma ferramenta que se utiliza de uma
linguagem de configuração declarativa, ela permite abstração do resultado desejado em vez de
necessitar da especificação de como atingi-lo (TURNBULL, 2016). Um aspecto central do
funcionamento do Terraform é sua representação da infraestrutura na forma de um grafo
acíclico dirigido. Quando o estado final de cada recurso foi definido, ele gera um grafo que
mantém o relacionamento com cada um dos elementos da infraestrutura e abstrai inclusive a
ordem necessária de criação de cada elemento (TURNBULL, 2016).
Turnbull (2016) diz que o Terraform pode ser utilizado de forma complementar a
ferramentas de gerenciamento de configuração devido a suas capacidades únicas no que tange
o gerenciamento da infraestrutura em si e não de software ou sistemas operacionais, como
outras ferramentas. O autor ainda recomenda que o Terraform seja utilizado para a criação de
recursos de infraestrutura e que as demais ferramentas configurem as aplicações envolvidas.
O Terraform é desenvolvido e mantido pela HashiCorp, uma empresa formada em
2012 por Mitchell Hashimoto e Armon Dadgar. Todas as tecnologias criadas pela empresa
são de código aberto, e buscam resolver problemas naturais da infraestrutura de hoje,
abrangendo máquinas físicas e virtuais, Windows, Linux, SaaS, IaaS, entre outras
(HASHICORP, 2019).
25
Os arquivos de configuração do Terraform são escritos numa linguagem própria da
empresa que criou a ferramenta, a HashiCorp Configuration Language (HCL) (TURNBULL,
2016). A linguagem é compatível com JavaScript Object Notation (JSON) e similar a
arquivos de configuração do servidor web Nginx. A necessidade de criação de uma linguagem
específica veio da complexidade encontrada por iniciantes em utilizar YAML e da procura
por um balanço entre uma linguagem mais legível para humanos e ao mesmo tempo para
máquinas (HASHICORP, 2016).
Através da utilização de diferentes providers, o Terraform é capaz de criar a
infraestrutura em diversos provedores de nuvem, como AWS, Azure, HuaweiCloud e
Alicloud, além de recursos não só relacionados a infraestrutura como os serviços providos por
empresas como Akamai e GitLab (TERRAFORM, 2019b). Após a especificação de um
provider, é possível utilizar resources específicos do provedor selecionado. É natural que o
provider tenha parâmetros como credenciais e um recurso de instância receba o tamanho
desejado e a imagem a partir da qual será criada. A criação de uma instância EC2 a partir de
uma Amazon Machine Image (AMI) no provedor AWS é demonstrado no Quadro 2.
Quadro 2 – Definição do provedor AWS e criação de um recurso de instância EC2
provider “aws” {
access_key = “abc123”
secret_key = “abc123”
region = “us-east-1”
}
resource “aws_instance” “base” {
ami = “ami-0d729a60”
instance_type = “t2.micro”
}
Fonte: Turnbull (2016).
O Terraform armazena o estado da infraestrutura em arquivos nomeados
terraform.tfstate, mas também é capaz de armazenar estes dados em locais remotos e
centralizados que são adequados quando um time está trabalhando no projeto
(TERRAFORM, 2019c). O armazenamento remoto é definido através de um backend
(TERRAFORM, 2019d). Alguns dos disponíveis atualmente são Amazon S3, Terraform
Enterprise, etcd, entre outros (TERRAFORM, 2019e). Alguns backends fornecem mais
funcionalidades que outros, e são divididos entre standard e enhanced (TERRAFORM,
2019e). Segundo Terraform (2019f), ambos podem realizar o armazenamento do estado,
envio e recebimento de informações a respeito do estado e travamento do estado
(caracterizado por impedir que alterações concorrentes ocorram). Os backends do tipo
enhanced também suportam remote operations, ou seja, execução de comandos do Terraform
remotamente em vez de localmente. É comum abstrair partes lógicas da infraestrutura
26
definida no Terraform na forma de módulos, que podem ser reutilizados em diferentes
infraestruturas e projetos (TERRAFORM, 2019g).
2.5 TRABALHOS CORRELATOS
Nesta seção são apresentados trabalhos semelhantes ao desenvolvido. O primeiro
descreve o trabalho da Amazon Web Services (2017), que utiliza uma ferramenta de descrição
de infraestrutura em código para criar uma arquitetura Magento na AWS. Em seguida
apresenta-se a ferramenta desenvolvida pela Magento (2019), o serviço Magento Cloud, que
consiste numa infraestrutura gerenciada e ofertada no modelo Plataforma como Serviço. Por
fim, o há a solução da Google Cloud (2019) para a criação de uma infraestrutura Magento na
sua plataforma.
2.5.1 Magento na AWS – Quick Start
A proposta deste Quick Start é criar uma infraestrutura Magento resiliente e escalável
baseada em código utilizando templates do AWS CloudFormation, serviço de infraestrutura
como código da AWS e algumas entradas do usuário (AMAZON WEB SERVICES, 2017).
Os requisitos dos templates Cloud Formation permitem que o usuário informe
credenciais de banco e de aplicação, além do tamanho dos recursos que serão provisionados.
Em termos de arquitetura, a alta disponibilidade é atingida utilizando um Auto Scaling Group
(serviço de scale-out da AWS) para servidores Bastion (intermediários para acesso remoto) e
outro para a aplicação, os da aplicação recebem tráfego através de um balanceador de carga.
Os servidores rodam Nginx e PHP-FPM, um servidor Web e um processo que executa scripts
PHP. O armazenamento de imagens é feito com AWS Elastic File System (EFS), serviço de
sistema de arquivos de rede, e o banco de dados possui replicação síncrona para outra zona de
disponibilidade através do serviço gerenciado Relational Database Service (RDS). Há
também a utilização do ElastiCache, serviço com bancos de dados em memória, com Redis,
um dos tipos de banco oferecidos no serviço, para armazenamento de sessão.
As principais ferramentas utilizadas são o AWS Cloud Formation, que gerencia a
infraestrutura como código, e o Amazon S3 que contém o código da aplicação Magento que
será utilizado nas instâncias EC2 que rodam a aplicação.
A infraestrutura criada segue princípios de arquitetura que garantem alta
disponibilidade, embora não suporte versões mais recentes do Magento como a 2.3.1, que
requer PHP 7.2 - a versão de PHP utilizada é 7.0. Mesmo assim, o código é aberto de forma
que usuários podem adaptar os templates para seus casos de uso.
27
2.5.2 Magento Cloud Pro Plan
O objetivo era a oferta de uma plataforma como serviço que gerencia toda a
infraestrutura AWS necessária para suportar a execução do Magento (MAGENTO, 2019h).
As funcionalidades oferecidas são relacionadas ao rápido fluxo de desenvolvimento,
implantação contínua, customização, escalabilidade e segurança, além de uma abstração da
camada de infraestrutura. Também fornecem a possibilidade de criar vários ambientes
(desenvolvimento, integração, produção). Características da infraestrutura de produção criada
e gerenciada incluem a utilização da Content Delivery Network Fastly na frente de um
balanceador de carga que distribui as requisições entre três servidores em diferentes zonas de
disponibilidade. Cada servidor roda HAProxy, Nginx, PHP-FPM, GlusterFS, um serviço de
Redis, Elasticsearch e MariaDB com replicação master-master.
Não ficam claras quais são as ferramentas de desenvolvimento utilizadas, uma vez que
se trata de uma solução de código fechado. O serviço é oferecido no modelo plataforma como
serviço e garante alta disponibilidade.
2.5.3 Architecture: Magento deployment
O objetivo deste trabalho é a criação de uma arquitetura para o Magento na Google
Cloud Platform, levando em conta diferentes requisitos da aplicação como versão e
necessidade de escalar (GOOGLE CLOUD, 2019).
São propostas duas arquiteturas, tanto para a versão paga do Magento, quanto para a
versão de código aberto, e as diferenças entre elas estão nos requisitos de cada uma das
versões do Magento. Ambas preveem servidores que executem um servidor Web capaz de
suportar aplicações PHP, um banco de dados MySQL e serviços para armazenamento de
sessão e cache.
O trabalho não descreve a utilização de uma ferramenta de infraestrutura como código
ou gerenciamento de configuração, uma vez que foca nos serviços da nuvem da Google e na
arquitetura envolvendo o mesmo em vez de na implementação em si. Serviços utilizados
incluem o Google Kubernetes Engine para gerenciamento de contêineres da aplicação e do
Compute Engine para execução dos serviços de cache e banco de dados.
A alta disponibilidade pode ser atingida realizando a implantação do cluster do
Compute Engine em múltiplas zonas de disponibilidade de uma região, com auto-scaling e
balanceamento de carga, aplicando o mesmo método aos serviços de cache e banco de dados.
Este último numa configuração que isole uma instância de leitura e uma de escrita.
28
3 DESENVOLVIMENTO
Este capítulo busca explicar a forma como a infraestrutura foi organizada em código e
como ela foi definida para atingir os objetivos de resiliência e escalabilidade.
3.1 REQUISITOS
O Magento, aplicação suportada pela infraestrutura desenvolvida neste trabalho, requer
que algumas tecnologias operem em conjunto a fim de garantir capacidade de escalabilidade e
disponibilidade. Assim, o trabalho deve garantir que os requisitos apresentados são supridos
pois eles levam em conta as necessidades de um ambiente para esta aplicação e são pontos
fundamentais de uma arquitetura segura, escalável e resiliente. Os Requisitos Funcionais (RF)
do Quadro 3 referem-se à parte ao qual o usuário interage para criação da infraestrutura,
enquanto os Requisitos Não Funcionais (RNF) listam as características do ambiente que deve
ser provisionado, conforme exibe o Quadro 4.
Quadro 3 – Requisitos funcionais
Requisito funcional
RF01: permitir que o usuário defina um nome para o projeto, que deve ser usado para identificação
dos recursos provisionados
RF02: permitir que a infraestrutura seja criada e destruída
RF03: permitir que o usuário informe a origem do código da aplicação utilizado como um
repositório Git
RF04: salvar as informações confidenciais informadas pelo usuário no serviço Parameter Store
Fonte: elaborado pelo autor.
Quadro 4 – Requisitos não funcionais
Requisito não funcional
RNF01: utilizar as ferramentas Ansible e Terraform para codificação da infraestrutura
RNF02: suportar a perda de uma zona de disponibilidade da AWS
RNF03: ser capaz de adicionar ou remover recursos de forma a atender à demanda
RNF04: contemplar a criação de uma imagem Docker da aplicação contendo recursos necessários
para a sua execução através de uma pipeline do AWS CodePipeline
RNF05: prever o armazenamento de dados referentes a sessão de usuários e e cache da aplicação em
Redis Fonte: elaborado pelo autor.
Conforme apontado pelo requisito RNF01, as ferramentas Ansible e Terraform foram
utilizadas. Como o Terraform depende da criação de alguns recursos para armazenar estado e
manter sessões travadas, o Ansible cria estes recursos e em seguida roda o comando do
Terraform para criação da infraestrutura em si. A fim de cumprir o RF02, é possível
especificar uma variável que determina se o Ansible irá criar ou destruir os recursos. O
Terraform oferece esta funcionalidade por padrão. As informações do usuário e senha para
acesso ao repositório do Composer do Magento podem ser passadas como variáveis, e são
29
armazenados no Parameter Store. Além disso, um repositório do CodeCommit deve ser
especificado para criação da infraestrutura.
3.2 ESPECIFICAÇÃO
A Figura 3 apresenta um diagrama geral dos principais serviços utilizados na
arquitetura proposta e a interação entre as ferramentas mencionadas. Nas seções seguintes são
apresentados os diagramas de cada parte da infraestrutura criada.
Figura 3 – Arquitetura geral proposta
Fonte: elaborado pelo autor.
A Figura 3 demonstra, da direita para a esquerda, os pontos da infraestrutura que são
acessíveis a partir da rede pública, sendo estes os servidores utilizados como Bastion Hosts e
o balanceador de carga. Os Bastion Hosts são acessados por membros da equipe de operações
como intermediários entre os servidores de aplicação e a internet. O acesso se dá através da
identificação da chave privada do usuário. O balanceador de carga direciona o tráfego para
contêineres rodando em instâncias distribuídas em um Auto Scaling Group. Os contêineres de
cache respondem por este tráfego e encaminham a requisição para contêineres da aplicação
Magento quando não houver cache. Contêineres de aplicação interagem com os serviços RDS
como camada de persistência, ElastiCache para armazenamento de cache e EFS para
armazenamento de imagens. O lado esquerdo da imagem demonstra o processo de criação de
contêineres de aplicação - o código é processado pelo AWS CodePipeline de forma a gerar
uma imagem conteinerizada que é enviada para o Elastic Container Registry da AWS. O
30
Amazon Elastic Container Service (ECS) é responsável por utilizar a imagem gerada e os
parâmetros salvos no Parameter Store para iniciar tanto contêineres de aplicação quanto os de
cache.
O serviço Parameter Store é utilizado para armazenar todas as variáveis utilizadas na
infraestrutura. Durante a execução do Terraform, a criação dos bancos de dados retorna
algumas saídas, como senha e usuário do banco e registro DNS que aponta para o cluster. A
criação dos clusters de Redis no ElastiCache também retorna estes registros DNS, por
exemplo. A chave SSH gerada pelo módulo de Bastion Hosts é outro valor armazenado no
Parameter Store. Assim, este serviço é utilizado para centralização de usuários, senhas e
outros segredos de forma segura.
O AWS Cloud Watch é o serviço de monitoramento da AWS, que permite tanto o
monitoramento de outros serviços quanto de métricas customizadas. Este serviço possui uma
funcionalidade de eventos agendados, que podem disparar, entre outras ações, a execução de
um contêiner do ECS. Este recurso foi utilizado para a execução de tarefas com este
requerimento no Magento. A cada cinco minutos, um evento agendado do ECS inicia um
contêiner que executa as tarefas necessárias. Este serviço também é integrado ao ECS e ao
Auto Scaling Group. Além de agregar métricas de uso de CPU e memória dos recursos da
nuvem, alguns alarmes foram criados para reagir a esses valores, disparando ações como a
adição ou remoção de instâncias ao Auto Scaling Group.
3.2.1 Virtual Private Cloud (VPC)
A Amazon Web Services (2019l) oferece um serviço que permite provisionar recursos
da nuvem em uma seção isolada, utilizando uma rede virtual cujas características de Classless
Inter-Domain Routing (CIDR), subredes e rotas são definidas pelo cliente. Através de outros
recursos e serviços é possível criar um nível de isolamento ainda maior, como uma separação
entre subredes públicas e privadas para recursos que precisam ser acessados a partir da
internet e para recursos que devem ser acessíveis internamente à VPC. Um módulo “network”
foi criado com Terraform para provisionamento desta parte da nuvem, e espera como
parâmetro um valor para o nome do projeto, utilizado para identificar os recursos criados. A
Figura 4 apresenta a arquitetura da VPC criada.
31
Figura 4 – Arquitetura da VPC
Fonte: elaborado pelo autor.
Para garantir segurança e resiliência, criou-se quatro subredes - duas públicas e duas
privadas. O motivo para isto é que cada subrede existe em uma única zona de disponibilidade.
Assim, para resistir à perda de uma delas, é preciso ter uma arquitetura redundante em outra
zona. No escopo da VPC, dois principais recursos foram criados - um Internet Gateway, porta
de saída e entrada para comunicação com a internet que já é redundante e altamente
disponível e um conjunto de Network Access Control Lists (NACLs). Foram criadas duas
NACLs - uma para as subredes privadas e uma para as subredes públicas. O motivo para isto
é um melhor refinamento das conexões que podem ser feitas na VPC, e reforçar regras de
segurança. O conjunto de NACLs público permite a entrada de conexões de qualquer origem
nas portas 22, 80, 443. Elas são utilizadas para acesso Secure Shell (SSH), conexão Hyper
Text Transfer Protocol (HTTP) e conexão Hyper Text Transfer Protocol Secure (HTTPS)
respectivamente.
As portas efêmeras são liberadas da mesma forma e todo o resto é bloqueado. No caso
da NACL para as subredes privadas, tráfego de origem interna à VPC pode fazer conexão
com as portas 22, 80, 443, 6379 e 3306 - além das já mencionadas, as portas 6379 e 3306 são
para os serviços de Redis e MySQL respectivamente. Assim como na NACL para subredes
públicas, as portas efêmeras são liberadas de qualquer origem e todo o resto é bloqueado. Os
recursos criados também são protegidos por Security Groups, que serão abordados nas áreas
específicas dos serviços que os utilizam.
32
Portas efêmeras, segundo a Microsoft (2019), são as portas dinâmicas utilizadas para
conexões de saída. A sua liberação é necessária pois ambas as subredes tem acesso à internet.
A diferença é que o trafégo das subredes privadas é roteado através de dois NAT Gateways
que estão provisionados na subrede pública na mesma zona de disponibilidade. Com isso,
recursos provisionados nas subredes públicas podem acessar e ser acessados através da
internet, enquanto recursos nas subredes privadas podem acessar a internet mas não são
acessíveis a partir dela.
3.2.2 Bastion Host
Segundo Malaval (2016, on-line, tradução nossa), um bastion host é um “servidor cujo
objetivo é prover acesso a uma rede privada a partir de uma rede pública, como a Internet”.
Assim, caso seja necessário acessar instâncias de aplicação para verificar a integridade do
sistema ou para alguma operação manual, os servidores bastion são acessados primeiro, e a
partir deles, o administrador pode acessar os demais recursos. A Figura 5 mostra a localização
dos bastion hosts no diagrama da VPC.
Figura 5 – Bastion hosts na VPC
Fonte: elaborado pelo autor.
A partir da Figura 5, pode-se notar que ambos os servidores bastion existem dentro de
um Security Group chamado “Bastion Group”, representado pelo tracejado vermelho, que é
utilizado para garantir que apenas acesso SSH (porta 22) possa ser feito às instâncias, além de
ser utilizado para determinar a origem do tráfego SSH interno à VPC para acesso às instâncias
de aplicação. Na arquitetura, o Security Group das instâncias de aplicação permite acesso
SSH a partir de instâncias no Security Group “Bastion Group”. Também é utilizado um Auto
33
Scaling Group que garante a existência de Bastion Hosts em múltiplas zonas de
disponibilidade a fim de suportar a perda de uma destas.
Uma IAM Role é uma “identidade IAM [...] que possui permissões específicas” e
podem ser vinculadas a “usuários, aplicações ou serviços que normalmente não tem acesso a
[...] recursos da AWS” (AMAZON WEB SERVICES, 2019m, on-line, tradução nossa). O
módulo “bastion” criado com Terraform provisiona uma IAM Role para as instâncias que
servirão como bastion para acesso à listagem de grupos e chaves públicas de usuários do IAM
e ao parâmetro de uma chave privada gerenciada pelo módulo para acesso às instâncias de
aplicação. O módulo cria uma tarefa agendada no servidor que servirá como bastion que a
cada minuto realiza requisições à API da AWS para verificar se algum usuário pertence ao
grupo do IAM criado pelo módulo - esta deve ser uma ação manual no Console da AWS ou
através da API da AWS, e garante que acesso de usuários pode ser adicionado ou revogado
facilmente. Na Figura 6 está diagramado o comportamento dos bastion hosts e a forma como
acesso é controlado utilizando-se de chamadas à API da AWS.
Figura 6 – Funcionamento do módulo de bastion hosts
Fonte: elaborado pelo autor.
Uma vez que um usuário foi adicionado ou removido do grupo, a rotina cria ou remove
o usuário do servidor. Ao adicionar um novo usuário, ele é criado sem senha para que
métodos de invasão, que tentem descobri-la, não sejam efetivos e a sua chave pública é
adicionada à lista de chaves com permissão de acesso SSH do novo usuário. Uma requisição à
API do AWS Parameter Store é realizada para buscar a chave privada que garante acesso aos
servidores de aplicação e esta é configurada para o novo usuário. A chave pública do par de
chaves gerenciado pelo módulo é configurada no usuário Linux padrão da instância, que roda
o sistema operacional Amazon Linux.
34
3.2.3 Contêineres e serviços principais da arquitetura
O Magento depende de alguns serviços básicos para o seu funcionamento. Estes
incluem um servidor de banco de dados MySQL, um servidor Web e um processo capaz de
processar scripts PHP. Estes últimos podem ser supridos pela combinação de Nginx e PHP-
FPM ou do servidor Apache HTTPD com o módulo do PHP. A partir da versão 2.0 do
Magento, também há suporte nativo ao Varnish, um proxy http reverso que é capaz de manter
em cache uma página inteira, recurso chamado de Full Page Cache, ou FPC. Por padrão, ao
rodar em um único servidor, é possível ter todos estes serviços na mesma instância. Neste
caso, o armazenamento padrão de cache que não é armazenado pelo Varnish, como cache de
configuração e blocos HTML, é armazenado em arquivos. As sessões dos usuários também
são armazenadas em arquivos, assim como as imagens carregadas através do painel
administrativo da loja.
Apesar de ser uma opção rodar a aplicação em um único servidor, neste caso só é
possível realizar o scale-up deste servidor. Isto significa aumentar seus recursos de memória e
processamento, e este processo incorre em alguns minutos de parada do serviço para ser
realizado. Desta forma perde-se em disponibilidade pois se a zona de disponibilidade onde o
servidor se encontra falhar, o serviço inteiro será interrompido. Estas características
contrastam com a arquitetura definida, que pressupõe mais de um servidor respondendo pela
aplicação, garantindo que caso um deixe de responder, outro se mantenha ativo. Além disso,
existe a possibilidade de scale-out, adicionando mais servidores para responder pela loja e
sem a necessidade de uma janela de indisponibilidade.
A fim de atingir estes requisitos, cada componente suscetível a falha foi isolado, de
forma a minimizar os pontos únicos de falha, ou seja, pontos que em caso de problemas,
impactam na disponibilidade do serviço. A camada de banco de dados da aplicação está num
serviço gerenciado da AWS, o Relational Database Service (RDS), replicado entre duas
zonas de disponibilidade de forma síncrona. O motor de banco Aurora foi utilizado – trata-se
de uma distribuição compatível com MySQL, de código fechado, desenvolvido pela AWS
para o seu ambiente.
O armazenamento de cache e sessão estão cada um em um cluster do ElastiCache de
Redis na AWS com replicação assíncrona entre duas zonas de disponibilidade. A fim de não
manter nenhum ponto único de falha para carregamento da mídia, foi utilizada o serviço EFS
da AWS que permite a montagem de um sistema de arquivos através da rede, assim
compartilhando estes entre todas as instâncias.
35
A parte da aplicação em si, que consiste no servidor Web, processador PHP e o código
da loja, foi encapsulado em um contêiner. Uma imagem de um contêiner Docker é criada
utilizando Nginx e PHP-FPM. Nesta imagem, um script de inicialização cria o arquivo de
configuração do Magento com base em variáveis de ambiente e inicia os processos que
transformam o próprio Magento em um serviço.
O processo do Varnish ficou em uma imagem separada. Esta imagem também possui
um script próprio, que ajusta o arquivo de configuração do Varnish com base em variáveis de
ambiente e inicia o processo em seguida. A Figura 7 apresenta a arquitetura proposta com
base nestas medidas.
Figura 7 – Arquitetura contendo os serviços principais
Fonte: elaborado pelo autor.
Na Figura 7, a instância EC2 não é única - ela faz parte de um Auto Scaling Group que
permite que outras, iguais a ela, sejam iniciadas conforme a demanda implementando assim
scale-out. Também é importante ressaltar que os contêineres não rodam necessariamente na
36
mesma instância, mas conforme os recursos disponíveis em cada uma, este gerenciamento é
feito pelo Elastic Container Service (ECS), que, assim como os clusters de ElastiCache Redis,
não foram diagramados para melhor legibilidade. Estes últimos têm uma estrutura semelhante
à dos bancos no RDS, com a diferença de ter replicação assíncrona.
Uma análise melhor da infraestrutura pode ser feita analisando o fluxo com base na
requisição de um cliente, representado pelas setas da Figura 7. Uma vez que a loja é aberta a
partir de um navegador, uma requisição é feita para o balanceador de carga, representado na
parte superior da Figura 7. Ele encontra-se em uma subrede pública e roteia tráfego para um
ou mais contêineres de Varnish, que ficam em subredes privadas. O Varnish então devolve a
página caso já tenha realizado o cache dela, ou encaminha a requisição para um contêiner de
Magento. Conforme a requisição, dados são recuperados do banco de dados (RDS), do
armazenamento de cache (ElastiCache Redis) ou do sistema de arquivos compartilhado (EFS)
no caso das imagens. É preciso notar que cada um destes componentes é isolado por Security
Groups, que garantem privilégio mínimo de acesso a cada recurso.
A comunicação entre contêineres Varnish e Magento se dá de forma transparente - o
serviço Cloud Map, da AWS, permite a criação de uma camada de abstração que trata da
descoberta de serviços. Na prática, a cada vez que um novo contêiner é criado através do
auto-scaling de serviços do ECS, ele é vinculado a uma interface de rede somente dele, com
um IP privado e Security Group específico. Este IP é armazenado numa entrada DNS do tipo
A para cada serviço - assim, quando dois serviços de Varnish estiverem rodando, haverá dois
apontamentos DNS, um para cada contêiner - o mesmo comportamento ocorre com o serviço
do Magento. Quando o Varnish precisar se comunicar com o Magento, ele direciona o tráfego
para uma das entradas DNS, e da mesma forma quando a comunicação se inverte.
3.2.4 Pipeline de construção do Magento
A infraestrutura definida também contempla a utilização dos serviços AWS
CodeCommit (serviço Git gerenciado), AWS CodeBuild (para realização da construção) e
AWS CodePipeline (integrador de vários passos de construção) para criação das imagens do
contêiner do Magento, que são publicadas no AWS Elastic Container Registry, um serviço
que oferece armazenamento privado de imagens Docker. A Figura 8 demonstra o pipeline de
criação.
37
Figura 8 – Pipeline de criação da imagem de contêiner Magento
Fonte: elaborado pelo autor.
Como pode ser observado na Figura 8, o serviço CodePipeline serve como
centralizador das partes. Este serviço é responsável por recuperar o código versionado no
CodeCommit (à esquerda do CodePipeline) e alguns parâmetros armazenados no Parameter
Store (à direita do CodePipeline) que são usados para criação da imagem, no caso, as
credenciais para acesso ao repositório oficial do Magento.
Os artefatos gerados durante a execução da pipeline são armazenados no serviço S3
(acima do CodePipeline). Estes artefatos incluem resultados de cada uma das etapas, como o
código obtido a partir do Code Commit e a aplicação construída pelo CodeBuild (abaixo do
CodePipeline). O CodeBuild utiliza um arquivo chamado “buildspec.yml” para determinação
de quais passos serão executados para realizar a construção ou a compilação da aplicação. Ele
também requer uma imagem Docker para executar estes passos. A imagem oficial do Docker
para o CodeBuild foi utilizada no projeto, pois alguns passos envolvem a criação e
manipulação de diferentes contêineres.
Uma imagem foi criada para executar os comandos durante o build e para servir de
base para a imagem final do Magento. Esta imagem já possui instalados o PHP, PHP-FPM e
Nginx e está armazenada no Docker Hub, um registry público. Os comandos necessários para
a construção do Magento são executados e ao final desta etapa, o CodeBuild monta uma
imagem Docker contendo o código gerado dentro da imagem base. Esta nova imagem é então
enviada para o ECR, que é acessado por instâncias de contêiner, que extraem e rodam as
imagens localmente.
A arquitetura também inclui uma imagem de contêiner do Varnish. Esta não é
construída na AWS, mas também foi criada e é armazenada no Docker Hub. Neste caso, as
instâncias de contêiner podem baixar a imagem diretamente do registry público.
38
3.3 IMPLEMENTAÇÃO
3.3.1 Contêineres
O Quadro 5 apresenta o arquivo que permite a criação da imagem de contêiner de
Magento. A imagem do oficial do PHP 7.2 é extendida neste arquivo para conter as extensões
necessárias do PHP, instalação do servidor Web Nginx e o conteúdo dos arquivos de
configuração tanto do Nginx quanto do PHP. Ao final é referenciado o script primário de
execução da imagem, que é rodado quando o contêiner inicia.
Quadro 5 – Arquivo para gerar a imagem de contêiner do Magento FROM php:7.2-fpm-stretch
# git and procps are required to run setup:dev:tests
RUN apt-get update --no-install-recommends \
&& apt-get install -y \
libpng-dev \
libicu-dev \
libxmlrpc-core-c3-dev \
libxslt1-dev \
libfreetype6-dev \
libjpeg62-turbo-dev \
git \
procps \
nginx \
curl \
&& rm -rf /var/lib/apt/lists/* \
&& rm -Rf /etc/nginx \
&& docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --
with-jpeg-dir=/usr/include/ \
&& docker-php-ext-install bcmath gd intl pdo_mysql soap hash opcache
xsl zip \
&& php -r "copy('https://getcomposer.org/installer', 'composer-
setup.php');" \
&& php composer-setup.php --install-dir=/usr/local/bin --
filename=composer \
&& php -r "unlink('composer-setup.php');" \
&& curl -s
http://gordalina.github.io/cachetool/downloads/cachetool.phar -o
/usr/local/bin/cachetool && chmod +x /usr/local/bin/cachetool \
&& mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini" \
&& find "$PHP_INI_DIR" -name php.ini -exec sed -i
's/memory_limit.*/memory_limit = -1/g' {} \; \
&& rm /usr/local/etc/php-fpm.d/* -f \
&& rm -Rf /var/www \
&& groupadd web -g 1212 \
&& useradd -m -u 1212 -g web -s /bin/bash magento
COPY nginx /etc/nginx
COPY fpm.conf /usr/local/etc/php-fpm.d/
COPY magento /var/www
COPY entrypoint.sh /entrypoint.sh
CMD ["bash", "/entrypoint.sh"]
Fonte: elaborado pelo autor.
39
O Quadro 6 apresenta a imagem que permite a criação da imagem de contêiner de
Varnish, que consiste na instalação de pacotes para realização do build do Varnish com o
módulo que realiza atualizações dinâmicas do IP do servidor de origem do conteúdo
armazenado no Varnish, seguido do build em si. Ao final, um script que é rodado no início da
execução do contêiner é definido.
Quadro 6 – Arquivo para gerar a imagem de contêiner de Varnish
FROM bitnami/minideb:stretch
# Build Varnish 6.2 with vmod dynamic
RUN apt-get update \
&& apt-get install -y git make libtool m4 automake pkg-config
python3-docutils python3-sphinx libpcre3-dev libedit-dev libcurl3 \
&& cd /root \
&& git clone -b 6.2 --depth 1
https://github.com/varnishcache/varnish-cache.git \
&& cd /root/varnish-cache/ \
&& ./autogen.sh \
&& ./configure \
&& make \
&& make install \
&& cd /root \
&& rm -Rf /root/varnish-cache/ \
&& git clone -b 6.2 --depth 1 https://github.com/nigoroll/libvmod-
dynamic.git \
&& cd /root/libvmod-dynamic/ \
&& ./autogen.sh \
&& ./configure \
&& make \
&& make install \
&& cd /root \
&& rm -Rf /root/libvmod-dynamic \
&& apt-get purge -y --autoremove git make libtool m4 automake pkg-
config python3-docutils python3-sphinx libpcre3-dev libedit-dev \
&& apt-get install gcc libbsd0 libedit2 libncurses5 curl -y \
&& rm -Rf /var/lib/apt/lists/* \
&& useradd varnish
ADD entrypoint.sh /entrypoint.sh
CMD /entrypoint.sh
Fonte: elaborado pelo autor.
3.3.2 Ansible
O Quadro 7 mostra o arquivo YAML de configuração do Ansible que inclui outras
funcionalidades para a criação do backend do Terraform, configuração de suas variáveis e por
fim sua execução. É interessante notar que o Ansible vai rodar na máquina local e não em um
servidor remoto, através da especificação da seção hots como localhost.
40
Quadro 7 – Arquivo principal do Ansible
---
- hosts: localhost
gather_facts: false
connection: local
tasks:
- import_tasks: init_vars.yml
tags:
- always
- include_role:
name: terraform_backend
tags:
- tf_backend
- include_role:
name: terraform_variables
tags:
- tf_vars
- include_role:
name: terraform
tags:
- terraform
Fonte: elaborado pelo autor.
3.3.3 Terraform
O Quadro 8 apresenta o módulo principal do Terraform, a partir do qual os outros são
incluídos. Este módulo define o provedor da nuvem que será utilizado, no caso o provedor da
AWS e em seguida inclui o módulo de rede, que cria e configura a VPC com subredes
públicas e privadas. Em seguida é criado o repositório no Elastic Registry Service (ECR) que
será usado para armazenar a imagem do Magento. Uma referência deste é utilizada como
parâmetro para o módulo dev_pipeline, que cria configura os recursos necessários para
criação da imagem e subsequente envio dela ao repositório no ECR. Os módulos seguintes
contemplam a configuração dos Bastion Hosts e o módulo “magento”, que provisiona os
recursos que vão suportar a arquitetura da aplicação durante sua execução, como ElastiCache,
RDS, EC2 e ECS.
41
Quadro 8 – Módulo principal do Terraform
# Specify the provider and access details
provider "aws" {
region = "${var.aws_region}"
}
module "network" {
source = "modules/network"
project_name = "${var.project_name}"
}
resource "aws_ecr_repository" "cmage" {
name = "${terraform.workspace}-${var.project_name}"
}
module "dev_pipeline" {
source = "modules/dev_pipeline"
project_name = "${var.project_name}"
repository = "${var.repository}"
aws_ps_prefix = "${var.aws_ps_prefix}"
buildspec_file_path = "${var.buildspec_file_path}"
vpc_id = "${module.network.vpc_id}"
ecr_repo_arn = "${aws_ecr_repository.cmage.arn}"
private_subnets = "${module.network.private_subnets}"
}
module "bastion-hosts" {
source = "modules/bastion"
name_prefix = "${terraform.workspace}-${var.project_name}-"
vpc_id = "${module.network.vpc_id}"
subnets = "${module.network.public_subnets}"
}
module "magento" {
source = "modules/magento"
project_name = "${var.project_name}"
private_subnets = "${module.network.private_subnets}"
public_subnets = "${module.network.public_subnets}"
cluster_node_instance_type = "c5.large"
db_instance_type = "db.r5.xlarge"
cache_instance_type = "cache.m5.large"
session_instance_type = "cache.m5.large"
mq_instance_type = "mq.t2.micro"
db_name = "cmage"
magento_image_uri = "${aws_ecr_repository.cmage.repository_url}"
vpc_id = "${module.network.vpc_id}"
aws_ps_prefix = "${var.aws_ps_prefix}"
magento_ecr_arn = "${aws_ecr_repository.cmage.arn}"
certificate_arn = "${var.certificate_arn}"
public_key_name = "${module.bastion-hosts.public_key_name}"
bastion_host_sg = "${module.bastion-hosts.sg_id}"
}
Fonte: elaborado pelo autor.
3.3.4 Locust
A classe que representa os testes possui cinco métodos. O primeiro deles é executado
pelo Locust quando a ferramenta cria um novo usuário, e realiza uma requisição para a página
42
de Login do Magento a fim de adquirir uma informação importante relacionada à sessão, o
form_key. Este campo é utilizado pelo Magento para evitar roubo de sessão dos usuários, e
deve ser enviado em todas as requisições para validar se a sessão pertence ao usuário correto.
Nesta etapa também é feita uma escolha aleatória para definir se uma conta será criada no
Magento, chamando o método que corresponde a esta ação em caso positivo. Há também um
método de busca, que utiliza um termo de busca aleatório para realizar pesquisas no Magento
e retorna o conteúdo da página de busca.
O método que adiciona itens ao carrinho espera como parâmetro o conteúdo de uma
página que contenha diversos produtos, abre a página de um item aleatório e adiciona o item
ao carrinho. Este método é capaz de identificar se o produto é do tipo simples ou
configurável, adicionando as configurações do produto à requisição se necessário. Ele
também esvazia o carrinho aleatoriamente. O último método é entendido pelo Locust como
uma “tarefa”, método que de fato é chamado durante a execução dos testes. Este método
chama o método de busca e utiliza o seu retorno como parâmetro do método de adição de item
ao carrinho, além de limpar os dados de sessão do usuário de forma aleatória.
O Quadro 9 apresenta o método principal do Locust, que busca por uma página,
retorna o código-fonte HTML e encaminha o resultado para o método que encontra e adiciona
produtos ao carrinho. Ao final, a sessão é aleatoriamente renovada.
Quadro 9 – Método principal do Locust
@task(25)
def shop(self):
page = self.search().text
self.add_random_item_to_cart(page)
if (bool(random.getrandbits(1))):
self.client.close()
self.client.cookies.clear()
self.on_start()
Fonte: elaborado pelo autor.
3.4 ANÁLISE DOS RESULTADOS
O trabalho cumpre com os requisitos funcionais e atende bem a estes pois permite uma
parametrização mínima do usuário para que a infraestrutura possa ser criada. A arquitetura
proposta também contempla uma imagem Docker da aplicação, utilização de Redis para
armazenamento de cache e sessão da aplicação e a utilização de Ansible e Terraform, que são
cumprimentos de requisitos não funcionais. Outros dois requisitos não funcionais são o foco
desta seção, pois a validação destes garante que a arquitetura desenvolvida é capaz de suportar
a perda de uma zona de disponibilidade e escalar de forma horizontal para atender a
43
requisições. Assim, esta seção é dividida em duas partes, a primeira simulando uma
indisponibilidade de uma zona de disponibilidade e a segunda realizando um teste de carga na
infraestrutura a fim de avaliar a sua capacidade de escalar.
Além disso, com o versionamento da infraestrutura em código, todos os recursos são
criados na nuvem em cerca de 11 minutos. O tempo para destruir os recursos criados com
Terraform foi de aproximadamente 30 minutos. Alguns recursos criados pelo Ansible e pelo
Terraform precisam de ações manuais para ser excluídos, como é o caso do Amazon S3, que
não permite a exclusão de um armazenamento que ainda contenha arquivos. Como a
funcionalidade padrão de criação e remoção de recursos das ferramentas foi utilizada, não
houve procura por uma solução para contornar este cenário.
3.4.1 Testes de disponibilidade
Para validar se a arquitetura proposta suporta a perda de uma zona de disponibilidade,
e tendo em vista que não há uma ferramenta da AWS que simule este tipo de cenário, algumas
ações manuais foram realizadas a fim de simular a perda da zona A, garantindo que recursos
na zona B continuassem a responder. A primeira camada trabalhada foi a das instâncias de
contêineres - todas as instâncias da zona A foram terminadas e o Auto Scaling Group foi
reconfigurado para criar novas máquinas somente na zona B. Em seguida cada um dos
serviços diretamente relacionados à execução e disponibilidade do Magento foi ajustado.
Como os clusters de Redis e MySQL trabalham no modelo instância primária e réplica, nos
casos necessários um failover foi feito no cluster para que a instância primária fosse a
existente na zona B. Após estes ajustes, a camada de rede foi alterada de forma a negar todo o
tráfego da zona de disponibilidade A. Isto foi atingido através da criação de uma NACL que
nega todo o tráfego, que foi vinculada às subredes pública e privada da zona A. Após estas
ações, a aplicação continuou a responder normalmente por requisições.
Em casos de falha real em uma zona de disponibilidade, entretanto, ações manuais não
devem ser necessárias. Os clusters Redis foram criados com a opção de failover automático,
que é realizado em casos como manutenções planejadas ou perda de uma zona de
disponibilidade (AMAZON WEB SERVICES, 2019n). Da mesma forma, no caso de falha da
instância primária do banco de dados, um failover automático é realizado (AMAZON WEB
SERVICES, 2019o). O Auto Scaling Group cria instâncias em uma zona de disponibilidade
saudável no caso de falha da outra (AMAZON WEB SERVICES, 2019p). O único serviço
que não requer qualquer tipo de ação é o EFS, que por ser totalmente gerenciado já é
altamente disponível e resiliente por padrão (AMAZON WEB SERVICES, 2019q).
44
3.4.2 Testes de carga
Uma potencial infraestrutura de produção foi utilizada para a execução dos testes. No
entanto, a conta utilizada tinha limites impostos pela AWS com relação ao número máximo de
instâncias rodando. Mesmo requisitando um limite de 30 instâncias junto à AWS, liberaram
apenas 20. Isto pode afetar a capacidade máxima suportada pela infraestrutura caso o gargalo
não seja a rede, banco de dados ou servidor de cache, por exemplo. O custo total da
infraestrutura criada durante o período de testes, incluindo as instâncias utilizadas para rodar a
ferramenta de testes foi de 58,18 dólares – as cobranças são referentes a cerca 30 horas em
que a infraestrutura rodou. O dimensionamento utilizado no primeiro teste da infraestrutura
pode ser observado no Quadro 3.
Quadro 10 – Dimensionamento da infraestrutura no primeiro teste
Serviço Função Tamanho ElastiCache Armazenamento de Sessão m5.large
ElastiCache Armazenamento de Cache m5.large
RDS Banco de dados r5.large
EC2 Instâncias de contêineres rodando
Varnish ou Magento
Auto Scaling Group de até 20
c5.large
EC2 Instância que executa os testes c5.large Fonte: elaborado pelo autor.
Uma loja com dados de amostra contendo “mais de 250 produtos (dos quais cerca de
200 são configuráveis), categorias, regras de preços promocionais, páginas CMS, banners”
(MAGENTO, 2015, on-line, tradução nossa) foi utilizada – os dados fictícios da loja são
oferecidos pela Magento através do módulos Sample Data.
O sistema escolhido para esta parte foi Locust, uma ferramenta criada para testes de
carga que apuram a quantidade simultânea de usuários que um sistema pode suportar
(LOCUST, 2019). Os testes são criados com a linguagem de programação Python, que
oferece a flexibilidade necessária para testar o Magento. Os autores consideraram as ações
principais de um usuário em uma loja como sendo a navegação, o cadastro de usuário, a
adição de itens ao carrinho e a finalização de pedido. Os testes desenvolvidos focaram nos
três primeiros itens, pois a ação de finalização de compra representa uma parcela menor das
requisições totais. As instâncias que rodam o teste de carga foram criadas manualmente na
mesma VPC criada no trabalho e por isto oferece latência de rede mínima. A única ressalva é
com relação ao fato de apontar para o balanceador de carga, que possui IP público. Assim, as
requisições saem da VPC e resolvem para o balanceador de carga, que retorna para ela.
A Figura 9 mostra o resultado de uma execução preliminar dos testes. Os gráficos
representam a quantidade de requisições por segundo e o tempo de resposta em
45
milissegundos, respectivamente. No topo pode ser observado que neste momento há 15% de
falha do total de requisições.
Figura 9 – Primeira execução dos testes
Fonte: elaborado pelo autor.
O problema encontrado nesta primeira execução era um retorno do código de status
HTTP 502 do servidor para o cliente. Após a análise dos logs do servidor Web, o problema
que foi identificado ocorreu devido ao tamanho dos cabeçalhos enviados na resposta do PHP
para o cliente, que pôde ser corrigido ajustando a configuração do Nginx. A Figura 10 mostra
os erros que ocorriam.
Figura 10 – Erros na primeira execução
Fonte: elaborado pelo autor.
Em seguida, novos testes foram executados. Após alguns minutos, uma quantidade
crescente de requisições com falha voltou a ocorrer devido a um código de status HTTP 500.
Os logs do PHP e do Nginx nada revelaram, mas uma mensagem de erro frequente nos logs
da aplicação indicaram o problema. No Magento, os Cookies têm um tamanho e uma
quantidade máxima, quando um destes é excedido, uma exceção é lançada. A Figura 11 indica
os erros que ocorreram na segunda execução dos testes.
46
Figura 11 – Erros na segunda execução
Fonte: elaborado pelo autor.
Ao adicionar uma linha de código que imprimia o conteúdo do cookie “mage-
messages”, referenciado na mensagem, o problema tornou-se mais claro. A sessão dos
usuários simulados havia expirado para o Magento e a mensagem de erro sobre isto era
adicionada continuamente aos cookies, aumentando seu tamanho até o limite. Para evitar este
problema, o código de testes foi alterado para limpar os cookies dos usuários, efetivamente
iniciando uma nova sessão para eles de forma aleatória. Com isto, a execução dos testes de
carga ocorreram sem erros. A Figura 12 apresenta os resultados de uma terceira execução,
sem erros.
Figura 12 – Execução sem erros do teste de carga
Fonte: elaborado pelo autor.
A partir da Figura 12 é possível observar os momentos em que a quantidade de
usuários simulados aumentou nos pontos A, de 60 para 80 usuários e B de 80 para 110
usuários simultâneos. Nestes intervalos há um aumento do tempo de resposta do Magento
para atender às requisições devido ao uso elevado de recursos exigidos. A infraestrutura
comportou-se sem problemas com 110 usuários simultâneos, e os gráficos de uso de
processamento do banco de dados e ElastiCache ficaram estáveis e baixos, sendo que a maior
variação ocorreu no Auto Scaling Group de instâncias de contêineres. Ao final destes testes,
50 usuários foram cadastrados na aplicação e um total de 5038 cotações foram criadas na loja.
47
No entanto, a quantidade de requisições por segundo se manteve em aproximadamente
30 em vez de aumentar proporcionalmente à quantidade de usuários. A fim de ter uma melhor
noção da capacidade e dos limites da infraestrutura, um conjunto de máquinas foi utilizado
para realizar uma nova execução. Inicialmente este grupo continha apenas uma máquina do
tipo m3.2xlarge, que possui 8 CPUs 30GB de memória. Conforme a execução do teste, um
novo limite foi atingido, levando a um grupo contendo a máquina original, outras duas do tipo
m3.xlarge (4 CPUs e 15GB de memória) e uma do tipo m4.xlarge, que possui 4 CPUs e 16GB
de memória.
Em momentos de pico, foi possível observar cerca de 9 mil requisições por minuto no
monitoramento do balanceador de carga, 427 usuários simultâneos, e aproximadamente 18
mil consultas por segundo no banco de dados. Ao total, 240 usuários foram criados no
Magento e 22843 cotações foram geradas na loja. Tendo em vista que o teste rodou por
aproximadamente duas horas, isto significa 190 cotações criadas a cada minuto.
Algumas ações tiveram de ser realizadas na infraestrutura para garantir que alguns
pontos de falha não afetassem o resultado do teste. A instância de banco de dados do tipo
r5.large chegou a 80% de uso de CPU, e não poderia mais suportar um aumento significativo
na quantidade de usuários. Para solucionar este gargalo, a instância réplica foi alterada para
r5.xlarge, e um failover, processo de troca de uma instância para outra, foi realizado. Isto
gerou uma indisponibilidade de menos de um minuto na aplicação. A Figura 13 item (a)
mostra o uso de CPU da instância inicial, onde o pico de processamento é causado por
requisições de 300 usuários simultâneos e o item (b) da Figura 3 mostra o uso após o failover
para uma instância maior, com o pico de processamento gerado por 420 usuários simultâneos.
48
Figura 13 – Consumo de CPU
(a) Pico causado por 300 usuários na
instância do tipo r5.large
(b) Pico causado por 420 usuários na instância
do tipo r5.xlarge Fonte: elaborado pelo autor.
Outro fator importante a ser considerado é uso de banda de rede das instâncias que
executaram o teste de carga. Em determinados momentos, os gráficos gerados pelo Locust
indicavam um tempo de resposta de até 10 segundos do servidor, mas ao navegar na loja pelo
navegador o processo de compra e cadastro de usuário eram mais rápidos do que os gráficos
apontavam. Isto pode ter ocorrido devido ao limite de banda das instâncias de teste de carga
utilizadas. A Figura 14 apresenta o uso de rede destas instâncias.
Figura 14 – Uso de rede das instâncias de teste
Fonte: elaborado pelo autor.
Assim, para analisar melhor os tempos de resposta da aplicação, os gráficos do
balanceador de carga referentes ao tempo de resposta das máquinas foram considerados. Este
pode ser encontrado na Figura 15, que sugere que o maior tempo de resposta ficou em torno
de 2,18 segundos.
49
Figura 15 - Tempo de resposta dos servidores segundo o monitoramento do balanceador de
carga
Fonte: elaborado pelo autor.
Em termos de escalabilidade, o Auto Scaling da AWS criou e destruiu instâncias
conforme o necessário, exibido na Figura 16. Apesar disso, foi possível notar uma quantidade
significativa de erros em determinados momentos, que ocorreram devido ao tempo que se
levava para que novas instâncias fossem criadas. O serviço, no entanto, escala de forma
automática.
Figura 16 – Quantidade de instâncias rodando
Fonte: elaborado pelo autor.
Nestes testes também houve uma quantidade significativa de erros, em parte devido ao
failover do banco de dados, mas também devido a um pequeno atraso na escalada dos
serviços. A Figura 17 mostra a quantidade de código HTTP 5XX apresentados no
monitoramento do balanceador de carga no decorrer da execução. Erros HTTP que iniciam
com 5 são “casos nos quais o servidor está ‘ciente’ de que está com erros ou é incapaz de
processar o método requisitado” (INTERNET ENGINEERING TASK FORCE, 2014, on-
line, tradução nossa).
50
Figura 17 – Erros 5XX no monitoramento do balanceador de carga
Fonte: elaborado pelo autor.
Por fim, um último teste foi executado, com a infraestrutura já escalada ao máximo. A
instância de banco de dados do tipo r5.xlarge, 20 instâncias c5.large e os serviços de
contêineres rodando de acordo. Foi possível constatar que a infraestrutura criada pode
suportar até 400 usuários simultâneos que estejam realizando adição de produtos ao carrinho e
realizando cadastros. Neste teste, um total de 24950 cotações foram criadas, assim como 735
usuários, num período de uma hora. Como se tratou de um teste com a infraestrutura já
escalada, é possível notar um aumento significativo na quantidade de cotações criadas por
minuto (415), em contraste com as 190 por minuto criadas no teste anterior. Os tempos de
resposta no decorrer do tempo são apresentados na Figura 18, com alterações visíveis
conforme o aumento dos usuários, apresentado na Figura 19.
Figura 18 – Tempos de resposta no decorrer do tempo
Fonte: elaborado pelo autor.
51
Figura 19 – Usuários no decorrer do tempo de duração dos testes
Fonte: elaborado pelo autor.
Neste teste um total de 5 instâncias foram utilizadas a fim de evitar que os tempos de
resposta registrados na ferramenta de teste fossem afetados pelo uso de rede das instâncias
que a executavam. Ao total, foram duas m3.2xlarge, duas m3.xlarge e uma m4.xlage. Foi
possível notar que não houveram erros do tipo 5XX no monitoramento do balanceador de
carga, porque a instância de banco de dados não teve de passar pelo failover e as instâncias de
Magento já estavam escaladas. O tempo de resposta das instâncias balanceadas também foi
menor pelo mesmo motivo, e pode ser visualizado na Figura 20.
Figura 20 – Tempo de resposta segundo o monitoramento do balanceador de carga em novo
teste
Fonte: elaborado pelo autor.
O resultado dos testes também revelou que as partes mais sensíveis à quantidade de
usuários ativos são o banco de dados relacional e as instâncias de contêiner executando o
Magento e o Varnish. O ElastiCache rodando Redis não apresentou aumento significativo no
uso de recursos de CPU para sessão nem para o cache, apenas uma redução na quantidade de
memória disponível, o que é esperado devido à natureza do armazenamento em memória
deste banco. Um fator importante que deve ser analisado conforme o ambiente é escalado é o
uso de banda de rede destas instâncias, pois este pode se tornar um potencial gargalo deste
elemento da arquitetura.
A infraestrutura já escalada chegou a suportar cerca de 17 mil consultas por segundo
no banco de dados, 10 mil requisições por minuto registradas no balanceador de carga e 460
52
usuários simultâneos. Foi possível identificar um período de instabilidade e falhas que foram
registradas somente pela ferramenta de teste, um indicativo de que a infraestrutura tenha
respondido corretamente (uma vez que o monitoramento do balanceador de carga não
registrou problemas) mas que algum erro ocorreu em alguma das instâncias de Locust quando
480 usuários foram simulados. Após este período, o comportamento normalizou e um pico de
703 usuários simulados foi registrado, conforme apresentado na Figura 19. A Figura 21
mostra o gráfico do Locust incluindo o período de instabilidade.
Figura 21 – Tempo de resposta registrado no Locust incluindo período de instabilidade
Fonte: elaborado pelo autor.
53
4 CONCLUSÕES
O trabalho apresentado serviu como um meio para validar uma arquitetura na nuvem
que fosse robusta, escalável e resiliente para o Magento. O resultado foi uma infraestrutura
que, através da utilização de contêineres Docker, é altamente disponível por garantir a
operação do serviço mesmo com a perda de uma zona de disponibilidade da AWS. Além
disto, a infraestrutura é escalável por aumentar ou reduzir automaticamente o seu tamanho de
forma a se adequar à demanda – limites neste quesito podem decorrer de um limite da
quantidade ou tamanho das instâncias permitidas pela AWS para a conta na qual o ambiente é
criado.
A utilização de um provedor de plataforma como serviço na nuvem foi fundamental
para o cumprimento dos objetivos, pois permitiu que a infraestrutura fosse criada e destruída
em poucos minutos com cobranças somente pelo tempo em que ficou rodando. A nuvem
também permitiu que houvesse versionamento da infraestrutura e o desenvolvimento de uma
arquitetura de alta disponibilidade com distribuição de dados e recursos computacionais entre
duas zonas de disponibilidade.
O Magento se provou uma plataforma escalável e viável para a execução dos testes.
Com a arquitetura proposta foi possível isolar potenciais pontos de falha da aplicação de
forma a evitar indisponibilidades no serviço, como o armazenamento de cache, sessão de
usuários, dados e processamento da aplicação em si. A utilização de Docker como forma de
centralizar os serviços que permitem a execução do Magento como um serviço único
simplificou a forma de implantar o código, e permitiu que múltiplas instâncias idênticas
fossem criadas.
A solução criada possui uma limitação na parte que a integra ao fluxo de
desenvolvimento. Apesar de possuir uma pipeline que cria uma imagem contendo o código, a
atualização desta imagem no ambiente de produção não foi planejada. Assim, a cada vez que
uma nova imagem é criada, é necessário intervir manualmente para que ela comece a ser
utilizada para rodar a aplicação. Outra limitação está na limpeza do cache do Varnish. Como o
Magento não faz uma consulta DNS para recuperar todas as instâncias de Varnish, ele executa
a limpeza em apenas uma. Estes pontos podem ser revisitados numa futura extensão do
trabalho, assim como a possibilidade de utilização de serviços como o AWS Web Application
Firewall (WAF) para melhoria da segurança do Magento. É válido também realizar testes
reais com a perda de uma zona de disponibilidade. Um estudo mais aprofundado,
54
potencialmente em contato com a própria AWS, precisa ser realizado para identificar como
isto pode ser feito.
Este artigo se mostra relevante por tratar de um conceito ainda em desenvolvimento, a
implementação de infraestrutura como código. Além disso, trata-se de um estudo de caso
detalhado dos requerimentos necessários para a criação de uma arquitetura altamente
disponível, permitindo que projetos com objetivos similares utilizem técnicas semelhantes e
contribuindo assim com uma base de conhecimento científico na área.
4.1 EXTENSÕES
Extensões futuras podem incluir a utilização de um serviço que realiza a distribuição
de conteúdo estático para os clientes, reduzindo a carga no servidor de origem. Uma Content
Delivery Network (CDN) como o Cloud Front da AWS poderia ser utilizado para este fim. É
importante notar que os testes que foram realizados englobam buscas, cadastro de clientes e
criação de cotações ou carrinhos dos clientes, e apesar de ter se mostrarem estáveis durante os
testes a próxima etapa seria avaliar o comportamento da infraestrutura em um ambiente de
produção, identificando e resolvendo possíveis incongruências. Uma forma de realizar a
transição seria com a divisão do tráfego entre uma infraestrutura já existente e uma
quantidade menor direcionada para a desenvolvida no trabalho. Além disso, melhores
avaliações dos custos da infraestrutura também precisam ser realizadas, uma vez que este
objetivo não fazia parte do escopo do trabalho. A possibilidade de excluir todos os recursos
criados também precisa ser avaliada, pois alguns requerem ação manual para ser destruídos.
55
REFERÊNCIAS
AJZELE, Branko. Magento 2 Developer's Guide: Harness the power of Magento 2 to extend
and customize your online store. Birmingham: Packt Publishing Ltd, 2015. 9 p.
ALSMADI, Izzat; ALHAMI, Ikdam. The requirements for building an e-commerce
infrastructure. International Journal of Recent Trends in Engineering, Jordânia, v. 2, n. 2,
p. 7, nov. 2009.
ALTAMEEM, Eman; ALMAKKI, Riyad. E-commerce Implementation: A Critical Review.
International Journal of Computing Academic Research, Dubai, v. 6, n. 2, p. 12-19, abr.
2017.
AMAZON WEB SERVICES. Amazon EC2: Capacidade computacional segura e
redimensionável na nuvem. Lance aplicativos quando necessário, sem compromissos
antecipados. [S.l.], 2019i. Disponível em: <https://aws.amazon.com/pt/ec2/>. Acessado em:
28 de junho de 2019.
_____. Amazon S3 FAQs. [S.l.], 2019h. Disponível em:
<https://www.amazonaws.cn/en/s3/faqs/>. Acessado em: 28 de junho de 2019.
_____. AWS Well-Architected Framework, 2018.
_____ Calling the API by Making HTTP Query Requests. [S.l.], 2019k. Disponível em:
<https://docs.aws.amazon.com/IAM/latest/UserGuide/programming.html> Acesso em: 05 de
junho de 2019.
_____. Computação em nuvem com a AWS. [S.l.], 2019a. Disponível em:
<https://aws.amazon.com/pt/what-is-aws/>. Acessado em: 28 de junho de 2019.
_____. Definição de preço da AWS: Como funciona a definição de preço da AWS?. [S.l.],
2019b. Disponível em: <https://aws.amazon.com/pt/pricing/>. Acessado em: 28 de junho de
2019.
_____. Grupos de segurança do Amazon EC2 para instâncias do Linux. [S.l.], 2019j.
Disponível em: <https://docs.aws.amazon.com/pt_br/AWSEC2/latest/UserGuide/using-
network-security.html>. Acessado em: 28 de junho de 2019.
_____. Infraestrutura global: A infraestrutura de nuvem global mais extensa, confiável e
segura. [S.l.], 2019c. Disponível em: <https://aws.amazon.com/pt/about-aws/global-
infrastructure/>. Acessado em: 28 de junho de 2019.
_____. Magento na AWS: Quick Start. [S.l.], 2017. Disponível em:
<https://aws.amazon.com/pt/quickstart/architecture/magento/>. Acessado em: 8 de junho de
2019.
_____. Regiões e zonas de disponibilidade. [S.l.], 2019d. Disponível em:
<https://docs.aws.amazon.com/pt_br/AWSEC2/latest/UserGuide/using-regions-availability-
zones.html>. Acessado em: 28 de junho de 2019.
_____. Troubleshooting General Issues. [S.l.], 2019f. Disponível em:
<https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html>. Acessado
em: 28 de junho de 2019.
_____. What is Amazon VPC? - Amazon Virtual Private Cloud. [S.l.], 2019l. Disponível
em: <https://docs.amazonaws.cn/en_us/vpc/latest/userguide/what-is-amazon-vpc.html>.
Acessado em: 9 de junho de 2019.
56
_____. What Is IAM? [S.l.], 2019e. Disponível em:
<https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html>. Acessado em: 28
de junho de 2019.
_____. Working with Amazon S3 Buckets. [S.l.], 2019g.
Disponível em: <https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html>.
Acessado em: 28 de junho de 2019.
_____. IAM Roles - AWS Identity and Access Management. [S.l.], 2019m. Disponível em:
<https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html>. Acessado em: 30 de
junho de 2019.
_____. Minimizing Downtime: Multi-AZ with Automatic Failover - Amazon ElastiCache
for Redis. [S.l.], 2019n. Disponível em:
<https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/AutoFailover.html>.
Acessado em: 17 de junho de 2019.
_____. Amazon Aurora Connection Management - Amazon Aurora. [S.l.], 2019o.
Disponível em:
<https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endp
oints.html>. Acessado em: 17 de junho de 2019.
_____. Benefits of Auto Scaling - Amazon EC2 Auto Scaling. [S.l.], 2019p. Disponível em:
<https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html>.
Acessado em: 17 de junho de 2019.
_____. Amazon Elastic File System (EFS) | Cloud File Storage | Recursos do produto.
[S.l.], 2019q. Disponível em: <https://aws.amazon.com/pt/efs/features/>. Acessado em: 17 de
junho de 2019.
ANSIBLE. All modules. [S.l.], 2019e. Disponível em:
<https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.htmll>. Acesso em: 30
de junho de 2019.
_____. Complete IT automation. [S.l.], 2019a. Disponível em:
<https://www.ansible.com/use-cases> Acesso em: 30 de junho de 2019.
_____. Introduction. [S.l.], 2019d. Disponível em:
<https://docs.ansible.com/ansible/latest/user_guide/modules_intro.html>. Acesso em: 30 de
junho de 2019.
_____. Intro to Playbooks. [S.l.], 2019c. Disponível em:
<https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html>. Acesso em: 30 de
junho de 2019.
_____. Use Case: Configuration Management. [S.l.], 2019b. Disponível em:
<https://www.ansible.com/use-cases/configuration-management>. Acesso em: 30 de junho de
2019.
ARTAC, Matej et al. DevOps: Introducing Infrastructure-as-Code. 2017 Ieee/acm 39th
International Conference On Software Engineering Companion (icse-c), [s.l.], p.497-498,
maio 2017.
AYYOUB, Joe. Supporting Magento 1 through June 2020. [S.l.], 2018. Disponível em:
<https://magento.com/blog/magento-news/supporting-magento-1-through-june-2020>.
Acesso em: 26 de junho de 2019.
57
BERNSTEIN, David. Containers and Cloud: From LXC to Docker to Kubernetes. IEEE
Cloud Computing, [s.l.], v. 1, n. 3, p.81-84, set. 2014. Institute of Electrical and Electronics
Engineers (IEEE).
BOLLINGER, Isaiah. Magento Commerce Vs Commerce Cloud Vs Open Source. [S.l.],
2018. Disponível em: <https://trellis.co/blog/magento-commerce-vs-commerce-cloud-vs-
open-source/>. Acessado em: 27 de junho de 2019.
ESTEVÃO, Dário. Why choose Ansible over other configuration management tools?.
[S.l.], 2017. Disponível em: <https://medium.com/@darioems/why-ansible-and-not-others-
configuration-manage-tools-909179b5d2b>. Acesso em: 30 de junho de 2019.
GEERLING, Jeff. Ansible for DevOps: Server and configuration management for humans. 2.
ed. Midwestern Mac, 2016, 450 p.
GOOGLE CLOUD. Architecture: Magento deployment. Disponível em:
<https://cloud.google.com/solutions/architecture/magento-deployment>. Acesso em: 17 de
junho de 2019.
HASHICORP. About Us. Disponível em: <https://www.hashicorp.com/about>. Acesso em:
30 de junho de 2019.
_____. HCL is the HashiCorp configuration language. [S.l.], 2019. Disponível em:
<https://github.com/hashicorp/hcl>. Acesso em: 30 de junho de 2019.
HWANG, Kai; SHI, Yue; BAI, Xiaoying. Scale-out vs. scale-up techniques for cloud
performance and productivity. In: 2014 IEEE 6th International Conference on Cloud
Computing Technology and Science. IEEE, 2014. p. 763-768.
INTERNET ENGINEERING TASK FORCE. Request for Comments: 7231. [Sl.l], 2014.
Disponível em: <https://tools.ietf.org/html/rfc7231>. Acesso em: 03 de julho de 2019.
KHATTAK, Fayyaz. Magento Versions – Years Of Ecommerce Excellence. [S.l.], 2019.
Disponível em: <https://www.cloudways.com/blog/magento-versions/>. Acesso em: 26 de
junho de 2019.
LOCUST. What is Locust?. [S.l.], 2019. Disponível em:
<https://docs.locust.io/en/stable/what-is-locust.html>. Acesso em: 19 de junho de 2019.
MAGENTO. 2.3.x Release Information. [S.l.], 2019a. Disponível em:
<https://devdocs.magento.com/guides/v2.3/release-notes/bk-release-notes.html>. Acesso em:
26 de junho de 2019.
_____. Magento 2.3 technology stack requirements. [S.l.], 2019c. Disponível em:
<https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html>.
Acesso em: 27 de junho de 2019.
_____. Configure and use Varnish. [S.l.], 2019d. Disponível em:
<https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish.html>.
Acesso em: 27 de junho de 2019.
_____. Install and configure Elasticsearch. [S.l.], 2019e. Disponível em:
<https://devdocs.magento.com/guides/v2.3/config-guide/elasticsearch/es-overview.html>.
Acesso em: 27 de junho de 2019.
_____. Magento Open Source 2.3.2 Release Notes. [S.l.], 2019b. Disponível em:
<https://devdocs.magento.com/guides/v2.3/release-
notes/ReleaseNotes2.3.2OpenSource.html>. Acesso em: 26 de junho de 2019.
58
_____. RabbitMQ. [S.l.], 2019f. Disponível em:
<https://devdocs.magento.com/guides/v2.3/install-gde/prereq/install-rabbitmq.html>. Acesso
em: 27 de junho de 2019.
_____. Split database performance solution (Magento Commerce only). [S.l.], 2019g.
Disponível em: <https://devdocs.magento.com/guides/v2.3/config-guide/multi-master/multi-
master.html>. Acesso em: 27 de junho de 2019.
_____. Magento Commerce Cloud guide. [S.l.], 2019h. Disponível em:
<https://devdocs.magento.com/guides/v2.3/cloud/bk-cloud.html>. Acesso em: 27 de junho de
2019.
_____. Magento 2 Sample Data. [S.l.], 2015. Disponível em:
<https://github.com/magento/magento2-sample-data>. Acesso em: 13 de julho de 2019.
MALAVAL, Nicolas. How to Record SSH Sessions Established Through a Bastion Host.
[S.l.], 2016. Disponível em: <https://aws.amazon.com/blogs/security/how-to-record-ssh-
sessions-established-through-a-bastion-host/>. Acesso em: 30 de junho de 2019.
MICROSOFT. Solucionar problemas de esgotamento de porta. [S.l.], 2019. Disponível
em: <https://docs.microsoft.com/pt-br/windows/client-management/troubleshoot-tcpip-port-
exhaust>. Acesso em: 28 de junho de 2019.
MCCOMBS, Adam; BANH, Robert. The Definitive Guide to Magento. Springer, 2010.
MELL, Peter; GRANCE, Timothy. The NIST Definition of Cloud
Computing: Recommendations of the National Institute of Standards and Technology.
Gaithersburg: National Institute Of Standards And Technology, 2011.
MORRIS, Kief. Infrastructure as code: managing servers in the cloud. Sebastopol: O'reilly
Media, Inc., 2016.
NIELSEN. E-commerce fatura R$53,2 bilhões em 2018, alta de 12%. [S.l], 2019.
Disponível em: <https://www.nielsen.com/br/pt/insights/article/2019/e-commerce-fatura-53-
bilhoes-em-2018-alta-de-12-por-cento/>. Acesso em: 05 de junho de 2019.
PERILLI, Alessandro. Why Red Hat Acquired Ansible. [S.l.], 2015. Disponível em:
<https://www.redhat.com/en/blog/why-red-hat-acquired-ansible>. Acesso em: 30 de junho de
2019.
RAZA, Ali. Puppet vs. Chef vs. Ansible vs. SaltStack. [S.l.], 2016. Disponível em:
<https://www.intigua.com/blog/puppet-vs.-chef-vs.-ansible-vs.-saltstack>. Acesso em: 30 de
junho de 2019.
REDIS. Redis. [S.l.], 2019. Disponível em: <https://redis.io/>. Acessado em: 27 de junho de
2019.
SHAHID, Sajjad. Top Ecommerce Platforms Market Share in 2018. [S.l.], 2018.
Disponível em: <https://www.cloudways.com/blog/top-ecommerce-platforms/>
SCHEUNER, Joel et al. Cloud Work Bench - Infrastructure-as-Code Based Cloud
Benchmarking. 2014 Ieee 6th International Conference On Cloud Computing Technology
And Science, [s.l.], p.246-253, dez. 2014.
SHARMA, Tushar; FRAGKOULIS, Marios; SPINELLIS, Diomidis. Does your configuration
code smell? 2016 Ieee/acm 13th Working Conference On Mining Software Repositories
(msr). Austin, p. 189-200. 15 maio 2016.
59
SUN, Chunling. Research of E-Commerce Based on Cloud Computing. Advances In
Intelligent And Soft Computing, [s.l.], p.15-20, 2012. Springer Berlin Heidelberg.
TERRAFORM. Backends. [S.l.], 2019d. Disponível em:
<https://www.terraform.io/docs/backends/>. Acesso em: 30 de junho de 2019.
_____. Backend Types. [S.l.], 2019e. Disponível em:
<https://www.terraform.io/docs/backends/types/index.html>. Acesso em: 30 de junho de
2019.
_____. Creating Modules. [S.l.], 2019g. Disponível em:
<https://www.terraform.io/docs/modules/index.html>. Acesso em: 30 de junho de 2019.
_____. Providers. [S.l.], 2019b. Disponível em:
<https://www.terraform.io/docs/providers/index.html>. Acesso em: 30 de junho de 2019.
_____. State. [S.l.], 2019c. Disponível em: <https://www.terraform.io/docs/state/>. Acesso
em: 30 de junho de 2019.
_____. State Storage and Locking. [S.l.], 2019f. Disponível em:
<https://www.terraform.io/docs/backends/state.html>. Acesso em: 30 de junho de 2019.
_____. Write, Plan, and Create Infrastructure as Code. [S.l.], 2019a. Disponível em:
<https://www.terraform.io/>. Acesso em: 25 de junho de 2019.
TURNBULL, James. The Terraform Book. 150. ed. Nova Iorque: Turnbull Press, 2019.
272p.
