Carlos Sérgio da Silva Marinho

Prévia do material em texto

Um Projeto de Serviço de Balanceamento de Carga Preditivo
para Bancos de Dados Replicados em Nuvem
Carlos S. S. Marinho1,2, Emanuel F. Coutinho1, José S. Costa Filho2,
Leonardo O. Moreira1,2, Flávio R. C. Sousa2, Javam C. Machado2
1Instituto Universidade Virtual (UFC Virtual)
Universidade Federal do Ceará (UFC) – Fortaleza, CE – Brasil
2Laboratório de Sistemas e Banco de Dados (LSBD)
Universidade Federal do Ceará (UFC) – Fortaleza, CE – Brasil
sergio.marinho@lsbd.ufc.br, emanuel@virtual.ufc.br,
{serafim.costa,leonardo.moreira,flavio.sousa,javam.machado}@lsbd.ufc.br
Resumo. A computação em nuvem surge como uma alternativa para prover
qualidade de serviço em aplicações orientadas a dados. Os Sistemas de Ge-
renciamento de Banco de Dados devem dar suporte a aplicações em nuvem
que utilizam bancos de dados. Muitas soluções usam replicação como uma es-
tratégia para aumentar a disponibilidade e descentralizar a carga de trabalho.
Por meio da distribuição de transações recebidas entre réplicas, as técnicas de
balanceamento de carga melhoram a utilização de recursos computacionais. No
entanto, várias soluções usam o estado atual do serviço de banco de dados na
tomada de decisões de distribuição de carga. Este trabalho propõe um serviço
de balanceamento de carga preditivo para bancos de dados replicados em nu-
vem. Para validar o modelo preditivo proposto, um experimento foi feito em um
trabalho relacionado. Os resultados indicam que o uso de predição pode trazer
benefı́cios na distribuição da carga de trabalho, de maneira que favoreça o me-
lhor uso dos recursos computacionais disponı́veis, bem como evitar violações
de SLA. Além disso, uma ferramenta foi desenvolvida como prova de conceito
para mostrar a predição de forma gráfica.
1. Introdução
A computação em nuvem é um modelo que permite acesso a uma rede compartilhada,
conveniente e sob demanda a um pool de recursos computacionais compartilhados con-
figuráveis, como redes, servidores, armazenamento, sistemas e serviços. Esses recursos
podem ser rapidamente fornecidos e liberados com o mı́nimo esforço de gerenciamento
ou de interação com o provedor de serviços [Mell and Grance 2011]. A infra-estrutura
de computação em nuvem é tipicamente composta por um grande número de máquinas
fı́sicas, conectadas por meio de uma rede.
Em cada máquina fı́sica há uma quantidade de Máquinas Virtuais (VMs) que varia
de acordo com a capacidade de hardware disponı́vel na máquina fı́sica. Nessas VMs,
os serviços são executados e geralmente devem atender a um Service Level Agreement
(SLA), contratado pelos usuários. O SLA pode ser definido como uma obrigação que
o provedor da nuvem tem de fornecer aos usuários determinadas garantias de nı́veis de
Qualidade de Serviço (QoS), como desempenho e disponibilidade [Moreira et al. 2012].
Muitas aplicações em nuvem são orientadas a dados e, por isso, os Sistemas
de Gerenciamento de Banco de Dados (SGBDs) são potenciais candidatos para se-
rem utilizados em nuvens computacionais [Moreira et al. 2014]. Outros motivos são:
(i) em geral, as instalações de SGBDs são complexas e envolvem uma grande quan-
tidade de dados, causando altos custos de hardware e software [Moreira et al. 2012];
(ii) a maior parte do tempo gasto com processamento em sistemas orientados a dados
está relacionada ao processamento no SGBD [Sousa et al. 2012]. Várias soluções estão
sendo propostas para usar bancos de dados em nuvem com aspectos de qualidade de
serviço [Sousa and Machado 2012] [Moreira et al. 2014]. Algumas soluções que utili-
zam a replicação de banco de dados usam estratégias de balanceamento de carga para
distribuir cargas de trabalho entre as réplicas. No entanto, de acordo com a revisão sis-
temática do presente trabalho, as soluções encontradas não usam aspectos preditivos para
observar o impacto da carga de trabalho futura em relação ao uso de recursos computa-
cionais e às determinações do SLA. As palavras chave utilizadas nos repositórios ACM
Digital Library e IEEE Xplore Digital Library foram ”balanceamento de carga”, ”bancos
de dados replicados em nuvem”e ”predição de carga”.
A hipótese da presente pesquisa é que o uso de predição em soluções de balan-
ceamento de carga para bancos de dados replicados pode aproveitar melhor os recursos
computacionais em nuvem, considerando os aspectos de SLA. A partir dessa hipótese, o
objetivo principal é projetar um serviço de balanceamento de carga que use técnicas de
predição de carga de trabalho para bancos de dados replicados em nuvem. A fim de se
alcançar o objetivo principal, foram estabelecidos os seguintes objetivos especı́ficos: (i)
analisar técnicas de balanceamento de carga em bancos de dados replicados que podem
ser utilizadas em nuvens computacionais; (ii) estudar técnicas empregadas para prever
carga de trabalho em bancos de dados; (iii) avaliar se as técnicas de predição são efetivas
para observar o comportamento da desempenho dos bancos de dados replicados em nu-
vem; (iv) desenvolver uma prova de conceito que demonstre graficamente a predição de
carga.
2. Trabalhos Relacionados
Os seguintes critérios de busca foram utilizados para coletar os trabalhos relacionados:
(i) trabalhos que utilizam bancos de dados replicados em nuvem; (ii) trabalhos que ado-
taram, de alguma forma, balanceamento de carga entre as réplicas; e (iii) trabalhos que
utilizaram o modelo relacional como modelo de persistência. A Tabela 1 lista os traba-
lhos relacionados e destaca suas caracterı́sticas. Sousa e Machado (2012) desenvolveram
o RepliC, uma abordagem para replicação total de banco de dados relacional na nuvem.
Esse trabalho considera os aspectos de qualidade de serviço, elasticidade e modelo multi-
inquilino de SGBD compartilhado. De acordo com as necessidades impostas pela carga
de trabalho, há o ajuste do número de réplicas para cumprir o SLA. Para dividir a carga
de trabalho entre as réplicas, o RepliC implementa um balanceamento de carga com ca-
racterı́stica de fila circular (round-robin), distribuindo as transações uniformemente nas
réplicas existentes.
Moon et al. (2013) propuseram o SWAT, um middleware que promove balancea-
mento de carga para bancos de dados replicados em nuvem. O SWAT usa o mesmo mo-
delo multi-inquilino adotado pelo RepliC, o qual faz o compartilhamento do SGBD para
hospedar as réplicas nas VMs. A estratégia de balanceamento de carga implementada
pelo SWAT direciona a carga de trabalho para a réplica que possui maior disponibilidade
de recursos computacionais em um determinado momento. Embora busque uma melhor
gestão e uso eficiente de recursos existentes na nuvem, o SWAT não resolve problemas
relacionados a violações de SLA quando os recursos são escassos, pois não emprega pro-
visão ou elasticidade. Pippal et al. (2015) desenvolveram uma estratégia baseada em
replicação parcial, usando o modelo read-one-write-all. Esse modelo propõe que os pe-
didos de gravação sejam encaminhados para todas as réplicas e as solicitações de leitura
sejam apenas para o servidor que possui os recursos computacionais menos disponı́veis.
O uso de CPU foi considerado para a decisão de distribuição de requisições. Os experi-
mentos foram feitos no MySQL Server. Além disso, é necessário que o Administrador do
Banco de Dados configure quais tabelas devem ser replicadas juntas.
Tabela 1. Principais trabalhos relacionadas e suas caracterı́sticas
Trabalho Estratégia de Replicação Modelo de Persistência Técnicas de Predição
Sousa e Machado (2012) Total Relacional Não
Moon et al. (2013) Total Relacional Não
Pippal et al. (2015) Parcial Relacional Não
Presente Trabalho Total Relacional Sim
3. O Serviço de balanceamento de carga
O serviço de balanceamento de carga proposto no presente trabalho foi projetado como
um serviço a ser implantado no modelo arquitetural Quality of Service for Database in the
Cloud (QoSDBC)[Sousa et al. 2012]. O QoSDBC foi concebido com o intuito de forne-
cer uma solução de persistência para dados em bancos de dados relacionais com o modelo
multi-inquilino de SGBD compartilhado, de modo a abranger aspectos de distribuição de
dados e qualidade de serviço em nuvens computacionais. No modelo multi-inquilino
de SGBD compartilhado, diferentes bancos de dados de aplicativos podem comparti-
lhar o mesmo SGBD. Barker et al. (2012) discutem que este modelo multi-inquilino
expressa a melhor relação entre o uso de recursos do provedor, performance e segurança
. O QoSDBC foi projetado para ser uma arquitetura de sistema genérica, de modo que
possa ser instanciada para diferentes estratégias de qualidade em bancos de dados em
nuvem, de acordo com as necessidades informadas no SLA. Os trabalhos propostos por
[Moreira et al. 2014] e [Sousa and Machado 2012] utilizaram o QoSDBC para fornecer
qualidade de serviço em bancos de dados em nuvem por meio de, respectivamente, es-
tratégias de migração e replicação. Uma visão geral da arquitetura do sistema QoSDBC
pode ser vista na Figura 1.
O QoSDBCDriver é o componente que fornece acesso ao sistema, implementa
o padrão Java Database Connectivity (JDBC) e é utilizado em vez de um driver de um
SGBD especı́fico. Esse componente oferece a mesma interface de comunicação com o
SGBD, sem a necessidade de modificar o SGBD. O QoSDBCCoordinator consiste em um
conjunto de serviços que lidam com o gerenciamento de banco de dados. O Agent é um
componente adicionado em cada VM, responsável por coletar, monitorar e interagir com
as VMs e os SGBDs. O Monitoring Service administra as informações coletadas pelo
Agent, pois agrega informações sobre: processamento, memória principal e secundária de
cada VM; estado do SGBD; carga de trabalho; e estatı́sticas. Essas informações podem
ser usadas para definir a alocação de réplicas de bancos de dados nos SGBDs ou para pro-
visionar recursos a fim de garantir a qualidade do serviço, e são armazenadas no Catalog.
Clients
VM1
QoSDBCCoordinator
Scheduling
Service
SLA
Service
Balancing
Service
Provisioning
Service
Log
Catalog
Monitoring
Service
DBMS1
Agent
VM2
DBMS2
Agent
VMn
DBMSn
Agent...
Distributed Storage Service
QoSDBCDriver
Figura 1. O Modelo QoSDBC [Sousa et al. 2012]
As informações são atualizadas de modo contı́nuo, de maneira que os demais serviços
obtenham informações verossı́meis para o pleno funcionamento do sistema.
O SLA Service administra as informações de SLA definido entre o usuário e o pro-
vedor que possui a instalação QoSDBC. As informações estão relacionadas a definições
de SLA, como desempenho e consistência. Esse serviço fornece parâmetros ao Monito-
ring Service para verificar os valores definidos e ajustar os outros serviços. O Provisioning
Service usa informações de outros serviços para provisionar recursos de VM. O Schedu-
ling Service lista e seleciona os recursos provisionados. Para isso, o escalonador gerencia
as réplicas, garantindo o acesso ao SGBD durante e após o processo de replicação. A
base de dados Log armazena todas as transações, juntamente com seus detalhes, que fo-
ram executados nas réplicas do sistema. Finalmente, o Balancing Service implementa a
estratégia de distribuição de transações entre as réplicas do sistema. Para tal, o Scheduling
Service usa o Balancing Service para decidir qual réplica executar uma transação.
O serviço proposto no presente trabalho consiste em uma estratégia predi-
tiva que considera os dados de monitoramento gerenciados pelo Monitoring Service.
O modelo de predição adotado nesse trabalho é o AutoRegressive Integrated Mo-
ving Average (ARIMA), uma vez que os estudos realizados por [Santos et al. 2013] e
[Moreira et al. 2014] indicam que esse modelo apresenta bons resultados ao predizer car-
gas de trabalho em janelas de predição curta. O uso de janelas de predição curtas ajuda a
ajustar um ambiente altamente dinâmico, especialmente para evitar violações do SLA. Os
tempos médios de resposta dos bancos de dados são utilizados para inferência de valores
futuros. O serviço de balanceamento de carga proposto requer que três parâmetros sejam
configurados: (i) a frequência que o modelo de predição deve ser treinado e executado
para cada réplica dos esquemas do banco de dados; (ii) o tamanho da janela de previsão,
que é retornada para cada réplica dos esquemas do banco de dados; e (iii) o tamanho dos
dados de monitoramento que devem ser inseridos à medida que o treinamento do ARIMA
para cada réplica dos esquemas do banco de dados.
4. Avaliação
A avaliação visa verificar se técnicas de predição podem ser usadas para observar o
comportamento de bancos de dados replicados em nuvem, com base no tempo de res-
posta. Para isso, o RepliC [Sousa and Machado 2012] foi executado em um cenário com
replicação total de bancos de dados em nuvem. As justificativas para o uso do RepliC
Figura 2. O cenário do Experimento
são: (i) o serviço proposto no presente trabalho e o serviço de balanceamento de carga do
RepliC podem ser implementados na mesma arquitetura do sistema, o que possibilita fu-
turas comparações entre os trabalhos; (ii) ambos usam o mesmo modelo de persistência;
e (iii) os dois trabalhos usam a mesma estratégia de replicação.
O OLTPBenchmark [Difallah et al. 2013] foi usado para gerar cargas de trabalho
de banco de dados no ambiente experimental. Essa ferramenta é um framework para
avaliar o desempenho de diferentes SGBDs relacionais com configurações de carga de
trabalho On-line Transaction Processing (OLTP). O framework possui vários benchmarks
com diferentes esquemas de dados, como TPC-C, Twitter, YCSB e Wikipedia. O OLTP-
Benchmark permite que o usuário defina a taxa de tempo para envio de solicitações, além
da porcentagem de cada tipo de transação por tempo de experimento. Para os experi-
mentos realizados nesse trabalho, os valores percentuais foram mantidos os padrões de
cada benchmark. Como saı́das, a ferramenta possibilita a obtenção de informações de
throughput, tempo de resposta médio e informações sobre o uso de recursos do sistema
operacional [Moreira et al. 2012]. O Amazon EC2 foi o provedor adotado como o ambi-
ente de gerenciamento das VMs para a execução dos experimentos. Todas as Máquinas
Virtuais utilizadas nos experimentos possuem sistema operacional Ubuntu Server 16.04
LTS. O SGBD adotado foi o MySQL Server, versão 5.7 com engine InnoDB e buffer de
128 Megabytes. Foram criadas VMs do tipo t2.small para hospedar cada SGBD. Para
utilizar o QoSDBCCoordinator, uma VM do tipo c4.2xlarge foi escolhida. Responsáveis
por simular as cargas de trabalho para os banco de dados, cada instância de OLTPBench-
mark utilizou uma VM do tipo t2.small. Todas as VMs do experimento foram criadas na
mesma sub-rede (us-west-2b). A Figura 2 mostra o cenário de avaliação.
A avaliação almeja observar o desempenho do ARIMA quando aplicado a uma
carga de trabalho no RepliC. No experimento, foi usada uma VM t2.small para cada
SGBD. Foram criadas 8 VMs desse tipo, as quais possuem um SGBD com seis bancos de
0
10
20
30
40
50
60
70
80
0 5 10 15 20 25 30 35 40 45 50 55 60
R
e
sp
o
n
se
 T
im
e
 (m
ill
is
e
co
n
d
s)
Experiment Time (minutes)
Real Response Time and Forecasted Response Time
Real Response Time Forecasted Response Time
Figura 3. Tempo de resposta real e tempo de resposta inferido em uma instância
do YSCB
dados: dois do tipo TPC-C, dois com o esquema do YCSBs e dois do tipo Wikipédia. O
TPC-C é um benchmark de e-commerce, equanto o Wikipedia simula a enciclopédia co-
laborativa que possui o mesmo nome, e, por último, o YCSB é uma ferramenta genérica
feita por desenvolvedores da Yahoo para uso em nuvem. Inicialmente, cada banco de
dados possuı́a 500 Megabytes de tamanho, o que totalizam 3 Gigabytes por máquina. A
fim de se simular a carga de trabalho,foram criadas 8 VMs do tipo t2.small, cada uma
continha 6 instâncias de OLTPBenchmark. Cada instância do OLTPBenchmark envia
50 conexões para um banco de dados. Portanto, como cada instância do MySQL pos-
sui 6 bancos de dados, no total foram criadas 300 conexões para cada SGBD em cada
t2.small. No total, 48 bases de dados foram criadas e distribuı́das uniformemente em 8
t2.small VMs. A métrica SLA utilizada no experimento foi o tempo médio de resposta das
transações e o SLA adotado para o YCSB foi de 60ms. A taxa de transações por segundo
em YCSB, por conexão, foi definida seguindo a sequência: 250, 500, 750, 1000, 1000,
1000. Cada transição na sequência ocorreu a cada 10 minutos, compondo o tempo total
de experimento de uma hora. As taxas TPC-C e Wikipedia, por conexão, foram em 10 e
100 respectivamente. Apenas o YCSB teve variações em sua taxa, pois esse foi o modelo
observado no presente trabalho. O uso dos demais benchmarks foi feito com o propósito
de tornar o cenário experimental mais próximo de um cenário real, com várias aplicações
de diferentes finalidades que podem causar interferência nos tempos de resposta das de-
mais. Para o uso do ARIMA na carga de trabalho, um minuto foi inferido a partir de cada
quatro minutos lidos do sistema de monitoramento do RepliC. A implementação do mo-
delo ARIMA utilizada foi o auto.arima, disponı́vel na biblioteca forecast da linguagem
R, que é auto-parametrizável. A Figura 3 mostra o tempo de resposta médio da carga do
experimento e os pontos previstos pelo ARIMA em uma instância do YCSB.
No instante de 30 minutos, o RepliC detectou uma violação de SLA para o
YCSB. Com isso, uma nova VM t2.small foi provisionada para fornecer uma réplica
para o YCSB. Após a disponibilização de uma nova réplica para o YCSB, houve uma
distribuição de carga de trabalho entre as réplicas, o que ocasionou a diminuição do tempo
médio de resposta. A partir do gráfico mostrado na Figura 3, é possı́vel ver que os pon-
tos previstos estão próximos dos pontos reais. Além dos pontos plotados no gráfico e da
comparação entre as séries temporais, é viável utilizar outros modelos para demonstrar o
nı́vel de precisão da predição obtida com ARIMA. A partir das funções root-mean-square
error (RMSE) e Mean Absolute Percentage Error (MAPE) [Santos et al. 2013], foram
obtidos valores que revelam a proximidade da série real com o série prevista. Quanto
menores os valores para RMSE e MAPE, maior a precisão de predição. Os resultados
obtidos foram: RMSE = 4.925 e MAPE = 0.071. Esses valores indicam que o modelo de
predição se aproximou dos dados reais, o que reforça que o ARIMA pode ser usado para
predizer cargas de trabalho de bancos de dados replicados em nuvem.
4.1. Prova de Conceito
Como prova de conceito para demonstrar a predição de carga de forma visual, foi desen-
volvida a ferramenta CloudBViewer1. O software em questão se trata de um sistema Web
que visa a proporcionar ao gestor da infraestrutura uma compreensão simplista da carga
de trabalho dos bancos de dados disponı́veis e da infraestrutura. Essa compreensão pode
ser obtida sem a necessidade de esforços maiores, como a execução de algoritmos de
predição e a realização de consultas aos bancos de dados do QoSDBC, os quais dispõem
as informações relacionadas aos bancos de dados e suas réplicas. Ao inserir um bancos
de dados para uso no QoSDBC, as informações desse banco são mantidas no catalog,
presente no QoSDBCCoordinator, e então são utilizadas pelo CloudBViewer. As funcio-
nalidades do sistema são: (i) informar todos os bancos de dados que estão dispostos nas
VMs; (ii) indicar as réplicas disponı́veis para cada banco de dados (iii) mostrar grafica-
mente a predição de carga de trabalho, de modo que se possa comparar com a real carga
de trabalho; (iv) caso alguma eventual violação de SLA ocorra, ou esteja prevista, infor-
mar ao usuário. Como restrição de implementação da ferramenta, ela implementa apenas
consultas a SGBD PostgreSQL.
O CloudBViewer está dividido em duas partes, uma parte está no lado servidor,
chamada front-end, e a outra está no lado cliente, denominada back-end. A parte do lado
servidor foi desenvolvida utilizando Java Enterprise Edition (JEE). Portanto, precisa de
um servidor que suporte a tecnologia Java para funcionar. Nos testes realizados para o
presente trabalho, foi utilizado o servidor Apache Tomcat, versão 8. A parte front-end uti-
liza as tecnologias HyperText Markup Language (HTML), Cascading Style Sheets (CSS)
e Javascript. As páginas originalmente foram desenvolvidas em JavaServer Pages (JSP),
que estão no servidor. Entretanto, JSPs são base para gerar as páginas HTML disponibili-
zadas para o lado cliente. Além disso, também foram utilizados alguns frameworks para a
construção da ferramenta. A biblioteca d3 possibilitou plotar o gráfico comparativo entre
dados reais e dados previstos, assim como a linha de SLA que pode ser adicionada pelo
usuário a esse gráfico. O SweetAlert foi usado para criação de alertas e lightboxes que
proporcionem uma melhor experiência de uso. O Bootstrap garantiu o design responsivo
da ferramenta, de modo que seja possı́vel utilizar a ferramenta tanto em computadores
quanto em smartphones. Por último, o framework Jquery proporcionou maior agilidade
no processo de desenvolvimento.
Para utilizar a ferramenta, basta configurar usuário e senha num arquivo de cre-
denciais, os quais são utilizados para autenticação no sistema. Além disso, também é
1O código-fonte da aplicação está disponı́vel em: https://github.com/sergiosmarinho/cloudbviewer/
Figura 4. Tela de Configurações
necessário indicar na classe de configurações o endereço desse arquivo. Após o login, o
usuário será redirecionado para a tela de configurações, mostrada na Figura 4. São pedi-
dos os dados para acessar as bases de dados Log e Catalog, responsáveis por armazenar
os dados utilizados pelo sistema. Esses dados se referem ao que é necessário para uso no
padrão JDBC: endereço, porta, usuário e senha. Os valores serão verificados pelo servlet
competente, e, em caso de sucesso, como pode ser visto na Figura 5, o usuário recebe
uma mensagem de confirmação, pois os dados foram salvos em um arquivo especı́fico
para essas informações.
Há uma tela responsável por mostrar todos os bancos de dados disponı́veis, de-
monstrada na Figura 6. A parte front-end faz consultas a um servlet que atende requisições
que utilizam o protocolo Hypertext Transfer Protocol (HTTP) com o método de requisição
GET. A resposta do servlet é um arquivo do tipo .json, que contém uma lista com os no-
mes de todos os bancos de dados disponı́veis naquele momento. O servlet obtém as
informações de todos os bancos disponı́veis por meio de consulta à tabela dbactive, do
banco de dados Catalog. Ao clicar em um banco de dados, o usuário é redirecionado para
a página de informações do banco de dados escolhido. A partir do clique, é feita uma
chamada à JSP que mostra os dados daquele banco. O nome do banco de dados escolhido
é passado como parâmetro por meio de requisição GET.
Em conformidade com a Figura 7, a tela de informações de um banco de dados
especı́fico está dividida em duas partes: (i) lista com todas as réplicas disponı́veis para
aquele banco de dados; (ii) um gráfico com os dados reais plotados em verde e os dados
previstos plotados em cinza. Na lista de réplicas, cada réplica é identificada pelo seu
endereço de Internet Protocol (IP). Essa informação é obtida no arquivo .json requisitado
ao servlet responsável por consultar a tabela dbActiveReplica, do banco de dados Catalog.
Já as informações de tempo de resposta médio por minuto plotadas em verde no gráfico
são obtidas por meio de um servlet que consulta a tabela Log do banco Log e retorna um
Figura 5. Configurações Aceitas Figura 6. Bancos Disponı́veis
Figura 7. Dadosde um banco especı́fico
Figura 8. Adição de SLA Figura 9. Alerta de violação de SLA
arquivo .csv. Além disso, o usuário pode inserir um SLA para acompanhar a relação entre
os tempos de resposta e o SLA, de maneira a ser avisado sonoramente quando alguma
violação de SLA ocorra ou esteja prevista. A Figura 8 mostra uma tela de cadastro de um
SLA, e a Figura 9 mostra uma tela com um aviso de previsão de violação de SLA.
O servlet responsável por buscar os dados de tempos de resposta também é o
responsável por gerar os dados de predição. Isso porque o arquivo .csv que contém os
tempos de resposta reais também contém os previstos, além das respectivas datas para
cada informação de tempo de resposta. Para obter os tempos de resposta previstos, é
feita uma chamada shell script, via código, à função auto.arima do R. Nessa chamada, a
série temporal dos quatro últimos tempos de resposta colhidos é passada como parâmetro.
É esperado que esses valores sejam correspondentes aos quatro últimos minutos. Final-
mente, esse dado é agregado a variável de contexto responsável por armazenar os dados
previstos. Caso a quantidade de dados colhidos seja menor que quatro, não há a predição
de dados até que se tenha esse valor mı́nimo.
5. Conclusão
Foi apresentada uma proposta de um serviço de balanceamento de carga preditivo para
bancos de dados replicados em nuvens computacionais. O serviço proposto foi proje-
tado para ser implantado na arquitetura do sistema QoSDBC. Na concepção do serviço
proposto, a adoção do modelo de predição ARIMA foi considerada porque este modelo
apresentou bons resultados para janelas de previsão curta. O experimento foi realizado e
mostrou que o ARIMA pode ser usado para prever as cargas de trabalho dos bancos de
dados replicados da nuvem. A predição dos tempos de resposta por cada réplica pode tra-
zer benefı́cios na distribuição da carga de trabalho, de modo a favorecer o melhor uso dos
recursos computacionais disponı́veis, bem como evitar violações de SLA. Como futuros
trabalhos, é pretendido: (i) implementar o serviço de predição projetado na arquitetura do
sistema QoSDBC; (ii) realizar experimentos mais aprofundados, com maior variedade de
cargas de trabalho e em outros cenários para replicação de bancos de dados em nuvem;
(iii) comparar o desempenho do ARIMA com o de outros modelos de predição no mesmo
cenário experimentado; (iv) atualizar a arquitetura do QoSDBC para que suporte o uso
de outros modelos multi-inquilino e de persistência; e (v) aprimorar a prova de conceito
para que ela mostre a predição de carga por réplica, e não por banco de dados, como está
implementada atualmente, de modo que possa ser utilizada como ferramenta de apoio.
Agradecimento
Essa pesquisa é resultado parcial do projeto no 455214/2014-0 fomentado pelo CNPq.
Referências
Barker, S., Chi, Y., Moon, H. J., Hacigümüş, H., and Shenoy, P. (2012). “cut me some
slack”: Latency-aware live migration for databases. In EDBT ’12, pages 432–443,
New York, NY, USA. ACM.
Difallah, D. E., Pavlo, A., Curino, C., and Cudré-Mauroux, P. (2013). Oltp-bench: An
extensible testbed for benchmarking relational databases. PVLDB, 7(4):277–288.
Mell, P. and Grance, T. (2011). The nist definition of cloud computing. National Institute
of Standards and Technology (NIST).
Moon, H. J., Hacümüş, H., Chi, Y., and Hsiung, W.-P. (2013). Swat: A lightweight load
balancing method for multitenant databases. In EDBT ’13, pages 65–76, New York,
NY, USA. ACM.
Moreira, L. O., Farias, V. A. E., Sousa, F. R. C., Santos, G. A. C., Maia, J. G. R., and
Machado, J. C. (2014). Towards improvements on the quality of service for multi-
tenant rdbms in the cloud. In ICDE Workshops, pages 162–169, Chicago, IL, USA.
Moreira, L. O., Sousa, F. R. C., and Machado, J. C. (2012). Analisando o desempenho de
banco de dados multi-inquilino em nuvem. In SBBD ’12, pages 161–168.
Pippal, S., Singh, S., Sachan, R. K., and Kushwaha, D. S. (2015). High availability of
databases for cloud. In INDIACom, pages 1716–1722.
Santos, G. A. C., Maia, J. G. R., Moreira, L. O., Sousa, F. R. C., and Machado, J. C.
(2013). Scale-space filtering for workload analysis and forecast. In CLOUD ’13,
pages 677–684. IEEE.
Sousa, F. R. C. and Machado, J. C. (2012). Towards elastic multi-tenant database replica-
tion with quality of service. In UCC ’12, pages 168–175. IEEE.
Sousa, F. R. C., Moreira, L. O., Santos, G. A. C., and Machado, J. C. (2012). Quality of
service for database in the cloud. In CLOSER ’12, pages 595–601.