capacidade de armazenamento de 2x40GB = 80GB SSD, que permite a escrita de 50 vídeos de tradução de legenda (50x1.6GB = 80GB). Como esse limite está muito justo, foi esco- lhido o valor 49 como o número máximo de requisições simultâneas. Para 50 requisições simultâneas o pior tempo coletado nos experimentos foi 534.53 s, que foi aproximado para 550 s e usado como limite folgado para o processamento de 49 traduções simultâneas.
Com esses experimentos preliminares, é possível observar que o programa VLIBRAS é passível de falhas, mesmo em condições favoráveis, vide 2/4/6 requisições simultâneas da Tabela 5.5 e a Tabela 5.8 como um todo. Esse é um dos fatores que eleva a necessidade de haver uma política de tolerância a falhas em nível de software.
Na próxima seção será descrito o projeto de experimentos e seus respectivos resultados.
5.3
Projeto de Experimentos
O planejamento do experimento foi realizado utilizando-se a técnica de projeto fatorial 2k
. Tal técnica é usada para analisar os efeitos de k fatores, onde todos eles tem dois níveis. Os níveis podem ser quantitativos (no de requisições simultâneas e injeção de falhas) ou quali-
tativos (tipo da instância Ec2 e carga de trabalho). Uma repetição completa consiste em 2k
unidades experimentais. Quando o experimento envolve muitos fatores, os projetos fatoriais completo e fracionado podem implicar restrições de tempo, ao passo que o fatorial 2k
por só ter dois níveis para cada fator, tende a resultar em um número plausível de experimentos. Porém, para estimar os erros experimentais e agregar valor ao resultado dos experimentos é preciso replicar os 2k experimentos. Desse modo, têm-se 2krobservações, e pode-se com- parar o grau de variação devido a cada fator, devido a interação entre eles, e devido aos erros experimentais.
Primordialmente, pretende-se avaliar a capacidade de provisionamento dinâmico e de tolerância a falhas. Para tanto, nosso projeto fatorial 2krcontará com os fatores “número de requisições simultâneas” assumindo o valor 10 ou 500, e “injeção de falhas” com valor 0 ou 10%. Adicionalmente, queremos saber a influência que a “carga de trabalho” e o “tipo de instância Ec2” terão sobre o tempo de geração dos vídeos. Nosso projeto fatorial 2k
rterá k = 4 e r = 20. A Tabela 5.10 detalha os fatores e suas variações.
5.3 Projeto de Experimentos 75
Tabela 5.10: Fatores do projeto fatorial 2k
r
Fatores Mínimo (-1) Máximo (1)
A Injeção de falhas 0 10%
B Node req. simultâneas 10 500
C Carga de trabalho Leg. (21 min.) e texto (581 chars) Leg. (2h) e texto (2202 chars) D Tipo de Instância Ec2 m1.small c3.xlarge
rão replicados 20 vezes1, resultando em 320 experimentos. A Tabela D.1 no apên-
dice D especifica os 16 experimentos, exibindo o valor que as variáveis A, B, C, e D assumirão, além dos valores para a interação entre estes fatores. Os valores para AB/AC/AD/BC/BD/CD/ABC/ABD/ACD/BCD/ABCD são calculados a partir do produto do seus fatores. A coluna ABC, por exemplo, é resultado da multiplicação dos valores de A, B, e C. A partir desses valores, e da média das replicações, é possível calcular o impacto de cada fator no tempo final, além do grau de importância das interações entre eles.
5.3.1
Execução do Projeto de Experimentos
Para cada teste utilizamos duas instâncias Ec2 c3.large como base. Uma instância foi utili- zada como origem das requisições, e a outra iniciada com o Broker e configurações especí- ficas para cada experimento. Escolhemos a instância c3.large pois ela é dotada de 3.75 GB de memória RAM, 2 núcleos de 3.5 ECUs cada (2 vCPUs e 7 ECUs), e desempenho de rede “moderado”.
A capacidade de memória RAM é importante ao Broker uma vez que configuramos o uso de memória RAM do servidor Tomcat 7 para 2048 MB, onde o padrão é apenas 128 MB (Código Fonte E.1 em Apêndice E). Sem essa alteração, o Broker lançava exceções do tipo “java.lang.OutOfMemoryError”, já que em alguns experimentos o Broker cria 500 threads simultâneas ao receber as 500 requisições.
O fato da máquina c3.large ter sido escolhida também se deve a seu desempenho de rede “moderado”, já que existem instâncias com desempenho classificado “baixo”. Isto é importante para que a rede não seja gargalo para nossos experimentos, não interferindo no resultado final. Neste sentido, também foi preciso reconfigurar a tag Connector do arquivo
5.3 Projeto de Experimentos 76
de configurações do servidor (/var/lib/tomcat7/conf/server.xml) para elevar sua capacidade de atender requisições simultâneas (Código Fonte ?? em Apêndice E).
Para simular as requisições simultâneas utilizamos a ferramenta ab - Apache HTTP ser- ver benchmarking (http://httpd.apache.org/docs/current/programs/ab.html). A linha de co- mando apresentada no Código Fonte E.2, é utilizada para simular o 1o experimento para
A=-1, B=1, C=-1 e D=-1 (sem injeção de falhas, com 500 requisições simultâneas, carga de trabalho baixa, instância Ec2 m1.small). A Tabela E.1 explica o que cada parâmetro utili- zado no ab representa. O Código Fonte E.3, no Apêndice E exemplifica a saída gerada pela ferramenta ab para o experimento executado na linha de comando do Código Fonte E.2, re- ferente as requisições de legenda. O principal conteúdo coletado é a linha 34 que nos detalha a média de tempo e desvio padrão em milissegundos para aquele experimento.
Injeção de Falhas
Para injetar 10% de falhas referentes as requisições submetidas, inserimos um trecho de código (5.1) no componente VLIBRAS que a cada 10 requisições recebidas, a primeira falha.
Código Fonte 5.1: Injeção de 10% de falhas no VLIBRAS
1 / ∗ I n j e c a o de 10% de f a l h a s no a t e n d i m e n t o das r e q u i s i c o e s ∗ / 2 i f ( V L i b r a s . m a y F a i l ) { 3 V L i b r a s . i n c r e m e n t a N u m R e q u i s i c o e s R e c e b i d a s ( ) ; 4 i f ( V L i b r a s . g e t N u m R e q u i s i c o e s R e c e b i d a s ( ) == 1 ) 5 r e t u r n n u l l ; 6 e l s e i f ( V L i b r a s . g e t N u m R e q u i s i c o e s R e c e b i d a s ( ) == 1 0 ) 7 V L i b r a s . s e t N u m R e q u i s i c o e s R e c e b i d a s ( 0 ) ; 8 }
Os métodos “VLibras.incrementaNumRequisicoesRecebidas()”, “VLi- bras.getNumRequisicoesRecebidas()” e “VLibras.setNumRequisicoesRecebidas(int)”, são sincronizados, e portanto seguros quanto à concorrência de threads simultâneas.
É importante ressaltar que a injeção de falhas acontece no componente VLIBRAS, e não nas requisições em si. Por exemplo, se submetermos 500 requisições, não necessariamente teremos 50 falhas, já que as máquinas serão criadas com o decorrer do experimento por meio do escalonamento. As falhas, portanto, estão diretamente relacionadas ao escalona- mento e quantidade de instâncias para processar a fila. Se uma instância processar apenas 11 requisições, devido à concorrência com outras instâncias para consumir a fila, 2 falharão,