读书笔记：Web容量规划的艺术

第1章 容量规划的目标、问题和过程

了解你的基础设施中每一部分何时会失败（最好不发生）对容量规划至关重要。

假设你有一台数据库服务器用于响应从前端Web服务器提交过来的查询。容量规划意味着你应该知道下述问题的答案。

  • 考虑到特定的硬件配置，数据库服务器每秒可管理多少个查询？
  • 在性能降低到影响终端用户体验之前，它每秒可应答多少次查询？

性能与容量：两种不同的概念

性能调优是优化已经存在的性能。容量规划通过使用当前性能做为基线决定你的系统需要什么以及什么时候需要。

当面对容量问题的时候，试着少花精力使已存在的设备运行更快，而是关注当下要解决的重点：找出你到底需要什么，什么时候需要。

权衡对已有系统进行调优所花的人力时间，可能简简单单的买更多的硬件是正确的。在最优化和容量扩展方面的权衡是一个挑战，并且因环境而异。

网站的架构和架构对容量方面的影响

你的驾车风格会影响到你的车的里程，类似的原理能够应用于网站的架构上。在本书中一个反复出现的主题是你的网站架构对于如何使用、消耗 和管理容量产生重大影响。在有效使用容量上，相比于调整和改变你的服务器和网络，设计能带来更大的影响。同时，随着需求的出现如何方便和灵活 地进行增加或者减少容量，也是设计能带来的重要作用。

调整架构以便更容易容量管理。保持你的架构易于分割和分段，可以帮助你处理大量的负载特性问题---即在你创建了一个需要增长什么和何时增长的准确规划之前， 你需要解决的问题。

通过开放API所提供的Web服务引入了另一个逐渐扩大的问题，因为你的应用程序数据会被更多的应用程序访问，它们也都有自己的使用和增长模式。 这也意味着用户可以方便地滥用系统，从而将更多不确定因素放入容量公式中。API的使用情况需要监控，以观察新出现的模式。

容量规划可以变得非常重要，但是并不困难，你所需要做的只是稍微关注一下正确因素。容量规划的过程可分解为：

  1. 设定你的目标
  2. 收集对应的指标并找出你所面临的限制
  3. 绘制趋势并根据那些指标和限制做出预测
  4. 容量部署和管理

第2章 设定容量目标

服务等级协议(SLA)

服务等级协议百分比和可接受的宕机时间

正常运行服务等级协议 每年的宕机时间

90.0% 36天12小时

95.0% 18天6小时

99.0% 87小时36分钟

99.50% 43小时48分钟

99.90% 8小时45分钟36秒

99.99% 52分钟33秒

99.999% 5分钟15秒

99.9999% 32秒

业务容量需求

在当今Web 2.0这样的网络现象中，由于大多数Web服务为个人应用程序开发者提供开放的API接口，以建立基于他们的B2B关系。因此，很多企业 通常把收入流寄托于方便的使用API。这也意味着企业关系依赖于一定程度的API的可用性或者性能，以可用性百分比来测量或者经过协商的API请求的频率。

架构决策

你的架构是关于你所有的后端组件（包括硬件和软件）是怎样结合的基本的设计。架构的设计对于规划和管理容量起到至关重要的作用。

推荐书籍：

  • Building Scalable Web Sites (《构建可扩展网站》)
  • Scalable Internet Architectures (《可扩展的网络架构》)

提供测量点

不管是为了测量的目的，还是对变化的环境快速响应，你都希望你的架构设计完美，以便你能将它分割成不同的部分来执行离散的任务。 在一个理想的情况下，后端的每个组件都有一个单独的工作要做，但如果需要，它也可以很好地执行多个工作。同时，它对每个工作的影响也可以很容易的被测量。

你会发现，简单的架构改变可以帮助你理解你的容量被使用的用途是什么。当你在考虑架构设计时，一定要记住：分工以及“分块、松耦合”原理， 可以一直在你的站点是如何被使用的方面给你一些线索。

硬件决策(垂直缩放比例、水平缩放比例、对角缩放比例)

为你架构中的每一个部件选择正确的硬件可以对成本产生很大影响。

能够横向扩展意味着该架构能简单地通过在现有的基础设施上添加相同功能的网络节点从而达到增加容量的目的。

能够纵向扩展则是指一种通过在服务器内部添加硬件资源从而达到扩充容量目的。这些硬件资源包括CPU、内存、硬盘和网络。

对角扩展是指对基础设施中已有的横向扩展节点进行纵向扩展的过程。

第3章 测量：容量的单位

认可测量本身带来的影响

为了采集和传输度量指标，一些系统资源就会被消耗。好的监测工具努力做得很轻量，不妨碍系统的主要工作，但是总会有一些额外开销。

监测可作为识别紧急问题的工具

当我们的站点出现错误的时候，如果能够迅速地获取状态信息是非常重要的。可能你想能够得到如下这些问题的快速回答：

  • 是什么错误？
  • 错误是何时发生的？
  • 是什么引发了错误？

负载均衡

负载均衡器基于一个相对简短的算法列表来建立负载分发，使得你能指定协议来达到跨越所有可用的服务器均衡地处理流量。

就我们的目的而言，负载均衡器为容量管理提供了一个非常理想的框架，因为通过它可以在生产环境中方便地进行容量的伸缩。

应用程序监测

服务器统计数据只是描绘了容量图的一部分。你还应该特别针对你的应用程序，测量并记录高级别的度量指标---不是针对一个服务器，而是对整个系统。

数据库容量

基本的服务器统计数据之外，还有一些数据库特定的指标你需要跟踪：

  • 每秒的查询（SELECT, INSERT, UPDATE, 和DELETE）
  • 当前打开的连接数
  • 复制时主从数据库之间的滞后时间
  • 高速缓存命中率

规划数据库（特别是集群的数据库）的容量需求是一件棘手的事情。确定你数据库的性能上限非常困难，因为可能有些隐藏的极端问题仅在一些边缘情况下才会暴露出来。

但对于数据库而言，性能调优是非常重要的。数据库的性能通常更多依赖于你的方案和查询而不是硬件的速度。

缓存系统

在Web架构中，缓存最经常被用于存储数据库结果（比如用Memcached）或实际文件（比如用Squid和Varnish）。

影响缓存容量的两个主要因素是你的工作集的大小，以及你的数据动态变化的程度。缓存有一个固定的大小。可缓存对象的工作集是指在给定时期内请求的独特对象的数目---不管数据库结果还是文件。 理想的情况是，你将拥有足够的缓存容量来处理整个工作集。这意味着绝大多数的缓存请求会命中。

在Flickr，我们使用Squid作为反向代理来缓存照片。我们使用更慢、更便宜、更大容量的磁盘来存储照片，但是利用缓存系统来提供照片，这些缓存系统使用的是更小但更快的磁盘。 随着照片请求率增长，我们横向扩展缓存服务器的数量。随着照片数量的增长，我们还横向扩展后台存储的数量。

跟踪任何缓存软件最重要的度量指标是：

  • 缓存命中率
  • 总请求率
  • 对象平均时间
  • LRU参考时间(当使用LRU方法时)

API的使用率及其对容量的影响

有一些方法来测量并记录每个用户或者每个请求方法对开放的API的使用量，这对于那些提供API接口的网站进行容量跟踪，应被视为必须的。 通常通过独特的API key，或者是其他独特的凭据来进行。每次调用API，通过key就能识别出应用程序和负责构建应用程序的开发者。

因为产生大量的API调用比使用常规的客户端浏览器要容易得多，你应该跟踪哪个应用程序正在以何种速率调用什么API。

在Flickr，我们根据在服务条款中列出的规定，使那些看起来滥用API的key自动失效。

基础架构的每一部分都将花费系统资源来为网站服务，你应该确保对这些资源进行适当的测量。然而，记录正确的测量并不足够。 你还需要知道何时那些资源将耗尽，这也是为什么你需要定期地探测并建立这些上限。

通过寻找基础架构上限的实践过程，可暴露出你甚至不知道的瓶颈。基于此，你可能需要改变应用程序、硬件、网络或造成问题的其他部分。 每次你对基础架构做一次修改，都需要再次检查上限，因为它们也很有可能改变。这不应该令人惊奇，因为现在你知道容量规划是一个过程，而不是一次性的事件。

没有测量系统、应用层度量指标的历史数据，则容量规划无法存在。不知道系统的最高性能上限从而避免接近它们，则规划也是没有效果的。 要找到基础架构每部分的上限，需要下面这些步骤：

  1. 测量和记录服务器的主要功能。例如：Apache命中，数据库查询
  2. 测量和记录服务器的基础硬件资源。例如：CPU、内存、硬盘、网络使用量
  3. 判断服务器的主要功能如何与其硬件资源相关联。例如：N个数据库查询占用M%的CPU使用量
  4. 通过以下方法之一，基于服务器的主要功能和硬件资源，找到可接受的最大资源使用量（或上限）：
    • 通过使用负载均衡或应用程序技术，人工（而小心）增加真实的生产负载到服务器。
    • 尽可能确切地模拟一个真实的生产负载。

第4章 趋势预测

预测容量需求部分靠直觉，部分靠数学。

曲线拟合

容量预测的整体过程非常简单：

  1. 确定、测量和绘制对每个资源定义的度量指标 例如：磁盘消耗
  2. 对你拥有的资源应用约束限制 例如：总可用磁盘空间
  3. 使用趋势分析（曲线拟合）说明何时你的使用量会超出限制 例如：找出磁盘空间耗尽的日期

第5章 部署

racp-5.1

附录A 虚拟化和云计算

容量规划的两个目标：一是以最有效的方式来利用你手头上所拥有的资源，二是根据目前的使用模式来预测未来需求。

虚拟化

虚拟化指的是一台计算机的不同层面的计算资源的抽象。实际中，虚拟化通常用于描述OS（操作系统）的抽象。

附录B 对瞬时增长的处理

减轻失败

以下的方法是针对那些最坏情况的场景，当所有其他增加容量的选择都不起作用，并且从根本上改变基础设施本身是不可能的时候。 应该说这种救火似的场景是容量规划所应该极力避免的；但是有些时候它确实是不可避免的。

以下列出的方法并非万能的，当暴发的访问流量来临并且你的服务器在负载下正要挂掉时，能对你有所帮忙。

  • 禁用重量级的功能

一种可能的方法就是禁用站点的一些重量级功能。将打开或者关闭一些功能的能力内建到系统中将帮助你对容量问题做出更加有效的响应， 即使是在那些重大的流量问题事件中。拥有一个快捷的，只有一行简单的打开或者关闭的配置参数在你的应用程序中是有巨大价值的， 特别是当该功能就是问题的起因或者是造成不可接受性能的时候。

  • 烘烤过的静态页面

那些遭遇非常严重流量问题的网站经常采用的另一种技术就是将动态页面转变为静态页面。这可能会很简单也可能会很难，这取决于页面到底有多动态， 但你可以保守的只将那些最常被访问的页面或者动态性最少的页面转换为静态页面。

  • 缓存

附录C 容量工具

  • Ganglia, http://ganglia.sourceforge.net/

  • Nagios, http://www.nagios.org/

  • Dstat，系统统计工具模块化，http://dag.wiee.rs/home-made/dstat/

  • Fabric, http://docs.fabfile.org/, https://github.com/fabric/fabric