궁금하면 드루와요 | Druid Tiering

Part.4 Druid Tiering: 데이터가 조회되는 빈도 기준으로 데이터를 구분

 

---

 

Part.1 Apache Druid란(링크)

Part.2 Druid Operator: 드루이드 오퍼레이터 도입으로 드루이드 설치부터 관리까지의 과정 개선 (링크)

Part.3 Druid Tuning: 제한된 자원속에서 카프카 스트림으로부터 데이터 수집하는 기능(성능)의 최적화(링크)

Part.4 Druid Tiering: 데이터가 조회되는 빈도 기준으로 데이터를 구분

Part.5 Druid without Middle Manager (MM less): k8s 리소스(파드)를 사용한 드루이드 태스크 관리 개선

---

 

이번 글에서는 Apache Druid의 티어링 시스템과 필요성을 알아보고, Druid에서 데이터 티어링을 설정하는 구체적인 방법을 살펴보겠습니다.

 

 

드루이드 티어링 시스템의 개요

데이터 티어링은 데이터의 접근 빈도에 따라 데이터를 다양한 스토리지 계층에 할당하는 방법입니다. 접근 빈도가 높은 데이터는 ‘hot’ 티어, 접근 빈도가 낮은 데이터는 ‘cold’ 티어라 불리는 스토리지에 유지합니다.

 

Druid의 티어링은 Broker, Historical에서 가능하고, 주로 Historical 서비스에서 이루어지면 데이터의 접근 빈도에 따라 분류합니다.

Druid는 데이터 소스별로 세그먼트를 관리하기 때문에 데이터 소스별 티어링 설정도 가능합니다. 또한 broker 티어링을 사용할 경우 라우터에서 특정 broker로 쿼리를 라우팅 하는 쿼리 최적화도 가능합니다.

 

 

Datasaker의 데이터 티어링 배경

티어링 도입 전, Datasaker의 데이터 보존 기간이 길지 않았고 처리하는 데이터 양이 많지 않았기 때문에 하나의 티어(default)만 사용했습니다.

하지만 데이터 보존 기간이 늘어나고 Druid에 저장되는 데이터 양이 많아지면서 문제가 발생했습니다. 오래된 데이터를 조회하거나 간혹 Scan 쿼리가 실행되면 timeout이 발생하거나 다른 쿼리의 실행 속도에도 영향을 주기 시작했습니다. Multi Historical 노드를 사용함에도 이런 문제가 발생하자 데이터 티어링을 결정했습니다.

 

 

Datasaker의 데이터 티어링 적용

Datasaker에서는 시계열 데이터를 주로 다루기 때문에 시간을 기준으로 티어를 나누었고 ‘hot’, ‘cold’ 명칭을 사용했습니다. 또한 데이터 소스별로 다른 티어링 구성을 사용했습니다. 예를 들어 A 데이터 소스는 하루치 데이터가 ‘hot’ 티어라면 B 데이터 소스는 6시간 데이터가 ‘hot’ 티어가 되도록 했습니다.

 

티어를 구분하기 위해 다음과 같은 것들을 고려했습니다.

 

1. 데이터 소스별로 다른 티어링 전략을 가져갈 것인가.
2. 티어는 어떻게 구분할 것인가. 예) hot + cold, hot + warm + cold
3. 데이터 소스별로 어떤 시간을 기준으로 티어를 나눌 것인가

 

데이터 양과 보존 기간이 달랐기 때문에 `데이터 소스별로 다른 티어링 전략`은 크게 고민할 것이 없습니다. 반면 `데이터 소스 별 시간 기준`은 Druid에서 데이터를 조회하는 API나 UI에서 필요로 하는 기준이 달랐기 때문에 여러 번 수정이 필요했습니다.

 

 

Druid 티어링 방법

Druid에서 티어링을 적용하는 방법을 알아보겠습니다.

먼저 데이터소스 별로 접근 빈도가 높은 세그먼트를 기준으로 티어를 구분합니다. 접근 빈도가 높은 세그먼트는 ‘hot’ 티어, 그 외의 세그먼트는 ‘cold’ 티어가 되도록 설정할 수 있습니다.

 

다음은 구분된 티어 기준으로 설정을 변경합니다. 변경이 필요한 부분은 Historical 설정 파일, 세그먼트 load rule 두 가지 입니다.

 

먼저 Historical 설정 파일입니다. 설정 파일에서는 단순히 Historical 서비스 설정에서 사용할 티어를 설정합니다.

 

druid.server.tier=<티어 이름>
# druid.server.tier=hot
# druid.server.tier=cold

 

 

이렇게 설정된 Historical 서비스는 설정된 티어로 실행됩니다.

 

다음은 load rule입니다.입니다 load rule은 UI를 이용하거나 JSON 설정으로 변경할 수 있습니다. 설정을 위해 먼저 UI의 데이터 소스 탭에서 티어를 지정할 데이터 소스의  “Edit retention rules”를 클릭합니다.

 

 

먼저 JSON 설정입니다.

 

{
    "period": "PT12H",
    "includeFuture": true,
    "tieredReplicants": {
      "hot": 1
    },
    "useDefaultTierForNull": true,
    "type": "loadByPeriod"
},

 

여기서 신경 써야 할 부분은 'type', 'tieredReplicants', 'period'입니다. 'type'에 따라 'tieredReplicants'에 설정한 티어에 저장할 데이터의 시간 범위를 'period'에 작성합니다.

 

예를 들어, 수집 시간 ~ 과거 12 시간의 데이터는 'hot' 티어, 과거 12시간 ~  과거 72 시간의 데이터는 'cold' 티어에 저장한다면 다음처럼 설정할 수 있습니다.

[
  {
    "period": "PT12H",
    "includeFuture": true,
    "tieredReplicants": {
      "hot": 1
    },
    "useDefaultTierForNull": true,
    "type": "loadByPeriod"
  },
  {
    "period": "PT72H",
    "includeFuture": true,
    "tieredReplicants": {
      "cold": 1
    },
    "useDefaultTierForNull": true,
    "type": "loadByPeriod"
  },
  {
    "type": "dropForever"
  }
]

 

 

마지막의 "type": "dropForever"은 'hot', 'cold' 티어에 저장하는 시간 범위 밖의 데이터에 대한 처리입니다.

 

 

UI에서 변경하는 방법

UI에서의 설정은 JSON에서 했던 것과 같습니다. 한 가지 주의할 점은 정의된 rule을 위에서부터 아래로 내려가면서 일치하는 rule이 있을 경우 해당 rule을 적용하기 때문에, 시간상 앞에 있는 rule이 위에 와야 합니다.

 

 

 

마치며

티어별로 데이터를 분류함으로써 접근 빈도가 높은 데이터는 빠른 응답을 위해 'hot' 티어에, 반면 접근 빈도가 낮은 오래된 데이터는 비용 효율적인 'cold' 티어에 저장함으로써 전체 시스템의 성능과 운영 비용을 최적화할 수 있습니다.

 

 

 

 

글 | 통합개발본부 플랫폼 3팀 박준수님, 윤혁준님