SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem

Transcrição

1 SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem Flávio R. C. Sousa, Leonardo O. Moreira, Javam C. Machado Universidade Federal do Ceará - Brasil {sousa,leoomoreira,javam}@ufc.br Abstract. Computação em nuvem é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços sob demanda com pagamento baseado no uso. Neste ambiente, a qualidade do serviço é uma característica fundamental que deve ser fornecida pelos provedores. Existem muitos modelos para acordo de nível de serviço em nuvem. Entretanto, estes modelos são muito gerais e não abordam características do gerenciamento de dados em nuvem. Este artigo propõe o SLADB, uma abordagem de SLA para serviços de banco de dados em nuvem. Esta abordagem auxilia os provedores na implementação da qualidade do serviço de banco de dados e contempla diferentes aspectos, tais como tempo de resposta, vazão, disponibilidade e consistência. Visando avaliar o SLADB, alguns experimentos que medem a qualidade do serviço são apresentados. Categories and Subject Descriptors: H.Information Systems [H.m. Miscellaneous]: Databases Keywords: Banco de Dados, SLA, Qualidade do serviço 1. INTRODUÇÃO Computação em nuvem é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação (TI) sob demanda com pagamento baseado no uso. Sistemas de gerenciamento de banco de dados (SGBDs) 1 são candidatos potenciais para a implantação em nuvem. Isso ocorre porque, em geral, as instalações destes sistemas são complexas e envolvem uma grande quantidade de dados, ocasionando um custo elevado, tanto em hardware quanto em software. Para muitas empresas, especialmente para startups e médias empresas, o pagamento baseado no uso do modelo de computação em nuvem, juntamente com o suporte para manutenção do hardware é muito atraente [Abadi 2009]. Na nuvem, o usuário do serviço tem algumas garantias, tais como desempenho e disponibilidade. Essas garantias de qualidade do serviço (QoS) são denidas entre o provedor do serviço e o usuário e expressas por meio de um acordo de nível de serviço (SLA) [Chi et al. 2011]. Este acordo consiste de contratos que especicam um nível de qualidade que deve ser atendido e penalidades em caso de falha. Muitas empresas dependem de SLA, por exemplo, para exibir uma página web dentro de um determinado intervalo de tempo. Essas empresas esperam que os provedores de nuvem forneçam garantias de qualidade utilizando SLAs com base em características de desempenho. Contudo, em geral, os provedores baseiam seus SLAs apenas na disponibilidade dos serviços oferecidos, ao passo que os serviços em nuvem apresentam uma variabilidade de desempenho bastante elevada. Portanto, é essencial que os provedores ofereçam SLAs baseados em desempenho para os usuários [Schad et al. 2010]. Para muitos sistemas, a maior parte do tempo de processamento das requisições está associada ao SGBD (em vez do servidor web ou servidor de aplicação). Dessa forma, é importante que a qualidade seja aplicada no SGBD para controlar o tempo de processamento [Schroeder et al. 2006]. 1 SGBD refere-se um uma classe geral de armazenamento de dados, incluindo sistemas não-relacionais. 155

2 132-2 F.R.C Sousa, L. O. Moreira e J. C. Machado Existem muitos modelos para SLA e qualidade de serviço em nuvem [Fito et al. 2010], [Malkowski et al. 2010] [Schnjakin et al. 2010]. Entretanto, estes modelos são muito gerais e não tratam características do gerenciamento de dados em nuvem. Modelos para SLAs e qualidade especícos para serviços de banco de dados propõem soluções neste contexto [LSCR 2011] [Yang et al. 2009] [Xiong et al. 2011] [Chi et al. 2011]. Contudo, estes modelos não contemplam alguns aspectos do gerenciamento de dados em nuvem, tais como métricas especícas para serviços de banco de dados em nuvem e propõem apenas parte de uma solução para qualidade, por exemplo, a denição de um SLA ou abordagens para penalidades. Além disso, estes trabalhos não utilizam técnicas ecazes de monitoramento especícas para SGBDs, fundamentais para tratar a elasticidade do ambiente de computação em nuvem. De acordo com nosso estudo, não existem soluções que abordem este problema, enquanto trabalhos anteriores se concentram apenas em alguns aspectos deste problema. Para solucionar este problema, este trabalho propõe o SLADB, uma abordagem de SLA para serviços de banco de dados em nuvem. Esta abordagem auxilia os provedores na implementação da qualidade do serviço de banco de dados e contempla diferentes aspectos, tais como tempo de resposta, vazão, disponibilidade e consistência. Visando avaliar o SLADB, alguns experimentos que medem a qualidade do serviço são apresentados. Este artigo está organizado da seguinte forma. Na seção 2, o SLADB é apresentado e suas características são discutidas. A implementação da solução é descrita na seção 3. Alguns experimentos que avaliam a qualidade do serviço são apresentados na seção 4. A seção 5 comenta sobre os trabalhos relacionados e, nalmente, a seção 6 contém as conclusões. 2. SLADB O SLADB é uma abordagem de SLA para serviços de banco de dados em nuvem. Esta abordagem contempla diferentes aspectos do gerenciamento de dados e é orientada ao lucro, o que faz o provedor fornecer um serviço com qualidade. O SLADB é uma solução completa para auxiliar a qualidade do serviço, pois aborda diferentes questões, tais como denição do SLA, técnicas de monitoramento e penalidades. O SLADB combina diferentes técnicas de monitoramento, permitindo a melhoria dos serviços de banco de dados em nuvem. 2.1 Especicação SLAs devem reetir o valor econômico, as exigências de serviço do usuário, descrever as condições comuns de negócios, tais como métricas de avaliação, contabilidade e questões jurídicas, prazos de contrato, bem como aspectos técnicos de desempenho e disponibilidade [Malkowski et al. 2010]. Este trabalho trata apenas de aspectos técnicos relacionados a estas métricas e sua avaliação. As propostas para SLAs apresentam muitas diferenças, mas é possível identicar uma estrutura geral para o SLA: informações sobre as partes envolvidas, parâmetros do SLA, métricas utilizadas para calcular os parâmetros do SLA, algoritmo para calcular os parâmetros do SLA, objetivo de nível de serviço (SLO) e ações a serem tomadas em caso de violação do acordo [Schnjakin et al. 2010]. Este trabalho propõe a seguinte denição: Denição 1.1: Um SLA para Serviço de Banco de Dados em Nuvem é composto por informações das partes envolvidas, métricas do SLA, SLOs, algoritmos para calcular as métricas do SLA e penalidades. Informações sobre as partes envolvidas referem-se ao contrato entre o provedor e o cliente. As métricas do SLA estão relacionadas aos itens a serem monitorados (ex. tempo de resposta e vazão) e o SLO contém os limites pré-denidos para o parâmetro (ex. tempo de reposta menor do que 5 ms). Para cada parâmetro é denido uma forma de calculá-lo (ex. tempo médio) e penalidades referentes a ações em caso de não conformidade dos SLOs (ex. multa). De acordo com [Chi et al. 2011], as métricas de SLA para serviços de banco de dados em nuvem devem otimizar o sistema, tratar aspectos relevantes para o gerenciamento de dados e contemplar 156

3 SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem as características do modelo de computação em nuvem. O SLADB utiliza as métricas de tempo de resposta, vazão, disponibilidade e consistência O SLADB dene estas métricas como fundamentais para o gerenciamento de serviços de banco de dados em nuvem. Entretanto, é importante ressaltar que o provedor de serviço pode optar por fornecer apenas algumas destas métricas no seu SLA, visto que existem métricas relacionadas, por exemplo, tempo de resposta e vazão. Para cada métrica, está associado um SLO, conforme destacado abaixo. Tempo de reposta: o tempo de resposta máximo, em segundos, para cada consulta, durante um período de tempo t. Vazão: o rendimento mínimo, em transações por segundo, durante um período de tempo t. Disponibilidade: a fração máxima de consultas rejeitadas ao longo de um período de tempo t. Consistência: o acesso a dados atualizados de acordo com o tipo de consistência: forte ou fraca. No SLADB, o SLA é orientado ao lucro. O SLA orientado ao lucro apresenta um funcionamento conável dos sistemas, pois o provedor está motivado para prestar o serviço com uma qualidade elevada. Nos casos onde o provedor não é capaz de atender o SLA, este é incentivado a continuar a prestar o serviço até obter o lucro. Para denir o lucro, o SLA considera três parâmetros: receita, custo e penalidades. A receita ou preço é o valor pago pelo cliente ao provedor para cumprir um SLA S i de um determinado serviço. O custo operacional são os gastos do provedor para a execução de um serviço com um SLA S i especicado, por exemplo, o custo com a infraestrutura. Dessa forma, o lucro consiste na receita obtida menos o custo mais as somas de todas as penalidades, conforme mostra a fórmula a seguir. Lucro = Receita (Custo + P enalidades) (1) A penalidade ou multa é o valor pago pelo provedor ao cliente, se o SLA S i não é cumprido. Por exemplo, no Google AppEngine 2, Microsoft Azure 3 ou Amazon S3 4, se a disponibilidade car abaixo de 99,9%, em seguida, os clientes recebem um crédito no serviço de acordo com a qualidade do serviço e proporcional a receita. Da mesma forma, o tempo de resposta é fundamental para garantir a qualidade do serviço e pode incorrer em penalidades em alguns modelos de serviços [Xiong et al. 2011]. No SLADB, a penalidade é a razão entre a soma de todas as consultas violadas pelo total de consultas multiplicado pela receita do sistema, de acordo com a fórmula abaixo. P enalidades = consultas_violadas consulta Receita (2) Com isso, pode-se denir uma função de satisfação para o SLA, conforme apresentado abaixo. A função é atendida, caso o SLA S i seja satisfeito, ou seja, todos os SLOs do SLA S i sejam satisfeitos e, não é atendida, caso contrário. { 1 se SLA Si é satisfeito F SS(Si) = (3) 0 se SLA Si é violado 2.2 Monitoramento das métricas do SLA Do ponto de vista do usuário, um serviço de banco de dados executa bem se os requisitos de desempenho e disponibilidade que o usuário se preocupa são cumpridos. Um primeiro ponto é traduzir os

4 132-4 F.R.C Sousa, L. O. Moreira e J. C. Machado requisitos de desempenho denidos pelo usuário em um conjunto comum de métricas que podem ser obtidos por meio do monitoramento. Exemplos de tais métricas incluem o tempo de resposta e vazão. O tempo de resposta médio é uma das formas mais comuns para vericar a qualidade do serviço. Contudo, em muitos contextos, é importante estabelecer metas mais gerais para o QoS [Schroeder et al. 2006], tais como o percentil, onde x% dos tempos de resposta são inferiores a um valor y. O percentil é solicitado pelos usuários como componente de um SLA, por exemplo, para garantir que pelo menos 90% das transações dos clientes tenha um tempo de resposta abaixo de um limite especi- cado [Entrialgo et al. 2011]. Para cada métrica do SLA, pode-se utilizar um algoritmo para calcular as métricas do SLA. O SLADB utiliza a seguinte estratégia: Tempo de reposta: percentil x% dos tempos de resposta inferiores a um valor y durante um período de tempo t. Vazão: percentil z% de vazão maiores a um valor k durante um período de tempo t. Disponibilidade: função atendido/não-atendido de acordo com a fórmula MTTF/(MTTF + MTTR), onde MTTF - Mean Time Between Fail e MTTR - Mean Time To Repair. Consistência: função atendido/não-atendido. O SLADB utiliza o intervalo de tempo de uma hora para vericar as penalidades do SLA, visto que este valor é utilizado pela maioria dos provedores para a tarifação de recursos. Para denir os limites de monitoramento, o SLADB adota estados para o SLA, conforme mostra a Figura 1. Fig. 1. Estados do SLA. Baixo: O SLA é menor do que o denido pelo cliente. Neste estado, recursos podem ser removidos do sistema. Denido: O nível denido é dividido em ideal e tolerável. Na faixa ideal, o SLA é mantido dentro um intervalo aceitável. Na faixa tolerável, o sistema intensica o monitoramento de forma a denir a adição de recursos. Falha: Neste nível, ocorreu uma falha em relação ao SLA. Neste caso, o provedor é penalizado de acordo com a quantidade de consultas no nível de falha e novos recursos devem ser adicionadas rapidamente para retornar ao nível denido. Devido à sua representatividade, o tempo de resposta e a vazão são métricas de desempenho de alto nível que precisam ser obtidas e analisadas. Os valores dessas métricas são dependentes do estado do SGBD. Quando este não está sobrecarregado, os valores são quase constantes. Entretanto, quando o SGBD está sobrecarregado, os valores crescem linearmente e depois, exponencialmente. Assim sendo, é necessário ter mecanismos ecazes para detectar a aumento ou diminuição destes valores [Malkowski et al. 2010]. Existem vários métodos para avaliar o desempenho de serviços em nuvem. Contudo, a natureza aleatória da demanda do usuário e as mudanças constantes na carga de trabalho ao longo do tempo tornam muito difíceis o planejamento de capacidade em um curto período de tempo. Isso ocasiona alguns problemas: (i) a carga de trabalho muda constantemente, implicando na atualização contínua da conguração do sistema e este cará sobrecarregado devido à execução dos procedimentos de adição e remoção de recursos; (ii) a quantidade e a precisão de dados coletados deve reetir o estado 158

5 SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem atual do sistema. O tempo de resposta e vazão do serviço podem variar muito em curtos períodos de tempo e é necessário ltrar essa variabilidade para obter um padrão regular e evitar adição ou remoção de recursos. O SLADB combina diferentes técnicas de monitoramento para tratar essa variabilidade. O monitoramento não pode ser realizado com intervalos muito curtos ou grandes de tempo. Dessa forma, a coleta é realizada seis vezes com o intervalo de 10 segundos. Para cada coleta, o SLADB calcula a mediana e desvio-padrão. As três medianas com menor desvio são selecionadas para obter os valores nais a serem armazenados. Com estes valores, aplica-se uma média ponderada exponencial X t = α X t + (1 - α) X t 1, onde α é o fator de ponderação (0 α 1). Nesta média, os valores mais recentes têm maior peso, como peso declinando exponencialmente à medida que esses valores se tornam ultrapassados. O fator de ponderação pode ser determinado experimentalmente, utilizando uma combinação de benchmarks com cargas articiais e aplicações com cargas reais. 3. ARQUITETURA DO SISTEMA E IMPLEMENTAÇÃO Para fornecer qualidade do serviço m-a-m para serviços web, é essencial incorporar todos os componentes da arquitetura web, ou seja, servidor web, servidor de aplicação e camada de banco de dados. O SLADB foi projetado para facilitar futuras extensões de qualidade do serviço para toda a arquitetura web. Por isso, todas as características do SLA e monitoramento estão agrupados em um coordenador. Assim, este coordenador pode ser facilmente estendido para monitorar a execução global de serviço web e não apenas na camada de banco de dados. A arquitetura do SLADB é dividida em duas partes: Agente e Coordenador. O Coordenador é composto por dois serviços: Monitoramento e SLA. O Agente é um componente presente em cada VM e é responsável por interagir com a VM e o SGBD. Especicamente, este agente coleta, monitora e interage com o SGBD, bem como verica o estado dos itens monitorados, por exemplo, se os mesmos estão operacionais ou indisponíveis. Uma visão geral da arquitetura do SLADB pode ser observada na Figura 2. Fig. 2. Arquitetura do SLADB. O Serviço de Monitoramento gerencia as informações coletadas pelo Agente. Este serviço monitora informações sobre cada VM e SGBD. Essas informações são armazenadas em um catálogo e utilizadas para denir a adição ou remoção de recursos e ajustes no SGBD de forma a garantir a qualidade do serviço. Para cada SGBD são monitorados as informações sobre os recursos de CPU, memória e tamanho das bases de dados utilizadas, assim como as métricas do SLA. O Serviço de SLA contém informações sobre o acordo de nível de serviço acertado entre o usuário e o provedor do serviço. Este serviço fornece métricas para o Serviço de Monitoramento vericar os valores denidos. As métricas do SLA são calculadas diretamente no provedor de serviço, pois seria complexo realizar medições no cliente em virtude das variações na qualidade da conexão. Contudo, muitos provedores de Internet fornecem soluções para melhorar a qualidade da conexão, por exemplo, Virtual Private Network(VPN), que podem ajudar na qualidade geral do serviço. 159

6 132-6 F.R.C Sousa, L. O. Moreira e J. C. Machado Em relação a denição dos SLAs, estes são normalmente escritos em uma linguagem natural e de forma simples. Entretanto, para permitir processamento e automação é necessária a utilização de uma linguagem formal que seja exível para expressar as necessidades dos clientes e informações dos provedores. Existem algumas linguagens para denir SLA, principalmente para serviços web, tais como WSLA, WSOL ou SLAang [Schnjakin et al. 2010]. O SLADB utiliza uma versão simplicada da linguagem WSLA para lidar com a gestão dos SLAs. A linguagem WSLA consiste de uma linguagem extensível baseada em XML Schema e permite SLAs individuais e personalizados. 4. AVALIAÇÃO A avaliação de serviços de banco de dados em nuvem apresenta diferenças signicativas em relação aos sistemas atuais que utilizam provisionamento estático. Sistemas com provisionamento estático pressupõem a existência de congurações xas de recursos e tem como objetivo maximizarem o desempenho ou disponibilidade. Essa visão não considera os custos operacionais do sistema. Entretanto, o modelo de pagamento baseado no uso da computação em nuvem requer que custos operacionais sejam considerados juntamente com o desempenho. No ambiente em nuvem, o objetivo é minimizar ou ajustar a quantidade de recursos necessários para garantir a qualidade do serviço. A diversidade de sistemas em nuvem e a forma como estes sistemas são construídos (ex. modelo de dados, níveis de consistência, linguagem de acesso) diculta o desenvolvimento de um benchmark padrão. Existem alguns benchmarks para avaliar SGBDs executados em nuvem. Contudo, cada benchmark elenca um conjunto de pressupostos próprios, o que diculta sua utilização. Mais detalhes sobre a avaliação de serviços de banco de dados em nuvem podem ser obtidos em [Sousa et al. 2010]. 4.1 Ambiente Para estes experimentos foi utilizado o provedor Amazon [Amazon 2011] com três máquinas virtuais do tipo small. Cada máquina possui o sistema operacional Ubuntu e duas máquinas possuem o SGBD MySQL 5.5. A outra máquina possui um benchmark com o objetivo de gerar a carga de trabalho a ser executada pelo SLADB. Este benchmark foi desenvolvido baseado no BenchmarkSQL [BSQL 2011], uma implementação em Java do TPC-C [TPC 2011]. Este benchmark diferencia-se do TPC-C em dois aspectos: (a) adição e remoção de clientes em tempo de execução, o que permite avaliar a elasticidade e qualidade do serviço e (b) distribuição da carga de trabalho entre as máquinas, possibilitando a avaliação de um ambiente distribuído. O benchmark permite gerar as transações de acordo com os parâmetros denidos, enviar para o SLADB e coletar os resultados ao nal da cada execução. A concorrência de transações é simulada usando múltiplos clientes. 4.2 Experimentos Para avaliar o SLADB, foram executados experimentos para vericar a conformidade da abordagem proposta, incluindo questões de penalidades. Os seguintes valores dos parâmetros do SLA foram denidos: tempo de reposta menor que 0.5 segundos, disponibilidade 99,9%, consistência forte e percentil do tempo de resposta em 90%. Como o tempo de resposta foi utilizado como métrica de desempenho, optou-se por não utilizar a vazão neste experimento. De acordo com o benchmark TPC- C, foi gerada uma base de dados com aproximadamente 500 MB e 6 numwarehouses, que permite conectar até 60 clientes. Para implementar a qualidade do serviço, nos casos de falha do SLA, foi realizada a adição de novos recursos ao sistema. Neste caso, utilizou-se uma máquina virtual com uma réplica total do banco de dados. Com isso, é possível dividir a carga de trabalho entre as máquinas e garantir a qualidade. Para analisar a execução do SLADB, foi realizado um experimento variando o número de clientes ao longo de um intervalo de tempo. O experimento consistiu em executar o sistema com 30 clientes por um período de 20 minutos, depois com 60 clientes por 20 minutos. Por m, o sistema é executado 160

7 SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem novamente com 30 clientes pelo mesmo período, totalizando 60 minutos. A Figura 3 apresenta a variação da métrica de tempo de resposta do SLA. Fig. 3. Gráco da Métrica de Tempo de Resposta do SLA. A Figura 3 (a) mostra o resultado da avaliação com provisionamento estático. Inicialmente, o SLA ca no estado denido. O tempo de resposta do SLA aumenta após os 20 primeiros minutos, pois foram adicionados novos clientes neste momento. Isso altera o tempo de resposta e o SLA passa para o estado de falha, ocasionando em penalidades para o provedor do serviço até a diminuição da quantidade de clientes, que ocorre após os 20 minutos seguintes. A Figura 3 (b) mostra o resultado com o provisionamento dinâmico utilizando o SLADB. De forma similar a Figura 3 (a), o SLA ca no estado denido. Com a adição de clientes, o tempo do SLA aumenta e o SLA passa para o estado de falha. Entretanto, o SLADB identica essa alteração e adiciona uma nova máquina com uma réplica do banco de dados, que pode receber parte das requisições dos clientes. Com isso, o sistema retornar para o estado denido, evitando novas penalidades. As métricas de disponibilidade e consistência foram atendidos. Considere um exemplo com custos reais de um provedor de um serviço de banco de dados em nuvem, neste caso, o Xeround 5. O Xeround tem um custo aproximado de k dólares por hora de utilização da infraestrutura da Amazon e recebe dos seus clientes uma receita de 4*k dólares por hora de utilização. No experimento apresentado, supondo que o provedor Xeround adotasse a abordagem do SLADB para garantir a qualidade do serviço, seria melhor adicionar uma nova máquina com um banco de dados, aumentando o custo em k dólares. Considerando que a abordagem do SLADB não fosse adotada, o Xeround deveria pagar a penalidade de (2/3) *4*k (i.e. corresponde a 2/3 das consultas que violaram o SLA multiplicado pela receita). 5. TRABALHOS RELACIONADOS Em [Yang et al. 2009] é apresentado uma plataforma que utiliza a denição de SLA para banco de dados considerando vazão e disponibilidade. Contudo, este trabalho não mostra como calcular as métricas do SLA nem as penalidades em caso de falhas. [Balazinska et al. 2011] discutem diferentes modelos de preço para serviços de dados em nuvem, mas não apresentam denições de SLA. Em [Zhu et al. 2011] é apresentada uma abordagem para escalonamento com o objetivo de fornecer qualidade do serviço. São apresentados um modelo de qualidade e SLA para sistemas de banco de dados que utilizam o modelo chave/valor, incluindo penalidades. Este trabalho foca em políticas de escalonamento, não trata questões de lucro e pode ser utilizado apenas em abordagens que utilizam a abordagem chave/valor. [Chi et al. 2011] propõem um framework para apoiar a tomada de decisão orientada ao lucro. Este framework utiliza uma nova estrutura de dados denominada SLA-tree com o objetivo de apoiar as

8 132-8 F.R.C Sousa, L. O. Moreira e J. C. Machado decisões em serviços de banco de dados em nuvem, tais como escalonamento e planejamento de capacidade. O SLA é denido para cada consulta do sistema. A utilização de SLA por consulta torna sua utilização complexa, pois o usuário necessita conhecer previamente todas as consultas para denir o SLA. Além disso, essa abordagem utiliza como métrica apenas o tempo de reposta e não considera penalidades. Em [Xiong et al. 2011] é apresentado o SmartSLA, um sistema de gerenciamento inteligente de recursos, que considera fatores de custo, carga de trabalho e custo da infraestrutura. Este trabalho dene um SLA por consulta e penalidades em caso de falhas. De forma similar ao trabalho [Chi et al. 2011], a utilização do SLA por consulta torna sua utilização complexa e apenas a métrica de tempo de reposta é considerada. 6. CONCLUSÃO Este trabalho apresentou o SLADB, uma abordagem de SLA para serviços de banco de dados em nuvem. Esta abordagem é orientada ao lucro e contempla diferentes aspectos, tais como tempo de resposta, vazão, disponibilidade e consistência. Avaliou-se o SLADB considerando características de qualidade do serviço. Pela análise dos resultados obtidos, foi possível vericar que o SLADB contempla as características de um serviço de banco de dados em nuvem e pode ser utilizado por provedores para melhor a qualidade dos serviços. Como trabalhos futuros pretende-se realizar novos experimentos considerando novos cenários para avaliar melhor o SLADB. Em seguida, pretende-se estudar novas estratégias de monitoramento, penalidades e modelos de custo a serem adicionados a este trabalho. Agradecimentos Este trabalho é suportado parcialmente pela Amazon Web Services Research Grant. REFERENCES Abadi, D. J. Data management in the cloud: Limitations and opportunities. IEEE Data Eng. Bull. vol. 32, pp. 312, Amazon. Amazon AWS, Balazinska, M., Howe, B.,, and Suciu, D. Data markets in the cloud: An opportunity for the database community. PVLDB, BSQL. BenchmarkSQL, Chi, Y., Moon, H. J., Hacigümü³, H., and Tatemura, J. Sla-tree: a framework for eciently supporting sla-based decisions in cloud computing. In EDBT '11. ACM, New York, NY, USA, pp , Entrialgo, J., García, D. F., García, J., García, M., Valledor, P., and Obaidat, M. S. Dynamic adaptation of response-time models for qos management in autonomic systems. J. Syst. Softw. vol. 84, pp , May, Fito, J. O., Presa, I. G., and Guitart, J. Sla-driven elastic cloud hosting provider. PDP, Euromicro'10 vol. 0, pp , LSCR. SLA for database projects, Malkowski, S., Hedwig, M., Jayasinghe, D., Pu, C., and Neumann, D. Cloudxplor: a tool for conguration planning in clouds based on empirical data. In SAC '10. ACM, New York, NY, USA, pp , Schad, J., Dittrich, J., and Quiané-Ruiz, J.-A. Runtime measurements in the cloud: Observing, analyzing, and reducing variance. PVLDB 3 (1): , Schnjakin, M., Alnemr, R., and Meinel, C. Contract-based cloud architecture. In CloudDB '10. ACM, New York, NY, USA, pp. 3340, Schroeder, B., Harchol-Balter, M., Iyengar, A., and Nahum, E. Achieving class-based qos for transactional workloads. In ICDE '06. IEEE Computer Society, Washington, DC, USA, pp. 153, Sousa, F. R. C., Moreira, L. O., Macêdo, J. A. F., and Machado, J. C. Gerenciamento de dados em nuvem: Conceitos, sistemas e desaos. In SBBD'10. SBC, Belo Horizonte, pp , TPC. Transaction Processing Performance Council, Xiong, P., Chi, Y., Zhu, S., Moon, H. J., Pu, C., and Hacigümüs, H. Intelligent management of virtualized resources for database systems in cloud environment. In ICDE'11. pp. 8798, Yang, F., Shanmugasundaram, J., and Yerneni, R. A scalable data platform for a large number of small applications. In CIDR pp. 110, Zhu, Y., Sharaf, M., and ZhouWelsh, X. Scheduling with freshness and performance guarantees for web applications in the cloud. In ADC,