Os componentes adicionais requeridos em uma infraestrutura de autorização exter- nalizada (como o PEP, PDP, PIP, entre outros) possibilitam que restrições de acesso que antes ficavam no código da aplicação sejam implementadas em serviços externos a aplicação, além de expor uma interface (PAP) que permite a manipulação dinâmica de políticas de controle de acesso, no entanto, esses componentes trazem um custo computacional extra para a infraestrutura de autorização que necessita ser medido, comparado com a abordagem anterior (legada - restrições no código), e avaliado no sentido de verificar se a perda de desempenho não inviabiliza a adoção da proposta.
Neste sentido, esta seção descreve os experimentos realizados com uma ferramenta de teste de desempenho ao sistema SUAP em um ambiente similar ao utilizado em produção, sendo uma das instâncias do SUAP configuradas com o formato legado de autorização (restrições no código), e outra com a proposta de externalização dos mecanismos de
autorização.
A seguir serão apresentados os planos de testes a serem executados nas instâncias do SUAP, os experimentos realizados, os resultados e ameaças a validade deste estudo.
5.3.1
Plano de Teste
Nesta seção é descrito o plano e a estratégia utilizada para realização dos testes de desempenho nas 2 abordagens de autorização do SUAP, a legada e a externalizada. O aplicativo Apache JMeter é instalado e configurado na máquina virtual mpes-load, que se encontra no mesmo segmento de rede das outras VM’s utilizadas pelo SUAP (mpes-suap01, mpes-suap02, entre outras).
A estratégia é realizar requisições a chamados do módulo Central de Serviços nas 2 instâncias do SUAP com uma quantidade crescente de usuários ao longo de 10 minutos, e no final obter métricas como tempo de resposta, quantidade de requisições, requisições por segundo, etc. Os testes são executados inicialmente no SUAP-Legado, e são repetidos por 10 vezes para remover distorções nos valores, em seguida os mesmos testes são executados no SUAP-Externalizado e as mesmas métricas são obtidas.
Para facilitar a implementação do plano de testes o ambiente gráfico do JMeter é utilizado, em seguida o arquivo do plano gerado pelo aplicativo (extensão jmx) é copiado para o servidor mpes-load para que os testes sejam executados em um ambiente não-gráfico. Outros procedimentos como a desativação dos listners ao executar o teste no servidor de carga foram realizadas seguindo as boas práticas recomendadas pelo JMeter 6, diminuindo as chances do teste ser comprometido com processamentos desnecessários como a geração de estatísticas (listeners), ambiente gráfico, latência de rede (teste realizado localmente mas apontando para um servidor remoto no datacenter por exemplo), entre outros. Os testes realizados pelo plano geram um arquivo no formato csv, que após o término dos testes são processados gerando uma página html (dashboard) com as estatísticas, gráficos, entre outras informações.
Os planos de testes contém os mesmos parâmetros, mudando apenas o alvo onde serão executados os testes, sendo o primeiro apontado para a a instância do SUAP denominada “SUAP-Legado” que se encontra na VM mpes-suap01, e o segundo apontando para o SUAP-Externalizado que se encontra na VM mpes-suap02. A tabela 4apresenta os parâmetros do plano de testes implementado no JMeter.
Tabela 4 – Plano de testes
Parâmetro Valor
Threads 100
Ramp-Up 500
Schedule 600
CSV Data Set users.csv
A propriedade threads no JMeter está relacionada ao número de usuários simul- tâneos a serem utilizados no teste. O teste inicia com 1 usuário, e baseado no valor especificado na propriedade Ramp-Up os demais usuários (limite de 100 usuários) são chamados gradativamente durante o tempo do teste. O tempo total do teste são 10 mi- nutos (600 segundos), sendo que cada usuário deve iniciar seu teste de forma simultânea a cada 5 segundos (500 ramp-up dividido por 100 threads = um novo usuário a cada 5 segundos), ou seja, antes do tempo total do teste (10 minutos) todos os 100 usuários já terão sido iniciados e estarão executando requisições simultaneamente. As credenciais dos 100 usuários utilizados nos testes são importados do arquivo users.csv
As requisições são realizadas em chamados aleatórios do módulo central de serviços em uma base contendo aproximadamente 72 mil registros (dados dos usuários e dos chamados foram mascarados), e tem por objetivo atenuar o impacto de cache nos diversos componentes envolvidos na infraestrutura (banco de dados, servidor web, servidor de autorização, PIP, entre outros) e que podem comprometer os resultados dos testes. O SecAuthAPI não implementa cache nas suas operações.
5.3.2
Experimentos
Esta seção apresenta os resultados dos experimentos realizados com a ferramenta de testes de desempenho JMeter nas 2 instâncias do SUAP. Conforme relatado anteriormente, a infraestrutura de autorização dos mecanismos de autorização tem um custo computacional envolvido, e este precisa ser comparado com a abordagem atual (legada) com intuito de avaliar a viabilidade considerando um cenário de um sistema real.
A tabela5 apresenta os resultados obtidos durante as 10 execuções dos testes de desempenho realizadas no “SUAP-Legado” baseado no plano de testes especificado na seção anterior. A coluna “Usuários” exibe a evolução dos testes durante diferentes cargas de usuários, iniciando com os resultados obtidos com até 10 usuários, e variando de 10 em 10 até o limite de 100 usuários. As colunas seguintes exibem o tempo médio, mediana, e o desvio padrão. Os dados obtidos durante os experimentos são apresentados detalhadamente nas tabelas 12e 13no apêndice C.
Tabela 5 – Testes de desempenho no SUAP-Legado e SUAP-Externalizado
Tempo de resposta das requisições em milissegundos (ms)
Os resultados dos testes de desempenho realizados no “SUAP-Legado” mostram que apesar do aumento gradativo na quantidade de usuários no decorrer do teste, o tempo de resposta das requisições se mantém linear até o limite máximo de usuários definidos para o experimento (100 usuários).
Os mesmos testes foram realizados no “SUAP-Externalizado”, e percebe-se que o custo computacional que a infraestrutura de externalização traz ocasiona um aumento no tempo de resposta das requisições, mas sem grandes variações durante o aumento gradativo dos usuários em comparando com a abordagem legada. O aumento do tempo de resposta na proposta de externalização também se mantém linear.
resposta das instâncias do SUAP considerando o aumento do número de usuários no decorrer do tempo. Considerando a diferença entre a média de tempo das requisições das 2 abordagens, percebe-se que a abordagem externalizada tem uma perda de desempenho médio de 7,01% em comparação com a legada. O impacto da perda de desempenho da infraestrutura de externalização em comparação com a infraestrutura legada em termos absolutos é de menos de 0,5 segundos.
Figura 22 – Tempo de resposta x Número de Usuários
Fonte: Elaborado pelo autor
A perda de desempenho da arquitetura de autorização externalizada em comparação com a legada se dá principalmente devido ao custo computacional extra dos componentes como o PEP, PDP e PIP. Cada requisição realizada na aplicação é interceptada pelo PEP, que necessita gerar uma requisição para o PDP para que a decisão seja computada (XACML Request/Response). Quando a requisição chega no PDP para decisão o servidor de autorização recupera as políticas, computa os atributos, e quando requerido solicita atributos extras ao PIP. O PIP por sua vez conecta em fontes externas como Postgres e
LDAP, e devolve os valores para o PDP finalizar a computação da decisão. Todas essas
etapas têm custos computacionais extras, como lidar com arquivos XML, latência de rede entre as comunicações do PEP com PDP e PIP com LDAP e Postgres, entre outros.
Considerando que a abordagem de externalização traz diversos benefícios elencados em seções anteriores, observa-se que essa perda de desempenho torna-se justificável e passível de mitigação, já que novos nós do SUAP podem ser incluídos no cluster de balanceamento de carga com intuito melhorar o tempo de resposta em ambientes em larga escala, e dessa forma melhorar o tempo de resposta das requisições para os usuários finais.
5.3.3
Discussão
Esta seção descreveu os teste de desempenho realizados nas instâncias legada e externalizadas do SUAP com intuito de obter o tempo médio de resposta das requisições
das duas abordagens e avaliar se o custo adicional da infraestrutura de autorização é viável considerando o contexto de um sistema real.
Os resultados dos testes de desempenho demonstram que a abordagem externalizada tem uma perda de desempenho média de aproximadamente 7%, no entanto considerarmos que em ambientes reais com centenas de usuários o tempo de resposta da abordagem externalizada pode ser melhorado usando estratégias de balanceamento de carga, cache, entre outros, portanto conclui-se que é viável a utilização da abordagem em ambientes reais.
De todo modo, embora os testes de desempenho tenham sido realizados baseados nas boas práticas recomendadas pela literatura e na documentação das ferramentas, os resultados são passíveis a ameaças de validade por alguns fatores que serão elencados a seguir.
Os testes foram realizados com um número máximo de 100 usuários simultâneos baseados em dados obtidos dos relatórios de uso do SUAP no IFRN, entretanto, esse número pode ser bem maior considerando acessos atípicos como votações em enquetes, resultados de provas, entre outros. Na avaliação, observou-se que o tempo de resposta das requisições cresceu de forma linear, no entanto não foram realizados testes de stress para observar o comportamento do sistema no seu limite máximo.
Um outro fator a considerar é o tempo da execução dos testes. Cada rodada de testes tem um tempo máximo de 10 minutos (600 segundos), e um ramp-up de 500 segundos, ou seja, ao chegar em 8 minutos e 20 segundos todos os usuários estarão ativos e fazendo requisições ao recurso, e essa carga máxima de 100 usuários continuará sendo executada por mais 100 segundos (1 minuto e 40 segundos) até atingir o tempo máximo do teste, no entanto testes mais longos (horas por exemplo) não foram executados, e estes poderiam indicar problemas como implementação que causem consumo excessivo de memória, condição de corrida (race-condition), entre outros.
Por fim, os testes foram realizados apenas no módulo central de serviços, no entanto, testes em outros módulos auxiliariam a identificar gargalos em implementações de consultas a outras fontes de dados (PIP) que poderiam comprometer o tempo de resposta da infraestrutura de autorização.