Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

9,582 views

Published on

추가 : 기존 발표자료에 부족한 부분이 있어서 좀 보강하였습니다. (Updated : 2015-12-07)

Bluehole(블루홀)에서 개발한 MMORPG게임 테라(TERA)에서 발생한 렉 이슈를 해결하기 위해 어떻게 데이터를 수집하고 분석하여 해결하였는지 설명합니다.

이 자료는 '한국 Tajo 사용자 그룹 11월 meet-up'에서 발표한 자료입니다.

Published in: Technology
  • Be the first to comment

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

  1. 1. 테라 렉 로그 분석 이야기 Bluehole 데이터엔지니어링팀 이의석(eslee@bluehole.net) Updated : 2015-12-07
  2. 2. 발표자 소개 • 이름 : 이의석 • 회사 : 블루홀 • 부서 : 데이터 엔지니어링 팀 • 담당 업무 : 로그 수집 시스템 개발, BI 서비스 구축, 데이터 분석 지원
  3. 3. 목차 1. 문제 발생 2. 고민 3. 로그 수집 4. 로그 분석 5. 결과 6. 또 다른 이슈 발생 7. 후기
  4. 4. 테라유저포럼에게임이느리다는말이나오고있습니다… 이러다가 게시판에 항의글로 가득찰지도 모릅니다. ㅠ
  5. 5. 로그를 수집해야 할 것 같습니다. 유저의 원성이 가득한게 혹시 클라이언트에 문제가 있는 것은 아닐까?
  6. 6. 빠른 시간 내에 테라 유저의 로그를 수용할 만한 시스템을 구축하고 분석해야 합니다.
  7. 7. 수집 로그 정보 로그는 1초마다 수집하여 2분동안의 json 형식의 데이터 셋을 만들기로 했습니다. 그리고 유저 정보와 함께 로그수집 서버에 업로드 해야 합니다. FPS, 대륙아이디, 채널, 위 치정보, 이용자 상태 등 초마다 수집되는 데이터 직업, 종족, 성별, Full scree여 부, 하드웨어 정보, IO정보 등 이용자 정보 데이터
  8. 8. 로그 포맷 { "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", ……….. } }
  9. 9. 예상 로그 사이즈 로그의 사이즈와 유저 1명이 한시간에 보내는 로그의 사이즈를 파악하여 계산해 보았을 때 로그의 크기는 시간당 약6GB를 예상할 수 있습니다. (대략적인 동접으로 계산했기 때문에 시간대별 편차는 있습니다.)
  10. 10. 예상 로그 사이즈 6 144 1008 4320 한시간 하루 일 주일 한 달 로그 사이즈 한 달이면 4TB!
  11. 11. 어떻게 수집하지? 서버 새로 사야 하나? 몇대 사지? 어느 정도 스팩의 서버를 넣어야 할까? 어떻게 수집하지? 어떻게 분석하지? 그전에 유저는 이탈해서 영영 안 돌아 올지도…
  12. 12. 빠르게 구축해야 합니다. 비용도 사용한만큼만 내면 되고, 필요할 때 바로 사용할 수 있으니 AWS를 이용해 보자.
  13. 13. AWS의 어떤 서비스를 이용해야 할까? API Gateway “테라 클라이언트는 C++이니깐 HTTP로 송신하면 쉽게 사용할 수 있겠지?” Lambda “api gateway로부터 받은 로그는 lambda에서 처리하여 s3에 저장하면되겠지?”
  14. 14. 1차 시도는 실패! 매일 천 만건 이상의 Request를 받고 처리하는데 예상보다 많은 비용이 청구 될 것 같습니다. ㅠ
  15. 15. Kinesis로 정했습니다. Kinesis 스트림 기반으로 데이터를 수집하고 KCL(Kinesis client library)를 이용하여 Kinesis에 저장된 데이터를 KCL Daemon을 이용하여 S3에 저장합니다. 예상가격도 한 달에 $40정도 입니다. 다만 클라이언트에서 http요청을 하기 위해 클라이언트 팀에서 aws와 통신하기 위한 데이터 암호화 및 인증 처리에 많은 고생을 해주셨습니다. http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthen tication.html
  16. 16. 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)
  17. 17. 로그 포맷 - 2분 단위 로그 { "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", ……….. } }
  18. 18. 로그 포맷 – 초당 데이터로 변환 { "clientTimemils": 1442894612906, "token": "a12d16a884704bcdf972163b613cfde5", "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건의 초단위 데이터로 변환 ?!
  19. 19. 로그 포맷 – My Fault! { "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", ……….. } }
  20. 20. 하루 쌓이는 데이터 건수 506,425,200 (10월 1일 기준) 500 ~ 600GB/day
  21. 21. 수집한 데이터를 어떻게 분석해야 할까요? 분석에 필요한 소프트웨어는 충분히 있습니다. 그럼 어떤걸 사용해야 할까요?
  22. 22. 타조(Tajo)를 이용해 보기로 하였습니다. • 분석팀에서 가장 익숙한 언어(SQL)로 분석할 수 있어야 합니다. • DB Client 소프트웨어를 이용한 분석이 가능해야 합니다. • 빅데이터(?)와 관련하여 잘 알지 못하더라도 이용 및 관리를 할 수 있어야 합니다.
  23. 23. • 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)
  24. 24. • 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)
  25. 25. 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
  26. 26. 데이터 압축(snappy) Uncompressed log files  logFile1.log (100MB)  logFile2.log (102MB)  logFile3.log (99MB)  logFile4.log (101MB)  logFile5.log (103MB)  logFile6.log (101MB)  logFile7.log (102MB)  logFile8.log (103MB) … LogBucket (500GB/day) use snappy compression  logFile1.snappy (200MB)  logFile2.snappy (202MB)  logFile3.snappy (201MB)  logFile4.snappy (201MB) … TableName (50GB/day) /regdate=20151012  logFile1.snappy (200MB)  logFile2.snappy (202MB) … /regdate=20151013
  27. 27. 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';
  28. 28. Column Partitioning SELECT fps, userinfo_accountid, ….. FROM teralaglog_us WHERE regdate=20151012 … use snappy compression  logFile1.snappy (200MB)  logFile2.snappy (202MB)  logFile3.snappy (201MB)  logFile4.snappy (201MB) … TableName (50GB/day) /regdate=20151012  logFile1.snappy (200MB)  logFile2.snappy (202MB) … /regdate=20151013 매일 데이터가 들어오면 따로 작업 필요 없이 바로 SELECT가 가능하다.
  29. 29. 결과는 만족스러웠습니다. • 빅 데이터가 뭔지 몰라도 기존에 알고 있던 SQL을 이용하여 분석 할 수 있었습니다. • 데이터 사이즈 대비 빠른 결과를 얻어서 빠르게 파악할 수 있었습니다. • 유저들이 어디에서 쾌적하지 못한 플레이를 하고 있는지 파악할 수 있었습니다.
  30. 30. 특정지역에서유저들이불편함을느끼고있었습니다. 116지역 116지역 프레임 수를 기준으로 쾌적 ~ 불쾌, 매우 불쾌로 구분하고 일정기준 이하의 불쾌함을 느끼는 유저들의 표본을 뽑아서 불쾌, 매우 불쾌한 지역을 찾았다.
  31. 31. 불만이접수된유저를분석해보았습니다. 116지역 116지역 고 사양 하드웨어를 갖추고 있는 사용자의 플레이 로그를 분석한 결과, 실재로 느린 것이 아닌 체감에 의한 불만이라고 판단.
  32. 32. 패치이후비교분석 116지역 116지역 클라이언트 패치 이후 지역별 불쾌 또는 매우 불쾌감을 느끼는 유저의 비중이 줄었다!
  33. 33. 북미분석이후… 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 북미 일본, 중국, 대만 러시아, 유럽 일본, 중국, 대만, 러시아, 유럽의 분석 국가를 확대하여 진행하고 있습니다.
  34. 34. • 렉 로그의 지속적인 업데이트… • 유의미한 정보를 찾을 수 있도록 고군분투 중! • 테스트환경에서의 렉 로그 분석 자동화 북미분석이후…
  35. 35. 예상치 못한 문제가 생겼습니다. 생각 보다 많은 비용이 청구되고 있습니다…
  36. 36. 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)
  37. 37. 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)
  38. 38. 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대만 가동되기 때문에 한달 추정치는 더 저렴하다.
  39. 39. AWS도 저와 같은 고민을 하고 있었습니다. 더욱 저렴하게 더 간편하게 구현이 가능해졌습니다. AWS Re-Invent 2015
  40. 40. AWS도 저와 같은 고민을 하고 있었습니다. Game Client PutRecords GetRecords checkPoint Save to S3 log files into separate files KCL Instance (Kinesis Client Library) s3distcp (file merging and compressing) Scheduling (Every day at 1:00) 500GB log files (60~70MB per file) 50GB snappy files (100MB per file) [데이터 수집과정] [데이터 압축과정]
  41. 41. AWS Kinesis firehose면 됩니다. Game Client PutRecords Save to S3 (.snappy) Kinesis firehose 데이터 처리 Batch Records Kinesis firehose만으로도 가능하겠지만, 2분동안 쌓인 로그를 초단위형식의 데이터를 변환하는 과정이 필요하였기 때문에 Kinesis - KCL이 필요했습니다. Kinesis stream KCL checkPoint
  42. 42. 타조에 조금은 아쉬웠던 것들… • EMR의 Spot Instance를 사용하면 할당/반납을 반복하게 되는데 반납한 Worker들이 Tajo admin에서 Dead Worker로 잡히는 점 • 데이터에 이상한 값이 들어가는 경우에 조회하였을때 Out of Memory 에러가 발생하는 문제 • 타조 어드민에서 현재 수행중인 쿼리를 확인하고 처리 정도를 알 수 있었습니다. • 수행중인 쿼리를 Kill!할 수 있었습니다. 의외로 좋았던 것
  43. 43. AWS를 사용하면서 이슈가 되었던 것들… • Kinesis는 데이터를 밀어넣기는 좋으나 꺼내기가 까다롭다. • Region을 잘못 선택하면 예상치 못한 비용을 지불해야 할 수도 있다. • 싸다고 싸다고 하지만 잘 써야 쌉니다.
  44. 44. 이런 실수는 저지르면 안됩니다. s3distcp (file merging and compressing) 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 (file merging and compressing) Scheduling (Every day at 1:00) 500GB log files (60~70MB per file) US Standard free not free [잘못된 결과] Oregon
  45. 45. EC2 Spot Instance의 사용시 주의! 너무 싸게 입찰 받는다면 금방 회수 당할 수 있다! 쓰고 있더라도 상위 입찰자가 나타나면 2분전 알람을 준 이후에 바로 회수합니다.
  46. 46. 감사합니다. Special thanks to Bluehole > 데이터 엔지니어링팀, 테라 통합 분석팀, 테라 클라이언트 팀 Gruter > 정재화

×