QCon北京|3天沉浸式学习,跳出信息茧房。 了解详情
写点什么

在 AWS Well-Architected Tool 中使用无服务器剖析

  • 2020-02-27
  • 本文字数:1954 字

    阅读完需:约 6 分钟

在 AWS Well-Architected Tool 中使用无服务器剖析

当您在云中构建和运行应用程序时,您问自己“我做得对吗”的频率如何?


实际上,这是一个很好的问题,为了让您得到满意答案,我们在 2015 年公开发布了 AWS 架构完善的框架,这是一种将您的工作负载与我们的最佳实践进行比较的形式化方法,并为您提供有关改进方法的指导。如今,架构完善的框架为客户和合作伙伴设计和评估云架构提供了一种一致的方法,该框架基于以下五大支柱:


  • 卓越运行

  • 安全性

  • 可靠性

  • 性能效率

  • 成本优化


为了提供更多针对特定工作负载的建议,我们跳出传统视角,在 2017 年使用“剖析”概念扩展了框架,进入了特定的技术领域。目前,您可以使用三种剖析:


  • 无服务器

  • 高性能计算 (HPC)

  • IoT(物联网)


要进行改进,首先要做的事情是决定要衡量的方面以及如何衡量。为了让您以更结构化的方式查看工作负载,我们在 2018 年推出了 AWS Well-Architected Tool,这是 AWS 管理控制台中提供的一种免费工具,您可以在其中定义工作负载,并回答有关五大支柱的问题。


您可以将此 Well-Architected Tool 用于不同用途。例如:


  • 如果您正在处理特定的应用程序,则可以使用该工具来评估风险并找出需要改进的方面。

  • 如果您负责多个应用程序,则可以使用该工具查看所有应用程序的当前状态。


今天,我很高兴地宣布,我们增加了将剖析应用到 Well-Architected Tool 的功能,我们提供的第一个剖析便是无服务器剖析!


**在 AWS Well-Architected Tool 中使用无服务器剖析


**在 Well-Architected Tool 控制台中,我首先定义我的工作负载。我目前正在使用 Amplify 框架为移动应用程序构建后端。这非常简单,但我将使用 DynamoDB 全局表为我的用户存储数据,并且应用程序将在两个 AWS 区域中运行。添加 AWS 账户 ID 为可选操作,但对于了解在多账户设置中部署应用程序非常有用。



现在,我可以选择应用哪种剖析。默认情况下,AWS 架构完善的框架已存在。我会选择无服务器剖析。这将添加一组其他问题,帮助我了解如何按照框架最佳实践设计、部署和构建我的无服务器应用程序。



定义工作负载后,我开始进行审查。我直接跳到无服务器剖析。 新问题涉及在五大支柱。例如,我最喜欢的其中一个问题是性能相关的问题:



控制台右侧会针对每个问题提供资源,可帮助我了解可能的答案和使用的术语。 我选择了我在实施过程中要执行的活动和技术选择,具体为:


  • 我正在使用数据流(如由 Amazon KinesisDynamoDB Streams 提供的数据流)和异步函数调用来提高并发性。

  • 我正在内存中缓存用户的数据,以减少对数据库的访问。我还可以使用 Lambda 函数的 /tmp,或者使用诸如 Amazon ElastiCache 之类的外部数据存储。

  • 当服务集成可以在本机完成作业时,例如当我需要从 Amazon API Gateway 调用 Kinesis Data Firehose 时(这也是在优化我的成本),我会删除函数。


我保存并退出,而且即使我只回答了一个问题,我也从工具中获得了一些反馈。从工作负载概览中,我选择了无服务器剖析。然后我注意到,我需要减轻一项很高的风险。



我在下面就如何解决风险提出了建议,包括根据提出风险的问题的具体建议。对于无服务器应用程序,使用由平台自动扩展的合适容量单位来平衡性能和成本非常重要。



我单击第一个建议,然后收到了针对我的改进计划的具体操作项目。其中涵盖了我可以在无服务器应用程序中使用的不同架构组件,如 Lambda 函数、DynamoDB 表或 API 网关终端节点。在 此我将根据建议使用 Lambda Power Tuning开源工具来微调 Lambda 函数的内存/电源配置。



在制定改进计划之前,我将继续回答所有问题。我现在可以在 AWS 控制台中查看完整报告,或将其下载为 PDF 格式的文件以便与其他利益相关者共享。通过这种方式,我们可以共同规划必要的改进,获得一个成功的无服务器应用程序。



在我们做出改进后,我就可以返回并标记正确的答案,以消除高风险问题。出色的架构是多次迭代的结果。


**现已推出


**无服务器剖析目前已在所有提供 Well-Architected Tool 的区域推出,详情请参阅 AWS 区域表。它可以应用于现有工作负载,也可以用于您在工具中定义的新工作负载。


使用 AWS Well-Architected Tool 不会产生任何成本,您可以使用它来改进您正在处理的应用程序,或查看您所在的部门或区域使用的多个工作负载。


作为首席信息官/首席技术官,您可以将其用作控制面板,呈现您负责的所有应用程序的状态。为了更更轻松地执行这一过程,您可以与其他 AWS 账户共享工作负载,您可以使用该账户在单一视图中呈现多个应用程序。


由于该工具输出的是一份包含风险及风险解决方法的报告,因此您应在应用程序的整个生命周期内使用该工具,尤其是在设计和实施阶段,而不仅仅是在生产阶段使用,因为在生产阶段实施您获得的一些建议可能为时已晚。


本文转载自 AWS 技术博客。


原文链接:https://amazonaws-china.com/cn/blogs/china/new-serverless-lens-in-aws-well-architected-tool/


2020-02-27 16:39602

评论

发布
暂无评论
发现更多内容

TiDB Binlog 支持 Oracle 目标库功能用户手册

TiDB 社区干货传送门

迁移

回顾下Hackathon中的TiCheck

TiDB 社区干货传送门

实践案例

JOIN 查询的执行计划 比较

TiDB 社区干货传送门

性能调优 TiDB 底层架构

TiDB 如何获取集群创建时间

TiDB 社区干货传送门

实践案例 TiDB 底层架构

5分钟搞定 MySQL 到 TiDB 的数据同步

TiDB 社区干货传送门

实践案例

大事务的处理方式对比

TiDB 社区干货传送门

实践案例

【考试指南】TiDB 5.0认证指南之PCTA PCTP

TiDB 社区干货传送门

TiDB 底层架构

TiDB学习之路

TiDB 社区干货传送门

实践案例

TiDB BR 备份至 MinIO S3 实战

TiDB 社区干货传送门

管理与运维

TiDB体系结构

TiDB 社区干货传送门

TiDB 底层架构

TiSpark On Kubernetes实践

TiDB 社区干货传送门

实践案例

使用SPM固定执行计划

TiDB 社区干货传送门

TiDB 元信息管理方式

TiDB 社区干货传送门

TiDB 底层架构

探索TiDB Lightning源码来解决发现的bug

TiDB 社区干货传送门

TiDB 底层架构

记一次TiDB的临时救场

TiDB 社区干货传送门

实践案例

骏彩竞猜分布式解决方案之路

TiDB 社区干货传送门

安装 & 部署

一言难尽的Prometheus监控实践

TiDB 社区干货传送门

实践案例

传统行业数据架构发展变化

TiDB 社区干货传送门

数据库架构选型

关于TiDB数据脱敏的一些想法

TiDB 社区干货传送门

实践案例

前缀索引在特殊场景下的优化尝试

TiDB 社区干货传送门

实践案例 TiDB 底层架构

使用 TiUP 安装部署 TiDB 集群实验流程

TiDB 社区干货传送门

版本升级 集群管理 管理与运维 安装 & 部署 扩/缩容

TiDB监控Prometheus磁盘内存问题

TiDB 社区干货传送门

故障排查/诊断

TiSpark数据写入过程解析(源码解析)

TiDB 社区干货传送门

TiDB 底层架构

TiDB 如何在 LVS FULL NAT 模式下显示客户端真实 IP

TiDB 社区干货传送门

实践案例

高并发请求下 TiDB 集群的业务无损升级

TiDB 社区干货传送门

记一次简单的Oracle离线数据迁移至TiDB过程

TiDB 社区干货传送门

TiDB 在 Cisco Webex 架构中的部署和应用

TiDB 社区干货传送门

TiDB 运维基础操作脑图

TiDB 社区干货传送门

TiDB架构浅析

TiDB 社区干货传送门

TiDB 底层架构

TiDB在个推的落地实践 | 解决热点难题,提升性能超千倍

TiDB 社区干货传送门

性能调优

TiCDC 4.0.15 初体验

TiDB 社区干货传送门

实践案例

在 AWS Well-Architected Tool 中使用无服务器剖析_行业深度_AWS_InfoQ精选文章