论文部分内容阅读
Roundup是基因组绘图应用之一，用于预测基因、生物体和生物功能之间的进化关系。Roundup使用了计算密集型算法，开发该算法的哈佛大学研究人员在其中结合使用了简单存储服务（Simple Storage Service，S3）、弹性计算云（Elastic Compute Cloud，EC2）和Elastic MapReduce（EMR）等服务，这些服务都由亚马逊网络服务（AWS）提供。为了优化该应用，Roundup团队减少了磁盘输入/输出，削减内存中缓存的使用，还计算了所需要的最佳实例数量。Roundup由此节省了40%的费用，并确保在不影响性能的情况下，可以满足将来计算增长的需要。
如果不进行像Roundup所做的这类优化，应用也许能正常运行，但是进行优化则可能提升应用的可用性、防灾能力，最重要的是降低使用公共云的成本。以下是将应用迁移到公共云时可以采用的五个具体的优化方法。
重构代码
AWS不仅对所用的计算、存储空间和网络宽带收费，而且每当访问存储空间进行读取或写入操作时，它同样要收费。因此，我们应该结合应用中的读取和写入操作，尽可能把它们并为单次操作。这样，当你使用自己的服务器进行读取或写入操作时，就不会产生额外成本。
这种云优化办法的总体效果取决于所签约使用的公共云服务提供商（CSP）的定价方法。然而，无论与哪家CSP签约，重构代码都可以看成是提升应用性能的机会。
优化选择云实例
借助弹性计算云（EC2）建立实例时，可以在不同数量的计算、内存和存储空间之间做一个选择。此外，EC2提供了现货实例（Spot Instance），指那些随时可用的多余容量，而且价格低于普通实例。
在选择之前，我们有必要花点时间对该应用进行一番试验，以便确定所需要的计算、内存和存储空间的最佳数量。这将保证我们在容量或配置方面不会过度开支，还能弄清楚是否应该考虑使用现货实例（或者另一家CSP提供的同类服务）。
注重服务级别
每种应用都有其自己的服务级别要求，也就是它的一般用途和功能。比如说，面向客户的电子商务网站，其服务级别就不同于面向内部员工的门户网站。对照各应用所需的服务级别来评估公共云实例的成本，这也许可以降低和优化公共云成本。
今年6月的一个周五的夜晚，一场突如其来的暴风雨导致亚马逊网络服务（AWS）中断，美国东部地区的许多用户因此无法使用Netflix、Pinterest和Instagram等服务，这对视频网站Netflix的用户影响最大，因为周五晚上通常是需求高峰时段。
在这个事例中，由于视频流服务本身所具有的特性，以及考虑到Netflix的存储量大、带宽密集，如果转而使用亚马逊在其他地区的数据中心也许不现实，但对于那些带宽不太密集又比较关键的服务，可以对其进行优化，以便用备用数据中心来提供服务，而使它们不受这类服务中断事件的影响。
微调自动扩展规则
能够自动上下扩展（增减）服务器实例数量的应用为优化提供了大好机会。比如说，也许有这样一条自动扩展规则：一旦所有目前实例上的处理器利用率达到80%，就会创建一个新实例；一旦处理器平均利用率达到40%，就会运用另一条自动扩展规则。
那我们如何知道80%和40%就是合适的数字？为什么不是85%和35%？如果采用后一条规则，可以创建较少的实例，降低成本。
此外，每个应用对计算、存储空间和带宽都有不一样的要求。因此，其规则要取决于这三个因素的复杂组合，而不单单取决于处理器。我们可以拟定一个对公共云应用和它们所需的服务级别来说看似合理的组合，然后进行测试，并在一段时间内优化这些百分比。
数据库的行优化
像Netflix等应用具有局部的特性，也就是说在大多数情况下，用户只访问符合自己要求的相关数据。Netflix使用AWS的地理区域（Region）和可用分区（Availability Zone），托管运行那些为住在数据中心附近的用户提供服务的服务器。
这些都仰仗于数据库分片（database sharding）技术。该技术可以拆分数据库中的行，并且把不同分区存储在位于不同数据中心的数据库内。这项技术还适用于信用卡处理等应用，因为分片技术可应用于局部使用模式，比如查询一个信用卡持有者的交易或者与一家商户之间的交易。
不需要把所有的数据库行存储在所有的数据库实例中。如果能拆分数据库行，并把它们存储在不同实例中的数据库片段，那么就能充分利用所使用的模式的局部性。这将减少所需要的服务器实例的数量，因而可降低公共云服务的成本。
将应用迁移到公共云时，也许不用任何改动，它就能像平常那样非常顺畅地运行。但如果注意到CSP的收费方式，再结合应用的计算、内存、存储空间和网络带宽的使用模式，就可以轻松减少公共云开支。借助一番代码重构来优化应用本身，也许能提升性能、延长应用的使用寿命；对自己的默认实例做一番试验和微调，加上自动扩展原则，也许能帮助进一步降低CSP收取的费用。
如果不进行像Roundup所做的这类优化，应用也许能正常运行，但是进行优化则可能提升应用的可用性、防灾能力，最重要的是降低使用公共云的成本。以下是将应用迁移到公共云时可以采用的五个具体的优化方法。
重构代码
AWS不仅对所用的计算、存储空间和网络宽带收费，而且每当访问存储空间进行读取或写入操作时，它同样要收费。因此，我们应该结合应用中的读取和写入操作，尽可能把它们并为单次操作。这样，当你使用自己的服务器进行读取或写入操作时，就不会产生额外成本。
这种云优化办法的总体效果取决于所签约使用的公共云服务提供商（CSP）的定价方法。然而，无论与哪家CSP签约，重构代码都可以看成是提升应用性能的机会。
优化选择云实例
借助弹性计算云（EC2）建立实例时，可以在不同数量的计算、内存和存储空间之间做一个选择。此外，EC2提供了现货实例（Spot Instance），指那些随时可用的多余容量，而且价格低于普通实例。
在选择之前，我们有必要花点时间对该应用进行一番试验，以便确定所需要的计算、内存和存储空间的最佳数量。这将保证我们在容量或配置方面不会过度开支，还能弄清楚是否应该考虑使用现货实例（或者另一家CSP提供的同类服务）。
注重服务级别
每种应用都有其自己的服务级别要求，也就是它的一般用途和功能。比如说，面向客户的电子商务网站，其服务级别就不同于面向内部员工的门户网站。对照各应用所需的服务级别来评估公共云实例的成本，这也许可以降低和优化公共云成本。
今年6月的一个周五的夜晚，一场突如其来的暴风雨导致亚马逊网络服务（AWS）中断，美国东部地区的许多用户因此无法使用Netflix、Pinterest和Instagram等服务，这对视频网站Netflix的用户影响最大，因为周五晚上通常是需求高峰时段。
在这个事例中，由于视频流服务本身所具有的特性，以及考虑到Netflix的存储量大、带宽密集，如果转而使用亚马逊在其他地区的数据中心也许不现实，但对于那些带宽不太密集又比较关键的服务，可以对其进行优化，以便用备用数据中心来提供服务，而使它们不受这类服务中断事件的影响。
微调自动扩展规则
能够自动上下扩展（增减）服务器实例数量的应用为优化提供了大好机会。比如说，也许有这样一条自动扩展规则：一旦所有目前实例上的处理器利用率达到80%，就会创建一个新实例；一旦处理器平均利用率达到40%，就会运用另一条自动扩展规则。
那我们如何知道80%和40%就是合适的数字？为什么不是85%和35%？如果采用后一条规则，可以创建较少的实例，降低成本。
此外，每个应用对计算、存储空间和带宽都有不一样的要求。因此，其规则要取决于这三个因素的复杂组合，而不单单取决于处理器。我们可以拟定一个对公共云应用和它们所需的服务级别来说看似合理的组合，然后进行测试，并在一段时间内优化这些百分比。
数据库的行优化
像Netflix等应用具有局部的特性，也就是说在大多数情况下，用户只访问符合自己要求的相关数据。Netflix使用AWS的地理区域（Region）和可用分区（Availability Zone），托管运行那些为住在数据中心附近的用户提供服务的服务器。
这些都仰仗于数据库分片（database sharding）技术。该技术可以拆分数据库中的行，并且把不同分区存储在位于不同数据中心的数据库内。这项技术还适用于信用卡处理等应用，因为分片技术可应用于局部使用模式，比如查询一个信用卡持有者的交易或者与一家商户之间的交易。
不需要把所有的数据库行存储在所有的数据库实例中。如果能拆分数据库行，并把它们存储在不同实例中的数据库片段，那么就能充分利用所使用的模式的局部性。这将减少所需要的服务器实例的数量，因而可降低公共云服务的成本。
将应用迁移到公共云时，也许不用任何改动，它就能像平常那样非常顺畅地运行。但如果注意到CSP的收费方式，再结合应用的计算、内存、存储空间和网络带宽的使用模式，就可以轻松减少公共云开支。借助一番代码重构来优化应用本身，也许能提升性能、延长应用的使用寿命；对自己的默认实例做一番试验和微调，加上自动扩展原则，也许能帮助进一步降低CSP收取的费用。