1. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
김성수
솔루션즈 아키텍트 – 게이밍
AWS 멀티리젼 서비스 활용
전략 – DR, 그리고 원소스
멀티리젼 글로벌 원빌드
운영전략

2. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
이번 세션에서는
DB는 어떻게
선택하지?
AI/ML은 어떻게
적용하지?
DR은 어떻게
구축하지?
데이터 분석은 어떻게
해야하지?

3. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
이번 세션에서는
데이터 분석은 어떻게
해야하지?
DB는 어떻게
선택하지?
AI/ML은 어떻게
적용하지?
AWS의
멀티리젼
서비스들을
활용하기

4. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR해야나하요?

5. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR해야나하요?
• 원인이 무엇이던 여러분의 Data center에 문제 발생 가능
• 인재, 천재지변, 기타
• AWS도 이러한 문제에 대하여 최대한 노력중
• 완벽한 이중화, 복수의 인터커넥트 등
• 그럼에도 불구하고 문제는 발생할 수 있습니다
• 2003 미국 북동부 정전, 2012허리케인 Sandy, 2011년
9.15정전사건
• 그래서 여러가지 방법으로 DR, 또는 그에 준하는 방법을 강구

6. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
보통 DR이라고 하면…..
• RPO, RTO를 먼저 생각하게 됩니다.
• 전통적인, 그리고 현재도 많은 엔터프라이즈 업무에선
그런 관점이 유효합니다.
• 물론 게임에서도 Roll Back을 생각하면 필요한 개념입니다.
• 하지만 구현은 전통적인 방법론에 의존할 필요는 없죠.
• 게임, 그리고 AWS의 특성을 최대한 살리는 방법을
찾아보겠습니다!

7. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
우리가 생각할 수 있는 DR의 종류
• Main IDC 와 Sub IDC 를 통하여 DR구성
• Main IDC 와 Cloud를 구성하여 DR구성
• Main Cloud와 Sub Cloud를 활용하여 DR구성
• Main Cloud의 복수 Region을 활용하여 DR구성
• Main Cloud의 복수 AZ를 활용하여 DR구성

8. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
게임에서의 DR 선택
• 금융권과 달리 규제에 의한 필수 선택사항이 아닐수 있다.
• 어카운트/ 과금에 대한 부분은 전통적 DR을 고민
• 게임 자체의 DR은 어떻게 봐야할 것인가?
• 잘못된 설계를 선택하면 ROI가 안 나올수 있다.
• 전체적인 가용성의 증대
• 가급적 게임 특성을 살리는 방향으로
• Disaster Recovery에만 제한을 둘 필요는 없다.

9. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
결론: DR해야합니다.
• 어떻게 할까요?
• 단순히 동일한 구성을
복수개 만들어서
Active/ Standby로
만들면 될까요?

10. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
기존 사이트의 복사
• 기존의 사이트를 새롭게 하나 더 만드는 방법
• 지금까지의 많은 DR전략의 형태
• 현재 서비스 형태에 따라 유일한 선택일 수도
• 이미 IDC에 대규모 투자가 이루어진 상태
• IDC 에서 여러 장애를 겪고 이에 대한 대비책이 필요할때
• 높은 도입/ 유지 비용이 필요
• 데이터의 싱크를 위한 추가적인 인프라가 필요

11. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
• 그런데 Active/ Standby 로 구성하면 아무 서비스를 하지
않는 Standby는 낭비 아닐까요?
• Active에서 Standby로 계속해서 데이터를 넘겨야합니다.
• 언제 Down이 발생할지 모르니까 정기적/ 실시간으로
Data/ Application Sync가 필요합니다
• 사용하지 않아도 계속 관리해줘야합니다.
• 비용과 노력은 2배이상, 효율은 오히려 낮아집니다.

12. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS상의 DR구현을 통하여 기대할 수 있는 부분
• 사용자 경험의 개선
• AWS리소스의 효율적인 활용 가능
• 사용자 ISP의 지역 장애에 대한 효과적인 대응 가능
• 안정적인 사업 전개 가능
• 외부 요인으로 인하여 게임, 또는 사용자 지원을 멈출
필요가 없다
• 게임내의 장애, 이벤트 폭주등의 문제로 인해 전체가
마비되는 것을 막을수 있습니다.

13. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR을 구축할 때 고민
• 기대 복구 소요 시간
• 복구가 필요한 데이터의 총량
• 복구에 필요한 시간
• 복구가 필요한 요소들은?
• 원복할지 여부/ 그 기준?

14. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
복구 소요 시간
• Data
• DB와 같은 중요 데이터의 복구; 소요 시간이 길다.
• 복구할 양이 보통 많다.
• Application
• Application Server의 복구; 소요 시간이 중간
• Instance의 시작, binary의 배포, Managed Service의 기동
• Infrastructure
• 인스턴스, Load Balancer등의 복구; 소요 시간이 짧다.
• Service의 활성화 및 기동

15. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR복구 목표 시간에 따라서
• Full Stack in the cloud
• 모든 구성이 Cloud상에 이중화
• 즉시 복구 가능
• Partial Stack in the cloud
• 중요 구성이 Cloud상에 존재
• 추가 구성은 Failover도중에 진행
• Data in the cloud
• Failover시 모든 구성을 진행

16. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR복구, 비용에 따라서
• Full Stand by
• 가장 비용이 많이 소요
• Data Only real time
• 비용이 많이 소모
• Data Only batched
• 주기적인 Backup File의 보관, 저비용이지만 일정 부분
Data Loss를 안고 감
• Recovery에 더 많은 시간이 소모
• Small Scale/ Reduced Capacity
• 다양한 Data 복구 전략과 함께 일정한 수준의 비용이 소요

17. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR복구전략
• DR복구는 비용과의 싸움
• 복구 시간이 중요하면 그에 상응하는 비용이 필요
• 비용
• 금전적 ($$$)
• 인적 (Man hour투입) 비용
• 시간, Data loss

18. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
과연 이러한 선택만이 있을까요?
• Recovery Time vs cost vs data loss
0
1
2
3
4
5
6
0
1
2
3
4
5
6
7
8
9
10
1 2 3 4 5 6 7 8 9 10
Recovery time cost data loss

19. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
• 그러면 어떻게 해야할까요?

20. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Come to cloud

21. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
게임에서 DR 다시 생각하기
• 금융기록 자료등과 달리 게임에서 DR은 조금 유연하게 볼
여지가 있습니다.
• DR의 특성을 활용한 게임 아키텍쳐를 만들면 어떨까요?
• 아니면 AWS의 특성을 활용하여 DR을 구축하는 것은
어떨까요?
• 비용효율적인 관점으로 봅니다!

22. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR에 유리한 AWS의 특성
• On Demand Infra가 가능
• Region과 Region은 구성이 Standard화
• 같은 region내의 AZ는 동일한 기능제공
• Region에서 Region은 가능한 전용망을 통한 통신 – low
latency
• Multi AZ 특성을 활용한 DR구축에 최적
• Region to Region 에 비해 월등히 저렴한 AZ to AZ 데이터
전송료

23. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Multi AZ와 DR
• Multi AZ는
• 물리적 장애에 대한 지리적 격리를 충분히 만족
• 네트워크또한 분리
• Managed Service는 Multi AZ에 대응: S3, Aurora등
• 지리적으로 분리되어있으나 네트워크 거리는 가까움
• DB의 싱크가 가능할 정도의 가까운 네트워크 거리
• 통상적인 관점의 DR을 만족하면서 마치 하나의 site와
같은 느낌으로 활용 가능한 사이트의 구축가능!

24. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS상에서 DR은 그러면 어떻게 만들까?
• 여러 시나리오들 중에서 순수하게 AWS상에서 구현하는
방법을 살펴보겠습니다.
• AWS상에서는 기본적으로 AZ를 활용합니다.
• Region단위는 latency때문에 더 많은 고려가 필요합니다.
• 이로 인하여 구축하는 시스템의 복잡도가 증가합니다.
• 더불어 데이터 전송 비용이 더욱 증가할수 있습니다.
• AZ단위의 DR구성을 생각하면 구성이 많이 간단해집니다!
• 많은 Managed Service가 이미 AZ의 구분 없이 동작합니다.

25. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
• 단일 지역, 다중 가용영역이 기본
Aurora Volume

26. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
• 단일 지역, 다중 가용영역이 기본
Aurora Volume

27. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
우리가 기대할수 있는 부분
• AZ단위의 outage에 대응
• 특정 영역의 Down상황에 대한 대응
• 특정 ISP의 특정 지역 Outage
• System내의 특정 기능이 실패할 경우
• 서버들의 Failure에 대하여 대응할 시간 확보
• 운영에 있어 효율을 올릴 수 있다

28. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
게임 서비스에서 Multi AZ를!
• 가장 간단한 방법으로, 데이터 베이스를 Aurora를
활용합니다
• MySQL과 100%호환
• Multi AZ에 대응하는 Managed Service
• Read Replica로 Load 분산도 가능 (Main에 부하를 주지
않고)
• 다양한 End point를 제공하기 때문에 Failover등에 대하여
어플리케이션의 수정이 최소화됩니다.

29. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
게임 서비스에서 Multi AZ 대응
• 최대한 AWS Native Service의 활용
• S3, Kinesis, SQS, Lambda, DDB등 대부분의 AWS서비스
• 이들 서비스들은 모두 Multi AZ를 기본으로 포함하여 디자인
되어있다.
• URI가 Region까지만 구분하여 AZ의 상태와 독립적으로 호출/
활용이 가능
• Script기반의 인프라 구성
• 뿐만 아니라 Meta정보를 변수로 받을 수 있도록!
• Region/ AZ정보등을 사용자가 지정할 수 있도록 (비율등)
• Application Cluster에서 데이터까지 액새스가 수 ms의
지연에 대응 할수 있도록 대응 – Caching등의 방법 활용

30. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR to AWS
• 현재 Data Center를 활용하고 있거나, 다른 Cloud
Provider를 사용하는 경우 AWS를 DR Target으로
활용하는 것도 가능합니다.
• How?
• DMS – continuous data replication, SSL end point
• S3 as database backup end point, Binary upload
• VM Import/ Export
• VPN or Direct Connect!
• R53 as entry point
• Remove IP dependancy

31. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS에서 DR을 구현한다면…
• AWS의 특징을 최대한 살립니다.
• Multi AZ in region
• Managed Services with Multi AZ enabled functions
• Very low latency between AZ
• AWS 의 관리형 서비스를 최대 활용
• S3에 데이터의 저장
• AURORA RDB
• DynamoDB
• ELB
• Lambda

32. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Multi AZ를 쓰지 않더라도..
• 수 많은 Managed Service를 사용하면서 Multi AZ의 예택,
또는 DR에 가까운 혜택을 얻을수 있습니다.
• S3
• Aurora
• Aurora with Multi Master
• Dynamo DB
• Dynamo DB Global Table

33. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DR을 넘어서
• 수동적 대응을 고려하는 DR이 아니라 능동적인 활용을
위한 방안
• 단순히 Data를 ＂보존＂만 할 것인가, 아니면 활용을 할
것인가?
• Read only Replica, Cross Region Replica
• Multi Master: Read/ Write nodes
• Global Table…

34. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Global One Build (GOB) 게임의 운영
• 게임은 대단히 개인적인 취향을 반영합니다.
• 지역적 취향도 반영합니다.
• 로컬라이제이션도 무시할수 없는 부분입니다.
• 그럼에도 불구하고 최근의 게임은 글로벌 원빌드를 많이
구현하고 있습니다.

35. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
GOB – 클라이언트
• 클라이언트들은 최근에는 필수 Binary만 앱스토어에서
배포하고 실제 로직의 상당수 (리소스포함) 은 사용자의
상황에 따라 다이나믹하게 전달
• Cloud Front 를 사용
• 데이터 배포의 지역적 안배가 가능
• API 서비스의 Regional선택이 가능해짐
• Cognito를 사용하면 다양한 meta data를 활용한 사용자
identification도 가능!

36. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
서버의 GOB 운영은?
• 지금까지 많은 방법들이 제시되고 운영되고 있습니다.
• 여기에서는 데이터 베이스에서 도움을 줄 수 있는 몇가지
방법을 살펴보겠습니다.
• 물론 게임 자체가 GoB를 지원 할수 있도록 디자인이
되어야 할것입니다.
• 하드코딩된 메타 데이터 없이 분산된 환경에서 동작 가능

37. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DDB Global Table
• DDB글로벌 테이블은 멀티 마스터 복제방식
• 리젼사이는 스트리밍을 통한 상시 동기화
• 충돌은 최종 쓰기 성공에 따라 해소
• 특성등의 상세한 부분은 앞서 다른 세션들에서 확인

38. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
DDB Global Table을 어떻게 사용할까?
• 게임의 키가 되는 계정/ 캐릭터 정보를 GT에 저장
• 어떤 지역에서 접근하더라도 로컬 게임서버에서 플레이
• 디자인에 따라 로컬DB를 액새스
• 하지만 계정/ 캐릭터 정보를 GT로부터 활용
• GT가 Single source of truth로 사용
• 개인 플레이어가 전세계를 돌아다니면서 플레이할까?
• 그것 보다 원월드를 구현하기 위한 시발점
• 지역/사업자 통합등에 훨씬 유연하게 대응이 가능 (계정/
캐릭터명이 고유 Key로 활용 가능)

39. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Aurora Multi Region Multi Master
• Dynamo DB는 Key Value형식의 DB이기 때문에 기존의
많은 게임에서 쉽게 접근하기 어려울수도 있다.
• 하지만 Aurora는 MySQL기반으로 기존의 게임에서 훨씬
쉬운 접근성을 가진다.
• Multi Master의 고성능 활용에 더불어 Multi Region
기능으로 다양한 컨텐트를 사용자에게 제시할 수 있다.

40. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Aurora MRMM
• 가령, 지역별로 구분 되어있는 게임 데이터를 별도의
API를 통하지 않고 마치 로컬 테이블과 같은 느낌으로
액새스가 가능하다면?
• 한국 서버에서 미국 서버에 있는 친구들에게 메시지를
전달. 하지만 인터넷을 통하거나 별도의 통신 서버가
아니라 미국의 게임내 Message Table에 접 insert할수
있다면?
• 아마도 개발 공수가 획기적으로 줄어들 수 있습니다.

41. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Aurora Multi Master
• 멀티 마스터 기능을 활용하여 복잡한 Latency와 관련된
걱정 없이 One World 구현도 가능합니다.
• 하나의 Region에 Aurora Instance를 구축합니다.
• Multi Master를 통하여 Cluster Capacity를 향상시킵니다.
• DB의 복제/ 지연등의 걱정없이 하나의 대형 Cluster에서
SQL을 처리합니다.
• 지금까지 구현하기 어려웠던 초대형 월드 구축
• MM을 통한 High Availability 환경 구축

42. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
Multi Master Demo

43. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
S3
• 원빌드 디플로이에서 빠질수 없는 서비스가 있다면 바로
S3가 될 수 있습니다.
• 오른쪽의 그림은 여러 리젼에 걸친 빌드/ 디플로이를
Lambda와 S3를 통하여 구현하는 도식입니다.
• 이 구조를 Daisy Chain하여 더 많은
Region, 또는 다른 Account로
연결할 수가 있습니다.

44. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
AWS Summit 모바일 앱과 QR코드를
통해 강연 평가 및 설문 조사에 참여해
주시기 바랍니다.
내년 Summit을 만들 여러분의 소중한
의견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사
소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

45. 감사합니다
AWS Gaming Team과의 전문 상담이 필요하다면
aws-gaming-korea@amazon.com