Stock Pipeline 성능 테스트 결과 보고서
테스트 개요
Stock Pipeline 시스템의 전체적인 성능과 안정성을 검증하고, 병목지점을 식별하여 최적화 방안을 도출합니다.
테스트 범위
- Kafka 메시지 처리 성능
- REST API 응답 성능
- PostgreSQL 데이터베이스 쿼리 성능
- 시스템 리소스 사용량 분석
Kafka 부하테스트 결과
주요 성능 지표
| 지표 | 결과 |
|---|---|
| 메시지 전송 속도 | 3-5ms (평균 4.1ms) |
| 처리량 (TPS) | ~120 messages/sec |
| 최대 지연시간 | 9ms (NVDA 종목) |
| 안정성 | 100% 성공률 |
종목별 상세 성능
| 종목 | 요청수 | 평균 응답시간 | 최소 | 최대 | TPS |
|---|---|---|---|---|---|
| AAPL | 5 | 4.53ms | 2.89ms | 5.25ms | 0.042 |
| GOOGL | 6 | 3.96ms | 2.24ms | 7.74ms | 0.050 |
| TSLA | 8 | 3.49ms | 2.41ms | 5.48ms | 0.067 |
| NVDA | 6 | 4.36ms | 2.43ms | 9.01ms | 0.050 |
| AMZN | 7 | 4.07ms | 2.37ms | 7.78ms | 0.059 |
분석
- 모든 종목에서 안정적인 응답시간 유지
- CRM 종목에서 1006ms 극단적 지연 1회 발생 (일회성 이슈)
- 타임아웃 설정 최적화 필요
API 부하테스트 결과
전체 지표
| 지표 | 결과 |
|---|---|
| 총 요청수 | 585개 |
| 성공률 | 70.8% (414건) |
| 실패율 | 29.2% (171건) |
| 평균 응답시간 | 33.9ms |
| 최대 TPS | 4.91 req/sec |
Stock Data API (Yahoo Finance) 종목별 성능
| 종목 | 성공률 | 평균 응답시간 | 최대 응답시간 |
|---|---|---|---|
| AAPL | 100% | 290ms | 397ms |
| GOOGL | 80% | 259ms | 457ms |
| AMZN | 89% | 294ms | 487ms |
| TSLA | 73% | 271ms | 530ms |
| META | 90% | 282ms | 469ms |
응답시간 분포
| 구간 | 비율 |
|---|---|
| 0-100ms | 5.2% |
| 100-300ms | 68.4% ✅ |
| 300-500ms | 21.7% ⚠️ |
| 500ms+ | 4.7% ❌ |
오류 원인 분석
| 원인 | 비율 |
|---|---|
| API Rate Limit 초과 | 45% |
| 네트워크 타임아웃 | 30% |
| 서버 내부 오류 | 15% |
| 인증 실패 | 10% |
오류 피크 시간대: 오후 8-9시 (미국 시장 개장 전)
PostgreSQL 쿼리 성능
Heavy Query 성능 (기술적 지표 복합 계산)
| 종목 | 성공률 | 평균 응답시간 | 데이터 크기 |
|---|---|---|---|
| NVDA | 100% | 421ms | 47.0KB |
| CRM | 100% | 474ms | 34.2KB |
| AAPL | 67% | 381ms | 32.7KB |
| GOOGL | 50% | 313ms | 5.6KB |
| META | 33% | 344ms | 11.8KB |
분석: 단일 종목 쿼리 응답은 허용 범위(300-500ms)이나, 복잡한 쿼리의 성공률이 50-67%로 낮아 인덱스 최적화 필요
-- 권장 인덱스 추가
CREATE INDEX idx_stock_symbol_date ON stock_data(symbol, date DESC);
CREATE INDEX idx_technical_indicators ON technical_indicators(symbol, calculation_date);시스템 리소스 사용량
| 상태 | CPU | 메모리 |
|---|---|---|
| 정상 운영 | 20-30% | 5-6GB |
| 부하 테스트 | 50-62% | 8-10GB |
| 최대 피크 | 61.8% | 9.82GB |
현재 용량으로 2-3배 부하까지 처리 가능한 여유 확보
성능 최적화 권장사항
즉시 개선 (High Priority)
API 오류율 개선 (현재 29.2% → 목표 5% 이하)
- Circuit Breaker 패턴 적용
- Retry 정책 최적화 (지수 백오프)
- API Rate Limit 모니터링 강화
Kafka 안정성 강화
request.timeout.ms: 30000 → 15000
retry.backoff.ms: 100 → 200
max.in.flight.requests.per.connection: 5 → 3중장기 개선 (Medium Priority)
Redis 캐싱 TTL 전략
| 데이터 유형 | TTL |
|---|---|
| API 응답 캐시 | 5분 |
| 기술적 지표 | 1시간 |
| 종목 기본정보 | 24시간 |