클러스터 배포

클러스터 배포

Apache Druid를 확장 가능하고 장애 허용(fault-tolerant)하는 클러스터로 배포하는 방법을 안내해요. Master·Data·Query 서버로 구성된 예시 클러스터를 설정하고 하드웨어 선택, 메타데이터·deep storage 구성, 서버 시작까지 다뤄요.

출처: 문서

본문

Apache Druid는 확장 가능하고 장애 허용되는 클러스터로 배포되도록 설계됐어요.

이 문서에서 간단한 클러스터를 설정하고, 이를 요구 사항에 맞게 더 구성하는 방법을 논의할 거예요.

이 간단한 클러스터는 다음을 갖출 거예요:

  • Coordinator와 Overlord 프로세스를 호스팅하는 Master 서버
  • Historical과 Middle Manager 프로세스를 실행하는 확장 가능하고 장애 허용하는 Data 서버 두 대
  • Druid Broker와 Router 프로세스를 호스팅하는 Query 서버

프로덕션에서는 특정 장애 허용 요구 사항에 기반해 장애 허용 구성으로 여러 Master 서버와 여러 Query 서버를 배포하는 것을 권장해요. 하지만 Master 하나와 Query 서버 하나로 빠르게 시작하고 나중에 서버를 더 추가할 수 있어요.

하드웨어 선택

새 배포

기존 Druid 클러스터가 없고 클러스터 배포에서 Druid 실행을 시작하려는 경우, 이 가이드는 사전 제작된 구성이 있는 예시 클러스터 배포를 제공해요.

Master 서버

Coordinator와 Overlord 프로세스는 클러스터의 메타데이터와 조정(coordination) 요구를 처리하는 역할을 담당해요. 같은 서버에 함께 배치할 수 있어요.

이 예시에서는 AWS m5.2xlarge 인스턴스 하나에 해당하는 것을 배포할 거예요.

이 하드웨어가 제공하는 것:

  • 8 vCPUs
  • 32 GiB RAM

이 하드웨어에 맞게 크기가 조정된 Master 서버 구성 예시는 conf/druid/cluster/master 아래에서 찾을 수 있어요.

Data 서버

Historical과 Middle Manager를 같은 서버에 배치해 클러스터의 실제 데이터를 처리할 수 있어요. 이 서버들은 CPU, RAM, SSD에서 큰 이점을 얻어요.

이 예시에서는 AWS i3.4xlarge 인스턴스 두 대에 해당하는 것을 배포할 거예요.

이 하드웨어가 제공하는 것:

  • 16 vCPUs
  • 122 GiB RAM
  • 2 * 1.9TB SSD 스토리지

이 하드웨어에 맞게 크기가 조정된 Data 서버 구성 예시는 conf/druid/cluster/data 아래에서 찾을 수 있어요.

Query 서버

Druid Broker는 쿼리를 받아 클러스터의 나머지 부분으로 분산해요. 또한 선택적으로 인메모리 쿼리 캐시를 유지해요. 이 서버들은 CPU와 RAM에서 큰 이점을 얻어요.

이 예시에서는 AWS m5.2xlarge 인스턴스 하나에 해당하는 것을 배포할 거예요.

이 하드웨어가 제공하는 것:

  • 8 vCPUs
  • 32 GiB RAM

오픈소스 UI나 쿼리 라이브러리를 Broker가 실행되는 것과 같은 서버에 함께 배치하는 것을 고려할 수 있어요.

이 하드웨어에 맞게 크기가 조정된 Query 서버 구성 예시는 conf/druid/cluster/query 아래에서 찾을 수 있어요.

기타 하드웨어 크기

위의 예시 클러스터는 Druid 클러스터의 크기를 정하는 많은 가능한 방법 중 하나의 예시로 선택된 거예요.

특정 요구 사항과 제약에 맞게 더 작거나 큰 하드웨어, 또는 서버 수를 늘리거나 줄일 수 있어요.

복잡한 확장 요구 사항이 있는 사용 사례라면 Druid 프로세스를 함께 배치하지 않는 것도 선택할 수 있어요 (예: 독립형 Historical 서버).

basic cluster tuning guide의 정보는 의사 결정 과정과 구성 크기 조정에 도움이 될 수 있어요.

단일 서버 배포에서 마이그레이션

single-server deployment examples 같은 기존 단일 서버 배포가 있고, 비슷한 규모의 클러스터 배포로 마이그레이션하려는 경우, 다음 섹션에 Master/Data/Query 서버 구성으로 동등한 하드웨어를 선택하는 지침이 포함돼 있어요.

Master 서버

Master 서버의 주요 고려 사항은 Coordinator와 Overlord 힙에 사용 가능한 CPU와 RAM이에요.

단일 서버 배포에서 Coordinator와 Overlord에 할당된 힙 크기를 합산하고, 결합된 힙에 충분한 RAM이 있고 머신의 다른 프로세스를 위한 여유 RAM이 있는 Master 서버 하드웨어를 선택해요.

CPU 코어의 경우 단일 서버 배포 코어의 약 1/4에 해당하는 하드웨어를 선택할 수 있어요.

Data 서버

클러스터의 Data 서버 하드웨어를 선택할 때 주요 고려 사항은 사용 가능한 CPU와 RAM이며, 가능하면 SSD 스토리지를 사용하는 것이에요.

클러스터 배포에서는 장애 허용 목적을 위해 여러 Data 서버를 두는 것이 좋아요.

Data 서버 하드웨어를 선택할 때 split factor N 을 선택하고, 단일 서버 배포의 원래 CPU/RAM을 N 으로 나눈 뒤, 새 클러스터에 크기가 줄어든 N 대의 Data 서버를 배포할 수 있어요.

분할을 위한 Historical/Middle Manager 구성을 조정하는 방법은 이 가이드의 후반 섹션에 설명돼 있어요.

Query 서버

Query 서버의 주요 고려 사항은 Broker 힙 + 직접 메모리와 Router 힙에 사용 가능한 CPU와 RAM이에요.

단일 서버 배포에서 Broker와 Router에 할당된 메모리 크기를 합산하고, Broker/Router를 충당하기에 충분한 RAM이 있고 머신의 다른 프로세스를 위한 여유 RAM이 있는 Query 서버 하드웨어를 선택해요.

CPU 코어의 경우 단일 서버 배포 코어의 약 1/4에 해당하는 하드웨어를 선택할 수 있어요.

basic cluster tuning guide에는 Broker/Router 메모리 사용량을 계산하는 방법 정보가 있어요.

OS 선택

선호하는 Linux 배포판 실행을 권장해요. 다음도 필요해요:

  • Java 17
  • Python 3

필요하면 환경 변수 DRUID_JAVA_HOME 또는 JAVA_HOME 을 사용해 Java 위치를 지정할 수 있어요. 자세한 내용은 bin/verify-java 스크립트를 실행하세요.

Java 설치에 대한 정보는 OS 패키지 매니저 문서를 참고하세요. Ubuntu 기반 OS에 충분히 최신 버전의 Java가 없다면, Linux Uprising 이 해당 OS용 패키지를 제공해요.

배포판 다운로드

먼저 릴리스 아카이브를 다운로드하고 압축을 풀어요. 구성을 편집한 후 수정된 배포판을 모든 서버에 복사하게 되므로, 처음에는 단일 머신에서 하는 것이 좋아요.

37.0.0 릴리스를 다운로드하세요.

터미널에서 다음 명령을 실행해 Druid를 압축 해제하세요:

tar -xzf apache-druid-37.0.0-bin.tar.gzcd apache-druid-37.0.0

패키지에서 다음을 찾을 수 있어요:

  • LICENSE 및 NOTICE 파일
  • bin/* - 단일 머신 퀵스타트 관련 스크립트
  • conf/druid/cluster/* - 클러스터 설정용 템플릿 구성
  • extensions/* - 핵심 Druid 확장
  • lib/* - 핵심 Druid의 라이브러리와 의존성
  • quickstart/* - 단일 머신 퀵스타트 관련 파일

실행되도록 conf/druid/cluster/ 의 파일을 편집할 거예요.

단일 서버 배포에서 마이그레이션

다음 섹션에서 conf/druid/cluster 아래의 구성을 편집할 거예요.

기존 단일 서버 배포가 있다면, 기존 구성을 conf/druid/cluster 로 복사해 변경한 구성을 보존하세요.

메타데이터 저장소와 deep storage 구성

단일 서버 배포에서 마이그레이션

기존 단일 서버 배포가 있고 마이그레이션 전반에 걸쳐 데이터를 보존하려면, 메타데이터/deep storage 구성을 업데이트하기 전에 metadata migration 및 deep storage migration 의 지침을 따르세요.

이 가이드는 Derby 메타데이터 저장소와 로컬 deep storage를 사용하는 단일 서버 배포를 대상으로 해요. 단일 서버 클러스터에서 이미 비-Derby 메타데이터 저장소를 사용 중이라면, 기존 메타데이터 저장소를 새 클러스터에 재사용할 수 있어요.

이 가이드는 또한 로컬 deep storage에서 segment를 마이그레이션하는 정보를 제공해요. 클러스터 배포에는 S3나 HDFS 같은 분산 deep storage가 필요해요. 단일 서버 배포가 이미 분산 deep storage를 사용 중이라면, 기존 deep storage를 새 클러스터에 재사용할 수 있어요.

메타데이터 저장소

conf/druid/cluster/_common/common.runtime.properties 에서 "metadata.storage.*" 를 메타데이터 저장소로 사용할 머신의 주소로 교체하세요:

  • druid.metadata.storage.connector.connectURI
  • druid.metadata.storage.connector.host

프로덕션 배포에서는 Druid 서버와 별도로 배포된, 복제가 있는 MySQL이나 PostgreSQL 같은 전용 메타데이터 저장소를 실행하는 것을 권장해요.

MySQL extension 과 PostgreSQL extension 문서에는 확장 구성과 초기 데이터베이스 설정 지침이 있어요.

Deep storage

Druid는 데이터 저장을 위해 분산 파일시스템 또는 대형 객체(blob) 저장소에 의존해요. 가장 일반적으로 사용되는 deep storage 구현은 S3 (AWS 사용자에게 인기)와 HDFS (Hadoop 배포가 이미 있다면 인기)예요.

S3

conf/druid/cluster/_common/common.runtime.properties 에서,

  • druid.extensions.loadList 에 "druid-s3-extensions" 를 추가해요.
  • "Deep Storage"와 "Indexing service logs" 아래의 로컬 저장소 구성을 주석 처리해요.
  • "Deep Storage"와 "Indexing service logs"의 "For S3" 섹션에서 적절한 값을 주석 해제하고 구성해요.

이후 다음 변경을 수행해야 해요:

druid.extensions.loadList=["druid-s3-extensions"]#druid.storage.type=local#druid.storage.storageDirectory=var/druid/segmentsdruid.storage.type=s3druid.storage.bucket=your-bucketdruid.storage.baseKey=druid/segmentsdruid.s3.accessKey=...druid.s3.secretKey=...#druid.indexer.logs.type=file#druid.indexer.logs.directory=var/druid/indexing-logsdruid.indexer.logs.type=s3druid.indexer.logs.s3Bucket=your-bucketdruid.indexer.logs.s3Prefix=druid/indexing-logs

자세한 내용은 S3 extension 문서를 참고하세요.

HDFS

conf/druid/cluster/_common/common.runtime.properties 에서,

  • druid.extensions.loadList 에 "druid-hdfs-storage" 를 추가해요.
  • "Deep Storage"와 "Indexing service logs" 아래의 로컬 저장소 구성을 주석 처리해요.
  • "Deep Storage"와 "Indexing service logs"의 "For HDFS" 섹션에서 적절한 값을 주석 해제하고 구성해요.

이후 다음 변경을 수행해야 해요:

druid.extensions.loadList=["druid-hdfs-storage"]#druid.storage.type=local#druid.storage.storageDirectory=var/druid/segmentsdruid.storage.type=hdfsdruid.storage.storageDirectory=/druid/segments#druid.indexer.logs.type=file#druid.indexer.logs.directory=var/druid/indexing-logsdruid.indexer.logs.type=hdfsdruid.indexer.logs.directory=/druid/indexing-logs

또한,

  • Hadoop 구성 XML(core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml)을 Druid 프로세스의 클래스패스에 배치하세요. conf/druid/cluster/_common/ 에 복사해 이 작업을 할 수 있어요.

자세한 내용은 HDFS extension 문서를 참고하세요.

Zookeeper 연결 구성

프로덕션 클러스터에서는 Druid 서버와 별도로 배포된 쿼럼의 전용 ZK 클러스터를 사용하는 것을 권장해요.

conf/druid/cluster/_common/common.runtime.properties 에서 druid.zk.service.host 를 ZK 쿼럼의 각 ZooKeeper 서버에 해당하는 host :port 쌍의 쉼표로 구분된 목록이 포함된 연결 문자열로 설정하세요 (예: "127.0.0.1:4545" 또는 "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002").

전용 ZK 클러스터를 두는 대신 Master 서버에서 ZK를 실행하도록 선택할 수도 있어요. 그렇게 한다면 ZK 쿼럼을 위해 Master 서버 3대를 배포하는 것을 권장해요.

구성 튜닝

단일 서버 배포에서 마이그레이션

Master

single-server deployment examples 의 예시 구성을 사용한다면, 이 예시들은 Coordinator와 Overlord 프로세스를 하나의 결합된 프로세스로 결합해요.

conf/druid/cluster/master/coordinator-overlord 아래의 예시 구성도 Coordinator와 Overlord 프로세스를 결합해요.

단일 서버 배포의 기존 coordinator-overlord 구성을 conf/druid/cluster/master/coordinator-overlord 로 복사할 수 있어요.

Data

32 CPU와 256GiB RAM을 가진 단일 서버 배포에서 마이그레이션한다고 가정해요. 이전 배포에서 Historical과 Middle Manager에 다음 구성이 적용됐었어요:

Historical (단일 서버)

druid.processing.buffer.sizeBytes=500MiBdruid.processing.numMergeBuffers=8druid.processing.numThreads=31

Middle Manager (단일 서버)

druid.worker.capacity=8druid.indexer.fork.property.druid.processing.numMergeBuffers=2druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100MiBdruid.indexer.fork.property.druid.processing.numThreads=1

클러스터 배포에서 split factor(이 예시에서는 2)를 선택하고, 각각 16CPU와 128GiB RAM의 Data 서버 2대를 배포할 수 있어요. 확장할 영역은 다음과 같아요:

Historical

  • druid.processing.numThreads : 새 하드웨어에 기반해 (num_cores - 1) 로 설정
  • druid.processing.numMergeBuffers : 단일 서버 배포의 이전 값을 split factor로 나누기
  • druid.processing.buffer.sizeBytes : 변경 없이 유지

Middle Manager:

  • druid.worker.capacity : 단일 서버 배포의 이전 값을 split factor로 나누기
  • druid.indexer.fork.property.druid.processing.numMergeBuffers : 변경 없이 유지
  • druid.indexer.fork.property.druid.processing.buffer.sizeBytes : 변경 없이 유지
  • druid.indexer.fork.property.druid.processing.numThreads : 변경 없이 유지

분할 후의 결과 구성:

새 Historical (2대의 Data 서버에서)

druid.processing.buffer.sizeBytes=500MiBdruid.processing.numMergeBuffers=4druid.processing.numThreads=15

새 Middle Manager (2대의 Data 서버에서)

druid.worker.capacity=4druid.indexer.fork.property.druid.processing.numMergeBuffers=2druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100MiBdruid.indexer.fork.property.druid.processing.numThreads=1

Query

기존 Broker와 Router 구성을 conf/druid/cluster/query 아래의 디렉토리로 복사할 수 있어요. 새 하드웨어가 그에 맞게 크기가 정해진다면 수정이 필요 없어요.

새 배포

위에서 설명한 예시 클러스터를 사용한다면:

  • Master 서버 1대 (m5.2xlarge)
  • Data 서버 2대 (i3.4xlarge)
  • Query 서버 1대 (m5.2xlarge)

conf/druid/cluster 아래의 구성은 이미 이 하드웨어에 맞게 크기가 정해져 있으며, 일반적인 사용 사례에서 추가 수정이 필요하지 않아요.

다른 하드웨어를 선택했다면 basic cluster tuning guide가 구성을 크기 조정하는 데 도움이 될 수 있어요.

포트 열기 (방화벽 사용 시)

방화벽이나 특정 포트에서만 트래픽을 허용하는 다른 시스템을 사용하는 경우, 다음에 대한 인바운드 연결을 허용하세요:

Master Server

  • 1527 (Derby 메타데이터 저장소; MySQL이나 PostgreSQL 같은 별도 메타데이터 저장소를 사용한다면 불필요)
  • 2181 (ZooKeeper; 별도 ZooKeeper 클러스터를 사용한다면 불필요)
  • 8081 (Coordinator)
  • 8090 (Overlord)

Data Server

  • 8083 (Historical)
  • 8091, 8100–8199 (Druid Middle Manager; 매우 높은 druid.worker.capacity 가 있다면 포트 8199보다 높은 포트가 필요할 수 있어요)

Query Server

  • 8082 (Broker)
  • 8088 (Router, 사용하는 경우)

프로덕션에서는 Master 서버가 아닌 전용 하드웨어에 ZooKeeper와 메타데이터 저장소를 배포하는 것을 권장해요.

Master 서버 시작

Druid 배포판과 편집한 구성을 Master 서버로 복사하세요.

로컬 머신에서 구성을 편집했다면 rsync 를 사용해 복사할 수 있어요:

rsync -az apache-druid-37.0.0/ MASTER_SERVER:apache-druid-37.0.0/

Master에 Zookeeper 없음

배포판 루트에서 다음 명령을 실행해 Master 서버를 시작하세요:

bin/start-cluster-master-no-zk-server

Master에 Zookeeper 포함

Master 서버에서 ZK를 실행할 계획이라면, 먼저 conf/zoo.cfg 를 업데이트해 ZK 실행 방식을 반영하세요. 그런 다음 ZK와 함께 Master 서버 프로세스를 시작할 수 있어요:

bin/start-cluster-master-with-zk-server

프로덕션에서도 자체 전용 하드웨어에 ZooKeeper 클러스터를 실행하는 것을 권장해요.

Data 서버 시작

Druid 배포판과 편집한 구성을 Data 서버로 복사하세요.

배포판 루트에서 다음 명령을 실행해 Data 서버를 시작하세요:

bin/start-cluster-data-server

필요에 따라 Data 서버를 더 추가할 수 있어요.

복잡한 리소스 할당 요구가 있는 클러스터의 경우 Historical과 Middle Manager를 분리하고 구성 요소를 개별적으로 확장할 수 있어요. 이렇게 하면 Druid에 내장된 Middle Manager 자동 확장 기능도 활용할 수 있어요.

Query 서버 시작

Druid 배포판과 편집한 구성을 Query 서버로 복사하세요.

배포판 루트에서 다음 명령을 실행해 Query 서버를 시작하세요:

bin/start-cluster-query-server

쿼리 부하에 따라 필요에 따라 Query 서버를 더 추가할 수 있어요. Query 서버 수를 늘린다면 basic cluster tuning guide 에 설명된 대로 Historical과 Tasks의 연결 풀을 조정해야 해요.

데이터 로드

축하합니다, 이제 Druid 클러스터가 생겼어요! 다음 단계는 사용 사례에 따라 Druid에 데이터를 로드하는 권장 방법을 배우는 것이에요. loading data 에 대해 더 읽어보세요.

더 알아보기 (Learn more)