Part.2 Druid Operator

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 리소스(파드)를 사용한 드루이드 태스크 관리 개선

Druid Operator란

Druid Operator는 쿠버네티스에서 실행 중인 드루이드 클러스터를 관리하는 도구입니다. 쿠버네티스 오퍼레이터 패턴을 따라 사용자 정의 리소스를 사용하여 요구에 맞게 드루이드 클러스터를 유지합니다.

먼저 드루이드 오퍼레이터가 어떤 방식으로 작동하는지 살펴보겠습니다.

드루이드 오퍼레이터는 Druid라는 별도의 사용자 지정 리소스(CRD)를 생성해 드루이드를 관리합니다.

사용자가 CRD 정의에 맞게 리소스 스펙을 정의하면, 드루이드 오퍼레이터가 작성된 오브젝트(드루이드)를 관리합니다.

오퍼레이트는 주기적으로 사용자가 작성한 리소스 스펙대로 드루이가 실행 중인지 확인하며 상태를 조정합니다.

1. Druid Operator 주요 기능 소개

Rolling Deploy(Update)

드루이드에서 권장하는 서비스 업데이트 순서에 맞게 드루이드 서비스를 재시작합니다.

Orphan pvc 관리

Statefulset이 다운될 경우 파드는 종료되지만, 연관된 PVC를 사용하지 않아 Orphan pvc로 남는 경우 오퍼레이터는 이런 PVC를 삭제합니다.

파드 스케일링

드루이드 노드의 HPA 오토 스케일링을 지원합니다.

1-1. 드루이드 오퍼레이터 도입 배경

Datasaker는 쿠버네티스상에서 드루이드를 운영 중입니다. 운영하면서 드루이드 클러스터 상태를 관리하는데 어려움이 있었습니다. 개발 계에서 운영 중인 드루이드 클러스터는 여러 테스트를 진행하느라 업데이트가 빈번하게 발생하는데, 매번 각 서비스를 재시작하는데 많은 시간이 소요됐습니다. 드루이드의 서비스는 메타 데이터로 서로의 상태를 공유하기 때문에 드루이드 버전 변경과 같은 업데이트 시 서비스의 재시작 순서를 맞춰야 했습니다.

업데이트 과정을 수동으로 진행하다 보니 소요되는 시간이 클뿐더러 인적 실수로 발생하는 문제들이 있었습니다. 현재 운영 중인 클러스터가 크지 않아 짧은 시간 안에 대처할 수 있었지만, 향후 클러스터 크기가 커질 때의 비용을 생각했을 때 이런 과정을 자동으로 진행해 줄 오퍼레이터의 도입 필요성을 느꼈습니다.

오퍼레이터가 제공하는 여러 기능 중, 저희의 요구를 가장 잘 충족시켜 줄 기능은 Rolling Deploy였습니다. Rolling Deploy에 대한 설명과 오퍼레이터 설치 후 테스트까지의 과정을 설명하겠습니다.

Rolling Deploy(Update)

오퍼레이터를 도입한 이유입니다.

앞서 소개한 대로 Rolling Deploy는 드루이드 클러스터 업데이트 시 드루이드에서 권장하는 업데이트 순서에 맞춰 서비스를 재시작합니다. 권장되는 순서는 Historical -> Overlord -> Middle manager -> Broker -> Coordinator -> Router입니다.

각 드루이드의 서비스는 다른 서비스에 영향을 주기 때문에 실행 중인 태스크와 드루이드 클러스터를 정상적으로 유지하며 업데이트하기 위해서는 권장 순서를 지켜야 합니다.

수동으로 업데이트 진행 시 다음과 같은 불편함이 있습니다.

순서에 맞게 한 번에 하나의 서비스만 업데이트해야 하며 업데이트된 서비스가 정상적으로 실행되는 것을 확인 후 다음 서비스를 업데이트해야 합니다.

하나의 서비스만 업데이트할 경우, 순서상 해당 서비스의 뒤에 오는 서비스들도 재시작해야 합니다. 예를 들어 broker의 Druid option을 변경해 업데이트하는 경우, 순서 상 뒤에 오는 coordinator와 router도 재시작이 필요합니다.

(2)의 순서가 틀리면 서비스를 재시작해야 합니다.

오퍼레이터는 순서에 맞게 서비스를 차례대로 업데이트하기 때문에 사용자가 신경 쓸 부분이 줄고 소요 시간 또한 감소합니다. 오퍼레이터 도입 후 최대 20분 걸리던 작업 시간이 5분 이내로 감소했고 업데이트 시 발생하는 각종 인적 실수 또한 사라졌습니다.

2. 오퍼레이터 사용 예시

오퍼레이터 설치부터 드루이드 클러스터 rolling update 예시를 보여드리겠습니다. 쿠버네티스 사용이 어려운 경우 minikube를 이용해 설치할 수 있습니다. 예시는 minikube를 이용했습니다. 필요한 예제 파일은 [여기]에서 찾을 수 있으며, druid operator github에서도 찾을 수 있습니다.