출처: https://dev.classmethod.jp/cloud/aws/20191120-agdc-b2-pubg-architecture/

2019년 11월 20일에 일본에서 열린 AWS 게임 테크 발표를 정리한 것

세션 개요

PUBG Corporation은 세계에서 50만개 이상 판매 된 PLAYERUNKNOWN 'S BATTLEGROUNDS의 개발 및 운영을 하고 있습니다. PUBG는 Amazon EC2, DynamoDB, SQS, S3 및 CloudFront 등 Amazon Web Services에서 제공하는 다양한 서비스를 제공하고 있다. 본 세션에서는 PUBG 백엔드 아키텍처와 AWS 서비스가 실제로 어떻게 이용되고 있는지를 소개한다.

PUBG Architecture Overview

톱 제목(OutGame로 읽는다) → 매치 메이킹 → 캐릭터 변경 → 전적 확인

→ Angular / MicroService Server .NET Core 3.0(C#)

Donkatsu Dinner(일본의 경우)를 먹기 위하여 노력하는 배틀 로얄 게임

Unreal Engine을 사용한다

메인 샤드와 게임 샤드로 나누고 있다

• 메인 샤드 : WebSocket 클라이언트와 통신, 모든 인스턴스가 Privaet Subnet로 버지니아 리전에 두고 있다
• 게임 샤드 : UDP 통신, 모든 인스턴스가 Public Subnet로 버지니아 리전에 두고 있고, DB 등은 사용하지 않는다
• 메인 샤드는 하나의 리전
• 게임 샤드는 다양한 리전에서 만든 각 리전에 존재
• 데이터 관리의 메인 샤드는 하나의 리전에서 저장하고 있다.
• 메인 샤드는 Private Subnet로 외부에서 액세스하려면 Public Subnet에 둔 Public Subnet으로 통신
• 메인 샤드에서 데이터를 저장

Server Components In Depth

Micro Service 구조로 되어 있다.

Micro Service 장점

서비스 필요한 부분만 확장

서비스를 독립적으로 개발할 수 있다

오류가 발생해도 분리하기 쉽다

Micro Service 단점

서비스 디스커버리 기능이 필요

운영 및 모니터링에 시간이 걸린다

PUBG는 장점이 단점보다 크기 때문에 Micro Service를 선택.

마이크로 서비스의 서비스 의존도가 잘 모르게 된다

"One project, One binary"에서 "do different depending on settings"

PUBG는 44 마이크로 서비스에서 움직이고 있다.

SQS

서비스 간 통신에는 일반적인 HTTP와 Messaging Queue를 이용하고 있다.

Direct HTTP Request 중복 처리 / 실패해도 괜찮은 것에 이용

절대 처리하지 않으면 안 되는 것, 비동기 적으로 처리하는 것에 Queue를 이용

큐를 사용하면 마이크로 서비스의 결합도를 낮춘다

PUBG의 Beta 환경에서는 다양한 Message Queue Service를 사용하고 있었지만 결국 SQS를 이용

→ 무한 용량, 안정, 명시적으로 메시지를 삭제하지 않으면 큐에 남기 때문에 장애가 발생하더라도 큐에 계속 남아 있다

DynamoDB

객체 관계 매핑이 필요하지 않기 때문에, DynamoDB를 이용.

사용자 ID를 이용하여 필요한 문서를 읽고 처리하고 있다.

NoSQL 중에서도 DynamoDB를 사용한 이유

• 완전 관리에 스케일링 해주는 비용 절감
• 순간적인 폭발을 장애 없이 처리 할 수 있다

CloudFront

S3를 Origin으로 하고 CloudFront 가능.

OutGame Serer와 연결된 때도 업데이트로 WebSocket이 대응하고, CloudFront를 사용할 수 있도록 한다.

CloudFront와 Global Accelerator도 나왔지만, 모든 시간대에서 안정적인 대기 시간이 더 중요하기 때문에 CloudFront를 이용.

Logging Infra

System Game Log와 OutGameLog는 Kinesis에 흘려서 Elasticsearch과 Kafka LogStream에 던져 Kafka에서 E Suports에 대한 실시간 분석

S3 로그 분석은 Data Tech Team이 Airflow + Spark (/ Dynamo)로

Monitoring

Server Metrics : DataDog, Promotheus를 이용하여 수집

SystemLogs : Elasticdearch, Kibana

Kubernetes Migration

메인 샤드를 Kubernetes로 전환

커밋 후 자동으로 Jenkins 빌드, S3 및 ECR에 업로드. CodeDeploy에서 ECS / EC2에 배포.

초기에는 CodeDeploy에서 배포하고 있었지만, 총 100 프로젝트가 되어 버렸다.

Terraform과 CodeDeploy는 너무 많아서 관리할 수 없게 되었다.

테스트 인프라를 구성해야 하고 서비스 플랫폼도 늘고 필요한 테스트 인프라도 필요하게 되었다.

테스트 서버도 인프라가 복잡하고 관리가 어렵다.

서비스가 증가함에 따라 작업량도 비례하여 증가했다

→ Kubernetes로 Migration했다.

Terraform 등에서는 사람이 수동으로 만진 자원을 관리 해주지 않지만, Kubernetes는 수동으로 만져도 자동으로 관리 해준다

명시적 배달 관리가 가능하며, 환경의 복사도 쉽다.

컨테이너의 고립된 환경과 복구 기능로 장애를 해결하는데 도움이 되었다

배포 흐름

   Repository -> Jenkins -> ECR -> YAML -> EKS

총 13 클러스터를 운용

8 클러스터는 실전, 3 클러스터는 QA 테스트 환경(10 ~ 30의 테스트 환경), 2 클러스터는 내부 관리

EKS : 매니지드로 관리 할 수 있고, ​​IAM의 결합이 편리

Kubernetes는 모든 문제를 해결하는 마법의 지팡이가 아니다(배워야 하는 것이 많다)

• YAML 작성 방법
• 동작의 이해
• 상호 작용하는 응용 프로그램의 이해

등 ..

Kubernetes에 치명적이라고도 할 수 있는 버그가 있긴 했지만

→ 대규모 클러스터에만 영향이 일어나지 않는 버그 등

"Kubernetes is hard, and not a sliver bullet"

분명히 장점이 있고, 알고 사용한다면 강력한 도구

QA

Q. Fargate를 사용하는 것은 생각하지 않았나?

A. 작업 생성 비용이 Kubernetes와 같은 정도로,별로 메리트가 없다

Q. EKS를 활용할 때 직원 교육 비용은 힘들지 않았나요?

A. 교육 과정을 통과 할 수 있도록 하는 제도를 만들어 가고 싶지만 어렵다

Q. Fifo Queue를 사용 하시나요?

A. FifoQueue를 사용하지 않는다. 스탠다드 Queue를 사용하여 한 번 전달 되도로하고, 내부에서 중복하지 않도록 하고 있다.