저자: Liu Qiuyang, Cai Jing
머리말
오늘날 전 세계적으로 통합된 경제 환경에서 디지털 엔터테인먼트 산업은 점차 문화 및 상업 교류의 강력한 대표자가 되고 있습니다. 이러한 맥락에서 많은 게임 제조사들이 자사의 게임을 해외로 진출시키기 위해 노력해 왔으며, 많은 게임이 글로벌 서버 구조를 통해 전 세계적으로 다양한 플레이어 그룹을 끌어들이고 있습니다. 게임의 글로벌 배포는 개별 제품의 시장 규모를 확대할 뿐만 아니라 게임 제조업체의 글로벌 영향력을 증가시키는 동시에 다음과 같은 많은 기술적 과제도 안겨줍니다.
게임 서비스에 필요한 높은 빈도의 상호 작용과 낮은 대기 시간을 위해서는 글로벌 서버 프레임워크에 따라 게임 서버를 여러 지역에 배포해야 합니다. 실제 운영에서는 일반적으로 대상 사용자 그룹의 지리적 위치와 대기 시간 허용 범위를 기반으로 서버 위치를 미리 계획해야 합니다. 일반적으로 다음 영역은 우리의 우선 서버 주소입니다. 미국 동부 는 인구 밀도가 높고 많은 북미 플레이어에게 서비스를 제공할 수 있습니다. 프랑크푸르트 지역은 유럽 인터넷의 교차점이며 네트워크 경험을 효과적으로 제공할 수 있습니다. 유럽 전역의 플레이어 ; 도쿄 지역은 주로 일본과 한국의 플레이어를 지원합니다.
가능한 구성 차이, 게임 버전 업데이트 및 다양한 지역의 서버 수 불일치에 직면하여 글로벌 규모로 게임 서버의 일관된 제공을 효과적으로 달성하는 방법은 글로벌 서버를 설계할 때 직면하고 해결해야 하는 핵심 과제가 되었습니다. 건축학. . 이 문서에서는 예를 사용하여 글로벌 게임 서버의 다중 지역 일관성 제공에 대한 모범 사례를 설명합니다.
배포 아키텍처
예시에서는 상하이, 도쿄, 프랑크푸르트에 서버를 개설할 계획이므로 이 세 지역에 인프라 리소스가 필요합니다. 이기종의 복잡한 인프라 시나리오에 직면한 클라우드 네이티브가 제공하는 선언적 API와 일관된 제공 기능은 기본 리소스의 차이를 완전히 보호하여 게임 운영 및 유지 관리 엔지니어가 애플리케이션 자체에 집중할 수 있도록 하고 게임 서버 제공 효율성을 크게 향상시킵니다. . 지역 자율성 안정성과 사용자 스케줄링 복잡성 측면에서 각 서버 지역에 Kubernetes 클러스터를 독립적으로 배포하고 멀티 클러스터 기능을 통해 통합 운영 및 유지 관리를 관리하는 것이 일관된 게임 서버를 제공하는 가장 좋은 방법이라고 믿습니다.
이 실습에서는 다중 지역 Kubernetes 클러스터를 관리하기 위해 Alibaba Cloud의 분산 클라우드 컨테이너 플랫폼 ACK One을 선택했습니다. 하이브리드 클라우드, 멀티 클러스터, 재해 복구 및 기타 시나리오를 위한 Alibaba Cloud의 엔터프라이즈급 클라우드 네이티브 플랫폼인 ACK One은 모든 지역 및 인프라에서 Kubernetes 클러스터를 연결 및 관리할 수 있으며 일관된 관리를 제공하여 애플리케이션과 트래픽을 지원합니다. , 보안, 저장, 가시성 등이 통합 제어됩니다.
이 예제의 배포 아키텍처는 서로 다른 지역의 3개 프로덕션 환경과 1개의 개발 및 테스트 환경을 포함하여 그림에 표시됩니다. 일반적으로, 프로덕션 환경에 배포하기 전 R&D 테스트 환경에서 해당 버전이 안정적인지 검증 및 확인함으로써 프로젝트의 전반적인 안정성을 확보하고 잠재적인 위험을 효과적으로 예방하는 데 도움이 됩니다.
이 예에서는 멀티 클러스터 하이브리드 클라우드 아키텍처를 사용합니다. 구체적으로 상하이 클러스터, 프랑크푸르트 클러스터, 상하이 데브 클러스터는 Alibaba Cloud ACK 클러스터인 반면, 일본 클러스터는 클러스터를 등록하여 통합 및 관리되는 비Alibaba Cloud Kubernetes 클러스터입니다. 각 클러스터 내에서 GameServerSet을 사용하여 게임 서버를 배포합니다. GameServerSet은 CNCF(Cloud Native Computing Foundation)에서 인큐베이팅한 오픈 소스 프로젝트인 OpenKruise에서 제공하는 게임별 워크로드입니다. 기본 배포 및 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 repo가 이러한 특성을 자연스럽게 충족한다는 것을 알게 될 것입니다. 운영 및 유지 관리 엔지니어는 커밋 및 병합 요청을 제출하고 모든 git 사양을 감사하여 디스크에 Yaml을 업로드하고 저장할 수 있습니다. 이상적인 세계에서는 게임 서버에 대한 일련의 YAML 설명만 유지하고 한 번의 클릭으로 전 세계 여러 지역의 게임 서버 출시를 트리거하면 됩니다. 배포를 수행하기 위해 클러스터를 하나씩 운영할 필요가 없습니다. 행위. 이것이 GitOps의 아이디어입니다.
GitOps 구현 과정에서 가장 어려운 점은 실제로 게임 서버 애플리케이션에 대한 추상적인 설명입니다. 글 서두에서 언급했듯이 지역마다 게임 서버의 차이가 다소 있고, 모든 게임 서버를 하나의 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의 왼쪽 탐색 모음에서 설정을 선택한 다음 리포지토리 > + Repo 연결을 선택합니다.
-
팝업 패널에서 다음 정보를 구성한 후 CONNECT를 클릭하여 연결을 추가합니다.
PvE형 게임 퍼블리싱
PvE 게임은 일반적으로 지역 서버라는 개념을 가지고 있으며, 대부분의 경우 운영 및 유지 관리 엔지니어가 각 지역에 열려 있는 서버 수를 수동으로 제어합니다. 클라우드 기반 PvE 게임의 모범 사례는 OKG PvE 게임 모범 사례 문서 [ 7] 를 참조하세요 .
흰색 화면 관리 애플리케이션
ArgoCD를 처음 시도할 때 흰색 화면 콘솔을 사용하여 각 지역의 클러스터에 대한 애플리케이션을 생성할 수 있습니다.
-
ArgoCD UI의 왼쪽 탐색 모음에서 애플리케이션을 선택한 다음 + 새 앱을 클릭합니다.
-
팝업 패널에서 다음 정보를 구성한 후 CREATE를 클릭하여 생성합니다. (opengame-demo-shanghai-dev를 예로 들어 보겠습니다).
- 생성이 완료되면 신청 페이지에서 opengame-demo-shanghai-dev의 신청 상태를 확인할 수 있습니다 . SYNC POLICY가 수동 모드를 선택하는 경우 수동으로 SYNC를 클릭하여 애플리케이션을 대상 클러스터에 동기식으로 배포 해야 합니다 . 애플리케이션의 상태 는 Healthy 및 Synced 이며 이는 동기화가 성공했음을 나타냅니다.
- opengame-demo-shanghai-dev 애플리케이션 이름을 클릭하면 애플리케이션 세부 정보를 확인하고 애플리케이션과 관련된 Kubernetes 리소스의 토폴로지 및 해당 상태를 표시할 수 있습니다.
ApplicationSet을 통해 한 번의 클릭으로 게시
ArgoCD에 익숙해지면 ApplicationSet 개체를 사용하여 한 번의 클릭으로 게임 서버를 게시할 수도 있습니다. 각 클러스터의 차이점은 요소를 통해 추상화됩니다. 예를 들어 아래 Yaml에서는 클러스터 차원에서 세 개의 필드가 추상화됩니다. 클러스터 이름은 애플리케이션 이름을 구별하는 데 사용됩니다. 다양한 클러스터에서 게시된 게임을 구별합니다.
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 두 컨트롤러와 충돌합니다. 이는 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을 일관되게 제공하기 위한 모범 사례를 소개합니다. 이 예에는 Kubernetes 클러스터 4개와 간단한 게임 서버 Yaml이 포함됩니다. 실제 프로덕션 환경에서는 클러스터 수가 더 많아지고 게임 서버 애플리케이션 설명이 더 복잡해질 가능성이 높습니다. 이때 핵심은 애플리케이션을 잘 추상화하는 것입니다.
클라우드 네이티브 게임 DingTalk 그룹 (그룹 번호: 44862615) 에 가입하여 OpenKruiseGame 개발자 및 게임 산업 R&D 및 운영 엔지니어와 소통하고 ACK One과 관련된 질문에 대해 토론할 수 있습니다. DingTalk 그룹 (그룹 번호: 35688562) 에도 가입할 수 있습니다. 상담을 위해.
관련된 링크들:
[1] ACK One 등록 클러스터
[2] 등록 클러스터 생성
[3] ACK One 멀티 클러스터 플릿 시작
[4] ACK 원 콘솔
https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Fcs.console.aliyun.com%2Fone
[5] GitHub 게임 서버 Helm 차트 예시
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에 원격으로 연결할 수 있습니다. 승객이 고속철 WiFi에 연결하면 중국 코더의 "35세 저주"가 고속으로 연결됩니다. 레일 WiFi MySQL의 첫 번째 장기 지원 버전 8.4 GA AI 검색 도구 Perplexica: 완전히 오픈 소스이며 무료이며 Perplexity의 오픈 소스 대안입니다. Huawei 경영진은 오픈 소스 Hongmeng의 가치를 평가합니다. 지속적인 탄압에도 불구하고 여전히 자체 운영 체제가 있습니다. 독일의 자동차 소프트웨어 회사 인 Elektrobit는 우분투 기반의 자동차 운영체제 솔루션을 오픈소스화했습니다.