Dark Matter: Motivation and Constraints
2.5 Dark Matter Detection
Neste capítulo, foram apresentados os objetivos e requisitos da arquitetura do eCaMid. Em seguida, foram explicados todos os mecanismos adicionados à arquitetura do CaMid origi- nal: coordenação, comunicação assíncrona, execução de tarefas, compartilhamento de estado, gerência de ciclo de vida e balanceamento de carga. Nas demais seções foram explicadas as tecnologias utilizadas pelo eCaMid para prover seus serviços e uma arquitetura de implantação para o mesmo.
4
Avaliação de Desempenho e Discussão
No capítulo anterior, foram apresentados vários mecanismos que estendem as funciona- lidades fornecidas pelo CaMid original, de forma a suportar o desenvolvimento de aplicações elásticas na nuvem. No entanto, a arquitetura e os mecanismos apresentados precisam ser valida- dos, para que seja possível quantificar os benefícios de desempenho e escalabilidade trazidos pelas novas funcionalidades.
Neste capítulo, iremos apresentar uma avaliação experimental que foi realizada com o eCaMid. Iniciaremos este capítulo citando os objetivos da avaliação e a metodologia utilizada. Em seguida, serão mostrados os resultados obtidos a partir da avaliação e será realizada uma análise dos benefícios e prejuízos dos novos mecanismos do eCaMid nos cenários avaliados.
4.1
Objetivos e Metodologia
A avaliação experimental usada no eCaMid utiliza a metodologia sistemática definida porJAIN(1991), voltada para avaliação de desempenho. O experimento realizado no eCaMid visa provar que os mecanismos de coordenação, replicação e balanceamento de carga não causam a queda de desempenho da aplicação. É necessário também provar que o mecanismo de balanceamento de carga utilizado consegue preservar o desempenho da aplicação quando nós são adicionados dinamicamente em um cluster, provando que seus mecanismos internos são capazes de reagir a mudanças de topologia rapidamente.
Para implementar a avaliação foi desenvolvida uma aplicação simples, que foi desenvol- vida utilizando o modelo de programação do eCaMid. Esta aplicação é constituída de um objeto remoto chamado PasswordEncryptionService que contém um método que aplica um hashing criptográfico a uma senha, utilizando o algoritmo PBKDF2WithHmacSha1, com um salt de 64 bits e uma senha de 160 bits. Este algoritmo aplica várias funções de hash à senha utilizada iterativamente, com o objetivo de aumentar o tempo necessário para realizar um ataque de força bruta que visa descobrir a senha original a partir do hash gerado. O objetivo desta aplicação é prover um kernel possa executar uma operação que é exigente em termos de processamento (uso de CPU), é comum em aplicações de nuvem (hashing criptográfico de senha) e não depende de
um mecanismo de persistência durável, como é o caso de um banco de dados.
Duas versões do mesmo objeto foram construídas. Na versão stateless, um salt é gerado a cada vez que um método é chamado e é aplicado o hashing criptográfico à senha utilizando este salt e o número de iterações do algoritmo. Na versão stateful, o salt é criado apenas na construção do objeto, permanecendo na memória mesmo a cada execução.
Dois diferentes cenários foram utilizados para fazer a avaliação experimental do eCaMid. O primeiro consiste no uso de uma máquina virtual representando a aplicação cliente e uma aplicação servidor com um conjunto de objetos remotos, o serviço de nomes e o global manager, que é executada em uma segunda máquina virtual. Neste primeiro cenário, o middleware é executado sem os mecanismos de suporte à elasticidade fornecidos pelo eCaMid, visando criar um ambiente similar ao utilizado na avaliação experimental do CaMid original.
O segundo cenário é bastante similar ao primeiro, com uma máquina virtual contendo o cliente e a outra com a parte servidor. Neste caso, no entanto, os mecanismos de coordenação, compartilhamento de estado e balanceamento de carga foram ativados. Adicionalemente, novos nós seriam adicionados ao cluster em intervalos regulares, através de um script, cada um executado uma nova máquina virtual. Apenas um nó fixo será utilizado, sem a utilização de failover, visto que esta avaliação não procura avaliar os mecanismos de disponibilidade do middleware. Este cenário visa criar um ambiente onde são utilizados os recursos de elasticidade do eCaMid, incluindo a sua capacidade de adaptação ao redimensinamento da infraestrutura.
4.1.1
Métricas, Parâmetros e Fatores
As métricas utilizadas para avaliar o desempenho do eCaMid são tempo de resposta e vazão. As métricas tempo de resposta e vazão visam medir o desempenho e escalabilidade do sistema.
A fórmula usada para medir o tempo de resposta é: Tresposta= tf im− tinicio, onde tf im
representa o instante em que a requisição foi concluída com sucesso e tiniciorepresenta o instante
em que a requisição foi iniciada. Para o cálculo do tempo de resposta, apenas as requisições que completaram com sucesso são contabilizadas.
A fórmula usada para calcular a vazão é: V = Rsucesso
T , onde Rsucessorepresenta o número
de requisições completadas com sucesso e T representa um intervalo temporal específico. A métrica de tempo de resposta é calculada para cada requisição realizada durante a avaliação. Já a métrica de vazão é calculadas uma vez ao final da avaliação, utilizando o número de requisições para um intervalo específico.
Uma série de parâmetros podem afetar as métricas mencionadas: (1) Número total de clientes concorrentes em um intervalo X; (2) O número total de iterações utilizado pelo algoritmo PBKDF2WithHmacSha1; (3) Tamanho do salt utilizado; (4) Tamanho do hash gerado; (5) Taxa de transferência da rede; (6) Capacidade de processamento da máquina virtual; (7) Quantidade de servidores virtuais; (8) Estado de objeto remoto.
As aplicações, em ambos os cenários, devem ter a escalabilidade suficiente para atender um grande número de requisições simultâneas. O número de clientes que realizam requisições influenciam diretamente as métricas de tempo de resposta e vazão. O tempo de resposta do sistema avaliado deve apresentar um valor baixo quando o número de clientes é pequeno, e deve crescer à medida que o número de clientes aumenta. A vazão não apresenta o mesmo tipo de variação. Caso o número de clientes seja baixo, a vazão deve apresentar um valor baixo. A vazão do sistema aumenta com um número de clientes até alcançar um ponto de saturação. Após este ponto, a vazão do sistema tende a cair. Este comportamento pode ser provado analiticamente através da teoria das filas (BAKOUCH,2011).
O número de iterações, dos parâmetros que afetam o mecanismo de hashing criptográfico, possui a maior influência sobre as métrica de desempenho, pois este tem um impacto direto sobre a complexidade computacional do algoritmo. Logo, se o número de iterações é grande, maior será o tempo de resposta do sistema e menor a vazão. Pode ser fixado um tamanho de hash e salt entre os valores recomendados enquanto são variados os valores de número de iterações para aumentar ou diminuir o tempo de resposta (TURAN et al.,2010).
A taxa de transferência da rede pode influenciar diretamente o desempenho e escala- bilidade do sistema avaliado. Por este motivo, para os dois cenários avaliados, é utilizado um ambiente de rede homogêneo. A mesma estratégia é adotada para a capacidade de processamento, utilizando máquinas virtuais com a mesma configuração em todos os cenários avaliados.
A quantidade de servidores virtuais usados na avaliação tem pouca influência no desem- penho, mas grande influência na escalabilidade do sistema avaliado. No primeiro cenário, um único servidor virtual é utilizado, enquanto no segundo cenário, é utilizado um único servidor virtual e mais quatro servidores virtuais são adicionados através do script que executa o teste de desempenho. Foi escolhido o número total de cinco servidores virtuais para que fosse pos- sível observar o ganho incremental nas métricas ao se adicionar novos servidores virtuais na infraestrutura.
Caso o objeto remoto apresentado pelo sistema testado possua estado durante a execução do middleware, este pode afetar de maneira adversa o desempenho do sistema avaliado por conta do esforço necessário para manter este estado consistente. Caso este mesmo objeto seja utilizado concorrentemente, a sincronização dessas requisições adicionam um impacto sobre o desempenho do middleware. Se este estado for compartilhado com outros nós, como é o caso do segundo cenário, o custo de sincronização afetará diretamente o tempo de resposta e vazão da aplicação.
Dentre os parâmetros citados, alguns foram escolhidos como fatores do experimento. Foram escolhidos parâmetros que podem ser variados durante a geração da carga de trabalho realizada no experimento e que são pertinentes para ambos os cenários. Os fatores escolhidos, e seus respectivos valores são:
Número de clientes: Foram utilizados os valores 50, 100, 150 e 200 para a quanti-
cenários diversos.
Número de iterações para o algoritmo PBKDF2WithHmacSha1: Foram selecio-
nados os valores 8000, 16000, 32000 e 64000 iterações para o algoritmo de hashing criptográfico.
Estado do objeto remoto: Este fator possui dois níveis: com estado (stateless) e
sem estado (stateful).
4.1.2
Técnica de avaliação, carga de trabalho e projeto de avaliação
Foi escolhida a técnica de experimentação para realizar a avaliação de desempenho do eCaMid. Esta técnica permite testar um protótipo real do middleware, em uma situação que se aproxima do uso real de uma aplicação distribuída.O provedor de nuvem escolhido foi o AWS, onde o serviço Elastic Compute Cloud (EC2) foi utilizado para provisionar as máquinas virtuais que foram usadas nos experimentos e fornecer uma imagem que já continha uma instalação prévia do eCaMid e um script de inicialização. As máquinas virtuais utilizadas em todos os experimentos e cenários eram da classe m1.small, com 1.7 GB de memória RAM e 1 Compute Unit1e localizadas na zona us-west-2a. Em cada máquina virtual foi instalado o sistema operacional Ubuntu Server 64 bits 12.04.
Uma máquina virtual separada foi utilizada para simular os clientes do sistema avaliado. Um programa sintético foi utilizado para simular os clientes, registrar o tempo de resposta de cada requisição e registrar se esta foi terminada com sucesso ou não. Cada cliente é simulado através de uma thread separada, onde cada cliente realiza uma nova requisição, com um intervalo entre cada requisição. O valor deste intervalo é definido como uma variável aleatória distribuído através de uma função gaussiana, com média de 300 ms e desvio padrão de 100 ms.
Cada experimento teve uma duração de 12 minutos, onde um minuto é utilizado como tempo de espera para que o programa sintético seja carregado e estabilizado (warm-up). O segundo minuto do experimento é utilizado para iniciar cada cliente em intervalos regulares (ramp-up). Supondo que sejam 200 clientes usados no experimento, então um novo cliente é iniciado a cada 30 segundos.
O programa sintético foi criado através da utilização da ferramenta JMeter (APACHE JMETER,2013). Foi criado um Sampler específico do JMeter que utiliza a parte cliente do eCaMid para se comunicar com a parte servidor da aplicação, onde o cluster está desativado no primeiro cenário e ativado no segundo. Através do JMeter foi possível implementar os mecanismos de simulação de clientes, warm-up e ramp-up utilizados no experimento.
Os objetos remotos que contém a função de hashing criptográfico, podem ou não conter estado. Na implementação stateless, um novo valor de salt é gerado para cada nova requisição 11 Compute Unit é equivalente a capacidade de processamento de um processador Opteron, com 1.0 GHz,
do método de hashing, portanto, duas invocações para aplicação de hashing à mesma senha irão produzir hashes diferentes. Na implementação stateful, o valor do salt é gerado durante a invocação do primeiro método. Invocações susbsequentes para a mesma senha irão gerar o mesmo hash. O valor retornado por objetos stateful é usado para verificar se houve algum erro de consistência. Objetos stateless utilizam a estratégia Per-Request Instance, enquanto objetos stateful Client-Dependent Instance.
Ao final de cada experimento, as máquinas virtuais foram reiniciadas e todos as partes da aplicação, cliente ou servidor, foram reiniciados, para reduzir a possibilidade de saturação dos recursos gerenciados pelo sistema operacional da máquina virtual e da própria aplicação. Os experimentos foram conduzidos em horário comercial, para evitar algum problema relacionado à manutenção da infraestrutura do provedor de nuvem.