소개

소개 (Introduction)

ClickHouse로 자체 SQL 기반 옵저버빌리티 솔루션을 구축하는 입문 가이드예요.

출처: 문서

본문

이 가이드는 ClickHouse를 사용해 자체 SQL 기반 옵저버빌리티 솔루션을 구축하려는 경우를 위한 것이며, 로그와 트레이스에 초점을 맞춰요. 수집 고려 사항, 접근 패턴에 맞춘 스키마 최적화, 비구조화 로그에서 구조 추출 등 자체 솔루션 구축의 모든 측면을 다뤄요. ClickHouse 단독으로는 즉시 사용 가능한 옵저버빌리티 솔루션이 아니에요. 하지만 옵저버빌리티 데이터를 위한 매우 효율적인 스토리지 엔진으로 사용될 수 있고, 비할 데 없는 압축률과 번개처럼 빠른 쿼리 응답 시간을 제공할 수 있어요. 옵저버빌리티 솔루션 내에서 ClickHouse를 사용하려면 사용자 인터페이스와 데이터 수집 프레임워크가 모두 필요해요. 현재 옵저버빌리티 신호의 시각화에는 Grafana를, 데이터 수집에는 OpenTelemetry를 권장해요(둘 다 공식 지원 통합이에요).

OpenTelemetry만은 아님 데이터 수집에 OpenTelemetry(OTel) 프로젝트를 권장하지만, Vector와 Fluentd 같은 다른 프레임워크와 도구로도 유사한 아키텍처를 만들 수 있어요(Fluent Bit 예시는 여기). Superset과 Metabase를 포함한 대체 시각화 도구도 존재해요.

왜 ClickHouse를 사용할까?

중앙 집중형 옵저버빌리티 저장소의 가장 중요한 기능은 다양한 소스의 방대한 로그 데이터를 빠르게 집계, 분석, 검색하는 능력이에요. 이러한 중앙화는 문제 해결을 간소화하고 서비스 중단의 근본 원인을 더 쉽게 찾게 해줘요. 사용자가 가격에 점점 민감해지고 이들 즉시 사용 가능한 제품의 비용이 제공하는 가치에 비해 높고 예측 불가능하다고 여기면서, 쿼리 성능이 수용 가능한 곳에서 비용 효율적이고 예측 가능한 로그 저장은 그 어느 때보다 가치가 있어요. 성능과 비용 효율성 덕분에 ClickHouse는 옵저버빌리티 제품에서 로그와 트레이싱 스토리지 엔진의 사실상 표준이 되었어요. 구체적으로 다음 이유로 ClickHouse는 옵저버빌리티 데이터 저장에 이상적이에요:

  • 압축 - 옵저버빌리티 데이터는 보통 HTTP 코드나 서비스 이름처럼 고유한 집합에서 값을 취하는 필드를 포함해요. ClickHouse의 컬럼형 저장(값이 정렬되어 저장됨)은 시계열 데이터용 특수 코덱과 결합하면 이 데이터를 매우 잘 압축해요. 보통 JSON 형식으로 원본 데이터 크기만큼의 스토리지가 필요한 다른 데이터 저장소와 달리, ClickHouse는 로그와 트레이스를 평균 최대 14배까지 압축해요. 대규모 옵저버빌리티 설치에 상당한 저장 공간 절약을 제공하는 것 외에도, 이 압축은 디스크에서 읽어야 할 데이터가 적어져서 쿼리를 가속화하는 데 도움을 줘요.
  • 빠른 집계 - 옵저버빌리티 솔루션은 보통 오류율 라인이나 트래픽 소스 바 차트 같은 차트를 통한 데이터 시각화를 많이 수반해요. 이러한 차트를 구동하려면 집계, 즉 GROUP BY가 근본적인데, 문제 진단 워크플로에서 필터를 적용할 때도 빠르고 반응적이어야 해요. ClickHouse의 컬럼형 포맷과 벡터화된 쿼리 실행 엔진의 조합은 빠른 집계에 이상적이며, 스파스 인덱싱으로 사용자 동작에 빠르게 반응하는 데이터 필터링을 허용해요.
  • 빠른 선형 스캔 - 다른 기술이 로그 빠른 조회를 위해 역 인덱스에 의존하는 반면, 이것들은 거의 항상 높은 디스크와 리소스 사용을 초래해요. ClickHouse는 역 인덱스를 추가 옵션 인덱스 유형으로 제공하지만, 선형 스캔은 고도로 병렬화되어 있고(달리 구성되지 않는 한) 머신의 모든 사용 가능한 코어를 사용해요. 이는 고도로 최적화된 텍스트 매칭 연산자로 초당 수십 GB(압축됨)를 매칭 스캔할 수 있게 해줘요.
  • SQL의 익숙함 - SQL은 모든 엔지니어에게 익숙한 만국 공통 언어예요. 50년 이상의 발전으로 데이터 분석의 사실상 언어로 입증되었고 여전히 3번째로 인기 있는 프로그래밍 언어예요. 옵저버빌리티는 SQL이 이상적인 또 하나의 데이터 문제일 뿐이에요.
  • 분석 함수 - ClickHouse는 SQL 쿼리를 더 단순하고 작성하기 쉽게 만드는 분석 함수로 ANSI SQL을 확장해요. 근본 원인 분석을 수행할 때 필수적이며, 데이터를 잘게 썰고 자를 수 있게 해줘요.
  • 보조 인덱스 - ClickHouse는 블룸 필터 같은 보조 인덱스를 지원해 특정 쿼리 프로필을 가속화해요. 이는 컬럼 레벨에서 선택적으로 활성화할 수 있어 사용자에게 세밀한 제어를 주고 비용-성능 이점을 평가하게 해줘요.
  • 오픈소스 & 오픈 표준 - 오픈소스 데이터베이스로서 ClickHouse는 OpenTelemetry 같은 오픈 표준을 수용해요. 벤더 종속을 피하면서 프로젝트에 기여하고 적극적으로 참여할 수 있는 능력은 매력적이에요.

옵저버빌리티에 언제 ClickHouse를 사용해야 할까

옵저버빌리티 데이터에 ClickHouse를 사용하려면 사용자가 SQL 기반 옵저버빌리티를 수용해야 해요. SQL 기반 옵저버빌리티의 역사는 이 블로그 포스트를 권장해요. 요약하면 SQL 기반 옵저버빌리티는 다음에 적합해요:

  • 여러분이나 팀원이 SQL에 익숙하거나(배우고 싶어 하거나)
  • 종속을 피하고 확장성을 달성하기 위해 OpenTelemetry 같은 오픈 표준을 따르는 것을 선호해요.
  • 수집부터 저장, 시각화까지 오픈소스 혁신으로 구동되는 생태계를 운영할 의향이 있어요.
  • 관리 중인 옵저버빌리티 데이터가 중간 또는 대규모(또는 매우 대규모)로 성장할 것으로 예상해요.
  • TCO(총소유비용)를 통제하고 옵저버빌리티 비용이 치솟는 것을 피하고 싶어요.
  • 비용을 관리하기 위해 옵저버빌리티 데이터의 보존 기간을 작게 제한할 수 없거나 하고 싶지 않아요.

SQL 기반 옵저버빌리티가 적합하지 않을 수 있는 경우:

  • SQL을 배우는(또는 생성하는!) 것이 여러분이나 팀원에게 매력적이지 않아요.
  • 패키지형 종단간 옵저버빌리티 경험을 찾고 있어요.
  • 옵저버빌리티 데이터 규모가 너무 작아(예: <150 GiB) 의미 있는 차이를 만들지 못하고 성장 전망도 없어요.
  • 여러분의 사용 사례가 메트릭 중심이고 PromQL이 필요해요. 그 경우에도 메트릭용 Prometheus 옆에 로그와 트레이싱용 ClickHouse를 사용하고 Grafana로 프레젠테이션 계층에서 통합할 수 있어요.
  • 생태계가 더 성숙해지고 SQL 기반 옵저버빌리티가 더 턴키(turnkey)가 되기를 기다리는 것을 선호해요.

로그와 트레이스

옵저버빌리티 사용 사례에는 로깅, 트레이싱, 메트릭이라는 세 가지 뚜렷한 기둥이 있어요. 각각 고유한 데이터 타입과 접근 패턴을 가져요. 현재 옵저버빌리티 데이터의 두 가지 유형을 저장하는 데 ClickHouse를 권장해요:

  • 로그 - 로그는 시스템 내에서 발생하는 이벤트의 타임스탬프가 찍힌 기록으로, 소프트웨어 운영의 다양한 측면에 대한 상세 정보를 담아요. 로그의 데이터는 보통 비구조화 또는 반구조화되어 있으며 오류 메시지, 사용자 활동 로그, 시스템 변경, 기타 이벤트를 포함할 수 있어요. 로그는 문제 해결, 이상 탐지, 시스템 내 문제로 이어지는 특정 이벤트 이해에 중요해요.
54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET
/filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"
  • 트레이스 - 트레이스는 분산 시스템에서 요청이 서로 다른 서비스를 거치며 이동하는 여정을 포착하며, 이 요청들의 경로와 성능을 상세히 보여줘요. 트레이스의 데이터는 고도로 구조화되어 있으며, 요청이 취하는 각 단계를 시간 정보를 포함해 매핑하는 스팬(span)과 트레이스로 구성돼요. 트레이스는 시스템 성능에 대한 귀중한 통찰을 제공해 병목, 지연 문제를 식별하고 마이크로서비스의 효율성을 최적화하는 데 도움을 줘요.

메트릭 ClickHouse로 메트릭 데이터를 저장할 수는 있지만, 이 기둥은 ClickHouse에서 덜 성숙하며 Prometheus 데이터 포맷과 PromQL 지원 같은 기능이 아직 준비 중이에요.

분산 트레이싱

분산 트레이싱은 옵저버빌리티의 핵심 기능이에요. 분산 트레이스, 간단히 트레이스는 시스템을 통한 요청의 여정을 매핑해요. 요청은 최종 사용자나 애플리케이션에서 시작해 시스템 전체로 퍼지며, 보통 마이크로서비스 간의 일련의 동작으로 이어져요. 이 순서를 기록하고 후속 이벤트를 상관시키게 함으로써, 옵저버빌리티 사용자나 SRE는 아키텍처가 아무리 복잡하거나 서버리스여도 애플리케이션 흐름의 문제를 진단할 수 있어요. 각 트레이스는 여러 스팬으로 구성되며, 요청과 연관된 초기 스팬을 루트 스팬이라 불러요. 이 루트 스팬은 시작부터 끝까지 전체 요청을 포착해요. 루트 아래의 후속 스팬들은 요청 중 발생하는 다양한 단계나 작업에 대한 상세한 통찰을 제공해요. 트레이싱 없이는 분산 시스템의 성능 문제를 진단하는 것이 극도로 어려울 수 있어요. 트레이싱은 요청이 시스템을 이동하며 거치는 이벤트 시퀀스를 상세히 보여줌으로써 분산 시스템의 디버깅과 이해를 쉽게 해줘요. 대부분의 옵저버빌리티 벤더는 이 정보를 상대적 시간이 비례적인 크기의 수평 바로 표시되는 워터폴로 시각화해요. 예를 들어 Grafana에서요. 로그와 트레이스의 개념을 깊이 숙지해야 하는 사용자에게는 OpenTelemetry 문서를 적극 권장해요.

더 알아보기 (Learn more)