A evolução dos controladores de entrega de aplicações
Introdução
No mundo dinâmico de hoje, as organizações enfrentam constantemente o desafio de disponibilizar aplicações essenciais para milhões de usuários em todo o mundo. É extremamente importante que elas implementem serviços de rede e de aplicações para tornar as aplicações escaláveis, seguras e disponíveis. Esse é um dos principais motivos por trás da evolução dos Controladores de Entrega de Aplicações (ADCs). No entanto, nenhum desses recursos pode ser implementado sem uma base sólida em tecnologia básica de balanceamento de carga. Portanto, vamos começar entendendo a importância do balanceamento de carga, como ele contribui para a entrega eficiente de aplicações e como os ADCs continuam evoluindo e adotando uma abordagem voltada prioritariamente para a nuvem.
Fatores que impulsionam a demanda por balanceamento de carga
O objetivo do balanceamento de carga é distribuir o tráfego de rede ou de aplicações recebido entre vários servidores físicos, fazendo com que, para o mundo externo, eles pareçam um único servidor. Há muitos motivos para fazer isso, mas os principais fatores são a necessidade de "escalabilidade", "alta disponibilidade" e "previsibilidade".
Escalabilidade é a capacidade de se adaptar de forma dinâmica ou fácil ao aumento da carga sem afetar o desempenho existente. A alta disponibilidade (HA), por outro lado, é a capacidade de um site permanecer disponível e acessível mesmo durante a falha de um ou mais sistemas. A virtualização de serviços (que imita o comportamento de componentes de software para acelerar e testar o desenvolvimento de aplicações) oferece uma oportunidade interessante tanto para a escalabilidade quanto para a disponibilidade. Se o serviço ou ponto de contato com o usuário estiver separado dos servidores reais, a aplicação poderá ser dimensionada com a adição de mais servidores. Além disso, a falha de um servidor individual não tornará toda a aplicação indisponível. A previsibilidade é um conceito um pouco menos claro, pois engloba aspectos da alta disponibilidade e algumas lições aprendidas ao longo do caminho. Ela pode ser melhor descrita como o controle sobre como e quando os serviços são fornecidos em termos de disponibilidade e desempenho.
Balanceamento de carga: uma perspectiva histórica
Nos primórdios da Internet comercial, muitos aspirantes a milionários das empresas ponto-com descobriram um sério problema em seus planos. Os mainframes não dispunham de software de servidor web (pelo menos até o AS/400e) e, mesmo que dispusessem, eles não cabiam no orçamento de uma startup. O que eles podiam comprar eram servidores convencionais, prontos para uso, de um dos inúmeros fabricantes de PCs. O principal problema da maioria desses equipamentos era que um único servidor baseado em PC jamais conseguiria lidar com o volume de tráfego que seus negócios gerariam. E, se ele parasse de funcionar, a empresa ficaria fora do ar e sem operar. Felizmente, algumas dessas pessoas planejavam ganhar milhões resolvendo justamente esse problema. Foi assim que surgiu o balanceamento de carga.
No princípio, havia o DNS
Antes que existissem dispositivos de balanceamento de carga desenvolvidos especificamente para essa finalidade e disponíveis comercialmente, houve muitas tentativas de utilizar tecnologias existentes para alcançar os objetivos de escalabilidade e disponibilidade. A tecnologia mais difundida (e ainda utilizada) era o DNS round-robin.
Nesse método, o DNS atribuía vários endereços IP exclusivos a diferentes servidores sob o mesmo nome DNS. Isso significava que, na primeira vez que um usuário solicitava a resolução de “www.example.com,” o servidor DNS encaminhava cada nova conexão ao primeiro servidor da fila até chegar ao último — antes de voltar novamente ao primeiro. Essa solução era simples e permitia distribuir as conexões uniformemente entre um conjunto de máquinas.
Do ponto de vista da escalabilidade, essa solução funcionou muito bem, pois permitia adicionar uma quantidade praticamente ilimitada de servidores a um nome DNS. No entanto, em termos de disponibilidade, a solução criava um obstáculo, já que o DNS não conseguia saber se os servidores listados estavam funcionando ou não. Se um servidor ficasse indisponível e um usuário tentasse acessá-lo, a solicitação poderia ser enviada a um servidor que estivesse fora do ar.
Outro fator determinante para o uso do DNS round-robin era a previsibilidade, ou seja, um alto grau de confiança de que um usuário seria direcionado a um servidor específico. Isso se baseia na ideia de persistência — o conceito de garantir que o balanceamento de carga não direcione o usuário a um novo servidor após o início de uma sessão ou quando ele retomar uma sessão anteriormente suspensa. Essa é uma questão muito importante que o DNS round-robin não conseguia resolver.
Balanceamento de carga proprietário em software
Para resolver esse problema, uma das primeiras soluções desenvolvidas especificamente para essa finalidade foi o balanceamento de carga integrado diretamente ao software da aplicação ou ao sistema operacional (SO) do servidor de aplicações. Embora houvesse tantas implementações diferentes quanto empresas que as desenvolveram, a maioria das soluções se baseava em artifícios básicos de rede. Por exemplo, em uma dessas soluções, todos os servidores de um pool (também conhecido como cluster) tinham, além de seus próprios endereços IP físicos, um endereço IP adicional.
Quando os usuários tentavam se conectar ao serviço, eles se conectavam ao IP do pool, em vez de ao IP físico do servidor. O servidor do pool que respondesse primeiro à solicitação de conexão redirecionava o usuário para um endereço IP físico (o seu próprio ou o de outro sistema do pool), e a sessão do serviço era iniciada. Um dos principais benefícios dessa solução era permitir que os desenvolvedores do aplicativo usassem diversas informações para determinar a qual endereço IP físico o cliente deveria se conectar. Por exemplo, cada servidor do pool poderia manter uma contagem de quantas sessões cada membro do pool já estava atendendo e, então, direcionar as novas solicitações ao servidor com menor utilização.
Inicialmente, a escalabilidade dessa solução era evidente. Bastava criar um novo servidor e adicioná-lo ao pool para aumentar a capacidade da aplicação. Com o tempo, porém, a escalabilidade do balanceamento de carga baseado em aplicações passou a ser questionada. Como os membros do pool precisavam manter contato constante entre si para decidir a qual deles a próxima conexão seria direcionada, o tráfego de rede entre esses membros aumentava exponencialmente a cada novo servidor adicionado ao pool. Quando o pool atingia determinado tamanho (geralmente de 5 a 10 hosts), esse tráfego começava a afetar tanto o tráfego dos usuários finais quanto a utilização dos processadores dos próprios servidores. Portanto, a escalabilidade era excelente, desde que não fosse necessário ultrapassar um número reduzido de servidores (por sinal, menor do que com o DNS round-robin).
A alta disponibilidade (HA) aumentou drasticamente com o DNS round-robin e o balanceamento de carga por software. Como os membros do pool mantinham comunicação constante entre si e os desenvolvedores podiam usar seu amplo conhecimento da aplicação para determinar quando um servidor estava funcionando corretamente, essas soluções praticamente eliminaram a possibilidade de os usuários chegarem a um servidor incapaz de atender às suas solicitações. No entanto, é importante destacar que cada nova implementação de recursos inteligentes de HA causava um impacto correspondente na utilização dos servidores e da rede, limitando ainda mais a escalabilidade. O outro impacto negativo sobre a HA estava relacionado à confiabilidade. Muitos dos artifícios de rede usados para distribuir o tráfego nesses sistemas eram complexos e exigiam um monitoramento considerável no nível da rede. Consequentemente, esses métodos de distribuição frequentemente apresentavam problemas que afetavam toda a aplicação e todo o tráfego na rede da aplicação.
Essas soluções também aumentaram a previsibilidade. Como os projetistas da aplicação sabiam quando e por que os usuários precisavam ser direcionados de volta ao mesmo servidor, em vez de terem suas solicitações distribuídas entre os servidores, eles puderam incorporar uma lógica que ajudava a garantir a persistência dos usuários quando necessário. Eles também usaram a mesma tecnologia de "pooling" para replicar as informações de estado dos usuários entre os servidores, eliminando muitas das situações que, a princípio, exigiam persistência. Por fim, graças ao profundo conhecimento que tinham da aplicação, eles conseguiram desenvolver algoritmos de balanceamento de carga baseados na integridade real da aplicação, em vez de fatores como o número de conexões, que nem sempre indicavam adequadamente a carga do servidor.
Além das possíveis limitações quanto à escalabilidade real e dos problemas de confiabilidade, o balanceamento de carga proprietário baseado em aplicações também apresentava outra desvantagem: dependia do fornecedor da aplicação para ser desenvolvido e mantido. O principal problema era que nem todas as aplicações ofereciam tecnologia de balanceamento de carga (ou pooling), e as que ofereciam muitas vezes não funcionavam com as soluções fornecidas por outros fornecedores de aplicações. Embora várias organizações produzissem software de balanceamento de carga no nível do sistema operacional e independente de fornecedor, infelizmente essas soluções enfrentavam os mesmos problemas de escalabilidade. Além disso, sem uma integração estreita com as aplicações, essas "soluções" de software também enfrentavam desafios adicionais de alta disponibilidade.
Hardware de balanceamento de carga baseado em rede
A segunda geração de soluções desenvolvidas especificamente para balanceamento de carga surgiu na forma de appliances baseados em rede. Eles são os verdadeiros precursores dos atuais Controladores de Entrega de Aplicações. Esses appliances ficavam fisicamente fora das próprias aplicações e, embora tenham surgido como balanceadores de carga, realizavam o balanceamento usando técnicas de rede muito mais simples, como NAT. Esses dispositivos apresentavam ao mundo externo um endereço de servidor virtual e, quando os usuários tentavam se conectar, encaminhavam a conexão para o servidor real mais adequado.
O balanceador de carga podia controlar exatamente qual servidor recebia cada conexão e utilizava "monitores de integridade" cada vez mais complexos para garantir que o servidor de aplicações (um servidor físico real) respondesse conforme o esperado. Se o servidor não respondesse corretamente, o balanceador de carga interromperia automaticamente o envio de tráfego para ele até que apresentasse a resposta desejada. Embora os monitores de integridade raramente fossem tão abrangentes quanto os desenvolvidos pelos próprios desenvolvedores da aplicação, a abordagem baseada em hardware de rede podia fornecer serviços básicos de balanceamento de carga para praticamente qualquer aplicação de maneira uniforme e consistente, criando finalmente um ponto de entrada de serviço verdadeiramente virtualizado e exclusivo para os servidores de aplicações.
Do ponto de vista da escalabilidade, as organizações que começaram a substituir o balanceamento de carga baseado em software por uma solução baseada em hardware observaram uma redução drástica na utilização de seus servidores. Isso evitou a necessidade de adquirir servidores adicionais no curto prazo e ajudou a aumentar o retorno sobre o investimento (ROI) no longo prazo.
Da mesma forma, a alta disponibilidade (HA) ajudou a reduzir a complexidade da solução e a oferecer balanceamento de carga independente da aplicação, resultando em maior confiabilidade e em uma solução mais abrangente. O hardware de balanceamento de carga baseado em rede permitiu ao proprietário da empresa oferecer um alto nível de disponibilidade a todas as suas aplicações, em vez de apenas às poucas que contavam com balanceamento de carga integrado.
A previsibilidade foi um componente essencial proporcionado pelo hardware de balanceamento de carga baseado em rede. Com ele, ficou muito mais fácil prever para onde uma nova conexão seria direcionada e manipulá-la. Esses dispositivos agregaram inteligência ao processo, o que, por sua vez, ajudou a criar uma distribuição controlada da carga (em oposição à distribuição não controlada do DNS dinâmico). Isso permitiu que os proprietários das empresas distribuíssem a carga entre os servidores de acordo com a capacidade de cada servidor de processá-la.
O surgimento do balanceador de carga baseado em rede e da virtualização trouxe novos benefícios para a segurança e o gerenciamento, como ocultar da comunidade da Internet a identidade dos servidores de aplicações e permitir o escoamento das conexões de um servidor para que ele pudesse ser colocado offline para manutenção sem afetar os usuários. Essa foi a base que deu origem aos ADCs.
Controladores de entrega de aplicações
Com uma função central de balanceamento de carga, que também atua como proxy completo, a TI identificou uma excelente oportunidade para adicionar e consolidar serviços novos e emergentes. Isso fez com que um dispositivo de balanceamento de carga evoluísse para uma plataforma ADC extensível. Em termos simples, o proxy é a base do balanceamento de carga e a tecnologia subjacente que viabiliza os ADCs.
Ao abordar a segurança de ADCs, a virtualização criada pelo proxy (a tecnologia de base) é fundamental. Seja ao tratar do descarregamento da criptografia SSL/TLS, da autenticação centralizada ou até mesmo de firewalls com reconhecimento de aplicações, o poder dessas soluções reside no fato de que um balanceador de carga (em hardware ou em edição virtual) é o ponto central de virtualização de todas as aplicações. A autenticação centralizada é um exemplo clássico. Tradicionalmente, os mecanismos de autenticação e autorização sempre foram incorporados diretamente à própria aplicação. Assim como no balanceamento de carga baseado em aplicações, cada implementação dependia da forma como cada aplicação era implementada e era exclusiva a ela, resultando em métodos numerosos e distintos. Em vez disso, ao aplicar a autenticação no ponto de entrada virtualizado de todas as aplicações, é possível adotar um método de autenticação único e uniforme. Isso não apenas simplifica drasticamente o projeto e o gerenciamento do sistema de autenticação, como também melhora o desempenho dos próprios servidores de aplicações, eliminando a necessidade de executarem essa função. Além disso, elimina a necessidade — especialmente em aplicações desenvolvidas internamente — de investir tempo e dinheiro no desenvolvimento de processos de autenticação para cada aplicação separadamente.
A disponibilidade é o atributo de um ADC mais fácil de associar ao balanceador de carga original, pois está relacionada a todos os atributos básicos de um balanceador de carga: escalabilidade, alta disponibilidade e previsibilidade. No entanto, os ADCs vão ainda mais longe do que os balanceadores de carga. Para os ADCs, a disponibilidade também abrange conceitos avançados, como dependência entre aplicações e provisionamento dinâmico. Os ADCs são capazes de compreender que, atualmente, as aplicações raramente operam de forma autônoma: muitas vezes, elas dependem de outras aplicações para cumprir sua finalidade. Esse conhecimento aumenta a capacidade do ADC de garantir a disponibilidade das aplicações, levando também esses outros processos em consideração. Os ADCs mais inteligentes do mercado também oferecem interfaces programáticas que lhes permitem alterar dinamicamente a forma como prestam serviços com base em entradas externas. Essas interfaces viabilizam o provisionamento dinâmico e o aumento ou a redução automatizados de escala necessários para ambientes modernos, como implantações em nuvem e em contêineres.
O aprimoramento do desempenho foi outra evolução natural do conceito de balanceamento de carga. Os balanceadores de carga melhoravam inerentemente o desempenho das aplicações ao garantir que as conexões fossem direcionadas não apenas para os serviços que estavam disponíveis (e respondiam dentro de um prazo aceitável), mas também para aqueles com o menor número de conexões e/ou a menor utilização do processador. Isso garantia que cada nova conexão fosse atendida pelo sistema mais capacitado para processá-la. Posteriormente, quando o descarregamento de SSL/TLS (usando hardware dedicado) se tornou um recurso comum nas soluções de balanceamento de carga, ele reduziu tanto a sobrecarga computacional do tráfego criptografado quanto a carga nos servidores de back-end, melhorando também o desempenho deles.
Os ADCs atuais vão ainda mais longe. Esses dispositivos geralmente incluem tecnologias de cache, compactação e até controle de taxa para aumentar ainda mais o desempenho geral e a entrega de aplicações. Além disso, em vez de serem implementações estáticas de appliances autônomos tradicionais que fornecem esses serviços, um ADC pode usar sua inteligência de aplicações integrada para aplicá-los somente quando proporcionarem ganhos de desempenho, otimizando assim seu uso.
Por exemplo, apesar da crença comum, a tecnologia de compactação não é necessariamente benéfica para todos os usuários da aplicação. Sem dúvida, usuários com pouca largura de banda podem se beneficiar enormemente de pacotes menores, pois o gargalo é a taxa de transferência efetiva. Até mesmo conexões que precisam percorrer longas distâncias podem se beneficiar, já que pacotes menores exigem menos viagens de ida e volta para transportar os dados, reduzindo o impacto da latência da rede. No entanto, conexões de curta distância (por exemplo, dentro do mesmo continente) com grande largura de banda podem apresentar um desempenho pior quando a compactação é aplicada. Como a taxa de transferência não é necessariamente o gargalo, a sobrecarga adicional da compactação e da descompactação aumenta a latência, e o ganho de taxa de transferência não compensa esse impacto no desempenho. Em outras palavras, se não for gerenciada adequadamente, a tecnologia de compactação como solução pode ser pior do que o problema original. Porém, ao aplicar a compactação de forma inteligente somente quando ela beneficiar o desempenho geral, um ADC otimiza o uso e o custo dessa tecnologia, deixando mais ciclos de processamento disponíveis para as funções que melhor os aproveitarão.
Para onde o mundo está caminhando
Como a transformação digital é um imperativo estratégico tão importante, muitas empresas começaram sua jornada rumo à nuvem. Com o número crescente de aplicações que surgem e transformam o mundo ao nosso redor, acredita-se que as organizações que migrarem para a nuvem terão muitos benefícios, como maior agilidade, custos operacionais mais bem alinhados, escalabilidade sob demanda e mais foco em seu negócio principal.
A “nuvem” não é uma entidade única e amorfa de recursos compartilhados de computação, armazenamento e rede; na verdade, ela é composta por uma combinação complexa de provedores, infraestruturas, tecnologias e ambientes, frequentemente implantados em vários nós ao redor do mundo. É por isso que muitas empresas implantaram aplicações em diversas nuvens — públicas, privadas e até mesmo em uma combinação de todas elas. Essa é a multinuvem: a nova realidade.
Mesmo com esse cenário em rápida evolução, vários fatores estão desacelerando a adoção da nuvem. O primeiro desafio é a proliferação de ambientes multinuvem, em que aplicações existentes foram simplesmente migradas para a nuvem (lift and shift), enquanto aplicações nativas da nuvem foram implantadas de forma não planejada e sem gerenciamento. Além disso, para atender às necessidades de curto prazo, as organizações tendem a usar plataformas de nuvem distintas, arquiteturas diferentes, serviços de aplicações variados e diversos conjuntos de ferramentas. Isso gera complexidade arquitetônica em toda a empresa e torna a migração de aplicações de um ambiente para outro muito mais difícil, além de cara.
Apesar desses desafios, novas implantações em nuvens públicas e privadas, bem como entre elas, inevitavelmente aumentarão nos próximos anos. A multinuvem está se aproximando rapidamente, e chegou a hora de as empresas implantarem serviços inteligentes de aplicações e ADCs que façam mais do que oferecer suporte a aplicações limitadas ou operar apenas em hardware e em uma única nuvem.
Resumo
Os ADCs são a evolução natural do espaço crítico na rede que antes era ocupado pelos balanceadores de carga. Embora devam muito a esses dispositivos do passado, os ADCs representam uma categoria claramente nova, que oferece não apenas disponibilidade, mas também desempenho e segurança. Como o próprio nome sugere, eles abrangem todos os aspectos necessários para disponibilizar uma aplicação da melhor maneira possível.
Com recursos avançados, como inteligência de aplicações, descarregamento de SSL e interfaces programáticas, os ADCs modernos podem ajudar as organizações a expandir seus negócios e alcançar usuários em qualquer lugar e a qualquer momento. Diante das necessidades em constante evolução do mundo da tecnologia, os ADCs também são mais capazes de se adaptar às tecnologias mais recentes em ambientes multinuvem e de contêineres.
Em suma, podemos afirmar com segurança que os ADCs não serão apenas o principal canal e ponto de integração por meio do qual as aplicações serão entregues de forma mais rápida, inteligente e segura, mas também continuarão evoluindo e adotando uma abordagem voltada prioritariamente para a nuvem.
PUBLICADO EM 10 DE SETEMBRO DE 2017