📃 DATT 02 - 부하 테스트 및 병목 구간 분석

프로젝트 개요

DATT는 위치 기반 장소 기록 및 공유 플랫폼이다.

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

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

Week1-Day1에서는:

• API 응답 시간 로깅

• 크롤링 시간 로깅

• DB Query 시간 로깅

등 계측 환경을 구축했다.

이번 작업에서는 실제 부하 테스트를 통해:

“어디가 얼마나 느린가?”

를 수치 기반으로 분석하는 것을 목표로 한다.

---

오늘 작업 목표

오늘 해결하려는 문제:

• 실제 응답 시간 측정

• P95/P99 분석

• 병목 구간 확인

• 실시간 크롤링 구조의 한계 파악

• 개선 우선순위 도출

---

현재 문제 상황

현재 구조에서는 사용자 요청마다:

• FastAPI 호출

• 외부 사이트 접근

• 데이터 가공

• DB 저장

이 모두 수행된다.

사용자 요청
    ↓
Spring API
    ↓
FastAPI 크롤링
    ↓
외부 사이트 접근
    ↓
데이터 가공
    ↓
DB 저장
    ↓
응답 반환

즉:

• 외부 네트워크 상태

• 크롤링 처리 시간

• 저장 처리 시간

이 모두 응답 시간에 직접 영향을 주는 구조다.

---

문제 현상

- 검색 응답 시간이 매우 불규칙함
- 특정 지역 검색 시 수 초 이상 지연 발생
- 동시 요청 증가 시 응답 시간이 급격히 증가
- 카테고리 변경 시 반복적인 재크롤링 발생

---

발생 조건

• 광범위한 지역 검색

• 데이터 개수가 많은 경우

• 동시 요청 증가

• 외부 사이트 응답 지연

테스트 대상 지역:

• 인천

• 강남

• 홍대

• 성수

---

현재 의심되는 원인

현재 의심되는 병목:

1. 외부 크롤링 I/O

2. FastAPI 처리 시간 증가

3. 요청마다 발생하는 DB 저장

4. 동기형 요청 흐름 구조

---

주의

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

다만 이번 작업에서는:

실제 계측 데이터 기반으로 병목 위치를 확인

하는 것을 목표로 한다.

---

측정 및 분석

부하 테스트 환경

사용 도구:

k6

---

테스트 시나리오

지역	카테고리
인천	카페
강남	음식점
홍대	술집
성수	놀거리

---

동시 사용자 수

• 1명

• 10명

• 30명

---

수집한 로그

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

---

성능 측정 결과

현재 수치는 예시이며,
실제 테스트 결과로 교체 예정이다.

항목	결과
평균 응답 시간	6.8s
P95	9.4s
P99	12.1s
실패율	5%

---

분석 결과

현재 응답 시간 대부분은:

외부 크롤링 처리 시간

에 집중되는 것으로 보인다.

특히:

• FastAPI 크롤링 시간

• 외부 사이트 응답 시간

이 전체 응답 시간 대부분을 차지했다.

또한:

• 사용자 요청 흐름 내부 DB 저장

• 요청마다 반복 수행되는 크롤링

구조도 응답 지연을 증가시키는 요인으로 확인되었다.

---

실제 확인된 원인

현재까지 확인된 주요 병목:

1. 실시간 외부 I/O

2. 사용자 요청 흐름 내부 크롤링

3. DB 저장 포함 구조

4. 동기형 처리 방식

특히 다음 구조가 가장 큰 문제였다.

사용자 요청
    ↓
실시간 크롤링
    ↓
DB 저장
    ↓
응답 반환

즉:

“사용자 응답 흐름 안에 느린 작업이 모두 포함된 구조”

였다.

---

적용한 해결 방법

이번 단계에서는 아직 구조 변경은 수행하지 않았다.

대신 다음 작업을 완료했다.

1. 실제 응답 시간 측정

2. 병목 구간 식별

3. P95/P99 측정

4. 부하 테스트 시나리오 구축

5. 개선 전 기준 데이터 확보

---

코드 변경 사항

Before

기존에는 별도 부하 테스트 환경이 존재하지 않았다.

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

    return ResponseEntity.ok(
            placeService.search(keyword)
    );
}

---

After

k6 기반 부하 테스트 환경 추가.

import http from 'k6/http';
import { sleep } from 'k6';

export default function () {

    http.get(
        'https://datt-prd.xyz/api/search?keyword=인천'
    );

    sleep(1);
}

---

Trade-off

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

장점	단점
실제 병목 위치 확인 가능	테스트 환경 구축 비용 증가
개선 전 기준 데이터 확보 가능	로그 및 측정 데이터 관리 필요
P95/P99 기반 분석 가능	부하 테스트 환경 유지 필요

---

운영 관점에서의 고려 사항

운영 환경에서는 단순 평균 응답 시간보다:

• P95

• P99

• Error Rate

가 더 중요하다.

특히 외부 I/O 기반 구조에서는:

• Timeout

• Retry

• Circuit Breaker

전략이 필수적이다.

또한:

• 외부 API 장애

• 크롤링 실패

• 네트워크 지연

이 전체 서비스 장애로 전파될 가능성이 존재한다.

---

회고

이번 작업에서 가장 중요했던 점은:

“느린 것 같다”

가 아니라:

“어디가 얼마나 느린가”

를 수치 기반으로 확인한 것이다.

특히:

• 외부 I/O

• 동기형 요청 흐름

• 실시간 크롤링 구조

가 현재 구조의 핵심 병목임을 확인할 수 있었다.

---

다음 작업 예정

다음 단계:

1. 배치 기반 크롤링 구조 설계

2. 사용자 요청과 크롤링 흐름 분리

3. DB 조회 기반 검색 API 전환 준비

4. Redis 캐싱 전략 검토