NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
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 로그는 쌓아서 뭐하나
먼저 로그시스템이 왜 필요한지,
로그는 왜 쌓고 있는지를 말씀 드리고자 합니다.
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시
관심 있으신 분들은 참관하셔도 좋을 듯합니다.
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. 우리의 지속적 발전을 위한 중요한 도구
결과적으로 이런 로그는
우리의 지속적 발전을 위한 중요한 도구로 사용되고 있는데요.
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
→ 로그 유입량에 따라 유연하게 대응가능
저희는 아직 적용하진 않았지만
오토 스케일링도 가능합니다.
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퍼센트에 가까운
가용성과 내구성을 보장하고 있습니다.
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 시각화 도구 제공
높은 가용성과 쉽게 확장이 가능하다는 장점이 있습니다.