소개
OpenTelemetry만 사용할 수 있는 것은 아닙니다데이터 수집에는 OpenTelemetry(OTel) 프로젝트 사용을 권장하지만, Vector나 Fluentd 같은 다른 프레임워크와 도구를 사용해서도 유사한 아키텍처를 구성할 수 있습니다. 예를 들어 Fluent Bit를 사용한 예시를 참조하십시오. Superset, Metabase와 같은 대체 시각화 도구도 있습니다.
ClickHouse를 사용하는 이유
- 압축 - 관측성 데이터에는 일반적으로 HTTP 코드나 서비스 이름처럼 값의 종류가 제한된 필드가 포함됩니다. 값이 정렬된 상태로 저장되는 ClickHouse의 컬럼 기반 저장 방식은 이런 데이터를 매우 효율적으로 압축할 수 있게 해줍니다. 특히 시계열 데이터용 특수 코덱과 함께 사용할 때 그 효과가 더욱 커집니다. 일반적으로 JSON 포맷의 원본 데이터 크기만큼 저장 공간이 필요한 다른 데이터 저장소와 달리, ClickHouse는 로그와 트레이스를 평균적으로 최대 14배까지 압축합니다. 이러한 압축은 대규모 관측성 환경에서 저장 공간을 크게 절감할 뿐만 아니라, 디스크에서 읽어야 하는 데이터 양을 줄여 쿼리 속도 향상에도 도움이 됩니다.
- 빠른 집계 - 관측성 솔루션에서는 일반적으로 오류율을 보여주는 선 그래프나 트래픽 소스를 보여주는 막대 그래프처럼 데이터를 차트로 시각화하는 작업이 큰 비중을 차지합니다. 집계, 즉 GROUP BY는 이러한 차트를 구동하는 핵심 요소이며, 문제 진단 워크플로에서 필터를 적용할 때도 빠르고 즉각적으로 응답해야 합니다. ClickHouse의 컬럼 기반 포맷과 벡터화된 쿼리 실행 엔진의 조합은 빠른 집계에 이상적이며, 희소 인덱싱을 통해 사용자 동작에 맞춰 데이터를 신속하게 필터링할 수 있습니다.
- 빠른 선형 스캔 - 로그를 빠르게 쿼리하기 위해 다른 기술들은 역인덱스에 의존하지만, 이는 대체로 높은 디스크 및 리소스 사용량으로 이어집니다. ClickHouse도 추가적인 선택형 인덱스 유형으로 역인덱스를 제공하지만, 선형 스캔은 고도로 병렬화되어 있으며 머신에서 사용 가능한 모든 코어를 활용합니다(별도로 구성하지 않는 한). 이를 통해 고도로 최적화된 텍스트 매칭 연산자를 사용해 초당 수십 GB의 압축 데이터를 매칭 대상으로 스캔할 수 있습니다.
- 익숙한 SQL - SQL은 모든 엔지니어에게 익숙한 보편적인 언어입니다. 50년이 넘는 발전을 거치며 데이터 분석의 사실상 표준 언어임을 입증했으며, 여전히 세 번째로 인기 있는 프로그래밍 언어입니다. 관측성 역시 결국 또 하나의 데이터 문제이며, SQL은 이를 해결하는 데 이상적입니다.
- 분석 함수 - ClickHouse는 SQL 쿼리를 더 단순하고 쉽게 작성할 수 있도록 설계된 분석 함수를 통해 ANSI SQL을 확장합니다. 데이터를 다양한 기준으로 나누고 조합해야 하는 근본 원인 분석을 수행할 때 이러한 함수는 필수적입니다.
- 보조 인덱스 - ClickHouse는 특정 쿼리 프로파일을 가속하기 위해 블룸 필터와 같은 보조 인덱스를 지원합니다. 이러한 인덱스는 컬럼 수준에서 선택적으로 활성화할 수 있어, 세밀한 제어가 가능하며 비용 대비 성능 이점을 평가할 수 있습니다.
- 오픈 소스 & 개방형 표준 - 오픈 소스 데이터베이스인 ClickHouse는 OpenTelemetry와 같은 개방형 표준을 수용합니다. 프로젝트에 기여하고 적극적으로 참여할 수 있다는 점은 매력적이며, 동시에 벤더 종속 문제도 피할 수 있습니다.
언제 관측성에 ClickHouse를 사용해야 할까요
- 사용자 또는 팀원이 SQL에 익숙하거나(또는 배우고자 하거나)
- 종속을 피하고 확장성을 확보하기 위해 OpenTelemetry와 같은 개방형 표준을 따르는 것을 선호합니다.
- 수집부터 저장, 시각화까지 오픈소스 혁신을 기반으로 한 생태계를 운영할 의향이 있습니다.
- 관리하는 관측성 데이터가 중간 규모 또는 대규모(심지어 매우 대규모)로 증가할 가능성이 있습니다
- TCO(총소유비용)를 직접 통제하고 관측성 비용이 걷잡을 수 없이 증가하는 것을 피하고자 합니다.
- 비용 관리를 위해 관측성 데이터의 보존 기간을 지나치게 짧게 설정하는 상황에 얽매이고 싶지 않거나, 그럴 수 없습니다.
- SQL을 배우는 것(또는 생성하는 것!)이 사용자나 팀원에게 매력적이지 않습니다.
- 패키지형 엔드투엔드 관측성 환경을 찾고 있습니다.
- 관측성 데이터 규모가 너무 작아 큰 차이가 없고(예: <150 GiB), 앞으로도 증가할 것으로 예상되지 않습니다.
- 사용 사례가 메트릭 중심이며 PromQL이 필요합니다. 이 경우에도 메트릭에는 Prometheus를 사용하고, 로그와 트레이싱에는 ClickHouse를 사용한 뒤, Grafana로 시각화 계층에서 이를 통합할 수 있습니다.
- 생태계가 더 성숙해지고 SQL 기반 관측성이 더 손쉽게 사용할 수 있는 형태가 되기를 기다리는 편을 선호합니다.
로그 및 트레이스
- 로그 - 로그는 시스템 내에서 발생하는 이벤트를 타임스탬프와 함께 기록한 레코드로, 소프트웨어 운영의 여러 측면에 대한 상세한 정보를 담고 있습니다. 로그 데이터는 일반적으로 비구조화 또는 반정형이며, 오류 메시지, 사용자 활동 로그, 시스템 변경 사항, 기타 이벤트를 포함할 수 있습니다. 로그는 문제 해결, 이상 징후 탐지, 그리고 시스템에서 문제가 발생하기 전까지 어떤 이벤트가 있었는지 파악하는 데 매우 중요합니다.
- 트레이스 - 트레이스는 분산 시스템에서 요청이 여러 서비스를 통과하는 전체 흐름을 포착하며, 요청이 거치는 경로와 성능을 자세히 보여줍니다. 트레이스 데이터는 스팬과 트레이스로 이루어진 고도로 구조화된 데이터로, 타이밍 정보를 포함해 요청이 거치는 각 단계를 나타냅니다. 트레이스는 시스템 성능에 대한 유용한 통찰을 제공하여 병목 구간과 지연 시간 문제를 식별하고, 마이크로서비스의 효율을 최적화하는 데 도움이 됩니다.
메트릭ClickHouse를 메트릭 데이터 저장에 사용할 수는 있지만, Prometheus 데이터 포맷 및 PromQL 지원과 같은 기능은 아직 지원이 진행 중이므로, 이 영역은 ClickHouse에서 상대적으로 성숙도가 낮습니다.