AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4

© 2021, Amazon Web Services, Inc. or its Affiliates.
AWS Korea Game Tech
Aug. 2021
Series #4. AWS로 게임 런칭 준비하기

GMO2021 Members
AWS Game Master Online 2021
Game Tech Solution Architect
Game Tech Territory
Manager(Sales)
최문석 박진성 채민관 장준성

Contents
• AWS Game Master Online 2021 소개
• Series #4. AWS로 게임 런칭 준비하기
• 1부: 부하테스트와 모니터링을 AWS에서 구현해보자!
CloudWatch, Distributed Testing on AWS
Recipe & Estimate
• Special Guest “DINO” – AWS Game Tech Hackathon Winner!
• 2부: 카오스엔지니어링을 AWS에서 구현해보자!
AWS Fault Injection Simulator
Recipe & Estimate
• Tips for Game Masters – AWS 리전 선택 가이드

AWS Game Master Online
We are with Game Studio!

2021년 총 5개의 Episode로 이루어진 장기 프로젝트
https://pages.awscloud.com/game-master-online

Game Life Cycle
게임 개발 시작 단계부터 분석 단계까지 개발 과정에 초점을 맞춘 온라인 시리즈
Easy to Learn
AWS 초급자도 쉽게 이해할 수 있는 기초수준의 내용
Live Demo
AWS 서비스 활용 방안 소개 후 라이브 데모 진행
Recipe and Estimate
라이브 데모 시 실제 발생 될 예상 요금 공개
Live Q&A
채팅창을 통한 실시간 Q&A

AWS Game Master Heroes
• 선정 기준
o 총 4회 이상 참석한 고객 (설문조사 기반)
o Game Master Online을 통해 실제 AWS 서비스를 도입한 고객
o 2021년 11월 최종 선정 예정
• 혜택
o AWS Game Tech Gift Box 증정
o AWS 정규 교육과정 및 Certification 취득 시험 지원

Meet The Expert
검색 Keyword: AWS MTE
https://pages.awscloud.com/gametech-mte.html

1부: 부하테스트와 모니터링을 AWS에서 구현해보자!
CloudWatch, Distributed Testing on AWS
AWS Solutions Architect 장준성

게임 개발 흐름
게임 주제 선정
프로토타입 작성
개발팀 세팅
계획
개발
시연
알파
베타
출시

비기능적 요구 사항
성능
확장성
안정성
모니터링
비용
보안
접근성

성능 테스트
응답성, 안정성, 신뢰성, 확장성 등의 시스템 성능을
특정 상황 아래에서 확인하기 위한 비기능적 테스트

성능 테스트 종류
부하 테스트
스트레스 테스트
내구 테스트
벤치 마크 테스트
장애 테스트

성능 테스트의 문제점
부하를 발생시킬 만큼 인원 모집이 어려움
인프라 부족
사용자 인터렉션 예측이 쉽지 않음
반복 테스트 필요

클라우드에서의 성능 테스트
인프라의 단기 임대 가능
서비스 환경과 동일한 인프라 구성
독립적인 네트워크 환경 및 성능 보유
멀티 리전을 활용한 부하 발생 분산
환경 재배포 자동화

성능 테스트 목적
부하 테스트
내구 테스트
확장성 테스트
스파이크 테스트
장애 테스트
• 최대 허용 부하 확인
• 정상 서비스 지표 선정
• 지표 모니터링 구현
• 부하를 점진적으로 증가
• 단일 자원 / 복합 자원

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 허용 부하가 넘었을 때의 동작
테스트
• 감지 및 안내
• 부분적인 처리
• 부하 감소 시 정상 복구 테스트

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 오랜 기간 부하가 주어졌을 때의
문제점 확인
• 메모리 누수, 메모리 파편화 등
리소스 고갈
• 리소스 모니터링 지표
• 문제 해결 및 문제 우회 방법 찾기
(주기별 프로세스 교체)

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 부하에 따른 확장/축소 기능 검증
• 서비스 컴포넌트별 확장 검증
• 확장/축소 기준 지표 확인
• 확장/축소 시의 문제 모니터링

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 급격한 부하 증가 시 동작 테스트
• 서비스 출시할 때
• 서비스 점검 때
• 특정 시각 이벤트 때

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 벤치 마크 테스트

부하 테스트
내구 테스트
확장성 테스트
장애 테스트
• 장애의 영향도 파악
• 장애 복구 테스트
• 부하에 따른 장애 대응 확인

성능 테스트 진행하기
1. 테스트 환경 검토
2. 성능 만족 조건 확인
3. 테스트 준비 및 설계
4. 테스트 환경 구성
5. 테스트 구현
6. 환경 준비
7. 테스트 실행
8. 테스트 결과 분석, 보고
9. 문제 수정 및 반복 테스트

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
요구 사항 분석
테스트 목표 분석
테스트 범위 설정
프로덕션 환경의 아키텍처 확인

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
응답시간
처리량

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
주요 시나리오 선정
사용자 행동 비율 선정
테스트 데이터 생성
빌드 준비
지표 추가

빌드 준비
 기능적인 문제 해결된 안정화된 버전
 각종 우회 코드 구현
 지표 모니터링 기능 구현
 Profiling 코드 및 APM 모듈 임베드

지표 추가
 CPU – CloudWatch Metric -> Profiler -> 전용 Profiler
 Memory – 프로세스 메모리 지표, Swap 지표, 애플리케이션 내부
모니터링 도구
 Network – CloudWatch Metrics, bps, pps, ALB 의 로그
 Disk – CloudWatch Disk IOPS, Throughput
 Multithread – 관련 애플리케이션 지표
 외부 서비스 – Response Time, Throttling, 애플리케이션 지표, 로그
 Cache – Hit Rate, 사용 규모
 RDS – Performance Insights

AWS 환경에서의 모니터링
 CloudWatch
 CloudWatch Agent
 EC2 디테일 지표 수집 활성화
 RDS Performance Insights 활성화
 애플리케이션 지표 노출, 수집
 CloudWatch Agent + StatsD
 애플리케이션 로그 수집
 CloudWatch Logs, Embedded Metric Format -> 지표
 X-Ray 를 통한 Traceability

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 테스트 전략 선정
 사용할 툴 선정
 테스트 설계

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 설계에 따라 테스트 구현
 MMORPG 의 경우는 커스텀 봇
테스트기 작성
 시나리오 구현
 데이터 생성 구현

전용 봇 테스트 도구
 전용 프로토콜 사용 시 고려
 도구 구현 비용 고려

분산 부하 발생 도구
 부하 시나리오의 배포
 부하 테스트 시작, 종료
 분산된 측정 결과값의 통합 모니터링

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 테스트 대상이 되는 서비스 환경
 부하 발생기가 실행될 환경
 테스트 시나리오
 반복적인 재구성이 가능하도록
환경 구축 (IaC)
 모니터링 구축

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 테스트 시나리오 배포
 테스트 시나리오 실행
 지표, 로그 데이터 수집

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 테스트 데이터 통합
 테스트 데이터 분석
 테스트 분석 결과 공유
 다음 테스트 준비

5. 테스트 구현
6. 환경 준비
7. 테스트 실행
 모니터링 추가 후 테스트
 병목 수정 후 테스트
 설정 변경 후 테스트

문제 수정 및 반복 테스트
 모니터링 추가 후 테스트
 병목 수정 후 테스트
 설정 변경 후 테스트

성능 테스트 시 유의 사항
 외부 시스템 대상 테스트 시 해당 시스템에 알리기
 실제 사용자의 동작 패턴과 다른 시나리오 구성 유의
 환경 변화에 따른 성능 특성 변화
 데이터 규모, 트래픽 규모에 따른 성능 변화 주의

부하 테스트 도구들

Distributed Load Testing on AWS
https://aws.amazon.com/ko/solutions/implementations/distributed-load-testing-on-aws/
 분산 부하 발생기
 Taurus + jMeter 백엔드
 서버리스 아키텍처
 CloudFormation 을
통한 쉬운 배포

Demo Session

Recipe & Estimate

Recipe and Estimate
(https://calculator.aws/#/)
Scenario) Distributed Load Testing
• 하루 2회, 1시간씩 4 vCPU ECS Fargate Task 40 개를 한달 간 수행 했을 때
• AWS Fargate Spot ( 시간당 vCPU당 0.013968 $, 시간당 GB당 0.001533 USD )
(4 vCPU + 8GB) * 40개 * 하루 2시간 * 한달 20일 = 0.015501 USD * 1,600 = 24.8061 USD
• CloudWatch 11.89 USD, DynamoDB 0.46 USD, S3 20.06 USD, Lambda 0.00 USD, ECR 1.37
USD
• Total estimate : $ 59 (약 69,000)

Special Session: AWS GameTech Hackathon

TEAM DINO

TEAM DINO 소개
김지완 | Developer
wanzi.info
kjwan4435@gmail.co
m
조광민 | Designer
linkedin.com/in/KM-Cho
sky2021003@gmail.com
강상권 | Developer
resume.sangkwun.me
sangkwun@kakao.com
이도영 | Developer
doyounglee.com
dylee.hci@gmail.com
이송일 | Entrepreneur
linkedin.com/in/songil-lee-
01024680359
songilux@gmail.com
장한솔 | Entrepreneur
linkedin.com/in/hsjang
hansol.jang@outlook.kr
이지영 | Designer
linkedin.com/in/jiyoung-jay-lee-
456103185/
dlwldud8196@gmail.com

Running Mate, Zombie 소개
센서데이터를 활용하여 실제 달리기 속도 반영
실제로 달려야 하는 모바일 게임
친구와 함께 만나 달리고, 좀비로 만들어보세요.

DESIGN | 캐릭터
플레이어
좀비
VS

DESIGN | 게임 에셋
구름
나무
산
집
일반 모드 / 좀비 모드
낮 모드 / 밤 모드

GAME | 시나리오

GAME

GAME | 시작 화면
닉네임 설정
게임 시작
게임 플레이 정보
게임 캐릭터
게임 세팅(소리/진동)

GAME | 대기 화면
다른 플레이어 입장
나의 게임 캐릭터
울타리 안 좀비들

GAME | 게임 화면 (인간 상태)
인간 상태로 게임이 시작되며,
캐릭터의 스피드는 실제 달리는 속도를 반영하여 정해짐.
뒤쫓아오는 좀비 플레이어에게 잡히면 좀비로 변하게 됨.
타이머
좀비 상태 ( 좀비에게 잡힌 유저 ) 플레이어 캐릭터 인간 상태 ( 감염되지 않은 유저 )

GAME | 게임 화면 (좀비 상태)
좀비 플레이어가 유저를 잡아 먹게 되면,
유저의 캐릭터는 좀비로 변하게 됨.
좀비로 변하게 된 유저의 미션은
다른 사람 플레이어를 잡아 먹어 좀비로 만드는 것!
잡은 사람 수 좀비 상태의 플레이어

GAME | 엔딩 화면
인간으로 살아남는 엔딩 좀비로 끝나는 엔딩

GAME | 사용 기술 소개
Lambda Dynamo DB
Cognito
GameLift
Game Server (Fleet)
4) 사용자 데이터 확인 (평균 달리기 속도)
1) Credential 요청
3) 매치메이킹 요청
Social Login
5) 사용자 데이터 기반 매치메이킹 요청
8) 세션 찾기/만들기 성공시
세션 정보 반환
(IP, Port, Session ID )
6) 서버에 가능한 세션 확인
9) 클라이언트 콜백
10) 반환된 세션 정보로 서버에 접속
7) 찾은 세션 반환 / 없으면 생성
2) OpenID Connect 기반 인증

PLAN | 앞으로의 계획
서비스 런칭
(10월 중순)
사용자 달리기 데이터 저장 및
분석
과거의 나와의 달리기 대결과 같이
달리기 데이터 분석을 통한
재미있고 효율적인 운동방법 제안
온라인 마라톤 / 달리기 이벤트 기획
코로나로 인해 거의 불가능해진
마라톤이나 좀비런과 같은 달리기
이벤트를 온라인으로 기획하여 개최

2부: 카오스엔지니어링을 AWS에서 구현해보자
AWS Solutions Architect 채민관

순서
• 카오스 엔지니어링이란?
• AWS Fault Injection Simulator
• 시연
• 시나리오 1 – EC2 중단
• 시나리오 2 – RDS 중단
• 시나리오 3 – 네트워크 지연

카오스 엔지니어링

카오스 엔지니어링 이란?
• 카오스 몽키!
https://github.com/netflix/chaosmonkey
• 2011년 Netflix “야생 원숭이가 무작위로
인스턴스를 파괴하고 케이블을 끊더라도
서비스에는 이상이 없어야 한다”
• 매일 임의의 인스턴스를 선택해서 경고
없이 끄는 방식으로 진행.

카오스 엔지니어링 이란?
• “의도적으로 장애”를 일으킴으로써 시스템의
탄력성을 더 높일 방법을 찾아내는 것.
• 복잡한 마이크로 서비스 아키텍처, 분산처리
시스템의 엔지니어링 원칙
• DEVOPS의 완성, 카오스 엔지니어링!

Why? 복잡한 현대의 아키텍처
https://aws.amazon.com/ko/solutions/case-studies/npixel/

Why? 기존의 테스트만으로는 부족
예상 가능한 환경에서의 테스트!
유닛 테스트
Tested in isolation to ensure
function meets expectations
통합 기능 테스트
Each execution path tested
to assure expected results

Why? 수많은 예측 불가능한 상황들 IOError: No space left on device
close failed in file object destructor:
IOError: No space left on device
logfile
ROTATE
logfile.0
ROTATE
logfile.1
ROTATE
logfile.2
ROTATE
logfile.3
ROTATE
logfile.n
ROTATE

카오스 엔지니어링 단계
상태 정의
가설 세우기
실험하기
검증하기
개선하기

카오스 엔지니어링 시작하기
1. 정상 동작을 나타내는 시스템의 측정 가능 통계치로 ‘정상 상태’ 정의하기
2. 정상 상태가 대조군 실험군 모두에서 계속 될 것이라고 가정하기
3. 서버 장애, 하드 디스크 오작동, 네트워크 끊김 등과 같은 실제 문제에 대한 변수
정의하기
4. 대조군과 실험군 사이의 정상 상태 차이를 조사하여 가설 검증하기

정말 하기는 쉽지 않음…
안전하게 하기
어려움
인프라별 다양한 툴,
스크립트 직접 짜야함
1
에이전트/
라이브러리 설치의
어려움
3
2
실제 장애 연출의
어려움(다양한 장애가
한번에 터지거나..)
4

카오스 엔지니어링 도구
• Gremlin (https://www.gremlin.com/)
-클라우드 지원
• 리트머스 (https://litmuschaos.io/)
-오픈소스, k8s 특화
• 그리고, AWS FIS

시스템 보호
실제 장애 시나리오
손쉬운 설정
완전관리형 카오스 엔지니어링 서비스

복잡한 여러가지 툴이나, 스크립트를 작성할
필요 없음.
AWS 콘솔이나 CLI 로 설정 가능.
사전 설정된 실험 템플릿으로 빠르게 시작.
실험 템플릿 공유 가능(JSON)
손쉬운 설정

실제 장애 시나리오
다양한 작업으로 시나리오 생성 가능(순차
실행, 임의의 지연 시간)
서비스, 인스턴스 등의 다양한 리소스
대상으로 실험 가능
실제 장애를 일으키는 실험 가능

시스템 보호
“중단 조건” 설정 가능
Amazon CloudWatch 활용
실험 후 롤백 지원
IAM 으로 세밀한 권한 조정

특징들
• AWS에서 카오스엔지니어링을 실행하기 위한 완전관리형 서비스
• 다양한 AWS 서비스에서 오류를 일으키는 실험을 설정하고 실행
• 사전에 구축된 템플릿을 사용하여 실험을 신속하게 설정
• 프로덕션에서 실험을 실행하는 데 필요한 제어 및 가드 레일을 제공
• 복잡한 시나리오를 실행하여 실제 조건을 만들 수 있음

FIS engine
Start experiment
내부 아키텍처
AWS Fault Injection
Simulator
Experiment
template
AWS Command
Line Interface
AWS Management
Console
AWS Identity and
Access Management
FIS safeguards
Compute
Third party
AWS
Amazon
EventBridge
Amazon
CloudWatch
alarms
AWS resources
Databases Networking Storage
Compute
Monitoring
Stop experiment

구성요소
실험 템플릿 실험하기
작업 대상

작업(Actions)은 실험이 진행될 동안 발생할 오류를 정의함.
aws:<service-name>:<action-type>
Actions include:
• Fault type
• Targeted resources
• Timing relative to any other actions
• Fault-specific parameters, such as duration, rollback
behavior, or the portion of requests to throttle
작업(Actions)

작업(Actions)
"actions": {
"StopInstances": {
"actionId": "aws:ec2:stop-instances",
"parameters": {
"duration": "PT10M",
"startInstancesAtEnd": "true"
},
"targets": {
"Instances": "RandomInstancesInAZ"
}
},
”Wait": {
"actionId": " aws:fis:wait",
"parameters": {
"duration": "PT1M",
},
"startAfter": [
"StopInstances"
]
},
}

대상(Targets)
대상(Target)은 작업(Acitons)을 적용할
리소스를 정의함
Targets include:
• Resource type
• Resource IDs, tags, and filters
• Selection mode (e.g., ALL, RANDOM)

대상(Targets)
"targets": {
”RandomInstancesInAZ": {
"resourceType": "aws:ec2:instance",
"resourceTags": {
”Env": ”test"
},
"filters" : [
{
"path": "Placement.AvailabilityZone",
"values": ["us.east.1a"]
},
{
"path": "State.Name",
"values": ["running"]
},
{
"path": "VpcId",
"values": ["vpc-0123456789"]
}
]
"selectionMode": ”COUNT(2)"
}

{
"tags”: {
"Name": "StopAndRestartRandomeInstance"
},
"description": "Stop and Restart One Random Instance",
"roleArn": "arn:aws:iam::0123456789:role/MyFISExperimentRole”,
"stopConditions": [
{
"source": "aws:cloudwatch:alarm",
"value": " "arn:aws:cloudwatch:us-east-1:0123456789:alarm:No_Traffic"
}
],
"targets": {
"myInstance": {
"resourceTags": {
”Env": ”test"
},
"resourceType": "aws:ec2:instance",
"selectionMode": ”COUNT(1)"
}
},
"actions": {
"StopInstances": {
"actionId": "aws:ec2:stop-instances",
"description": "stop the instances",
"parameters": {
"startInstancesAtEnd": "true”,
"duration": "PT2M",
},
"targets": {
"Instances": "myInstance"
}
}
}
}
실험 템플릿 설정하기
Description
IAM role
Stop conditions
Targets
Actions
Name

실험은 “실험 템플릿”을 기반으로 실제 진행된 스냅샷(로그)를
뜻함.
Experiments include:
• Snapshot of the experiment
• Creation and start time
• Status
• Execution ID
• Experiment template ID
• IAM role ARN
실험하기

지원 오류 목록
Server error (EC2)
Stop, reboot, and terminate instance(s) (EC2)
API throttling
Increased memory or CPU load (EC2)
Kill process (EC2)
Latency injection (EC2)
Container instance termination (ECS)
Increase memory or CPU consumption per task (ECS)
Terminate nodes (EKS)
Database stop, reboot, and failover (RDS)
계속 추가 중!!
Supported
fault injections

Demo

데모 아키텍처(서비스)
AWS Cloud
Ap-northeast-2 AZ-b
RDS Aurora(master)
2
2
RDS Aurora
MySQL 5.7 (2.09.2)
Db.r5.xlarge
R/W 1대(AZ-a), R/R 구성(AZ-b)
Ap-northeast-2 AZ-a
Apache + PHP on EC2 #1 ~ #5
1
1
EC2 Test-Client
Amazon Linux2
C5.large
10대
Apache +PHP
Apache + PHP on EC2 #6 ~ #10
Application Load
Balancer
RDS Aurora(replica)
http://loadtester-2026219477.ap-northeast-2.elb.amazonaws.com/

아키텍처 안정성을 위한 조치들
• 멀티 AZ로 이중화
• Application Load Balancer 장애 감지
• RDS의 failover
• 그 외에 Auto-Scaling, 주기적인 백업, 멀티 리전 전략 등…

데모 시나리오
• AZ-a 의 EC2 인스턴스 2대 중단
예상 : 수초 동안 20% 요청이 실패하지만, ALB 가 중단된 EC2를 서비스 목록에서 제거하여 서비스 정상화
• AZ-a 의 모든 EC2 인스턴스 중단
예상 : 수초 동안 요청의 50%가 실패하지만, ALB 가 중단된 EC2를 서비스 목록에서 제거하여 서비스 정상화
• AZ-a RDS Writer 중단
예상 : 수십초동안 모든 요청이 실패하지만, RDS가 secondary 로 failover 하여 서비스 정상화
• AZ-a 의 EC2 인스턴스의 2대의 네트워크 지연
예상 : 실험 진행중에 20% 요청이 지연되지만 서비스에 큰 지장은 없음.

데모 아키텍처(모니터링 클라이언트)
AWS Cloud
Administrator
loadTester 1 ~ n…
Amazon
API Gateway
loadTesterManager
Amazon DynamoDB
Amazon SNS
Web Service

Recipe and Estimate
(https://calculator.aws/#/)
Scenario) Live-demo Workflow
• 10분간 진행되는 Fault Action 을 100번 수행 했을 때
• AWS FIS ( 분당 $0.1 : $100 )
• 그 외 서비스 비용은 별도
• Total estimate : $100 (약 110,000)

Tips for the Game Masters

AWS 리전 선택 가이드
Q) 글로벌 게임 런칭을 준비하고 있습니다. 어느 리전을 선택해야 하나요?
A) 다양한 조건을 사전에 검토하셔서 리전을 선택하셔야 합니다.
(주요 타겟 국가, 서비스 제품, 가격, 게임의 장르 등)
비동기 방식 게임(웹기반, 방치형 장르) : 하나의 리전 + CloudFront 동적 컨텐츠 전송
세션 방식 게임(FPS, 실시간 대전류) : 타겟 국가와 근접한 리전에 백엔드 배치 + AWS Global Accelerator
멀티플레이어 온라인 게임(MMORPG) : 플레이어 분포에 인접한 리전

Game Master Online 2022
여러분의 목소리가 큰 힘이 됩니다.

감사합니다

AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4

Ähnlich wie AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4 (20)

Mehr von Amazon Web Services Korea

Mehr von Amazon Web Services Korea (20)

AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4