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