Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유
SlideShare에 슬라이드 300장 제한으로 부득이하게 2부로 나누어 올렸습니다. 현재 보고 계신 슬라이드는 1부입니다.
〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 안녕하세요.
〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기를 주제로 발표하게 된
〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 전효준입니다.
〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 많은 분들이 찾아와주셨는데 이렇게 시간내어 찾아와주셔서 감사드립니다.
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 제 소개를 먼저 드리자면
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 왓 스튜디오의 백엔드 엔지니어이고요.
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전 경력이라고 하면
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 2개의 스타트업을 거쳐서 넥슨에 입사하게 되었고
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 직전에는 버즈니라는 회사의 데이터 인프라팀에서
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 로그 시스템을 개발하고 운영한 경험이 있습니다.
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 스튜디오에서는 자료공이라고 불리기도 하는데요.
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전에 이런 종이로 된 명패를 받았었는데
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 여기에 자료공 내정자라고 써있더라고요.
전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 자료공 = 데이터 엔지니어 전효준 devin@nexon.co.kr 이 자료공은 저희가 흔히 말하는 데이터 엔지니어를 한...
152,402,774 시작하기에 앞서 저희 듀랑고의 재미있는 통계 중 하나를 뽑아보았습니다.
152,402,774 과연 이 숫자가 의미하는 것은 무엇일까요?
152,402,774 네 1억 5천이라는 숫자는 바로
152,402,774 현재까지 제작된 꼬치구이 개수 현재까지 듀랑고에서 제작된 꼬치구이의 개수입니다.
152,402,774 현재까지 제작된 꼬치구이 개수 꼬치구이라고 하면 듀랑고에서 가장 기본적으로 할 수 있는 요리인데요.
152,402,774 현재까지 제작된 꼬치구이 개수 엄청나게 많은 수의 꼬치구이가 제작된 것을 알 수있습니다.
327 또 하나 좀더 재미있는 통계가 있는데요.
327 이 327이라는 숫자는 바로
327가죽장화를 먹은 플레이어 수 현재까지 가죽장화를 먹은 플레이어의 수입니다.
327가죽장화를 먹은 플레이어 수 아시는 분들도 있겠지만 2014년 NDC에서
327가죽장화를 먹은 플레이어 수 “가죽 장화를 먹게 해주세요” “가죽 장화를 먹게 해달라니”라는 주제로
327가죽장화를 먹은 플레이어 수 이정수님과 최호영님의 NDC 발표가 있었는데
327가죽장화를 먹은 플레이어 수 보시다시피 실제로도 가죽 장화를 먹은 유저분들이 있었습니다.
로그 네, 어쨌든 이런 통계를 뽑기위해 필요한 것들이 바로 로그인데요.
로그 간단하게는 DAU, 리텐션부터 유저들이 어떤 구간에서 이탈하는 지와 같은
로그 많은 것들을 알 수 있습니다.
(론칭이후 약 3개월간) 110 TB 지금 앞에 보시는 숫자는 저희가 론칭 이후 약 3개월간 적재한 로그의 양입니다.
(론칭이후 약 3개월간) 110 TB 꽤 많은 로그를 모두 적재하고 있고,
(론칭이후 약 3개월간) 110 TB 이 것들을 잘 다룰 수 있는 로그 시스템을 구축하고 있습니다.
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 이쯤에서 듀랑고의 로그 시스템을 간단히 소개드리면
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB 먼저 저희는 보여드린 것과 같이 로그들을 버리지 않고 수집하고...
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 로그가 발생하고 나서 대략 5초 ...
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고...
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고...
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고...
듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고...
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 오늘 발표는 이런 로그 시스템에 대하여 발표를 할 텐데요.
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 저희가 로그를 쌓아서 어떻게 사용하고 있는지
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 이렇게 사용하기 위해 어떤 것을 목표로 잡았고
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그 목표를 달성하기 위해 어떻게 아키텍처를 구성하였는지
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그리고 이런 아키텍처에서 각각의 요소들을 ‘잘’ 사용하는 방법들을 소개하고
#1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 개선할 점들을 이야기하며 마무리할 예정입니다.
#1 로그는 쌓아서 뭐하나 먼저 로그시스템이 왜 필요한지, 로그는 왜 쌓고 있는지를 말씀 드리고자 합니다.
아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 첫 번째로 서비스 운영을 위해 로그 조회가 필요한데요.
아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 그 예로 “아이템이 없어졌어요!” 라는 고객문의가 들어올 때가 있습니다.
아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 이런 문의가 들어오면 운영하는 입장에서는 확인절차를 거쳐야 하는데요.
서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 실제로 유저가 아이템을 획득하였는지, 혹시나 다른 경로로 소비한 내역이 없는지 등
서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 여러 가지를 확인하고 복구를 해야 하는데
서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 이 때 로그를 조회하여 확인절차를 거치게 됩니다.
주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 다음으로는 각종 주요 지표를 추출하기 위함인데요.
주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 실제로 DAU나, MAU, 리텐션 등
주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 각종 지표나 통계를 추출하기 위한 기반 데이터로 사용하고 있습니다.
데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 세 번째는 데이터 기반으로 의사결정을 하고 있기 때문입니다.
데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 몇 가지 사례를 말씀드리면
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표• 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 섬 인구수 별 재방문율 지표를 보고 적정 인구수를 산정하기도 했고요.
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 유저분들의 플레이 유형을 클러스터링한 정보를 통해
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 업데이트 방향을 설정하는 지표로 삼기도 하였습니다.
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 그리고 이탈구간...
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 초반 가이드를 ...
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄...
데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄...
마지막으로 듀랑고를 하시면서 이런 오류 메시지를 보신 적이 있을 텐데요.
자세히 보시면 여기에는 오류코드라는 것이 있습니다.
A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 오류가 발생했을 때 분산된 게임서버에 하나하나 SSH로 접속하여
A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 관련된 로그를 찾다가 결국 못 찾게 되는 상황이 있을 수 있습니다.
A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 로그를 못 찾아서 원인파악을 빠르게 하지 못하면
A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 이슈를 빠르게 대응할 수 없고 개발자들의 생산성이 떨어질 수 있겠죠
• 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시...
• 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시...
• 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시...
• 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시...
• 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시...
게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 정리를 해보면 저희는 게임플레이 로그와 시스템 로그
게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 크게 두 가지 종류의 로그를 수집하고 있는데요.
게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 게임플레이 로그는 서비스 운영, 의사결정, 주요 지표 추출에 사용되고있고
게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 시스템 로그는 개발자들의 생산성을 확대하고, 빠른 이슈 대응을 위해 수집하고 있습니다.
우리의 지속적 발전을 위한 중요한 도구 결과적으로 이런 로그는 우리의 지속적 발전을 위한 중요한 도구로 사용되고 있는데요.
#2 로그 시스템의 목표 이런 로그를 수집하고 잘 활용하기 위한
#2 로그 시스템의 목표 로그 시스템의 목표를 한번 세워보았습니다.
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 먼저 로그 시스템의 요구사항들을 한번 살펴보겠습니다.
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 듀랑고는 복잡한 게임시스템을 가지고 있는데
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 자유도 높은 아이템 구조와 같은 특징으로
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 이는 곧 복잡한 로그 스키마 구조를 표현할 수 있어야...
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 게임 플레이로그와 시스템 로그들을 모두 수집하다...
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 대규모 로그 발생을 감당할 수 있어야 했고
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 같은 맥락으로 대규모 분석도 가능해야 했습니다.
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 대규모 분석말고도 즉각적인 조회와 검색도 가능해...
별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 하지만 이런 로그 시스템의 요구사항 외에
별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 스키마의 변동이 없거나 높은 신뢰도가 요구되는 일부 로그들은
별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 별도의 RDB를 사용했습니다.
→ 이번 발표에서 RDB 로그는 다루지 않아요 하지만 이번 발표에서 RDB에 저장하는 로그에 대해서는 따로 다루지 않을 예정입니다.
로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 앞서 이런 요구사항을 충족하는 로그시스템을 구축하기 ...
설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 목표는 총 4가지로
설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 높은 가용성이 보장되어야 하고
설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 실시간 조회가 가능해야 하며
설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 분석 및 시각화가 가능해야 합니다.
설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 그리고 관리부담을 최소화하는 것 입니다.
• 시스템이 죽으면 로그는 유실됨 높은 가용성 먼저 높은 가용성에 대하여 간단히 설명 드리자면
• 시스템이 죽으면 로그는 유실됨 높은 가용성 로그를 수집하고 저장하는 시스템이 죽으면
• 시스템이 죽으면 로그는 유실됨 높은 가용성 로그는 결국 유실될 수 있는데요.
높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 로그가 유실되면
높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 각종 지표를 오염시킬 수도 있고 운영에 차질이 생길 수 있습니다.
높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 저 또한 힘들어질 수 있겠지요.
로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 높은 가용성 → 높은 가용성이 보장되어야 따라서 로그 시스템이 항상 잘 살아서 잘 돌아가도록 만들어야 했습니다.
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 두 번째로는 실시간 조회가 가능해야 한다는 것 입니다.
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 저장만 하고 원하는 로그를 찾을 수 없다면
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 사실 저장하는 의미가 없습니다.
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 반면에, 빠르게 로그를 찾을 수 있다는 건
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 그만큼 빨리 문제에 대응할 수 있는 생산성 향상을 의미합니다.
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 그래서 로그가 발생하고 부터
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 대략 5초 이내에 조회가 가능하길 원했습니다.
실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 추가로 원하는 로그만을 조회할 수 있도록 검색도 가능해야 했습니다.
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 또한 로그 시스템은 각종 분석 및
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 그 결과에 대한 시각화도 가능해야 했는데요.
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 대규모로 적재된 로그에 대해서도 빠르게 분석할 수 있어야 합니...
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 마치 RDB에 적재한 것처럼 SQL도 가능한 것을 목표로 했고
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 여기서 분석 결과에 대한 그래프도
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 코드를 이용해서 직접 그리거나 엑셀에 옮겨서 그래프를 표현하는...
분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 분석 결과를 보고 어느정도 알아서 그려줬으면 좋겠다는 생각을 ...
관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 마지막으로 저는 자료공의 역할만 하는 것이 아니기 때문에
관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 관리부담의 최소화가 필요했습니다.
관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 사실 하드웨어 이슈는
관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 클라우드 서비스를 이용하면서 거의 탈출했다고 보아도 무방하지만
관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 로그 유입량에 따라 시스템을 쉽게 확장하거나 축소할 수 있어야 했습니다.
알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 결국, 종합해보면
알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 알아서 잘 수집하고 빠르게 조회도하고 분석도할 수 있는 로그 시스템인데요.
알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 정말 완벽하게 충족하진 못하더라도
알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리가 감수할 수 있는 만큼은 만족하는 시스템이길 바랐습니다.
알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리에겐 지속적으로 개선할 기회가 있기 때문이죠
#3 로그 시스템 아키텍처 결국 이렇게 로그 시스템을 개발하게 되었습니다.
#3 로그 시스템 아키텍처 저희 로그 시스템은 앞서 말씀드린 목표를 충족하기 위해
#3 로그 시스템 아키텍처 다양한 AWS 서비스와 오픈소스를 사용하였는데요.
#3 로그 시스템 아키텍처 이번에는 로그 시스템이 어떤 아키텍처로 구성되어 있는지 말씀드리려고 합니다.
수집 조회 분석 로그 시스템을 수집, 조회, 분석으로 크게 3단계로 나누어 보았습니다.
수집 먼저 로그를 서버에서 수집하고 이를 적재하는 과정까지의 수집단계 입니다.
수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd 로그를 수집하는 파이프라인은 보시는 바와 같이 구성되어 있습니다.
로그 수집 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd 서버에서 로그가 발생하면 Fluentd에서 로그를 수집하고
스트림에 전송 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd Fluentd는 Kinesis라는 거대한 스트림으로 전송을 하게 되고
로그 처리 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd Lambda는 Kinesis에 들어오는 로그들을 처리하여
저장 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd S3에 저장하게 됩니다.
게임서버 Fluentd 먼저 게임서버에서 Fluentd로 로그를 전송하는 부분입니다.
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd Fluentd는 오픈소스 데이터 수집기인데
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd 성능이 필요한 부분은 C언어로, 확장성이 필요한 부분은 Ruby로 구현되어 있어서
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Fluentd Fluentd 리소스 차지도 매우 적고 빠릅니다.
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 또한 다양한 플러그인을 가지고 있는데요.
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 앞서 보여드렸던 Kinesis에 로그를 전송할 수 있는 플러그인도
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd AWS에서 지원하고 있습니다.
• 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 마지막으로 비교적 간편하게 설정할 수 있다는 점도 장점이었습니다.
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 여러 개의 노드가 실행됩니다.
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 여기서 용어정리를 잠깐 하자면
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 호스트는 하나의 머신을 의미하고
• 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 노드는 각각의 프로세스를 의미합니다.
• 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 하나의 Fluentd가 존재해서 노...
• 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd 로그 수집 에이전트의 역할 Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 쉽게 말해서 로그 수집 에...
Fluentd Kinesis Fluentd는 이렇게 수집한 로그를 Kinesis라는 곳에 넘기는데요.
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis 여기서 이야기하...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis AWS의 관리형...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
→ 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data ...
→ 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data ...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
• AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복...
LambdaKinesis 이렇게 Kinesis에 데이터들이 들어오면
LambdaKinesis Lambda는 Kinesis에 데이터가 들어왔다는 이벤트를 트리거하여
LambdaKinesis 데이터를 가져와서 처리하는 역할을 합니다.
• 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 여기서 Lambda는 AWS에서 지원하는 서버리스 컴퓨팅 서비스...
• 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 자동으로 확장하거나 축소하기도 하는데
• 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 때문에 저희가 따로 인프라를 관리할 필요...
• 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 Lambda는 Kinesis의 이벤트를 ...
• 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 이렇게 Lambda는 Kinesis의 데...
Lambda S3 AWS의 저장소인 S3에 저장합니다.
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 실제로 ...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 무한대로...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 도쿄 리...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 그리고 ...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 대...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 트래픽에...
• 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 1...
조회 여기까지가 저희의 로그 수집 파이프라인입니다.
조회 다음으로는 로그를 조회하는 단계입니다.
Kinesis Lambda S3 방금 Kinesis에 들어온 로그 데이터를 Lambda가 S3에 저장하고 있다고 설명드렸는데요.
Kinesis Lambda S3 여기에는 사실 하나가 생략되어 있었습니다.
S3Lambda ESLambda Kinesis 저희 로그 시스템에는 하나의 Kinesis를
S3Lambda ESLambda Kinesis 두개의 Lambda가 트리거하고 있는데요.
S3Lambda ESLambda Kinesis 두 번째 Lambda는 Elasticsearch로 데이터를 insert하는 역할을 합니다.
S3Lambda ESLambda Kinesis 여기서 알 수 있는 것은
S3Lambda ESLambda Kinesis Kinesis는 내부적으로 Iterator Id라는 것으로 관리되고 있어서
S3Lambda ESLambda Kinesis 여러 개의 Lambda가 트리거할 수 있습니다.
S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 물론 약간의 제한이 있는데요.
S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) Kinesis에 최대 5개의 읽기 트랜잭션 제한때문인데
S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 이것이 의미하는 건
S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 사실상 하나의 Kinesis에 최대 5개의 Lambda만 안정적으로 ...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 다시 돌아와서, 저희는 실시간 ...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 Lucene 기반의 분산 검색엔...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 역 인덱스를 이용한 빠른 검색이...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 그리고 Kibana라는 아주 유...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 ...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 ...
• Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 ...
ES 로그가 늘어날 수록 유지비용 증가 하지만 로그가 늘어날 수록
ES 로그가 늘어날 수록 유지비용 증가 Elasticsearch의 클러스터를 유지하기에는 비용이 점점 늘어날 수 밖에 없는데
ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 때문에 저희는 빠르게 조회할 필요성이 있는
ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 최근 3개월만의 로그만 ES에 저장하고 있습니다.
이 것은 아까 보여드렸던 오류코드입니다.
저희는 이것을 Elasticsearch의 시각화 도구인 Kibana에서 조회하고 있는데요.
간단하게 오류코드를 검색하면 해당하는 로그를 찾을 수 있고
로그가 발생한 호스트 host 로그가 발생한 호스트가 어디인지 알 수 있습니다.
에러 메시지 message 에러메시지를 확인할 수 있고
Traceback exc_info 어떤 경로로 함수가 호출되었는 지
Traceback exc_info 스택 추적이 가능한 Python Traceback을 제공합니다.
특정 유형의 로그 검색도 가능 실제로 “Timeout”과 같은 키워드로 검색하여
특정 유형의 로그 검색도 가능 특정 유형의 로그 검색도 가능합니다.
특정 유형의 로그 검색도 가능 예제로 보여드렸던 시스템 로그 조회 뿐만 아니라
특정 유형의 로그 검색도 가능 게임 플레이 로그도 ES에 저장하여 Kibana에서 조회할 수 있도록 사용하고 있습니다.
오류코드 검색 이 것은 실제로 저희가 Kibana를 통해 특정 오류코드를 검색하는 영상이고요.
특정 플레이어의 최근 플레이 로그 검색 다음 영상은 저의 최근 게임 플레이 로그를 검색하는 모습입니다.
수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 이렇게 저희 수집 파이프라인을 다시 요약해보면
수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 결국 로그는 Fluentd와 Kinesis를 거쳐
수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 두 개의 Lambda를 통해 S3와 Elasticsearch로 저장되는 것으로 정리할 수 있습니다.
SlideShare에 슬라이드 300장 제한으로 부득이하게 2부로 나누어 올렸습니다. 2부는 아래 링크에서 계속됩니다. https://goo.gl/wpoZpY
Upcoming SlideShare
Loading in …5
×

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

10,550 views

Published on

NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)

Published in: Data & Analytics
License: CC Attribution License
no profile picture user
  • Sex in your area is here: ❶❶❶ http://bit.ly/39sFWPG ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/39sFWPG ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
Show More

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

  1. 1. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유
  2. 2. SlideShare에 슬라이드 300장 제한으로 부득이하게 2부로 나누어 올렸습니다. 현재 보고 계신 슬라이드는 1부입니다.
  3. 3. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 안녕하세요.
  4. 4. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기를 주제로 발표하게 된
  5. 5. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 전효준입니다.
  6. 6. 〈야생의 땅: 듀랑고〉의 데이터 엔지니어링 이야기 넥슨 컴퍼니 왓 스튜디오 전효준 : 로그 시스템 구축 경험 공유 많은 분들이 찾아와주셨는데 이렇게 시간내어 찾아와주셔서 감사드립니다.
  7. 7. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 제 소개를 먼저 드리자면
  8. 8. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 왓 스튜디오의 백엔드 엔지니어이고요.
  9. 9. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전 경력이라고 하면
  10. 10. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 저는 2개의 스타트업을 거쳐서 넥슨에 입사하게 되었고
  11. 11. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 직전에는 버즈니라는 회사의 데이터 인프라팀에서
  12. 12. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 로그 시스템을 개발하고 운영한 경험이 있습니다.
  13. 13. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 스튜디오에서는 자료공이라고 불리기도 하는데요.
  14. 14. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 이전에 이런 종이로 된 명패를 받았었는데
  15. 15. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 여기에 자료공 내정자라고 써있더라고요.
  16. 16. 전효준 • 현재 왓 스튜디오의 백엔드 엔지니어 • 주로 자료공 역할 devin@nexon.co.kr 자료공 = 데이터 엔지니어 전효준 devin@nexon.co.kr 이 자료공은 저희가 흔히 말하는 데이터 엔지니어를 한글로 표현한 것 입니다.
  17. 17. 152,402,774 시작하기에 앞서 저희 듀랑고의 재미있는 통계 중 하나를 뽑아보았습니다.
  18. 18. 152,402,774 과연 이 숫자가 의미하는 것은 무엇일까요?
  19. 19. 152,402,774 네 1억 5천이라는 숫자는 바로
  20. 20. 152,402,774 현재까지 제작된 꼬치구이 개수 현재까지 듀랑고에서 제작된 꼬치구이의 개수입니다.
  21. 21. 152,402,774 현재까지 제작된 꼬치구이 개수 꼬치구이라고 하면 듀랑고에서 가장 기본적으로 할 수 있는 요리인데요.
  22. 22. 152,402,774 현재까지 제작된 꼬치구이 개수 엄청나게 많은 수의 꼬치구이가 제작된 것을 알 수있습니다.
  23. 23. 327 또 하나 좀더 재미있는 통계가 있는데요.
  24. 24. 327 이 327이라는 숫자는 바로
  25. 25. 327가죽장화를 먹은 플레이어 수 현재까지 가죽장화를 먹은 플레이어의 수입니다.
  26. 26. 327가죽장화를 먹은 플레이어 수 아시는 분들도 있겠지만 2014년 NDC에서
  27. 27. 327가죽장화를 먹은 플레이어 수 “가죽 장화를 먹게 해주세요” “가죽 장화를 먹게 해달라니”라는 주제로
  28. 28. 327가죽장화를 먹은 플레이어 수 이정수님과 최호영님의 NDC 발표가 있었는데
  29. 29. 327가죽장화를 먹은 플레이어 수 보시다시피 실제로도 가죽 장화를 먹은 유저분들이 있었습니다.
  30. 30. 로그 네, 어쨌든 이런 통계를 뽑기위해 필요한 것들이 바로 로그인데요.
  31. 31. 로그 간단하게는 DAU, 리텐션부터 유저들이 어떤 구간에서 이탈하는 지와 같은
  32. 32. 로그 많은 것들을 알 수 있습니다.
  33. 33. (론칭이후 약 3개월간) 110 TB 지금 앞에 보시는 숫자는 저희가 론칭 이후 약 3개월간 적재한 로그의 양입니다.
  34. 34. (론칭이후 약 3개월간) 110 TB 꽤 많은 로그를 모두 적재하고 있고,
  35. 35. (론칭이후 약 3개월간) 110 TB 이 것들을 잘 다룰 수 있는 로그 시스템을 구축하고 있습니다.
  36. 36. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 이쯤에서 듀랑고의 로그 시스템을 간단히 소개드리면
  37. 37. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB 먼저 저희는 보여드린 것과 같이 로그들을 버리지 않고 수집하고 적재하고 있고
  38. 38. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 로그가 발생하고 나서 대략 5초 이내에 조회하고 검색할 수 있습니다.
  39. 39. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 이런 단순 조회나 검색이 아닌 대규모의 로그도 빠르게 분석 가능하고
  40. 40. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 별다른 조작 없이도 시각화할 수 있습니다.
  41. 41. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 그리고 관리부담을 최소화하였는데
  42. 42. 듀랑고의 로그 시스템 • 로그를 버리지 않고 적재 • 실시간 로그 조회 및 검색 • 분석 및 시각화 • 관리부담 최소화 → 론칭 이후 3개월간 약 110TB → 5초 안에 조회 + 검색 → 대규모 로그도 빠르게 분석하고 시각화까지 → 혼자서도 여유롭게 때문에 저 혼자서도 여유롭게 로그 시스템을 운영할 수 있습니다.
  43. 43. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 오늘 발표는 이런 로그 시스템에 대하여 발표를 할 텐데요.
  44. 44. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 저희가 로그를 쌓아서 어떻게 사용하고 있는지
  45. 45. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 이렇게 사용하기 위해 어떤 것을 목표로 잡았고
  46. 46. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그 목표를 달성하기 위해 어떻게 아키텍처를 구성하였는지
  47. 47. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 그리고 이런 아키텍처에서 각각의 요소들을 ‘잘’ 사용하는 방법들을 소개하고
  48. 48. #1 로그는 쌓아서 뭐하나 #2 로그 시스템의 목표 #3 로그 시스템 아키텍처 #4 ‘잘’ 사용하기 #5 개선할 점 개선할 점들을 이야기하며 마무리할 예정입니다.
  49. 49. #1 로그는 쌓아서 뭐하나 먼저 로그시스템이 왜 필요한지, 로그는 왜 쌓고 있는지를 말씀 드리고자 합니다.
  50. 50. 아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 첫 번째로 서비스 운영을 위해 로그 조회가 필요한데요.
  51. 51. 아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 그 예로 “아이템이 없어졌어요!” 라는 고객문의가 들어올 때가 있습니다.
  52. 52. 아이템이 없어졌어요! ”“ 서비스 운영을 위한 로그 조회 이런 문의가 들어오면 운영하는 입장에서는 확인절차를 거쳐야 하는데요.
  53. 53. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 실제로 유저가 아이템을 획득하였는지, 혹시나 다른 경로로 소비한 내역이 없는지 등
  54. 54. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 여러 가지를 확인하고 복구를 해야 하는데
  55. 55. 서비스 운영을 위한 로그 조회 아이템이 없어졌어요! ”“ 실제 이력을 확인해보아야 한다. 실제 아이템 획득 여부, 제작 재료 소비 여부 등 이 때 로그를 조회하여 확인절차를 거치게 됩니다.
  56. 56. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 다음으로는 각종 주요 지표를 추출하기 위함인데요.
  57. 57. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 실제로 DAU나, MAU, 리텐션 등
  58. 58. 주요 지표 추출 • 월/일 별 활성 유저수 • 재방문율, 플레이 시간 • 각종 통계 추출 • 등등 ... 각종 지표나 통계를 추출하기 위한 기반 데이터로 사용하고 있습니다.
  59. 59. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 세 번째는 데이터 기반으로 의사결정을 하고 있기 때문입니다.
  60. 60. 데이터 기반의 의사결정 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 몇 가지 사례를 말씀드리면
  61. 61. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표• 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 섬 인구수 별 재방문율 지표를 보고 적정 인구수를 산정하기도 했고요.
  62. 62. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 유저분들의 플레이 유형을 클러스터링한 정보를 통해
  63. 63. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 업데이트 방향을 설정하는 지표로 삼기도 하였습니다.
  64. 64. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 그리고 이탈구간 분석 및 레벨별 활성 유저 수와 같은 정보를 기반으로
  65. 65. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 플레이 유형 클러스터링 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • 업데이트 방향 설정 • 초반 가이드 개선 • 등등 ... 초반 가이드를 개선하기도 하였는데요.
  66. 66. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 이 초반가이드 개선에 대한 발표도 NDC 마지막날인 26일에 있으니
  67. 67. 데이터 기반의 의사결정 → 섬 인구수 별 재방문율 지표 → 이탈구간 분석, 레벨별 활성 유저수 • 적정 인구수 산정 • (광영님 분석사례 추가) • 초반 가이드 개선 • 등등 ... 낯선 게임인데 익숙해야 하고, 알려줄 게 많은데 재미있어야 한다고요? - <야생의 땅: 듀랑고> 초반 플레이 변천사 강임성 님 / 4월 26일 오전 11시 관심 있으신 분들은 참관하셔도 좋을 듯합니다.
  68. 68. 마지막으로 듀랑고를 하시면서 이런 오류 메시지를 보신 적이 있을 텐데요.
  69. 69. 자세히 보시면 여기에는 오류코드라는 것이 있습니다.
  70. 70. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 오류가 발생했을 때 분산된 게임서버에 하나하나 SSH로 접속하여
  71. 71. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 관련된 로그를 찾다가 결국 못 찾게 되는 상황이 있을 수 있습니다.
  72. 72. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 로그를 못 찾아서 원인파악을 빠르게 하지 못하면
  73. 73. A섬에서 채집할 때 오류가 자꾸 난대요! 로그를 못 찾겠어요 ㅠㅠ (호스트마다 SSH 접속해서 로그파일들 열어보다가…) 이슈를 빠르게 대응할 수 없고 개발자들의 생산성이 떨어질 수 있겠죠
  74. 74. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 그래서 이 오류코드는 저희 서버의 시스템 로그를 조회하기 위한 것입니다.
  75. 75. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희 로그 시스템에서는 어떤 서버에서 어떤 에러가 발생하였는지,
  76. 76. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 어떤 경로로 호출되었는지 Python Traceback을 남기고 있습니다.
  77. 77. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 저희는 수많은 호스트들에서 발생하는 시스템 로그를 모두 수집하여 한 곳에 모으고 있고
  78. 78. • 많은 수의 게임 서버로부터 시스템 로그를 모두 수집 • 어떤 서버에서 어떤 에러가 발생했는 지 • 코드가 어떤 경로로 호출되었는지 Traceback 을 남김 • 오류코드는 해당 시점의 서버 로그를 찾기 위한 단서 시스템 로그 조회 결국 오류코드는 로그가 발생한 시점의 서버로그를 찾기 위한 단서라고 할 수 있습니다.
  79. 79. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 정리를 해보면 저희는 게임플레이 로그와 시스템 로그
  80. 80. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 크게 두 가지 종류의 로그를 수집하고 있는데요.
  81. 81. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 게임플레이 로그는 서비스 운영, 의사결정, 주요 지표 추출에 사용되고있고
  82. 82. 게임플레이 로그 • 서비스 운영 • 의사결정을 위한 분석 • 주요 지표 추출 시스템 로그 • 개발자 생산성 확대 • 빠른 이슈 대응 시스템 로그는 개발자들의 생산성을 확대하고, 빠른 이슈 대응을 위해 수집하고 있습니다.
  83. 83. 우리의 지속적 발전을 위한 중요한 도구 결과적으로 이런 로그는 우리의 지속적 발전을 위한 중요한 도구로 사용되고 있는데요.
  84. 84. #2 로그 시스템의 목표 이런 로그를 수집하고 잘 활용하기 위한
  85. 85. #2 로그 시스템의 목표 로그 시스템의 목표를 한번 세워보았습니다.
  86. 86. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 먼저 로그 시스템의 요구사항들을 한번 살펴보겠습니다.
  87. 87. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 듀랑고는 복잡한 게임시스템을 가지고 있는데
  88. 88. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 자유도 높은 아이템 구조와 같은 특징으로
  89. 89. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 이는 곧 복잡한 로그 스키마 구조를 표현할 수 있어야 했습니다.
  90. 90. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 게임 플레이로그와 시스템 로그들을 모두 수집하다 보니
  91. 91. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 대규모 로그 발생을 감당할 수 있어야 했고
  92. 92. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 같은 맥락으로 대규모 분석도 가능해야 했습니다.
  93. 93. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 또한 대규모 분석말고도 즉각적인 조회와 검색도 가능해야 했습니다.
  94. 94. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 하지만 이런 로그 시스템의 요구사항 외에
  95. 95. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 스키마의 변동이 없거나 높은 신뢰도가 요구되는 일부 로그들은
  96. 96. 별도의 RDB를 사용하기도 … • 스키마의 변동이 없는 로그 ex) 플레이어 접속 로그 • 높은 신뢰도가 요구되는 로그 ex) 결제로그 별도의 RDB를 사용했습니다.
  97. 97. → 이번 발표에서 RDB 로그는 다루지 않아요 하지만 이번 발표에서 RDB에 저장하는 로그에 대해서는 따로 다루지 않을 예정입니다.
  98. 98. 로그 시스템의 요구사항 • 복잡한 게임 시스템 → 복잡한 로그 스키마 • 게임 플레이로그 + 시스템 로그 → 대규모 로그 발생 • 대규모 분석 • 빠른 조회 및 검색 앞서 이런 요구사항을 충족하는 로그시스템을 구축하기 위한 목표를 세워보았습니다.
  99. 99. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 목표는 총 4가지로
  100. 100. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 높은 가용성이 보장되어야 하고
  101. 101. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 실시간 조회가 가능해야 하며
  102. 102. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 분석 및 시각화가 가능해야 합니다.
  103. 103. 설계 목표 • 높은 가용성 • 실시간 조회 • 분석 및 시각화 • 관리부담 최소화 그리고 관리부담을 최소화하는 것 입니다.
  104. 104. • 시스템이 죽으면 로그는 유실됨 높은 가용성 먼저 높은 가용성에 대하여 간단히 설명 드리자면
  105. 105. • 시스템이 죽으면 로그는 유실됨 높은 가용성 로그를 수집하고 저장하는 시스템이 죽으면
  106. 106. • 시스템이 죽으면 로그는 유실됨 높은 가용성 로그는 결국 유실될 수 있는데요.
  107. 107. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 로그가 유실되면
  108. 108. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 각종 지표를 오염시킬 수도 있고 운영에 차질이 생길 수 있습니다.
  109. 109. 높은 가용성 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 저 또한 힘들어질 수 있겠지요.
  110. 110. 로그 조회가 안 돼요! 로그가 없어요! • 시스템이 죽으면 로그는 유실됨 높은 가용성 → 높은 가용성이 보장되어야 따라서 로그 시스템이 항상 잘 살아서 잘 돌아가도록 만들어야 했습니다.
  111. 111. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 두 번째로는 실시간 조회가 가능해야 한다는 것 입니다.
  112. 112. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 저장만 하고 원하는 로그를 찾을 수 없다면
  113. 113. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 사실 저장하는 의미가 없습니다.
  114. 114. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 반면에, 빠르게 로그를 찾을 수 있다는 건
  115. 115. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 그만큼 빨리 문제에 대응할 수 있는 생산성 향상을 의미합니다.
  116. 116. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 그래서 로그가 발생하고 부터
  117. 117. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 대략 5초 이내에 조회가 가능하길 원했습니다.
  118. 118. 실시간 조회 • 빠른 조회는 곧 생산성 향상과 직결 • • 검색이 가능해야 한다. 빠르고 쉽게 조회 가능해야한다. 로그 발생 조회5초 이내 추가로 원하는 로그만을 조회할 수 있도록 검색도 가능해야 했습니다.
  119. 119. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 또한 로그 시스템은 각종 분석 및
  120. 120. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 그 결과에 대한 시각화도 가능해야 했는데요.
  121. 121. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 대규모로 적재된 로그에 대해서도 빠르게 분석할 수 있어야 합니다.
  122. 122. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 마치 RDB에 적재한 것처럼 SQL도 가능한 것을 목표로 했고
  123. 123. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 여기서 분석 결과에 대한 그래프도
  124. 124. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 코드를 이용해서 직접 그리거나 엑셀에 옮겨서 그래프를 표현하는 것이 아닌
  125. 125. 분석 및 시각화 • 예) 지난 3개월 간 유저들이 획득/소비한 티스톤의 양 • 대규모 로그도 빠르게 분석 • SQL 사용 가능 • 그래프도 알아서 그려줬으면 분석 결과를 보고 어느정도 알아서 그려줬으면 좋겠다는 생각을 했습니다.
  126. 126. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 마지막으로 저는 자료공의 역할만 하는 것이 아니기 때문에
  127. 127. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 관리부담의 최소화가 필요했습니다.
  128. 128. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 사실 하드웨어 이슈는
  129. 129. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 클라우드 서비스를 이용하면서 거의 탈출했다고 보아도 무방하지만
  130. 130. 관리부담 최소화 • 우리는 바쁘다. • 하드웨어 이슈로부터 탈출 • 쉬운 확장 및 축소 로그 유입량에 따라 시스템을 쉽게 확장하거나 축소할 수 있어야 했습니다.
  131. 131. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 결국, 종합해보면
  132. 132. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 알아서 잘 수집하고 빠르게 조회도하고 분석도할 수 있는 로그 시스템인데요.
  133. 133. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 정말 완벽하게 충족하진 못하더라도
  134. 134. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리가 감수할 수 있는 만큼은 만족하는 시스템이길 바랐습니다.
  135. 135. 알아서 잘 수집하고 빠르게 조회하고 분석할 수 있는 우리에겐 지속적으로 개선할 기회가 있기 때문이죠
  136. 136. #3 로그 시스템 아키텍처 결국 이렇게 로그 시스템을 개발하게 되었습니다.
  137. 137. #3 로그 시스템 아키텍처 저희 로그 시스템은 앞서 말씀드린 목표를 충족하기 위해
  138. 138. #3 로그 시스템 아키텍처 다양한 AWS 서비스와 오픈소스를 사용하였는데요.
  139. 139. #3 로그 시스템 아키텍처 이번에는 로그 시스템이 어떤 아키텍처로 구성되어 있는지 말씀드리려고 합니다.
  140. 140. 수집 조회 분석 로그 시스템을 수집, 조회, 분석으로 크게 3단계로 나누어 보았습니다.
  141. 141. 수집 먼저 로그를 서버에서 수집하고 이를 적재하는 과정까지의 수집단계 입니다.
  142. 142. 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd 로그를 수집하는 파이프라인은 보시는 바와 같이 구성되어 있습니다.
  143. 143. 로그 수집 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd 서버에서 로그가 발생하면 Fluentd에서 로그를 수집하고
  144. 144. 스트림에 전송 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd Fluentd는 Kinesis라는 거대한 스트림으로 전송을 하게 되고
  145. 145. 로그 처리 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd Lambda는 Kinesis에 들어오는 로그들을 처리하여
  146. 146. 저장 수집 파이프라인 게임서버 Kinesis Lambda S3Fluentd S3에 저장하게 됩니다.
  147. 147. 게임서버 Fluentd 먼저 게임서버에서 Fluentd로 로그를 전송하는 부분입니다.
  148. 148. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd Fluentd는 오픈소스 데이터 수집기인데
  149. 149. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 Fluentd Fluentd 성능이 필요한 부분은 C언어로, 확장성이 필요한 부분은 Ruby로 구현되어 있어서
  150. 150. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Fluentd Fluentd 리소스 차지도 매우 적고 빠릅니다.
  151. 151. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 또한 다양한 플러그인을 가지고 있는데요.
  152. 152. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 앞서 보여드렸던 Kinesis에 로그를 전송할 수 있는 플러그인도
  153. 153. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd AWS에서 지원하고 있습니다.
  154. 154. • 오픈소스 데이터 수집기 • C + Ruby • 다양한 플러그인 • 간편한 설정 빠르고 가볍다 Kinesis 플러그인 지원Fluentd Fluentd 마지막으로 비교적 간편하게 설정할 수 있다는 점도 장점이었습니다.
  155. 155. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
  156. 156. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
  157. 157. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 실제로 듀랑고에서 하나의 서버군은 수많은 호스트로 구성이 되어있고
  158. 158. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 여러 개의 노드가 실행됩니다.
  159. 159. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 여기서 용어정리를 잠깐 하자면
  160. 160. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 호스트는 하나의 머신을 의미하고
  161. 161. • 하나의 호스트에는 여러 개의 노드가 실행 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 노드는 각각의 프로세스를 의미합니다.
  162. 162. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 하나의 호스트에는 하나의 Fluentd가 존재해서 노드들의 로그를 수집하는데요.
  163. 163. • 하나의 호스트에는 여러 개의 노드가 실행 • 노드들의 로그를 수집하는 하나의 Fluentd 로그 수집 에이전트의 역할 Fluentd 호스트 노드 노드 노드 호스트 = 머신 노드 = 프로세스 쉽게 말해서 로그 수집 에이전트의 역할을 하고있습니다.
  164. 164. Fluentd Kinesis Fluentd는 이렇게 수집한 로그를 Kinesis라는 곳에 넘기는데요.
  165. 165. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis 여기서 이야기하는 Kinesis는
  166. 166. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream Kinesis AWS의 관리형 서비스중 하나인 Kinesis data stream을 의미합니다.
  167. 167. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 관리형 서비스이다 보니 높은 가용성이 보장되고
  168. 168. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 크게 관리할 것이 없습니다.
  169. 169. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 스트리밍 데이터를 저장하는 거대한 큐 역할을 하는데요.
  170. 170. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 물론 큐는 데이터를 완전히 꺼내버리지만
  171. 171. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis Kinesis는 데이터를 삭제하지 않고 명시된 기간만큼 데이터를 보존합니다.
  172. 172. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 Kinesis 이 기간은 기본적으로 24시간 부터 최대 7일 인데요.
  173. 173. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 기간 동안은 데이터가 삭제되지 않기 때문에
  174. 174. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 만약 데이터를 처리하는 레이어에서 문제가 발생하더라도
  175. 175. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis Kinesis에는 아직 데이터가 남아있어서
  176. 176. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 언제든지 복구가 가능하다는 것을 의미합니다.
  177. 177. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 추가로 Kinesis에는 내부적으로 1개 이상의 샤드로 구성되는데
  178. 178. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 샤드가 무중단으로 확장 및 축소가 가능하고
  179. 179. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 이 것은 결국 로그 유입량에 따라
  180. 180. → 로그 유입량에 따라 유연하게 대응가능 • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis 다운타임 없이 유연하게 대응 가능하다는 것을 의미합니다
  181. 181. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 실제로 이 확장 및 축소는
  182. 182. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 AWS 콘솔에서 클릭 2번으로도 가능하고
  183. 183. • AWS의 관리형 서비스 • 스트리밍 데이터를 저장하는 큐 역할 • 최대 7일동안 데이터 보존 • 데이터 유입량에 따라 무중단 확장 및 축소가능 AWS Kinesis Data Stream → 높은 가용성 → 언제든 복구가능 Kinesis → 로그 유입량에 따라 유연하게 대응가능 저희는 아직 적용하진 않았지만 오토 스케일링도 가능합니다.
  184. 184. LambdaKinesis 이렇게 Kinesis에 데이터들이 들어오면
  185. 185. LambdaKinesis Lambda는 Kinesis에 데이터가 들어왔다는 이벤트를 트리거하여
  186. 186. LambdaKinesis 데이터를 가져와서 처리하는 역할을 합니다.
  187. 187. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 여기서 Lambda는 AWS에서 지원하는 서버리스 컴퓨팅 서비스입니다.
  188. 188. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda Lambda Kinesis stream 트리거 가능 자동으로 확장하거나 축소하기도 하는데
  189. 189. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 때문에 저희가 따로 인프라를 관리할 필요가 없었습니다.
  190. 190. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 Lambda는 Kinesis의 이벤트를 트리거하여 쉽게 연동할 수 있기도 합니다.
  191. 191. • 서버리스 컴퓨팅 서비스 • 자동으로 확장 및 축소 • • 데이터를 처리하는 단계 AWS Lambda → 인프라 관리 불필요 Lambda Kinesis stream 트리거 가능 이렇게 Lambda는 Kinesis의 데이터를 처리하여
  192. 192. Lambda S3 AWS의 저장소인 S3에 저장합니다.
  193. 193. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 실제로 비용만 감당할 수 있다면
  194. 194. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 무한대로 저장할 수 있는 AWS 스토리지 서비스이고
  195. 195. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전의 EC2에서 높은 전송속도를 보장합니다.
  196. 196. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 도쿄 리전에서 테스트한 결과 r4.4xlarge 기준으로 200MB/s 정도 나오더라고요.
  197. 197. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 그리고 높은 데이터 요청 빈도에 대하여 자동으로 확장하기도 합니다.
  198. 198. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 대규모 데이터를 업로드하거나 다운로드하더라도
  199. 199. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 같은 리전에서는 데이터 전송 비용이 무료이기 때문에
  200. 200. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 트래픽에 따른 비용걱정은 하지 않아도 됩니다.
  201. 201. • 무한 용량 • 같은 리전의 EC2에서 높은 전송속도 • 높은 요청 빈도에 대하여 자동확장 • 같은 리전에서 데이터 전송 비용 무료 • 99.99% 가용성 / 99.999999999% 내구성 AWS S3 S3 또한 100퍼센트에 가까운 가용성과 내구성을 보장하고 있습니다.
  202. 202. 조회 여기까지가 저희의 로그 수집 파이프라인입니다.
  203. 203. 조회 다음으로는 로그를 조회하는 단계입니다.
  204. 204. Kinesis Lambda S3 방금 Kinesis에 들어온 로그 데이터를 Lambda가 S3에 저장하고 있다고 설명드렸는데요.
  205. 205. Kinesis Lambda S3 여기에는 사실 하나가 생략되어 있었습니다.
  206. 206. S3Lambda ESLambda Kinesis 저희 로그 시스템에는 하나의 Kinesis를
  207. 207. S3Lambda ESLambda Kinesis 두개의 Lambda가 트리거하고 있는데요.
  208. 208. S3Lambda ESLambda Kinesis 두 번째 Lambda는 Elasticsearch로 데이터를 insert하는 역할을 합니다.
  209. 209. S3Lambda ESLambda Kinesis 여기서 알 수 있는 것은
  210. 210. S3Lambda ESLambda Kinesis Kinesis는 내부적으로 Iterator Id라는 것으로 관리되고 있어서
  211. 211. S3Lambda ESLambda Kinesis 여러 개의 Lambda가 트리거할 수 있습니다.
  212. 212. S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 물론 약간의 제한이 있는데요.
  213. 213. S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) Kinesis에 최대 5개의 읽기 트랜잭션 제한때문인데
  214. 214. S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 이것이 의미하는 건
  215. 215. S3Lambda ESLambda Kinesis 최대 5개의 읽기 트랜잭션 제한 ＝최대 5개의 Lambda 트리거 가능 (+ 읽기 처리량도 고려해야함) 사실상 하나의 Kinesis에 최대 5개의 Lambda만 안정적으로 트리거할 수 있다는 것 입니다.
  216. 216. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 다시 돌아와서, 저희는 실시간 조회를 위해 Elasticsearch를 사용하고 있습니다.
  217. 217. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 Lucene 기반의 분산 검색엔진이고
  218. 218. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 역 인덱스를 이용한 빠른 검색이 가능합니다.
  219. 219. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES Kibana 시각화 도구 제공 그리고 Kibana라는 아주 유용한 시각화 플러그인을 제공합니다.
  220. 220. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 저희는 직접 구축할 수도 있지만
  221. 221. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 AWS에서 제공하는 Elasticsearch를 사용하는데요.
  222. 222. • Lucene 기반의 분산 검색엔진 • 역인덱스를 이용한 빠른 검색가능 • • AWS Elasticsearch Service Elasticsearch ES 완전관리형 서비스 = 가용성, 확장성 등 Kibana 시각화 도구 제공 높은 가용성과 쉽게 확장이 가능하다는 장점이 있습니다.
  223. 223. ES 로그가 늘어날 수록 유지비용 증가 하지만 로그가 늘어날 수록
  224. 224. ES 로그가 늘어날 수록 유지비용 증가 Elasticsearch의 클러스터를 유지하기에는 비용이 점점 늘어날 수 밖에 없는데
  225. 225. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 때문에 저희는 빠르게 조회할 필요성이 있는
  226. 226. ES 로그가 늘어날 수록 유지비용 증가 → 최근 3개월의 로그만 저장 (그 이후는 S3에 저장된 로그를 사용) 최근 3개월만의 로그만 ES에 저장하고 있습니다.
  227. 227. 이 것은 아까 보여드렸던 오류코드입니다.
  228. 228. 저희는 이것을 Elasticsearch의 시각화 도구인 Kibana에서 조회하고 있는데요.
  229. 229. 간단하게 오류코드를 검색하면 해당하는 로그를 찾을 수 있고
  230. 230. 로그가 발생한 호스트 host 로그가 발생한 호스트가 어디인지 알 수 있습니다.
  231. 231. 에러 메시지 message 에러메시지를 확인할 수 있고
  232. 232. Traceback exc_info 어떤 경로로 함수가 호출되었는 지
  233. 233. Traceback exc_info 스택 추적이 가능한 Python Traceback을 제공합니다.
  234. 234. 특정 유형의 로그 검색도 가능 실제로 “Timeout”과 같은 키워드로 검색하여
  235. 235. 특정 유형의 로그 검색도 가능 특정 유형의 로그 검색도 가능합니다.
  236. 236. 특정 유형의 로그 검색도 가능 예제로 보여드렸던 시스템 로그 조회 뿐만 아니라
  237. 237. 특정 유형의 로그 검색도 가능 게임 플레이 로그도 ES에 저장하여 Kibana에서 조회할 수 있도록 사용하고 있습니다.
  238. 238. 오류코드 검색 이 것은 실제로 저희가 Kibana를 통해 특정 오류코드를 검색하는 영상이고요.
  239. 239. 특정 플레이어의 최근 플레이 로그 검색 다음 영상은 저의 최근 게임 플레이 로그를 검색하는 모습입니다.
  240. 240. 수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 이렇게 저희 수집 파이프라인을 다시 요약해보면
  241. 241. 수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 결국 로그는 Fluentd와 Kinesis를 거쳐
  242. 242. 수집 파이프라인 게임서버 Fluentd S3Lambda ESLambda Kinesis 두 개의 Lambda를 통해 S3와 Elasticsearch로 저장되는 것으로 정리할 수 있습니다.
  243. 243. SlideShare에 슬라이드 300장 제한으로 부득이하게 2부로 나누어 올렸습니다. 2부는 아래 링크에서 계속됩니다. https://goo.gl/wpoZpY

×