如何用服务等级协议SLA来评估系统

如何用服务等级协议SLA来评估系统

本文是笔者订阅学习了极客时间蔡元楠老师的专栏《大规模数据处理实战》，总结添加一些自己的学习心得后整理而成。

什么是SLA服务协议

SLA（Service-Level Agreement）是服务等级协议，指的是服务提供商对于服务使用者的服务承诺，常常用来衡量服务是否健康的标准。

形象的来说，就像是使用者寻求某一项服务，而该服务可以由多个服务商可以提供，但是不同的服务商可以提供的服务可以实现不同的效果，而各个服务商可以拿着竞标文件介绍自家的服务，而SLA就是类似于服务商提供的竞标文件。

反过来说，作为分布式系统的设计者与开发者，我们也用SLA协议来衡量自己开发设计的分布式系统可以提供什么样的服务。

SLA服务协议的指标

定义SLA服务协议的指标可以由很多种，常见的四个有：可用性，准确性，系统容量和延迟。

可用性（Availiablity）

可用性，通常指的是系统可以正常运行所占用的时间百分比。

• 如果一个系统在任何时间都可以正常运行，则将该系统称为100%可用性。
• 但是在实际情况中，实现一个100%可用性的系统是不太可能的，因为难于避免的系统需要维护，或者系统需要迭代升级。
• 更现实的情况下，一个4个9 可用性的系统即可认定为是高可用性的系统。4个9 的系统指的是系统在运行一年的时间里边，大约有50分钟的系统不可用时间。
• 99.9% 可用性的系统在一天的运行时间内，有约86秒的时间是处于非正常运行的状态。（24 * 60 * 60 * 0.001 = 86.4 秒）

准确性（Accuracy）

准确性指的是我们所设计的系统服务中，是否允许某些数据是不准确的或者是丢失了的。如果允许这样的情况发生，用户可以接受的百分比是多少？

• 很多时候系统架构以错误率来衡量准确率。
  • 错误率 = 导致系统内部产生错误的有效请求数/ 期间内有效请求总数
• 不同的服务商对于错误率的定义可以不同，比如说可以定义每年错误率高于5%的时间占比多少，或者某一段时间内错误率是多少。
• 也正因为如此，在对比不同的服务的时候，在知道提供商对于错误率如何定义的前提下，仍需要通过查看系统日志或者性能测试的方式来评价该系统的准确率。

系统容量（Capacity）

一般指的是系统能够承受的预期负载是多少，一般以QPS（Queries Per Second）或者 RPS（Requests Per Second）为单位

• 如何准确的定义出系统的QPS
  • 对系统进行性能测试
    • 可以使用像Apache JMeter一类的工具进行性能测试，可以测出系统的QPS是多少。
    • 但是可能出现的情况是，如果使用同一类型的请求参数，导致后台服务器在多数情况下命中缓存，进而得出不准确的QPS。
    • 举个例子，在第一次请求之后，请求参数会保存在内存中，如果后续的请求参数保持一致， 该请求则不需要查询数据库，因此在进行性能评估时候需要格外注意避免请求参数一致的情况。
  • 分析系统在使用过程中的产生的日志
    • 可以通过统计系统在最繁忙时候的请求数目，来计算系统的QPS
    • 但是这种方法不一定可以得到系统承载的最大QPS，只能找的到系统QPS的极大值，但是不一定是系统的最大值点。
  • 想要得到系统的最大QPS，最好的方式还是系统性能测试加日志分析的方式。
  • 另一种方式是进行限流的方式，可以使用扩展库内自带的方法来定义每秒最多发送多少请求到后台处理。但是如果该值设定的过高，会导致内存溢出。

延迟（Latency）

系统延迟指的是系统收到用户的请求到对该请求作出响应的时间间隔

• 常见的定义SLA 延迟性的指标为P95 或者 P99 的延迟声明。
• P指的是percentile，如果一个系统的P95为1秒，则表示在100个请求中，95个请求的延迟是小于1秒的，而5个请求的时间是多于1秒的。
• 当P95 或者P99 过高时，就会有5% 或者 1% 的用户会抱怨系统的体验太差，这都是我们需要通过优化系统来实现的。
• 为了降低系统的延迟，可以将数据库中的数据放入缓存中，以此来减少数据库的读取时间。
• 而我们可以通过改进缓存策略来提高命中缓存率，或者通过优化数据库的schema或者索引index来降低P95 或 P99 延迟。

参考文献

分布式系统（上）：学会用服务等级协议SLA来评估你的系统