크기 조정 전에 하나의 느린 요청 따르기

명확한 예상 결과가 있는 요청을 선택하십시오

예시적인 보고서 엔드포인트의 경우 경로 패턴, 대략적인 데이터 크기, 인증 컨텍스트 및 백그라운드 작업을 생성하는지 여부를 기록하십시오. 테스트 계정과 대표적인 정리된 데이터를 사용하십시오. 토큰, 고객 식별자 또는 전체 요청 본문을 사고 노트에 복사하지 마십시오.

첫 요청 시작 비용을 반복적인 정상 상태 동작과 분리하십시오. UTC 기간과 릴리스 개정을 기록하십시오. 모든 경로가 느린지, 대규모 보고서만 영향을 받는지, 또는 지연이 하나의 외부 종속성을 따르는지 판단하십시오. 이러한 구분은 다음 측정을 관련 없는 메트릭의 광범위한 수집보다 더 유용하게 만듭니다.

이중 계산 없이 타임라인을 구축하십시오

OpenTelemetry 트레이스는 서비스 경계를 넘어 전파된 컨텍스트를 통해 관련 스팬을 연결합니다. 타임스탬프만 일치하는 것으로는 충분하지 않습니다. 중첩된 동기 스팬과 병렬 호출은 겹칠 수 있습니다. 비동기 자식은 부모보다 오래 살 수 있으므로 모든 스팬 기간을 더하면 경과 시간이 이중 계산될 수 있습니다. 요청이 완료되는 시점을 결정하는 작업을 따르십시오.

기술 참조: OpenTelemetry 트레이스 · OpenTelemetry 스팬 종료 동작.

가장 큰 간격은 근본 원인이 아니라 검사할 위치를 시사합니다. API에서 측정된 데이터베이스 간격은 쿼리가 데이터베이스에 도달하기 전 연결 대기를 포함할 수 있습니다. 텔레메트리 누락도 작업이 발생하지 않았다는 것을 증명하지 않습니다. 샘플링과 계측 범위를 검사하십시오.

애플리케이션과 호스트 관찰을 연관시키십시오

동일한 기간에 대한 요청 타이밍, 오류, 데이터베이스 연결 사용량, 큐 수명, CPU, 메모리 및 디스크 압력을 수집하십시오. 동시 백업, 마이그레이션 또는 릴리스를 기록하십시오. 단일 사용률 스크린샷은 요청에 영향을 준 버스트를 놓칠 수 있습니다.

적절한 보존 및 액세스 제어가 있는 마스킹된 로그에서 상관 ID와 타임스탬프를 사용하십시오. 원시 비밀, 고객 페이로드 및 무제한 메트릭 레이블을 피하십시오. 가설에 필요한 경계를 계측하고 오버헤드를 검토하십시오. 새로운 추적 에이전트 자체가 관찰할 가치가 있는 변경입니다.

또 다른 사고를 일으키지 않고 쿼리를 검사하십시오

먼저 쿼리 형태, 입력 크기 특성 및 연결 또는 잠금 대기를 식별하십시오. PostgreSQL EXPLAIN 은 계획을 설명합니다; EXPLAIN ANALYZE 은 실제로 명령문을 실행하고 계측 오버헤드를 추가합니다. 쓰기는 데이터를 변경할 수 있으며, 비용이 많이 드는 읽기도 부하를 생성합니다. 초기 조사에는 격리된 대표 데이터베이스를 사용하십시오.

플래너 비용은 경과 밀리초가 아닙니다. 작은 테스트 테이블은 애플리케이션의 더 큰 데이터 세트와 다른 계획을 산출할 수 있습니다. 통계, 인덱스 및 분포를 검토하고 변경 후 동일한 쿼리 형태를 비교하십시오. 단지 타이밍을 얻기 위해 프로덕션의 분석 명령에 알 수 없는 쓰기를 붙여넣지 마십시오.

기술 참조: PostgreSQL EXPLAIN.

하나의 변경이 개선해야 할 것을 예측하십시오

풀 대기가 지배적이면 불필요하게 연결을 보유하는 워커 연결 또는 요청을 검사하십시오. 쿼리 실행이 지배적이면 계획과 요청된 행을 검사하십시오. 외부 API가 지배적이면 타임아웃, 재시도 및 작업이 동기식이어야 하는지 검토하십시오. 직렬화 중 CPU 포화는 다른 실험을 가리킵니다.

예측을 작성하십시오: 내보내기 동시성을 줄이면 내보내기가 더 오래 걸리면서 API 풀 대기가 줄어야 합니다. 이는 트레이드오프를 드러냅니다. 동일한 요청 조합을 반복하고, 지연 시간과 오류를 비교하며, 개선이 단순히 실패를 계속 증가하는 큐로 이동시키지 않았는지 확인하십시오.

결과와 그 불확실성을 유지하십시오

원래 관찰, 테스트된 변경, 비교 방법 및 남은 불확실성을 기록하십시오. 증거가 가설과 모순되면 적절한 경우 격리된 변경을 되돌리고 다른 경계를 조사하십시오. 설명 없이 영구적인 튜닝 변경을 축적하지 마십시오.

측정이 추가 할당으로 해결할 수 있는 리소스 제약을 식별할 때 크기를 조정하십시오. 다음을 사용하십시오: 워크로드 예산 그리고 다음에서 릴리스 회귀를 캡처하십시오: 사고 요약. 결과는 약속된 지연 시간이나 제공자 벤치마크가 아닌 추론된 진단입니다.