数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

使用无服务架构,亿级请求的API服务如何将成本降低两个数量级

当我去年加入 Postlight 时,第一个任务是重写转码服务(Readability Parser API)。转码服务为稍后阅读应用程序以及其他服务提供 API 支持,它接受互联网上任何文章的链接,然后返回了该文章的结构化内容展示(它可以从网络上混乱的内容中提取结构化内容)[1]。 

重写的原因有三个:

  1. API 多年来变得老旧而脆弱,解析结果都存储在数据库中,这意味着整个数据库非常庞大。执行稍微复杂的查询都有问题,这意味着我们对 API 内部发生了什么一无所知。同时也存在原始文章如果更改,API 响应将不会包含更新的结果。

  2. 最初作者已经不在公司了,新工程师缺乏必要的领域知识。

  3. 最重要的是这个服务每月要花费公司大约 10,000 美元。

重写的几个目标:

  1. 生成功能相同的库,返回与原始代码相同的结果。

  2. 工程师可以轻松贡献代码。

  3. 减少每月产生的费用。

对于语言,我们选择了JavaScript。选择 JavaScript 意味着代码理论上可以在服务器或浏览器中运行。 公司的每个工程师都有 Web 编程经验,所以选择 JavaScript 也意味着几乎每人都可以给新项目提交代码。 旧的代码是用 Python 编写的,但是 Python 缺乏浏览器运行的优势。

为了大幅度降低成本,我们选择了运行在 AWS Lambda[2] 和 API Gateway[3] 上的无服务器架构,它使用 Serverless 框架[4]来构建和部署。

去年十月,我们发布了 Mercury Web Parser[5],结果令人震惊。我们的成本大幅度下降,Mercury Web Parser 每月的成本约为 400 美元,比老的服务的成本要低两个数量级。 (当然也是因为需求或架构略有不同,以前的费用也包括数据库费用,而现在的无服务器架构使用缓存,因此存在数据库开销。)

以下是我们如何实现的一些细节。

1、使用无服务器架构

假设您以在无服务器环境中满足需求,采用无服务器架构将大大降低成本。简单地转到无服务器环境对降低托管成本有很大帮助。在我们完成改变之后,运行成本降低两个数量级。即使在切换到无服务器架构之后,仍然有降低成本的余地。

如果您对 Lambda 没有任何经验,则其定价将如下所示:

Lambda 免费套餐包含每月 1M 免费请求以及每月 400,000 GB 秒的计算时间。您为 Lambda 函数选择的内存大小决定着它们能以免费套餐运行多久。Lambda 免费套餐在 AWS 免费套餐 12 个月的期限到期后不会自动过期,而是无期限地提供给现有的和新的 AWS 客户。


当您希望在 Lambda上优化成本时,最重要的是该函数分配的内存大小决定运行成本。该成本与执行函数所需的时间成比例增加或减少。

(注意:GB-seconds 是分配给函数的内存及执行时间的计量单位,例如,如果你调用一次 3 秒钟的函数,并且你已经为该函数分配了 1GB 内存, 就是执行了 3GB-seconds 的计算时间,如果将该分配减少到 512MB,执行时间保持 3 秒,则将计算时间缩短到 1.5GB-seconds。)

这意味着您可以通过加快执行函数所需的时间,降低内存分配或两者都用来降低 Lambda 成本。由于我们程序的执行速度已经很不错了,所以降低内存是显而易见的选择。

2、降低内存分配

Lambda 的内存分配范围从 128MB 到 1536MB。降低 Lambda 成本的过程很简单。持续降低您的 Serverless 配置中的 memorySize 分配,部署,然后关注您的函数的执行延迟。如果我们的函数的延迟在几个小时后没有显示出显着的变化,那么我们会保留变化并降低成本。

请记住,每次将函数的内存分配减半时,您的 Lambda 成本大致减半。例如,根据官方的 Lambda 定价计算器,100 万次调用(不包括免费级别),平均运行 2 秒(不快,不是特别慢),分配 1GB 内存,将花费 33.54 美元。如果使用 512MB,将花费 $16.87。 256MB 花费 $8.54。

对于转码服务,我们目前运行的函数使用 256MB 配置。


3、API Gateway Responses 缓存

API Gateway 中的缓存响应可以显著减少 Lambda 调用。 例如,用户通常会为相同的文章发起请求。 我们每个月只需要为 API Gateway(使用 0.5GB 内存,1 小时TTL)支付约 14 美元。 在上个月,API 请求中有 52%(2 千万)由缓存命中返回,这意味着只有不到一半(1870 万请求)需要调用我们的 Lambda 函数,这可以为我们节省 240 美元。


关于可伸缩性的注意事项

除了节省成本之外,无服务器架构也可能会大大降低维护/配置成本以及复杂性。 我们的 API 可以使用相同的配置,缓存和部署方法来为 1,000 个请求到 100,000,000 个请求提供服务。

此外,随着服务的扩展,成本并不一定会增加。 毕竟超过一半的 API 请求可以由我们的缓存提供服务。 

最终成本

在上述所有优化之后,我们目前运行 Mercury Web Parser API 的成本如下所示:

API 网关


  • 服务费用为137美元

  • 缓存:$ 14

  • 数据传输:$ 42(这是以0.09美元/ GB计算)


LAMBDA


  • 请求费用:3美元

  • 计算成本:$ 174(平均2.37s /调用,内存分配256MB)

总成本:$ 370

看好无服务器架构的未来

我们已经使用 Lambda 做了很多事情,从解析网页到编写 Slack 机器人; 从批量转换数十万张照片到转码数十万部影片。

我们越多使用它,就越认为无服务器架构解决了很多问题。到目前为止,Mercury Web Parser 及其所使用的工具一直是我们决定使用无服务器架构的最佳验证。


关于我们的转码服务

在 Postlight,我们使用了 Mercury Web Parser 来支持:

  • Mercury AMP 转换器[6],任何使用 Google AMP 的网站,只需要加入一行代码。

  • Mercury Reader[7] 是超过 100 万用户使用的 Chrome 扩展程序,通过点击按钮可以消除文章中的广告和干扰,只留下任何网站上的文字和图像。

  • Bloomberg Lens[8],Chrome 扩展程序和 iOS 共享表应用程序,其中提供有关网络上任何文章的相关新闻,公司数据和个人信息。

我们还支持数千名每天使用 Mercury 的开发人员从网络上的任何文章中提取结构化内容。 每月完成 3900 万个请求,只需 370 美元。

对于每一百万的请求,花费还不到 10 美元,并且可以轻松地扩容。 

相关链接:

  1. https://trackchanges.postlight.com/extracting-content-from-the-chaos-of-the-web-introducing-the-mercury-web-parser-e920a1db7f86

  2. https://aws.amazon.com/lambda/

  3. https://aws.amazon.com/api-gateway/

  4. https://serverless.com

  5. https://trackchanges.postlight.com/extracting-content-from-the-chaos-of-the-web-introducing-the-mercury-web-parser-e920a1db7f86

  6. https://mercury.postlight.com/amp-converter/

  7. https://mercury.postlight.com/reader/

  8. https://trackchanges.postlight.com/fat-static-and-happy-building-bloomberg-lens-8a458a10ed2a


原文来自:高可用架构

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
使用无服务架构,亿级请求的API服务如何将成本降低两个数量级
发布:2017-07-26

当我去年加入 Postlight 时,第一个任务是重写转码服务(Readability Parser API)。转码服务为稍后阅读应用程序以及其他服务提供 API 支持,它接受互联网上任何文章的链接,然后返回了该文章的结构化内容展示(它可以从网络上混乱的内容中提取结构化内容)[1]。 

重写的原因有三个:

  1. API 多年来变得老旧而脆弱,解析结果都存储在数据库中,这意味着整个数据库非常庞大。执行稍微复杂的查询都有问题,这意味着我们对 API 内部发生了什么一无所知。同时也存在原始文章如果更改,API 响应将不会包含更新的结果。

  2. 最初作者已经不在公司了,新工程师缺乏必要的领域知识。

  3. 最重要的是这个服务每月要花费公司大约 10,000 美元。

重写的几个目标:

  1. 生成功能相同的库,返回与原始代码相同的结果。

  2. 工程师可以轻松贡献代码。

  3. 减少每月产生的费用。

对于语言,我们选择了JavaScript。选择 JavaScript 意味着代码理论上可以在服务器或浏览器中运行。 公司的每个工程师都有 Web 编程经验,所以选择 JavaScript 也意味着几乎每人都可以给新项目提交代码。 旧的代码是用 Python 编写的,但是 Python 缺乏浏览器运行的优势。

为了大幅度降低成本,我们选择了运行在 AWS Lambda[2] 和 API Gateway[3] 上的无服务器架构,它使用 Serverless 框架[4]来构建和部署。

去年十月,我们发布了 Mercury Web Parser[5],结果令人震惊。我们的成本大幅度下降,Mercury Web Parser 每月的成本约为 400 美元,比老的服务的成本要低两个数量级。 (当然也是因为需求或架构略有不同,以前的费用也包括数据库费用,而现在的无服务器架构使用缓存,因此存在数据库开销。)

以下是我们如何实现的一些细节。

1、使用无服务器架构

假设您以在无服务器环境中满足需求,采用无服务器架构将大大降低成本。简单地转到无服务器环境对降低托管成本有很大帮助。在我们完成改变之后,运行成本降低两个数量级。即使在切换到无服务器架构之后,仍然有降低成本的余地。

如果您对 Lambda 没有任何经验,则其定价将如下所示:

Lambda 免费套餐包含每月 1M 免费请求以及每月 400,000 GB 秒的计算时间。您为 Lambda 函数选择的内存大小决定着它们能以免费套餐运行多久。Lambda 免费套餐在 AWS 免费套餐 12 个月的期限到期后不会自动过期,而是无期限地提供给现有的和新的 AWS 客户。


当您希望在 Lambda上优化成本时,最重要的是该函数分配的内存大小决定运行成本。该成本与执行函数所需的时间成比例增加或减少。

(注意:GB-seconds 是分配给函数的内存及执行时间的计量单位,例如,如果你调用一次 3 秒钟的函数,并且你已经为该函数分配了 1GB 内存, 就是执行了 3GB-seconds 的计算时间,如果将该分配减少到 512MB,执行时间保持 3 秒,则将计算时间缩短到 1.5GB-seconds。)

这意味着您可以通过加快执行函数所需的时间,降低内存分配或两者都用来降低 Lambda 成本。由于我们程序的执行速度已经很不错了,所以降低内存是显而易见的选择。

2、降低内存分配

Lambda 的内存分配范围从 128MB 到 1536MB。降低 Lambda 成本的过程很简单。持续降低您的 Serverless 配置中的 memorySize 分配,部署,然后关注您的函数的执行延迟。如果我们的函数的延迟在几个小时后没有显示出显着的变化,那么我们会保留变化并降低成本。

请记住,每次将函数的内存分配减半时,您的 Lambda 成本大致减半。例如,根据官方的 Lambda 定价计算器,100 万次调用(不包括免费级别),平均运行 2 秒(不快,不是特别慢),分配 1GB 内存,将花费 33.54 美元。如果使用 512MB,将花费 $16.87。 256MB 花费 $8.54。

对于转码服务,我们目前运行的函数使用 256MB 配置。


3、API Gateway Responses 缓存

API Gateway 中的缓存响应可以显著减少 Lambda 调用。 例如,用户通常会为相同的文章发起请求。 我们每个月只需要为 API Gateway(使用 0.5GB 内存,1 小时TTL)支付约 14 美元。 在上个月,API 请求中有 52%(2 千万)由缓存命中返回,这意味着只有不到一半(1870 万请求)需要调用我们的 Lambda 函数,这可以为我们节省 240 美元。


关于可伸缩性的注意事项

除了节省成本之外,无服务器架构也可能会大大降低维护/配置成本以及复杂性。 我们的 API 可以使用相同的配置,缓存和部署方法来为 1,000 个请求到 100,000,000 个请求提供服务。

此外,随着服务的扩展,成本并不一定会增加。 毕竟超过一半的 API 请求可以由我们的缓存提供服务。 

最终成本

在上述所有优化之后,我们目前运行 Mercury Web Parser API 的成本如下所示:

API 网关


  • 服务费用为137美元

  • 缓存:$ 14

  • 数据传输:$ 42(这是以0.09美元/ GB计算)


LAMBDA


  • 请求费用:3美元

  • 计算成本:$ 174(平均2.37s /调用,内存分配256MB)

总成本:$ 370

看好无服务器架构的未来

我们已经使用 Lambda 做了很多事情,从解析网页到编写 Slack 机器人; 从批量转换数十万张照片到转码数十万部影片。

我们越多使用它,就越认为无服务器架构解决了很多问题。到目前为止,Mercury Web Parser 及其所使用的工具一直是我们决定使用无服务器架构的最佳验证。


关于我们的转码服务

在 Postlight,我们使用了 Mercury Web Parser 来支持:

  • Mercury AMP 转换器[6],任何使用 Google AMP 的网站,只需要加入一行代码。

  • Mercury Reader[7] 是超过 100 万用户使用的 Chrome 扩展程序,通过点击按钮可以消除文章中的广告和干扰,只留下任何网站上的文字和图像。

  • Bloomberg Lens[8],Chrome 扩展程序和 iOS 共享表应用程序,其中提供有关网络上任何文章的相关新闻,公司数据和个人信息。

我们还支持数千名每天使用 Mercury 的开发人员从网络上的任何文章中提取结构化内容。 每月完成 3900 万个请求,只需 370 美元。

对于每一百万的请求,花费还不到 10 美元,并且可以轻松地扩容。 

相关链接:

  1. https://trackchanges.postlight.com/extracting-content-from-the-chaos-of-the-web-introducing-the-mercury-web-parser-e920a1db7f86

  2. https://aws.amazon.com/lambda/

  3. https://aws.amazon.com/api-gateway/

  4. https://serverless.com

  5. https://trackchanges.postlight.com/extracting-content-from-the-chaos-of-the-web-introducing-the-mercury-web-parser-e920a1db7f86

  6. https://mercury.postlight.com/amp-converter/

  7. https://mercury.postlight.com/reader/

  8. https://trackchanges.postlight.com/fat-static-and-happy-building-bloomberg-lens-8a458a10ed2a


原文来自:高可用架构

×
企业用户认证,
可获得1000次免费调用
注册登录 > 企业账户认证 > 领取接口包
企业用户认证领取接口包 立即领取
× 企业用户认证,
可获得1000次免费调用,立即领取>
数 据 驱 动 未 来
Data Drives The Future