The Brief FactStack이 되었습니다

FactStack

Datadog Bits Database Optimization이란, 쿼리 재작성 검증하는 방법

데이터 신뢰성

한마디로

Datadog가 쿼리를 고친 뒤 진짜 빨라졌는지 가짜 운영환경에서 50번씩 돌려 증명하는 기능을 소개했어요

한눈에

Datadog Bits Database Optimization은 느린 쿼리를 찾아 개선안을 제시하는 Database Monitoring(DBM) 기능이에요. 이번에 공개된 내용은 그 개선안이 실제로 더 빠른지 어떻게 증명하는지에 관한 부분인데요, 운영 DB를 그대로 복제한 게 아니라 스키마와 통계 기반으로 시뮬레이션 인스턴스를 새로 만들어서 원본 쿼리와 재작성 쿼리를 각각 50회씩 돌려 비교합니다. 마케팅 조직이 직접 쓰는 도구는 아니지만, 캠페인 데이터를 다루는 백엔드 DB 성능이 느려질 때 이런 검증 방식이 왜 필요한지 이해해두면 데이터팀과 소통할 때 도움이 돼요.

쿼리 최적화, 왜 증명이 어려운가

원문에 따르면 쿼리 최적화에서 흔히 겪는 문제는 재작성한 쿼리가 기존 쿼리보다 실제로 빠른지 증명하는 일이라고 해요. 밀리초 단위로 측정되는 hot query에서는 캐시 상태, 동시에 실행되는 다른 쿼리들의 CPU와 I/O 경합, noisy neighbor 같은 요인들이 진짜 성능 차이를 가려버릴 수 있습니다. 그래서 두 쿼리를 그냥 돌려서 시간을 비교하는 방식으로는 신뢰할 만한 결론을 내기 어렵다는 게 출발점이에요. 많은 최적화 도구들은 실행 계획이나 비용 추정치, 과거 성능 데이터를 근거로 개선 가능성을 예측하는 데 그치는데, 그러면 엔지니어가 그 예측을 믿을지 아니면 운영 데이터로 직접 벤치마크할지 선택해야 하고, 후자는 보안 위험이나 노이즈 문제를 동반한다고 합니다.

운영 DB를 흉내 낸 시뮬레이션 인스턴스

Bits Database Optimization은 이 문제를 풀기 위해 Datadog 인프라 안에 새 데이터베이스 인스턴스를 만들어 통제된 벤치마크 환경으로 씁니다. Datadog Agent가 DBM 스키마 수집 과정에서 이미 테이블과 인덱스 정의를 모으고 있는데, 이 정보를 이용해서 쿼리가 쓰는 스키마를 재현하고 테이블, 인덱스, 제약 조건이 운영 DB와 같도록 맞춥니다. 그다음 카디널리티와 컬럼별 분포 같은 운영 데이터의 핵심 특성을 근사하는 합성 데이터로 테이블을 채우는데요, 이렇게 해야 쿼리 플래너가 실제 운영 환경에서 내리는 것과 비슷한 계획 결정을 내릴 수 있다고 해요. 이런 인스턴스는 쓰고 버리는 방식이라 운영 데이터 위험이나 권한 있는 자격 증명 관리 부담이 없고, 락 경합이나 동시 트래픽 방해 없이 변수를 더 일관되게 통제할 수 있다는 장점이 있습니다.

시뮬레이션이 실제와 얼마나 닮았는지, cost fidelity와 read fidelity

시뮬레이션 데이터가 아무리 정교해도 실제 운영 데이터의 쿼리 행동을 얼마나 정확히 반영하는지가 관건이에요. Datadog는 이를 측정하기 위해 cost fidelity와 read fidelity라는 지표를 씁니다. cost fidelity는 쿼리 플래너가 예측하는 실행 비용이 시뮬레이션 DB와 운영 DB에서 얼마나 비슷한지를 보는 지표이고, read fidelity는 실제로 접근하는 데이터 블록 수를 비교해서 더 세밀하게 봅니다. fidelity는 1.00배가 완전 일치를 뜻하고 값이 클수록 차이가 크다는 의미인데, 평가한 쿼리 유형들에서 중간값 차이는 1.00배에서 1.05배, p95 차이는 1.00배에서 1.24배로 나타났다고 해요. read fidelity는 대부분의 쿼리 클래스에서 중간값 기준으로는 1.00배에 근접할 정도로 강했지만, 일부 쿼리 클래스는 p95 구간에서 편차가 더 컸고 이 부분은 계속 개선 중이라고 합니다. 특히 여러 컬럼에 걸친 AND 조건을 가진 쿼리의 fidelity를 높이기 위해 PostgreSQL extended statistics를 반영하는 작업을 진행 중이에요.

진짜 개선인지 판단하는 기준

벤치마크 환경이 갖춰졌다면 다음 질문은 얼마나 개선돼야 진짜 개선으로 인정하느냐인데요, Bits는 실행 시간(데이터베이스 자체가 보고하는 서버 시간, wall-clock 시간이 아님), 논리적 읽기(캐시든 스토리지든 접근한 블록 수), 더티 블록(수정돼서 스토리지에 반영돼야 하는 블록 수) 세 가지를 측정합니다. 기존 쿼리와 재작성 쿼리를 각각 50회씩 실행한 뒤 평균, 중간값, p95, 최대값을 비교하고, 각 측정 항목에서 20%를 넘는 개선이 있어야 인정하는 방식이에요. 한 번의 벤치마크에 의존하지 않고 반복 실행값 여러 개를 놓고 판단한다는 점이 핵심입니다. 데이터팀과 협업할 때는 이런 검증 기준을 이해하고 있으면 개선안을 얼마나 신뢰할 수 있는지 판단하는 데 도움이 됩니다.

자주 묻는 질문

Datadog Bits Database Optimization이란 무엇인가요

느린 쿼리나 병목 쿼리를 자동으로 찾아내고 개선안을 제안하는 Datadog의 Database Monitoring 기능이에요. 단순 예측이 아니라 운영 DB를 모사한 시뮬레이션 인스턴스에서 실제로 벤치마크해 개선 여부를 증명하는 게 특징입니다.

쿼리 재작성이 진짜 빨라졌는지 어떻게 검증하나요

원본 쿼리와 재작성 쿼리를 각각 50회 실행해서 실행 시간, 논리적 읽기, 더티 블록 세 지표의 평균, 중간값, p95, 최대값을 비교합니다. 각 지표에서 20%를 넘는 개선이 나와야 실제 개선으로 판단해요.

어떤 데이터베이스를 지원하나요

현재는 Postgres를 지원하고 있고, MySQL, Microsoft SQL Server, Oracle은 추후 지원할 계획이라고 합니다.

cost fidelity와 read fidelity는 무엇인가요

cost fidelity는 쿼리 플래너의 예상 실행 비용이 시뮬레이션 DB와 운영 DB에서 얼마나 일치하는지 보는 지표이고, read fidelity는 실제 접근하는 데이터 블록 수를 비교하는 더 세밀한 지표예요. 평가한 쿼리 유형 기준으로 중간값 차이는 1.00배에서 1.05배, p95 차이는 1.00배에서 1.24배 수준이었습니다.

에디터 노트

마케터가 직접 만질 기능은 아니지만, 캠페인 대시보드나 CDP 쿼리가 느려질 때 데이터팀이 어떤 근거로 최적화를 검증하는지 알아두면 협업 대화가 편해져요. 다만 아직 Postgres만 지원하고 일부 쿼리 클래스는 p95 구간에서 fidelity 편차가 크다는 점은 한계로 봐야 합니다.

참고 출처 | 원문 보기

태그

용어 풀이
Datadog
데이터독
쿼리최적화
쿼리 최적화
데이터베이스모니터링
데이터베이스 모니터링

이 노트는 자동 검증을 거쳐 발행되었습니다. 오류 제보는 편집팀이 즉시 확인합니다.

공유

관련 마테크