Alta Vaz˜ao
Computac¸˜ao paralela ´e uma tecnologia chave para permitir o processamento tempestivo da quantidade crescente de dados que est´a sendo gerada por sensores, experimentos cient´ıficos, modelos de simulac¸˜ao e, ultimamente, como um efeito da era de digitalizac¸˜ao que a nossa sociedade como um todo est´a experimentando. De fato, algumas das cargas de trabalho (workloads) que precisam ser processadas s˜ao t˜ao grandes, que a ´unica maneira vi´avel para lidar com elas, em um tempo razo´avel, ´e quebrar o processamento em uma determinada quantidade de tarefas menores, e execut´a-las em paralelo no maior n´umero dispon´ıvel de processadores. Em uma classificac¸˜ao bastante ampla, notadamente quando se consideram as diferenc¸as entre as caracter´ısticas das cargas de trabalho, a computac¸˜ao paralela ´e nor- malmente dividida em Computac¸˜ao de Alta Performance (HPC, do inglˆes High Performance Computing) e Computac¸˜ao de Alta Vaz˜ao (HTC) [Litzkow, Livny e Mutka 1988].
Obviamente, paralelismo em larga escala s´o pode ser alcanc¸ado se houver unidades de processamento dispon´ıveis e um n´ıvel relativamente elevado de independˆencia entre as ta- refas que comp˜oem a aplicac¸˜ao paralela. Felizmente, muitas das cargas de trabalho das aplicac¸˜oes paralelas podem ser mapeadas em tarefas que podem ser processadas de forma completamente independente uma das outras, compondo uma classe de aplicac¸˜oes conhecida como “bag-of-tasks” (BoT) [Cirne et al. 2003]. O fato de que as tarefas de uma aplicac¸˜ao BoT s˜ao totalmente independentes, n˜ao s´o faz o agendamento trivial, mas tamb´em faz com que a tolerˆancia a falhas seja muito mais f´acil, j´a que um mecanismo de repetic¸˜ao simples
3.2 Escalabilidade e Elasticidade para Computac¸˜ao de Alta Vaz˜ao 45
pode ser usado para recuperar tarefas que eventualmente falhem durante a execuc¸˜ao. Como consequˆencia, as aplicac¸˜oes BoT s˜ao menos exigentes com a qualidade do servic¸o suportado pela infraestrutura computacional subjacente.
A vaz˜ao obtida quando se executam aplicac¸˜oes HTC, em geral, e BoT, em particular, sobre uma infraestrutura computacional distribu´ıda depende diretamente da escala que a mesma permite. O tamanho do pool de processamento, definido como o n´umero de pro- cessadores alocados, ´e o principal promotor de desempenho, enquanto que o esforc¸o de coordenac¸˜ao envolvido ´e o principal fator de limitac¸˜ao. Para atingir uma vaz˜ao extrema- mente alta ´e necess´ario operar eficientemente em escala extremamente alta, assumindo que a distribuic¸˜ao de tarefas para os processadores dispon´ıveis e o fornecimento de qualquer dado de entrada necess´ario ou coleta dos resultados gerados n˜ao sejam um gargalo.
De fato, a execuc¸˜ao eficiente de aplicac¸˜oes BoT tem sido relatada em uma variedade de infraestruturas para computac¸˜ao de alta vaz˜ao (HTC), que v˜ao desde grades P2P [Litzkow, Livny e Mutka 1988; Cirne et al. 2006] at´e sistemas massivos de computac¸˜ao volunt´aria [An- derson et al. 2002; Anderson 2004].
O paradigma de grades de desktops (desktop grids) j´a se consagrou como um ambiente apropriado para computac¸˜ao de alta vaz˜ao. O Projeto Condor [Litzkow, Livny e Mutka 1988] ´e reconhecido como o melhor representante existente de tecnologias para dar suporte a grades de desktops de alta vaz˜ao. Outros sistemas que seguiram a filosofia do Condor provaram tamb´em ser igualmente eficazes [Cirne et al. 2006; Oliveira, Lopes e Silva 2002]. Estas infraestruturas gen´ericas s˜ao, entretanto, sistemas de escala limitada. Mesmo se algum tipo de mecanismo de incentivo for usado [Andrade et al. 2007], ´e improv´avel que um sistema que integra mais do que algumas dezenas de milhares de computadores possa ser montado. De fato, os maiores sistemas existentes que usam estas tecnologias n˜ao possuem mais do que alguns poucos milhares de computadores [Thain, Tannenbaum e Livny 2006].
Plataformas para computac¸˜ao volunt´aria (Voluntary Computing) [Anderson et al. 2002; Anderson 2004], por outro lado, j´a provaram a sua adequac¸˜ao para prover HTC e podem congregar quantidades enormes de recursos para processar a carga extremamente alta de suas aplicac¸˜oes t´ıpicas. Estas infraestruturas poderosas s˜ao, entretanto, menos flex´ıveis em relac¸˜ao aos tipos de aplicac¸˜oes que suportam. Primeiro, porque configurar uma infraestru- tura de computac¸˜ao volunt´aria tem um custo significativamente mais elevado do que executar
aplicac¸˜oes BoT de ciclos de vida curtos sobre grades de desktops - isto se deve, principal- mente, pelo fato de que ´e necess´ario conseguir volunt´arios para a iniciativa. Desta forma, tais plataformas tendem a ser mais apropriadas para executar aplicac¸˜oes BoT de longa durac¸˜ao cuja carga de trabalho ´e virtualmente infinita [Anderson et al. 2002]. Al´em disso, a efic´acia da obtenc¸˜ao de recursos volunt´arios para tais plataformas ´e profundamente influenciada pelo impacto percebido da aplicac¸˜ao que ir´a ser executada sobre elas. Em conseq¨uˆencia, somente algumas aplicac¸˜oes de forte apelo popular podem beneficiar-se da vaz˜ao extremamente alta que os sistemas de computac¸˜ao volunt´aria podem entregar. Mesmo assim, isso s´o pode ser alcanc¸ado se um esforc¸o significativo for dedicado a convencer os participantes volunt´arios a aderir ao sistema o que, por sua vez, depende, em maior ou menor grau, de fatores tais como o m´erito e o apelo p´ublico da aplicac¸˜ao, da quantidade de cobertura da m´ıdia recebida, de campanhas de publicidade expl´ıcita em meios populares de comunicac¸˜ao, de marketing viral, dos incentivos para os volunt´arios e de outras atividades de relac¸˜oes p´ublicas [Shiers 2010]. A escalabilidade na implantac¸˜ao deste tipo de projeto tamb´em depende de tornar a tarefa de instalac¸˜ao extremamente simples e contar com o propriet´ario do recurso envolvido ativamente na configurac¸˜ao do sistema. Normalmente, a implantac¸˜ao ´e bem simplificada, constando basicamente do download e da instalac¸˜ao de um programa, o que pode ser fa- cilmente realizado pelo propriet´ario do recurso. Entretanto, n˜ao h´a uma padronizac¸˜ao do que deve ser instalado por cada projeto de computac¸˜ao volunt´aria, o que requer a repetic¸˜ao do esforc¸o de instalac¸˜ao por parte do volunt´ario. Por exemplo, um usu´ario que deseja doar recursos computacionais para os projetos SETI@home [Anderson et al. 2002] ou Fight- AIDS@home [Scripps 2011] deve instalar duas aplicac¸˜oes espec´ıficas e diferentes, cada uma com os seus pr´oprios protocolos e parˆametros.
Se por um lado, o envolvimento do usu´ario permite a implantac¸˜ao potencial em milh˜oes de recursos com baixo custo, do outro lado, isto torna o crescimento da infraestrutura lento e fora do controle do gestor do projeto de computac¸˜ao volunt´aria. Al´em disso, as mudanc¸as no software instalado nos recursos s˜ao mais dif´ıceis de serem realizadas, a menos que algum procedimento de atualizac¸˜ao autom´atica seja fornecido. Isto, por sua vez, pode aumentar as preocupac¸˜oes de seguranc¸a por parte dos volunt´arios e, eventualmente, afetar negativamente a sua vontade de aderir ao sistema. Al´em disso, a singularidade intr´ınseca de cada aplicac¸˜ao e a necessidade de configurac¸˜ao inicial, diminui consideravelmente a flexibilidade destas pla-