네이버 로그 저장소 구축 사례

Hbase 사용, 동일한 인터페이스를 제공하는 로그 저장 서비스

로그 유실 이슈

비동기로 저장 완료 시에 응답 하도록 정리함.

• 데이터 중복 이슈
  • 로그성은 불변 데이터임.
    • Hbase 에서 UID로 사용 할 고유 식별자를 무조건 보내도록 인터페이스를 구성함.
      • 시퀀스 발급 서버
        • 병목 가능성때문에 제외
      • 전체 해시
        • 같은 값의 다른 로그는 구분 못하마.
      • UUID
        • 사용자 인터페이스에 UUID 생성 하도록 요구함.

RowKey 디자인

Region	Group	MessageType
위치	서비스 그룹	서비스 로그 유형

시간	IP	variant
생성시간	아이피	특정변수

Hotspot

• 시간 별로 구성 할 때 특정 리전에 로그가 몰릴 수 있음.
• 해당 현상으로 인해 특정 Region으로 로그가 몰릴 수 있는데 이걸 핫 스팟 현상이라 함.

해결 방법

• salt 사용.

로그 데이터 스토어 활용 방안

• 로그 분석이 여태 수동이었음
  • 인간 분석
  • 인간 결재

로그 생성자, 활용자 관련 서비스 구조를 만듬

• 해당 서비스 구조로 인해 개발자 아닌 사용자들이 로그를 접근하게 됨.

SQL Interface

• 그냥 SQL 활용하여 HBASE 쿼리 가능하게끔 만들어 둠.
• SQL 툴 제공, => SQL 직접 받아서 로그 볼 수 있게 함.

SQL 템플릿

• SQL도 힘들어하는 비개발자를 위해 그간 요청된 분석 의뢰건을 분석해서 템플릿을 만듦.
  • HUE 이용

SQL 아카이브

• 내부 깃허브로 요청 날리면 받아서 분석자들이 SQL문만 만들어서 템플릿 형식으로 제공,
  • 세부 파라미터는 요청자가 할용 하도록 열어줌

ORC 포맷

RDBMD 처럼 컬럼이 정해진 데이터 구조 말하는 듯.

2차 테이블

복잡한 로그분석 쿼리들 중에 자주 사용하는 쿼리들 뽑아내서 2차 테이블로 가공 해둠.