性能效率支柱侧重于有效利用计算资源来满足需求,并随着需求的变化和技术的发展而保持这种效率。
释义
云计算中的性能效率有四个最佳实践领域:
- 选择(计算、存储、数据库、网络)
- 回顾
- 监测
- 权衡取舍
采用数据驱动方法选择高性能架构。从高层设计到资源类型的选择和配置,收集架构各个方面的数据。通过周期性地审查您的选择,您将确保您正在利用不断发展的AWS云。
监控将确保您意识到与预期性能的任何偏差,并可以对此采取行动。最后,您的体系结构可以进行权衡以提高性能,例如使用压缩或缓存,或放宽一致性要求。
最佳实践
话题
选择
SaaS性能1:如何防止一个租户对另一个租户的体验产生负面影响?
在多租户环境中,租户可能具有对系统施加显著不同负载的配置文件和用例。具有新工作负载配置文件的新租户也可能会不断添加到系统中。这些因素使得SaaS公司构建一个能够满足这些租户快速发展的性能需求的架构非常具有挑战性。
处理和管理租户负载的这些变化是SaaS环境性能概要的关键。SaaS架构必须能够成功检测这些租户消费趋势,并应用能够有效扩展以满足租户需求或限制单个租户活动的策略。
有多种策略可用于管理租户可能对系统造成不成比例负载的情况。这可以通过隔离高需求资源、引入扩展策略或应用节流策略来实现。
在最简单和最极端的情况下,您可以考虑为应用程序的部分创建租户特定的部署。图22中的图表说明了一种分解系统以解决性能挑战的方法。
图22:使用孤立服务解决性能问题
在本例中,您将注意到我们有两个不同的部署足迹(一些在思洛存储器模型中,一些在池模型中)。在图的左侧,您将看到为每个租户部署了Product、Order和Cart微服务的单独实例。同时,在图的右侧,您将看到所有租户共享的微服务集合。
该方法背后的基本思想是开发特定的服务,这些服务被视为对应用程序的性能概要至关重要。通过将它们分开,您的系统可以确保任何一个租户的负载不会影响其他租户的性能(对于这组服务)。此策略可能会增加成本并降低环境的操作灵活性,但仍然是实现性能目标的有效方法。同样的方法也可用于解决合规性和隔离要求。
例如,您可以为每个租户部署一个订单管理微服务,以限制一个租户对另一个租户的订单处理体验产生不利影响的能力。这增加了操作复杂性并降低了成本效率,但可以作为一种暴力手段,有选择地针对应用程序关键领域的跨租户性能问题。
理想情况下,您应该尝试通过构造来解决这些性能需求,这些构造可以解决租户负载问题,而不会吸收单独部署服务的开销和成本。在这里,您将专注于创建一个扩展配置文件,使您的共享基础架构能够有效地响应租户负载和活动的变化。
基于容器的架构(如AmazonEKS或AmazonECS)可以配置为基于租户需求扩展服务,而不需要任何过度资源调配。容器快速扩展的能力增强了系统对急剧租户负载的有效响应能力。将容器的扩展速度与AWS Fargate的成本概况相结合,通常是弹性、运营灵活性和成本效率的完美结合,可以帮助组织解决租户的巨大负载,而不会过度配置环境。
使用AWS Lambda构建的无服务器SaaS架构也可能非常适合解决租户负载过高的问题。AWS Lambda的管理特性允许您的应用程序服务快速扩展,以解决租户负载的峰值问题。这种方法可能需要考虑并发性和冷启动因素。然而,它可以代表限制跨租户性能影响的有效策略。
虽然响应式扩展策略可以帮助解决这个问题,但您可能需要采取其他措施,以简单地防止租户施加可能会造成跨租户影响的负载。在这些场景中,您可以选择通过设置限制(可能按层)来检测和约束租户的活动,这些限制将应用节流来控制系统上的负载级别。这将通过引入节流政策来实现,该政策将检查租户的负载,识别超出限制的活动,并限制他们的体验。
SaaS性能2:您如何确保基础设施资源的消耗与租户的活动和工作负载保持一致?
SaaS公司的商业模式通常严重依赖于一种策略,该策略允许他们将基础设施的成本与租户的实际活动相一致。由于SaaS系统中租户的负载和组成不断变化,因此您需要一种架构策略,该策略可以有效地以一种模式来扩展资源的消耗,这种模式非常反映SaaS体验中的这些实时、不可预测的消耗模式。
图23中的图表提供了一个环境的假设示例,该环境已协调了基础设施消耗和租户活动。这里蓝色实线表示租户在一段时间内的实际活动趋势。红色虚线表示为解决租户负载而配置的实际基础设施。
图23:调整租户活动和消费
在理想的环境中,我们的策略是尽量缩小红线和蓝线之间的差距。在这里,您总是有一定的误差余量,因为您有一些缓冲,以确保不会影响系统的可用性或性能。同时,您希望能够提供足够的基础设施,以支持租户当前的性能需求。
这里的关键挑战是,图中显示的负载通常是不可预测的。虽然可能存在一些一般趋势,但您的架构和扩展策略不能假设今天的负载明天甚至未来一小时都会相同。
调整消费与活动的最简单方法是使用提供无服务器体验的AWS服务。这方面的经典例子是AWS Lambda。使用AWS Lambda,您可以构建一个服务器和扩展策略不再由您负责的模型。使用无服务器,您的SaaS应用程序只会产生与租户消费直接相关的费用。如果您的SaaS系统没有负载,那么AWS Lambda将不会产生任何成本。
AWS Fargate还支持基于容器的版本,这是一种无服务器的心态。通过将Fargate与AmazonEKS或AmazonECS一起使用,您只需支付应用程序实际消耗的容器计算成本。
这种使用无服务器模型的能力超出了计算构造。例如,您的解决方案的存储部分也可以依赖于无服务器技术。AmazonAuroraServerless允许您存储关系数据,而无需调整运行数据库的实例的大小。相反,AmazonAuroraServerless将根据实际负载来调整您的环境大小,并且只对您的应用程序消耗的内容收费。
任何让您不再需要创建扩展策略的模型都将简化您的运营和成本体验。您可以将更多的时间和精力集中在应用程序的特性和功能上,而不是继续追求难以捉摸的完美自动缩放配置。这也使该公司能够发展并接受新租户,而不必担心AWS账单的意外增长。
对于无服务器可能不是一个选项的场景,您需要回到传统的扩展策略。在这些场景中,您需要捕获和发布租户消费指标,并根据这些指标定义扩展策略。
回顾
SaaS应用程序没有独特的性能实践。
监测
SaaS性能3:如何为不同的租户层和计划实现不同级别的性能?
SaaS解决方案通常以分层模式提供,租户可以获得不同的体验。性能通常是一个用于区分SaaS环境的层的领域,使用性能作为一种创建价值边界的方式,迫使租户转移到更高级别的层。
在此模型中,您的体系结构将引入用于监视和控制每个层的体验的构造。这不仅仅是为了最大限度地提高性能,还在于限制低层租户的消费。即使您的系统可以容纳这些租户的负载,您也可以纯粹基于成本或业务考虑来限制负载。这通常是确保租户的成本足迹与租户为业务贡献的收入相关的一部分。
解决此问题最简单的方法是引入与单个租户层相关联的限制策略。当租户达到限制时,您将应用限制并限制其消费。
在某些情况下,您可以使用特定的AWS配置来配置租户层的消费配置文件。例如,在AWS Lambda中,可以使用保留并发来限制给定租户层的消耗。图24中的图表提供了如何实现这一点的示例。
图24:使用保留并发控制租户性能
在本例中,我们创建了三个独立的租户层,并为每个层部署了三个不同的SaaS应用程序微服务集合。这些集合还配置有单独的保留并发设置,这些设置用于确定可以为该组函数运行多少个并发函数调用。基本层的保留并发数为100,高级层为300。这里的想法是,我的低端层的消耗将受到限制,将所有剩余的并发留给高级层。
这种方法很好地符合我们的目标,即为我们的首选层提供最佳体验,同时限制较低层消耗多余资源的能力,并影响较高层租户的绩效。
容器还具有解决性能分层问题的独特策略。例如,在AmazonEKS中,您可以配置单独的ResourceQuotas和LimitRanges来控制命名空间中可用的资源量。
虽然这些约束有助于配置租户的性能体验,但一些SaaS应用程序实际上会通过应用程序设计和分解策略来解决性能问题。这可以通过为更高层租户部署孤立的微服务来实现,消除这些特定服务的任何噪音邻居考虑。事实上,您可能会发现,将系统分解为微服务可能会直接受到目标分层和性能配置文件的影响。
在某些情况下,您的SaaS应用程序还可能引入架构结构,以优化更高层租户的体验。例如,想象一下,为高级租户提供关键数据的缓存。通过将缓存仅限于这些用户,可以避免必须支持所有用户的缓存的开销。引入这些优化的努力应该用对客户和业务的足够价值来抵消,以保证投资。
权衡取舍
SaaS应用程序没有独特的性能实践。
资源
请参阅以下资源,以了解有关性能效率的最佳实践的更多信息。
文档和博客
-
Amazon API Gateway: Throttle API requests for better throughput
-
Monitoring CloudWatch metrics for your Auto Scaling groups and instances
白皮书
-
SaaS Storage Strategies Building a Multi-tenant Storage Model on AWS
-
Whitepaper: SaaS Solutions on AWS Tenant Isolation Architectures
视频
最新内容
- 1 week 5 days ago
- 2 weeks 6 days ago
- 3 weeks 2 days ago
- 3 weeks 2 days ago
- 3 weeks 5 days ago
- 3 weeks 6 days ago
- 4 weeks ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago