Business-Driven Long-Term Capacity Planning for SaaS Applications
IEEE Transactions on Cloud Computing
, 2015 CCF C类
目标：使得SaaS provider的利润最大化
设想的场景：一个SaaS服务商向IaaS服务商拿取资源。云服务有按需付费（on-demand）和预付费(reservation)两种，前者昂贵、不可获得但是灵活，后者便宜、保证获得但是只能按时购买。因此如何选择预付费资源的购买数量和时间是很重要的。
这也是我看到的第一篇
3 Utlity Model
没什么好说的，这个建模挺标准的，但是没什么新意。不过这居然是微观经济学的模型，让我有点没想到。
4 Capacity Planning Heuristics
采取了两种容量计划的启发式方法:
- 一种基于instance utilization(UT)
- 一种基于Queueing Theory
两种都接受一个未来时间段D中流量的预测结果。D即为计划的时间（长时间，比如一年）
4.1
QT方法：实际上是一种替换方法，即已经知道未来需要多少on-demand的资源，该如何确定reservation资源的数量。
- 开始的时候，算法会为每个资源类型计算：对于预付费的资源，用多久才能与按需付费的资源单位时间消耗的金钱是相等的（最小利用率minimal utilization rate）。这个比例根据on-demand的价格与reservation fee来计算。
- 不同的服务商提供的不同种类的VM，这个比例是不同的。算法会按照顺序排序，使得最值得被预付费的资源排在最前面。（Q：没有考虑到实际性能，而且默认厂商是按照实际性能来给on-demand规定价格的；然而不同厂商的定价策略是不一样的，有些厂商可能就是预付费定价会便宜很多，也可能会出现on-demand极其昂贵的无用资源反而排的很前的情况）
- 对于每一种资源，去计算出它的平均使用率（即在目前的预付费策略内，资源被需要的比例）。选择刚好大于前面最低资源比例的那个market。
- 调整剩余on-demand资源值，更新向量
这个算法很像避免死锁的银行家算法，这样通过多次迭代一定是能够起到优化作用的。但问题的关键其实是在于究竟如何去估计on-demand所需要的资源数量。文章说它能够对一年的reservation进行估计，我表示深切地怀疑。
因为时间问题，我没有具体看它的实验部分，不过与我预想的比较类似，设计的还不错，但是与我需要的相差甚远，可以参考一下（特别是直接对于预测式算法预测误差的假设）