게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018

다양한 DB 를 써보자!
Various DB services at your hand!
Gaming on AWS 2018

Let’s play with your DB
Copyright 2018, Amazon Web Services, All Rights Reserved Page 2
Table of Contents
Overview of this HoL..................................................................................................................4
Hands on Lab 0: 준비 운동을 합니다. .....................................................................................4
Hands on Lab 1: 우리 게임은 MySQL 을 써요 (또는 MariaDB)...............................................7
Hands on Lab 2: DDB 를 사용해보자....................................................................................18
Hands on Lab 3: 분석에 대하여 ............................................................................................36
HoL Material by
Version 1.0 Sungsoo Khim 2018 July

Download the asset and codes for hands-on-lab exercise
https://bit.ly/2PqmE6s

Overview of this HoL
Hands on Lab 0: 준비 운동을 합니다.
이 HoL 들은 데이터를 움직일 필요가 있기 때문에 모두 AWS 상의 EC2 인스턴스 위에서
실행하도록 하겠습니다. 이를 위하여 아래를 참고하여 Control Host 를 만들어주시기
바랍니다.
(상세한 Step by Step 은 이 세션의 Level 을 고려하여 생략합니다.)
1. Amazon Linux 2 를 사용하여 t2/t3.medium 급의 인스턴스를 시작합니다.
2. 스토리지 크기는 50GB 로 확인합니다.
3. Security Group 은 인스턴스를 만들때 생성될 SSH 를 위한 22 번 포트를 열어주는
Group 과 VPC default 를 함께 할당해줍니다. (복수개의 VPC 를 할당합니다.)
4. 생성이 되면 할당된 Public DNS/IP 로 로그인을 확인합니다.
5. 로그인 이후 wget https://bit.ly/2PqmE6s 를 실행하여 HoL 리소스를 다운받습니다. 이
파일안에 기본 데이터 및 Script 들이 들어있기 때문에 이를 활용하여 아래의 HoL 을
진행하게 됩니다.
인스턴스와 함께 Script 에서 활용할 각종 IAM 사용자들을 확보합니다.
1. 콘솔에서 IAM 페이지를 열어줍니다.

2. “사용자추가” 버튼을 누르고 사용자 이름을 지정하고 액세스 유형을 프로그래밍 방식
액세스로 설정합니다.
3. 이 데모에서 필요로 하는 권한이 현재 다양하기 때문에 기존 정책 직접 연결을
선택해줍니다.
4. 우선 S3 에 대한 권한으로 AmazonS3FullAccess 를 부여합니다.

5. 사용자를 만들면 액새스키 ID 와 비밀 액새스키가 표시됩니다. 이 페이지를 벗어나면
비밀 액세스키를 확인할수 없기 때문에 반드시 다른 안전한 곳에 보관하시길 바랍니다.
6. 만일 이 사용자의 비밀 액세스 키 (Secret Access Key)를 분실했을 경우 위와 같은
방법으로 다시 만들어서 사용하면 됩니다.

이 HoL 을 진행하면서 사용할 S3 버킷을 만들어줍니다.
콘솔에서 간단히 필요한 버킷의 이름을 지정하고 적절한 지역에 만들어주면 됩니다.
리젼사이에 데이터 이동 비용을 고려하여 EC2 인스턴스가 있는 미국 서부 (오레곤)에
만들어주시면 됩니다. 모든 것은 기본 설정으로 만드시면 됩니다.
버킷 이름은 DNS 이름처럼 사용자별로 중복될수 없기 때문에 타인과 중복되지 않을 본인만의
이름을 사용하시면 됩니다.
이제 기본적인 준비가 완료되었으므로 본격적으로 시작하도록 하겠습니다
Hands on Lab 1: 우리 게임은 MySQL 을 써요 (또는 MariaDB)

AWS 상에서 MySQL, 또는 비슷한 RDBMS 를 사용하는 방법은 여러가지가 있습니다. (사실
다양한 DB 시스템을 사용하는 방법을 가지고 있기도 하지요.) 게임에서 사용하는
DB 시스템으로는 여러가지 선택이 가능합니다만, MySQL 도 여러 선택중에서 인기가 많은
방법의 하나입니다. Open Soure 이면서 (네, 이 부분은 여러 논쟁이 가능하겠습니다만)
사용자층이 두텁고 성능이나 기능적으로 상당부분 검증된 DB 엔진이기도 하죠.
이번 Lab 에서는 다양한 조합중에서 MySQL 을 활용하는 방법과 서로의 차이점을 살펴보도록
하겠습니다.
대표적으로 MySQL 을 사용하는 방법이라면 EC2 위에 직접 MySQL 을 설치하여 활용하는
방법이 있습니다. 그리고 추가적으로 RDS MySQL 을 활용하는 방법, 그리고 마지막으로
Aurora 를 사용하는 방법이 있습니다.
그러면 이번 HoL 에서는 EC2 상에서 MySQL 을 설치하여 운영하는 방법부터 살펴보도록
하겠습니다.
EC2 위에서 MySQL 설치하기
1. HoL 을 위해서 t2.medium 크기의 인스턴스를 사용합니다. 우선 Console 을 통하여
t2.medium 크기의 인스턴스를 생성합니다. 기본적인 설정은 그대로 가져가고 다만
Storage 의 크기만 50GB 로 생성합니다.

2. 네트워크 설정은 Public IP 를 부여하지 않도록 해줍니다. Security Group(보안그룹)은
VPC default 와 22 번을 허용 할수 있도록 만들어줍니다. 3306 에 대한 Allow 는 별도로
구성하지 않습니다. (VPC default 에서 허용됨)
(*) 만일 Linux 에서 호스트 생성, SSH 키와 관련된 사항에 대하여 기존 경험이 없으시다면
현장의 다른 SA 들의 도움을 받으시길 바랍니다.
3. 호스트 생성이 완료되면 ssh 로그인을 해줍니다.
4. 아마존 리눅스의 인스턴스이므로 기본 yum repo 를 통하여 mysql 을 설치할 수
있습니다. 아래의 command 를 활용하여 mysql 과 관련 툴들을 설치해줍니다.
# sudo yum update -y (경우에 따라 재부팅이 필요할수 있습니다.)
# sudo yum install -y mariadb-server
5. MySQL 의 설치가 완료되면 아래와 같이 MySQL 프로세스를 시작합니다.
# sudo systemctl start mariadb
6. MySQL 프로세스가 시작되면 설치된 MySQL 서버의 보안 설정을 확인합니다.
# sudo mysql_secure_installation

7. 정상적으로 구성이 완료되면 아래와 같이 서비스 등록을 해줍니다.
# sudo systemctl enable mariadb
8. DB 에 어드민 사용자를 추가해줍니다. Root 사용자 사용이 권장되지 않기 때문에
아래와 같은 형태로 dbholuser 사용자를 추가해줍니다.
mysql --user=root -p mysql -e "
CREATE USER 'dbholuser'@'%' IDENTIFIED BY 'some_pass';
GRANT ALL PRIVILEGES ON *.* TO 'dbholuser'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;"
9. 서비스가 정상적으로 돌아가고 있으므로 이제 준비된 data 를 import 하도록 합니다.
빠른 Import 를 위하여 DB 서버에 로그인하여 새로운 DB 와 테이블 스키마를
생성해줍니다.
create database maindb;
use maindb;
CREATE TABLE `PlayLog` (
ìdx` bigint(20) NOT NULL AUTO_INCREMENT,
`pidx` bigint(20) NOT NULL,
`createdate` datetime DEFAULT CURRENT_TIMESTAMP,
àction` int(11) DEFAULT NULL,
`posoldx` bigint(20) DEFAULT NULL,
`posoldy` bigint(20) DEFAULT NULL,
`posoldz` bigint(20) DEFAULT NULL,
`posnewx` bigint(20) DEFAULT NULL,
`posnewy` bigint(20) DEFAULT NULL,
`posnewz` bigint(20) DEFAULT NULL,
PRIMARY KEY (ìdx`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1
10. Control Host 의 DBHoL/HoL1 폴더에 보면 S3 에서 다운로드한 데이터를 Import 하는
importEC2.sh 라는 스크립트가 있습니다. 이를 실행하여 데이터들을 import 하도록
하겠습니다. 스크립트를 실행하기 위해서 mariadb 의 private ip 주소를 환경변수로
지정합니다.

# export MARIA_IP=172.31.33.65 이 주소는 실제 사용하는 DNS 주소, 또는 private ip 를 쓰셔야합니다.
11. 스크립트를 실행하면 Import 구문이 실행됩니다. 다만 파일 마다 한번씩 password 를
입력해야하기 때문에 불편할 수는 있습니다. 이 경우 importEC2_pwd.sh 를 사용하면
됩니다. 이 스크립트는 위 사용자 패스워드를 환경변수로 받아서 전달하는 방식이기
때문에 안전에 주의해주셔야합니다. 스크립트 실행이 완료되면 아래의 환경변수를
없애주시기 바랍니다.
# export MARIA_PWD=[some password]
12. Data Import 가 완료되면 아래의 Query 를 실행해보도록 하겠습니다. Table 의 크기가
크고 복합 쿼리인 관계로 상당한 시간이 소모되는 것을 볼수 있었습니다.
select year(createdate), month(createdate), day(createdate), hour(createdate), count(*) from
PlayLog group by year(createdate), month(createdate), day(createdate), hour(createdate);
상당히 중요한 데이터 베이스라고 보면 이러한 데이터를 효과적으로 활요할 수 있는 방법에
대하여 고민을 안할 수가 없습니다. 게임 서버 쪽에서는 안정적으로 데이터를 삽입해야하고
실제 쿼리를 실행하여 활용하는 쪽에 대한 고려, 또한 failure 에 대응하는 대책을 가지는 것이
중요할 것입니다.
그렇다면 이러한 수요 – Redundancy, read replia 를 손쉽게 활용할 수 있는 방법은 무엇이
있을까요? Log shipping 을 이용하여 replication 을 구성하는 것은 상상만해도 끔찍한 운영
부담으로 다가옵니다.
RDS 서비스를 사용하기
만일 우리가 Resilience 나 redundancy 를 고려한다면 RDS 옵션을 사용하는 것이 정답입니다.
Managed Serice 로 복제본의 설정 및 관리의 부담을 지워주기 때문입니다. 이 경우
사용가능한 옵션은 RDS MySQL/ MariaDB/ Aurora MySQL 이 있습니다. 이중에서 이번

HoL 에서는 Aurora 옵션을 선택하도록 하겠습니다. 일반 RDS 에 비하여 Aurora 는
replication 에 대한 부담이 적고, 그리고 read replica 의 운영이 훨씬 효율적이기 때문입니다.
1. RDS 콘솔을 통하여 Aurora RDS 를 생성해줍니다. 이번에도 앞서 EC2 에서 사용했던
t2.medium 크기로 생성하도록 하겠습니다. 에디션은 5.7 로 진행합니다.
2. 생성옵션들은 아래와 같이 Multi AZ 를 활성화하여 구성하도록 합니다. 인스턴스 크기,
인스턴스 식별자, 마스터 사용자 이름 그리고 패스워드를 기록하도록합니다.

3. 퍼블릭 주소로 접근할 필요가 없기 때문에 아래 사진과 같이 옵션을 수정하고 생성을
시작합니다. 나머지 항목중에서는 VPC default 보안그룹을 추가하는 정도로 구성이
완료됩니다.

4. Aurora 클러스터의 구성이 완료되면 Writer Endpoint 를 통하여 R/W 작업을 진행하게
됩니다. 만일 Read Replica 의 활용이 필요할 경우 Reader Endpoint 를 사용하면
됩니다.

5. 디비의 생성에 다소 시간이 걸릴수 있습니다.
6. 생성이 완료되면 클러스터 메뉴를 통하여 클러스터 정보를 확인합니다.

7. 클러스터의 세부 정보를 확인하여 Aurora 의 End Point 를 기록합니다.
8. 최초에 만들었던 Management Host 에 로그인하여 사용에 필요한 DB 와 테이블
정보를 생성하도록 하겠습니다. (만일 접속이 안되면 보안그룹에 VPC 기본 보안그룹이
추가 되어있는지 확인하시면 됩니다.)

9. 앞서 예제에서 수행했던것과 같이 아래의 쿼리를 실행해줍니다.
create database maindb;
use maindb;
CREATE TABLE `PlayLog` (
ìdx` bigint(20) NOT NULL AUTO_INCREMENT,
`pidx` bigint(20) NOT NULL,
`createdate` datetime DEFAULT CURRENT_TIMESTAMP,
àction` int(11) DEFAULT NULL,
`posoldx` bigint(20) DEFAULT NULL,
`posoldy` bigint(20) DEFAULT NULL,
`posoldz` bigint(20) DEFAULT NULL,
`posnewx` bigint(20) DEFAULT NULL,
`posnewy` bigint(20) DEFAULT NULL,
`posnewz` bigint(20) DEFAULT NULL,
PRIMARY KEY (ìdx`)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1
10. DB 와 스키마가 완셩되면 DBHoL/HoL1 디렉토리안의 importAurora.sh 스크립트를
실행합니다. 이번에는 아래와 같이 환경변수를 정의하여 실행합니다.
# export AURORA_HOST = [클러스터엔드포인트]
# export AURORA_USER = [위에서 생성한 오로라 사용자]
# export AURORA_PASS = [위에서 생성한 오로라 패스워드]
11. 실행되는 동안 Data 가 Import 되는 것을 볼수 있습니다.
12. Data Import 가 완료되면 앞서 실행했던 SQL 을 실행해줍니다. 아까와 같은 복합
쿼리가 실행되는 모습을 확인할 수 있습니다.
13. 단일 쿼리의 실행 속도는 일반 EC2 에 연결할때와 큰 차이가 없을수 있습니다만, 많은
수의 쿼리를 실행요청을 할 경우, 오로라가 큰 잇점을 가질수가 있습니다.
14. 생성된 두개의 동일한 데이터셋을 가지고 있는 EC2 의 DB 와 AURORA 의 차이를 직접
데이터를 쿼리하면서 살펴보시기 바랍니다.
Hands on Lab 2: DDB 를 사용해보자.
앞서 우리는 RDBMS 를 사용하는 방법들을 고민해보았습니다. 지금까지 많은 게임들이
MySQL 이나 MSSQL 과 같은 RDBMS 를 활용했다면, 몇년 전부터 RDBMS 가 아닌 다른
솔루션을 사용하는 경우가 늘어나고 있습니다.
가장 많이 사용하는 대안으로 NoSQL 계열이 있을 것입니다. 최근에는 NoSQL 과 SQL 의
경계가 일부 흐려지고 있지만 기본적으로 key -> value 형태로 데이터를 관리하는 NoSQL 은
많은 게임상에서 다양한 장점을 가져다 줄 수가 있습니다. 다양한 NoSQL 의 솔루션이
있습니다만, Fully Managed 형태로 사용할 수 있는 DynamoDB 를 사용하는 방법과 특징을
살펴보도록 하겠습니다.

그러면 실험을 위하여 DDB 의 Console 에서 DDB 를 생성해보도록 하겠습니다.
1. AWS Console 에서 DDB 를 선택하여 열어줍니다.
2. DDB 는 완전한 Managed Service 이기 때문에 리소스의 수량에 대한 직접적인 결정을
할 필요가 없습니다. 물론 사용량을 예측 할 수 있으면 사전에 필요한 Read/ Write
용량을 지정할 수 있습니다.
3. DDB 테이블은 기존의 RDB 에서 DB 와 Table 을 만드는 과정과는 달리 기본적으로
Table 의 이름과 Key 값을 정하는 것으로 끝납니다.
4. 그외의 다른 요소들은 부차적인 값으로, 이는 DDB 가 가지는 Key Value 기반의
시스템이라는 특성에서 기인합니다.
5. 단지 테이블 이름과 기본 키를 지정하는 것으로 생성의 과정이 완료됩니다. 완료되면
즉시 사용을 할수가 있게 됩니다.
6. 만들어진 DDB Table 을 살펴보시면 단순히 Primary Key 만 정의되어있고 우리가 흔히
Schema 라고 부르는 테이블의 개별 컬럼이 없는 것을 볼수 있습니다. 이러한 영역, 즉

Key Value 에서 Key 만 최초에 정의되고 사용하면서 Value 라는 영역을 추가하고
사용하게 되는 것입니다.
7. Console 을 통하여 새로운 Key Value pair 를 추가하도록 하겠습니다. 아래의 그림에서
처럼 items 텝에서 Create item 버튼을 눌러줍니다.
8. 화면에 새로운 편집창이 나오는데 여기에서 여러 데이터를 추가해줄 수가 있습니다.
창에 보면 앞에서 정해준 Primary Key 가 존재하는 것을 볼수 있습니다. 이 항목은 필수
항목이기 때문에 존재하는 것이며 여기에 다른 Value 항목에 들어가는 데이터 구조를
추가하여 삽입할 수 있게 되는 것입니다.
9. 여기에서는 아래와 같은 형태의 데이터를 추가하도록 하겠습니다.
10. 다시, 아래와 같이 데이터를 추가해줍니다.

11. Items 텝에서 확인하면 위에서 만들어준 데이터 열이 2 개가 보입니다.
12. 이번에는 다시금 아래와 같이 데이터를 넣어줍니다. 앞서 만들어줬던 데이터와
비교하면 primary key 값이 같고 뒤의 추가 항목이 다릅니다.

13. Save 버튼을 누르는 순간 오류가 나타나는 것을 볼 수 있습니다. 이는 Primary 키가
고유값이 되어야하는데 신규 항목 생성을 기존의 Primary Key 와 같은 이름으로 시도
하였기 때문에 발생하는 문제입니다. 따라서 실제 사용할때는 Primary Key 가 중복하여
입력되지 않도록 관리하는 필요가 있습니다.
14. 지금까지 입력된 데이터를 보면 모두 동일한 컬럼 구조를 가지고 있는 것을 볼수
있습니다. 그렇다면 고정된 Schema 가 존재하는 것처럼 보일수 있습니다만, 아래와
같은 형태로 새로운 데이터를 입력해봅니다.

15. 이번에 입력한 데이터는 앞서 입력한 데이터와 다른 field 값을 가지고 있습니다. 이렇게
입력해서 Save 를 눌러줍니다.
16. 이번에 Items 텝에서 보면 컬럼이 늘어나있는 것을 보실수 있습니다.
17. 이와 같이 기존의 데이터들에 대하여 별도의 컬럼에 대한 처리를 하지 않아도되는 것을
볼수 있습니다. 기존의 RDBMS 에서는 테이블의 형태를 바꾸는 경우 Alter Table 과
같은 형태로 컬럼데이터 형태를 수정해야하고 그 과정에 시간이 많이 걸리는것에 반해
DynamoDB 에서는 Key->Value 의 형태에 대한 약속만 지키진다면 사용하고자 하는
어떤 조합도 대응 할 수가 있습니다. 다만 같은 이름의 컬럼은 모두 동일한 Data
Type 을 유지하도록 주의하시기 바랍니다.
하지만 이렇게 Key Value 의 형태로 데이터를 쌓다보면 조건에 맞는 쿼리를 실행해야하는
필요가 생기게 됩니다. 특히 DynamoDB 의 특성상 수백만에서 수억건의 데이터를 가지게
되고, 이 데이터들에 대하여 쉽게 Key->Value 를 언제나 파악 할수 없는 경우가 많습니다.

이러한 경우 우리는 GSI 라는 인덱스 테이블을 활용하여 그 문제를 해결하게 됩니다. GSI 는
DynamoDB 의 중요 기능의 하나로 기존의 데이블의 데이터를 바탕으로 새로운 조건에 맞춰
재정렬한 새로운 테이블입니다. 이 과정에서 기존의 데이블에서 필요한 조건과 속성들만을
추려서 만들게 되기 때문에 기존의 테이블보다 작게 유지하거나 관련 조건 쿼리를 빠르게
수행 할수 있는 환경을 마련해줍니다.
1. GSI, Global Secondary Index 를 만들기 위해서는 Indexes 텝에서 Create index 버튼을
눌러서 시작할 수 있습니다.
2. 그림과 같이 GSI 에서 사용하고자 하는 새로운 Primary Key 조합을 만들어주면 됩니다.
(원 테이블의 Primary 키는 무조건 따라갑니다. 따라서 이것을 포함하는 Index 를 만들
수도 있습니다.) 테이블 컬럼이 여러개가 있다면 GSI 에 포함하고자 하는 column 만
추가하는 것도 가능합니다.

3. 생성을 시작하면 Table 을 생성하는 것과 같이 약간의 시간이 지나면 Index 가
생성됩니다.

4. 다시 Items 텝에서 보면 간단하게 테이블에 대하여 Scan, 또는 Query 를 수행 할 수가
있습니다.
5. Scan 을 통해서 보면 Main Table 에 비해서 일부의 항목만 들어있는 것을 볼 수
있습니다.
6. GSI 의 활용은 일반 DDB 테이블에 비해서 기대 밖의 행동을 보이는 것처럼 생각될 수도
있기 때문에 어느정도 기본 테이블에서 여러 행동 형태를 인지하고 접근 하는 것을
추천드립니다.
DDB 의 기본적인 특성을 살펴보았기 때문에 이제 실제 많은 데이터가 들어있는
DDB 테이블에 대하여 어떤 특색을 가지는지를 살펴보도록 하겠습니다. 실제로 DDB 에 많은
데이터를 넣고, 액새스하는데는 많은 비용과 시간이 걸리므로 이번 HoL 에서는 이미 준비된
DDB 테이블을 액새스해보도록 하겠습니다. 이를 통하여 실제 어플리케이션들에서 DDB 의
특성을 어떻게 활용할 수 있는지를 살펴보도록 하겠습니다.

1. 앞서 준비한 Control Host 에서 DBHoL/HoL2 디렉토리로 들어가시기 바랍니다.
2. 여기에서 첫번째 Script, simplecall.sh 를 실행해보도록 하겠습니다. 이 스크립트는
반복적으로 임의의 Key 를 단순 호출하는 스크립트입니다. Table 의 크기는 약 10 만
row 가량이 됩니다.
3. HoL 에 있는 여러분들이 동시에 Access 하고 있기 때문에 실제로 부여되는 Load 는
상당히 높은 상태입니다.
우리는 여기에서 DDB 가 가지는 일관된 성능을 확인할 수 있습니다. 하지만 개별 read 는 모두
비용이고 DDB 까지의 Latency 는 어떻게 하더라도 유지되는 사실에는 변함이 없습니다.
여기에서 유사한 데이터에 대한 read request 가 많다면 어떨까요?
보통 DB 를 구축할때 우리는 DB 에 쿼리를 직접하여 최신의 데이터를 가져오는 것을 기본으로
삼지만, 쿼리마다 변하지 않은 질의에 대해서는 Cache 를 통하여 DB 에 불필요한 부하를
줄이거나, DB 커넥션에 대한 비용을 최소화하는 방법을 강구하기도 합니다. 직접 redis 를
사용하여 구현할 경우 데이터 정합성에 대한 많은 고민을 피할 수 없었습니다만, Dynamo
DB 는 DAX – Amazon Dynamo DB Accelerator 를 활용하여 이러한 고민을 한번에 해결할 수
있는 솔루션을 제공하고 있습니다. (현재 서울 리젼에는 서비스 개시를 위하여 노력중입니다.
하지만 일본, 미국내의 리젼들에서 당장 활용 하실 수 있습니다.)
DAX 의 사용 방법은 기존의 DDB 와 다르지 않기 때문에 거의 Drop In Replacement 로
생각하셔도 좋습니다.
1. 앞서 HoL2 폴더에 보면 daxcall.sh 라는 스크립트가 있습니다. 이 스크립트는
DDB 포인터가 아니라 DAX 포인터로 수정한 것을 볼 수 있습니다. 기본적으로 응답
속도가 현저히 낮아지는 것을 볼 수 있습니다.

2. 다시, 먼저번 스크립트와 실행을 비교해보면 속도차이를 볼수 있습니다.
DAX 는 일반적인 데이터의 액새스에 대한 응답속도를 “평균적”으로 낮출 수 있는 훌륭한 도구
입니다. 하지만 모든 데이터 입출력에 대하여 공통적으로 응답속도를 향상시키는 것을 아니고
일반적인 캐쉬의 역할과 마찬가지로 이미 Cache 안에 들어있는 데이터에 대한 응답 속도를
획기적으로 향상시킨다는 것을 의미합니다. 따라서 어플리케이션의 디자인에서는 기본적인
DDB 의 응답속도를 기반으로 삼고, DAX 를 통하여 향상된 성능을 즐긴다는 관점으로
보셔야합니다.
DAX 의 읽기는 read through 형태입니다. 데이터가 요청되어야 Cache 에 들어가는 형태가
됩니다. 즉 최초의 Read 는 언제나 DDB 에서 직접 읽는 수준이 됩니다. DAX 의 쓰기는
비슷하게 write through 형태입니다. 즉, DAX 에 쓰기를 할때 DAX 가 그것을 받고, DDB 를
업데이트한뒤, 로컬 Cache 를 갱신하고 완료 신호를 전달하는 형태가 됩니다.
DAX 의 구성 및 구체적인 활용에 대해서는 여러분의 AM, 또는 담당 SA 들에게 문의하시면
실습을 포함한 다양한 도움을 받으실 수 있습니다.
DynamoDB 의 또 다른 빼놓을 수 없는 기능으로 Global Table 을 들 수 있습니다. Global
Table 은 한 지역에서 생성된 Table 의 내용이 다른 Region 에 그대로 복제되고 양방향으로
sync 가 이루어지는 기능을 가지고 있습니다. Global One Build + Multi Deploy 를 생각해보면
유용하게 사용할 수 있는 가능성을 생각해볼 수 있습니다. (특성과 제약에 대해서는
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_reqs_b
estpractices.html#globaltables_requirements 를 참고하시기 바랍니다.)

1. 앞서 직접 생성한 Dynamo DB Table 의 콘솔로 들어가서 Global Table 로 만들어줄
새로운 테이블을 새롭게 생성합니다. Global Table 을 생성하기 위해서는 비어있는
테이블을 사용해야하기 때문입니다.
2. 테이블 생성이 완료되면 만들어준 테이블의 Global Tables 텝을 열여줍니다.
3. 텝 안에서 streams 를 활성화 시켜줍니다. Global table 은 이 Stream 을 통하여
데이터를 이동하게 됩니다.
4. 복수개의 region 사이에서 복제를 지원하기 때문에 서비스의 근간이 되는 데이터를
보존하거나 일관성이 중요시되는 데이터의 변경을 Global table 을 통하여 관리하면
효율적인 스텍 구성이 편리해 질수 있습니다. 예를 들어 Master Account Table, 또는
서버 role 설정 데이터, 또는 Item 특성 마스터 테이블등을 이러한 방법으로 서비스의
locality 를 유지하면서 관리의 편의성을 높일 수가 있을 것입니다.
5. Stream 이 활성화가 완료되면 Add region 버튼을 눌러서 어느 지역에 이 Global
Table 을 만들지를 선택합니다. (아무거나 선택하셔도 되지만 이 HoL 에서는 서울을
선택해보겠습니다.)

6. 선택된 Region 에 테이블이 생성이 준비됩니다. 잠시 기다리면 생성이 완료되고 사용이
가능해집니다.

7. 브라우저에서 새로운 콘솔을 열어줍니다. 이번에는 아까 생성을 원했던 region 의
DynamoDB 를 열어줍니다.
8. 양쪽에 각각의 다른 region 의 콘솔을 가지고 한쪽에 데이터를 삽입해보도록
하겠습니다. Oregon 의 콘솔을 A, 서울의 콘솔을 B 콘솔이라고 부르겠습니다.

9. A 콘솔에서 임의의 데이터를 아래와 같이 입력해줍니다.
10. A 콘솔에는 입력된 데이터가 나타나는 것을 확인합니다.
11. 이제 B 콘솔을 확인합니다. A 콘솔에서 추가한 데이터가 첫번째 줄에 나오는 것을 볼 수
있습니다. 추가적인 origin 에 대한 데이터가 들어있는 것을 볼수 있습니다.

12. 이어서 B 콘솔에서 다른 데이터를 추가해줍니다.
13. B 콘솔에서 저장을 하면 B 콘솔에 2 개의 데이터가 표시 되는 것을 볼 수 있습니다.

14. A 콘솔로 돌아가서 Item 텝을 refresh 해주거나 Start search 버튼을 눌러주면
B 콘솔에서 추가한 데이터가 보이는 것을 확인 할 수 있습니다.

Global Table 은 상호 업데이트가 가능합니다. 그리고 self managed 특성을 가지고 있습니다.
그리고 DDB/NoSQL 의 기본적인 특성을 그대로 상속하기 때문에 이러한 특성을 고려하여
여러분의 서비스에서 활용하는 것을 시작해보시기 바랍니다!

Hands on Lab 3: 분석에 대하여
어떠한 서비스/ 어플리케이션을 운영하더라도, 사용자로부터 우리는 많은 데이터를 받게
됩니다. 단순한 로그부터 운영에 필요한 중요 입력/ 행동등에 대한 다양한 데이터를 수집하게
됩니다.
데이터의 양이 많지 않으면 이의 분석에 많은 노력을 들일 필요/ 수요는 없을 것입니다.
하지만 지금 우리는 쉽게 수 GB 에서 수 TB 어치의 데이터가 생성되는 시대를 살고 있습니다.
이 상황에서 이렇게 많은 데이터를 손쉽게 처리하고 운영해야하는 필요가 있습니다.
기존에는 Data Warehouse 를 만들고 운영하는 입장을 가지고 있었습니다. 하지만 지금
상황에서 기존의 Data Warehouse 가 가지는 장단점에 대해서 다시금 생각해야할 정도로
데이터의 크기가 상상을 초월하는 상황에 다다르게 되었습니다. 데이터의 속성의 추가/ 변경/
쌓이는 속도는 기존의 DW 의 설계 방식으로 쉽게 따라오기 버거울 정도가 되었으며
전/후처리의 부담은 살인적이 되었다고 할수도 있습니다. 이러한 환경에서 AWS 의 여러가지
Managed Service 를 통한 방법들을 살펴보도록 하겠습니다.
RedShift 는 AWS 에서 제공하는 Data Warehouse 솔루션입니다. 기존의 DW 와 유사한 사용
경험을 제공하면서 RedShift 만의 다양한 특성을 녹여서 현재 사용하는 DW 솔루션에서의
부드러운 이전을 지원하면서, 또한 AWS 만의 다양한 특성을 녹여낼수 있든 장점을 가지고
있습니다.
RedShift 를 통하여 소형 Data Warehouse 를 만들어보도록 하겠습니다.

1. RedShift 콘솔을 통하여 작은 RedShift 클러스터를 만들어줍니다. 콘솔에서 “빠른 시작
클러스터” 를 선택해줍니다.
2. 화면에 클러스터의 상세 설정을 구성하는 부분에서 그림과 같이 설정을 조절해줍니다.
노드 유형은 dc2.large, 노드 수는 1 개, 식별자는 기억하기 좋은 식별자를
선택해줍니다. 마스터 암호는 대소문자와 숫자가 섞인 암호를 사용하고 “클러스터시작”
버튼을 눌러줍니다.
3. 이 클러스터가 만들지는데 약 5 분 가량 시간이 걸릴 것입니다.

4. 클러스터가 만들어지면 현재 사용자가 Full Administrator 권한을 가지고 있지 않을
경우 사용자에게 위 화면에서 보는 가이드에 따라 아래의 권한을 부여해주시기
바랍니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"redshift:CancelQuery",
"redshift:CreateSavedQuery",
"redshift:DeleteSavedQueries",
"redshift:DescribeClusters",
"redshift:DescribeQuery",
"redshift:DescribeSavedQueries",

"redshift:DescribeTable",
"redshift:ExecuteQuery",
"redshift:FetchResults",
"redshift:GetClusterCredentials",
"redshift:ListDatabases",
"redshift:ListSchemas",
"redshift:ListTables",
"redshift:ModifySavedQuery",
"redshift:ViewQueriesFromConsole"
],
"Resource": "*"
}
]
}
5. 클러스터가 생성되는 동안 클러스터 텝에서는 현재 생성 상황을 보여줍니다. 클러스터
상태가 “생성중”에서 “사용 가능”으로 바뀔때가지 기다려줍니다. (커피 한잔을 하고 올
좋은 기회일 것입니다.)
6. 클러스터가 완성되면 콘솔에 있는 Query Editor 텝을 열어주시기 바랍니다. 여기에서
방금 만들어준 RedShift 클러스터로 접속을 해줍니다. 사용 방법 자체는 일반적인
DB 관리툴과 크게 다르지 않을 것입니다. 클러스터가 완성되지 않은 상태에서는 Query
Editor 텝이 열리지 않습니다.

7. 처음 연결하는 경우에는 클러스터의 이름, 그리고 위에서 구성한 사용자 이름과
패스워드를 넣어주면 연결이 됩니다.
8. 우선은 간단하게 테이블을 하나 만들어보겠습니다. Schema 는 Public 으로 변경하고
오른쪽의 빈창에 table 생성 SQL 을 입력해줍니다.

9. 쿼리창에서 간단히 Create Table 구문을 실행합니다. SQL 구문은 간단하게 아래와
같습니다.
create table Hello (idx bigint, body varchar(255));
10. 생성된 테이블이 비어있는 것을 확인할 수 있습니다.이번에는 Insert 구문을
실행합니다. 사용된 insert 구문은 아래와 같습니다.
insert into Hello (idx, body) values (1, 'Hello'), (2, 'World');

11. Insert 구분이 실행되면 이번에는 select 를 실행해주면 앞서 만들어준 테이블에
데이터가 들어가 있는 모습을 확인할 수 있습니다.

통상적인 overview 에 관련한 작업은 이렇게 web console 을 통하여 충분히 진행 할수 있기
때문에 간단한 lookup 등은 Web Tool 을 통하여 진행하면 됩니다.
12. 다시 Query Editor 에서 클러스터의 public Schema 를 열어보면 안에 들어있는 테이블
리스트를 볼수 있습니다. 위에서 만들어준 테이블을 열어보면 안의 각각의 컬럼들에
대한 타입 정보등을 살펴볼 수가 있습니다.

13. 웹 Query Editor 또한 일반적으로 사용하는 여러 툴들의 일반적인 기능들을 많이 따라
제작되었기 때문에 실제 업무에서 활용하는데 큰 지장은 없을 것입니다. 아래
그림에서처럼 ctrl-space 를 이용한 자동완성을 사용할수도 있기 때문에 생각보다
편리하게 활용할수 있습니다.
RedShift 에서는 이와 더불어 RedShift Spectrum 을 통하여 Cluster 에 직접 적재되지 않은
다량의 데이터에 대해서도 쿼리를 진행할 수가 있습니다. 이를 통하여 잦은 분석 쿼리가
필요한 데이터는 RedShift 의 클러스터에 직접 저장하여 빠른 활용을, 그렇지 않은 대량의
데이터에 대해서는 S3 에 적재된 상태에서 쿼리를 통하여 운영비용을 아낄수가 있습니다. 즉,

직접 클러스터에 적재된 것보다는 다소 느리지만, 훨씬 저렴하게 큰 데이터를 만질 수가 있게
되는 것입니다. 즉, 필요한 만큼만 사용한다는 AWS 의 사용 정신에도 부합할 것입니다.
먼저, RedShift Spectrum 을 사용하기 위해서 준비된 데이터들을 S3 로 업로드하도록
하겠습니다.
1. 먼저 사용되었던 Control Host 의 DBHoL/rawdata 폴더로 이동합니다.
2. 여기에 준비되어있는 2.4GB 의 데이터를 여러분이 준비하신 S3 버킷으로 업로드를
합니다.
3. 사용하는 커맨드는 아래와 같습니다.
export AWS_ACCESS_KEY_ID=[위에서 만든 본인의 ACCESS_KEY_ID]
export AWS_SECRET_ACCESS_KEY=[위에서 만든 본인의 Secret Access Key]
export AWS_DEFAULT_REGION=us-west-2
aws s3 sync . s3://[생성한 버킷의 이름]/playlog
4. 버킷 이름은 이름만 들어가는 것은 나머지 지역정보등은 aws cli 가 채워주기 때문에
짧은 이름으로 충분합니다.
5. 만들어둔 버킷에 미리 폴더를 만들어둘 필요는 없으며 업로드가 완료되면 S3 콘솔을
통하여 업로드가 된것을 볼수 있습니다. (만일 보이지 않을 경우 브라우저창을
reload 하면 보입니다.)

6. 폴더의 내부에 20 개의 파일이 업로드 된 것을 볼수 있습니다.
7. 이제 RedShift 가 위 S3 를 읽을수 있도록 IAM role 을 생성해줍니다. Role 은
IAM 콘솔을 통하여 생성합니다.

8. 역할만들기 버튼을 눌러서 AWS 서비스를 고르고 아래에서 Redshift 를 선택합니다.
9. 사용 사례는 아래에 있는 Redshift – Customizable 을 선택합니다.

10. 그리고 다음페이지에서 AmazonS3ReadOnlyAccess 를 선택합니다.

11. 그리고 AWSGlueConsoleFullAccess 를 마찬가지로 선택합니다.

12. 검토를 눌러주고 적절한 이름을 부여한다음 역할을 만들어줍니다.
13. 만들어준 역할의 arn 을 확인해줍니다.
14. RedShift 콘솔에서 클러스터 텝에서 IAM Roles 오른쪽의 See IAM Roles 링크를
눌러줍니다. 그리고 앞서 만들어준 Role(역할)을 적용해줍니다.

15. 다시 RedShift 콘솔에서 Query Editor 를 열어줍니다.
16. 우선 새로운 외부 스키마를 생성합니다.
17. 성공적으로 스키마가 만들어지면 아래와 같이 나타납니다.

18. 그리고 외부 Table 인 S3 에 존재하는 데이터를 연결하기 위하여 아래를 Query
Editor 에서 실행합니다.
CREATE external table spectrum.PlayLog (
posnewz BIGINT,
posnewy BIGINT,
posnewx BIGINT,
pidx BIGINT,
createdate timestamp,
action INT,
posoldx BIGINT,
posoldy BIGINT,
posoldz BIGINT,
idx BIGINT

)
row format delimited
fields terminated by ','
stored as textfile
location 's3://[여러분의 Bucket 이름]/playlog/';
19. 성공하면 Tables 에 playlog 테이블이 추가된 것을 볼수 있습니다.
20. 생성된 table 의 오란쪽에 있는 눈동자를 눌러주면 10 개의 row 의 내용을 볼 수
있습니다.

이제 RedShift 를 통하여 HoL1 에서 사용하던 데이터들을 사용한 다양한 편집/ 분석을 하실
수가 있습니다.
Quiz…..
1) 20 개의 데이터를 MySQL/ Aurora/ RedShift Spectrum 에 import 했습니다. 이
데이터를 통하여 가장 사용자 activity 가 많았던 때 (1 시간 단위)가 언제일까요? –
YYYY 년 MM 월 DD 일 HH 시 MM 분 으로 가장 빨른 시간에 분석해보세요
2) DDB 에서 서로 다른 thread 에서 거의 동시에 쓰기를 시도 했습니다. 누가 이길까요?
3) DDB 에서 Safe Write 를 할 수 있는 방법은 무엇일까요?

게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018

More Related Content

게임을 위한 AWS의 다양한 관리형 Database 서비스 Hands on Lab (김성수 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018