Page History

분석에 사용되는 데이터의 종류

• 시스템로그
• 어플리케이션로그
• RDB에 적재된 중요 데이터
• 사용자유입및 트래킹로그
• 중요이벤트(결제,취소등)
• 크롤링데이터: 내부서비스에서 생산하지 못하는정보  

시스템로그와 어플리케이션로그를 간과하는 경우가 많습니다. 로그 설계가 잘되어있으면

중요이벤트및 성능향상을 위한 유입측정등 많은 분석이 가능합니다.

성능을 위해 로그레벨을 경고이상에서만 적는다.란 정책이 아무렇지 않게 결정되는것을 봤으며

이것은 아주 무지한 정책입니다. 당연히 시스템로그와 인포레벨의 어플리케이션로그는 실제로

가장큰 빅데이터가 되며, 정의한것만 빅데이터화를 한다고하면 분석의 대처가 늦어져서 

실제로 쓰임새가 있기까지 오랜시간이 걸리게됩니다. 빅데이터의 원초 목적은 이것이 쓸모있는가?

없는가? 파악이안되는 모든 데이터를 가지고 의미있는 데이터로 분석을 하는과정이라고 봅니다. 

그래서 저장소및 분석툴을 각각 전략별로 분리를하고 그것을 다시 통합하여 분석할수 있는

분석툴이 있어야된다라고 봅니다.  

저장소분리

• RDB
• 시스템로그
• 어플리케이션로그
• 사용자 유입로그

도메인별로 중요도는 다르며 RDB에 저장되는 데이터가 항상 중요하다라고 볼수 없습니다.

사용자정보를 가지고 있지않고, 사용자의 유입랭킹을 분석하여 트랜드를 제공하는 서비스라고 가정을 하면

그 서비스는 사용자의 유입로그가 가장 중요한 데이터입니다.

분석툴

• 엘라스틱서치/Splunk : 주로 어플리케이션 로그를 분석하여 의미있는 데이터를 찾기위한 용도 (BI가 주로사용) 
• OpenNMS : 주로 시스템을 포함한 어플리케이션 모니터링을 위한툴이며 엘라스틱서치와도 연동이 되도록함 (데브옵스가 주로사용)
• SPARK/주피터 : 의미있는 빅데이터의 분석을 얼마나 빠르게하고 사용자에게 적절하게 제공할지 고민이 포함된 분석툴 (BA를 포함한 서비스개발자가 주로사용)

결제량별 네트워크 트리픽이란 문제를 풀기위해서 저장소관점에서

결제건수가 있는 저장소와 네트워크 트래픽을 시간별로 저장하는 저장소가 다르며

이것은 OpenNMS와 연동되는 엘라스틱서치의 키바나기능으로 시각화가 가능하며 실제로 중요한 분석결과입니다.

하지만 사용자에게 제공되는 리포팅은 아니기때문에 SPARK이 이용될 필요는 없습니다.

사용자의 결제에따른, 결제전 인기 카테고리를 분석하여 실시간으로 미리 추천하는 문제를 풀기위해

사용자의 반응에 반응하여 빅데이터를 매번 분석하는것은 올바르지 않습니다. 그때 SPARK을 활용합니다.