Building Higher Level Functionality For Games Using AWS
Room 3014, West Hall
Speakers : Dhruv Thukral | Gaming Solutions Architect, Amazon Web Services
Greg McConnel | Solutions Architect, Amazon Web Services
Greg Murphy | TBD, Amazon
이번 강연에서는 AWS를 사용하여 얼마나 효율적으로 게임 개발을 할 수 있는지에 대해 소개했습니다.
이러한 것이 가능하게 해주는 2가지 중요 요소는 바로 Lambda와 DynamoDB 입니다.
실제 개발 시뮬레이션을 하기 전에 각각에 대해 살펴보도록 하겠습니다.
먼저 Lambda는 AWS에서 제공하는 Cloud 서비스로, DB 업데이트 / 사용자 입력 / 시스템 상태 변화에 따라 트리거가 동작하여 자동으로 등록된 코드를 실행시켜주는 역할을 합니다.
예를 들어 유저가 아이템을 사는 경우, DB에 구매 로그를 남기도록 서버 구현을 해야만 했습니다. 이러한 경우 Lambda를 적용하면 서버 로직에는 단순히 유저 인벤토리를 업데이트 하는 구현부만 있으면 됩니다. DB가 업데이트 될 때 트리거가 발동하여 구매 로그를 남기는 코드를 Lambda가 실행 시켜 줄 것이기 때문입니다. 이러한 feature 뿐 아니라 시스템 상태에 따른 트리거를 동작하게 하여 서버 인스턴스 관리를 자동화 할 수 있습니다.
이 Lambda와 함께 거의 형제처럼 붙어다니는 DB가 있는데 그것이 바로 DynamoDB 입니다.
DynamoDB는 MongoDB나 Redis와 같은 NoSQL DB로 key-value 형태의 데이터를 디스크 I / O 없이 빠르게 읽고 저장할 수 있습니다. 하지만 단순히 데이터를 메모리에서 관리하는 NoSQL DB의 특성 뿐 아니라, RDB에서 사용하는 index기능을 특정 key값 들을 묶어서 사용 할 수 있다는 것이 가장 큰 매력이 아닐까 합니다. (이것을 Global Secondary Indexes, GSI 라고 합니다.)
이 부분에 대해서도 예를 들면, 여러 앱을 서비스하면서 랭킹 시스템을 구현 해야 하는 상황을 놓고 보면 이해가 쉬울 것 입니다. 전형적인 NoSQL DB를 사용 하는 경우, 유저 ID 하나만을 key로 사용해야 하기 때문에 각각의 앱 별로 테이블을 생성하고 관리해야만 합니다. 하지만 DynamoDB는 하나의 테이블에서 유저 ID와 앱코드를 index로 사용 할 수 있기때문에 하나의 테이블만 관리하면 된다는 이점이 있습니다.
그럼 이제 위의 두가지 핵심 요소 Lambda와 DynamoDB를 사용해 얼마나 효율적으로 게임을 개발 할 수 있는지, 강연에서 얘기한 친구초대 시스템 구현 시뮬레이션을 해보겠습니다.
먼저 친구 초대 시스템의 동작 flow는 다음과 같을 것입니다.
1. 대상에게 요청 (sender)
2. 대상자의 정보 업데이트 (receiver)
3. 대상자의 수락 (receiver)
4. 요청자의 정보 업데이트 (sender)
그리고 DB 테이블의 구조는 name, pending_request, received_request, friends 의 4개 column이면 될 것 같습니다.
이제 동작 flow에 따라 한 스텝씩 진행 해보겠습니다.
A가 B에게 친구 요청을 합니다. 그럼 DB의 데이터가 다음과 같이 업데이트 될 것입니다.
|
name |
pending_request |
recieved_request |
friends |
|
A |
B |
||
|
B |
다음 스텝에서 B의 정보가 업데이트 되어야 하는데, 이 부분에서 Lambda가 사용됩니다.
A 정보의 업데이트로 인해 트리깅 되어 자동으로 B의 데이터를 업데이트 할 수 있게 되는 것입니다.
만약 Lambda를 사용하지 않았다면 서버 로직에 B의 정보를 업데이트하는 코드를 써야 했을 겁니다.
그리고 이때 B의 정보를 선택하기 위해 DynamoDB의 GSI가 사용 되어 부하 없이 동작을 수행하게 됩니다.
그렇다면 Lambda로 인해 B의 정보가 업데이트 되고, 그 결과는 다음과 같이 됩니다.
|
name |
pending_request |
recieved_request |
friends |
|
A |
B |
||
|
B |
A |
그 다음 단계에서 B가 A의 요청을 수락하고, B의 데이터가 업데이트 됩니다.
|
name |
pending_request |
recieved_request |
friends |
|
A |
B |
||
|
B |
A |
A |
또 Lambda에 의해 A의 정보도 자동으로 업데이트 될 것이고 최종 적으로 이렇게 업데이트 될 것입니다.
|
name |
pending_request |
recieved_request |
friends |
|
A |
B |
B |
|
|
B |
A |
A |
전체적인 flow는 총 4단계이지만, 실제 서버 사이드 구현은 2단계로 마무리가 될 수 있게 되었습니다.
현재 사내에서 꾸준히 개발하고 있는 PV의 친구 관리 시스템도 총 4단계의 로직으로 구현 되어 있는데, Lambda와 DynamoDB를 적용한다면 지금 보다 훨씬 좋은 성능을 발휘하면서 효율적으로 개발을 완료 할 수 있지 않을까 기대하게 만드는 강연이었습니다.
by Justin Hwang