概览
工作原理
这些技术细节包含一张架构图,用于说明如何有效使用本解决方案。该架构图展示了关键组件及其相互作用,并逐步概述了架构的结构和功能。
Well-Architected 支柱
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构,您应该遵循尽可能多的 Well-Architected 最佳实践。
本指南使用的服务可让您通过监控和日志记录,全面了解工作负载,同时还能为您提供可靠、稳定、可信赖的应用程序。例如,通过 CloudWatch,您可以通过指标、个性化控制面板和日志获得可观测性,此外还可以根据本指南中的指标定义警报,从而监控工作负载的运行状况,最大限度地降低事故造成的影响。此外,Amazon EKS 集群还可以识别运行状况不佳的容器,并自动将它们替换为新容器,使您的工作负载能够应对事故和事件。
默认情况下,所有传入 Galaxy 的连接均来自公共互联网,并通过可公开访问的应用程序负载均衡器定向到 Galaxy 服务器。或者,可以将本指南配置为在私有子网中使用内部应用程序负载均衡器,在该子网中,流量通过虚拟专用网络 (VPN) 连接或 AWS Direct Connect 进行路由。在这两种情况下,计算资源都部署在专用子网内,不能直接从公共互联网访问。Galaxy 通过自身的用户管理或 Active Directory 联合身份验证服务(AD FS)处理应用程序级身份验证和授权。
为了实现可靠的应用程序级架构,本指南的各个组件都作为松散耦合的 Kubernetes 容器组(pod)部署。此外,消息代理是完全托管的服务 Amazon MQ,在我们的默认配置中,它包含一个备用服务器。最后,共享文件系统通过 Amazon EFS 提供,具有高度可用性,通过 Aurora Serverless 提供的数据库也是如此。
Amazon EKS 是一项 AWS 原生服务,本指南重点介绍通过经济划算的方法,使用选定的资源部署和配置该服务,让您可以实现具有高可用性和低运营成本的可靠 Kubernetes 应用程序。Amazon EKS 的架构跨越多个可用区,可实现高可用性。虽然在部署到可用区的子网之间会存在一些流量,但其延迟应该不会对性能产生任何重大影响。
Amazon EFS 旨在提供无服务器、完全弹性的文件存储,让您无需预置或管理存储容量和性能,即可共享文件数据。它提供了便携式操作系统接口(POSIX)文件系统,具有生物信息工作负载所需的性能。
在 Amazon EKS 集群中,影响数据传输成本的一个重要因素是外部客户端通过应用程序负载均衡器对 Kubernetes 服务的调用。调用服务时的数据传输成本被映射为运行在不同可用区的容器组(pod)间通信。
由于具有高度可配置的自动扩展的最小、最大和所需数量以及相应的亚马逊弹性计算云 (Amazon EC2) 参数,因此可以高效管理资源。
最后,无服务器架构采用按价值付费的定价模式,并可根据需求进行扩展。这包括 Aurora Serverless 数据库和 Amazon EFS。我们建议您以编程方式标记属于某个项目的 AWS 资源,然后使用标签在 AWS Cost Explorer 中创建自定义报告,以实现成本的可视化和监控。
通过选择合理调整规模的实例,您可以仅使用所需的资源,从而减少不必要的碳排放。同时,通过使用具有动态扩展功能的服务,可以最大限度地减少后端服务对环境的影响,并确保根据网站的需求扩展计算资源。此外,使用完全托管的服务(例如 Amazon EFS)可以最大限度地减少所需的资源。
自信地进行部署
为部署做好准备了吗? 查看 GitHub 上的示例代码,了解详细的部署说明,以根据需要按原样部署或进行自定义部署。
免责声明
找到今天要查找的内容了吗?
请提供您的意见,以便帮助我们提高页面内容的质量