Upgrade to Pro — share decks privately, control downloads, hide ads and more …

(자막)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축...

(자막)[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유

NDC18에서 발표하였습니다.

자막없이 보기 -> https://hyojun.me/~ndc18-slide

Hyojun Jeon

April 24, 2018
Tweet

More Decks by Hyojun Jeon

Other Decks in Programming

Transcript

  1. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오

    전효준 : 로그 시스템 구축 경험 공유 안녕하세요.
  2. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오

    전효준 : 로그 시스템 구축 경험 공유 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기를 주제로 발표하게 된
  3. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오

    전효준 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 전효준입니다.
  4. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오

    전효준 : 로그 시스템 구축 경험 공유 많은 분들이 찾아와주셨는데 이렇게 시간내어 찾아와주셔서 감사드립니다.
  5. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 저는 왓 스튜디오의 백엔드 엔지니어이고요.
  6. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 저는 2개의 스타트업을 거쳐서 넥슨에 입사하게 되었고
  7. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 직전에는 버즈니라는 회사의 데이터 인프라팀에서
  8. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 로그 시스템을 개발하고 운영한 경험이 있습니다.
  9. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 스튜디오에서는 자료공이라고 불리기도 하는데요.
  10. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공

    역할 [email protected] 자료공 = 데이터 엔지니어 전효준 [email protected] 이 자료공은 저희가 흔히 말하는 데이터 엔지니어를 한글로 표현한 것 입니다.
  11. (론칭이후 약 3개월간) 110 TB 지금 앞에 보시는 숫자는 저희가

    론칭 이후 약 3개월간 적재한 로그의 양입니다.
  12. (론칭이후 약 3개월간) 110 TB 이 것들을 잘 다룰 수

    있는 로그 시스템을 구축하고 있습니다.
  13. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 이쯤에서 듀랑고의 로그 시스템을 간단히 소개드리면
  14. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB 먼저 저희는 보여드린 것과 같이 로그들을 버리지 않고 수집하고 적재하고 있고
  15. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 로그가 발생하고 나서 대략 5초 이내에 조회하고 검색할 수 있습니다.
  16. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 이런 단순 조회나 검색이 아닌 대규모의 로그도 빠르게 분석 가능하고
  17. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 별다른 조작 없이도 시각화할 수 있습니다.
  18. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 관리부담을 최소화하였는데
  19. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간

    로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 → 혼자서도 여유롭게 때문에 저 혼자서도 여유롭게 로그 시스템을 운영할 수 있습니다.
  20. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 오늘 발표는 이런 로그 시스템에 대하여 발표를 할 텐데요.
  21. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 저희가 로그를 쌓아서 어떻게 사용하고 있는지
  22. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 이렇게 사용하기 위해 어떤 것을 목표로 잡았고
  23. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그 목표를 달성하기 위해 어떻게 아키텍처를 구성하였는지
  24. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그리고 이런 아키텍처에서 각각의 요소들을 ‘잘’ 사용하는 방법들을 소개하고
  25. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그

    시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 개선할 점들을 이야기하며 마무리할 예정입니다.
  26. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 첫

    번째로 서비스 운영을 위해 로그 조회가 필요한데요.
  27. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 그

    예로 “아이템이 없어졌어요!” 라는 고객문의가 들어올 때가 있습니다.
  28. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 이런

    문의가 들어오면 운영하는 입장에서는 확인절차를 거쳐야 하는데요.
  29. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제

    이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 실제로 유저가 아이템을 획득하였는지, 혹시나 다른 경로로 소비한 내역이 없는지 등
  30. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제

    이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 여러 가지를 확인하고 복구를 해야 하는데
  31. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제

    이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 이 때 로그를 조회하여 확인절차를 거치게 됩니다.
  32. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율,

    플레이 시간 • 각종 통계 추출 • 등등 ... 다음으로는 각종 주요 지표를 추출하기 위함인데요.
  33. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율,

    플레이 시간 • 각종 통계 추출 • 등등 ... 실제로 DAU나, MAU, 리텐션 등
  34. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율,

    플레이 시간 • 각종 통계 추출 • 등등 ... 각종 지표나 통계를 추출하기 위한 기반 데이터로 사용하고 있습니다.
  35. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향

    설정 • 초반 가이드 개선 • 등등 ... 세 번째는 데이터 기반으로 의사결정을 하고 있기 때문입니다.
  36. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향

    설정 • 초반 가이드 개선 • 등등 ... 몇 가지 사례를 말씀드리면
  37. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 •

    적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 섬 인구수 별 재방문율 지표를 보고 적정 인구수를 산정하기도 했고요.
  38. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 유저분들의 플레이 유형을 클러스터링한 정보를 통해
  39. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 업데이트 방향을 설정하는 지표로 삼기도 하였습니다.
  40. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 그리고 이탈구간 분석 및 레벨별 활성 유저 수와 같은 정보를 기반으로
  41. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 초반 가이드를 개선하기도 하였는데요.
  42. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 이 초반가이드 개선에 대한 발표도 NDC 마지막날인 26일에 있으니
  43. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 →

    이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 관심 있으신 분들은 참관하셔도 좋을 듯합니다.
  44. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ

    (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 오류가 발생했을 때 분산된 게임서버에 하나하나 SSH로 접속하여
  45. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ

    (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 관련된 로그를 찾다가 결국 못 찾게 되는 상황이 있을 수 있습니다.
  46. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ

    (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 로그를 못 찾아서 원인파악을 빠르게 하지 못하면
  47. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ

    (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 이슈를 빠르게 대응할 수 없고 개발자들의 생산성이 떨어질 수 있겠죠
  48. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 •

    어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 그래서 이 오류코드는 저희 서버의 시스템 로그를 조회하기 위한 것입니다.
  49. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 •

    어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희 로그 시스템에서는 어떤 서버에서 어떤 에러가 발생하였는지,
  50. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 •

    어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 어떤 경로로 호출되었는지 Python Traceback을 남기고 있습니다.
  51. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 •

    어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희는 수많은 호스트들에서 발생하는 시스템 로그를 모두 수집하여 한 곳에 모으고 있고
  52. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 •

    어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 결국 오류코드는 로그가 발생한 시점의 서버로그를 찾기 위한 단서라고 할 수 있습니다.
  53. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 •

    주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 정리를 해보면 저희는 게임플레이 로그와 시스템 로그
  54. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 •

    주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 크게 두 가지 종류의 로그를 수집하고 있는데요.
  55. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 •

    주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 게임플레이 로그는 서비스 운영, 의사결정, 주요 지표 추출에 사용되고있고
  56. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 •

    주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 시스템 로그는 개발자들의 생산성을 확대하고, 빠른 이슈 대응을 위해 수집하고 있습니다.
  57. 우리의 지속적 발전을 위한 중요한 도구 결과적으로 이런 로그는 우리의

    지속적 발전을 위한 중요한 도구로 사용되고 있는데요.
  58. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 먼저 로그 시스템의 요구사항들을 한번 살펴보겠습니다.
  59. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 듀랑고는 복잡한 게임시스템을 가지고 있는데
  60. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 자유도 높은 아이템 구조와 같은 특징으로
  61. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 이는 곧 복잡한 로그 스키마 구조를 표현할 수 있어야 했습니다.
  62. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 게임 플레이로그와 시스템 로그들을 모두 수집하다 보니
  63. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 대규모 로그 발생을 감당할 수 있어야 했고
  64. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 같은 맥락으로 대규모 분석도 가능해야 했습니다.
  65. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 대규모 분석말고도 즉각적인 조회와 검색도 가능해야 했습니다.
  66. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex)

    플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 하지만 이런 로그 시스템의 요구사항 외에
  67. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex)

    플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 스키마의 변동이 없거나 높은 신뢰도가 요구되는 일부 로그들은
  68. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex)

    플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 별도의 RDB를 사용했습니다.
  69. → 이번 발표에서 RDB 로그는 다루지 않아요 하지만 이번 발표에서

    RDB에 저장하는 로그에 대해서는 따로 다루지 않을 예정입니다.
  70. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 앞서 이런 요구사항을 충족하는 로그시스템을 구축하기 위한 목표를 세워보았습니다.
  71. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석

    및 시각화 • 관리부담 최소화 목표는 총 4가지로
  72. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석

    및 시각화 • 관리부담 최소화 높은 가용성이 보장되어야 하고
  73. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석

    및 시각화 • 관리부담 최소화 실시간 조회가 가능해야 하며
  74. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석

    및 시각화 • 관리부담 최소화 분석 및 시각화가 가능해야 합니다.
  75. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석

    및 시각화 • 관리부담 최소화 그리고 관리부담을 최소화하는 것 입니다.
  76. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이

    죽으면 로그는 유실됨 각종 지표를 오염시킬 수도 있고 운영에 차질이 생길 수 있습니다.
  77. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이

    죽으면 로그는 유실됨 저 또한 힘들어질 수 있겠지요.
  78. 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는

    유실됨 높은 가용성 → 높은 가용성이 보장되어야 따라서 로그 시스템이 항상 잘 살아서 잘 돌아가도록 만들어야 했습니다.
  79. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 두 번째로는 실시간 조회가 가능해야 한다는 것 입니다.
  80. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 저장만 하고 원하는 로그를 찾을 수 없다면
  81. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 사실 저장하는 의미가 없습니다.
  82. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 반면에, 빠르게 로그를 찾을 수 있다는 건
  83. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 그만큼 빨리 문제에 대응할 수 있는 생산성 향상을 의미합니다.
  84. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 그래서 로그가 발생하고 부터
  85. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 대략 5초 이내에 조회가 가능하길 원했습니다.
  86. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 •

    • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 추가로 원하는 로그만을 조회할 수 있도록 검색도 가능해야 했습니다.
  87. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 또한 로그 시스템은 각종 분석 및
  88. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 그 결과에 대한 시각화도 가능해야 했는데요.
  89. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 대규모로 적재된 로그에 대해서도 빠르게 분석할 수 있어야 합니다.
  90. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 마치 RDB에 적재한 것처럼 SQL도 가능한 것을 목표로 했고
  91. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 여기서 분석 결과에 대한 그래프도
  92. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 코드를 이용해서 직접 그리거나 엑셀에 옮겨서 그래프를 표현하는 것이 아닌
  93. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한

    티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 분석 결과를 보고 어느정도 알아서 그려줬으면 좋겠다는 생각을 했습니다.
  94. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 •

    쉬운 확장 및 축소 마지막으로 저는 자료공의 역할만 하는 것이 아니기 때문에
  95. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 •

    쉬운 확장 및 축소 관리부담의 최소화가 필요했습니다.
  96. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 •

    쉬운 확장 및 축소 클라우드 서비스를 이용하면서 거의 탈출했다고 보아도 무방하지만
  97. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 •

    쉬운 확장 및 축소 로그 유입량에 따라 시스템을 쉽게 확장하거나 축소할 수 있어야 했습니다.
  98. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 알아서 잘

    수집하고 빠르게 조회도하고 분석도할 수 있는 로그 시스템인데요.
  99. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리가 감수할

    수 있는 만큼은 만족하는 시스템이길 바랐습니다.
  100. 로그 수집 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd 서버에서

    로그가 발생하면 Fluentd에서 로그를 수집하고
  101. 스트림에 전송 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd Fluentd는

    Kinesis라는 거대한 스트림으로 전송을 하게 되고
  102. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 Fluentd Fluentd Fluentd는 오픈소스 데이터 수집기인데
  103. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 Fluentd Fluentd 성능이 필요한 부분은 C언어로, 확장성이 필요한 부분은 Ruby로 구현되어 있어서
  104. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 빠르고 가볍다 Fluentd Fluentd 리소스 차지도 매우 적고 빠릅니다.
  105. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 또한 다양한 플러그인을 가지고 있는데요.
  106. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 앞서 보여드렸던 Kinesis에 로그를 전송할 수 있는 플러그인도
  107. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd AWS에서 지원하고 있습니다.
  108. • 오픈소스 데이터 수집기 • C + Ruby • 다양한

    플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 마지막으로 비교적 간편하게 설정할 수 있다는 점도 장점이었습니다.
  109. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 실제로 듀랑고에서

    하나의 서버군은 수많은 호스트로 구성이 되어있고
  110. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 실제로

    듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
  111. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드

    실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
  112. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드

    노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 여러 개의 노드가 실행됩니다.
  113. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드

    노드 호스트 = 머신 노드 = 프로세스 여기서 용어정리를 잠깐 하자면
  114. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드

    노드 호스트 = 머신 노드 = 프로세스 호스트는 하나의 머신을 의미하고
  115. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드

    노드 호스트 = 머신 노드 = 프로세스 노드는 각각의 프로세스를 의미합니다.
  116. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를

    수집하는 하나의 Fluentd Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 하나의 Fluentd가 존재해서 노드들의 로그를 수집하는데요.
  117. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를

    수집하는 하나의 Fluentd 로그 수집 에이전트의 역할 Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 쉽게 말해서 로그 수집 에이전트의 역할을 하고있습니다.
  118. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis 여기서 이야기하는 Kinesis는
  119. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis AWS의 관리형 서비스중 하나인 Kinesis data stream을 의미합니다.
  120. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 관리형 서비스이다 보니 높은 가용성이 보장되고
  121. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 크게 관리할 것이 없습니다.
  122. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 스트리밍 데이터를 저장하는 거대한 큐 역할을 하는데요.
  123. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 물론 큐는 데이터를 완전히 꺼내버리지만
  124. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 데이터를 삭제하지 않고 명시된 기간만큼 데이터를 보존합니다.
  125. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 이 기간은 기본적으로 24시간 부터 최대 7일 인데요.
  126. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 기간 동안은 데이터가 삭제되지 않기 때문에
  127. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 만약 데이터를 처리하는 레이어에서 문제가 발생하더라도
  128. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis Kinesis에는 아직 데이터가 남아있어서
  129. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 언제든지 복구가 가능하다는 것을 의미합니다.
  130. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 추가로 Kinesis에는 내부적으로 1개 이상의 샤드로 구성되는데
  131. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 샤드가 무중단으로 확장 및 축소가 가능하고
  132. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스

    • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 것은 결국 로그 유입량에 따라
  133. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스

    • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 다운타임 없이 유연하게 대응 가능하다는 것을 의미합니다
  134. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 실제로 이 확장 및 축소는
  135. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 AWS 콘솔에서 클릭 2번으로도 가능하고
  136. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할

    • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 저희는 아직 적용하진 않았지만 오토 스케일링도 가능합니다.
  137. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 •

    • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 여기서 Lambda는 AWS에서 지원하는 서버리스 컴퓨팅 서비스입니다.
  138. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 •

    • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 자동으로 확장하거나 축소하기도 하는데
  139. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 •

    • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 때문에 저희가 따로 인프라를 관리할 필요가 없었습니다.
  140. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 •

    • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 Lambda는 Kinesis의 이벤트를 트리거하여 쉽게 연동할 수 있기도 합니다.
  141. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 •

    • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 이렇게 Lambda는 Kinesis의 데이터를 처리하여
  142. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 실제로 비용만 감당할 수 있다면
  143. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 무한대로 저장할 수 있는 AWS 스토리지 서비스이고
  144. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전의 EC2에서 높은 전송속도를 보장합니다.
  145. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 도쿄 리전에서 테스트한 결과 r4.4xlarge 기준으로 200MB/s 정도 나오더라고요.
  146. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 그리고 높은 데이터 요청 빈도에 대하여 자동으로 확장하기도 합니다.
  147. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 대규모 데이터를 업로드하거나 다운로드하더라도
  148. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전에서는 데이터 전송 비용이 무료이기 때문에
  149. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 트래픽에 따른 비용걱정은 하지 않아도 됩니다.
  150. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 •

    높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 100퍼센트에 가까운 가용성과 내구성을 보장하고 있습니다.
  151. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한

    =최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 물론 약간의 제한이 있는데요.
  152. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한

    =최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) Kinesis에 최대 5개의 읽기 트랜잭션 제한때문인데
  153. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한

    =최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 이것이 의미하는 건
  154. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한

    =최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 사실상 하나의 Kinesis에 최대 5개의 Lambda만 안정적으로 트리거할 수 있다는 것 입니다.
  155. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 다시 돌아와서, 저희는 실시간 조회를 위해 Elasticsearch를 사용하고 있습니다.
  156. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 Lucene 기반의 분산 검색엔진이고
  157. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 역 인덱스를 이용한 빠른 검색이 가능합니다.
  158. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 그리고 Kibana라는 아주 유용한 시각화 플러그인을 제공합니다.
  159. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 저희는 직접 구축할 수도 있지만
  160. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 AWS에서 제공하는 Elasticsearch를 사용하는데요.
  161. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능

    • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 높은 가용성과 쉽게 확장이 가능하다는 장점이 있습니다.
  162. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만

    저장 (그 이후는 S3에 저장된 로그를 사용) 때문에 저희는 빠르게 조회할 필요성이 있는
  163. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만

    저장 (그 이후는 S3에 저장된 로그를 사용) 최근 3개월만의 로그만 ES에 저장하고 있습니다.
  164. 특정 유형의 로그 검색도 가능 게임 플레이 로그도 ES에 저장하여

    Kibana에서 조회할 수 있도록 사용하고 있습니다.
  165. 특정 플레이어의 최근 플레이 로그 검색 다음 영상은 저의 최근

    게임 플레이 로그를 검색하는 모습입니다.
  166. 수집 파이프라인 게임서버 Fluentd S3 Lambda ES Lambda Kinesis 이렇게

    저희 수집 파이프라인을 다시 요약해보면
  167. 수집 파이프라인 게임서버 Fluentd S3 Lambda ES Lambda Kinesis 두

    개의 Lambda를 통해 S3와 Elasticsearch로 저장되는 것으로 정리할 수 있습니다.
  168. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 전체적으로 Apache

    Spark와 Apache Zeppelin을 사용하고 있습니다.
  169. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 컴퓨팅 엔진

    DataPipeline Apache Spark는 클러스터 컴퓨팅 엔진으로
  170. 분석 클러스터 S3 Zeppelin Spark AWS EMR 대화식 인터프리터 +

    쉬운 시각화 DataPipeline Zeppelin은 이런 Spark를 대화식 인터프리터에서 사용하게 해주고
  171. 분석 클러스터 S3 Zeppelin Spark AWS EMR 대화식 인터프리터 +

    쉬운 시각화 DataPipeline 결과를 시각화하는 용도로 사용하고 있고요.
  172. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 구성 DataPipeline

    이러한 Spark와 Zeppelin의 클러스터를 구성하는 데에
  173. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 구성 DataPipeline

    EMR이라는 서비스를 사용하고 있습니다.
  174. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 배치잡 구성

    그리고 여기 옆에 DataPipeline은 배치잡을 구성하는 데 사용하고있습니다.
  175. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 Apache Spark는 클러스터 컴퓨팅 엔진인데요.
  176. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 이전에 Hadoop에서 디스크 기반으로 수행하던 MapReduce 작업을
  177. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! Spark에서는 메모리에서 처리하기 때문에
  178. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 빠른 속도라는 장점을 가지고 있습니다.
  179. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 다양한 언어를 지원하기도 하고
  180. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 데이터에 대하여 SQL을 사용할 수 있는 SparkSQL 모듈과
  181. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 머신러닝 라이브러리, 스트리밍 모듈 등 여러가지 모듈을 지원하는데
  182. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 클러스터 컴퓨팅 엔진이라고 소개해 드리긴 했지만
  183. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java

    언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 범용 분산 플랫폼이 맞는 표현입니다.
  184. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() 나이가 21세

    이상인 사람들에 대한 로그를 카운트하는 예제입니다.
  185. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() Spark에서 저희가

    주로 사용하는 데이터 프레임이라는 데이터 구조를 사용한 코드인데요.
  186. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    Zeppelin 대화식 분석이 가능한 웹 기반 노트북 다음으로는 이런 Spark 사용을 쉽게해주는 Apache Zeppelin입니다.
  187. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    Zeppelin 대화식 분석이 가능한 웹 기반 노트북 대화식 분석이 가능하기 때문에
  188. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    Zeppelin 대화식 분석이 가능한 웹 기반 노트북 파이썬으로 데이터 분석하시는 분들께서 많이 사용하시는 Jupyter notebook 처럼
  189. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    Zeppelin 대화식 분석이 가능한 웹 기반 노트북 파라미터를 바꿔가면서 결과를 보면서 작업을 이어갈 수 있고
  190. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 다양한 인터프리터를 사용할 수 있기 때문에
  191. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 Spark 인터프리터부터, 각종 언어들, JDBC 등 여러 가지를 연동하여 사용할 수 있습니다.
  192. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 마지막으로 가장 유용하다고 생각하는 기능 중 하나인 시각화인데요.
  193. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin

    → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 별다른 처리 없이도 결과에 따라서 잘 알아서 시각화를 해줍니다.
  194. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR 이렇게 Apache Spark와 Apache Zeppelin의 클러스터를 구성하는 데에는
  195. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR AWS의 EMR 서비스를 사용하고 있습니다.
  196. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin Spark 클러스터를 클릭 몇 번으로 쉽게 구성가능하고
  197. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 여기에 Zeppelin도 같이 구성할 수 있습니다.
  198. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 게다가 AWS에서 유휴자원을 싼 가격에 사용할 수 있는
  199. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 스팟 인스턴스도 사용가능한데요.
  200. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 도쿄 리전 r4.4xlarge 기준으로 4분의 1가격에 사용가능합니다.
  201. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 또한 쉽게 확장 및 축소가 가능하다는 것도 장점입니다.
  202. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 아주 단순하게 생각했을 때
  203. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 10개 인스턴스로 5분동안 처리하는 것과
  204. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 1개 인스턴스로 50분동안 처리하는 것이
  205. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 비용 만약 같은 비용이라면
  206. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 •

    쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 비용 당연히 많은 인스턴스로 짧은 시간 동안 처리하는 게 훨씬 이득이겠죠.
  207. 정기적인 배치 잡은 어떻게 실행하나요? 하지만 정기적으로 필요한 분석을 위한

    배치잡은 어떻게 실행하는 지 궁금하실 수 있는데요.
  208. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료

    시 클러스터 반납 하지만 Zeppelin은 실패시 자동으로 재시도하거나
  209. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료

    시 클러스터 반납 완료 시 인스턴스를 반납하는 것과 같은 동작은 할 수 없기 때문에
  210. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료

    시 클러스터 반납 Ad-hoc 분석용으로만 사용 저희는 Zeppelin을 Ad-hoc 분석용으로만 사용하고 있습니다.
  211. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 이렇게 저희의

    분석 클러스터가 어떻게 구성되었는지 말씀드렸는데요.
  212. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES Zeppelin Spark

    AWS EMR DataPipeline 다음과 같이 표현될 수 있습니다.
  213. S3 Lambda Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd

    Lambda Kinesis ES 5초 이내 1. 로그를 확인하기 까지 로그를 확인하는 데 까지 5초 이내로 확인할 수 있고
  214. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임

    서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 만약 로그 유입량이 증가하더라도
  215. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임

    서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 Kinesis의 샤드 개수만 증가시키면 됩니다.
  216. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임

    서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 아, Fluentd는 저희 같은 경우 아까 말씀드렸다시피
  217. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임

    서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 각각의 호스트에 하나씩 존재하므로 호스트 개수만큼 알아서 확장하는 구조입니다.
  218. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외)
  219. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 여기서 잠시 로그 수집 파이프라인의 비용을 살펴보면
  220. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 만약에 초당 1000개의 로그가 지속적으로 유입되고
  221. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 초당 2MB정도 유입된다고 가정하면
  222. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 월 5TB정도의 로그가 발생하는데요.
  223. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 이 때 최소로 필요한 Kinesis 샤드 2개와
  224. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 데이터를 기록하는 비용, Lambda에서 처리하는 비용을 모두 합쳐도
  225. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 월 110달러 정도의 유지 비용이 발생합니다.
  226. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각

    로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 물론 이건 저장비용을 제외하고, 최소로 맞춘 스펙이니 참고만 부탁드립니다.
  227. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES DataPipeline 4.

    빠르게 분석하고 싶을 때 확장 포인트 Zeppelin Spark AWS EMR 분석을 빠르게 하고 싶을 때는
  228. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES DataPipeline 4.

    빠르게 분석하고 싶을 때 확장 포인트 Zeppelin Spark AWS EMR EMR 클러스터만 확장해주면 됩니다.
  229. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge

    X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = $1 미만 → 10분 = 약$1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 만약 대규모 분석을 위해서
  230. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge

    X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = $1 미만 → 10분 = 약$1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 도쿄 리전을 기준으로 r4.8xlarge 타입의 인스턴스를 스팟 인스턴스로 10개를 띄우고
  231. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge

    X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = $1 미만 → 10분 = 약$1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 분석이 끝나는 즉시 종료한다면
  232. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge

    X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = $1 미만 → 10분 = 약$1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 보시는 바와 같이 시간과 비용을 최대한 절감할 수 있습니다.
  233. 게임 서버 Fluentd S3 Lambda Lambda ES Zeppelin Spark AWS

    EMR DataPipeline Kinesis 확장 포인트 Kinesis 샤드 개수는 어떻게 결정하나요? 첫 번째로, 방금 로그 유입량이 늘어나면
  234. 게임 서버 Fluentd S3 Lambda Lambda ES Zeppelin Spark AWS

    EMR DataPipeline Kinesis 확장 포인트 Kinesis 샤드 개수는 어떻게 결정하나요? Kinesis의 샤드개수를 늘리면 된다고 말씀드렸는데요.
  235. • 샤드의 처리량 제한 • Lambda의 처리속도 Kinesis 샤드 개수는

    어떻게 결정하나요? 사실 이 Kinesis 샤드 개수를 결정하기 위해
  236. • 샤드의 처리량 제한 • Lambda의 처리속도 Kinesis 샤드 개수는

    어떻게 결정하나요? 고려해야 할 두 가지가 있습니다.
  237. Kinesis 샤드 개수는 어떻게 결정하나요? • 샤드의 처리량 제한 •

    Lambda의 처리속도 샤드 하나에 초당 처리할 수 있는 처리량 제한이 있고요.
  238. Kinesis 샤드 개수는 어떻게 결정하나요? • 샤드의 처리량 제한 •

    Lambda의 처리속도 또한 Lambda의 처리속도를 고려해야합니다.
  239. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과

    Lambda가 레코드를 받은 시간차이 이 그래프는 Lambda의 Iterator age라는 메트릭입니다.
  240. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과

    Lambda가 레코드를 받은 시간차이 Lambda가 가장 최근에 처리한 레코드의
  241. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과

    Lambda가 레코드를 받은 시간차이 Kinesis에 실제로 처음 기록된 시간과
  242. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과

    Lambda가 레코드를 받은 시간차이 Lambda가 이 레코드를 처리하기 위해 이벤트를 받은
  243. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과

    Lambda가 레코드를 받은 시간차이 시간 차이인데요.
  244. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 결국 Kinesis에 데이터가 들어오는 속도보다
  245. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda의 처리속도가 느리면
  246. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 메트릭이 계속 상승곡선을 이루게 됩니다.
  247. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 여기서 Lambda는 이벤트가 일어나는 만큼 자동으로 확장하지 않느냐?라고 생각하실 수 있는데요.
  248. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda를 일반적인 사용예인 API형태로 사용할 때와 Kinesis를 트리거할 때는
  249. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에

    기록된 시간과 Lambda가 레코드를 받은 시간차이 다른 동작 형태를 보입니다.
  250. Shard 1 Kinesis Lambda Shard 2 Shard 3 예를 들어

    Kinesis에 3개의 샤드가 존재하고
  251. Shard 1 Kinesis Lambda Shard 2 Shard 3 Lambda가 이를

    트리거한다고 가정해보겠습니다.
  252. Shard 1 Kinesis Lambda Shard 2 Shard 3 보통은 Kinesis의

    샤드에는 랜덤하게 데이터가 분배되는데
  253. Shard 1 Kinesis Lambda Shard 2 Shard 3 ! Lambda는

    “아! 이번 샤드에 데이터가 들어왔구나!”하고
  254. Shard 1 Kinesis Lambda Shard 2 Shard 3 ! 이

    것을 처리하려고 하는데요.
  255. Shard 1 Kinesis Lambda Shard 2 Shard 3 이때 Lambda는

    1번 샤드의 데이터를 처리합니다.
  256. Shard 1 Kinesis Lambda Shard 2 Shard 3 더 이상

    Lambda가 실행되지 않고요.
  257. Shard 1 Kinesis Lambda Shard 2 Shard 3 그리고 다시

    3번 샤드에 데이터가 들어오면
  258. Shard 1 Kinesis Lambda Shard 2 Shard 3 만약 3개의

    샤드에 동시에 데이터가 들어오면
  259. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 만약 지속적으로 데이터가 들어오는 상황에서는
  260. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 각각의 샤드에 대해서 1초마다 동기적으로 배치처리를 하게 됩니다.
  261. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 샤드 개수 증가 Lambda 동시실행 결국 Lambda는 최대 Kinesis의 샤드개수만큼
  262. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 샤드 개수 증가 Lambda 동시실행 동시실행이 될 수 있기 때문에
  263. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 샤드 개수 증가 Lambda 동시실행 Kinesis의 샤드 개수를 증가시키는 것은
  264. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다

    배치 처리 샤드 개수 증가 Lambda 동시실행 Lambda의 동시실행 수를 높일 수 있다는 것을 의미합니다.
  265. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) 여기서 Lambda의 처리속도를 높이는 방법을 정리해보면
  266. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Kinesis의 샤드 개수를 증가시켜서 Lambda의 동시 실행 수를 늘리는 방법이 있고
  267. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Lambda는 설정된 메모리 크기에 따라
  268. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) CPU 성능이 조절되기 때문에
  269. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Lambda의 가용 메모리를 증가시켜서 CPU 성능을 높이는 방법이 있습니다.
  270. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) 하지만 저희의 경우 CPU 보다는
  271. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드

    개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) I/O에 인텐시브하기 때문에 두 번째 방법은 배제하고 있습니다.
  272. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 이제 저희가 로그를 어떻게 저장하는 지 말씀드리려고 합니다.
  273. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 저희는 아이템 구조 등 복잡한 게임시스템으로
  274. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 보다 유연한 로그 스키마가 필요했고
  275. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 때문에 JSON 형식으로 로그를 저장하고 있습니다.
  276. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그

    스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 여기서 Lambda는 최대 1000개의 로그를 하나의 파일로 저장하는데요.
  277. 엄청나게 많은 파일 개수 → 네트워크 오버헤드 로그파일 포맷: JSON

    • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 사실 이런 저장방식은 엄청나게 많은 파일을 생성시키고
  278. 엄청나게 많은 파일 개수 → 네트워크 오버헤드 로그파일 포맷: JSON

    • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 결국 분석 시에 네트워크 오버헤드를 유발하게 됩니다.
  279. { "type":"ItemPurchased", "seller_id":"1a2b3c4d5e6f", "@time":"2018-04-24T……", "item":{ "level":12, "durability":1234, "tags":{ ... },

    } ... } JSON 실제 저희 로그 형태를 보면 중첩된 데이터 구조로 이루어져 있는데
  280. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩

    데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Parquet 파일 형식에 대해서 소개해드리면
  281. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩

    데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 먼저 스키마를 가진 컬럼형 저장 포맷이라고 말씀드릴 수 있습니다.
  282. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩

    데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 또한 구조화된 포맷임에도 불구하고
  283. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩

    데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 복잡한 중첩데이터 구조도 지원하고요.
  284. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장

    포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 기본적으로 Snappy 형식의 압축을 하고있고
  285. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장

    포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Column projection, Predicate Pushdown 기능을 제공합니다.
  286. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장

    포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Snappy 압축과 아래 두가지 기능은
  287. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장

    포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 네트워크 트래픽을 감소 시킬 수 있습니다.
  288. Column projection 4월 1일에 접속한 레벨 60의 플레이어 수 SELECT

    COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 4월 1일에 접속한 레벨 60의 플레이어 수를 추출하는 쿼리를 예제로 들 수 있습니다.
  289. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53]

    쿼리에 실제로 필요한 플레이어 아이디와, 레벨, 날짜만 스캔하는 것을 알 수 있습니다.
  290. Table Partitioning • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>'

    형태로 분리 여기에 테이블 파티셔닝이라는 기능을 이용하면
  291. Table Partitioning → 네트워크 트래픽 감소 • 데이터 스캔 범위를

    제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 추가적으로 네트워크 트래픽을 감소시킬 수 있습니다.
  292. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔

    범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 여러 가지 방법이 있긴 하지만
  293. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔

    범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 저장경로에 Key=Value 형태로 중간 경로를 지정하는 형태로 사용할 수 있습니다.
  294. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔

    범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 실제로 저희는 날짜별로 파티셔닝을 하고 있는데
  295. Table Partitioning SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60

    아까와 같이 4월 1일에 접속한 레벨이 60인 플레이어 수를 구하는 예제에서
  296. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 실제 컬럼처럼

    사용가능 Table Partitioning WHERE __date="2018-04-01" s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> 아까 저장경로 상에서 지정한 date라는 파티션을
  297. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 실제 컬럼처럼

    사용가능 Table Partitioning WHERE __date="2018-04-01" s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> 실제 컬럼처럼 사용가능하고요.
  298. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 쿼리 플랜에서

    동작을 확인할 수 있다. Table Partitioning PartitionFilters: [isnotnull(__date#53), (cast(__date#53as string)=2018-04-01)] 쿼리플랜에서도 다음과 같이 파티션 필터가 동작하면서
  299. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 쿼리 플랜에서

    동작을 확인할 수 있다. Table Partitioning PartitionFilters: [isnotnull(__date#53), (cast(__date#53as string)=2018-04-01)] date가 4월 1일인 파티션을 필터링하는 것을 볼 수 있습니다.
  300. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 쿼리 플랜에서

    동작을 확인할 수 있다. Table Partitioning PartitionFilters: [isnotnull(__date#53), (cast(__date#53as string)=2018-04-01)] 실제로 해당되는 파티션의 데이터만 S3에서 읽기 때문에
  301. SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 쿼리 플랜에서

    동작을 확인할 수 있다. Table Partitioning PartitionFilters: [isnotnull(__date#53), (cast(__date#53as string)=2018-04-01)] 훨씬 네트워크 트래픽을 감소시킬 수 있습니다.
  302. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 다음은 로그 스키마 관리인데요.
  303. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 결국은 JSON에서 Parquet로 구조화된 데이터 유형을 사용하기 때문에
  304. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 로그 스키마 관리가 필요합니다.
  305. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 먼저 저희는 접속로그, 채집로그 등
  306. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 로그 유형별로 스키마를 가지고 있습니다.
  307. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 새롭게 컨텐츠가 들어갈 때 새로운 스키마를 쉽게 추가할 수 있지만
  308. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 기존에 존재하는 스키마를 변경할 땐
  309. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 약간 제한되는 것들이 있습니다.
  310. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 약간 제한되는 것들이 있습니다.
  311. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 예를 들어, 컬럼 이름을 바꾼다고 하면
  312. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 이미 적재되어 있는 모든 로그에 대하여
  313. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 새로운 컬럼 이름으로 바꿔서 다시 저장하는 마이그레이션 비용이 매우 크기 때문입니다.
  314. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. → 컬럼 추가만 가능! 하위호환성을 유지하여야 한다. 때문에 저희는 컬럼 추가만 가능하게 하여
  315. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그,

    채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. → 컬럼 추가만 가능! 하위호환성을 유지하여야 한다. 하위호환성을 유지하는 정책을 두고 있습니다.
  316. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 저희는 서버 코드 상에서 로그 스키마를 관리하는데요.
  317. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 스키마 별로 클래스가 존재하고
  318. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 이 클래스로부터 데이터를 담은 객체를 생성하여 로그를 전송합니다.
  319. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 새로운 버전 배포 시에
  320. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 각각의 스키마 별로
  321. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 SparkSQL에서 StructType이라는 클래스에서 다루는 JSON 포맷으로 스키마를 추출하고
  322. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 이 것을 따로 특정 S3 버킷에 저장합니다.
  323. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 그리고 JSON 파일을 Parquet로 변환하는 배치잡에서는
  324. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 아까 저장했던 스키마 중 가장 최근 버전의 스키마를 읽고 처리하는데요.
  325. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 스키마 저장소를 따로 관리하기 때문에
  326. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 새로 추가된 스키마에 대해서도
  327. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트

    2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 별다른 처리 없이 배치잡에서 알 수 있습니다.
  328. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark
  329. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark JSON으로된 로그를 Parquet로 변환시
  330. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 보시는 코드와 같이 JSON으로된 스키마 파일을 로드하여
  331. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark StructType 객체를 생성하고
  332. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark JSON 로그의 스키마를 지정하고 있습니다.
  333. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 물론 JSON 로그로 부터 스키마를 추론할 수 있기도 하지만
  334. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 성능이 느려지고
  335. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 명시적인 것이 훨씬 좋다는 판단 하에
  336. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드

    1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 스키마를 따로 정의하고 관리하는 방법을 사용하고 있습니다.
  337. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 다음으로는 EMR에서 Spark 클러스터를 할당하는 팁인데요.
  338. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 인 메모리 방식이기 때문에 많은 메모리가 필요할 수 있어서
  339. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 메모리 최적화 타입인 r4 타입을 선호하고 있습니다.
  340. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 또한 작은 인스턴스 여러 개 보다는
  341. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 큰 인스턴스 하나를 사용하고 있는데
  342. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 그 이유는 좋은 인스턴스일수록
  343. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 AWS에서 더 높은 네트워크 속도를 제공하고 있고
  344. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 EMR에서 Spark를 사용할 때
  345. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 YARN이라는 리소스 매니저를 사용하는데
  346. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호

    • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 이 때 YARN 컨테이너에 할당하는 메모리 비율이 더 크기 때문입니다.
  347. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 먼저 분석의 대중화가 어려웠습니다.
  348. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 분석에 대한 수요는 많지만 분석가는 언제나 부족합니다.
  349. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 때문에 비 개발자도 분석하기 쉬웠으면 이라는 생각도 하는데요.
  350. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 사실 이런 점을 위해서 나름 간단한 분석은 쉽게 할 수 있도록
  351. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 SQL을 사용할 수 있는 것을 목표로 하였습니다만
  352. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 •

    SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 사실상 대중화는 쉽지 않았습니다.
  353. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석

    규모에 따른 오토 스케일링 또한 분석 규모에 따라 오토 스케일링이 되었으면 좋겠다라는 생각을 했습니다.
  354. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석

    규모에 따른 오토 스케일링 비용을 좀 더 효과적으로 절감하고
  355. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석

    규모에 따른 오토 스케일링 시간을 효율적으로 사용할 수 있었으면 하는 바람이 있습니다.
  356. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. •

    Zeppelin으로는 아직 제한적 한편으로는 Zeppelin에만 시각화에 대한 상당부분을 의존하고 있기 때문에
  357. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. •

    Zeppelin으로는 아직 제한적 복잡한 시각화의 경우
  358. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. •

    Zeppelin으로는 아직 제한적 Jupyter notebook에서 따로 시각화하고 있는데요.
  359. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. •

    Zeppelin으로는 아직 제한적 이 부분도 아직은 아쉬움으로 남고 있습니다.
  360. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능

    • 오직 컬럼 추가만 가능 세 번째는 아까 말씀드렸던 로그 스키마 변경입니다.
  361. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능

    • 오직 컬럼 추가만 가능 쉽게 스키마를 추가할 수 있고
  362. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능

    • 오직 컬럼 추가만 가능 컬럼 추가도 자유롭지만
  363. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능

    • 오직 컬럼 추가만 가능 컬럼 이름을 바꿀 수 없다는 것이
  364. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능

    • 오직 컬럼 추가만 가능 의외로 시간이 지나면서 불편을 초래하고 있습니다.
  365. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 마지막으로 컨텐츠가 추가되거나
  366. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 남겨야 할 정보들이 더 많아지고 하면서
  367. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 스키마 개수도 100개가 넘고
  368. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 컬럼도 계속 추가되고 있는데요.
  369. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 어떤 컬럼이 정확히 무엇을 의미하는 지에 대해
  370. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 직접 코드를 보아야 알 수 있는 경우도 있었습니다.
  371. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 이 것은 결국 문서가 없기 때문에 발생하는 현상인데요.
  372. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 → Docstring을 이용한 스키마 문서화? 스키마 별로 클래스를 정의하고 있기 때문에
  373. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두

    기억하지 못함 • 문서가 없기 때문에 발생하는 현상 → Docstring을 이용한 스키마 문서화? Docstring을 이용해서 스키마를 문서화하는 방법을 고안 중입니다.
  374. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포

    이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 듀랑고의 서버에 관련된 발표로
  375. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포

    이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 내일과 내일 모레에도 세션들이 준비되어있으니
  376. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포

    이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 관심있는 분들은 많은 참석바랍니다.