著者: Liu Qiuyang、Cai Jing
序文
今日の世界的に統合された経済環境において、デジタル エンターテインメント業界はますます文化的および商業的交流の強力な代表となりつつあります。このような背景から、多くのゲームメーカーがゲームの海外展開に挑戦し、グローバルサーバー構造により世界中の幅広いプレイヤー層を魅了するゲームが数多く誕生し、目覚ましい成果を上げています。ゲームの世界的な展開は、個々の製品の市場規模を拡大するだけでなく、ゲームメーカーの世界的な影響力を増大させますが、同時に多くの技術的な課題ももたらします。
ゲーム サービスに必要な高頻度のインタラクションと低遅延を実現するには、ゲーム サーバーをグローバル サーバー フレームワークの下で複数のリージョンにデプロイする必要があります。実際の運用では、通常、対象となるユーザー グループの地理的位置と遅延の許容範囲に基づいて、サーバーの場所を事前に計画する必要があります。一般的に、次のエリアが優先サーバー アドレスです。米国東部は人口が密集しており、多数の北米プレーヤーにサービスを提供できます。フランクフルトエリアはヨーロッパのインターネットの交差点であり、ネットワーク エクスペリエンスを効果的に提供できます。ヨーロッパ全土のプレイヤー、シンガポールこの地域は東南アジアのプレイヤーベースを幅広くカバーしており、東京リージョンは主に日本と韓国のプレイヤーをサポートしています。
構成の違い、ゲームのバージョンの更新、地域ごとのサーバー数の不一致の可能性に直面して、世界規模でゲームサーバーの一貫した配信を効果的に実現する方法が、グローバルサーバーの設計時に直面し、解決しなければならない中心的な課題となっています。建築。 。この記事では、例を使用して、グローバル ゲーム サーバーのマルチリージョン一貫性配信のベスト プラクティスを説明します。
導入アーキテクチャ
この例では、上海、東京、フランクフルトにサーバーを開設する予定であるため、これら 3 つの地域にインフラストラクチャ リソースが必要です。異種混合の複雑なインフラストラクチャ シナリオに直面しても、クラウド ネイティブによってもたらされる宣言型 API と一貫した配信機能により、基盤となるリソースの違いを完全にシールドできるため、ゲームの運用およびメンテナンス エンジニアはアプリケーション自体に集中できるようになり、ゲーム サーバー配信の効率が大幅に向上します。 。地域の自律性の安定性とユーザーのスケジューリングの複雑さの観点から、各サーバー リージョンに独立して Kubernetes クラスターを展開し、マルチクラスター機能による統合された運用保守管理が、一貫したゲーム サーバーを提供する最良の方法であると考えています。
この実践では、マルチリージョン Kubernetes クラスターを管理するために Alibaba Cloud の分散クラウド コンテナ プラットフォーム ACK One を選択しました。 ACK One は、ハイブリッド クラウド、マルチクラスター、災害復旧、その他のシナリオ向けの Alibaba Cloud のエンタープライズ クラスのクラウドネイティブ プラットフォームとして、あらゆる地域およびあらゆるインフラストラクチャ上の Kubernetes クラスターに接続して管理でき、アプリケーションとトラフィックをサポートするための一貫した管理を提供します。 、セキュリティ、ストレージ、可観測性などは一元管理されています。
この例の展開アーキテクチャは図に示されており、異なるリージョンにある 3 つの実稼働環境と 1 つの開発およびテスト環境が含まれています。一般的に、このプロセスは、本番環境に展開する前に、バージョンが研究開発テスト環境で安定していることを検証して確認することで、プロジェクト全体の安定性を確保し、潜在的なリスクを効果的に防止するのに役立ちます。
この例では、マルチクラスターのハイブリッド クラウド アーキテクチャを使用します。具体的には、上海クラスター、フランクフルトクラスター、上海開発クラスターは Alibaba Cloud ACK クラスターですが、日本のクラスターは非 Alibaba Cloud Kubernetes クラスターであり、クラスターを登録することで統合および管理されます。各クラスター内では、GameServerSet を使用してゲーム サーバーをデプロイします。 GameServerSet は、Cloud Native Computing Foundation (CNCF) が育成するオープン ソース プロジェクトである OpenKruise によって提供されるゲーム固有のワークロードです。ネイティブの Deployment および StatefulSet ワークロードと比較して、GameServerSet はゲーム セマンティクスを備えており、ゲーム シーンに近いため、ゲーム サーバーの運用と保守管理がより便利かつ効率的になります。
クラスター管理
Kubernetes クラスターの準備が完了したら、ACK One フリートを使用してクラウド上とクラウド外のクラスターを均一に管理します。
まず、ACK One 登録クラスター[ 1]を介して IDC またはサードパーティのパブリック クラウド クラスターを Alibaba Cloud に登録します。具体的には次のとおりです。
-
登録クラスターを作成し[ 2] 、作成した登録クラスターの右側にある操作列の下にある「詳細」をクリックします。
-
クラスター情報ページの「接続情報」タブをクリックします。
-
クラスター インポート エージェントの構成領域で、必要に応じてパブリック ネットワークまたはプライベート ネットワークを選択し、右側の[コピー] をクリックしてパブリック ネットワークまたはプライベート ネットワーク タグの内容をファイルにコピーし、kubectl コマンドを実行してターゲット クラスターを登録します。新しいクラスター。たとえば、新しいagent.yamlファイルを作成し、上記の内容をagent.yamlファイルにコピーし、ターゲットクラスターでkubectl apply -f Agent.yamlコマンドを実行します。
この手順により、日本のクラスターが Alibaba Cloud に登録されました。
次に、ACK One マルチクラスター フリート[ 3]を開き、登録されたクラスターを ACK One コンソール上のクラウド クラスターに関連付けます[ 4] 。クラスターは複数のリージョンにまたがっているため、ACK One フリートはパブリック ネットワークを使用してクラスターに関連付けられ、フリートが配置されている VPC はパブリック ネットワーク NAT ゲートウェイを使用して構成する必要があります。
この時点で、マルチクラスタ フリートの準備が整いました。この例に対応する概略図は次のとおりです。
ゲームサーバーのリリース
例の特定のリリース操作を実行する前に、クラウド ネイティブの配信のアイデアを理解しましょう。これは、クラウド ネイティブ アプリケーションの配信が、アプリケーションのデプロイメント プロセスではなく、アプリケーションの定義に焦点を当てていることを意味します。アプリケーションの定義は Yaml であり、構成パラメータを通じてアプリケーションがどのようなものであるかを記述します。したがって、アプリケーションに関連するすべての変更とリリースは、実際にはアプリケーションの説明 (Yaml) に対する変更になります。
これまでのところ、Yaml を保存し、アプリケーションの現在の記述を記録し、過去の Yaml の変更を追跡および監査できるようにするためのウェアハウスが必要であることがわかりました。そうは言っても、運用およびメンテナンスのエンジニアは、コミットおよびマージ リクエストを送信して、すべての Git 仕様に従って監査を行うことで、この特性を自然に満たすことができることに誰もが気づくと思います。理想的な世界では、ゲーム サーバーの一連の YAML 記述を維持するだけで、ワンクリックで世界中の複数の地域でゲーム サーバーのリリースをトリガーできます。デプロイメントを実行するためにクラスターを 1 つずつ操作する必要はありません。行動。これがGitOpsの考え方です。
GitOps の実装プロセスで最も難しいのは、実はゲーム サーバー アプリケーションの抽象的な記述です。記事の冒頭でも述べたように、地域ごとにゲームサーバーには多かれ少なかれ違いがあり、すべてのゲームサーバーを1つのYamlでまとめるのは難しいと思われます。たとえば、上海では 10 個のゲーム リージョン サーバーをリリースしたいのですが、フランクフルトでは 3 個のリージョン サーバーだけをリリースしたいと考えています。このように、レプリカ フィールドの違いにより、Yaml では異なるリージョンのゲーム サーバーを記述することができません。リージョンごとに Yaml を維持する必要がありますか?これは、区別のないフィールド変更 (すべてのリージョンのゲーム サーバーのラベル付けなど) を行う場合にも、複数の Yaml 変更を繰り返し実行する必要があるため、漏れやエラーが発生しやすくなります。これは、クラウドネイティブ配信の考え方に沿ったものではありません。
実際、Helm Chart を通じてゲーム サーバー アプリケーションをさらに抽象化し、さまざまな部分を値として抽出できます。今回の例 (GitHub ゲーム サーバーの Helm Chart の例[ 5] ) では、いくつかの異なるフィールドを抽象化しました。
- マスター イメージ - 各リージョン/クラスターのマスター イメージは異なる場合があります
- サイドカー イメージ - 各リージョン/クラスターのサイドカー イメージは異なる場合があります
- コピー数 - リージョン/クラスターごとにリリースされるゲームサーバーの数は異なる場合があります
- 自動スケーリングするかどうか - 各リージョン/クラスターには自動スケーリングの要件が異なる場合があります。
これ以外の分野は一貫しており、地域差はありません。
GitOps を理解し、ゲーム サーバー アプリケーションを抽象化して説明した後、ACK One GitOps を使用して実際のアプリケーション配信を実行しました。次に、特定の操作を開始します。
Git リポジトリに接続する
ArgoCD UI にログインします。ACK One コンソールの左側のナビゲーション バーで [ Fleet] -> [GitOps] -> [GitOps Console]に移動し、ログイン ページで[LOG IN VIA ALIYUN]をクリックしてArgoCD UI にログインします。パブリック ネットワーク アクセスが必要な場合は、パブリック ネットワークを開いて GitOps にアクセスする必要があります[ 6]。
-
ArgoCD UI の左側のナビゲーション バーで [設定] を選択し、[リポジトリ] > [+ Connect Repo] を選択します。
-
ポップアップ パネルで次の情報を設定し、[接続] をクリックして接続を追加します。
PvEタイプのゲームを公開する
PvE ゲームには通常、地域サーバーの概念があり、運用および保守エンジニアが各地域で開設されるサーバーの数を手動で制御します。クラウドネイティブ PvE ゲームのベスト プラクティスについては、OKG PvE ゲームのベスト プラクティス ドキュメント[ 7]を参照してください。
ホワイトスクリーン管理アプリケーション
初めて ArgoCD を試すときは、白い画面のコンソールを使用して、各リージョンのクラスター用のアプリケーションを作成できます。
-
ArgoCD UI の左側のナビゲーション バーで[アプリケーション]を選択し 、[+新しいアプリ] をクリックします。
-
ポップアップパネルで以下の情報を設定し、 「作成」 をクリックして作成します。 (opengame-demo-shanghai-dev を例として取り上げます)。
- 作成が完了すると、 アプリケーションページで opengame-demo-shanghai-dev のアプリケーション ステータスを確認できます。 SYNC POLICYで手動モード を選択した 場合は 、手動でSYNCをクリックして、アプリケーションをターゲット クラスターに同期的にデプロイする 必要があります 。アプリケーションの ステータスはHealthy and Synced となり 、同期が成功したことを示します。
- opengame-demo-shanghai-dev アプリケーション名をクリックすると、アプリケーションの詳細が表示され、アプリケーションに関連する Kubernetes リソースのトポロジと対応するステータスが表示されます。
ApplicationSet を介してワンクリックで公開
ArgoCD に慣れると、ApplicationSet オブジェクトを使用して、ワンクリックでゲーム サーバーを公開することもできます。各クラスターの違いは、要素を通じて抽象化されています。たとえば、以下の Yaml では、クラスター ディメンションから 3 つのフィールドが抽象化されています。クラスター名は、アプリケーション名を区別するために使用されます。異なるクラスターによって公開されたゲームを区別するため。
ApplicationSet Yaml を作成した後、それを ACK One フリート クラスターにデプロイして、4 つのアプリケーションを自動的に作成します。
kubectl apply -f pve.yaml -n argocd
# pve.yaml 内容如下：
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: minecraft
spec:
generators:
- list:
elements:
- cluster: shanghai-dev
url: <https://47.100.237.xxx:6443>
replicas: '1'
- cluster: shanghai-prod
url: <https://47.101.214.xxx:6443>
replicas: '3'
- cluster: frankfurt-prod
url: <https://8.209.103.xxx:6443>
replicas: '2'
- cluster: japan-prod
url: <https://10.0.0.xxx:6443>
replicas: '2'
template:
metadata:
name: '{{cluster}}-minecraft'
spec:
project: default
source:
repoURL: '<https://github.com/AliyunContainerService/gitops-demo.git>'
targetRevision: HEAD
path: manifests/helm/open-game
helm:
valueFiles:
- values.yaml
parameters: #对应helm chart中提取的value参数
- name: replicas
value: '{{replicas}}'
- name: scaled.enabled
value: 'false'
destination:
server: '{{url}}'
namespace: game-server #部署到对应集群的game-server命名空间下
syncPolicy:
syncOptions:
- CreateNamespace=true #若集群中命名空间不存在则自动创建
この Yaml では、すべてのイメージ バージョンが一貫しています。各クラスターのイメージ バージョンを異なるものにしたい場合は、レプリカと同じ方法で新しいパラメーターを追加できます。
PvPタイプのゲームを公開する
PvP タイプのゲームの場合、ルーム サーバーの数は、運用保守エンジニアが手動で指定するのではなく、独自のスケーラーによって割り当てられます。 PvP ゲームのクラウドネイティブのベスト プラクティスについては、OKG PvP ゲームのベスト プラクティスのドキュメント[ 8]を参照してください。
OKG では、GameServerSet の ScaledObject オブジェクトを構成することで、ルーム サーバーの柔軟なスケーリングを実装します。したがって、このシナリオでは、scaled.enabled をオンにする必要があります。さらに、ルーム サーバーのコピー数は、ArgoCD と OKG の 2 つのコントローラーと競合します。これは、ArgoCD に GameServerSet リソースのコピー数の変更を無視させることで解決できます。具体的には、spec.ignoreDifferences で対応するフィールドを設定します。上記を考慮すると、pvp.yaml は次のようになります。
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: pvp
spec:
generators:
- list:
elements:
- cluster: shanghai-dev
url: <https://47.100.237.xxx:6443>
- cluster: shanghai-prod
url: <https://47.101.214.xxx:6443>
- cluster: frankfurt-prod
url: <https://8.209.103.xxx:6443>
- cluster: japan-prod
url: <https://10.0.0.xxx:6443>
template:
metadata:
name: '{{cluster}}-pvp'
spec:
project: defaultminecraft
ignoreDifferences: # 设置 GameServerSet minecraft副本数目由集群自控制
- group: game.kruise.io
kind: GameServerSet
name: minecraft
namespace: game
jsonPointers:
- /spec/replicas
source:
repoURL: '<https://github.com/AliyunContainerService/gitops-demo.git>'
targetRevision: HEAD
path: manifests/helm/open-game
helm:
valueFiles:
- values.yaml
destination:
server: '{{url}}'
namespace: pvp-server
syncPolicy:
syncOptions:
- CreateNamespace=true
要約する
この記事では、例を使用して、グローバル ゲーム サーバー上の複数のリージョンで ACK One を一貫して配信するためのベスト プラクティスを紹介します。この例には、4 つの Kubernetes クラスターと単純なゲーム サーバー Yaml が含まれています。実際の運用環境では、クラスタの数がさらに多くなり、ゲーム サーバー アプリケーションの記述がより複雑になる可能性があります。このとき、アプリケーションを適切に抽象化することが重要です。
クラウド ネイティブ ゲームの DingTalk グループ(グループ番号: 44862615)に参加して、OpenKruiseGame 開発者やゲーム業界の研究開発および運用エンジニアとコミュニケーションやディスカッションを行ってください。ACK One に関する質問については、DingTalk グループ(グループ番号: 35688562)に参加することもできます。ご相談に応じます。
関連リンク：
[1] ACK 1 つの登録クラスター
[2] 登録クラスタの作成
[3] ACK One マルチクラスタ フリートの開始
[4] ACK 1 コンソール
https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Fcs.console.aliyun.com%2Fone
[5] GitHub ゲームサーバー Helm Chart の例
https://github.com/AliyunContainerService/gitops-demo/tree/main/manifests/helm/open-game
[6] GitOps にアクセスするにはパブリック ネットワークを開く必要があります
[7] OKG PvE ゲームのベスト プラクティス ドキュメント
https://openkruise.io/zh/kruisegame/best-practices/pve-game
[8] OKG PvP ゲームのベスト プラクティス ドキュメント
https://openkruise.io/zh/kruisegame/best-practices/session-based-game/
Google Python Foundation チームが解雇されたことを Google が確認し、Flutter、Dart、Python に関与するチームが GitHub のホット リストに殺到しました - オープンソースのプログラミング言語とフレームワークはどうしてこんなにも魅力的なのでしょうか? Xshell 8 が ベータ テストを開始: RDP プロトコルをサポートし、Windows 10/11 にリモート接続 できる Rail WiFi の最初の長期サポート バージョン 8.4 GA AI 検索ツール Perplexica : 完全にオープンソースで無料、Perplexity の代替となるオープンソースの価値をファーウェイ幹部が評価 : 継続的な抑制にもかかわらず、依然として独自のオペレーティング システムを持っています。ドイツの自動車ソフトウェア会社 Elektrobit が、Ubuntu をベースとした自動車オペレーティング システム ソリューションをオープンソース化しました。