AWS云服务在现代化按租户账户解决方案中的考虑

主要要点

在现代化SaaS架构时，许多服务提供商正在努力提高资源利用效率并降低运营成本。本文将探讨如何从“按租户账户”模型迁移到“基于Amazon Elastic Kubernetes Service (EKS)”的架构，利用Kubernetes来优化多租户设计，实现更高的成本效率和更好的扩展策略。

隔离的账户与隔离的Kubernetes命名空间

在SaaS环境中，存在多种部署租户的策略。有些环境共享基础设施，而有些不然。这些模型被称为“共享Pooled”和“独立Siloed”。本文关注两种独立模型的变体。

以某SaaS产品为例，该产品需要支持众多客户，每个客户都有其独立的应用，比如一个Web应用。在“隔离的按租户账户模型”中，SaaS提供者会利用一个专用的AWS账户来托管每个租户的工作负载。

每个租户都有自己的Amazon Elastic Compute Cloud (Amazon EC2)实例，组织在自动伸缩组中。对这些EC2实例上应用的访问将通过应用负载均衡器进行。每个租户分配有自己的数据库环境，使用Amazon RDS来实现。网站的存储包括PHP、JavaScript、CSS和HTML文件由连接到EC2实例的Amazon Elastic Block Store (Amazon EBS)卷提供。SaaS提供者拥有一个控制平面AWS账户，用于创建和修改这些租户专用的账户。按租户账户模型使每个账户成为扩展和隔离的单位。

在按租户账户模型中，每个账户都是扩展和隔离的单元。现在，让我们考虑将此环境迁移到“每租户一个命名空间”的模型，其中SaaS提供者可以使用容器化技术将每个网站打包，并利用容器编排工具在共享计算节点EC2实例上部署这些网站。Kubernetes可以作为容器编排工具，并且每个网站将由Kubernetes部署及其相关的Pod表示。Kubernetes命名空间将作为租户特定资源的逻辑封装，每个租户映射到一个Kubernetes命名空间。Kubernetes的HorizontalPodAutoscaler可用于自动扩展，根据工作负载需求动态调整特定命名空间的部署副本数量。

当需要额外计算资源时，Cluster Autoscaler或Karpenter等工具可以动态地向共享Kubernetes集群添加更多EC2实例。应用负载均衡器可以被多个租户共享，用于将流量路由到适当的Pod。对于Amazon RDS，SaaS提供者可以使用租户特定的数据库模式来划分租户数据。可以使用Amazon Elastic File System (EFS)和租户特定目录来处理静态数据。SaaS提供者仍然拥有一个控制平面AWS账户，用于与Kubernetes和AWS API交互，创建和更新租户特定资源。

通过使用Amazon EKS和其他托管服务进行向Kubernetes的迁移带来了诸多优势。它利用Amazon EKS的扩展模型，使得资源利用效率更高，从而降低成本，更好地将租户的消费与租户的活动进行对齐。

Amazon EKS集群规模和客户细分在多租户设计中的考虑

在相同的系统中托管大量SaaS租户会导致“爆炸半径”增大。这意味着系统内的故障可能影响所有驻留租户，导致多个租户同时停机。为了解决此问题，SaaS提供者应考虑在多个AWS账户或EKS集群之间对客户进行分区，每个分区都拥有自己的多租户架构部署。租户数量的多少最终应由SaaS提供者根据租户的消费活动进行分析，以决定在单个集群中可以容纳多少租户。应比较这部分客户的共享风险以及资源共享带来的效益。

Amazon EKS的安全性

SaaS提供者应评估在多租户Kubernetes架构中，是否适合利用容器作为工作负载隔离边界。考虑到在单个EC2实例上运行的容器共享底层Linux内核，因此这尤为重要。安全漏洞可能使共享资源EC2实例受到来自宿主Linux实例的攻击。当任何Kubernetes Pod集群中运行的容器启动不受信任的代码时，这种风险会显著提高。如果SaaS提供者允许租户“带上他们的代码”，就会增加这种风险。

Kubernetes是一个单租户的编排器，但采用多租户SaaS架构时，Amazon EKS控制平面的单个实例将在集群内的所有工作负载之间共享。Amazon EKS把集群视为硬性隔离的安全边界。每个Amazon EKS管理的Kubernetes集群都在一个专用的单租户Amazon Virtual Private Cloud (VPC)中隔离。目前，只有为每个租户提供一个独特的集群，才能实现硬多租户的实施。

考虑如何使用AWS Fargate来满足安全需求。还可以探索如何通过应用权限限制跨命名空间的访问，并将IAM角色与我的命名空间关联，以限定对其它租户基础设施的访问。

Amazon EFS的考虑因素

SaaS提供者可能会考虑使用Amazon EFS作为多个租户的静态内容存储解决方案。这为他们提供了一个简单、无服务器且弹性的文件系统。可以使用目录来分离每个租户的内容。

尽管在Amazon EFS中创建租户特定目录提供了许多好处，但在收集每个租户的利用率和性能指标时可能会遇到困难。这可能给需要细化资源使用的提供者带来运营挑战。因此，难以识别和解决“嘈杂邻居”问题。为了解决这一点，SaaS提供者应该考虑构建一个自定义解决方案，通过利用存储和吞吐量/IOPS指标，监控多租户文件系统中的单个租户。

Amazon RDS的考虑因素

在同一个Amazon RDS数据库集群中整合多个客户或最终用户数据的多租户工作负载可能会给每个租户的可观察性带来运营挑战。MySQL社区版和开源PostgreSQL提供的每个租户可观察性和资源管理能力有限。运营多租户工作负载的AWS客户通常使用数据库或模式及数据库用户账户作为替代品。AWS客户需使用其他机制来建立租户与这些替代品之间的映射。这将使您能够在外部处理数据库引擎生成的原始可观察性数据。然后，您可以将这些替代品映射回租户，以区分可观察性数据中的租户。

结论

在本文中，我们展示了在AWS云中转向多租户SaaS解决方案时应考虑的内容，如何优化云基础的SaaS设计，以及一些挑战和解决方法。建议在SaaS设计策略的早期阶段投资精力，探索客户对租户的要求。从SaaS租户的最终目标反向推导，以确定所需的计算性能和网络安全特性，以及SaaS提供者如何监控和运营目标租户配置的平台。您所在的AWS账户团队非常有能力为这些设计决策提供建议。请利用AWS WellArchitected Framework来审查和改进您的设计，尤其是SaaS Lens。租户设计过程应在生产部署前经过全面的原型测试，以验证功能。

相关信息

Dennis Greene

Dennis是AWS客户解决方案经理，专注于美洲独立软件供应商ISV领域。他是一名经验丰富的技术领导者，拥有超过25年的技术转型项目实施经验，涵盖应用和基础设施领域。他在金融服务、制药和软件行业的工作经验丰富。Dennis目前是复杂云迁移和现代化项目的可信C级顾问，专注于云架构、规划、商业价值和可持续性。

Ignacio Fuentes

Ignacio是AWS的高级解决方案架构师，专注于协助ISV客户的云和应用开发。作为一名拥有超过10年经验的软件工程师，他以创新和务实的心态处理每一个项目。他倡导使用技术解决现实世界中的挑战，并致力于利用其专业知识在科技行业及其他领域创造积极影响。

Greg Pierce

Greg是AWS高级经理，拥有超过20年的管理和软件开发经验，设计、开发和部署关键任务应用。他在市场研究、可行性研究、客户和公共关系、技术管理和项目预算方面具备强大的分析、解决问题、计划和管理能力。他是AWS认证专家，专长于C#、Python、TensorFlow、Unity、OpenGL、DirectX、Java和ObjectiveC。