---
kind: QUESTION
slug: performance-and-capacity-unmeasured
title: 실제 성능·용량 특성을 어떤 모듈에서도 측정하지 않았다
topic: multitenancy-isolation
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: open-question:performance-and-capacity-unmeasured
questionStatus: OPEN
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# 실제 성능·용량 특성을 어떤 모듈에서도 측정하지 않았다

이 분석은 성능을 측정하지 않았다. 문서에 남은 성능과 용량 관련 서술은 전부 코드가 선언한 상한과 그 강제 여부에 대한 것이다.

## 사실

성능 레인은 릴리스 게이트에서 의도적으로 빠져 있다. 기계 의존적인 측정을 게이트 판정의 입력으로 삼지 않는다는 결정이다.

풀 사이징 수식은 설정 파일 주석에 있고 부하 테스트로 조정하라고 적혀 있다.

테넌트 풀 예산은 두 상한을 갖지만 그 값이 어떤 부하에서 적절한지에 대한 근거가 없다.

httpclient 의 성능 레인과 벤치마크는 기계 의존적이라는 이유로 기본 검사에서 빠져 있다.

GraphQL 리프의 등급표는 실부하와 장애를 미달성으로 적고, 증거가 없으면 릴리스 게이트가 거부한다고 적는다.

## 가정

선언된 상한들이 합리적인 범위에 있다고 전제하고 있다. 그 전제의 근거는 문서에 적힌 시작점 수식이며 측정이 아니다.

## 미지수

각 상한이 실제 부하에서 적절한가.

테넌트 풀 예산의 두 상한이 어떤 테넌트 수와 부하에서 유효한가.

성능 회귀가 발생하면 무엇이 그것을 알아채는가.

## 제약

실부하 증거는 실제 부하 인프라를 요구한다. 리프 안에서 생성할 수 없다.

기계 의존적 측정을 게이트에 넣지 않는다는 결정이 이미 있다.

## 선택지

전용 성능 인프라를 만든다
러너와 워밍업과 표본 수와 기록된 기준선이 필요하다. 그것이 생기면 별도 레인으로 만든다.

측정하지 않은 상태를 명시적으로 유지한다
등급표가 이미 그렇게 하고 있다. 릴리스 게이트가 증거 없이는 거부한다.

## 다음 검증

성능 레인을 실행할 인프라를 정하고, 어떤 지표를 어떤 조건에서 잴지 먼저 문서로 고정한다. 그다음 기준선을 기록한다.

기준선이 기록되면 이 질문을 닫고, 이후의 측정은 그 기준선과의 비교가 된다.

인프라를 만들지 않기로 하면 그 결정과 그때 포기하는 것을 기록한다.

## 관계

- **성능 측정은 릴리스 게이트에 넣지 않는다**
  이 질문이 전제하는 결정이다.
- **tenant별 풀이 개별적으로 합리적이고 그 합이 서버 상한을 넘긴다**
  측정되지 않은 용량 판단의 사례다.
- **능력 등급은 코드가 아니라 실행된 증거에서 파생한다**
  실부하 증거가 최상위 등급의 조건인 이유다.