백엔드 벤치마킹 방법: 반복 가능한 방법론

경쟁 반응형 백엔드 게시자인 Convex는 기술 팀이 데이터베이스 제공업체 간의 "막대 차트 전쟁"이라고 부르는 것과 공개적으로 거리를 두었습니다. 그의 공식은 직접적입니다. "확장이 아닌 극장 확장입니다." — 실제 스케일링이 아닌 극장 확장입니다(stack.convex.dev/on-competitive-benchmarks, Stack 기술 블로그, 2026년 8월 23일 액세스).

핵심 주장은 일관성, 토폴로지 또는 가격 모델이 서로 다른 두 시스템을 비교하는 벤치마크는 종종 동일한 것을 테스트하지 않는다는 것입니다. "벤치마크는 실제로 동일한 것을 테스트하지 않습니다." 업계에서는 벤치마킹, 즉 방법론적 엄격함보다는 마케팅 효과를 위해 선택된 수치를 게시하는 등의 반사 작용으로 유명합니다.

우리의 대응은 측정을 거부하는 것이 아닙니다. 수치를 무기한 게시하는 것을 거부하는 것은 입증되지 않은 수치를 게시하는 것만큼 부정직한 것입니다. 무엇이든 측정했다고 주장하기 전에 먼저 어떤 도구를 사용하여 어떤 조건에서 어떻게 측정할지 문서화하는 것입니다. 이는 또한 유용한 비교(예: 검증 가능한 아키텍처 차이를 문서화하는 Aurabase 대 Appwrite 비교)와 공통 프로토콜이 없는 성능 수치의 비교를 구별하는 것입니다.

이는 기술 위원회에서 백엔드 선택을 옹호해야 하는 기술 책임자나 CTO에게 특히 중요합니다. 방법을 추적할 수 없는 수치는 다소 끈질긴 첫 번째 질문에서 살아남지 못합니다. 문서화된 프로토콜은 자기 방어적입니다. 스크립트와 테스트된 버전을 보여주고 필요한 경우 다른 사람 앞에서 테스트를 다시 실행할 수 있습니다.

체계적으로 두 가지 함정이 발생합니다. 하나는 보고하지 않고 다양한 토폴로지를 비교하는 것이고, 다른 하나는 사용자에게 가장 중요한 일시 중지를 정확히 숨기는 방식으로 대기 시간을 측정하는 것입니다.

첫 번째 지점에서 PlanetScale은 하드웨어 패리티 제약 조건을 명시적으로 문서화합니다. 비교되는 각 환경은 동일한 클라우드 지역(planetscale.com/benchmarks, "Telescope" 방법론, 2026년 8월 23일 액세스)의 참조 인스턴스보다 크거나 같은 컴퓨팅 리소스(vCPU, RAM)에서 실행되어야 합니다. 이러한 규율이 ​​없으면 대기 시간 격차는 더 빠른 아키텍처가 아니라 단순히 더 큰 시스템을 반영할 수 있습니다.

캐시 상태와 네트워크 토폴로지에도 동일한 원칙이 적용됩니다. 방금 시작된 인스턴스(콜드 Postgres 캐시, 빈 연결 풀, 아직 캐시되지 않은 쿼리 계획)는 안정적인 로드에서 한 시간 동안 실행된 인스턴스보다 구조적으로 느리게 응답합니다. 데이터베이스와 동일한 지역의 쿼리는 지역 간 쿼리보다 구조적으로 더 빠르게 응답합니다. 둘 다 지정하지 않은 두 벤치마크는 동일한 단위를 표시하더라도 단순히 비교할 수 없습니다.

두 번째 점에서는 함정을 조정 생략이라고 합니다. Gil Tene이 만든 대기 시간 측정에 대한 참조 프로젝트인 HdrHistogram은 이를 다음과 같이 설명합니다. 로드 생성기가 다음 요청을 보내기 전에 요청의 응답을 기다릴 때(폐쇄 루프), 서비스 일시 중지는 일시 중지 중에 전송된 요청 수를 자동으로 삭제합니다. 따라서 대기 시간이 긴 측정 수가 기록됩니다(github.com/HdrHistogram/HdrHistogram, 8월에 액세스함). 2026년 2월 23일). 이 프로젝트는 구체적이고 정량화된 예를 제공합니다. 200초 동안 10ms마다 지연 시간을 샘플링하는 가상 시스템에서 테스트 중간에 100초 동안 한 번 일시 중지하면 수정 없이 응답의 약 99.99%가 1ms 미만에 맞는 것으로 보이는 히스토그램을 생성하는 데 충분합니다. 비록 이 단일 일시 중지에서 실제 시간의 절반이 경과했음에도 불구하고 말입니다.

요청 20개 중 하나가 5배 더 오래 걸리면 평균 대기 시간이 매우 좋아 보일 수 있습니다. 이것이 바로 백분위수가 드러내는 것과 평균이 구조적으로 숨기는 것입니다.

기계적으로 백분위수에 대해 신비한 것은 없습니다. 측정된 모든 지연 시간을 오름차순으로 정렬한 다음 해당 위치의 값을 가져옵니다. 1000개의 정렬된 쿼리 중 p50은 500번째 값, p95는 950번째, p99는 990번째 값입니다. 1000개 중 비정상적으로 느린 단일 요청이면 p99를 움직일 수 있습니다. 이 동일한 격리된 요청이 평균에 거의 영향을 미치지 않는 경우를 유용하게 만드는 것은 바로 드문 경우에 대한 민감도입니다.

표시 기호: 공식 PostgreSQL 벤치마크 도구인 pgbench가 기본적으로 표시하는 텍스트 보고서는 백분위수가 아닌 평균 및 표준 편차를 제공합니다(postgresql.org/docs/current/pgbench.html, 2026년 8월 23일 액세스). 공식 문서에서는 다음과 같이 경고합니다. "단 몇 초 동안만 실행되는 테스트는 절대 믿지 마세요." - 선택한 측정 항목만큼 지속 시간에 적용되는 몇 초 동안만 실행되는 테스트를 절대 믿지 마세요.

우리 제품군의 레벨 2에 사용하는 로드 도구인 k6은 백분위수로 표현된 임계값으로 이 문제를 해결합니다. p(95)<500 구문은 테스트 구성(grafana.com/docs/k6, 8월 23일에 참조)에서 직접 통과/실패 기준을 정의합니다(요청의 95%가 500ms 이내에 응답해야 함). 2026).

실제 도구 없이 방법론을 출판하는 것은 연극의 또 다른 형태일 뿐입니다. Aurabase 저장소의 benchmarks/ 폴더에는 공개 Supabase 방법론의 구조에서 영감을 받은 3레벨 제품군이 이미 포함되어 있습니다. 도구는 존재하지만 측정되고 날짜가 지정된 결과는 아직 존재하지 않습니다.

레벨 1 - 마이크로 벤치마크 Criterion.rs

화물 작업 공간의 세 상자에는 전용 CPU 바인딩 벤치마크가 있습니다: aura-crypto(Argon2 해시, JWT HS256 — PostgREST에 대한 생성, 검증 및 서명, AES-GCM 암호화), aura-db-adapters(PostgREST 형식의 구문 분석 필터 및 select — eq., gte., in.(), 관계 포함) 및 aura-core(JSON 직렬화, schema_name확인, UUID 유효성 검사).

// 저장소에서 실제 추출
let mut group = c.benchmark_group("jwt/hs256");

group.bench_function("generate", |b| {
    b.iter(|| jwt::generate_access_token(
        black_box(user_id), black_box(project_id),
        black_box("authenticated"), black_box(SECRET),
    ))
});

group.bench_function("validate", |b| {
    b.iter(|| jwt::validate_token(black_box(&token), black_box(SECRET)))
});

aura-db-adapters는 특히 PostgREST 형식 쿼리를 구문 분석하는 비용을 측정합니다. 즉, 필터의 경우 4가지(50개의 값이 있는simple_4, complex_10, or_group, in_large_50) 및 select의 경우 4가지(단일 열, *, 관계 포함 1개, 포함 5개)입니다. 이는 글로벌 로드 테스트에서 보이지 않는 일종의 비용입니다. 복잡한 or.(...) 필터 분석에 대한 회귀는 거의 사용되지 않는 엔드포인트의 p95에서는 거의 변경되지 않지만 트래픽이 많은 엔드포인트에서는 측정 가능해집니다. 따라서 레벨 2에만 의존하기보다는 마이크로 벤치마크에서 이를 격리하는 것이 좋습니다.

aura-core는 다른 접근 방식을 취합니다. 원시 시간을 측정하는 대신 게이트웨이와 서비스 간에 교환되는 내부 NatsRequest/NatsResponse 메시지의 JSON 직렬화 및 역직렬화에 대한 처리량(Throughput::Bytes)을 세 가지 현실적인 페이로드 크기(최소 요청, 중첩된 JSON 본문이 있는 요청, 50줄 목록)로 측정합니다. 응답).

group.throughput(Throughput::Bytes(
    serde_json::to_vec(&small).unwrap().len() as u64
));
group.bench_function("NatsRequest/small", |b| {
    b.iter(|| serde_json::to_vec(black_box(&small)).unwrap())
});

Criterion.rs는 단지 루프의 시간을 측정하는 것이 아닙니다. 먼저 CPU/OS 캐시를 채우기 위해 준비 단계를 실행하고, Tukey 방법의 수정된 버전으로 이상값을 감지하고(데이터 세트에서 제외하지 않음), 많은 수의 리샘플링된 샘플에 대한 부트스트래핑을 통해 신뢰 구간을 계산하고, 구성 가능한 노이즈 임계값(일반적으로 ±1%)을 사용하여 Student의 통계 테스트를 통해 두 실행 사이의 성능 회귀를 감지하여 통계적으로 유의하지 않은 변동을 무시합니다(bheisler.github.io/criterion.rs/book/analytic.html, 2026년 8월 23일 액세스).

레벨 2 — k6 부하 테스트

8개의 k6 스크립트는 데이터 플레인 측의 게이트웨이를 포함합니다: health(대기 시간 기준), auth-flow(등록 → 로그인 → 새로 고침 → 로그아웃), crud-read 및 crud-write, storage(업로드/다운로드), realtime-ws``breakpoint(실패할 때까지 부하 증가) 및 supabase-compare. 7개는 전용 Makefile 대상에 연결되어 있습니다. supabase-compare.js는 저장소에 있지만 아직 대상이 없습니다. 이 기사에서는 위장하는 것이 아니라 있는 그대로 문서화합니다.

export const options = {
  scenarios: {
    crud_read: {
      executor: 'ramping-vus',
      startVUs: 10,
      stages: [
        { duration: '30s', target: 50 },
        { duration: '1m', target: 200 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: THRESHOLDS_READ,
}

공유 구성은 작업 유형별로 임계값을 정의합니다. 다음은 테스트가 실행될 때마다 확인하는 통과/실패 기준입니다. 이미 측정된 결과는 아닙니다.

레벨 3 — Direct PostgreSQL과 API 비교

Python 스크립트(direct_vs_api.py)는 동일한 작업(목록, ID별 일회성 읽기, 필터링 및 정렬된 읽기)의 HTTP 호출에 대한 직접 psycopg2 요청을 비교하여 게이트웨이 + 서비스 계층의 실제 오버헤드를 측정합니다. 각 측정은 시간 제한 루프 이전에 10회 반복 워밍업을 수행한 다음 평균, p50, p95, p99 및 초당 작업 처리량을 계산합니다.

def percentile(data, p):
    k = (len(data) - 1) * (p / 100)
    f = int(k)
    c = f + 1
    if c >= len(data):
        return data[f]
    return data[f] + (k - f) * (data[c] - data[f])

두 번째 스크립트(aurabase_vs_supabase.py)는 로컬 Supabase 인스턴스(Supabase CLI, 기본적으로 localhost:54321)와의 정면 비교에 동일한 워밍업 및 백분위수 계산 논리를 적용합니다. 즉, 둘 모두에 대해 동일한 시스템, 동일한 로컬 네트워크, 정확히 PlanetScale이 자체 비교를 위해 문서화하는 환경 패리티 원칙입니다.

오케스트레이션 스크립트(collect_baseline.sh, Makefile의 대상 bench-baseline )는 세 가지 수준(3개 상자에 대한 기준, k6 시나리오의 하위 집합(현재health 및 crud-read, 아직 8개는 아님), Python 비교)을 연결하고 고유한 타임스탬프가 있는 폴더에 로그, JSON 및 Criterion HTML 보고서를 작성합니다. benchmarks/results/AAAAMMJJ_HHMMSS/. 이는 다음 섹션에서 완전한 프로토콜로 공식화하는 재현 가능한 단일 실행에서 날짜가 지정된 공개를 반영한 ​​것입니다.

8가지 약속, 각 약속은 해당 상황을 위해 고안된 것이 아닌 인정된 타사 도구 또는 프로젝트에 의해 이미 문서화된 관행에 기반을 두고 있습니다.

1. 측정과 별도로 예열. Criterion.rs는 타이밍 전에 CPU/OS 캐시를 채웁니다. pgbench는 단 몇 초 동안 지속되는 실행을 절대로 믿지 말 것을 명시적으로 권장합니다.
2. 고정된 반복 횟수가 아닌 고정 기간입니다. 로드는 수렴하는 데 시간이 필요합니다. 이것이 stages k6의 역할과 pgbench의 -T 플래그입니다.
3. 백분위수는 단지 평균이 아니며 부하 생성기가 폐쇄 루프에서 작동하는 경우 조정된 누락에 대한 적극적인 경계입니다.
4. 자세히 문서화된 환경: 테스트된 서비스의 git 커밋, PostgreSQL 버전, 하드웨어 사양, 로드 도구 버전. PlanetScale은 바로 이러한 이유로 정확한 TPCC 매개변수(TABLES=20, SCALE=250, ~500GB)를 문서화합니다. 이러한 세부 정보가 없으면 누구도 실행을 재현할 수 없습니다.
5. 타임스탬프 및 버전이 지정된 결과, 날짜 없이 마케팅 페이지에 단일 숫자가 새겨지지 않습니다. 현재 도구는 이미 날짜가 지정된 파일에 기록되어 있습니다. 다른 환경 변수처럼 문서화된 호스팅 지역을 사용하여 이 반사를 공개적으로 발표된 측정으로 확장해야 합니다(수치가 특정 지역에 따라 달라지는 즉시 관련되는 EU 호스팅 주권에 대한 가이드 참조).
6. 최종 평균이 아닌 집계 결과와 함께 게시된 스크립트 및 원시 데이터입니다. PlanetScale은 독자들에게 전용 주소에 대한 방법론적 오류를 보고하도록 초대합니다. 이는 우리가 건강하다고 생각하고 재개하고 싶은 자세입니다.
7. 둘 중 하나만이 아니라 지연 시간과 함께 광고된 처리량입니다. 시스템은 낮은 로드에서 우수한 대기 시간을 가지며 동시성이 증가함에 따라 처리량이 붕괴될 수 있습니다. 이것이 바로 k6 제품군의 breakpoint 시나리오(충돌 확장)가 공개하도록 설계된 것이며 Criterion의 Throughput::Bytes 마이크로 벤치마크 측정이 기능 수준에서 캡처하는 것입니다.
8. 개선 사항을 발표하기 전에 상당한 격차가 있습니다. 두 실행 사이의 몇 퍼센트의 변화는 실제 이득이 아니라 측정 노이즈일 수 있습니다. Criterion.rs는 관찰된 차이가 회귀 또는 개선으로 검증되기 전에 우연으로 인한 확률을 계산합니다. 이러한 검증이 없는 고립된 수치는 단지 통계적인 일화일 뿐입니다.

이 목록은 위의 긍정적인 프로토콜만큼 중요합니다.

• 명시적으로 보고하지 않고 다양한 토폴로지(자체 호스팅과 관리형, 콜드 인스턴스와 예열 인스턴스)를 비교합니다.
• 나머지 9개는 언급하지 않고 10개 중 가장 좋은 결과를 유지합니다.
• 날짜 없이, 서비스 버전 없이, 복제 스크립트 없이 그림을 게시합니다.
• 이 프로토콜로 역추적되지 않는 한 기존 마케팅 수치를 다시 게시하십시오.
• 경쟁사가 동등한 방식으로 자신의 방법론을 발표하지 않는 경우 원시 성과 수치로 우리 자신을 경쟁사와 비교하는 것입니다. 수치 대 침묵은 비교가 아니라 슬로건입니다.

이 프로토콜은 특정 Aurabase 도구에 의존하지 않습니다. 지금 바로 자신의 API에 적용할 수 있습니다.

1. 도구 이전에 로드를 설정합니다. 읽기 전용, 쓰기, 애플리케이션에 대한 현실적인 혼합 — 다른 프로젝트에서 복사한 일반 비율이 아닙니다.
2. 예열 단계와 측정 단계를 명시적으로 분리하세요.
3. 몇 초가 아닌 몇 분 동안 테스트를 실행하세요.
4. 백분위수(p50/p95/p99)로 측정하고 평균만으로 측정하지 마십시오.
5. 부하 생성기가 폐쇄 루프에 있지 않은지 확인하거나 해석에서 조정 누락을 수정하십시오.
6. 테스트 중인 환경을 격리합니다. 시끄러운 이웃이나 경쟁하는 백그라운드 작업이 없습니다.
7. 최종 결과뿐만 아니라 테스트된 버전, 날짜, 하드웨어 사양 및 스크립트를 게시하세요.

기본 Postgres 기반에서 이 프로토콜은 pgbench 명령 하나를 사용합니다. 20개의 동시 클라이언트가 5분 동안 4개의 스레드에 분산되고 10초마다 진행 상황이 보고됩니다.

# 테스트 데이터세트 초기화(배율 인수 >= 클라이언트 수)
pgbench -i -s 50 ma_base

# -c 동시 클라이언트, -j 스레드, -T 기간(초), -P 보고 간격
pgbench -c 20 -j 4 -T 300 -P 10 ma_base

각기 다른 스택 수준에 적합한 5가지 도구 - 다른 도구를 대체할 수 있는 도구는 없습니다.