使用MagicOnion开展实时通信（后续）

2020年Happy Elements《快乐元素》圣诞倒数日历活动，第八天内容。

继《第7天的日志》之后，我是”梦境传说”的工程师，岸本。

在之前的文章中，我介绍了MagicOnion的基本部分以及服务器配置的思路。

这次，我想介绍一些关于基础架构的话题，比如Kubernetes和Agones，以及具体的流程。

本内容所述为当前正在开发中的内容，实际规格可能会有所不同！

Kubernetes / Agones：容器编排系统与游戏服务器托管

现在，为了实现之前讨论的内容，我们面临着基础设施方面的问题。

通过使用Kubernetes和Agones来解决这个问题。
（不会详细解释Kubernetes和Agones！）

容器编排

Kubernetes是一个容器编排系统，可以负责部署和扩展容器化应用程序的工作。

对于像服务发现和实时通信服务器这样由多个服务器组成的微服务，它非常适合本次这样的场景，并且是一个非常强大的系统。然而，如果要在状态为全局的配置下实现实时通信，可能会出现一些问题。

• サーバーを直接外部に公開できない。

 

• Kubernetes では、サーバー (Pod) を直接外部に公開することはできず、

 

• Service というロードバランサーのような仕組みを経由させて公開する必要があり、

 

• 特定のユーザーを特定のサーバーに接続させたい場合、若干不向きな仕組みになっています。

 

• スケーリングからの保護ができない。

 

• ユーザーの常時接続が必要なリアルタイム通信サーバーが、

 

• Kubernetes の スケーリング の対象となって、

 

意図しないタイミングでシャットダウンされると困るので、やはり若干不向きな仕組みになっています。

为了解决这个问题，我们将使用Agones。

比赛

Agones 是一个用于在 Kubernetes 上运行有状态实时通信服务器的扩展系统。

• サーバーを直接外部に公開できる！

 

• Agones では、公開可能な IPアドレス を サーバー (Pod) に割当することで、

 

• Service を介さず、直接外部に公開できるようになります。

 

• スケーリングから保護できる！

 

• Agones では、サーバー (Pod) のステータスを管理できるようになっていて、

 

使用中 (Allocated) なサーバーは、Kubernetes の スケーリング から保護されるようになります。

由於這些特點，Kubernetes 使得處理有狀態的即時通訊服務器變得更加方便，成為適合運營即時通訊服務器的系統。

整体构图

通过组合这些机制，云平台的大致结构如下。
（请注意，由于运营上可能还需要其他组件，因此这并不是全部！）

服务发现和实时通信服务器

从软件上来看，它被构建成这样的形式。

Service Discovery 是在 Kubernetes 上运行的服务器，使用 MagicOnion 的 Service。

实时通信服务器是在Kubernetes上运行的服务器，使用MagicOnion的StreamingHub。

在一个服务器上，我们通过多个端口托管了多个主机。除了供客户端使用的公开API外，我们还单独设置了专用于服务器间通信的内部API，并进行了分割。

此外，您可以通过查询Kubernetes和Agones的API来了解Kubernetes内部的各种信息，例如其他服务器的信息。

以下是一个基于命令的简单示例，该示例可以获取正在运行的实时通信服务器（游戏服务器）在Agones中的列表，并获取可以公开的外部IP地址和端口信息。（这是在Minikube环境下的结果。）

$ kubectl get gameserver
NAME                    STATE   ADDRESS          PORT   NODE       AGE
real-time-xhxkn-8szj7   Ready   192.168.99.100   7400   minikube   24m
real-time-xhxkn-ff4rp   Ready   192.168.99.100   7101   minikube   24m

在包括C#在内的多种语言中，Kubernetes和Agones的SDK已经公开发布，通过它们，您可以从应用程序内部获取类似的信息。

处理流程

以聊天作为例子，我们来考虑具体的处理流程。

我們前提是參與特定群組專用的聊天室，如派對或公會，而不是完全隨機的聊天室。

1. 因为用户（客户端）不知道聊天室（实时通信服务器）的连接地址，

 

1. 所以向服务发现（API服务器）查询聊天室的连接地址。

服务发现想要获取运行在Kubernetes上的聊天室列表，
所以向Kubernetes查询。

服务发现根据聊天室列表检查分配情况等，
保证用户请求的聊天室能够被分配。
此时，聊天室声明为已分配给Agones，
并受到Kubernetes的扩展保护。

服务发现将聊天室的连接地址返回给用户。

用户连接到从服务发现得到的聊天室。
然后，双向通信能够在客户端和服务器之间一直建立，
从而能够自由地进行聊天。
当所有用户离开聊天室并且不再需要时，
聊天室将宣告为可关闭给Agones，
并重新成为扩展的目标。

虽然走了一段长路，
但是如果能够到达这一步，
那么就可以建立一个以状态为基础的实时通信环境，
并且能够运行得差不多了。

我认为只需根据要求进行定制化，就可以实现想要的功能！

额外的附赠品

部署机制

我們的設計基於使用AWS運作，以下是我們建立的部署流程機制。

通过更改容器镜像的版本来解决问题，这是 Kubernetes 中最基本的部署方法之一，需要在目标服务器的 Deployment（或 Agones 的 Fleet）中指定。

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: hoge
        image: hoge:v1.0 → hoge:v2.0

在Merクストーリア中，我们构建了从管理界面上可以部署的机制，并且可以通过应用程序内部进行Deployment和Fleet的补丁操作，即使可以通过自动化实现对该yaml定义的更新。

如果将源代码提交到GitHub，CodeBuild将会自动构建容器，并将其推送到ECR。
您可以通过管理界面访问ECR仓库，并选择要部署的图像版本，以进行部署。

此外，由于在Agones管理下使用的实时通信服务器，需要实现优雅关闭功能，例如保持连接的切断，这个问题可以通过运行部署批处理来解决。

通过这样做，我们尽可能地消除了手动操作，并确保了安全的部署。

保密事项的处理

以下也基于AWS运行
为了能够处理秘密信息，我们采用了以下流程。

在Kubernetes中，有一种机制可以处理名为”Secret”的敏感信息，但是，如果要在Secret中处理例如私钥之类的东西，则需要注意管理方面的问题。

因此，我们决定使用 AWS 的 SecretsManager 来管理机密信息，并通过应用程序内部与 SecretsManager 进行交互，以使其能够反映到 Kubernetes 的 Secret 中。

通过这样做，可以避免将机密信息嵌入到代码中，避免将其提交到Git中或在本地进行管理。

总结一下

以下是关于使用MagicOnion进行实时通信机制的介绍！

由于它仍处于开发阶段，我们只能提供很少的具体实例，包括必要的技术介绍在内，因此内容相对较为繁琐，不知道您觉得如何？

目前在日本国内，选择采用魔术洋葱（MagicOnion）和C#作为游戏服务器端的情况还相对较少。在我们的卡卡利亚工作室，客户端普遍使用Unity（C#），而服务器端主要采用Ruby on Rails（Ruby）。

在这样的环境下，使用MagicOnion、Kubernetes和Agones等进行开发可能会变得相当具有挑战性。希望这对于对实时通信和服务器端C#等感兴趣的人有所帮助！

招募团队成员

在Happy Elements株式会社的卡卡力工作室，我们正在大力招募能共同创造受到热情喜爱的内容的成员！

如果您对我们公司感兴趣的话，一定要前往下面的招聘网站查看。
Happy Elements株式会社招聘专用网站。

请继续享受Happy Elements Advent Calendar 2020！谢谢！