导读

在Amazon ECS上构建SaaS解决方案正成为一种日益增长的趋势。开发多租户SaaS应用程序需要解决多个问题，包括租户隔离、租户入驻、租户特定的计量、监控以及其他SaaS相关方面。在本次讨论中，我们将探讨如何在使用Amazon Fargate部署Amazon ECS解决方案时管理多租户方面的问题。

演讲精华

以下是小编为您整理的本次演讲的精华。

在软件即服务(SaaS)领域，与客户建立并维护信任关系至关重要。经验丰富的SaaS架构师Nathan Peck深入探讨了利用Amazon Fargate简化多租户架构的细节，确保在四个关键支柱上保持不渝的信任。

第一个支柱是可用性，这是一个连续的光谱，而不是二元状态。Peck强调了尽量减少停机时间的影响，尤其是在不同用户层级共存的多租户环境中。通过微服务、容器和Amazon Fargate实现隔离，可以将组件分离，确保在某些部分不可用时，其他部分仍可正常运行。这种细胞式架构，具有多个生产部署，可以限制故障的影响范围，从而减轻对客户的影响。Peck举例说明，在三个生产单元中，一个单元发生故障只会影响33%的客户，而剩余66%的客户仍可获得良好的体验。他进一步解释，这种细胞式架构被广泛应用于各种Amazon服务，有些大型服务甚至采用数百个单元来分布客户，将故障影响限制在很小的百分比范围内。

在单个单元内部，采用了节流机制，防止噪音邻居对其他邻居产生不利影响。请求速率限制(如每天1000个请求的配额，每秒50个请求的突发量)、计算消耗上限和底层资源节流相互协作，以维持平衡。Amazon Fargate的每个任务CPU和内存限制(最低可达1/4 vCPU和1GB内存)，加上隔离的微虚拟机，实现了精确的资源控制，防止资源匮乏并确保公平分配。Peck演示了一个场景，其中一个任务的CPU利用率达到95%，而同一单元中的其他任务则保持在25%和65%的CPU使用率，不受影响。

第二个支柱是数据安全性，在SaaS领域至关重要。微服务再次发挥了关键作用，通过限制组件之间的访问，减小了潜在数据泄露的面积。虚拟私有云(VPC)安全组使用细粒度的网络策略限制流量流动，确保只有授权的组件才能相互通信。Peck举例说明，一个面向公网的负载均衡器可以与Web任务通信，但不能与内部API任务通信，反之亦然，实施了严格的网络边界。这种方法被广泛应用于各种Amazon服务，以保护内部API免受公网访问。

借助亚马逊云科技的令牌发放机制，身份和访问管理(IAM)角色不仅可以按服务和容器划分，还可以按租户请求划分。这种创新技术可以防止代码漏洞导致未经授权的跨租户数据访问，即使发生入侵也是如此。Peck举例说明，一段存在漏洞的代码片段未能验证用户身份，可能会暴露敏感数据。然而，令牌发放机制将IAM角色缩小到每个请求的范围，有效缓解了这一风险，确保了数据隔离。例如，一个具有广泛DynamoDB访问权限的任务角色可以缩小到只允许访问以特定租户ID为前缀的数据，如“acme”。Peck指出，在过去8年里，他在亚马逊云科技工作时一直在使用这种方法。

多租户数据隔离模式从共享表到单元表和专用表不等，适用于不同的服务层级。通过利用IAM条件，每个租户请求只能访问自己的数据切片，进一步加强了数据安全性。

审计功能(如Amazon ECS FireLens)可捕获租户身份、访问的资源和其他元数据，从而检测和响应潜在攻击。Peck演示了当一个“恶意用户”试图访问属于另一个租户的数据时，FireLens日志显示了401 Unauthorized错误，为事件响应提供了宝贵的取证信息。他强调了查询自定义元数据(如租户ID、ECS集群和任务详情)的能力，实现全面的审计和取证。

第三个支柱是敏捷性，满足客户期望及时获得新功能的需求。Peck强调减少开销的重要性，以增加开发人员学习和实施新功能的时间，而不是维护现有系统。Amazon Fargate消除了EC2、操作系统和编排器的维护需求，释放了宝贵的资源。Peck引用了一份报告，指出当前影响开发速度最大的因素是变更失败率，而不是编写代码本身，这凸显了在部署期间隔离新代码的重要性。他指出，像Amazon ECS这样的容器编排系统已将这种隔离构建到核心概念中，有助于安全部署和回滚。

亚马逊云科技 Cloud Development Kit (CDK)允许使用熟悉的编程语言和模式以代码的形式供应基础设施。这种方法支持共享和重用基础设施模块，促进协作并加速开发周期。Peck演示了开发人员如何利用预构建的模式和模块化扩展快速部署负载均衡的Fargate服务，简化了基础设施供应过程。他展示了一个使用亚马逊云科技 CDK Containers ECS Service Extensions将不同团队开发的自定义基础设施模块链接在一起的示例，促进了代码共享和可重用性。

第四个也是最后一个支柱是长期可行性，这对任何SaaS业务都是一个关键考虑因素。成本控制对于避免资金耗尽并确保服务的长期持续至关重要。Peck强调了平衡不同定价层级的重要性，因为对高级用户收费过高而对基础层级收费过低，可能会耗尽利润并危及业务的可持续性。他举例说明，大量基础层级用户消耗了不成比例的基础设施资源，仅靠少量高级层级客户的收入难以抵消。

使用CloudWatch Container Insights数据监控租户资源消耗与收入的关系，可以发现不平衡的情况。通过调整每个层级的定价或资源使用量，SaaS提供商可以保持健康的利润率，确保长期可行性。Peck展示了一个分析原始Container Insights数据的仪表板，以确定潜在的节省成本领域。

事件驱动的异步工作负载提供了一个优化成本的机会，只在需要处理工作批次时启动Fargate容量。Peck举例说明，SaaS的某些组件可以延迟处理，允许在处理窗口期间批量处理并高效利用基础设施，从而降低成本，而不会显著影响客户体验。他承认了启动延迟(Fargate大约30秒)与一旦供应就能高效处理大型工作负载之间的权衡，并指出这种方法适用于没有严格SLA的工作负载。

Amazon Fargate提供了几种定价策略来进一步优化成本。使用价格/性能比x86处理器更高的廉价Graviton处理器(由于缺乏超线程而获得更好的性能)可以降低成本。利用Spot实例的空闲容量，以相同价格获得高达3倍的任务数量，是另一种节省成本的方法。Peck演示了一种容量分配策略，使用2个按需任务满足基线需求，4个Spot任务提供补充容量。

在整个演讲过程中，Peck借鉴了真实世界的场景和客户案例，阐释了这些原则的实际应用…

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。