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

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차 테이블로 가공 해둠.