Introdução
LDAP (Lightweight Directory Access Protocol) é uma fonte ubíqua de informações de diretório, codificada pela primeira vez em 1993. É normalmente utilizado para uma vasta gama de aplicações, incluindo a gestão de informações de utilizadores/grupos para instâncias Linux e o controlo da autenticação para VPNs e aplicações legadas.
Tradicionalmente, o servidor LDAP de uma empresa era executado internamente. muitas vezes, ou parte do Active Directory da Microsoft ou uma implementação do projeto open source OpenLDAP. Hoje em dia, o suporte LDAP está disponível junto de fornecedores SaaS, incluindo Foxpass, que foi o primeiro fornecedor de LDAP na cloud a criar, de raiz, uma implementação LDAP multi-tenant e centrada na cloud.
O LDAP normalmente tem as seguintes primitivas: bind, search, compare, e add. Depois de criar uma ligação Transmission Control Protocol (TCP), as aplicações teriam primeiro de se associar enviando um nome de utilizador e uma palavra-passe. Depois de vinculado com sucesso, o cliente emite comandos para o servidor LDAP. Normalmente, este é o comando de pesquisa em conjunto com filtros. A ligação TCP mantém-se até que o cliente ou o servidor se desligue.
LDAP na Foxpass
Na Foxpass, o nosso serviço LDAP é desenvolvido com base em Twisted, uma framework de serviços baseada em eventos popular para Python. O serviço está alojado na plataforma ECS da AWS e é executado em dezenas de contentores (nós). Como as ligações LDAP são persistentes, o cluster tem de conseguir manter centenas de milhares de sessões TCP simultâneas.
Mantemos os dados dos clientes na RAM. A razão para isto é múltipla: primeiro, o conjunto de dados é relativamente pequeno, mesmo para grandes clientes. Em segundo lugar, a linguagem de consulta LDAP permite pesquisar campos arbitrários (o que é importante, uma vez que o Foxpass permite campos personalizados). Isto significa que um sistema RDBMS tradicional não conseguirá criar índices eficazes, e temos de transformar os dados numa representação diferente na memória. Em terceiro lugar, manter os dados na RAM permite o tempo de resposta mais rápido possível: as latências situam-se normalmente em torno dos 100 ms (ver gráfico a).
Uma desvantagem desta abordagem é a invalidação da cache. Quando os dados de um cliente mudam (por exemplo, um utilizador foi adicionado ou eliminado), os nós LDAP têm de atualizar os seus dados a partir do nosso RDBMS principal. Na nossa arquitetura anterior, esta era uma operação relativamente dispendiosa; quando cada nó atualiza os dados da mesma empresa, isso pode causar um aumento visível na latência do LDAP e na carga sobre o armazenamento de suporte.
Desafios de sensibilidade à latência
Como referido acima, devido aos requisitos de latência, cada contentor armazena todos os dados de um cliente na memória (ver figura a). Os dados são obtidos a pedido quando o pedido chega a um nó (caso ainda não estejam presentes) e depois mantêm-se enquanto existir pelo menos uma ligação desse cliente.
Uma vez que um pedido de ligação de entrada pode chegar a qualquer contentor (através do balanceador de carga), o contentor que recebe uma consulta também carrega e armazena todos os dados do cliente. Subsequentemente, o contentor regista-se num serviço de redis pubsub para receber mensagens de invalidação. Quando os dados da empresa são atualizados, é difundido um sinal de invalidação para os nós recetores, que limpam a cache de dados dessa empresa e acedem à base de dados para voltar a obter os dados da empresa.
Isto colocou os seguintes desafios para escalar o nosso serviço LDAP à medida que continuávamos a crescer e a adicionar novos clientes ao nosso sistema:
Todos os dados do cliente (M) em todos os nós (N) exigem um recarregamento em caso de invalidações. Embora, na prática, nem todos os nós alojem uma ligação de todos os clientes, no pior dos casos são feitas MxN chamadas à base de dados para atualizar os dados. À medida que são adicionados mais clientes (M), o número de pesquisas na BD pode aumentar por um fator de N. Isto também significava que, para não sobrecarregar as máquinas da base de dados, eram necessárias instâncias adicionais de leitura da BD para lidar com o pico de pedidos.
Uma vez que todos os dados de todos os clientes (M) são armazenados em memória em muitos nós (N), a memória continua a aumentar em todos os nós proporcionalmente ao número de clientes (M). Isto também significa que os requisitos de memória do contentor têm de aumentar para acomodar todos os dados em memória, o que, por sua vez, aumenta o custo global da infraestrutura.
Os desafios acima eram muito claros e levaram-nos a optar por distribuir os dados dos clientes pelos nós, em vez de replicar todos os dados em cada nó. Isto levou-nos a uma solução distribuída de gestão de cache.
Gestão de cache distribuída
Introduzimos uma camada de encaminhamento inteligente no nosso serviço LDAP que encaminhava os pedidos para os nós que alojavam os dados do cliente, caso o contentor em que a ligação chegasse não alojasse os dados. Para alcançar isto, restringimos os seguintes requisitos de design para a camada de encaminhamento:
Os clientes precisam de ser distribuídos dinamicamente pelos nós à medida que são adicionados.
Os dados dos clientes precisam de ser distribuídos dinamicamente à medida que os nós diminuem, expandem e em caso de falhas dos nós.
A capacidade de aumentar e reduzir o número de partições para um cliente específico, para que o desequilíbrio no tráfego não sobrecarregue nenhum nó individual.
Apresentámos o Apache Helix, que distribui os recursos entre instâncias. O controlador Helix, o cérebro do ecossistema Helix, toma decisões de atribuição de recursos entre nós quando são adicionados ou removidos nós ou clientes. Nós dockerizámos o controlador Apache Helix, o servidor Rest e implementámo-lo no ECS. O controlador Helix depende do Zookeeper para escutar as alterações do cluster. Implementámos uma forma fiável de implementar o Zookeeper no ECS, pelo que agora toda a infraestrutura do Helix e do Zookeeper funciona no ECS.
Cada nó LDAP interage com o Zookeeper para se registar e participar no cluster. Cada instância LDAP surge como um participante Helix que participa no cluster de atribuições de cliente para nó pelo controlador Helix. Quando um novo cliente é criado dinamicamente por um nó LDAP, o número de partições (cada partição representa um nó que aloja os dados) desse cliente é determinado com base no número de utilizadores.
Com esta integração, os nossos nós LDAP ficam cientes dos eventos que ocorrem no cluster (ou seja, quando é adicionado um novo cliente ou quando o conjunto de nós disponíveis muda).
Com esta perceção do cluster, a camada de encaminhamento no nosso serviço LDAP fornece o mapeamento entre os nós e os clientes. Cada ligação recebida passará agora pela camada de encaminhamento para determinar para que nó a ligação tem de ser encaminhada. Com isto, os dados do cliente são atribuídos a nós específicos (ver figura b).
A camada de encaminhamento aloja uma cache que contém as informações de rota dos clientes e dos nós. A camada de encaminhamento identifica quaisquer alterações nas atribuições de cliente para nó e atualiza-as imediatamente quando as alterações são detetadas. Desta forma, cada nó LDAP fica a par das alterações de cliente para nó assim que acontecem.
Com a solução de gestão de cache acima, os desafios de escalabilidade mencionados na secção Desafios de sensibilidade à latência foram resolvidos:
Agora temos clientes distribuídos pelos nós. Cada nó irá alojar apenas um subconjunto de clientes e será responsável por obter apenas um subconjunto dos dados dos clientes ao receber invalidações pubsub. Isto reduz significativamente o número de leituras da DB, eliminando a necessidade de adicionar nós leitores de DB para lidar com um elevado volume de leituras da DB. O cluster LDAP faz agora menos 75% leituras da BD do que antes.
Também melhorámos a eficiência da memória porque não armazenamos todos os dados do cliente (M) na memória em todos os nós (N). Esta arquitetura oferece a capacidade de escalar horizontalmente sem aumentar o tamanho da instância. Cada nó LDAP consome agora menos 40% de memória do que antes.
Desafios atuais
Com a implementação acima, um dos desafios é que os nós recebem um número desigual de ligações TCP. Este desequilíbrio na distribuição provoca uma maior utilização da CPU em alguns nós (nós sobrecarregados) em comparação com outros. Mas a utilização média global da CPU em todos os nós continua a ser a mesma, em comparação com antes.
Agradecimentos
Obrigado a toda a equipa. Menção especial a Bryan Bojorque por nos ajudar com a contentorização e implementação do cluster Helix e Zookeeper e por dar vida às métricas destes clusters no Datadog.
Reforce a sua segurança
A sua rede está protegida contra utilizadores não autorizados? Clique aqui para saber como a Foxpass pode ajudar a evitar erros de segurança dispendiosos:
