AWS + Tajo를 이용한 '테라 렉 로그 분석 이야기' 2nd (2015.12.07)

테라 렉 로그 분석 이야기
Bluehole
데이터엔지니어링팀
이의석(eslee@bluehole.net)
Updated : 2015-12-07

발표자 소개
• 이름 : 이의석
• 회사 : 블루홀
• 부서 : 데이터 엔지니어링 팀
• 담당 업무 : 로그 수집 시스템 개발,
BI 서비스 구축,
데이터 분석 지원

목차
1. 문제 발생
2. 고민
3. 로그 수집
4. 로그 분석
5. 결과
6. 또 다른 이슈 발생
7. 후기

테라유저포럼에게임이느리다는말이나오고있습니다…
이러다가 게시판에 항의글로
가득찰지도 모릅니다. ㅠ

로그를 수집해야 할 것 같습니다.
유저의 원성이 가득한게 혹시 클라이언트에
문제가 있는 것은 아닐까?

빠른 시간 내에 테라 유저의 로그를 수용할 만한
시스템을 구축하고 분석해야 합니다.

수집 로그 정보
로그는 1초마다 수집하여 2분동안의 json 형식의 데이터 셋을 만들기로 했습니다.
그리고 유저 정보와 함께 로그수집 서버에 업로드 해야 합니다.
FPS, 대륙아이디, 채널, 위
치정보, 이용자 상태 등
초마다 수집되는 데이터
직업, 종족, 성별, Full scree여
부, 하드웨어 정보, IO정보 등
이용자 정보 데이터

로그 포맷
{
"clientTimemils": 1442894612906,
"token": "a12d16a884704bcdf972163b613cfde5",
"data": [
"79.852348|4.354904|4.887936|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game",
…
"79.969070|4.403917|5.012484|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game"
],
"userInfo": {
"accountDbId": 60,
"class": 1,
….
},
"clientInfo": {
"cpuModel": "Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz",
………..
}
}

예상 로그 사이즈
로그의 사이즈와 유저 1명이 한시간에 보내는 로그의 사이즈를
파악하여 계산해 보았을 때
로그의 크기는 시간당 약6GB를 예상할 수 있습니다.
(대략적인 동접으로 계산했기 때문에 시간대별 편차는 있습니다.)

예상 로그 사이즈
6 144
1008
4320
한시간 하루 일 주일 한 달
로그 사이즈
한 달이면 4TB!

어떻게 수집하지?
서버 새로 사야 하나? 몇대 사지?
어느 정도 스팩의 서버를 넣어야 할까?
어떻게 수집하지?
어떻게 분석하지?
그전에 유저는 이탈해서 영영 안 돌아 올지도…

빠르게 구축해야 합니다.
비용도 사용한만큼만 내면 되고,
필요할 때 바로 사용할 수 있으니 AWS를 이용해 보자.

AWS의 어떤 서비스를 이용해야 할까?
API Gateway
“테라 클라이언트는 C++이니깐 HTTP로 송신하면 쉽게 사용할 수 있겠지?”
Lambda
“api gateway로부터 받은 로그는 lambda에서 처리하여 s3에 저장하면되겠지?”

1차 시도는 실패!
매일 천 만건 이상의 Request를 받고 처리하는데
예상보다 많은 비용이 청구 될 것 같습니다. ㅠ

Kinesis로 정했습니다.
Kinesis
스트림 기반으로 데이터를 수집하고 KCL(Kinesis client library)를 이용하여
Kinesis에 저장된 데이터를 KCL Daemon을 이용하여 S3에 저장합니다.
예상가격도 한 달에 $40정도 입니다.
다만 클라이언트에서 http요청을 하기 위해
클라이언트 팀에서 aws와 통신하기 위한 데이터 암호화 및 인증 처리에
많은 고생을 해주셨습니다.
http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthen
tication.html

Game Client
• Tera Client에서 매초마다의 데이터를 수집하여 2분단위로 json format의 데이터를 만든다.
• 10분에 한번 2분단위로 수집한 데이터들을 AWS Kinesis로 전송한다. (PutRecords)
• KCL이 올라와 있는 EC2인스턴스에서는 Kinesis에 저장된 Record를 주기적으로 가져온다.(GetRecords)
2분단위로 저장된 데이터는 1초 단위의 데이터로 분리한다. (2분 단위 1건 데이터 -> 1초 단위 120건 데이터)
• 분리된 데이터는 s3에 저장한다.
(저장은 EC2인스턴스에 지정된 버퍼사이즈, 파일수, 타임아웃에 따라 적절한 단위로 저장된다.)
이렇게 수집해보기로 하였습니다.
PutRecords GetRecords
checkPoint
Save to S3
log files into
separate files
KCL Instance
(Kinesis Client Library)

로그 포맷 - 2분 단위 로그
{
"data": [
"79.852348|4.354904|4.887936|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game",
…
"79.969070|4.403917|5.012484|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game"
],
"userInfo": {
"accountDbId": 60,
"class": 1,
….
},
"clientInfo": {
………..
}
}

로그 포맷 – 초당 데이터로 변환
{
"data_fps": 79.85234,
"data_position": 4.354904,
"data_status": 1,
"userInfo_accountDbId": 60,
"userInfo_class": 1,
"clientInfo_cpuModel": "Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz“,
….
}
2분에 해당하는 1건의 데이터를 120건의 초단위 데이터로 변환 ?!

로그 포맷 – My Fault!
{
"data": [
"79.852348|4.354904|4.887936|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game",
…
"79.969070|4.403917|5.012484|9827|-1|206110724|-13511.272461|-21982.505859|-3409.861084|0|1|0|Game"
],
"userInfo": {
"accountDbId": 60,
"class": 1,
….
},
"clientInfo": {
………..
}
}

하루 쌓이는 데이터 건수
506,425,200
(10월 1일 기준)
500 ~ 600GB/day

수집한 데이터를 어떻게 분석해야 할까요?
분석에 필요한 소프트웨어는 충분히 있습니다.
그럼 어떤걸 사용해야 할까요?

타조(Tajo)를 이용해 보기로 하였습니다.
• 분석팀에서 가장 익숙한 언어(SQL)로 분석할 수 있어야 합니다.
• DB Client 소프트웨어를 이용한 분석이 가능해야 합니다.
• 빅데이터(?)와 관련하여 잘 알지 못하더라도 이용 및 관리를 할 수 있어야 합니다.

• s3에 압축되어 저장된 로그는 EMR에 세팅된 타조를 이용하여 분석을 한다. 타조에서는 JDBC 커넥터를 제공하기 때문에 jdbc를
지원하는 다양한 Application에서 이용이 가능 할 수 있다.
• 매일 저장되는 약50GB의 데이터는 5억건정도로 이를 분석하기 위해서는 Tajo에서 column based partitioning table을 이용하여
일자별 파티셔닝을 하여 좀더 빠른 검색이 가능하도록 하였다.
데이터 분석
Tajo table data,
catalog, logs…
50GB snappy files/1 day
(100MB per file)
올챙이(Tadpole)
Tajo
Master
(m3.xlarge) 1x
Core
(c3.4xlarge) 5x
DB client tool
(ex. DB Visualizer)

• Kinesis를 통해서 s3에 저장되는 파일은 버퍼의 사이즈에 따라 다르지만 60~70MB 단위의 텍스트 파일로 이루어져 있다.
이렇게 매일 쌓이는 데이터는 약 500GB정도로 분석을 하기에는 파일의 개수나 사이즈가 큰 편이다.
• AWS Data pipeline으로 스케쥴링 작업을 수행하여 매일 1시(UTC기준)에 s3에 저장된 데이터를 s3distcp를 이용하여 snappy로
압축을 하고 100MB 단위로 압축을 수행한다.
• 압축된 파일은 s3의 다른 bucket에 저장된다.
• 매일 500GB 데이터는 snappy로 압축되어 50GB로 줄어든다. 파일은 100~120MB단위로 쪼개져 있다.
데이터 압축(snappy)
s3distcp
(file merging and compressing)
Scheduling
(Every day at 1:00)
500GB log files
(60~70MB per file)
50GB snappy files
(100MB per file)

162,746
5,394
11,908,920,350,709
1,193,879,915,587
0 5,000,000,000,000 10,000,000,000,000 15,000,000,000,000
0 20,000 40,000 60,000 80,000 100,000 120,000 140,000 160,000 180,000
압축전
압축후
파일수 파일사이즈 (bytes)
수치로 보는 데이터크기 (9월22일~10월14일기준)
압축 전
162,746 files / 10.83 TB
압축 후
5,394 files / 1.09 TB

데이터 압축(snappy)
Uncompressed
log files
 logFile1.log (100MB)
…
LogBucket (500GB/day)
use snappy
compression
 logFile1.snappy (200MB)
…
TableName (50GB/day)
/regdate=20151012
…
/regdate=20151013

Create external table
CREATE EXTERNAL TABLE IF NOT EXISTS teralaglog_us (
token text,
"clientTimemils" bigint,
streamtimemils bigint,
….
)
USING json WITH ('compression.codec'='org.apache.hadoop.io.compress.SnappyCodec')
partition by column (regdate int)
LOCATION 's3://{tajo.base.dir}/TeraLagLogUs';

Column Partitioning
SELECT fps, userinfo_accountid, …..
FROM teralaglog_us
WHERE regdate=20151012
…
use snappy
compression
…
TableName (50GB/day)
/regdate=20151012
…
/regdate=20151013
매일 데이터가 들어오면 따로 작업 필요 없이 바로 SELECT가 가능하다.

결과는 만족스러웠습니다.
• 빅 데이터가 뭔지 몰라도 기존에 알고 있던 SQL을 이용하여 분석 할 수
있었습니다.
• 데이터 사이즈 대비 빠른 결과를 얻어서 빠르게 파악할 수 있었습니다.
• 유저들이 어디에서 쾌적하지 못한 플레이를 하고 있는지 파악할
수 있었습니다.

특정지역에서유저들이불편함을느끼고있었습니다.
116지역 116지역
프레임 수를 기준으로 쾌적 ~ 불쾌, 매우 불쾌로 구분하고
일정기준 이하의 불쾌함을 느끼는 유저들의 표본을 뽑아서 불쾌, 매우 불쾌한 지역을 찾았다.

불만이접수된유저를분석해보았습니다.
116지역 116지역
고 사양 하드웨어를 갖추고 있는 사용자의
플레이 로그를 분석한 결과,
실재로 느린 것이 아닌 체감에 의한 불만이라고 판단.

패치이후비교분석
116지역 116지역
클라이언트 패치 이후
지역별 불쾌 또는 매우 불쾌감을
느끼는 유저의 비중이 줄었다!

북미분석이후…
116지역
us-east-1 (S3 : US Standard) ap-northeast-1
Firehose
eu-west-1
EMR(Tajo)
KinesisKCLKinesis KCL
s3distcp s3distcp
500GB/day
650GB/day
400GB/day
Kinesis KCL
북미 일본, 중국, 대만
러시아, 유럽
일본, 중국, 대만, 러시아, 유럽의 분석 국가를
확대하여 진행하고 있습니다.

• 렉 로그의 지속적인 업데이트…
• 유의미한 정보를 찾을 수 있도록 고군분투 중!
• 테스트환경에서의 렉 로그 분석 자동화
북미분석이후…

예상치 못한 문제가 생겼습니다.
생각 보다 많은 비용이 청구되고 있습니다…

AWS 비용 절약사례 (as-is)
Master
(m3.xlarge) 1x
Core (c3.4xlarge) 5x
EMR
AWS의 비용정책은 사용한 시간만큼의 비용을
지불합니다.
데이터를 분석하기 위한 Tajo환경을 구성하는데
있어서 EMR + EC2인스턴스 비용을 지불
(s3나 기타 RDS는 미비 하며 고정비용이므로 여기선 생략)
실제 사용시간 = 업무시간
그 외의 시간에도 가동됨에 따라 비용이 계속 발
생. (낭비)
Instance type EC2 pricing EMR pricing
m3.xlarge $0.266 / hour $0.070 / hour
c3.4xlarge $0.84 / hour $0.210 / hour
10:00 ~ 19:00 (9hour)

AWS 비용 절약사례 (to-be)
Master
(m3.xlarge) 1x
Core (c3.4xlarge) 1x
EMR
Task (c3.4xlarge) 4x spot instance
Spot instance
add / remove
매일 출근 시간 30분전에 c3.4xlarge 4대를 Spot
instance로 추가 한다.
spot instance로 추가하는경우 희망하는 가격으
로 입찰할 수 있다. c3.4xlarge의 입찰가 범위는
$0.16~0.19사이 (on-demand 가격은 $0.84)
그리고 매일 오후 8시에 낙찰된 인스턴스를 반
납한다.
이렇게 매일 업무시간 이외에는 최소한 유지해
야 하는 자원만 남길 수 있다.
(Master 1대, Core 1대)
Instance type EC2 pricing EC2 Biding price
c3.4xlarge $0.84 / hour $0.18 / hour 9:30 ~ 20:00 (10.5hour)

EC2 EMR
적용 전 117.6 30.94
적용 후 29.65 12.46
$117.60
$30.94$29.65
$12.46
1
10
100
1000
절약 비용(일 기준)
적용 전 적용 후
AWS 비용 절약사례 (to-be)
매일 $100정도 절약할 수
있게 되었다!!
물론 토요일, 일요일에는
2대만 가동되기 때문에
한달 추정치는 더 저렴하다.

AWS도 저와 같은 고민을 하고 있었습니다.
더욱 저렴하게 더 간편하게 구현이 가능해졌습니다.
AWS Re-Invent 2015

AWS도 저와 같은 고민을 하고 있었습니다.
Game Client
PutRecords GetRecords
checkPoint
Save to S3
log files into
separate files
KCL Instance
(Kinesis Client Library)
s3distcp
Scheduling
(Every day at 1:00)
500GB log files
(60~70MB per file)
50GB snappy files
(100MB per file)
[데이터 수집과정]
[데이터 압축과정]

AWS Kinesis firehose면 됩니다.
Game Client
PutRecords
Save to S3
(.snappy)
Kinesis firehose
데이터 처리 Batch Records
Kinesis firehose만으로도 가능하겠지만, 2분동안 쌓인 로그를 초단위형식의
데이터를 변환하는 과정이 필요하였기 때문에 Kinesis - KCL이 필요했습니다.
Kinesis stream KCL
checkPoint

타조에 조금은 아쉬웠던 것들…
• EMR의 Spot Instance를 사용하면 할당/반납을 반복하게 되는데 반납한
Worker들이 Tajo admin에서 Dead Worker로 잡히는 점
• 데이터에 이상한 값이 들어가는 경우에 조회하였을때 Out of Memory 에러가
발생하는 문제
• 타조 어드민에서 현재 수행중인 쿼리를 확인하고 처리 정도를 알 수 있었습니다.
• 수행중인 쿼리를 Kill!할 수 있었습니다.
의외로 좋았던 것

AWS를 사용하면서 이슈가 되었던 것들…
• Kinesis는 데이터를 밀어넣기는 좋으나 꺼내기가 까다롭다.
• Region을 잘못 선택하면 예상치 못한 비용을 지불해야 할 수도 있다.
• 싸다고 싸다고 하지만 잘 써야 쌉니다.

이런 실수는 저지르면 안됩니다.
s3distcp
Scheduling
(Every day at 1:00)
500GB log files
(60~70MB per file)
50GB snappy files
(100MB per file)
50GB snappy files
(100MB per file)
US Standard
free free
[원래 계획]
s3distcp
Scheduling
(Every day at 1:00)
500GB log files
(60~70MB per file)
US Standard
free not free
[잘못된 결과]
Oregon

EC2 Spot Instance의 사용시 주의!
너무 싸게 입찰 받는다면 금방 회수 당할 수 있다!
쓰고 있더라도 상위 입찰자가 나타나면 2분전 알람을 준 이후에 바로 회수합니다.

감사합니다.
Special thanks to
Bluehole > 데이터 엔지니어링팀, 테라 통합 분석팀, 테라 클라이언트 팀
Gruter > 정재화

AWS + Tajo를 이용한 '테라 렉 로그 분석 이야기' 2nd (2015.12.07)

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

AWS + Tajo를 이용한 '테라 렉 로그 분석 이야기' 2nd (2015.12.07)