F5 e AWS: Serviços avançados de entrega de aplicativos na nuvem

A Amazon Web Services (AWS) se tornou a maior e mais importante provedora de infraestrutura como serviço (IaaS) de nuvem pública. As organizações agora podem criar, testar e implantar pilhas inteiras de aplicativos sem comprar ou reconfigurar a infraestrutura local. Os aplicativos de produção podem se beneficiar de serviços avançados de entrega de aplicativos, como firewall de aplicativo da Web (WAF), aceleração de SSL, roteamento baseado em conteúdo, balanceamento de carga, mitigação de DDoS, gerenciamento de identidade e acesso e agilidade de protocolo, o que torna esses aplicativos essenciais mais rápidos, inteligentes e seguros. Para implantações da AWS nativas na nuvem, as soluções da F5 permitem a entrega simples e fácil desses serviços de aplicativos para ambientes de nuvem da AWS.

Como provedora de IaaS, a Amazon Web Services (AWS) oferece uma infraestrutura de computação alugada suficiente para desenvolver aplicativos. Sem gastar dinheiro em despesas de capital ou manutenção, um conjunto completo de aplicativos pode ser desenvolvido e implantado. Além de fornecer infraestrutura de computação como aquelas encontradas no local, a AWS fornece serviços de aplicativos, dimensiona automaticamente a infraestrutura e hospeda aplicativos em muitos locais. Devido a esses recursos adicionais, as práticas recomendadas para a AWS são diferentes das práticas recomendadas para um data center comum. Para entender melhor as diferenças entre a AWS e um data center tradicional, é importante entender como a AWS fornece seus serviços.

Para obter o máximo de benefícios da AWS, vamos analisar vários atributos importantes de sua oferta de IaaS, como distribuição geográfica, instâncias de computação, rede e conceitos de armazenamento.

Entender a AWS começa com uma descrição física de como os recursos são distribuídos. No nível mais alto, a AWS tem diversas regiões, cada uma das quais cobre uma grande área geográfica, como a parte leste dos EUA. Cada região geográfica contém diversas zonas de disponibilidade, que são assim chamadas porque são projetadas para serem isoladas de falhas entre si. Uma falha em uma zona de disponibilidade (AZ) não será repercutida em outra AZ dentro de uma região. Embora cada AZ seja isolada, as AZs dentro de uma região são conectadas por meio de links de rede de baixa latência. Para fins de disponibilidade, existem padrões de design para capacidade redundante em várias AZs dentro de uma região.

As instâncias de computação começam como uma imagem de disco de software, conhecida como Amazon Machine Image (AMI). Cada AMI é imutável, o que significa que ela é somente leitura pelo computador que a utiliza. Inicializar uma instância de computação em uma AMI cria uma máquina virtual em execução na nuvem. As características de hardware virtual da instância de computação podem variar, como o número de CPUs e RAM disponíveis para a instância.

Cada instância de computação existe dentro de uma Nuvem Privada Virtual (VPC), que equivale aproximadamente a uma LAN no mundo físico. Cada VPC é logicamente separada. Uma VPC pode consistir em várias sub-redes com roteamento implícito entre sub-redes. Sub-redes públicas são roteáveis pela Internet, enquanto sub-redes privadas estão disponíveis apenas internamente. Para implantar um aplicativo completo, uma ou mais instâncias de computação são implantadas dentro de uma VPC. A comunicação entre VPCs pode ocorrer quando uma instância de computação ou balanceador de carga tem uma entrada DNS atribuída.

Conforme observado acima, cada AMI é imutável em relação à instância que a utiliza. Para armazenamento persistente, a AWS oferece muitas soluções, principalmente Simple Storage Service (S3) e Elastic Block Storage (EBS). O S3 é um serviço de armazenamento de objetos onde um objeto pode ser armazenado e acessado por nome. O tamanho do objeto pode variar de zero bytes a 5 TB. Na verdade, cada AMI é implicitamente um objeto S3. Os objetos não podem ser modificados, apenas criados e excluídos, o que os torna ideais para conteúdo relativamente estático, como fotografias ou imagens de máquinas virtuais.

O EBS fornece armazenamento mais semelhante ao armazenamento tradicional. Uma instância de computação anexada ao EBS vê o EBS como um disco rígido tradicional. Somente uma instância em execução por vez pode ser anexada a um volume EBS, portanto, o EBS não pode ser usado para armazenamento compartilhado.

Além de fornecer componentes de infraestrutura essenciais, a AWS fornece serviços adicionais que permitem o dimensionamento de aplicativos. Como a AWS pode provisionar recursos de infraestrutura rapidamente, a Amazon desenvolveu soluções que permitem o dimensionamento automático e o balanceamento de carga desses recursos.

A AWS fornece um serviço de balanceamento de carga elástico (ELB). Inicialmente, ELB se referia a um balanceador de carga simples operando na camada 4 que distribuía o tráfego entre vários nós saudáveis em um pool. O pool pode abranger diversas zonas de disponibilidade, criando redundância automática em caso de falha em uma zona de disponibilidade. Embora esse balanceador de carga forneça alguns recursos básicos da camada 7 da rede, ele opera principalmente na camada 4, simplesmente roteando o tráfego TCP em rodízio para os nós no pool. As verificações de integridade determinam quais nós estão disponíveis e, portanto, são candidatos ao tráfego. A AWS agora se refere a esse balanceador de carga inicial como Balanceador de Carga Clássico para diferenciá-lo do novo Balanceador de Carga de Aplicativo (ALB).

Como a AWS tem capacidade de espera disponível, ela pode fornecer a opção de dimensionar nós dentro de um pool. O serviço AWS CloudWatch monitora as métricas de desempenho de cada nó dentro de um pool. Quando limites predefinidos — como utilização de CPU superior a 60% por 5 minutos — são ultrapassados, outro nó é provisionado. Inversamente, quando um limite inferior é ultrapassado, um nó é removido. O designer pode determinar o número máximo e mínimo de nós em um pool e os limites que acionam a instanciação ou remoção de nós. Usar o dimensionamento automático por trás de um balanceador de carga permite que o pool de nós se expanda ou contraia conforme necessário com base na carga.

Embora os aplicativos lidem com regras e lógica de negócios, muitas vezes eles não têm o reforço necessário para implantação, gerenciamento e operação de produção em escala. As soluções F5 permitem que os aplicativos sejam mais rápidos, inteligentes e seguros, fornecendo os serviços avançados de entrega de aplicativos detalhados na tabela abaixo.

Serviços avançados de entrega de aplicativos F5

Monitoramento em nível de aplicativo

• Verificações avançadas de integridade do aplicativo (usando um monitor de várias etapas)
• Verificações de integridade em vários níveis (como verificar se o banco de dados e o aplicativo estão disponíveis)
• Verificações de integridade não HTTP (como SIP, Microsoft Windows SQL Server e FTP)
• Algoritmos avançados para melhor distribuir o tráfego para os servidores que funcionam melhor

Disponibilidade global

• Disponibilidade de aplicativos em uma mistura heterogênea de diferentes provedores de nuvem ou data centers
• Integração com monitores avançados BIG-IP
• Suporte DNSSec

Os serviços avançados de entrega de aplicativos permitem que os aplicativos tenham um desempenho de alto nível, ao mesmo tempo em que estão disponíveis e são mais seguros. Esses serviços podem existir em um ponto estratégico de controle independente de cada aplicativo. Desvincular os serviços da lógica de negócios do aplicativo permite que os aplicativos atendam às necessidades de negócios sem sobrecarregar as equipes de desenvolvimento com preocupações de infraestrutura, gerenciamento e desempenho. Um ponto de controle estratégico também permite que questões de governança sejam tratadas de maneira uniforme e independente de cada aplicação.

Ao fornecer integração nativa da nuvem com a infraestrutura da AWS, a F5 permite que as organizações aproveitem ao máximo suas implantações da AWS, capacitando seus aplicativos com melhor desempenho, maior disponibilidade e segurança mais forte. Na seção a seguir, examinaremos como a AWS e a F5 trabalham juntas.

Quando uma instância de servidor é inicializada a partir de uma imagem genérica, geralmente faz sentido alterar parâmetros ou definir configurações, como o nome do host e o endereço IP. Em máquinas clientes, esses parâmetros são definidos via DHCP, mas definir parâmetros do servidor via DHCP pode frequentemente causar problemas. Além das configurações de rede, às vezes uma instância específica requer pacotes de software específicos ou certas configurações de software.

No caso de uma implantação do BIG-IP, um administrador pode querer automatizar a configuração de cada um dos módulos, como as configurações de servidores virtuais e pool para o BIG-IP Local Traffic Manager (LTM), configurações WAF específicas para o BIG-IP Application Security Manager ou talvez configurações de firewall para o BIG-IP Advanced Firewall Manager. Os mesmos problemas são enfrentados por qualquer pessoa que instala uma instância de servidor: a imagem base precisa de configuração adicional para funcionar corretamente.

A AWS oferece duas abordagens principais para configurar uma instância: criar uma nova AMI ou usar o cloud-init para modificar um servidor durante o processo de inicialização. Criar uma nova AMI é mais apropriado para alterações comuns entre várias instâncias que têm menos probabilidade de serem atualizadas com frequência. Em contraste, o cloud-init é mais apropriado para alterações que impactam menos instâncias e têm uma expectativa de vida mais curta.

Para alterações que devem persistir por um período de tempo mais longo — e para alterações comuns a várias instâncias — uma boa abordagem é criar uma nova AMI inicializando uma máquina a partir de uma AMI semelhante à configuração desejada. Depois que o administrador faz as alterações necessárias na instância em execução, a instância é interrompida e uma nova AMI é gerada e registrada na AWS. Todas as instâncias futuras inicializadas a partir desta AMI já terão as alterações aplicadas. Como essa abordagem torna as alterações efetivamente permanentes — e como a geração da nova AMI pode consumir tempo — as alterações incorporadas à AMI são geralmente aquelas que duram muito tempo e podem ser utilizadas em várias instâncias. Outro motivo para usar a AMI é que ela permite tempos de inicialização mais rápidos, já que alguns processos de inicialização na nuvem podem ser demorados.

Alterações necessárias que não são adequadas para incorporação em uma nova AMI são boas candidatas para o cloud-init, que essencialmente habilita um script de inicialização sempre que a instância é inicializada. Usar o cloud-init permite que alterações simples e específicas da instância sejam incorporadas à instância.

As desvantagens do cloud-init incluem que as alterações de configuração, como instalações de pacotes, devem ser executadas no momento da inicialização, fazendo com que a inicialização demore mais. Um longo tempo de inicialização tem impacto real em cenários de dimensionamento automático, onde um tempo de inicialização prolongado pode tornar o dimensionamento automático ineficaz. Por esses motivos, alterações que levam muito tempo devem ser incluídas em uma nova AMI em vez de fazer as alterações via cloud-init.

Gerenciar a configuração também pode ser complicado quando uma alteração pode ser usada em várias instâncias, mas não em todas. Por exemplo, suponha que uma implantação específica do BIG-IP seja usada em um grupo de dimensionamento automático com uma configuração específica de servidor virtual. Uma única AMI poderia servir para essas máquinas e uma AMI diferente poderia servir para outras máquinas BIG-IP em outro grupo de dimensionamento automático. Usar uma única AMI para cada grupo de dimensionamento automático garante que somente alterações específicas para cada host sejam necessárias dentro do processo cloud-init. Quaisquer alterações comuns ao grupo podem ser incorporadas à AMI. A desvantagem dessa abordagem é que ela requer uma atualização da AMI para cada alteração comum a todas as máquinas.

Os aplicativos fornecem uma capacidade, geralmente para vários usuários simultaneamente. À medida que o aplicativo se torna mais bem-sucedido, ele pode exceder a capacidade do computador no qual é executado. Quando as necessidades do aplicativo excedem as do computador, opções para aumentar a capacidade precisam ser avaliadas. Existem três abordagens genéricas para escalonamento: escalonamento vertical, pipeline e escalonamento horizontal.

A expansão vertical é a abordagem mais simples para aumentar a capacidade porque envolve apenas a substituição do computador existente por um mais rápido. Ao instalar um computador mais rápido, todos os aspectos do aplicativo e quaisquer outros serviços no computador se tornam mais rápidos, sem necessidade de alterações no aplicativo ou na infraestrutura. A desvantagem da expansão é que os custos tendem a aumentar exponencialmente com o aumento do desempenho, levando a um ponto de retornos decrescentes. Quando um limite é ultrapassado, a expansão se torna proibitiva em termos de custos.

Pipelining é o resultado da decomposição da carga de trabalho em etapas sequenciais, semelhante a uma linha de montagem. Quando computadores diferentes podem trabalhar independentemente em cada etapa, o rendimento geral pode ser aumentado. No entanto, o pipelining apenas aumenta a produtividade e, muitas vezes, faz isso às custas da latência. Em outras palavras, o pipelining pode aumentar o desempenho geral, mas pode diminuir o desempenho de um único usuário ou de uma única solicitação. A outra desvantagem do pipelining é que ele exige um profundo entendimento do fluxo de trabalho decomponível e que a infraestrutura corresponda a esse entendimento. Ele acopla firmemente as decisões de infraestrutura à lógica de negócios, o que é exatamente o oposto do que muitas organizações estão tentando fazer.

A expansão envolve deixar o aplicativo e o computador sozinhos e, em vez disso, escolher distribuir as solicitações uniformemente em um conjunto de servidores. Como os aplicativos geralmente processam várias solicitações independentes simultaneamente, as solicitações podem ser distribuídas com segurança em um pool de servidores de aplicativos idênticos. O escalonamento tem o benefício adicional de redundância, pois uma falha em qualquer membro do pool não causará uma interrupção de todo o aplicativo. A desvantagem do escalonamento horizontal é que ele exige uma orquestração complexa externa ao aplicativo para garantir que as solicitações sejam balanceadas entre os nós do pool.

O dimensionamento automático da AWS usa uma abordagem de expansão horizontal para aumentar a capacidade dos aplicativos que precisam dela. O serviço CloudWatch monitora nós em um pool. Quando os nós ultrapassam limites predefinidos, o CloudWatch inicia automaticamente novos nós ou desliga os nós no pool, conforme apropriado. Com a plataforma BIG-IP, esse processo pode ocorrer de duas maneiras: alterando o número de instâncias do BIG-IP ou alterando o número de nós em um pool por trás de uma única instância do BIG-IP. A diferença entre as duas abordagens é uma função do que é dimensionado: a instância do BIG-IP ou um pool.

No primeiro cenário, um pool BIG-IP fica entre um par de dispositivos ELB. O primeiro dispositivo ELB controla a instanciação e o encerramento de membros do BIG-IP, enquanto o segundo dispositivo ELB é a única entrada em um pool de servidores para cada uma das instâncias do BIG-IP. Essa abordagem faz sentido quando a instância BIG-IP está fornecendo serviços avançados de entrega de aplicativos, como terminação SSL ou atuando como um firewall de aplicativo da web. O primeiro dispositivo ELB executa o balanceamento de carga e também aumenta ou diminui o pool conforme apropriado.

No segundo cenário, o número de membros do pool de back-end aumenta e diminui via CloudWatch, mas a instância do BIG-IP executa o balanceamento de carga. A instância do BIG-IP se comunica com a AWS para descobrir nós que estão sendo adicionados ou removidos do pool. Essa abordagem faz sentido ao usar recursos avançados de balanceamento de carga, como a linguagem de script iRules, ou ao direcionar solicitações com base em URL ou conteúdo. Nesses casos, uma única instância do BIG-IP é suficiente para gerenciar a carga de servidores no pool de back-end.

A instância do BIG-IP deve interagir com a infraestrutura da AWS em pelo menos dois cenários. Primeiro, uma implantação de AWS em várias zonas requer a alteração do endereço IP por trás de um IP elástico da AWS. Em segundo lugar, uma instância BIG-IP precisa de visibilidade dos membros do pool adicionados e removidos pelo serviço AWS CloudWatch, que dimensiona os servidores para cima e para baixo dentro de um pool. Cada interação com a infraestrutura ocorre por meio de chamadas de API e, assim como qualquer outro software que faz chamadas de API, a instância do BIG-IP deve ser autenticada na AWS. Geralmente, há duas abordagens para autenticação na AWS: por meio de credenciais ou funções do IAM.

A abordagem mais simples para autenticação é incluir as credenciais apropriadas com a chamada de API. As credenciais da AWS consistem em uma chave de acesso e uma chave secreta, que correspondem aproximadamente a um nome de usuário e uma senha. O administrador gera as credenciais, que o desenvolvedor então incorpora no aplicativo. Isso dá ao aplicativo acesso às chamadas de API apropriadas.

Embora simples, incorporar credenciais em um aplicativo traz riscos de segurança. A menos que o desenvolvedor proteja as credenciais no aplicativo, outras pessoas ou softwares poderão recuperá-las e usá-las de maneiras maliciosas. Essa abordagem também dificulta a alteração das credenciais sem alterar também o software. Embora o uso de credenciais seja uma abordagem razoável para testes rápidos, uma solução de produção deve usar outra abordagem para autenticação. É por isso que as práticas recomendadas da AWS recomendam não usar credenciais armazenadas em um aplicativo.

Uma abordagem mais segura para autenticação de chamadas de API é o uso de funções do IAM. O AWS Identity and Access Management (IAM) permite que os usuários gerenciem o acesso à infraestrutura da AWS. Qualquer instância de computação, como uma máquina BIG-IP, pode receber uma função do IAM que autoriza um conjunto específico de recursos. Quando a instância é iniciada, o IAM gera um conjunto temporário de credenciais para a instância. Essas credenciais duram enquanto a instância estiver funcionando e habilitam apenas os recursos de API especificados. Quando configurada com uma função do IAM, a instância do BIG-IP não armazena credenciais, mas tem acesso apenas às APIs de infraestrutura necessárias, fornecendo mais segurança do que a autenticação baseada em credenciais.

Conforme mencionado anteriormente, os data centers da AWS existem em regiões geográficas, cada uma das quais pode existir em uma zona de disponibilidade (AZ). Cada AZ dentro de uma região não compartilha nada com outras AZs: não há energia, rede ou edifícios compartilhados. Na verdade, cada AZ é geograficamente separada das outras dentro de uma região. Devido à separação entre zonas, os assinantes da AWS podem ter certeza de que um evento que afeta uma AZ não afetará outra AZ. Em outras palavras, como regra, no máximo uma AZ dentro de uma região deve estar indisponível a qualquer momento. Isso significa que qualquer serviço implantado em duas ou mais zonas de disponibilidade deve estar continuamente disponível.

A plataforma BIG-IP oferece suporte à alta disponibilidade em todas as AZs da AWS usando um IP elástico da AWS, que é um endereço IP não intrinsecamente associado a uma instância de computação. Em vez disso, o endereço IP pode ser encaminhado dinamicamente para um endereço IP privado de uma instância de computação em execução. Para permitir alta disponibilidade em várias zonas, conjuntos idênticos de instâncias BIG-IP e servidores de aplicativos são colocados em sua própria AZ. Inicialmente, o IP elástico é atribuído a uma das instâncias do BIG-IP. As conexões são estabelecidas de cada cliente para o IP elástico que, por sua vez, as encaminha para o endereço IP privado em uma das instâncias do BIG-IP. Caso ocorra uma falha, a outra instância do BIG-IP assumirá as responsabilidades fazendo uma chamada de API para a AWS, solicitando que o endereço IP elástico seja encaminhado a ela.

Ao integrar-se ao ELB, a plataforma BIG-IP pode fornecer serviços de aplicativos que se integram perfeitamente aos recursos da AWS, como várias AZs e nós BIG-IP de dimensionamento automático.

Colocar o ELB na frente de uma instância do BIG-IP simplifica a implantação em várias AZs, porque o ELB pode balancear perfeitamente o tráfego para as pilhas de aplicativos individuais dentro de cada AZ onde uma instância do BIG-IP está fornecendo serviços de aplicativo. Essa abordagem simplifica o balanceamento de carga entre várias AZs.

Quando a elasticidade das instâncias BIG-IP é necessária, um ELB com dimensionamento automático pode dimensionar automaticamente para cima e para baixo um pool de dispositivos virtuais BIG-IP, fornecendo serviços de aplicativos como firewall de aplicativo da Web, gerenciamento de identidade ou terminação SSL. Usando um sanduíche ELB, o tráfego é roteado para o primeiro ELB, que equilibra e dimensiona automaticamente o tráfego para um pool de instâncias BIG-IP. Para simplificar a configuração no pool do BIG-IP, cada instância do BIG-IP tem um único endereço ELB no pool de servidores. O segundo ELB então roteia o tráfego para o pool de servidores downstream.

Várias combinações de topologias ELB e BIG-IP fornecem dimensionamento automático, disponibilidade e serviços de aplicativos que não estão disponíveis para nenhum deles sozinho. Ao explorar as vantagens do ELB e da plataforma BIG-IP, o arquiteto pode fornecer o nível de serviços necessário para uma implantação específica.

Para permitir implantações repetíveis e com script, a AWS fornece Cloud Formation Templates (CFTs), que simplificam tanto a implantação quanto o gerenciamento contínuo. Após a criação de um CFT para a arquitetura de serviço ou aplicativo desejada, a AWS pode usá-lo para provisionar um aplicativo de forma rápida e confiável. Os CFTs são particularmente úteis em ambientes DevOps, permitindo que as equipes criem facilmente processos repetíveis para testes e implantação de produção.

O F5 não apenas oferece suporte ao uso de CFTs para implantar instâncias do BIG-IP, mas também fornece vários arquivos CFT de referência para implantações típicas do BIG-IP .

Ajustar os parâmetros nos arquivos CFT de referência permite implantações com script de soluções BIG-IP para diferentes cenários, incluindo dimensionamento automático de instâncias BIG-IP ou servidores back-end por trás de instâncias BIG-IP, bem como cenários mais complicados. Ao automatizar implantações repetíveis na AWS usando CFTs e soluções F5, ambientes de aplicativos complexos podem ser implantados rapidamente e com pouco trabalho.

É claro que a tecnologia é de pouca utilidade se não puder ser aproveitada ao máximo. Para isso, o F5 fornece ampla documentação. A documentação está disponível para a plataforma BIG-IP em geral e para as especificidades de uma instância BIG-IP na AWS. Um bom ponto de partida para qualquer pergunta está no Ask F5 .

A guia de documentação fornece informações sobre módulos BIG-IP específicos, bem como uma seção inteira sobre integração com a AWS. O portal da AWS fornece uma interface pesquisável para documentação, artigos, comunidade e recursos, desde os primeiros passos até cenários complexos de implantação.

Para as perguntas não respondidas pela documentação, a comunidade F5 DevCentral está pronta para fornecer respostas e assistência.

A marcha em direção à adoção da nuvem pública não é mais uma moda passageira, mas uma tendência duradoura em TI. A Amazon Web Services, como a maior e mais abrangente provedora de serviços de nuvem pública do mundo, oferece às organizações a capacidade de criar, testar e implantar aplicativos sem nenhum equipamento local. A F5 disponibilizou seus serviços avançados de entrega de aplicativos como parte do ecossistema da AWS e os configurou para ajudar os aplicativos a ficarem mais rápidos, inteligentes e seguros em ambientes de nuvem da AWS.