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

NDC18에서 발표하였습니다.

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

Transcript

1. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유
2. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 안녕하세요.
3. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기를 주제로 발표하게 된
4. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 전효준입니다.
5. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 많은 분들이 찾아와주셨는데 이렇게 시간내어 찾아와주셔서 감사드립니다.
6. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 제 소개를 먼저 드리자면
7. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 왓 스튜디오의 백엔드 엔지니어이고요.
8. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전 경력이라고 하면
9. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 2개의 스타트업을 거쳐서 넥슨에 입사하게 되었고
10. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 직전에는 버즈니라는 회사의 데이터 인프라팀에서
11. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 로그 시스템을 개발하고 운영한 경험이 있습니다.
12. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 스튜디오에서는 자료공이라고 불리기도 하는데요.
13. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전에 이런 종이로 된 명패를 받았었는데
14. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 여기에 자료공 내정자라고 써있더라고요.
15. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 자료공 = 데이터 엔지니어 전효준 devin@nexon.co.kr 이 자료공은 저희가 흔히 말하는 데이터 엔지니어를 한글로 표현한 것 입니다.
16. 152,402,774 시작하기에 앞서 저희 듀랑고의 재미있는 통계 중 하나를 뽑아보았습니다.
17. 152,402,774 과연 이 숫자가 의미하는 것은 무엇일까요?
18. 152,402,774 네 1억 5천이라는 숫자는 바로
19. 152,402,774 현재까지 제작된 꼬치구이 개수 현재까지 듀랑고에서 제작된 꼬치구이의 개수입니다.
20. 152,402,774 현재까지 제작된 꼬치구이 개수 꼬치구이라고 하면 듀랑고에서 가장 기본적으로 할 수 있는 요리인데요.
21. 152,402,774 현재까지 제작된 꼬치구이 개수 엄청나게 많은 수의 꼬치구이가 제작된 것을 알 수있습니다.
22. 327 또 하나 좀더 재미있는 통계가 있는데요.
23. 327 이 327이라는 숫자는 바로
24. 327 가죽장화를 먹은 플레이어 수 현재까지 가죽장화를 먹은 플레이어의 수입니다.
25. 327 가죽장화를 먹은 플레이어 수 아시는 분들도 있겠지만 2014년 NDC에서
26. 327 가죽장화를 먹은 플레이어 수 “가죽 장화를 먹게 해주세요” “가죽 장화를 먹게 해달라니”라는 주제로
27. 327 가죽장화를 먹은 플레이어 수 이정수님과 최호영님의 NDC 발표가 있었는데
28. 327 가죽장화를 먹은 플레이어 수 보시다시피 실제로도 가죽 장화를 먹은 유저분들이 있었습니다.
29. 로그 네, 어쨌든 이런 통계를 뽑기위해 필요한 것들이 바로 로그인데요.
30. 로그 간단하게는 DAU, 리텐션부터 유저들이 어떤 구간에서 이탈하는 지와 같은
31. 로그 많은 것들을 알 수 있습니다.
32. (론칭이후 약 3개월간) 110 TB 지금 앞에 보시는 숫자는 저희가 론칭 이후 약 3개월간 적재한 로그의 양입니다.
33. (론칭이후 약 3개월간) 110 TB 꽤 많은 로그를 모두 적재하고 있고,
34. (론칭이후 약 3개월간) 110 TB 이 것들을 잘 다룰 수 있는 로그 시스템을 구축하고 있습니다.
35. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 이쯤에서 듀랑고의 로그 시스템을 간단히 소개드리면
36. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB 먼저 저희는 보여드린 것과 같이 로그들을 버리지 않고 수집하고 적재하고 있고
37. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 로그가 발생하고 나서 대략 5초 이내에 조회하고 검색할 수 있습니다.
38. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 이런 단순 조회나 검색이 아닌 대규모의 로그도 빠르게 분석 가능하고
39. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 별다른 조작 없이도 시각화할 수 있습니다.
40. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 관리부담을 최소화하였는데
41. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 → 혼자서도 여유롭게 때문에 저 혼자서도 여유롭게 로그 시스템을 운영할 수 있습니다.
42. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 오늘 발표는 이런 로그 시스템에 대하여 발표를 할 텐데요.
43. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 저희가 로그를 쌓아서 어떻게 사용하고 있는지
44. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 이렇게 사용하기 위해 어떤 것을 목표로 잡았고
45. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그 목표를 달성하기 위해 어떻게 아키텍처를 구성하였는지
46. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그리고 이런 아키텍처에서 각각의 요소들을 ‘잘’ 사용하는 방법들을 소개하고
47. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 개선할 점들을 이야기하며 마무리할 예정입니다.
48. #1 로그는 쌓아서 뭐하나 먼저 로그시스템이 왜 필요한지, 로그는 왜 쌓고 있는지를 말씀 드리고자 합니다.
49. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 첫 번째로 서비스 운영을 위해 로그 조회가 필요한데요.
50. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 그 예로 “아이템이 없어졌어요!” 라는 고객문의가 들어올 때가 있습니다.
51. 아이템이 없어졌어요! ” “ 서비스 운영을 위한 로그 조회 이런 문의가 들어오면 운영하는 입장에서는 확인절차를 거쳐야 하는데요.
52. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 실제로 유저가 아이템을 획득하였는지, 혹시나 다른 경로로 소비한 내역이 없는지 등
53. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 여러 가지를 확인하고 복구를 해야 하는데
54. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ” “ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 이 때 로그를 조회하여 확인절차를 거치게 됩니다.
55. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 다음으로는 각종 주요 지표를 추출하기 위함인데요.
56. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 실제로 DAU나, MAU, 리텐션 등
57. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 각종 지표나 통계를 추출하기 위한 기반 데이터로 사용하고 있습니다.
58. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 세 번째는 데이터 기반으로 의사결정을 하고 있기 때문입니다.
59. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 몇 가지 사례를 말씀드리면
60. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 섬 인구수 별 재방문율 지표를 보고 적정 인구수를 산정하기도 했고요.
61. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 유저분들의 플레이 유형을 클러스터링한 정보를 통해
62. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 업데이트 방향을 설정하는 지표로 삼기도 하였습니다.
63. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 그리고 이탈구간 분석 및 레벨별 활성 유저 수와 같은 정보를 기반으로
64. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 초반 가이드를 개선하기도 하였는데요.
65. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 이 초반가이드 개선에 대한 발표도 NDC 마지막날인 26일에 있으니
66. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 관심 있으신 분들은 참관하셔도 좋을 듯합니다.
67. 마지막으로 듀랑고를 하시면서 이런 오류 메시지를 보신 적이 있을 텐데요.
68. 자세히 보시면 여기에는 오류코드라는 것이 있습니다.
69. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 오류가 발생했을 때 분산된 게임서버에 하나하나 SSH로 접속하여
70. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 관련된 로그를 찾다가 결국 못 찾게 되는 상황이 있을 수 있습니다.
71. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 로그를 못 찾아서 원인파악을 빠르게 하지 못하면
72. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 이슈를 빠르게 대응할 수 없고 개발자들의 생산성이 떨어질 수 있겠죠
73. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 그래서 이 오류코드는 저희 서버의 시스템 로그를 조회하기 위한 것입니다.
74. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희 로그 시스템에서는 어떤 서버에서 어떤 에러가 발생하였는지,
75. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 어떤 경로로 호출되었는지 Python Traceback을 남기고 있습니다.
76. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희는 수많은 호스트들에서 발생하는 시스템 로그를 모두 수집하여 한 곳에 모으고 있고
77. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 결국 오류코드는 로그가 발생한 시점의 서버로그를 찾기 위한 단서라고 할 수 있습니다.
78. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 정리를 해보면 저희는 게임플레이 로그와 시스템 로그
79. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 크게 두 가지 종류의 로그를 수집하고 있는데요.
80. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 게임플레이 로그는 서비스 운영, 의사결정, 주요 지표 추출에 사용되고있고
81. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 시스템 로그는 개발자들의 생산성을 확대하고, 빠른 이슈 대응을 위해 수집하고 있습니다.
82. 우리의 지속적 발전을 위한 중요한 도구 결과적으로 이런 로그는 우리의 지속적 발전을 위한 중요한 도구로 사용되고 있는데요.
83. #2 로그 시스템의 목표 이런 로그를 수집하고 잘 활용하기 위한
84. #2 로그 시스템의 목표 로그 시스템의 목표를 한번 세워보았습니다.
85. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 먼저 로그 시스템의 요구사항들을 한번 살펴보겠습니다.
86. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 듀랑고는 복잡한 게임시스템을 가지고 있는데
87. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 자유도 높은 아이템 구조와 같은 특징으로
88. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 이는 곧 복잡한 로그 스키마 구조를 표현할 수 있어야 했습니다.
89. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 게임 플레이로그와 시스템 로그들을 모두 수집하다 보니
90. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 대규모 로그 발생을 감당할 수 있어야 했고
91. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 같은 맥락으로 대규모 분석도 가능해야 했습니다.
92. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 대규모 분석말고도 즉각적인 조회와 검색도 가능해야 했습니다.
93. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 하지만 이런 로그 시스템의 요구사항 외에
94. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 스키마의 변동이 없거나 높은 신뢰도가 요구되는 일부 로그들은
95. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 별도의 RDB를 사용했습니다.
96. → 이번 발표에서 RDB 로그는 다루지 않아요 하지만 이번 발표에서 RDB에 저장하는 로그에 대해서는 따로 다루지 않을 예정입니다.
97. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 앞서 이런 요구사항을 충족하는 로그시스템을 구축하기 위한 목표를 세워보았습니다.
98. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 목표는 총 4가지로
99. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 높은 가용성이 보장되어야 하고
100. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 실시간 조회가 가능해야 하며
101. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 분석 및 시각화가 가능해야 합니다.
102. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 그리고 관리부담을 최소화하는 것 입니다.
103. • 시스템이 죽으면 로그는 유실됨 높은 가용성 먼저 높은 가용성에 대하여 간단히 설명 드리자면
104. • 시스템이 죽으면 로그는 유실됨 높은 가용성 로그를 수집하고 저장하는 시스템이 죽으면
105. • 시스템이 죽으면 로그는 유실됨 높은 가용성 로그는 결국 유실될 수 있는데요.
106. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 로그가 유실되면
107. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 각종 지표를 오염시킬 수도 있고 운영에 차질이 생길 수 있습니다.
108. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 저 또한 힘들어질 수 있겠지요.
109. 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 높은 가용성 → 높은 가용성이 보장되어야 따라서 로그 시스템이 항상 잘 살아서 잘 돌아가도록 만들어야 했습니다.
110. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 두 번째로는 실시간 조회가 가능해야 한다는 것 입니다.
111. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 저장만 하고 원하는 로그를 찾을 수 없다면
112. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 사실 저장하는 의미가 없습니다.
113. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 반면에, 빠르게 로그를 찾을 수 있다는 건
114. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 그만큼 빨리 문제에 대응할 수 있는 생산성 향상을 의미합니다.
115. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 그래서 로그가 발생하고 부터
116. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 대략 5초 이내에 조회가 가능하길 원했습니다.
117. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회 5초 이내 추가로 원하는 로그만을 조회할 수 있도록 검색도 가능해야 했습니다.
118. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 또한 로그 시스템은 각종 분석 및
119. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 그 결과에 대한 시각화도 가능해야 했는데요.
120. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 대규모로 적재된 로그에 대해서도 빠르게 분석할 수 있어야 합니다.
121. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 마치 RDB에 적재한 것처럼 SQL도 가능한 것을 목표로 했고
122. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 여기서 분석 결과에 대한 그래프도
123. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 코드를 이용해서 직접 그리거나 엑셀에 옮겨서 그래프를 표현하는 것이 아닌
124. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 분석 결과를 보고 어느정도 알아서 그려줬으면 좋겠다는 생각을 했습니다.
125. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 마지막으로 저는 자료공의 역할만 하는 것이 아니기 때문에
126. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 관리부담의 최소화가 필요했습니다.
127. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 사실 하드웨어 이슈는
128. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 클라우드 서비스를 이용하면서 거의 탈출했다고 보아도 무방하지만
129. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 로그 유입량에 따라 시스템을 쉽게 확장하거나 축소할 수 있어야 했습니다.
130. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 결국, 종합해보면
131. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 알아서 잘 수집하고 빠르게 조회도하고 분석도할 수 있는 로그 시스템인데요.
132. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 정말 완벽하게 충족하진 못하더라도
133. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리가 감수할 수 있는 만큼은 만족하는 시스템이길 바랐습니다.
134. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리에겐 지속적으로 개선할 기회가 있기 때문이죠
135. #3 로그 시스템 아키텍처 결국 이렇게 로그 시스템을 개발하게 되었습니다.
136. #3 로그 시스템 아키텍처 저희 로그 시스템은 앞서 말씀드린 목표를 충족하기 위해
137. #3 로그 시스템 아키텍처 다양한 AWS 서비스와 오픈소스를 사용하였는데요.
138. #3 로그 시스템 아키텍처 이번에는 로그 시스템이 어떤 아키텍처로 구성되어 있는지 말씀드리려고 합니다.
139. 수집 조회 분석 로그 시스템을 수집, 조회, 분석으로 크게 3단계로 나누어 보았습니다.
140. 수집 먼저 로그를 서버에서 수집하고 이를 적재하는 과정까지의 수집단계 입니다.
141. 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd 로그를 수집하는 파이프라인은 보시는 바와 같이 구성되어 있습니다.
142. 로그 수집 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd 서버에서 로그가 발생하면 Fluentd에서 로그를 수집하고
143. 스트림에 전송 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd Fluentd는 Kinesis라는 거대한 스트림으로 전송을 하게 되고
144. 로그 처리 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd Lambda는 Kinesis에 들어오는 로그들을 처리하여
145. 저장 수집 파이프라인 게임서버 Kinesis Lambda S3 Fluentd S3에 저장하게 됩니다.
146. 게임서버 Fluentd 먼저 게임서버에서 Fluentd로 로그를 전송하는 부분입니다.
147. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd Fluentd는 오픈소스 데이터 수집기인데
148. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd 성능이 필요한 부분은 C언어로, 확장성이 필요한 부분은 Ruby로 구현되어 있어서
149. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Fluentd Fluentd 리소스 차지도 매우 적고 빠릅니다.
150. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 또한 다양한 플러그인을 가지고 있는데요.
151. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 앞서 보여드렸던 Kinesis에 로그를 전송할 수 있는 플러그인도
152. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd AWS에서 지원하고 있습니다.
153. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원 Fluentd Fluentd 마지막으로 비교적 간편하게 설정할 수 있다는 점도 장점이었습니다.
154. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
155. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
156. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
157. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 여러 개의 노드가 실행됩니다.
158. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 여기서 용어정리를 잠깐 하자면
159. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 호스트는 하나의 머신을 의미하고
160. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 노드는 각각의 프로세스를 의미합니다.
161. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 하나의 Fluentd가 존재해서 노드들의 로그를 수집하는데요.
162. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd 로그 수집 에이전트의 역할 Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 쉽게 말해서 로그 수집 에이전트의 역할을 하고있습니다.
163. Fluentd Kinesis Fluentd는 이렇게 수집한 로그를 Kinesis라는 곳에 넘기는데요.
164. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis 여기서 이야기하는 Kinesis는
165. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis AWS의 관리형 서비스중 하나인 Kinesis data stream을 의미합니다.
166. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 관리형 서비스이다 보니 높은 가용성이 보장되고
167. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 크게 관리할 것이 없습니다.
168. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 스트리밍 데이터를 저장하는 거대한 큐 역할을 하는데요.
169. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 물론 큐는 데이터를 완전히 꺼내버리지만
170. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 데이터를 삭제하지 않고 명시된 기간만큼 데이터를 보존합니다.
171. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 이 기간은 기본적으로 24시간 부터 최대 7일 인데요.
172. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 기간 동안은 데이터가 삭제되지 않기 때문에
173. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 만약 데이터를 처리하는 레이어에서 문제가 발생하더라도
174. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis Kinesis에는 아직 데이터가 남아있어서
175. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 언제든지 복구가 가능하다는 것을 의미합니다.
176. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 추가로 Kinesis에는 내부적으로 1개 이상의 샤드로 구성되는데
177. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 샤드가 무중단으로 확장 및 축소가 가능하고
178. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 것은 결국 로그 유입량에 따라
179. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 다운타임 없이 유연하게 대응 가능하다는 것을 의미합니다
180. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 실제로 이 확장 및 축소는
181. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 AWS 콘솔에서 클릭 2번으로도 가능하고
182. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 저희는 아직 적용하진 않았지만 오토 스케일링도 가능합니다.
183. Lambda Kinesis 이렇게 Kinesis에 데이터들이 들어오면
184. Lambda Kinesis Lambda는 Kinesis에 데이터가 들어왔다는 이벤트를 트리거하여
185. Lambda Kinesis 데이터를 가져와서 처리하는 역할을 합니다.
186. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 여기서 Lambda는 AWS에서 지원하는 서버리스 컴퓨팅 서비스입니다.
187. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 자동으로 확장하거나 축소하기도 하는데
188. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 때문에 저희가 따로 인프라를 관리할 필요가 없었습니다.
189. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 Lambda는 Kinesis의 이벤트를 트리거하여 쉽게 연동할 수 있기도 합니다.
190. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 이렇게 Lambda는 Kinesis의 데이터를 처리하여
191. Lambda S3 AWS의 저장소인 S3에 저장합니다.
192. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 실제로 비용만 감당할 수 있다면
193. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 무한대로 저장할 수 있는 AWS 스토리지 서비스이고
194. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전의 EC2에서 높은 전송속도를 보장합니다.
195. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 도쿄 리전에서 테스트한 결과 r4.4xlarge 기준으로 200MB/s 정도 나오더라고요.
196. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 그리고 높은 데이터 요청 빈도에 대하여 자동으로 확장하기도 합니다.
197. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 대규모 데이터를 업로드하거나 다운로드하더라도
198. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전에서는 데이터 전송 비용이 무료이기 때문에
199. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 트래픽에 따른 비용걱정은 하지 않아도 됩니다.
200. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 100퍼센트에 가까운 가용성과 내구성을 보장하고 있습니다.
201. 조회 여기까지가 저희의 로그 수집 파이프라인입니다.
202. 조회 다음으로는 로그를 조회하는 단계입니다.
203. Kinesis Lambda S3 방금 Kinesis에 들어온 로그 데이터를 Lambda가 S3에 저장하고 있다고 설명드렸는데요.
204. Kinesis Lambda S3 여기에는 사실 하나가 생략되어 있었습니다.
205. S3 Lambda ES Lambda Kinesis 저희 로그 시스템에는 하나의 Kinesis를
206. S3 Lambda ES Lambda Kinesis 두개의 Lambda가 트리거하고 있는데요.
207. S3 Lambda ES Lambda Kinesis 두 번째 Lambda는 Elasticsearch로 데이터를 insert하는 역할을 합니다.
208. S3 Lambda ES Lambda Kinesis 여기서 알 수 있는 것은
209. S3 Lambda ES Lambda Kinesis Kinesis는 내부적으로 Iterator Id라는 것으로 관리되고 있어서
210. S3 Lambda ES Lambda Kinesis 여러 개의 Lambda가 트리거할 수 있습니다.
211. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 물론 약간의 제한이 있는데요.
212. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) Kinesis에 최대 5개의 읽기 트랜잭션 제한때문인데
213. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 이것이 의미하는 건
214. S3 Lambda ES Lambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 사실상 하나의 Kinesis에 최대 5개의 Lambda만 안정적으로 트리거할 수 있다는 것 입니다.
215. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 다시 돌아와서, 저희는 실시간 조회를 위해 Elasticsearch를 사용하고 있습니다.
216. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 Lucene 기반의 분산 검색엔진이고
217. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 역 인덱스를 이용한 빠른 검색이 가능합니다.
218. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 그리고 Kibana라는 아주 유용한 시각화 플러그인을 제공합니다.
219. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 저희는 직접 구축할 수도 있지만
220. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 AWS에서 제공하는 Elasticsearch를 사용하는데요.
221. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 높은 가용성과 쉽게 확장이 가능하다는 장점이 있습니다.
222. ES 로그가 늘어날 수록 유지비용 증가 하지만 로그가 늘어날 수록
223. ES 로그가 늘어날 수록 유지비용 증가 Elasticsearch의 클러스터를 유지하기에는 비용이 점점 늘어날 수 밖에 없는데
224. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 때문에 저희는 빠르게 조회할 필요성이 있는
225. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 최근 3개월만의 로그만 ES에 저장하고 있습니다.
226. 이 것은 아까 보여드렸던 오류코드입니다.
227. 저희는 이것을 Elasticsearch의 시각화 도구인 Kibana에서 조회하고 있는데요.
228. 간단하게 오류코드를 검색하면 해당하는 로그를 찾을 수 있고
229. 로그가 발생한 호스트 host 로그가 발생한 호스트가 어디인지 알 수 있습니다.
230. 에러 메시지 message 에러메시지를 확인할 수 있고
231. Traceback exc_info 어떤 경로로 함수가 호출되었는 지
232. Traceback exc_info 스택 추적이 가능한 Python Traceback을 제공합니다.
233. 특정 유형의 로그 검색도 가능 실제로 “Timeout”과 같은 키워드로 검색하여
234. 특정 유형의 로그 검색도 가능 특정 유형의 로그 검색도 가능합니다.
235. 특정 유형의 로그 검색도 가능 예제로 보여드렸던 시스템 로그 조회 뿐만 아니라
236. 특정 유형의 로그 검색도 가능 게임 플레이 로그도 ES에 저장하여 Kibana에서 조회할 수 있도록 사용하고 있습니다.
237. 오류코드 검색 이 것은 실제로 저희가 Kibana를 통해 특정 오류코드를 검색하는 영상이고요.
238. 특정 플레이어의 최근 플레이 로그 검색 다음 영상은 저의 최근 게임 플레이 로그를 검색하는 모습입니다.
239. 수집 파이프라인 게임서버 Fluentd S3 Lambda ES Lambda Kinesis 이렇게 저희 수집 파이프라인을 다시 요약해보면
240. 수집 파이프라인 게임서버 Fluentd S3 Lambda ES Lambda Kinesis 결국 로그는 Fluentd와 Kinesis를 거쳐
241. 수집 파이프라인 게임서버 Fluentd S3 Lambda ES Lambda Kinesis 두 개의 Lambda를 통해 S3와 Elasticsearch로 저장되는 것으로 정리할 수 있습니다.
242. 분석 마지막으로 이렇게 S3에 적재한 로그를 분석하는 단계인데요.
243. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 전체적으로 Apache Spark와 Apache Zeppelin을 사용하고 있습니다.
244. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 컴퓨팅 엔진 DataPipeline Apache Spark는 클러스터 컴퓨팅 엔진으로
245. 분석 클러스터 S3 Zeppelin Spark AWS EMR 대화식 인터프리터 + 쉬운 시각화 DataPipeline Zeppelin은 이런 Spark를 대화식 인터프리터에서 사용하게 해주고
246. 분석 클러스터 S3 Zeppelin Spark AWS EMR 대화식 인터프리터 + 쉬운 시각화 DataPipeline 결과를 시각화하는 용도로 사용하고 있고요.
247. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 구성 DataPipeline 이러한 Spark와 Zeppelin의 클러스터를 구성하는 데에
248. 분석 클러스터 S3 Zeppelin Spark AWS EMR 클러스터 구성 DataPipeline EMR이라는 서비스를 사용하고 있습니다.
249. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 배치잡 구성 그리고 여기 옆에 DataPipeline은 배치잡을 구성하는 데 사용하고있습니다.
250. Zeppelin Spark AWS EMR 먼저 Spark와 Zeppelin, 그리고 이것을 구성하는 EMR에 대해서 말씀드리려고 합니다.
251. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 Apache Spark는 클러스터 컴퓨팅 엔진인데요.
252. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 이전에 Hadoop에서 디스크 기반으로 수행하던 MapReduce 작업을
253. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! Spark에서는 메모리에서 처리하기 때문에
254. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 빠른 속도라는 장점을 가지고 있습니다.
255. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 다양한 언어를 지원하기도 하고
256. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 데이터에 대하여 SQL을 사용할 수 있는 SparkSQL 모듈과
257. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 머신러닝 라이브러리, 스트리밍 모듈 등 여러가지 모듈을 지원하는데
258. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 클러스터 컴퓨팅 엔진이라고 소개해 드리긴 했지만
259. • 클러스터 컴퓨팅 엔진 • • Python, Scala, R, Java 언어지원 • 다양한 모듈 지원 (SparkSQL, MLlib 등) Apache Spark Spark 인 메모리 데이터 처리 → 빠르다! 범용 분산 플랫폼이 맞는 표현입니다.
260. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() 보고 계신 코드는 Spark에서 JSON 포맷의 로그를 읽고
261. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() 나이가 21세 이상인 사람들에 대한 로그를 카운트하는 예제입니다.
262. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() Spark에서 저희가 주로 사용하는 데이터 프레임이라는 데이터 구조를 사용한 코드인데요.
263. df = spark.read.json('logs.json') over_21 = df.where('age >= 21').count() 실제로 보시는 바와 같이 쉽게 사용할 수 있습니다.
264. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin Zeppelin 대화식 분석이 가능한 웹 기반 노트북 다음으로는 이런 Spark 사용을 쉽게해주는 Apache Zeppelin입니다.
265. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin Zeppelin 대화식 분석이 가능한 웹 기반 노트북 대화식 분석이 가능하기 때문에
266. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin Zeppelin 대화식 분석이 가능한 웹 기반 노트북 파이썬으로 데이터 분석하시는 분들께서 많이 사용하시는 Jupyter notebook 처럼
267. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin Zeppelin 대화식 분석이 가능한 웹 기반 노트북 파라미터를 바꿔가면서 결과를 보면서 작업을 이어갈 수 있고
268. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 다양한 인터프리터를 사용할 수 있기 때문에
269. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 Spark 인터프리터부터, 각종 언어들, JDBC 등 여러 가지를 연동하여 사용할 수 있습니다.
270. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 마지막으로 가장 유용하다고 생각하는 기능 중 하나인 시각화인데요.
271. • • 다양한 인터프리터 사용가능 • 쉬운 시각화 Apache Zeppelin → Spark! Zeppelin 대화식 분석이 가능한 웹 기반 노트북 별다른 처리 없이도 결과에 따라서 잘 알아서 시각화를 해줍니다.
272. SparkSQL 보시는 것은 실제 Zeppelin의 사용 모습입니다.
273. SparkSQL 이렇게 Spark SQL 쿼리로 분석할 수 있고 (쿼리 내용 중요하지 않음)
274. 다이나믹 폼 사용가능 실제 쿼리의 조건절에 들어가는 값을 다양하게 바꿀 수 있는 다이나믹 폼도 지원합니다.
275. 다양한 그래프 또한, 단순 테이블, 막대 그래프, 파이 그래프 등 여러 가지 그래프를 지원하고요.
276. CSV 다운로드 결과를 CSV로 다운로드할 수 있습니다.
277. 스케줄링 그리고 노트북을 특정 시간대에 자동으로 실행하도록
278. 스케줄링 스케줄링이 가능합니다.
279. 스케줄링 보시는 바와 같이 Cron Expression으로 자동실행 스케줄을 지정할 수 있습니다.
280. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR 이렇게 Apache Spark와 Apache Zeppelin의 클러스터를 구성하는 데에는
281. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR AWS의 EMR 서비스를 사용하고 있습니다.
282. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin Spark 클러스터를 클릭 몇 번으로 쉽게 구성가능하고
283. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 여기에 Zeppelin도 같이 구성할 수 있습니다.
284. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 게다가 AWS에서 유휴자원을 싼 가격에 사용할 수 있는
285. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 스팟 인스턴스도 사용가능한데요.
286. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 도쿄 리전 r4.4xlarge 기준으로 4분의 1가격에 사용가능합니다.
287. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 또한 쉽게 확장 및 축소가 가능하다는 것도 장점입니다.
288. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 아주 단순하게 생각했을 때
289. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 10개 인스턴스로 5분동안 처리하는 것과
290. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 1개 인스턴스로 50분동안 처리하는 것이
291. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 비용 만약 같은 비용이라면
292. • Spark 클러스터를 손쉽게 구성 • 스팟 인스턴스 사용가능 • 쉬운 확장 및 축소 AWS EMR EMR + Zeppelin 10개 인스턴스로 5분 1개 인스턴스로 50분 비용 당연히 많은 인스턴스로 짧은 시간 동안 처리하는 게 훨씬 이득이겠죠.
293. 정기적인 배치 잡은 어떻게 실행하나요? 하지만 정기적으로 필요한 분석을 위한 배치잡은 어떻게 실행하는 지 궁금하실 수 있는데요.
294. Zeppelin의 노트북 스케줄 기능 ? 여기서 아까 보셨던 Zeppelin의 노트북 스케줄 기능을 생각하실 수 있습니다.
295. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료 시 클러스터 반납 하지만 Zeppelin은 실패시 자동으로 재시도하거나
296. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료 시 클러스터 반납 완료 시 인스턴스를 반납하는 것과 같은 동작은 할 수 없기 때문에
297. Zeppelin의 노트북 스케줄 기능 ? 실패 시 자동 재시도 완료 시 클러스터 반납 Ad-hoc 분석용으로만 사용 저희는 Zeppelin을 Ad-hoc 분석용으로만 사용하고 있습니다.
298. DataPipeline 그 대안으로 AWS의 DataPipeline이라는 서비스를 사용하고 있습니다.
299. 보시는 것은 DataPipeline 서비스를 AWS 콘솔에서 봤을 때의 모습인데요.
300. 다이어그램을 간단히 설명드리면
301. 매일 00시에 매일 특정 시간에
302. 매일 00시에 클러스터를 실행하고 EMR 클러스터를 띄우고
303. 매일 00시에 클러스터를 실행하고 특정 Job을 수행해라 특정 Job을 수행해라라는 의미인데요.
304. 매일 00시에 클러스터를 실행하고 특정 Job을 수행해라 실제로 Job이 실패했을 때 재시도하거나
305. 매일 00시에 클러스터를 실행하고 특정 Job을 수행해라 실행이 끝났을 때 클러스터를 모두 종료할 수 있기 때문에
306. 매일 00시에 클러스터를 실행하고 특정 Job을 수행해라 비용을 절감할 수 있습니다.
307. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 이렇게 저희의 분석 클러스터가 어떻게 구성되었는지 말씀드렸는데요.
308. 분석 클러스터 S3 Zeppelin Spark AWS EMR DataPipeline 마지막으로 전체 아키텍처를 정리를 해보면
309. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES Zeppelin Spark AWS EMR DataPipeline 다음과 같이 표현될 수 있습니다.
310. S3 Lambda Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd Lambda Kinesis ES 5초 이내 1. 로그를 확인하기 까지 로그를 확인하는 데 까지 5초 이내로 확인할 수 있고
311. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 만약 로그 유입량이 증가하더라도
312. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 Kinesis의 샤드 개수만 증가시키면 됩니다.
313. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 아, Fluentd는 저희 같은 경우 아까 말씀드렸다시피
314. S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline 게임 서버 Fluentd 2. 로그 유입량이 증가하면? Kinesis 확장 포인트 각각의 호스트에 하나씩 존재하므로 호스트 개수만큼 알아서 확장하는 구조입니다.
315. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외)
316. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 여기서 잠시 로그 수집 파이프라인의 비용을 살펴보면
317. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 만약에 초당 1000개의 로그가 지속적으로 유입되고
318. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 초당 2MB정도 유입된다고 가정하면
319. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 월 5TB정도의 로그가 발생하는데요.
320. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 이 때 최소로 필요한 Kinesis 샤드 2개와
321. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 데이터를 기록하는 비용, Lambda에서 처리하는 비용을 모두 합쳐도
322. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 월 110달러 정도의 유지 비용이 발생합니다.
323. • 도쿄 리전 기준 • 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도) • Kinesis 샤드 2개 + 데이터 PUT 비용 • Lambda (처리시간 1초) → 약 $90 → 약 $20 3. Kinesis + Lambda 월 유지비용 → 월 $110 정도로 유지 비용(저장비용 제외) 물론 이건 저장비용을 제외하고, 최소로 맞춘 스펙이니 참고만 부탁드립니다.
324. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES DataPipeline 4. 빠르게 분석하고 싶을 때 확장 포인트 Zeppelin Spark AWS EMR 분석을 빠르게 하고 싶을 때는
325. 게임 서버 Fluentd S3 Lambda Lambda Kinesis ES DataPipeline 4. 빠르게 분석하고 싶을 때 확장 포인트 Zeppelin Spark AWS EMR EMR 클러스터만 확장해주면 됩니다.
326. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = ＄1 미만 → 10분 = 약＄1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 만약 대규모 분석을 위해서
327. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = ＄1 미만 → 10분 = 약＄1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 도쿄 리전을 기준으로 r4.8xlarge 타입의 인스턴스를 스팟 인스턴스로 10개를 띄우고
328. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = ＄1 미만 → 10분 = 약＄1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 분석이 끝나는 즉시 종료한다면
329. 5. 대규모 분석 비용 • 모든 로그에 대하여 • r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준 • 생성된 모든 섬의 개수 • 가장 많이 채집된 자원(10위까지) • 모든 섬의 날짜별 일일 활성 유저수 → 5분 = ＄1 미만 → 10분 = 약＄1 → 15분 = 약 $ 1.3 프로비저닝 시간 제외, 2018년 4월 24일 기준 보시는 바와 같이 시간과 비용을 최대한 절감할 수 있습니다.
330. #4 ‘잘’ 사용하기 다음으로는 이런 아키텍처에서
331. #4 ‘잘’ 사용하기 각각의 구성요소들을 잘 사용하기 위한 방법들을 말씀드리려고 합니다.
332. 게임 서버 Fluentd S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline Kinesis 확장 포인트 Kinesis 샤드 개수는 어떻게 결정하나요? 첫 번째로, 방금 로그 유입량이 늘어나면
333. 게임 서버 Fluentd S3 Lambda Lambda ES Zeppelin Spark AWS EMR DataPipeline Kinesis 확장 포인트 Kinesis 샤드 개수는 어떻게 결정하나요? Kinesis의 샤드개수를 늘리면 된다고 말씀드렸는데요.
334. • 샤드의 처리량 제한 • Lambda의 처리속도 Kinesis 샤드 개수는 어떻게 결정하나요? 사실 이 Kinesis 샤드 개수를 결정하기 위해
335. • 샤드의 처리량 제한 • Lambda의 처리속도 Kinesis 샤드 개수는 어떻게 결정하나요? 고려해야 할 두 가지가 있습니다.
336. Kinesis 샤드 개수는 어떻게 결정하나요? • 샤드의 처리량 제한 • Lambda의 처리속도 샤드 하나에 초당 처리할 수 있는 처리량 제한이 있고요.
337. Kinesis 샤드 개수는 어떻게 결정하나요? • 샤드의 처리량 제한 • Lambda의 처리속도 또한 Lambda의 처리속도를 고려해야합니다.
338. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 이 그래프는 Lambda의 Iterator age라는 메트릭입니다.
339. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda가 가장 최근에 처리한 레코드의
340. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 Kinesis에 실제로 처음 기록된 시간과
341. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda가 이 레코드를 처리하기 위해 이벤트를 받은
342. Lambda Iterator age 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 시간 차이인데요.
343. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 결국 Kinesis에 데이터가 들어오는 속도보다
344. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda의 처리속도가 느리면
345. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 메트릭이 계속 상승곡선을 이루게 됩니다.
346. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 여기서 Lambda는 이벤트가 일어나는 만큼 자동으로 확장하지 않느냐?라고 생각하실 수 있는데요.
347. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 Lambda를 일반적인 사용예인 API형태로 사용할 때와 Kinesis를 트리거할 때는
348. Lambda Iterator age 증가하면 안됨 가장 최근에 처리한 레코드가 Kinesis에 기록된 시간과 Lambda가 레코드를 받은 시간차이 다른 동작 형태를 보입니다.
349. Shard 1 Kinesis Lambda Shard 2 Shard 3 예를 들어 Kinesis에 3개의 샤드가 존재하고
350. Shard 1 Kinesis Lambda Shard 2 Shard 3 Lambda가 이를 트리거한다고 가정해보겠습니다.
351. Shard 1 Kinesis Lambda Shard 2 Shard 3 보통은 Kinesis의 샤드에는 랜덤하게 데이터가 분배되는데
352. Shard 1 Kinesis Lambda Shard 2 Shard 3 데이터가 1번 샤드에 하나 들어오면
353. Shard 1 Kinesis Lambda Shard 2 Shard 3 ! Lambda는 “아! 이번 샤드에 데이터가 들어왔구나!”하고
354. Shard 1 Kinesis Lambda Shard 2 Shard 3 ! 이 것을 처리하려고 하는데요.
355. Shard 1 Kinesis Lambda Shard 2 Shard 3 이때 Lambda는 1번 샤드의 데이터를 처리합니다.
356. Shard 1 Kinesis Lambda Shard 2 Shard 3 만약에 모든 데이터가 다 처리되면
357. Shard 1 Kinesis Lambda Shard 2 Shard 3 더 이상 Lambda가 실행되지 않고요.
358. Shard 1 Kinesis Lambda Shard 2 Shard 3 물론 여기서 데이터를 처리하더라도
359. Shard 1 Kinesis Lambda Shard 2 Shard 3 Kinesis에 데이터는 계속 보존되는데
360. Shard 1 Kinesis Lambda Shard 2 Shard 3 그림에서는 이해를 돕기 위해 없앴습니다.
361. Shard 1 Kinesis Lambda Shard 2 Shard 3 그리고 다시 3번 샤드에 데이터가 들어오면
362. Shard 1 Kinesis Lambda Shard 2 Shard 3 다시 이것을 처리하게 되겠죠.
363. Shard 1 Kinesis Lambda Shard 2 Shard 3 만약 3개의 샤드에 동시에 데이터가 들어오면
364. Shard 1 Kinesis Lambda Shard 2 Shard 3 Lambda는 3개 샤드만큼 동시실행하여
365. Shard 1 Kinesis Lambda Shard 2 Shard 3 각각의 샤드에 대해서 처리하게 됩니다.
366. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 만약 지속적으로 데이터가 들어오는 상황에서는
367. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 각각의 샤드에 대해서 1초마다 동기적으로 배치처리를 하게 됩니다.
368. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 샤드 개수 증가 Lambda 동시실행 결국 Lambda는 최대 Kinesis의 샤드개수만큼
369. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 샤드 개수 증가 Lambda 동시실행 동시실행이 될 수 있기 때문에
370. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 샤드 개수 증가 Lambda 동시실행 Kinesis의 샤드 개수를 증가시키는 것은
371. Shard 1 Kinesis Lambda Shard 2 Shard 3 1초 마다 배치 처리 샤드 개수 증가 Lambda 동시실행 Lambda의 동시실행 수를 높일 수 있다는 것을 의미합니다.
372. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) 여기서 Lambda의 처리속도를 높이는 방법을 정리해보면
373. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Kinesis의 샤드 개수를 증가시켜서 Lambda의 동시 실행 수를 늘리는 방법이 있고
374. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Lambda는 설정된 메모리 크기에 따라
375. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) CPU 성능이 조절되기 때문에
376. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) Lambda의 가용 메모리를 증가시켜서 CPU 성능을 높이는 방법이 있습니다.
377. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) 하지만 저희의 경우 CPU 보다는
378. Kinesis – Lambda 처리속도를 높이는 방법 1. Kinesis stream의 샤드 개수를 증가시킨다. 2. Lambda의 가용 메모리를 증가시킨다. (Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨) I/O에 인텐시브하기 때문에 두 번째 방법은 배제하고 있습니다.
379. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 이제 저희가 로그를 어떻게 저장하는 지 말씀드리려고 합니다.
380. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 저희는 아이템 구조 등 복잡한 게임시스템으로
381. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 보다 유연한 로그 스키마가 필요했고
382. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 때문에 JSON 형식으로 로그를 저장하고 있습니다.
383. 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 여기서 Lambda는 최대 1000개의 로그를 하나의 파일로 저장하는데요.
384. 엄청나게 많은 파일 개수 → 네트워크 오버헤드 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 사실 이런 저장방식은 엄청나게 많은 파일을 생성시키고
385. 엄청나게 많은 파일 개수 → 네트워크 오버헤드 로그파일 포맷: JSON • 복잡한 게임 시스템 → 복잡한 로그 스키마 • Lambda는 최대 1000개의 로그를 하나의 파일로 저장 (Kinesis 샤드의 초당 최대 쓰기 개수) 결국 분석 시에 네트워크 오버헤드를 유발하게 됩니다.
386. JSON → Parquet 때문에 저희는 JSON을 Parquet 형식의 파일로 가공하는데요.
387. JSON → Parquet 많은 수의 파일을 단지 몇 개로 분할된 Parquet 파일로 변환하고 있고
388. JSON → Parquet 이런 변환을 1시간 마다 배치잡으로 처리하고 있습니다.
389. { "type":"ItemPurchased", "seller_id":"1a2b3c4d5e6f", "@time":"2018-04-24T……", "item":{ "level":12, "durability":1234, "tags":{ ... }, } ... } JSON 실제 저희 로그 형태를 보면 중첩된 데이터 구조로 이루어져 있는데
390. Parquet 이런 중첩 데이터 구조를 모두 지원하면서도
391. Parquet 구조화된 형태를 가지는 Parquet 포맷으로 변환하게됩니다.
392. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Parquet 파일 형식에 대해서 소개해드리면
393. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 먼저 스키마를 가진 컬럼형 저장 포맷이라고 말씀드릴 수 있습니다.
394. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 또한 구조화된 포맷임에도 불구하고
395. Parquet • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 복잡한 중첩데이터 구조도 지원하고요.
396. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 기본적으로 Snappy 형식의 압축을 하고있고
397. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Column projection, Predicate Pushdown 기능을 제공합니다.
398. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown Snappy 압축과 아래 두가지 기능은
399. Parquet → 네트워크 트래픽 감소 • 스키마를 가진 컬럼형 저장 포맷 • 복잡한 중첩 데이터 구조도 지원 • 기본적으로 Snappy 압축 • Column projection • Predicate pushdown 네트워크 트래픽을 감소 시킬 수 있습니다.
400. Column projection 이 Column projection에 대해서 간단히 설명을 드리면
401. 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의 플레이어 수를 추출하는 쿼리를 예제로 들 수 있습니다.
402. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53] 이 쿼리의 플랜을 보면
403. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53] 쿼리에 실제로 필요한 플레이어 아이디와, 레벨, 날짜만 스캔하는 것을 알 수 있습니다.
404. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53] 결국 컬럼형 저장방식이기 때문에
405. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53] 쿼리에 필요한 컬럼만 스캔하여
406. Column projection 쿼리에 필요한 컬럼만 스캔 +- *FileScan parquet [player_entity_id#44,player_level#45,__date#53] 네트워크 트래픽을 낮출 수 있습니다.
407. Predicate pushdown 레벨 60인 데이터만 필터링 PushedFilteres: [IsNotNull(player_level), EqualTo(player_level,60)] 또 Predicate pushdown은 같은 예제로
408. Predicate pushdown 레벨 60인 데이터만 필터링 PushedFilteres: [IsNotNull(player_level), EqualTo(player_level,60)] 메타데이터에 저장된 통계값을 이용해
409. Predicate pushdown 레벨 60인 데이터만 필터링 PushedFilteres: [IsNotNull(player_level), EqualTo(player_level,60)] 레벨이 60인 데이터만 필터링하여 스캔합니다.
410. Predicate pushdown Column projection 이렇게 Column Projection과 Predicate pushdown을 활용하여
411. Predicate pushdown Column projection 최대한 필요한 데이터만 읽도록 하여
412. Predicate pushdown Column projection 네트워크 트래픽을 낮출 수 있는데요.
413. Table Partitioning • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 여기에 테이블 파티셔닝이라는 기능을 이용하면
414. Table Partitioning → 네트워크 트래픽 감소 • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 추가적으로 네트워크 트래픽을 감소시킬 수 있습니다.
415. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 여러 가지 방법이 있긴 하지만
416. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 저장경로에 Key=Value 형태로 중간 경로를 지정하는 형태로 사용할 수 있습니다.
417. Table Partitioning s3://<bucket>/<schema>/__date=<yyyy-mm-dd>/<filename> → 네트워크 트래픽 감소 • 데이터 스캔 범위를 제한가능 • 저장경로에 '<key>=<value>' 형태로 분리 실제로 저희는 날짜별로 파티셔닝을 하고 있는데
418. Table Partitioning SELECT COUNT(DISTINCT(player_entity_id)) FROM PlayerEntered_asia_a WHERE __date="2018-04-01" AND player_level=60 아까와 같이 4월 1일에 접속한 레벨이 60인 플레이어 수를 구하는 예제에서
419. 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라는 파티션을
420. 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> 실제 컬럼처럼 사용가능하고요.
421. 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)] 쿼리플랜에서도 다음과 같이 파티션 필터가 동작하면서
422. 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일인 파티션을 필터링하는 것을 볼 수 있습니다.
423. 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에서 읽기 때문에
424. 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)] 훨씬 네트워크 트래픽을 감소시킬 수 있습니다.
425. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 다음은 로그 스키마 관리인데요.
426. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 결국은 JSON에서 Parquet로 구조화된 데이터 유형을 사용하기 때문에
427. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 로그 스키마 관리가 필요합니다.
428. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 먼저 저희는 접속로그, 채집로그 등
429. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 로그 유형별로 스키마를 가지고 있습니다.
430. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 새롭게 컨텐츠가 들어갈 때 새로운 스키마를 쉽게 추가할 수 있지만
431. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 기존에 존재하는 스키마를 변경할 땐
432. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 약간 제한되는 것들이 있습니다.
433. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 약간 제한되는 것들이 있습니다.
434. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 예를 들어, 컬럼 이름을 바꾼다고 하면
435. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 이미 적재되어 있는 모든 로그에 대하여
436. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. 새로운 컬럼 이름으로 바꿔서 다시 저장하는 마이그레이션 비용이 매우 크기 때문입니다.
437. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. → 컬럼 추가만 가능! 하위호환성을 유지하여야 한다. 때문에 저희는 컬럼 추가만 가능하게 하여
438. 로그 스키마 관리 • 로그는 다양한 스키마를 가진다. • 접속로그, 채집로그, 구매로그 등 • 새로운 스키마는 언제든지 추가될 수 있어야 한다. • 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다. → 컬럼 추가만 가능! 하위호환성을 유지하여야 한다. 하위호환성을 유지하는 정책을 두고 있습니다.
439. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 저희는 서버 코드 상에서 로그 스키마를 관리하는데요.
440. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 스키마 별로 클래스가 존재하고
441. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 이 클래스로부터 데이터를 담은 객체를 생성하여 로그를 전송합니다.
442. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 새로운 버전 배포 시에
443. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 각각의 스키마 별로
444. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 SparkSQL에서 StructType이라는 클래스에서 다루는 JSON 포맷으로 스키마를 추출하고
445. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 이 것을 따로 특정 S3 버킷에 저장합니다.
446. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 그리고 JSON 파일을 Parquet로 변환하는 배치잡에서는
447. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 아까 저장했던 스키마 중 가장 최근 버전의 스키마를 읽고 처리하는데요.
448. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 스키마 저장소를 따로 관리하기 때문에
449. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 새로 추가된 스키마에 대해서도
450. 로그 스키마 업데이트 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 별다른 처리 없이 배치잡에서 알 수 있습니다.
451. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark
452. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark JSON으로된 로그를 Parquet로 변환시
453. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 보시는 코드와 같이 JSON으로된 스키마 파일을 로드하여
454. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark StructType 객체를 생성하고
455. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark JSON 로그의 스키마를 지정하고 있습니다.
456. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 물론 JSON 로그로 부터 스키마를 추론할 수 있기도 하지만
457. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 성능이 느려지고
458. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 명시적인 것이 훨씬 좋다는 판단 하에
459. 로그 스키마 업데이트 schema = StructType.fromJson(schema_json) Parquet 변환 시 로드 1. 스키마 별 Class 추가 또는 업데이트 2. 배포 시 Spark StructType JSON 포맷으로 추출 3. AWS S3에 저장 4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행 PySpark 스키마를 따로 정의하고 관리하는 방법을 사용하고 있습니다.
460. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 다음으로는 EMR에서 Spark 클러스터를 할당하는 팁인데요.
461. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 인 메모리 방식이기 때문에 많은 메모리가 필요할 수 있어서
462. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 메모리 최적화 타입인 r4 타입을 선호하고 있습니다.
463. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 또한 작은 인스턴스 여러 개 보다는
464. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 큰 인스턴스 하나를 사용하고 있는데
465. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 그 이유는 좋은 인스턴스일수록
466. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 AWS에서 더 높은 네트워크 속도를 제공하고 있고
467. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 EMR에서 Spark를 사용할 때
468. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 YARN이라는 리소스 매니저를 사용하는데
469. EMR Spark 클러스터 스펙 • 메모리가 중요하므로 r4 타입을 선호 • 작은 인스턴스 4개 보다 큰 인스턴스 1개로 • 좋은 인스턴스가 네트워크 속도도 더 빠르다 • EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다 이 때 YARN 컨테이너에 할당하는 메모리 비율이 더 크기 때문입니다.
470. #5 개선할 점 네, 여기까지 저희 로그 시스템에 대한 소개를 마쳤습니다.
471. #5 개선할 점 그래서 결론이 “완벽한 로그 시스템인가?” 에 대하여
472. #5 개선할 점 실제 운영결과, 앞서 말했던 목표를 달성하였지만
473. #5 개선할 점 몇 가지 분명 불편한 점이 있었습니다.
474. #5 개선할 점 마지막으로 개선할 점을 말씀드리면서 정리를 하고자합니다.
475. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 먼저 분석의 대중화가 어려웠습니다.
476. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 분석에 대한 수요는 많지만 분석가는 언제나 부족합니다.
477. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 때문에 비 개발자도 분석하기 쉬웠으면 이라는 생각도 하는데요.
478. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 사실 이런 점을 위해서 나름 간단한 분석은 쉽게 할 수 있도록
479. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 SQL을 사용할 수 있는 것을 목표로 하였습니다만
480. • 분석가는 언제나 부족 • 비 개발자도 분석하기도 쉬웠으면 • SQL은 과연 쉬운가…? • 사실상 대중화 실패 • 하는 사람만 한다. 분석의 대중화 사실상 대중화는 쉽지 않았습니다.
481. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석 규모에 따른 오토 스케일링 또한 분석 규모에 따라 오토 스케일링이 되었으면 좋겠다라는 생각을 했습니다.
482. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석 규모에 따른 오토 스케일링 비용을 좀 더 효과적으로 절감하고
483. • 분석의 규모에 따라 • 클러스터 크기가 자동으로 조절되었으면 분석 규모에 따른 오토 스케일링 시간을 효율적으로 사용할 수 있었으면 하는 바람이 있습니다.
484. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. • Zeppelin으로는 아직 제한적 한편으로는 Zeppelin에만 시각화에 대한 상당부분을 의존하고 있기 때문에
485. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. • Zeppelin으로는 아직 제한적 복잡한 시각화의 경우
486. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. • Zeppelin으로는 아직 제한적 Jupyter notebook에서 따로 시각화하고 있는데요.
487. 시각화의 다양화 • 한편으로는 복잡한 시각화가 필요할 때도 있다. • Zeppelin으로는 아직 제한적 이 부분도 아직은 아쉬움으로 남고 있습니다.
488. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능 • 오직 컬럼 추가만 가능 세 번째는 아까 말씀드렸던 로그 스키마 변경입니다.
489. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능 • 오직 컬럼 추가만 가능 쉽게 스키마를 추가할 수 있고
490. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능 • 오직 컬럼 추가만 가능 컬럼 추가도 자유롭지만
491. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능 • 오직 컬럼 추가만 가능 컬럼 이름을 바꿀 수 없다는 것이
492. 로그 스키마 변경 • 이미 쌓인 로그에 대하여 마이그레이션 불가능 • 오직 컬럼 추가만 가능 의외로 시간이 지나면서 불편을 초래하고 있습니다.
493. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 마지막으로 컨텐츠가 추가되거나
494. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 남겨야 할 정보들이 더 많아지고 하면서
495. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 스키마 개수도 100개가 넘고
496. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 컬럼도 계속 추가되고 있는데요.
497. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 어떤 컬럼이 정확히 무엇을 의미하는 지에 대해
498. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 직접 코드를 보아야 알 수 있는 경우도 있었습니다.
499. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 이 것은 결국 문서가 없기 때문에 발생하는 현상인데요.
500. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 → Docstring을 이용한 스키마 문서화? 스키마 별로 클래스를 정의하고 있기 때문에
501. “이 컬럼은 정확히 뭘 의미하나요?” • 100개가 넘는 스키마, 모두 기억하지 못함 • 문서가 없기 때문에 발생하는 현상 → Docstring을 이용한 스키마 문서화? Docstring을 이용해서 스키마를 문서화하는 방법을 고안 중입니다.
502. 감사합니다 네, 제가 준비한 내용은 여기까지인데요.
503. 감사합니다 많은 것을 공유하고 싶었고
504. 감사합니다 때문에 많은 내용을 다루다 보니
505. 감사합니다 조금 지루할 수도 있고 미처 자세히 설명하지 못한 부분도 있을 수 있지만
506. 감사합니다 여기까지 들어주신 분들께 감사드립니다.
507. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 듀랑고의 서버에 관련된 발표로
508. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 내일과 내일 모레에도 세션들이 준비되어있으니
509. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기 김찬웅 님 / 4월 25일 오후 4시 30분 〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3 이흥섭 님 / 4월 25일 오후 3시 20분 〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기 최호영 님 / 4월 26일 오전 11시 관심있는 분들은 많은 참석바랍니다.
510. WE'RE HIRING! http://what.studio/ 마지막으로 저희 왓 스튜디오는 다양한 직군에 대해서 채용을 진행하고 있으니
511. WE'RE HIRING! http://what.studio/ 많은 관심 부탁드립니다.
512. WE'RE HIRING! http://what.studio/ 이상으로 발표를 마치겠습니다. 감사합니다.