为大中型使用管理WebRTC 媒体服务器的最佳方法之一是使用基于云的按需扩展。Amazon Web Services (AWS) 提供了一些可以帮助您扩展基础设施需求的最佳工具。
AWS 等基于云的解决方案的显着特征之一是您只需为 WebRTC 会话期间使用的资源付费。因此，您不仅可以降低成本，还可以提高速度，并可以通过简单的 API 调用灵活地更改配置。
在本文中，我们将介绍如何利用 AWS 工具创建媒体服务器池，这些服务器可以根据您的应用程序逻辑和用户负载按需扩展。
我们将重点介绍这些 AWS 服务：
为什么很难扩展媒体服务器？
当谈到媒体服务器的按需扩展时，主要问题之一是每个媒体服务器都需要是有状态的。换句话说，作为单个实体处理。这使得在使用Elastic Load Balancer (ELB)时进行缩放的过程与我们过去对 Web 应用程序所做的不同。
问题的出现是因为对于每个 WebRTC 会话/呼叫，都会选择一组媒体服务器来处理它。如果您要使用负载均衡器，如前所述，您的流量将被随机引导到池后面的每个服务器，而不一定是会话所在的服务器。
对于您可以指定路由规则的固定数量的实例，这可以很好地工作。但随着流量增加，您的媒体服务器池将需要增加实例数量，并在流量下降时减少实例数量。这将使您的负载均衡器难以跟踪用于特定会话的实例。
另一件需要考虑的事情是，特定 WebRTC 会话中的用户需要连接到给定的媒体服务器并建立持续连接，直到呼叫或流媒体会话结束。这是使用 ELB 时很难实现的事情。
如何正确扩展媒体服务器
首先，您需要一个AWS 账户。准备好帐户后，让我们开始准备一些先决条件，如下所示：
- 创建一个 AMI 映像，您的 Auto Scaling 组将使用该映像启动媒体服务器池中的实例。
确保在将要部署媒体服务器的同一区域中创建 AMI 映像。如果要部署到多个 AWS 区域，则必须为每个区域构建 AMI 映像。
我们推荐用于构建 AMI 映像的工具之一是HashiCorp 的 Packer。Packer 是可配置的，可以以声明的形式使用。这意味着您可以将它添加到您的 CI/CD 管道并使用变量为特定构建配置它。
您构建的 AMI 映像将需要以下内容：
- 在目标操作系统中安装您选择的媒体服务器，并根据您的需要进行配置。媒体服务器安装步骤可以在它们各自的文档中找到，即对于Janus Media Server，您可以从README中记录的源代码构建它。
- 使用 Web 服务器和 SSL 证书将媒体服务器配置为可访问。
对于 Web 服务器，您可以使用适合您的任何选项，但我们建议使用 Nginx，因为它易于配置。
此 SSL 证书可以是您从第三方获得的自定义证书，也可以使用ZeroSSL或Letsencrypt生成证书。
我们用来请求免费 ZeroSSL 或 LetsEncrypt 的工具之一是acme.sh，或者有时您可能更喜欢使用certbot或其他工具。
您需要确保您的证书是您的媒体服务器子域或您将用作 Route53 托管区域的域的通配符证书。例如，如果我的应用程序域是example.com并且我决定我的媒体服务器域是mediaserver.example.com，那么我的媒体服务器通配符证书将包括mediaserver.example.com和*.mediaserver.example.com。
- Lambda 函数代码将接收我们的 SNS 主题事件并处理它们以获取有关我们的 AutoScaling 组的信息。
lambda 函数可以用您选择的任何语言编写，并且具有以下方法/函数：
- 确定是否正在从自动缩放组（我们称之为媒体服务器池）中添加或删除实例。
- 确定是否将新实例添加到自动缩放组暖池中。这很关键，因为它将帮助我们仅为活动实例创建 DNS 记录。
- 使用实例元数据创建 Route53 记录。这将创建一个子域，其 A 记录包含我们的实例 IP 地址数据（在这里您可以根据您的设置决定是使用私有 IP 还是公共 IP）。为此，您需要有一个 Route53 托管区域，检查下一个要求。
- 使用新的实例记录更新您的应用程序，并在服务器终止时通知它。为此，您将需要一个创建和删除端点来记录来自 Lambda 函数的服务器详细信息。
虽然是可选的，但 Python3 可用于编写您的函数代码，并且您可以利用boto3库从您的 lambda 函数内与 AWS API 进行通信。
- 一个 Route53 公共托管区域，用于管理每个服务器的媒体服务器池 dns 记录。
如果托管区域由 Route53 管理，您可以根据您的域注册一个托管区域。
另一种选择是将您域的子域注册为托管区域，如果您不想将您的域从其他提供商转移到 AWS，则使用它。您可以在此处阅读更多相关信息。
假设您现在具备上述先决条件，您现在可以继续。
创建您的 Lambda 函数
首先，创建一个标准 SNS 主题，稍后您将在 Lambda 函数中将其注册为触发器。相同的 SNS 主题也将用于稍后订阅您的 Autoscaling Group 生命周期事件。
准备好 SNS 主题后，您可以使用“从头开始创作”选项继续创建 Lambda 函数。这将允许您在进行过程中自定义功能。
选择您的运行时环境，例如，如果将 Python 用于 lambda 函数代码，您可以选择可用的 python 环境之一。确保环境版本与您的代码可以运行的版本相匹配。您可以修改其他配置，包括体系结构和高级设置。
创建 Lambda 函数后，您需要添加一个 SNS 主题作为其触发器。使用 <<Add trigger>> 按钮，然后搜索您创建的触发器并选择它。
一旦您将 SNS 主题添加为触发器，Lambda 函数现在就可以从它接收事件作为触发器，并且能够处理这些事件，这正是我们想要的。
注意：如果您使用基础架构即代码 (IaC)，您可能需要找到一种方法来压缩您的 Lambda 函数并将其上传到 S3 存储桶，您可以从那里将其读入您的 lambda 函数块。使用 Terraform，您可以使用 null_resource 或其他替代方法来压缩您的 lambda 代码及其任何包，将它们上传到 S3，然后使用上传的存档作为 lambda 函数的源。
创建媒体服务器池
现在您已准备好 Lambda 函数和 SNS 主题，您可以继续创建服务器池。在这里，您将使用 EC2 仪表板创建一个 Auto Scaling 组。
Auto Scaling Group 将需要一个将使用我们的 AMI 映像的启动模板。这是您为启动实例而创建的 AMI 映像。
您有两个选择，要么创建一个启动模板，要么单击 <<切换到启动配置>> 以输入所需的配置，如下所示。
由于此时您没有启动模板，您可以通过单击 <<Create a launch template>> 链接继续并创建一个。这将打开一个新选项卡，您可以在其中填写必填字段。
启动模板内容下最重要的部分是应用程序和操作系统映像（Amazon 机器映像），您应该在其中选择我的 AMI选项卡，然后选择您为媒体服务器构建的 AMI 映像。
请记住，所选的 AMI 操作系统是将用于您的实例的操作系统。在此示例中，我们使用Ubuntu，但您可以使用 AWS 支持的任何 Linux 发行版或操作系统。
选择实例类型
接下来，选择您的实例类型。您可以在此处决定哪种实例类型和大小更适合您的媒体服务器。例如，如果您希望单个媒体服务器处理 300 个可能分布在不同呼叫或单个呼叫中的参与者，那么您选择的实例应该有足够的内存和 vCPU 足以处理此类负载。
正确估计的最佳方法是从小型实例类型开始。开发应用程序后，您可以在测试期间不断更改实例类型，直到达到支持每个媒体服务器 300 个参与者的大小。这个数字对于这个例子是任意的。请务必记住，在测试时您可以使用 AWS CloudWatch 指标来确定您的实例性能。如果您还可以将第三方监控工具集成到您的实例设置中，那么在此阶段它会派上用场。
选择网络设置
然后，另一个关键部分是网络设置。这是您配置安全组规则以打开特定端口并限制其他连接的地方。
如果 AMI 映像的默认磁盘大小较小，您还可以增加磁盘空间，例如，您的 AMI 可能有 20GB 的卷，但您的媒体服务器可能至少需要 40GB。您可以在存储（卷）部分下修改它。
在高级设置下，您可以添加一个用户数据脚本，实例可以使用该脚本在启动期间进行一些配置。
根据需要填写其他配置，然后点击<<Create launch template>>。
创建完成后，您可以关闭选项卡并返回到Auto Scaling 组创建页面，单击<<选择启动模板>> 下拉菜单左侧的刷新按钮。这将更新可用启动模板列表，选择您创建的启动模板并单击<<Next>>。
在下一个屏幕上，您将选择用于启动实例的选项，如果您有多个实例，则包括 VPC。您还可以为您的实例选择可用性区域，对于此示例，建议您选择所有三个可用性区域，以使您的媒体池在一个可用性区域中对故障更具弹性。选择后单击<<Next>> 继续。
确保负载平衡选项设置为“无负载平衡器”，然后单击<<下一步>>。
选择初始容量
在下一节中，配置初始容量，即自动缩放组的所需容量、最小容量和最大容量。此部分下的另一个相关设置是确保将缩放策略选项设置为无。因为您希望您的自动缩放组缩放由应用程序的逻辑来管理。然后单击<<Next>> 进入下一节。
下一部分也很重要，因为它将允许您配置 Auto Scaling 组，以便能够将其生命周期事件发送到 SNS 主题。在“添加通知”部分下，单击 <<添加通知>> 按钮，这将打开一个通知配置部分。
在打开的部分，单击 SNS 主题下的字段，然后搜索您创建并链接到上面的 Lambda 函数的 SNS 主题。
选择通知事件
选择后，选择您的通知事件。对于这种情况，我们只需要两个：启动和终止。除非您在 Lambda 函数中包含特定条件和函数来处理其他事件，否则您可以选择包含或不包含它们。
点击<<Add notification>>按钮并点击<<Next>>进入标签部分，或者如果您不想添加标签，您可以点击<<Skip to review>>。
检查您的设置并单击 <<Create Auto Scaling Group>>。这将启动您的 Auto Scaling 组并按照您在配置中定义的方式添加初始实例。
管理按需扩展
假设您的 Auto Scaling 组已准备就绪并与您的 Lambda 函数链接，最后一步是在您的应用程序后端添加逻辑以管理组的扩展和扩展。在这里，您使用AWS 软件开发工具包 (SDK)之一与 AWS API 进行通信。
在您的应用程序中配置 AWS 开发工具包后，您可以跟踪哪些会议当前正在运行以及哪些会议已结束。您还可以跟踪当前有多少用户在线。根据此数据和您可能决定使用的任何其他数据，您的应用程序可以确定当前使用情况是否几乎达到可用媒体服务器的阈值。如果是这种情况，则 API 可以向您的 Auto Scaling 组发送一个扩展 AWS API 调用，这将增加实例。在 Auto Scaling 组中实例化每个服务器后，Lambda 函数将接收创建事件。处理 SNS 事件后，服务器详细信息将发送到后端/应用程序。这将使用提供给 Lambda 函数的端点。
您还需要根据哪些会议结束、有多少用户退出以及其他关键数据来跟踪使用情况。您可以在此处使用保存的实例详细信息来终止实例并缩减您的 AutoScaling 组。
上述逻辑将保持平衡您的应用程序使用的实例数。您的任务是了解您的应用程序在什么时候检测到它需要更多服务器，以及您在什么时候知道服务器没有被使用。
媒体服务器池启动时间改进
有时，服务器使用率的增长速度可能快于 AWS Autoscaling Group 添加新实例所需的时间。要缩短此时间，您可以使用AWS Auto Scaling Group Warm Pools。
这些将使用您的媒体服务器配置准备一组实例，并将它们置于休眠/停止/运行状态。有了这个，每当需要一个新实例时，它就会从暖池中取出，并且只会启动它，这将大大减少新媒体服务器的启动时间。
暖池将不断替换取出到 Auto Scaling 组的任何实例。因此，如果您的设置要求在峰值期间可能需要太多实例，您可以利用暖池来让那么多实例在这种峰值时刻处于待命状态。好处是可以使用 AWS SDK API 调用修改暖池和自动缩放组。
按照以下步骤将暖池添加到已创建的 Auto Scaling 组：
- 转到 EC2 仪表板，导航到 <<Auto Scaling Groups>> 并从列表中单击您的媒体服务器的 Auto Scaling Group。如果列表很长，您也可以搜索它。
- 单击<<Instance management>> 选项卡，然后在Warm pool部分下单击<<Create warm pool>> 按钮。
- 选择暖池实例状态。
- 如果需要媒体服务器无法承受启动已停止或休眠实例所需的时间，请选择运行状态。在这里，您将对正在运行的实例收取全额费用。
- 如果停止状态实例需要很长时间才能将数据加载到内存中以跟上应用程序所需的扩展等待时间，请选择休眠状态。这会对附加到休眠实例的资源收费。
- 如果您的应用程序扩展等待时间不受启动已停止实例所需时间的影响，请选择停止状态以节省计算成本。费用仅适用于附加资源。
- 然后，通过输入最小暖池实例和最大设置来定义池的大小。完成后单击 <<Create>> 将温池添加到您的 Auto Scaling 组。
使用 AWS SDK API 的美妙之处在于，您可以根据应用程序的当前状态或基于高峰和非高峰时间在上述模式之间切换。例如，如果您的高峰时间在上午 11 点到中午 12 点之间，那么您可以向后端/应用程序添加逻辑以将暖池状态更改为运行。在中等高峰时段，您可以将暖池设置为休眠状态，而在非高峰时段，您可以将其设置为停止状态，具体取决于您处理的用户流量类型。这种灵活性将使您能够大量节省按需实例成本。
其他建议
我们的第一个建议是在单个基础架构即代码（Pulumi或Terraform）设置中协调所有这些设置步骤，您可以使用它一次性部署基础架构。这将简化单个设置中的所有这些步骤，您可以在多个版本甚至不同环境中发布该设置。
一些团队更喜欢将应用程序 IaC 代码与基础设施设置 IaC 代码分开。无论您选择什么选项，使用 IaC 都会减少设置、调试和配置所需的时间。它还将确保一旦您的设置准备就绪，就可以更轻松地迁移到 AWS 上的任何环境、账户或区域。
使用 IaC，还可以更轻松地记录您的设置和配置。这将改善基础设施维护和移交时间。
作者：Brian Collins
原文链接：https://webrtc.ventures/2023/01/high-available-webrtc-media-servers-on-aws/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/14281.html
