병렬 운영 전략
- 위험 최소화: 두 시스템을 동시에 운영하면 ClickStack을 검증하고 사용자가 새 시스템에 익숙해지는 동안에도 기존 데이터와 대시보드에 계속 접근할 수 있습니다.
- 자연스러운 데이터 만료: 대부분의 관측성 데이터는 보존 기간이 제한적이며(일반적으로 30일 이하), Elastic의 데이터가 만료되면서 자연스럽게 전환할 수 있습니다.
- 간소화된 마이그레이션: 시스템 간 과거 데이터를 옮기기 위한 복잡한 데이터 전송 도구나 프로세스가 필요하지 않습니다.
데이터 마이그레이션Elasticsearch에서 ClickHouse로 필수 데이터를 마이그레이션하는 방법은 “데이터 마이그레이션” 섹션에서 설명합니다. 다만 이 방식은 대규모 데이터셋에는 권장하지 않습니다. Elasticsearch의 내보내기 성능에 제약이 있고 JSON 포맷만 지원되므로, 충분한 성능을 내는 경우가 드물기 때문입니다.
구현 단계
이중 수집 구성
데이터 수집 파이프라인을 설정하여 데이터를 Elastic과 ClickStack으로 동시에 전송합니다.구성 방법은 현재 사용 중인 수집 에이전트에 따라 달라집니다. “Migrating Agents”를 참조하십시오.검증 및 비교
- 두 시스템에서 모두 쿼리를 실행하여 데이터 일관성을 확인합니다
- 쿼리 성능과 결과를 비교합니다
- 대시보드와 알림을 ClickStack으로 마이그레이션합니다. 이 작업은 현재 수동으로 수행해야 합니다.
- 모든 핵심 대시보드와 알림이 ClickStack에서 예상대로 작동하는지 확인합니다
점진적 전환
- 데이터가 Elastic에서 자연스럽게 만료되면서 점차 ClickStack에 더 많이 의존하게 됩니다
- ClickStack에 대한 신뢰가 확보되면 쿼리와 대시보드를 점진적으로 전환할 수 있습니다
장기 보존
- Elastic에서 모든 데이터가 만료될 때까지 두 시스템을 계속 병렬로 운영합니다.
- ClickStack의 계층형 스토리지 기능을 활용하면 장기 데이터를 효율적으로 관리할 수 있습니다.
- 원시 데이터는 만료되도록 두면서 집계되거나 필터링된 이력 데이터를 유지하려면 구체화된 뷰(Materialized View) 사용을 고려하십시오.
마이그레이션 일정
- 30일 보존: 마이그레이션은 한 달 이내에 완료할 수 있습니다.
- 더 긴 보존 기간: 데이터가 Elastic에서 만료될 때까지 병렬 운영을 계속하십시오.
- 과거 데이터: 꼭 필요한 경우에만 데이터 마이그레이션을 사용해 특정 과거 데이터를 가져오는 방안을 고려하십시오.
설정 마이그레이션
권장 설정
- ClickHouse Cloud: 기본적으로 단일 세그먼트, 다중 레플리카 아키텍처를 사용합니다. 스토리지와 컴퓨트가 독립적으로 스케일링되므로, 수집 패턴을 예측하기 어렵고 읽기 중심의 워크로드가 많은 관측성 사용 사례에 적합합니다.
- ClickHouse OSS: 자가 관리형 배포에서는 다음을 권장합니다.
- 단일 세그먼트로 시작
- CPU와 RAM을 추가하여 수직으로 스케일링
- 계층형 스토리지를 사용하여 S3 호환 객체 스토리지로 로컬 디스크를 확장
- 고가용성이 필요한 경우
ReplicatedMergeTree사용 - 장애 허용을 위해서는 관측성 워크로드에서 일반적으로 세그먼트당 레플리카 1개면 충분합니다.
세그먼트 분할이 필요한 경우
- 수집 속도가 단일 노드의 처리 용량을 초과하는 경우(일반적으로 초당 500K행 초과)
- 테넌트 격리 또는 리전별 데이터 분리가 필요한 경우
- 객체 스토리지를 사용하더라도 전체 데이터셋이 단일 서버에 저장하기에는 너무 큰 경우
보존 및 TTL
- 만료된 데이터를 자동으로 삭제
- 오래된 데이터를 콜드 객체 스토리지로 이동
- 최근 데이터 중 자주 조회되는 로그만 고속 디스크에 유지
데이터 마이그레이션
- 데이터 보강에 사용하는 소규모 조회 테이블(예: 사용자 매핑, 서비스 카탈로그)
- 관측성 데이터와 연관시켜야 하는 Elasticsearch의 비즈니스 데이터. ClickHouse는 SQL 기능과 비즈니스 인텔리전스 통합을 제공하므로, Elasticsearch의 제한적인 쿼리 옵션에 비해 데이터를 유지 관리하고 쿼리하기가 더 쉽습니다.
- 마이그레이션 과정 전반에서 보존해야 하는 구성 데이터
스키마 마이그레이션
Elasticsearch에서 마이그레이션할 인덱스에 대한 테이블을 ClickHouse에 생성하십시오. Elasticsearch 타입을 ClickHouse 동등 타입으로 매핑할 수 있습니다. 또는 ClickHouse의 JSON 데이터 타입을 활용하면, 데이터가 삽입될 때 적절한 타입의 컬럼이 동적으로 생성됩니다.syslog 데이터를 포함하는 인덱스에 대한 다음 Elasticsearch 매핑을 확인하십시오.Elasticsearch 매핑
Elasticsearch 매핑
ClickHouse 스키마
ClickHouse 스키마
- 중첩 구조는 점 표기법 대신 튜플로 표현합니다
- 매핑에 따라 적절한 ClickHouse 타입을 사용했습니다:
keyword→Stringdate→DateTimeboolean→UInt8long→Int64ip→Array(Variant(IPv4, IPv6)). 이 필드에는IPv4와IPv6가 혼재되어 있으므로 여기서는Variant(IPv4, IPv6)를 사용합니다.object→ 구조를 예측할 수 없는 syslog 객체에는JSON을 사용합니다.
host.ip및host.mac컬럼은 Elasticsearch에서 모든 타입이 배열로 취급되는 것과 달리, 명시적인Array타입입니다.- 시간 기반 쿼리를 효율적으로 처리할 수 있도록 timestamp와 호스트명을 사용한
ORDER BY절이 추가됩니다 - 로그 데이터에 최적화된
MergeTree를 엔진 유형으로 사용합니다
- 데이터 검증 – 특정 구조를 제외하면 엄격한 스키마를 적용해 컬럼 폭증 위험을 방지할 수 있습니다.
- 컬럼 폭증 위험 방지: JSON 타입은 서브컬럼이 전용 컬럼으로 저장되는 방식으로 잠재적으로 수천 개의 컬럼까지 확장될 수 있지만, 이 경우 지나치게 많은 컬럼 파일이 생성되는 컬럼 파일 폭증으로 이어져 성능에 영향을 줄 수 있습니다. 이를 완화하기 위해 JSON의 기반이 되는 Dynamic 타입은
max_dynamic_paths매개변수를 제공하며, 이 매개변수는 별도의 컬럼 파일로 저장되는 고유 경로 수를 제한합니다. 임계값에 도달하면 추가 경로는 compact 인코딩 포맷을 사용하는 공유 컬럼 파일에 저장되므로, 유연한 데이터 수집을 지원하면서도 성능과 스토리지 효율성을 유지할 수 있습니다. 다만 이 공유 컬럼 파일에 접근할 때는 성능이 전용 컬럼만큼 좋지 않습니다. 하지만 JSON 컬럼은 타입 힌트와 함께 사용할 수도 있습니다. “힌트가 지정된” 컬럼은 전용 컬럼과 동일한 성능을 제공합니다. - 경로와 타입을 더 간단히 내부 검사: JSON 타입은 추론된 타입과 경로를 확인하기 위한 인트로스펙션 함수를 지원하지만, 정적 구조는 예를 들어
DESCRIBE로 더 쉽게 살펴볼 수 있습니다.
또는
JSON 컬럼 하나로 테이블을 간단히 생성할 수도 있습니다.정렬/프라이머리 키(primary key)에서 이를 사용하므로 JSON 정의에서
host.name 및 timestamp 컬럼에 유형 힌트를 제공합니다. 이렇게 하면 ClickHouse가 이 컬럼이 NULL이 될 수 없음을 파악할 수 있고, 어떤 서브컬럼(sub-columns)을 사용해야 하는지도 알 수 있습니다(유형마다 여러 개가 있을 수 있으므로, 그렇지 않으면 모호해집니다).JSON을 사용하십시오.스키마에서 JSON 타입을 사용하는 방법과 이를 효율적으로 적용하는 방법에 대한 자세한 내용은 “스키마 설계” 가이드를 참조하십시오.elasticdump 설치
Elasticsearch에서 데이터를 내보낼 때는 elasticdump를 권장합니다. 이 도구를 사용하려면 node가 필요하며, Elasticsearch와 ClickHouse 모두에 네트워크 지연이 낮은 머신에 설치해야 합니다. 대부분의 내보내기 작업에는 최소 4코어와 16GB RAM을 갖춘 전용 서버를 권장합니다.elasticdump는 데이터 마이그레이션에 몇 가지 장점이 있습니다:- Elasticsearch REST API와 직접 통신하므로 데이터를 정확하게 내보낼 수 있습니다.
- Point-in-Time (PIT) API를 사용해 내보내기 과정에서 데이터 일관성을 유지합니다. 즉, 특정 시점의 일관된 데이터 스냅샷을 생성합니다.
- 데이터를 JSON 포맷으로 직접 내보내므로, 이를
ClickHouse client로 스트리밍해 삽입할 수 있습니다.
elastic dump를 모두 동일한 가용 영역 또는 데이터 센터에서 실행하는 것이 좋습니다.ClickHouse client 설치
elasticdump가 있는 서버에 ClickHouse를 설치했는지 확인하십시오. ClickHouse 서버는 시작하지 마십시오. 이 단계에는 클라이언트만 필요합니다.데이터 스트리밍
Elasticsearch와 ClickHouse 간에 데이터를 스트리밍하려면elasticdump 명령을 사용해 출력을 clickhouse client로 직접 파이프하세요. 다음 예제에서는 데이터를 잘 구조화된 테이블 logs_system_syslog에 삽입합니다.elasticdump에서 다음 플래그를 사용한다는 점에 유의하십시오:type=data- 응답을 Elasticsearch의 문서 내용으로만 제한합니다.input-index- Elasticsearch 입력 인덱스입니다.output=$- 모든 결과를 stdout으로 리디렉션합니다.sourceOnly플래그 - 응답에서 메타데이터 필드를 제외합니다.searchAfter플래그 - 결과를 효율적으로 페이지네이션하기 위해searchAfterAPI를 사용합니다.pit=true- point in time API를 사용해 쿼리 간 일관된 결과를 보장합니다.
여기서 사용하는 ClickHouse client 매개변수는 다음과 같습니다(자격 증명 제외):
max_insert_block_size=1000- 이 행 수에 도달하면 ClickHouse client가 데이터를 전송합니다. 값을 늘리면 처리량은 향상되지만 block을 구성하는 시간이 길어지므로, ClickHouse에 데이터가 나타나기까지 걸리는 시간도 늘어납니다.min_insert_block_size_bytes=0- 바이트 기준 server block squashing을 비활성화합니다.min_insert_block_size_rows=1000- server 측에서 client가 보낸 block을 squashing합니다. 여기서는 행이 즉시 나타나도록 이 값을max_insert_block_size와 동일하게 설정합니다. 처리량을 높이려면 값을 늘리십시오.query="INSERT INTO logs_system_syslog FORMAT JSONAsRow"- 데이터를 JSONEachRow 포맷으로 삽입합니다. 이는logs_system_syslog처럼 스키마가 명확하게 정의된 경우에 적합합니다.
초당 수천 행 수준의 처리량을 기대할 수 있습니다.
단일 JSON 행으로 삽입단일 JSON 컬럼에 삽입하는 경우(위의 자세한 내용은 “JSON을 객체로 읽기”를 참조하십시오.
syslog_json 스키마 참조)에도 동일한 삽입 명령을 사용할 수 있습니다. 다만 포맷으로 JSONEachRow 대신 JSONAsObject를 지정해야 합니다. 예:데이터 변환(선택 사항)
위 명령은 Elasticsearch 필드와 ClickHouse 컬럼이 1:1로 매핑된다고 가정합니다. 실제로는 ClickHouse에 삽입하기 전에 Elasticsearch 데이터를 필터링하고 변환해야 하는 경우가 많습니다.이 작업은input 테이블 함수를 사용해 수행할 수 있습니다. 이 함수로 stdout에 대해 임의의 SELECT 쿼리를 실행할 수 있습니다.앞서 사용한 데이터에서 timestamp와 hostname 필드만 저장한다고 가정해 보겠습니다. ClickHouse 스키마는 다음과 같습니다.elasticdump에서 이 테이블로 삽입하려면 input 테이블 함수를 바로 사용할 수 있습니다. 이때 JSON 타입을 사용해 필요한 컬럼을 동적으로 감지하고 선택할 수 있습니다. 참고로 이 SELECT 쿼리에는 필터를 쉽게 추가할 수 있습니다.@timestamp 필드 이름은 이스케이프 처리해야 하며, JSONAsObject 입력 형식을 사용해야 합니다.