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 sobdemanda com pagamento baseado no uso. Neste ambiente, a qualidade do serviço é uma característica fundamental quedeve 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õeo SLADB, uma abordagem de SLA para serviços de banco de dados em nuvem. Esta abordagem auxilia os provedoresna implementação da qualidade do serviço de banco de dados e contempla diferentes aspectos, tais como tempo deresposta, vazão, disponibilidade e consistência. Visando avaliar o SLADB, alguns experimentos que medem a qualidadedo 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çosde Tecnologia da Informação (TI) sob demanda com pagamento baseado no uso. Sistemas de geren-ciamento 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 grandequantidade de dados, ocasionando um custo elevado, tanto em hardware quanto em software. Paramuitas empresas, especialmente para startups e médias empresas, o pagamento baseado no uso domodelo de computação em nuvem, juntamente com o suporte para manutenção do hardware é muitoatraente [Abadi 2009]. Na nuvem, o usuário do serviço tem algumas garantias, tais como desempenhoe disponibilidade. Essas garantias de qualidade do serviço (QoS) são de�nidas entre o provedor doserviç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 especi�cam um nível de qualidade que deve ser atendido epenalidades em caso de falha.

Muitas empresas dependem de SLA, por exemplo, para exibir uma página web dentro de um deter-minado intervalo de tempo. Essas empresas esperam que os provedores de nuvem forneçam garantiasde qualidade utilizando SLAs com base em características de desempenho. Contudo, em geral, osprovedores baseiam seus SLAs apenas na disponibilidade dos serviços oferecidos, ao passo que osserviços em nuvem apresentam uma variabilidade de desempenho bastante elevada. Portanto, é essen-cial 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 aoSGBD (em vez do servidor web ou servidor de aplicação). Dessa forma, é importante que a qualidadeseja aplicada no SGBD para controlar o tempo de processamento [Schroeder et al. 2006].

1SGBD refere-se um uma classe geral de armazenamento de dados, incluindo sistemas não-relacionais.

SBBD - Simpósio Brasileiro de Banco de Dados

155

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], [Malkowskiet al. 2010] [Schnjakin et al. 2010]. Entretanto, estes modelos são muito gerais e não tratam car-acterísticas do gerenciamento de dados em nuvem. Modelos para SLAs e qualidade especí�cos paraserviços de banco de dados propõem soluções neste contexto [LSCR 2011] [Yang et al. 2009] [Xionget al. 2011] [Chi et al. 2011]. Contudo, estes modelos não contemplam alguns aspectos do gerencia-mento de dados em nuvem, tais como métricas especí�cas para serviços de banco de dados em nuveme propõem apenas parte de uma solução para qualidade, por exemplo, a de�nição de um SLA ouabordagens para penalidades. Além disso, estes trabalhos não utilizam técnicas e�cazes de monitora-mento especí�cas para SGBDs, fundamentais para tratar a elasticidade do ambiente de computaçãoem nuvem. De acordo com nosso estudo, não existem soluções que abordem este problema, enquantotrabalhos 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çosde banco de dados em nuvem. Esta abordagem auxilia os provedores na implementação da qualidadedo 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 qualidadedo 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ção3. Alguns experimentos que avaliam a qualidade do serviço são apresentados na seção 4. A seção 5comenta 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 abordagemcontempla diferentes aspectos do gerenciamento de dados e é orientada ao lucro, o que faz o provedorfornecer um serviço com qualidade. O SLADB é uma solução completa para auxiliar a qualidade doserviço, pois aborda diferentes questões, tais como de�nição do SLA, técnicas de monitoramento epenalidades. O SLADB combina diferentes técnicas de monitoramento, permitindo a melhoria dosserviços de banco de dados em nuvem.

2.1 Especi�cação

SLAs devem re�etir o valor econômico, as exigências de serviço do usuário, descrever as condiçõescomuns de negócios, tais como métricas de avaliação, contabilidade e questões jurídicas, prazos decontrato, bem como aspectos técnicos de desempenho e disponibilidade [Malkowski et al. 2010]. Estetrabalho trata apenas de aspectos técnicos relacionados a estas métricas e sua avaliação. As propostaspara SLAs apresentam muitas diferenças, mas é possível identi�car uma estrutura geral para o SLA:informações sobre as partes envolvidas, parâmetros do SLA, métricas utilizadas para calcular osparâ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 trabalhopropõe a seguinte de�nição:

De�niçã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 penal-

idades.

Informações sobre as partes envolvidas referem-se ao contrato entre o provedor e o cliente. Asmétricas do SLA estão relacionadas aos itens a serem monitorados (ex. tempo de resposta e vazão) eo SLO contém os limites pré-de�nidos para o parâmetro (ex. tempo de reposta menor do que 5 ms).Para cada parâmetro é de�nido uma forma de calculá-lo (ex. tempo médio) e penalidades referentesa 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 nuvemdevem otimizar o sistema, tratar aspectos relevantes para o gerenciamento de dados e contemplar

SBBD - Simpósio Brasileiro de Banco de Dados

156

SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem · 132-3

as características do modelo de computação em nuvem. O SLADB utiliza as métricas de tempo deresposta, vazão, disponibilidade e consistência O SLADB de�ne estas métricas como fundamentaispara o gerenciamento de serviços de banco de dados em nuvem. Entretanto, é importante ressaltarque o provedor de serviço pode optar por fornecer apenas algumas destas métricas no seu SLA, vistoque 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 umperí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 funcionamentocon�ável dos sistemas, pois o provedor está motivado para prestar o serviço com uma qualidadeelevada. Nos casos onde o provedor não é capaz de atender o SLA, este é incentivado a continuar aprestar o serviço até obter o lucro. Para de�nir 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 SLASi de um determinado serviço. O custo operacional são os gastos do provedor para a execução de umserviço com um SLA Si especi�cado, por exemplo, o custo com a infraestrutura. Dessa forma, o lucroconsiste na receita obtida menos o custo mais as somas de todas as penalidades, conforme mostra afórmula a seguir.

Lucro = Receita− (Custo+ Penalidades) (1)

A penalidade ou multa é o valor pago pelo provedor ao cliente, se o SLA Si não é cumprido. Porexemplo, no Google AppEngine 2, Microsoft Azure 3 ou Amazon S3 4, se a disponibilidade �carabaixo de 99,9%, em seguida, os clientes recebem um crédito no serviço de acordo com a qualidade doserviço e proporcional a receita. Da mesma forma, o tempo de resposta é fundamental para garantira 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 deconsultas multiplicado pela receita do sistema, de acordo com a fórmula abaixo.

Penalidades =

∑consultas_violadas∑

consulta∗Receita (2)

Com isso, pode-se de�nir uma função de satisfação para o SLA, conforme apresentado abaixo. Afunção é atendida, caso o SLA Si seja satisfeito, ou seja, todos os SLOs do SLA Si sejam satisfeitose, não é atendida, caso contrário.

FSS(Si) =

{1 se SLA Si é satisfeito0 se SLA Si é violado

(3)

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 desem-penho e disponibilidade que o usuário se preocupa são cumpridos. Um primeiro ponto é traduzir os

2http://code.google.com/appengine/sla.html3http://www.microsoft.com/windowsazure/sla4http://aws.amazon.com/s3-sla/

SBBD - Simpósio Brasileiro de Banco de Dados

157

132-4 · F.R.C Sousa, L. O. Moreira e J. C. Machado

requisitos de desempenho de�nidos pelo usuário em um conjunto comum de métricas que podem serobtidos 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 veri�car a qualidade do serviço.Contudo, em muitos contextos, é importante estabelecer metas mais gerais para o QoS [Schroederet al. 2006], tais como o percentil, onde x% dos tempos de resposta são inferiores a um valor y. Opercentil é solicitado pelos usuários como componente de um SLA, por exemplo, para garantir quepelo 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 calcularas 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íodode 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 veri�car as penalidades do SLA, visto queeste valor é utilizado pela maioria dos provedores para a tarifação de recursos. Para de�nir os limitesde 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 de�nido pelo cliente. Neste estado, recursos podem ser removidosdo sistema.

�De�nido: O nível de�nido é dividido em ideal e tolerável. Na faixa ideal, o SLA é mantido dentroum intervalo aceitável. Na faixa tolerável, o sistema intensi�ca o monitoramento de forma a de�nira adição de recursos.

�Falha: Neste nível, ocorreu uma falha em relação ao SLA. Neste caso, o provedor é penalizado deacordo com a quantidade de consultas no nível de falha e novos recursos devem ser adicionadasrapidamente para retornar ao nível de�nido.

Devido à sua representatividade, o tempo de resposta e a vazão são métricas de desempenho de altonível que precisam ser obtidas e analisadas. Os valores dessas métricas são dependentes do estado doSGBD. Quando este não está sobrecarregado, os valores são quase constantes. Entretanto, quando oSGBD está sobrecarregado, os valores crescem linearmente e depois, exponencialmente. Assim sendo,é necessário ter mecanismos e�cazes para detectar a aumento ou diminuição destes valores [Malkowskiet al. 2010]. Existem vários métodos para avaliar o desempenho de serviços em nuvem. Contudo, anatureza aleatória da demanda do usuário e as mudanças constantes na carga de trabalho ao longodo tempo tornam muito difíceis o planejamento de capacidade em um curto período de tempo. Issoocasiona alguns problemas: (i) a carga de trabalho muda constantemente, implicando na atualizaçãocontínua da con�guração do sistema e este �cará sobrecarregado devido à execução dos procedimentosde adição e remoção de recursos; (ii) a quantidade e a precisão de dados coletados deve re�etir o estado

SBBD - Simpósio Brasileiro de Banco de Dados

158

SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem · 132-5

atual do sistema. O tempo de resposta e vazão do serviço podem variar muito em curtos períodosde tempo e é necessário �ltrar essa variabilidade para obter um padrão regular e evitar adição ouremoção de recursos.

O SLADB combina diferentes técnicas de monitoramento para tratar essa variabilidade. O moni-toramento não pode ser realizado com intervalos muito curtos ou grandes de tempo. Dessa forma, acoleta é realizada seis vezes com o intervalo de 10 segundos. Para cada coleta, o SLADB calcula amediana 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 =α Xt + (1 - α) X ′t−1, onde α é o fator de ponderação (0 ≤ α ≤ 1). Nesta média, os valores maisrecentes têm maior peso, como peso declinando exponencialmente à medida que esses valores se tor-nam ultrapassados. O fator de ponderação pode ser determinado experimentalmente, utilizando umacombinação de benchmarks com cargas arti�ciais 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 compo-nentes da arquitetura web, ou seja, servidor web, servidor de aplicação e camada de banco de dados. OSLADB foi projetado para facilitar futuras extensões de qualidade do serviço para toda a arquiteturaweb. 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çoweb 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 VMe é responsável por interagir com a VM e o SGBD. Especi�camente, este agente coleta, monitora einterage com o SGBD, bem como veri�ca o estado dos itens monitorados, por exemplo, se os mesmosestão operacionais ou indisponíveis. Uma visão geral da arquitetura do SLADB pode ser observadana Figura 2.

Fig. 2. Arquitetura do SLADB.

O Serviço de Monitoramento gerencia as informações coletadas pelo Agente. Este serviço monitorainformações sobre cada VM e SGBD. Essas informações são armazenadas em um catálogo e utilizadaspara de�nir a adição ou remoção de recursos e ajustes no SGBD de forma a garantir a qualidadedo serviço. Para cada SGBD são monitorados as informações sobre os recursos de CPU, memória etamanho das bases de dados utilizadas, assim como as métricas do SLA. O Serviço de SLA contéminformaçõ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 veri�car os valores de�nidos. Asmétricas do SLA são calculadas diretamente no provedor de serviço, pois seria complexo realizarmedições no cliente em virtude das variações na qualidade da conexão. Contudo, muitos provedoresde Internet fornecem soluções para melhorar a qualidade da conexão, por exemplo, Virtual PrivateNetwork(VPN), que podem ajudar na qualidade geral do serviço.

SBBD - Simpósio Brasileiro de Banco de Dados

159

132-6 · F.R.C Sousa, L. O. Moreira e J. C. Machado

Em relação a de�nição dos SLAs, estes são normalmente escritos em uma linguagem natural e deforma simples. Entretanto, para permitir processamento e automação é necessária a utilização deuma linguagem formal que seja �exível para expressar as necessidades dos clientes e informações dosprovedores. Existem algumas linguagens para de�nir SLA, principalmente para serviços web, taiscomo WSLA, WSOL ou SLAang [Schnjakin et al. 2010]. O SLADB utiliza uma versão simpli�cada dalinguagem WSLA para lidar com a gestão dos SLAs. A linguagem WSLA consiste de uma linguagemextensí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 signi�cativas em relaçãoaos sistemas atuais que utilizam provisionamento estático. Sistemas com provisionamento estáticopressupõem a existência de con�gurações �xas de recursos e tem como objetivo maximizarem o de-sempenho 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 se-jam considerados juntamente com o desempenho. No ambiente em nuvem, o objetivo é minimizarou ajustar a quantidade de recursos necessários para garantir a qualidade do serviço. A diversidadede sistemas em nuvem e a forma como estes sistemas são construídos (ex. modelo de dados, níveisde consistência, linguagem de acesso) di�culta o desenvolvimento de um benchmark padrão. Existemalguns benchmarks para avaliar SGBDs executados em nuvem. Contudo, cada benchmark elenca umconjunto de pressupostos próprios, o que di�culta sua utilização. Mais detalhes sobre a avaliação deserviç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 virtuaisdo tipo small. Cada máquina possui o sistema operacional Ubuntu 10.04 e duas máquinas possuemo SGBD MySQL 5.5. A outra máquina possui um benchmark com o objetivo de gerar a carga detrabalho 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 doTPC-C em dois aspectos: (a) adição e remoção de clientes em tempo de execução, o que permiteavaliar 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 deacordo com os parâmetros de�nidos, enviar para o SLADB e coletar os resultados ao �nal da cadaexecução. A concorrência de transações é simulada usando múltiplos clientes.

4.2 Experimentos

Para avaliar o SLADB, foram executados experimentos para veri�car a conformidade da abordagemproposta, incluindo questões de penalidades. Os seguintes valores dos parâmetros do SLA foramde�nidos: tempo de reposta menor que 0.5 segundos, disponibilidade 99,9%, consistência forte epercentil do tempo de resposta em 90%. Como o tempo de resposta foi utilizado como métrica dedesempenho, 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 permiteconectar até 60 clientes. Para implementar a qualidade do serviço, nos casos de falha do SLA, foirealizada a adição de novos recursos ao sistema. Neste caso, utilizou-se uma máquina virtual com umaréplica total do banco de dados. Com isso, é possível dividir a carga de trabalho entre as máquinas egarantir a qualidade.

Para analisar a execução do SLADB, foi realizado um experimento variando o número de clientesao longo de um intervalo de tempo. O experimento consistiu em executar o sistema com 30 clientespor um período de 20 minutos, depois com 60 clientes por 20 minutos. Por �m, o sistema é executado

SBBD - Simpósio Brasileiro de Banco de Dados

160

SLADB: Acordo de Nível de Serviço para Banco de Dados em Nuvem · 132-7

novamente com 30 clientes pelo mesmo período, totalizando 60 minutos. A Figura 3 apresenta avariaçã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 de�nido. O tempo de resposta do SLA aumenta após os 20 primeiros minutos, poisforam adicionados novos clientes neste momento. Isso altera o tempo de resposta e o SLA passapara o estado de falha, ocasionando em penalidades para o provedor do serviço até a diminuição daquantidade de clientes, que ocorre após os 20 minutos seguintes. A Figura 3 (b) mostra o resultadocom o provisionamento dinâmico utilizando o SLADB. De forma similar a Figura 3 (a), o SLA �ca noestado de�nido. Com a adição de clientes, o tempo do SLA aumenta e o SLA passa para o estado defalha. Entretanto, o SLADB identi�ca essa alteração e adiciona uma nova máquina com uma réplicado banco de dados, que pode receber parte das requisições dos clientes. Com isso, o sistema retornarpara o estado de�nido, evitando novas penalidades. As métricas de disponibilidade e consistênciaforam 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 dainfraestrutura 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 paragarantir 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, oXeround deveria pagar a penalidade de (2/3) *4*k (i.e. corresponde a 2/3 das consultas que violaramo SLA multiplicado pela receita).

5. TRABALHOS RELACIONADOS

Em [Yang et al. 2009] é apresentado uma plataforma que utiliza a de�nição de SLA para banco de dadosconsiderando vazão e disponibilidade. Contudo, este trabalho não mostra como calcular as métricasdo SLA nem as penalidades em caso de falhas. [Balazinska et al. 2011] discutem diferentes modelos depreço para serviços de dados em nuvem, mas não apresentam de�nições de SLA. Em [Zhu et al. 2011] éapresentada uma abordagem para escalonamento com o objetivo de fornecer qualidade do serviço. Sãoapresentados um modelo de qualidade e SLA para sistemas de banco de dados que utilizam o modelochave/valor, incluindo penalidades. Este trabalho foca em políticas de escalonamento, não trataquestõ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. Esteframework utiliza uma nova estrutura de dados denominada SLA-tree com o objetivo de apoiar as

5http://www.xeround.com

SBBD - Simpósio Brasileiro de Banco de Dados

161

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 ca-pacidade. O SLA é de�nido para cada consulta do sistema. A utilização de SLA por consulta tornasua utilização complexa, pois o usuário necessita conhecer previamente todas as consultas para de�niro SLA. Além disso, essa abordagem utiliza como métrica apenas o tempo de reposta e não considerapenalidades. Em [Xiong et al. 2011] é apresentado o SmartSLA, um sistema de gerenciamento in-teligente de recursos, que considera fatores de custo, carga de trabalho e custo da infraestrutura. Estetrabalho de�ne 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étricade tempo de reposta é considerada.

6. CONCLUSÃO

Este trabalho apresentou o SLADB, uma abordagem de SLA para serviços de banco de dados emnuvem. Esta abordagem é orientada ao lucro e contempla diferentes aspectos, tais como tempo deresposta, vazão, disponibilidade e consistência. Avaliou-se o SLADB considerando características dequalidade do serviço. Pela análise dos resultados obtidos, foi possível veri�car que o SLADB contem-pla as características de um serviço de banco de dados em nuvem e pode ser utilizado por provedorespara melhor a qualidade dos serviços. Como trabalhos futuros pretende-se realizar novos experimentosconsiderando novos cenários para avaliar melhor o SLADB. Em seguida, pretende-se estudar novasestraté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. 3�12,2009.

Amazon. Amazon AWS, 2011. http://aws.amazon.com.

Balazinska, M., Howe, B., , and Suciu, D. Data markets in the cloud: An opportunity for the database community.PVLDB , 2011.

BSQL. BenchmarkSQL, 2011. http://www.sourceforge.net/projects/benchmarksql.

Chi, Y., Moon, H. J., Hacigümü³, H., and Tatemura, J. Sla-tree: a framework for e�ciently supporting sla-baseddecisions in cloud computing. In EDBT '11. ACM, New York, NY, USA, pp. 129�140, 2011.

Entrialgo, J., García, D. F., García, J., García, M., Valledor, P., and Obaidat, M. S. Dynamic adaptationof response-time models for qos management in autonomic systems. J. Syst. Softw. vol. 84, pp. 810�820, May, 2011.

Fito, J. O., Presa, I. G., and Guitart, J. Sla-driven elastic cloud hosting provider. PDP, Euromicro'10 vol. 0,pp. 111�118, 2010.

LSCR. SLA for database projects, 2011. http://lscr.berkeley.edu/rates/sla/database.php.

Malkowski, S., Hedwig, M., Jayasinghe, D., Pu, C., and Neumann, D. Cloudxplor: a tool for con�gurationplanning in clouds based on empirical data. In SAC '10. ACM, New York, NY, USA, pp. 391�398, 2010.

Schad, J., Dittrich, J., and Quiané-Ruiz, J.-A. Runtime measurements in the cloud: Observing, analyzing, andreducing variance. PVLDB 3 (1): 460�471, 2010.

Schnjakin, M., Alnemr, R., and Meinel, C. Contract-based cloud architecture. In CloudDB '10. ACM, New York,NY, USA, pp. 33�40, 2010.

Schroeder, B., Harchol-Balter, M., Iyengar, A., and Nahum, E. Achieving class-based qos for transactionalworkloads. In ICDE '06. IEEE Computer Society, Washington, DC, USA, pp. 153�, 2006.

Sousa, F. R. C., Moreira, L. O., Macêdo, J. A. F., and Machado, J. C. Gerenciamento de dados em nuvem:Conceitos, sistemas e desa�os. In SBBD'10. SBC, Belo Horizonte, pp. 101�130, 2010.

TPC. Transaction Processing Performance Council, 2011. http://www.tpc.org/.

Xiong, P., Chi, Y., Zhu, S., Moon, H. J., Pu, C., and Hacigümüs, H. Intelligent management of virtualizedresources for database systems in cloud environment. In ICDE'11. pp. 87�98, 2011.

Yang, F., Shanmugasundaram, J., and Yerneni, R. A scalable data platform for a large number of small applica-tions. In CIDR 2009. pp. 1�10, 2009.

Zhu, Y., Sharaf, M., and ZhouWelsh, X. Scheduling with freshness and performance guarantees for web applica-tions in the cloud. In ADC, 2011.

SBBD - Simpósio Brasileiro de Banco de Dados

162