Introdução 12 que inuenciam a execução do sistema. As informações necessárias para o diagnóstico de tais problemas podem ser obtidas através da instru

Transcrição

1 1 Introdução Atualmente a demanda pela construção de novos sistemas de software tem aumentado. Junto com esse aumento também cresce a complexidade das soluções que estão sendo desenvolvidas, o que torna ainda mais desaador o processo de concepção e manutenção desses sistemas. Nesse cenário, soluções baseadas em componentes de software vêm sendo amplamente usadas [6]. Sistemas baseados em componentes apresentam a característica de dividir um problema grande em partes. Essa divisão auxilia a construção e manutenção do sistema, pois as partes podem ser desenvolvidas individualmente, abstraindo o restante do sistema. Isso torna mais fácil a distribuição dos componentes por diversas máquinas. Para auxiliar o desenvolvedor dos componentes, algumas ferramentas oferecem uma camada de abstração capaz de tornar transparentes questões como localização, concorrência, replicação, falhas e mobilidade. Nesse contexto alguns middlewares foram implementados como CORBA [7] e Java RMI[8]. Esses middlewares fornecem uma camada de software entre as aplicações e o sistema operacional, provendo mecanismos para tratar de problemas recorrentes em aplicações distribuídas, como heterogeneidade e portabilidade. Embora esses middlewares facilitem o desenvolvimento de aplicações distribuídas ao esconder do desenvolvedor questões como a comunicação entre as partes do sistema, também escondem gargalos existentes nesta comunicação e componentes sobrecarregados. Dessa forma, caso a aplicação passe a apresentar um comportamento inesperado, como queda de desempenho, torna-se difícil a atividade de identicar em qual ou entre quais componentes está o problema. Sendo assim, passa a ser necessário o uso de técnicas que possibilitem a monitoração do comportamento de cada componente e de suas interações. Isso pode facilitar a identicação de gargalos de comunicação, sobrecarga de processamento e demais informações

2 Introdução 12 que inuenciam a execução do sistema. As informações necessárias para o diagnóstico de tais problemas podem ser obtidas através da instrumentação do sistema. Basicamente o que é feito é uma inserção de código em determinados pontos do sistema, permitindo que sejam coletadas métricas relevantes para detecção de problemas na aplicação. As formas de realizar essa inserção de código variam de acordo com o tipo de sistema e o tipo de informação que se deseja obter. Por exemplo, em um ambiente computacional distribuído pode ser interessante saber a frequência de uso de cada serviço do componente, quais componentes trocam informações, ou ainda, qual o tempo médio de resposta de um determinado serviço implementado pelo componente. Realizar a coleta de informações relevantes é um dos passos necessários para monitorar o sistema, no entanto, de nada adianta ter essas informações se não existir uma forma de disponibilizá-las. Para isso, neste trabalho, foram desenvolvidas formas de publicação dos dados coletados, que permitem ao administrador da aplicação criar estratégias para denir a periodicidade das publicações. As informações obtidas podem ser usadas, por exemplo, em ferramentas de gerência e diagnóstico de problemas em sistemas distribuídos. Por exemplo, alguns trabalhos [9] [10] usam técnicas de estatística para relacionar os valores coletados com violações no comportamento esperado dos serviços oferecidos. Trabalhos que propõem serviços de conguração dinâmica de sistemas distribuídos [1] [11], como balanceamento de carga e sistemas auto-adaptativos, também podem se beneciar de uma infra-estrutura de instrumentação. Nesses trabalhos o objetivo principal é a realização de recongurações na aplicação, sem a necessidade de interromper o funcionamento do sistema. No entanto, a única forma de concluir quais modicações devem ser realizadas, para melhorar o desempenho do sistema, é analisando as informações coletadas sobre o ambiente de execução desse sistema. O projeto e implementação de uma infraestrutura de monitoração de sistemas distribuídos apresentam uma série de desaos. Como exemplos desses desaos, que serão tratados neste trabalho, incluem-se: A identicação de quais métricas devem ser coletadas, levando-se em consideração que estamos lidando com sistemas de componentes distribuídos; a forma que deve ser utilizada para publicar as informações, de maneira que diversos usuários possam receber as informações coletadas, e tentando causar pouco impacto na execução do

3 Introdução 13 sistema; e até quanto é compensatório aumentar a acurácia das informações coletadas, levando em consideração que o excesso de precisão poderá acarretar em um aumento da sobrecarga imposta à aplicação. 1.1 Objetivos Este trabalho pesquisou e implementou técnicas para monitoração do ambiente de execução de sistemas baseados em componentes distribuídos. O objetivo principal é disponibilizar, para o desenvolvedor ou administrador de aplicações baseadas em componentes distribuídos, um conjunto de ferramentas que o ajude a observar o ambiente de execução desses componentes. Baseado nas métricas coletadas, ele poderá atuar no sistema para otimizar o seu ambiente de execução. O administrador do sistema pode tanto ser uma pessoa ou um outro sistema capaz de avaliar as informações e propor melhorias [12]. Mais especicamente, a arquitetura de monitoração proposta neste trabalho deverá alcançar os seguintes objetivos: coletar métricas do sistema de forma transparente para o desenvolvedor dos componentes; garantir que a coleta das informações do ambiente de execução da aplicação seja realizada sem onerar excessivamente o desempenho da aplicação; poder disponibilizar as informações coletadas para múltiplos consumidores; prover uma forma das informações coletadas serem avaliadas antes de enviadas para o usuário, evitando um número excessivo de envio de mensagens; Para avaliar os resultados obtidos, este trabalho implementou experimentos para vericar os resultados alcançados e demonstrar a viabilidade da arquitetura proposta. Para tanto, foi implementada uma pequena aplicação de componentes distribuídos que possibilitou a realização de testes de desempenho com a arquitetura desenvolvida. Para realizar um teste com uma aplicação mais complexa e que utiliza mais intensivamente as vantagens de uma arquitetura distribuída, foi implementado um exemplo baseado no paradigma de programação MapReduce[5].

4 Introdução Solução Proposta Este trabalho propõe uma arquitetura extensível para coleta e publicação de informações de sistemas de componentes distribuídos, procurando minimizar o impacto sobre o desempenho da aplicação. O administrador da solução distribuída poderá monitorar as máquinas participantes da aplicação e ao mesmo tempo as interações entre os diversos objetos remotos que compõem a aplicação. Para implementação desta arquitetura foi escolhido o middleware SCS [13], que é capaz de fornecer facilidades para construção de componentes de software distribuídos. Esta ferramenta possui uma implementação simplicada do CORBA Component Model (CCM) [14], o que facilitou o processo de instrumentação da mesma. É comum que cada sistema, dependendo de sua nalidade, tenha um conjunto de métricas especícas que sejam relevantes para sua monitoração. Por exemplo, uma ferramenta que realize tarefas de transferência de arquivos entre máquinas distintas terá uma grande demanda por escrita e leitura em disco; logo, informações sobre o número de escritas e leituras realizadas pelos componentes da aplicação serão importantes para o gerenciamento da mesma. Nada garante que essa métrica também será relevante para um outro sistema com características totalmente diferentes como, por exemplo, uma ferramenta para execução de algoritmos distribuídos, que poderá ter maior interesse no uso de memória e CPU de cada componente do que em leituras e escritas em disco. A solução proposta neste trabalho fornece um conjunto básico de métricas que, na nossa visão, são importantes para monitoração de sistemas distribuídos de um modo geral, bem como irá fornecer uma arquitetura exível na qual novas métricas podem ser adicionadas de acordo com a nalidade do sistema monitorado. Além da coleta de dados, é de extrema importância a forma como essas informações serão enviadas para os administradores da aplicação. Neste trabalho, utilizaremos um serviço de eventos para que o mecanismo de monitoração possa enviar as informações para o usuário imediatamente após a coleta. Esse mecanismo permitirá que existam mais de um consumidor das informações, além de evitar que a manutenção dos dados coletados que no mesmo local onde a aplicação executa, o que poderia prejudicar o seu desem-

5 Introdução 15 penho. O envio de um número excessivo de eventos com informações de monitoração pode trazer problemas, sobrecarregando o sistema. Por outro lado, intervalos muito grandes entre publicações de eventos podem ocultar do usuário o real comportamento da métrica que está sendo observada. Para contornar esse problema, propomos o uso de políticas responsáveis por determinar a relevância da publicação de uma determinada métrica, tentando equilibrar a taxa de publicação de métricas com a taxa de variação de seus valores ou do tempo que se passou desde a última publicação. Para avaliar a arquitetura elaborada foi desenvolvido um sistema baseado em um modelo para programação distribuída denominado MapReduce [5]. Com tal modelo foi montada uma aplicação distribuída responsável por contar as ocorrências de palavras em grandes arquivos, e medido o quanto a arquitetura de monitoração onerou a execução do sistema. Além desse caso de uso outros testes foram realizados para mensurar a perda de desempenho obtida ao utilizar as ferramentas desenvolvidas, e o comportamento das políticas de publicação que foram implementadas. 1.3 Estrutura do Texto Os próximos capítulos apresentam em detalhes o trabalho desenvolvido, bem como trabalhos relacionados e os experimentos realizados com a infraestrutura construída. No Capítulo 2, são apresentados trabalhos relacionados com esta dissertação, que serviram como norteador para o trabalho desenvolvido. A infraestrutura de desenvolvimento de componentes de software utilizada neste trabalho, o SCS, é apresentada no Capítulo 3. Já o Capítulo 4 mostra uma visão geral da arquitetura proposta neste trabalho. Em seguida o Capítulo 5 detalha os mecanismos utilizados para realizar a coleta e publicação dos valores. Um estudo dos resultados obtidos, através da implementação de exemplos e testes de desempenho é feito no Capítulo 6. Finalmente no Capítulo 7 são apresentadas as conclusões tiradas após o desenvolvimento desta dissertação.