Uma Anlise do Impacto da

Elasticidade no Lucro de
Provedores de Computao na
Nuvem
Rostand Costa
1,2
, Francisco Brasileiro
1
, Guido Lemos
2
, Dnio Mariz
2
1
Universidade Federal de Campina Grande Departamento de Sistemas e Computao
Av. Aprgio Veloso, s/n, Bodocong 58.429-900 - Campina Grande, PB - Brasil
{rostand, fubica}@lsd.ufcg.edu.br
2
Universidade Federal da Paraba Departamento de Informtica
Laboratrio de Aplicaes de Vdeo Digital 58.050-900, Joo Pessoa, PB
{rostand, guido, denio}@lavid.ufpb.br
Abstract
The cloud computing paradigm allows the provision
of Information Technology infrastructure in the form of a
service that clients acquire on-demand and paying only
for the amount of service that they actually consume.
Many embarrassingly parallel applications could po-
tentially achieve an enormous benet from the elasticity
offered by cloud computing providers. The execution
time of these applications is inversely proportional to
the amount of computing resources available to process
them. Unfortunately, current public cloud computing
providers do impose strict limits on the amount of
resources that a single user can simultaneously acquire.
In this paper we analyze the reasons why traditional
providers need to impose such a limit. We show that
increases on the limit imposed have a severe impact on
the prot achieved by the providers. This leads to the con-
clusion that new approaches to deploy cloud computing
services are required to properly serve embarrassingly
parallel applications.
Keywords: Cloud computing, elasticity, prot, bag-
of-tasks
Resumo
O paradigma da computao na nuvem permite o
fornecimento de infraestrutura de Tecnologia da In-
formao sob a forma de um servio que os clientes
adquirem sob demanda e pagam apenas pela quantidade
de servios que realmente consomem. Muitas aplicaes
que processam grandes cargas de trabalho em paralelo
poderiam potencialmente se beneciar da elasticidade
oferecida pelos provedores de computao na nuvem. Es-
sas aplicaes tm seu tempo de execuo inversamente
proporcional quantidade de recursos computacionais
usados para process-las. Infelizmente, os provedores
pblicos atuais de computao na nuvem precisam im-
por um limite estrito na quantidade de recursos que um
nico usurio pode adquirir concomitantemente. Neste
trabalho ns analisamos por que esse limite precisa ser
imposto. Nossos resultados mostram que aumentos no
limite imposto tm um grande impacto na lucratividade
do provedor. Desse modo, preciso pensar em novas for-
mas de oferecer computao na nuvem para que as apli-
caes estudadas possam ser atendidas de forma apro-
priada.
Palavras-chave: Computao na nuvem, elastici-
dade, lucratividade, utilizao intensiva.
1. INTRODUO
Computao na nuvem um paradigma em evoluo
que permite o fornecimento de Tecnologia da Informao
(TI) como um servio que pode ser adquirido on line
e sob demanda pelos clientes. Os recursos utilizados
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
para prover servio aos clientes podem ser rapidamente
provisionados e liberados pelos provedores do servio,
que utilizam um modelo de tarifao onde o cliente
paga apenas pelo que foi efetivamente consumido. Este
paradigma pode ser usado em diferentes nveis da pilha
de TI [15]. Por exemplo, no nvel mais alto, clientes po-
dem adquirir servios que provem uma funcionalidade
particular de software. Este tipo de fornecimento de TI
normalmente chamado de SaaS (do ingls, software-as-
a-service). Similarmente, o nvel mais baixo da pilha,
clientes podem adquirir mquinas virtuais totalmente fun-
cionais executando um determinado sistema operacional,
sobre o qual eles podem instalar e executar as suas
prprias aplicaes. Este tipo de servio recebeu o nome
de IaaS (do ingls, infrastructure-as-a-service) [15].
Este trabalho est focado no ltimo tipo de servio.
Dessa forma, no restante deste artigo sero usados os
termos computao na nuvem e IaaS com o mesmo
propsito.
Ao adquirir recursos de TI de um provedor de com-
putao na nuvem, os clientes podem desfrutar da elasti-
cidade oferecida, podendo aumentar e diminuir o seu con-
sumo de servios de uma forma virtualmente ilimitada,
sem qualquer custo adicional. Em teoria, essa elastici-
dade ilimitada permitiria aos usurios decidir livremente,
por exemplo, se desejam usar 1 recurso por 1.000 horas
ou 1.000 recursos por 1 hora, pagando o mesmo preo em
ambos os casos.
A elasticidade do modelo de computao na nuvem
particularmente interessante para uma classe importante
de aplicaes que est se tornando cada vez mais popular.
As chamadas aplicaes de e-cincia so caracterizadas
por cargas de trabalho que requerem computao inten-
siva. Muitas destas aplicaes podem ser paralelizadas
trivialmente, atravs da quebra do trabalho a ser realizado
em vrias tarefas menores que podem ser processadas in-
dependentemente. Esta classe de aplicao referenci-
ada na literatura como aplicaes embaraosamente pa-
ralelas ou simplesmente saco-de-tarefas (BoT, do in-
gls bag-of-tasks) [4]. Por exemplo, as simulaes de
Monte Carlo, que podem envolver a execuo de milhares
de cenrios diferentes, podem ser paralelizadas simples-
mente pela execuo de cada cenrio em uma unidade
de processamento diferente. Aplicaes que processam
enormes quantidades de dados podem usualmente ser pa-
ralelizadas atravs da diviso dos dados entre um nmero
de processos idnticos que executam a computao so-
bre cada bloco de dados independentemente; no nal,
pode ser necessrio realizar algum tipo de consolidao
dos processamentos individuais. A renderizao de ima-
gens complexas e vdeos se encaixa bem nesta descrio.
A lista de aplicaes BoT vasta e engloba no ape-
nas usurios da academia, mas tambm da indstria e
do governo. Alm disso, a quantidade crescente de da-
dos gerada e consumida pela sociedade moderna deve au-
mentar a presso para executar ecientemente estas apli-
caes [8].
Se o cliente que necessita executar uma aplicao BoT
fosse capaz de requisitar de um provedor de computao
na nuvem tantas mquinas virtuais quanto as necessrias
para maximizar o nvel de paralelizao da execuo da
aplicao, isto lhe permitiria executar esta aplicao no
menor tempo possvel, sem que isso implicasse em um
gasto extra com os recursos computacionais usados. A
elasticidade do servio oferecido por um provedor de IaaS
, obviamente, limitada pela quantidade fsica de recur-
sos que ele dispe. Acontece que, atualmente, esse limite
muito mais restritivo, uma vez que os provedores de
computao na nuvem em operao restringem a quan-
tidade de recursos que cada cliente pode demandar de
cada vez a um nmero relativamente muito baixo, com-
parado com a capacidade dos provedores. Por exemplo,
no momento em que este texto estava sendo escrito, um
dos principais provedores comerciais em atividade limi-
tava em 20 o nmero de mquinas virtuais que podem ser
instanciadas de forma dedicada (on-demand instances)
e em 100 o nmero de mquinas virtuais que podem
ser instanciadas segundo um modelo best-effort (spot
instances) [1]. Para este provedor em particular, clientes
podem usar um canal paralelo de negociao para ten-
tar aumentar este limite de forma ad hoc, mas como as
condies sob as quais uma negociao bem sucedida
no so documentadas, ns consideramos neste artigo
apenas o canal de comunicao automtico. Aparente-
mente, o alvo do limite no o volume da requisio
em si, mas o exerccio extremo da elasticidade atravs
de grandes alocaes com liberaes logo em seguida.
Como j existem servios de alta demanda hospedados
em provedores de computao na nuvem (ex. Gmail,
Twitter, Bing etc.) e tambm a possibilidade de se ne-
gociar alocaes superiores, possvel inferir que o limite
serve como um regulador do uso intensivo de recursos por
perodos curtos.
Embora os limites atualmente impostos pelos prove-
dores de IaaS no impeam que a maioria dos clientes
enxerguem o servio provido como uma fonte innita
de recursos, este no o caso para a maioria das apli-
caes BoT. Estas aplicaes requerem a instanciao de
um sistema com milhares de mquinas virtuais. Alm
disso, quanto mais mquinas elas puderem usar, mais
curto ser o tempo de utilizao das mesmas. O projeto
Belle II Monte Carlo [14], por exemplo, requer de 20.000
a 120.000 mquinas virtuais para o processamento em
tempo aceitvel dos dados produzidos em trs meses de
experimentos. Ou seja, eles tm uma altssima demanda
por recursos de forma bastante espordica. Esse padro
de consumo muito comum entre os usurios que execu-
tam aplicaes BoT.
10
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
Neste artigo ns fazemos uma anlise que tenta iden-
ticar as razes que levam os provedores de IaaS a im-
porem limites que restringem a utilidade de seus servios
para a execuo de aplicaes da classe BoT. Nossa
metodologia baseia-se no uso de simulao. Inicialmente
denimos um modelo simplicado de provedores de IaaS,
apresentado na Seo 3, e um gerador de cargas de tra-
balho sintticas apropriadas para esse modelo, discutido
na Seo 4. Em seguida, ns apresentamos o modelo de
simulao utilizado (Seo 5.1). Para instanciar o modelo
de simulao de forma adequada, ns realizamos um pro-
jeto de experimento para identicar as variveis aleatrias
do modelo que tinham um maior impacto na varivel de
resposta, e dessa forma denir os cenrios de experimen-
tao (Seo 5.2). Os resultados das simulaes execu-
tadas que apresentamos na Seo 6 apontam que aumen-
tos no limite imposto pelo provedor de IaaS levam a im-
pactos substanciais na lucratividade do provedor. Dessa
forma, pouco provvel que os provedores de IaaS atual-
mente em operao possam vir a oferecer um servio ade-
quado para os usurios que precisam executar aplicaes
BoT. Na seo de concluso deste artigo ns indicamos
uma possvel alternativa para a implantao de umservio
de IaaS que possa atender apropriadamente essa classe de
aplicaes.
Antes de apresentar o nosso estudo sobre o impacto
que o limite no nmero mximo de recursos que um
cliente pode instanciar concomitantemente tem na lucra-
tividade de um provedor de IaaS, na prxima seo ns
fazemos uma breve reviso da literatura relacionada com
o nosso trabalho.
2. TRABALHOS RELACIONADOS
O trabalho de Menasc e Ngo discute como os mto-
dos tradicionais de planejamento de capacidade foram
impactados com o advento da computao na nuvem e
como o atendimento dos nveis de servio negociados
passam a exigir novos mecanismos, como tcnicas de
computao autonmica [12]. So considerados os pon-
tos de vista tanto do cliente quanto do provedor, com a
percepo de que todos os riscos e custos associados com
o provisionamento de recursos migram dos ombros dos
clientes para os ombros dos provedores. O aprofunda-
mento que fazemos neste artigo nos aspectos de disponi-
bilidade e regulao da demanda pelos provedores con-
rma esta condio, indicando que novas abordagens so
necessrias para a construo de infraestrutura para com-
putao na nuvem tanto para contornar as limitaes a-
tuais quanto para aliviar a carga dos provedores.
O estudo de Greenberg et al. [7] mostra que os custos
tpicos associados para a construo de centros de proces-
samento de dados para nuvens possuem a seguinte dis-
tribuio: aquisio de servidores, incluindo hardware e
software, respondem por 45% do custo total; montagem
da infraestrutura, incluindo refrigerao e instalaes l-
gicas e eltricas, consomem 25% dos recursos; equipa-
mentos e canais de comunicao em geral so respon-
sveis por 15% do oramento e os 15% restantes cam
por conta de fornecimento de energia e outras despesas.
Um arcabouo para a anlise detalhada destes investimen-
tos e como eles compem o custo total de propriedade
[13] dos provedores foi proposto por Li et al. [11]. Na
abordagem proposta, os quatro principais grupos de cus-
tos identicados por Greenberg et al. so expandidos para
oito categorias e, em complemento aos investimentos ini-
ciais, so tambm considerados os custos relacionados
com a operao do centro de processamento de dados,
considerando a elasticidade no consumo de recursos da
nuvem. Para isto, o arcabouo permite a apurao do
custo de amortizao e do custo de utilizao de cada re-
curso virtual. No primeiro caso, denido quanto cada
recurso custa por estar disponvel para o uso e, no se-
gundo caso, quanto custa ao ser efetivamente usado pe-
los clientes. No modelo usado no nosso trabalho ns uti-
lizamos esses dois custos para computar o valor do lucro
obtido por um provedor de IaaS.
No trabalho de Anandasivam et al. [2] introduzida
uma verso do conceito de preo auto-ajustvel adap-
tada para computao na nuvem. Considerando um con-
texto com demandas dinmicas e imprevisveis, no qual
o provedor precisa decidir como alocar os seus recursos
nitos de forma a maximizar a sua lucratividade, a apli-
cao de um sistema de leilo pode atuar como um in-
uenciador no comportamento de usurios sensveis ao
preo dos recursos. Este mecanismo pode ter impactos
positivos no controle da capacidade do provedor. Atravs
do nosso estudo possvel constatar que o limite imposto
pelos provedores tambm usado como um regulador da
demanda dos usurios para conciliar os picos de utiliza-
o com a sua capacidade instalada.
3. UM MODELO SIMPLIFICADO DE UM
PROVEDOR DE IAAS
Os servios oferecidos por provedores de computao
na nuvem precisam, normalmente, fornecer garantias de
qualidade de servio (QoS, do ingls Quality of Ser-
vice) que atendam plenamente os requisitos estabeleci-
dos com os clientes que adquirem os seus servios, ex-
pressos atravs de um acordo de nvel de servio (SLA,
do ingls service level agreement). Muitas dessas garan-
tias so providas atravs da manuteno de capacidade
excedente pelo provedor. Por outro lado, os custos do
provedor so reduzidos pelas vantagens que a economia
de escala pode proporcionar-lhes. Por exemplo, a con-
11
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
centrao de sua estrutura em grandes centros de proces-
samento de dados, dedicados e centralizados, e o compar-
tilhamento de recursos fsicos atravs da virtualizao so
estratgias cruciais para efetivamente oferecer servios de
uma forma economicamente vivel. Sua competitividade
tambm baseada na capacidade de realizar uma multi-
plexao estatstica de picos e vales no uso simultneo de
recursos por um grande nmero de clientes. Outra van-
tagem o nvel de automao atingido pelos provedores
de computao na nuvem que, entre outras coisas, per-
mite que eles reduzam substancialmente a relao de fun-
cionrios por servidores. Adicionalmente, os provedores
podem obter um aumento no nvel de utilizao dos seus
servios atravs da oferta de um portflio de servios que
contemple diferentes modelos de precicao [1].
Dentre as muitas propriedade de QoS que um prove-
dor de computao na nuvem precisa observar, neste tra-
balho ns iremos nos concentrar na disponibilidade do
servio (service availability), isto , na probabilidade de
que um cliente que solicita um servio tenha o seu pe-
dido plenamente atendido
1
. Esta propriedade no deve
ser confundida com a conabilidade do servio (service
reliability), que representada pela probabilidade de que
o servio provido no ir falhar enquanto o cliente estiver
usandoo. Por exemplo, no caso de um provedor de IaaS,
a sua disponibilidade afetada quando um cliente solicita
uma nova mquina virtual e o provedor incapaz de ins-
tanciar o recurso pedido, enquanto que a sua conabili-
dade afetada sempre que uma mquina virtual que tenha
sido instanciada sofre uma falha.
Considerando que os recursos de umprovedor so alo-
cados a cada cliente por um intervalo de tempo mnimo,
por exemplo, 1 hora, vamos assumir que o tempo dis-
cretizado em intervalos de tamanho xo (fatias), e mode-
laremos um provedor IaaS P em um determinado perodo
de observao de tamanho T como uma tupla:
P = K, L, U, D, A, C
i
, C
u
, V, E),
onde:
K a quantidade de recursos disponveis no servi-
dor;
L a quantidade mxima de recursos que pode ser
alocado em cada fatia de tempo;
U o conjunto de usurios registrados no servidor;
D a distribuio de demanda desses usurios;
A a estratgia de alocao de recursos usada pelo
provedor;
1
O foco em disponibilidade foi uma simplicao para tornar o modelo
tratvel, outras dimenses sero abordadas em trabalhos futuros.
C
i
o custo incorrido pelo provedor para disponi-
bilizar cada recurso individual por fatia de tempo,
obtido pelo rateio da amortizao do custo total de
propriedade pelos recursos disponveis e pelas fatias
possveis no mesmo perodo
2
;
C
u
o custo adicional incorrido pelo provedor, por
fatia de tempo, gasto somente quando cada recurso
individual est sendo efetivamente usado, baseado
no conceito de custo de utilizao proposto por Li et
al. [11] e considerando que algum nvel de ecincia
energtica praticado [3];
V o valor cobrado dos usurios pela utilizao efe-
tiva de um recurso por uma fatia de tempo ou frao;
E o encargo para o provedor por cada violao
cometida; ele pode ser tangvel (ex. compensao
para o usurio) ou intangvel (ex. dano na imagem
do provedor). Neste trabalho ns consideramos ape-
nas o aspecto tangvel dos encargos por violaes.
Na prxima seo ns apresentamos em detalhes
como a demanda D dos usurios U de um provedor P
descrita. Por enquanto, basta assumir que d(u, t), 0
d(u, t) L, u U, 1 t T, a quantidade de re-
cursos demandada pelo usurio u na fatia t. Dependendo
do padro de demanda (D) dos usurios do provedor, da
estratgia de alocao (A) e da capacidade (K) do prove-
dor, cada usurio u que requisita d(u, t) recursos na fa-
tia t ir receber uma alocao de recursos associada que
expressa por a(u, t), 0 a(u, t) d(u, t). Quando
a(u, t) < d(u, t) temos uma violao na disponibilidade
do servio do provedor. Dessa forma, o nmero total de
violaes ocorridas em uma fatia t dado por:
v(t) =

uU
1
a(u, t)
d(u, t)
| (1)
Seja (t) a utilizao do provedor na fatia de tempo t.
(t) =

uU
a(u, t). Uma maneira de aferir a ecincia
do provedor medir o seu lucro no perodo de tempo con-
siderado, o qual representado em nosso modelo atravs
da frmula:
=
T

t=1
[(V C
u
)(t)v(t)E]KC
i
T (2)
2
Embora os custos descritos possuam um comportamento linear e se-
jam uma simplicao dos custos reais, de perl mais complexo, essa
simplicao oferece uma boa aproximao e atende as necessidades do
nosso modelo.
12
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
4. GERAO DE CARGAS DE TRA-
BALHO SINTTICAS PARA UM PROVEDOR
DE IAAS
Por causa da indisponibilidade de traos de execues
reais ou mesmo caracterizaes da carga de trabalho de
provedores de IaaS, ns tivemos que criar um gerador de
cargas de trabalho sintticas, para denir a demanda im-
posta ao provedor modelado na seo anterior.
O uso total do sistema em cada fatia de tempo t, re-
presentado por (t), resultante do perl de uso de cada
usurio individual ou, em outras palavras, da forma como
ele requisita recursos dentro do limite imposto pelo prove-
dor durante o seu tempo de permanncia no sistema. Em
princpio, todos os usurios podem, sob demanda e sem
custos adicionais, se beneciar da inerente elasticidade
do servio e usar qualquer quantidade de recursos (desde
nenhum) at o limite L imposto pelo provedor, em qual-
quer fatia de tempo.
Considerando o comportamento do sistema no in-
tervalo de tempo de durao T, algumas categorias
de usurios iro emergir. Uma classicao inicial dos
usurios est relacionada com o nvel de demanda ob-
servada no perodo considerado. Os usurios ativos so
aqueles que zeram alguma demanda por recursos do sis-
tema em um dado intervalo, ou seja, d(u, t) > 0 para
algum valor de t, 1 t T. Os outros usurios
so ditos inativos. Seja U
a
o conjunto de usurios ativos;
U
a
= u[u U t, 1 t T, d(u, t) > 0.
O comportamento de cada categoria de usurio ativo
descrito atravs do uso das distribuies tradicional-
mente associadas na literatura com classes de usurios e
sesses de uso [6, 16, 9]. Para gerao da carga de tra-
balho foi aplicada a abordagem de gerao hierrquica,
usando uma modelagem baseada no usurio [6]. Esta
tcnica baseia-se na separao do comportamento dos
usurios em trs nveis: perl da populao/durao da
sesso/atividade dentro da sesso, contemplando aspec-
tos como localidade e amostragem [6], alm de auto-
similaridade [6]. Com isto, possvel a incluso na carga
de trabalho gerada de longas permanncias e ausncias
(cauda longa [9]) e tambmde comportamentos regulares.
O sistema modelado do tipo fechado, com um nmero
conhecido e nito de usurios ([U
a
[).
A populao de usurios ativos pode ser dividida em
dois grupos, considerando a regularidade de demanda dos
mesmos. Usurios ativos regulares so aqueles com uso
ininterrupto. O conjunto de usurios regulares descrito
da seguinte forma: U
r
= u[u U
a
t, 1 t
T, d(u, t) > 0. Os usurios eventuais so os usurios
ativos no regulares, ou seja, U
e
= U
a
U
r
.
Ns assumimos que os usurios regulares tm apenas
uma sesso, cuja durao engloba pelo menos todo o in-
tervalo de T fatias considerado. Por outro lado, para os
usurios eventuais o tempo de sesso governado pelas
seguintes variveis aleatrias:
o: durao (em fatias) de cada sesso de um usurio
eventual, seguindo uma distribuio uniforme com
limite inferior l
o
e limite superior u
o
[9]; e

i: intervalo entre sesses, seguindo uma distribuio
pareto com parmetros k
i
e s
i
[9].
Dentro de cada sesso o usurio pode estarem ativi-
dade ou em espera (think time), que indicam, respec-
tivamente, se o usurio est efetivamente usando recur-
sos, ou no. O comportamento de cada usurio em sesso
pode ser denido pela quantidade de recursos que ele uti-
liza, pela durao deste uso e tambm pelo tempo que ele
ca sem usar os recursos do sistema. Desta forma, cada
atividade pode ser caracterizada pela tupla / = r, n, e),
onde r e n representam a quantidade de recursos requi-
sitados por fatia de tempo e a durao da atividade em
nmero de fatias, respectivamente, e e representa o tempo
de espera at a prxima fatia quando o usurio estar em
atividade. A mudana na quantidade de recursos, em-
bora possvel, implica no incio de outra atividade. A
seguir, sero descritos os pers de uso de cada categoria
de usurio da nossa populao.
O perl de uso dos usurios regulares foi modelado
de uma forma simplicada. Usurios regulares apresen-
tam atividades ininterruptas (sem espera) que duram uma
fatia de tempo. Em cada sesso o nmero de recursos
demandados baseado na varivel aleatria m com dis-
tribuio normal, mdia e varincia , onde o ticket
mdio dos usurios regulares, dado por:
=

t
t=1

uU
r
a(u,t)
T
[U
r
[
(3)
O perl de atividade dos usurios regulares denido
como:
/
regular
= m N(, ), 1, 0) (4)
Esta abordagem permite contemplar eventuais au-
mentos ou diminuies do tamanho das atividades dos
usurios regulares que, atravs de compensao, no al-
terem substancialmente a utilizao total dos usurios
regulares do sistema em cada fatia de tempo. Mudanas
mais abruptas no comportamento de usurios regulares
que afetam este relacionamento sero tratadas adiante.
O comportamento em sesso dos usurios eventuais,
por sua vez, baseado em trs variveis aleatrias:
s: quantidade de recursos alocados em cada ativi-
dade, seguindo uma distribuio uniforme entre 1 e
L [9];
13
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem

d: durao (em fatias) de cada atividade, seguindo
uma distribuio exponencial com mdia
d
[9]; e

t: intervalo (em fatias) entre atividades (think time),
seguindo uma distribuio exponencial com mdia

t
[9].
O perl de atividades dos usurios eventuais
denido como:
/
eventual
= s U(1, L),

d E(
d
),

t E(
t
)) (5)
Dois pers particulares de usurios eventuais foram
tambm modelados para cobrir as seguintes situaes: a)
usurios regulares apresentando uma demanda no usual
por recursos motivada por urries ou ashmobs em seus
servios [10]; b) usurios eventuais com utilizao inten-
siva e sensvel ao tempo (aplicaes BoT) [14] que con-
somem todos os recursos disponveis. Estes pers so
denidos da seguinte forma:
/
flashmob
= U( +1, L),

d E(
d
),

t E(
t
)) (6)
A
BoT
= L,

d E(
d
),

t E(
t
)).(7)
5. DESCRIO DOS EXPERIMENTOS
O principal objetivo dos experimentos de simulao
observar: i) a capacidade mnima necessria para atendi-
mento de todas as solicitaes dentro do limite; ii) a
ociosidade do sistema em cada cenrio; e iii) o resul-
tado operacional com diferentes limites. Em seguida a-
presentaremos como o modelo de simulao foi imple-
mentado e como os cenrios de simulao foram instan-
ciados.
5.1. IMPLEMENTAO DO MODELO DE SIMU-
LAO
Para ser resolvido por simulao, o modelo proposto
foi implementado usando a ferramenta Mbius [5]. Esta
plataforma permite a realizao de simulao de eventos
discretos e resoluo numrica ou analtica de modelos
de sistemas que podem ser descritos em uma variedade
de formalismos diferentes.
Um dos formalismos suportados so os modelos com-
postos Replicate/Join que permitem a denio de mode-
los por composio na forma de uma rvore, na qual cada
folha da rvore pode ser um modelo atmico, descrito em
um dos formalismos suportados, ou outro modelo com-
posto. Cada n da rvore que no uma folha classi-
cado ou como um n Join ou como um n Replicate. Um
n do tipo Join usado para compor dois ou mais sub-
modelos atravs do compartilhamento de estado e um n
do tipo Replicate usado para construir um modelo con-
sistindo de um determinado nmero de cpias idnticas
do seu submodelo lho. Recursivamente, cada n lho de
um n Replicate ou Join pode ser um Replicate, um Join,
ou um modelo atmico ou composto.
Figure 1. O Modelo Composto dos Usurios Ativos de um Provedor
IaaS
Ns usamos o formalismo Replicate/Join para a cri-
ao do modelo composto representantivo dos usurios
ativos de um provedor IaaS ActiveUsers (Figura 1). Este
modelo contm quatro submodelos atmicos, modelados
no formalismo Stochastic Activity Network (SAN), re-
presentando os quatro pers de usurios descritos: Regu-
lar, Eventual, FlashMob e BoT. O uso dos ns Replicate
permite a criao do nmero desejado de instncias de
cada perl de usurio associado e tambm o comparti-
lhamento de estado entre as instncias de um mesmo tipo
de submodelo. O n Join, por sua vez, permite o com-
partilhamento de estado entre instncias de submodelos
de tipos diferentes. Desta forma, a carga de trabalho sin-
ttica foi construda atravs da atividade autnoma e com-
binada de uma instncia do submodelo Regular, cuja de-
manda em cada fatia multiplicada por [U
r
[, e [U
e
[ ins-
tncias dos submodelos Eventual, FlashMob e BoT, de
acordo com a distribuio de atividade congurada para
cada tipo de perl.
Figure 2. O modelo atmico (SAN) de um usurio do perl Eventual
O submodelo Eventual (Figura 2) representa o com-
14
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
portamento de um usurio do perl Eventual. Conforme
descrito na seo anterior, um usurio consome recursos
atravs de uma srie de estgios. Estes estgios foram
modelados em um submodelo SAN como places e ex-
tended places (crculos azuis e laranja, respectivamente).
Cada place mantm um contador (representado como to-
kens) de como cada usurio est em cada estgio e os
input gates (tringulos vermelhos) so usados para ins-
pecionar estes valores e habilitar (ou no) a transio do
sistema atravs da execuo de atividades temporizadas
(barras verticais). Cada atividade temporizada tem uma
durao que impacta na dinmica do sistema modelado e
tambm uma distribuio (e parmetros associados) que
regula o seu comportamento. Os output gates (tringu-
los pretos) so executados aps o tempo de durao de
uma atividade ter sido completada e permite a alterao
do estado do sistema atravs da alterao dos tokens nos
places. Os arcos (linhas pretas) controlam o uxo de tran-
sio de estgios.
Figure 3. O modelo atmico (SAN) de um usurio do perl Regular
Cada usurio de perl Eventual inicializado ran-
domicamente em um dos estgios possveis (OnSession
ou OffSession) que controlado pelo lugar On. A
partir deste momento, as atividades OffTime e OnTime
comeam a regular a alternncia do usurio em sesses de
uso e perodos de inatividade, controlados pelas variveis
aleatrias o e

i, respectivamente. Uma nova atividade
para o usurio em sesso atribuda (conforme descrito
no perl Eventual e usando as variveis aleatrias

d e s)
atravs da porta de sada SetActivity aps um perodo de
espera (think time) ser cumprido. A durao de cada es-
pera gerida pela atividade temporizada NewThinkTime
(varivel aleatria

t). O lugar ActivityControl, por sua
vez, controla a durao de cada atividade individual, fatia
a fatia, atravs da atividade temporizada NewCycle.
Os outros submodelos Regular (Figura 4), FlashMob
(Figura 3) e BoT ou Intenso (Figura 5) possuem mode-
Figure 4. O modelo atmico (SAN) de um usurio do perl FlashMob
lagem similar
3
.
Figure 5. O modelo atmico (SAN) de um usurio do perl BoT
(Intenso)
Atravs da congurao dos parmetros do sistema,
modelados como variveis globais, foi usado o simulador
do Mbius para executar o modelo proposto e obter as
medidas de interesse desejadas ao longo do tempo, in-
cluindo a quantidade de recursos usados, o nmero de so-
licitaes e o nmero de violaes cometidas.
5.2. PARMETROS DO SISTEMA
Para atribuio dos parmetros do sistema foram u-
sadas duas estratgias: projeto de experimento (DoE, do
ingls Design of Experiment) e varredura de parmetros.
A parte dos parmetros relacionada com a gerao da
carga sinttica e associada com as distribuies descritas
na Seo 4 foi tratada atravs de um DoE do tipo 2
k
fa-
torial [Jain 1991]. Atravs do DoE foi possvel analisar o
efeito dos parmetros das variveis aleatrias o (durao
da sesso),

i (intervalo entre sesses), s (durao da ativi-

dade),

t (think time) e tambm do valor de L sobre uma
das variveis de resposta do sistema: a utilizao mxima
do sistema em um dado intervalo (max((t)) t, 1
3
O modelo Mbius completo usado nos experimentos de sim-
ulao usados nesta anlise pode ser encontrado no stio
http://www.lsd.ufcg.edu.br/rostand/IaaSModel.zip
15
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
Fator Baixo Alto Efeito Soma dos % Cont.
Estimado Quadrados
A: Limite superior u
o
(em fatias) para 36 108 0, 0624 0, 0312 6, 53
B: Limite inferior k
i
(em fatias) para

i 120 360 0, 0315 0, 0080 1, 66
C: Mdia
d
(em fatias) para

d 0, 0625 0, 1875 0, 0726 0, 0421 8, 83
D: Mdia
t
(em fatias) para t 0, 125 0, 375 0, 0220 0, 0039 0, 81
E: L (em quantidade de recursos) 20 100 0, 2143 0, 3673 77, 05
Table 1. Fatores, nveis e efeitos para DoE 2
k
fatorial (k = 5)
t T). Os nveis atribudos para o experimento fato-
rial so apresentados na Tabela 1.
Foram conduzidas vrias repeties dos 32 experi-
mentos para obter mdias com 95% de intervalo de con-
ana com erro mximo de 5% para mais ou para menos.
Acontribuio de cada fator est exibida na Tabela 1, com
destaque para o fator predominante L que teve partici-
pao de 77, 05%. A nica interao relevante (acima
de 0, 5%) foi BC que apresentou uma contribuio de
2, 53%. Como resultado da anlise dos efeitos atravs de
ANOVA [9], o F-Value de 158, 6521 implica que o mo-
delo signicativo. O R
2
ajustado indica que o modelo
explica 96, 83% da variao observada e o R
2
de predio
est dentro de 0, 20 do R
2
ajustado, representando uma
boa capacidade de predio do modelo. Maiores detalhes
sobre este estudo, incluindo os grcos de diagnstico,
cubo e interao, podem ser encontrados no mesmo en-
dereo citado na Seo 5.1. De acordo com os resultados,
a variao dos quatro primeiros fatores no afetou o com-
portamento da varivel de resposta que ocorreu emfuno
da variao de L.
Para a realizao das simulaes, os valores destes
quatro parmetros foram ajustados para os valores me-
dianos entre os nveis Alto e Baixo usados no DoE
e para os parmetros Percentual de Atividade Even-
tual, Percentual de Usurios com Perl BoT, Nmero
de Usurios Ativos e L foi aplicada uma varredura de
parmetros. A Tabela 2 mostra como o sistema foi con-
gurado para os experimentos.
6. RESULTADOS E ANLISE
No primeiro experimento, o objetivo foi observar
como a lucratividade do provedor era impactada com o
aumento do limite imposto pelo provedor (L). Nesse
experimento ns consideramos uma situao em que a
disponibilidade do provedor deve ser mantida em 100%.
Para tal, a estratgia de alocao (A) simulada tal, que
para qualquer fatia t, sempre possvel alocar recur-
sos para um usurio u que tenha uma demanda positiva
(d(u, t) > 0) e, portanto, a(u, t) = d(u, t)u U 1
t t. Dessa forma, considerando a Equao 2, como
as penalidades sero nulas e a receita lquida da execuo
de uma mesma carga de trabalho constante, o lucro do
provedor afetado apenas pela capacidade que precisa ser
mantida para atender o nvel de disponibilidade desejado.
Para garantir condies similares de carga do sistema, o
nmero de usurios ativos foi mantido constante para este
experimento em 5.000 usurios. Entretanto, foi feita uma
varredura dos parmetros Percentual de Atividade Even-
tual e Percentual de Usurios com Perl BoT para si-
mular diferentes cenrios de atividade regular e eventual e
diferentes participaes dos usurios com perl BoT. Esta
classe de usurios especialmente interessante para esta
anlise porque possuem cargas de trabalho de alto volume
e sensveis ao tempo e tendem a consumir todo o limite
mximo de alocao de recursos permitido.
Para cobrir todas as combinaes dos parmetros de
entrada foram realizadas 288 simulaes - repetidas at
que as mdias obtidas tivessem 95% de intervalo de con-
ana e erro mximo de 5% para mais ou para menos. A
resposta de interesse observada foi a utilizao mxima
(max((t))) observada em todas as fatias de tempo de
cada congurao do sistema simulado, j que esta de-
ne a capacidade mnima necessria para garantir 100%
de disponibilidade. Parte dos resultados obtidos esto e-
xibidos gracamente na Figura 6.
Como pode ser observado, mesmo assumindo uma
populao de tamanho constante, a capacidade mnima
necessria aumenta medida que o limite incremen-
tado. Esta demanda por maior capacidade instalada as-
sociada com o aumento da alocao mxima de recursos
por usurio j est presente mesmo em cenrios onde a
atividade regular dominante (25% de usurios eventuais
e 10% com perl BoT). Onde a atividade eventual mais
preponderante com95%, dos quais 25%dos usurios pos-
suem perl BoT, o aumento necessrio da capacidade ins-
talada chega a representar quase o dobro.
O segundo experimento teve como nalidade obser-
var como o incremento na capacidade instalada afeta o
nvel de utilizao do sistema. Usando os valores de
max((t)) obtidos no experimento anterior como a ca-
pacidade instalada do provedor (K), os mesmos cenrios
foram novamente executados (288 simulaes, mdias
com 95% IC e erro mximo de 5%) para obter a ociosi-
dade apresentada pelo sistema. A ociosidade repre-
sentada pela razo entre a utilizao total observada em
16
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
Parmetro Valor
Durao da Sesso () l
o
= 1 hora e u
o
= 72 horas
Intervalo entre Sesses (

i) k
i
= 240 horas e s
i
= 2
Durao da Atividade (

d)
d
= 0.125 (8 horas)
Espera entre Atividades ou think time (

t)
t
= 0.25 (4 horas)
T 8.760 horas (1 ano)
Nmero de Usurios Ativos (|U
a
|) { 625; 1.250; 2.500; 5.000 }
Percentual de Atividade Eventual { 25%; 35%; 45%; 55%; 65%; 75%; 85%; 95% }
Percentual de Usurios com Perl FlashMob 1%
Percentual de Usurios com Perl BoT { 10%; 15%; 20%; 25% }
Limite (L) { 20; 30; 40; 50; 60; 70; 80; 90; 100 }
Ticket Mdio () 2 recursos
Table 2. Parmetros Usados na Simulao
T e a capacidade total disponvel no mesmo perodo:
(

T
t=1
(t)
KT
). Os resultados obtidos indicaram uma vari-
ao da ociosidade proporcional variao do limite, com
amplitude variando consistentemente de 20% a 65% de
capacidade ociosa em todas as combinaes de atividade
eventual e perl BoT simuladas. A Figura 7 ilustra a
ociosidade encontrada em trs cenrios de atividade even-
tual, todos com 10% de usurios com perl BoT.
Este aumento proporcional da ociosidade com o au-
mento do limite ganha um impacto signicativo nos cus-
tos do provedor. Considerando o preo cobrado pelo prin-
cipal provedor de IaaS e usando a frmula para clculo
do lucro (Equao 2), foi realizada uma terceira anlise.
Foram aplicadas diferentes margens de lucro aos valores
obtidos nos experimentos anteriores para identicar a par-
tir de que ponto a operao do provedor se torna equili-
brada, ou seja, sem lucro nem prejuzo, em cada cong-
urao. Foi observado que medida que o limite in-
crementado o ponto de equilbrio da operao s al-
canado quando a margem de lucro tambm aumen-
tada, com reexos diretos na competitividade do prove-
dor. Na Figura 8, que traz o estudo referente a variao
de 25 a 75% de atividade eventual e com 10% de usurios
com perl BoT, pode ser visto que a margem de lucro
necessria para empatar receitas e despesas chega a 300%
no maior valor considerado para o limite.
Os mesmos experimentos foram repetidos para quan-
tidades diferentes de usurios ativos para observar se
havia variao do comportamento em escalas diferentes.
Como pode ser observado na Figura 9, as curvas so bas-
tante similares para os valores entre 625 e 5.000 usurios
quando so mantidas as mesmas condies de limite e
pers de atividade
4
.
4
5.000 foi o mximo de instncias do modelo que a ferramenta suportou
simular.
7. CONCLUSO
A partir da modelagem de um provedor de IaaS e da
gerao de uma carga de trabalho sinttica, ns simu-
lamos diversos cenrios de utilizao. A anlise dos re-
sultados aponta que no s a atribuio de um limite para
alocao de recursos necessrio como o valor atribudo
tem impacto relevante nos investimentos necessrios em
infraestrutura para garantir umnvel adequado de disponi-
bilidade do provedor. Tambmfoi observado que usurios
com utilizao eventual e intensa pressionam a capaci-
dade mnima necessria e aumentam a ociosidade do sis-
tema, aumentando os custos operacionais do provedor.
Mantido o mesmo perl da populao e o mesmo valor de
limite, a dinmica do sistema independe da quantidade de
usurios no sendo, portanto, um contexto onde a econo-
mia de escala possa signicar uma melhoria direta.
O uso de modelo mais prximo da realidade, mesmo
com o impacto na sua tratabilidade, nos pareceu a opo
mais adequada para este estudo. Para mitigar a comple-
xidade do modelo e a inexistncia de dados de campo,
usamos tcnicas como o design de experimento, para
identicar as variveis independentes mais importantes, e
a varredura de parmetros para instanciao de um amplo
espectro de cenrios. Obtivemos resultados consistentes
em todos os cenrios simulados.
Os resultados ajudam a entender a necessidade do uso
de um limite e como o seu impacto na lucratividade do
provedor est diretamente relacionado com o padro de
utilizao da populao de usurios, nos fazendo con-
cluir que algumas categorias de usurios/aplicaes que
se beneciariam de uma elasticidade mais ampla, conti-
nuaro sendo mal servidas se o modelo atual de provi-
sionamento de recursos for mantido.
Os prximos passos da nossa pesquisa incluem a
investigao de alternativas para minimizar os custos
envolvidos com a disponibilidade de capacidade pelos
provedores. Estes custos so umdos principais obstculos
para a oferta de elasticidade em condies mais exveis,
mesmo que ainda limitada, mas que permitam que classes
17
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
(a)
(b)
(c)
Figure 6. Capacidade mnima para atender 100% dos pedidos dos
usurios em diferentes cenrios de limite (L), Percentual de Atividade
Eventual e Percentual de Usurios com Perl BoT
de aplicaes de uso intenso possam se beneciar das
vantagens do modelo de computao na nuvem. A des-
coberta, federao e revenda de recursos j amortiza-
dos em outros contextos podem representar um caminho
promissor, pois se baseiam na existncia de capacidade
ociosa em contextos onde os custos de disponibilidade
j foram absorvidos por outros negcios ou nalidades.
Dentre estes contextos com capacidade de processamento
ociosa e amortizada, podemos citar data centers privados,
grades P2P e recursos computacionais no convencionais,
como dispositivos mveis, telefones celulares, receptores
de TV Digital etc.
O maior desao dotar os provedores comerciais
de computao na nuvem com mecanismos, tecnolgi-
cos e comerciais, que permitam a montagem dinmica
de infraestruturas computacionais sobre estes recursos de
forma a atender aplicaes com diferentes requisitos de
(a)
(b)
(c)
Figure 7. Ociosidade observada com a variao de limite para
diferentes cenrios de Atividade Eventual e com 10% de usurios com
perl BoT
QoS e com diferentes expectativas de custos.
Agradecimentos
Os autores gostariam de agradecer a Jacques Sauv
pelas vrias sugestes sobre o modelo de simulao e o
gerador de cargas de trabalho sintticas e a equipe do
Mbius pelo prestativo suporte no uso da ferramenta.
Francisco Brasileiro gostaria de agradecer o apoio nan-
ceiro do CNPq.
References
[1] Amazon. Amazon Web Services, 2010.
[2] Arun Anandasivam, Stefan Buschek, and Rajkumar
Buyya. A Heuristic Approach for Capacity Control
in Clouds. In 2009 IEEE Conference on Commerce
and Enterprise Computing, July 2009.
18
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
Figure 8. Equilbrio do resultado operacional com diferentes valores de
limite
[3] Luiz Andr Barroso and Urs Hlzle. The Case
for Energy-Proportional Computing. Computer,
40(12):3337, December 2007.
[4] W. Cirne, D. Paranhos, L. Costa, E. Santos-Neto,
and F. et al Brasileiro. Running Bag-of-Tasks ap-
plications on computational grids: the MyGrid ap-
proach. IEEE, 2003.
[5] D.D. Deavours, G. Clark, T. Courtney, and D. et al
Daly. The Mobius framework and its implementa-
tion. IEEE Transactions on Software Engineering,
28(10):956969, October 2002.
[6] Dror G Feitelson. Workload Modeling for Computer
Systems Performance Evaluation. Hebrew Univer-
sity of Jerusalem (Online Book), 0.30 edition, 2009.
[7] Albert Greenberg, James Hamilton, David a.
Maltz, and Parveen Patel. The cost of a cloud.
ACM SIGCOMM Computer Communication Re-
view, 39(1):68, December 2008.
[8] A J G Hey and A E Trefethen. The Data Deluge: An
e-Science Perspective, chapter 36, pages 809824.
Wiley and Sons, 2003.
[9] Raj Jain. The Art of Computer Systems Performance
Analysis. John Wiley and Sons, 1991.
[10] Jaeyeon Jung, Balachander Krishnamurthy, and
Michael Rabinovich. Flash crowds and denial of
service attacks. ACM Press, New York, New York,
USA, 2002.
[11] Xinhui Li, Ying Li, Tiancheng Liu, Jie Qiu, and
Fengchun Wang. The Method and Tool of Cost
Analysis for Cloud Computing. 2009 IEEE Interna-
tional Conference on Cloud Computing, September
2009.
[12] Daniel A Menasc and Paul Ngo. Understanding
Cloud Computing: Experimentation and Capacity
Planning. In 2009 Computer Measurement Group
Conference, 2009.
(a)
(b)
(c)
(d)
Figure 9. Resultados de Capacidade Mnima e Ociosidade para 625 e
5.000 usurios
19
Rostand Costa, Francisco Brasileiro, Guido
Lemos, Dnio Mariz
Uma Anlise do Impacto da Elasticidade no
Lucro de Provedores de Computao na Nuvem
[13] L. Mieritz and B Kirwin. Dening Gartner Total
Cost of Ownership, 2005.
[14] Martin Sevior, Tom Field, and Nobuhiko
Katayama. Belle monte-carlo production on
the Amazon EC2 cloud. Journal of Physics:
Conference Series, 219(1):012003, April 2010.
[15] Katarina Stanoevska-Slabeva and Thomas Wozniak.
Cloud Basics: An Introduction to Cloud Computing.
Grid and Cloud Computing, pages 4761, 2010.
[16] David Talby. User Modeling of Parallel Workloads
by User Modeling of Parallel Workloads. Hebrew
University of Jerusalem (PhD Thesis), 2006.
20