📃 DATT 01 - 성능 측정 환경 구축 및 응답 시간 계측

오늘 작업 목표

오늘 해결하려는 문제:

• 현재 검색 API의 실제 성능 상태 파악
• 병목 위치 확인을 위한 계측 환경 구축
• 개선 전 기준(Baseline) 데이터 확보
• 이후 성능 개선 결과를 비교할 수 있는 기반 마련

---

현재 문제 상황

현재 DATT 검색 구조는 사용자 요청 시마다 실시간 크롤링을 수행한다.

Client
    ↓
Spring Boot
    ↓
FastAPI Crawling Engine
    ↓
External Place Sources
    ↓
PostgreSQL(PostGIS)

현재는 체감상 느리다고만 인지하고 있으며,
실제로 어느 계층이 병목인지 정확하게 파악되지 않은 상태다.

---

문제 현상

- 검색 응답 시간이 일정하지 않음
- 특정 지역 검색 시 응답 시간이 급격히 증가
- 카테고리 변경 시 재로딩이 반복적으로 발생
- 외부 사이트 응답 상태에 따라 전체 응답 시간이 영향을 받음

---

발생 조건

• 지역 범위가 넓은 경우
• 외부 사이트 응답이 느린 경우
• 크롤링 데이터가 많은 경우
• 카테고리 전환이 반복되는 경우

예시:

• 인천
• 강남
• 홍대

---

현재 의심되는 원인

현재 시점에서 의심되는 원인은 다음과 같다.

1. 실시간 외부 크롤링 I/O 병목
2. 외부 사이트 응답 지연
3. 사용자 요청 흐름 내부에 DB 저장 과정 포함
4. 요청마다 전체 크롤링이 재수행되는 구조

---

주의

현재 원인은 아직 확정되지 않았다.

위 내용은:

추측 기반 가설

이며,
실제 로그 및 성능 측정을 통해 검증이 필요하다.

---

측정 및 분석

오늘 구축할 측정 항목

항목	목적
API 응답 시간	전체 처리 시간 측정
FastAPI 크롤링 시간	외부 I/O 병목 확인
DB Insert 시간	저장 비용 확인
DB Query 시간	조회 비용 확인
실패율	Timeout/Error 확인

---

수집한 로그

구축 예정 로그 형식:

API 응답 로그

[SEARCH_API]
keyword=인천
category=cafe
durationMs=8420
status=200

---

크롤링 로그

[CRAWLING]
keyword=인천
category=cafe
durationMs=6210
resultCount=42

---

DB Query 로그

[DB_QUERY]
query=searchPlaces
durationMs=180

---

성능 측정 결과

현재는 아직 계측 환경 구축 단계다.

따라서 아래 수치는 아직 비어 있는 상태다.

항목	결과
평균 응답 시간	측정 예정
P95	측정 예정
P99	측정 예정
실패율	측정 예정

---

실제 확인된 원인

현재는 아직 측정 이전 단계다.

따라서 실제 원인은 아직 확인되지 않았다.

오늘의 목표는:

병목을 추측이 아니라 수치 기반으로 확인 가능한 상태를 만드는 것

이다.

---

적용한 해결 방법

오늘 진행할 작업:

1. Spring Interceptor 기반 API 응답 시간 측정
2. FastAPI 크롤링 시간 로깅 추가
3. DB Query 시간 로깅 추가
4. k6 부하 테스트 환경 구축
5. 성능 측정 기준 시나리오 정의

---

코드 변경 사항

Before

기존에는 API 응답 시간을 별도로 기록하지 않았다.

@GetMapping("/search")
public ResponseEntity<?> search(String keyword) {

    List<Place> result = placeService.search(keyword);

    return ResponseEntity.ok(result);
}

---

After

Interceptor 기반 응답 시간 측정 추가 예정.

@Component
public class RequestLoggingInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(
            HttpServletRequest request,
            HttpServletResponse response,
            Object handler
    ) {

        request.setAttribute("startTime", System.currentTimeMillis());

        return true;
    }

    @Override
    public void afterCompletion(
            HttpServletRequest request,
            HttpServletResponse response,
            Object handler,
            Exception ex
    ) {

        long startTime = (long) request.getAttribute("startTime");

        long duration = System.currentTimeMillis() - startTime;

        log.info(
                "[SEARCH_API] path={}, durationMs={}, status={}",
                request.getRequestURI(),
                duration,
                response.getStatus()
        );
    }
}

---

Trade-off

이번 작업으로 인해 발생하는 Trade-off:

장점	단점
병목 위치를 수치 기반으로 분석 가능	로깅 증가로 로그량 증가
개선 전/후 비교 가능	측정 코드 추가 필요
운영 관점 분석 가능	초기 작업 공수 증가

---

운영 관점에서의 고려 사항

운영 환경이라면 다음 항목도 추가적으로 고려해야 한다.

• TraceId 기반 요청 추적
• 로그 수집 시스템 연동
• 로그 보관 정책
• P95/P99 기반 모니터링
• 비정상 응답 탐지

---

회고

이번 단계에서 중요한 것은:

“개선”

보다

“측정 가능한 상태를 만드는 것”

이다.

실무에서는 단순히:

느리다

가 아니라:

어디가 얼마나 느린가

를 수치 기반으로 설명할 수 있어야 한다.

이번 작업은 이후 모든 성능 개선의 기준점(Baseline)이 된다.

---

다음 작업 예정

다음 단계:

1. k6 기반 실제 부하 테스트 수행
2. 지역별/카테고리별 응답 시간 측정
3. 병목 위치 분석
4. 배치 구조 전환 설계 시작