Skip to content

docs/29 - 카탈로그 최종 부하테스트 #47

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ji-circle merged 2 commits into from
May 18, 2026
Merged

docs/29 - 카탈로그 최종 부하테스트 #47

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1f92501
docs: 카탈로그 최종 부하테스트
ji-circle May 18, 2026
7a5c55c
fix: 카탈로그 최종 부하테스트 내용 수정
ji-circle May 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# 📊 [Catalog Service] Redis 캐시 도입을 통한 읽기(Read) 성능 최적화 리포트 (2차 부하테스트)

본 문서는 AS-IS 아키텍처에서 발생했던 MongoDB Disk I/O 병목 현상(153 TPS 한계)을 해결하기 위해 **Redis 인메모리 캐시 (Cache-Aside 패턴)를** 도입한 후, 카탈로그 조회
성능이 얼마나 향상되었는지 검증한 TO-BE 리포트입니다.

---

## 1. 캐시 도입 후 읽기 성능 측정 및 'Cache Warming' 효과 분석

> **테스트 목적:** 카탈로그 메인 화면 및 단건 조회 API에 Redis 캐시(`@Cacheable`)를 적용한 후, Disk I/O 한계를 돌파하여 목표치인 200 TPS를 안정적으로 상회하는지 검증합니다.

### 📌 부하테스트 결과 (JMeter)

이번 테스트에서는 캐시 적중 상태에 따라 명확한 성능 차이가 나타나는 'Cache Warming' 현상이 뚜렷하게 관측되었습니다.

- **부하 규모:** 100 Threads 동시 요청 (총 1,000건 스파이크)
- **1차 타격 결과 (Cold Cache / Partial Hit):**
- **처리량:** `약 394 TPS`
- 분석: Redis에 데이터가 완전히 적재되지 않아 일부 요청이 MongoDB로 흘러 들어간(Cache Miss) 상태입니다. 그럼에도 불구하고 기존 AS-IS(153 TPS) 대비 2.5배 이상의 성능을
기록했습니다.

<img width="856" height="233" alt="스크린샷 2026-05-18 오후 7 10 54" src="https://github.com/user-attachments/assets/4a36b2dc-d06f-47bd-83f9-22b87f176585" />

- **2차 타격 결과 (Warm Cache / Full Hit) - 최종 지표:**
- **처리량(Throughput):** `993.0 / sec` **(AS-IS 대비 약 646% 성능 향상)**
- **평균 지연 시간(Average):** `25.8 ms` **(AS-IS 대비 약 95% 지연 시간 단축)**
- **최소 / 최대 지연 시간:** `1 ms` / `170 ms`
Comment on lines +24 to +27

@coderabbitai coderabbitai Bot May 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

목표 지연시간 달성 여부를 명시해 주세요.

Line 26 기준 평균 25.8ms는 링크된 목표(≤10ms)와 불일치합니다. 현재 표/결론은 “전면 달성”처럼 읽혀서, 목표 미달 항목과 후속 계획을 함께 명시하는 게 필요합니다.

제안 문구(예시) 
-    - **평균 지연 시간(Average):** `25.8 ms` **(AS-IS 대비 약 95% 지연 시간 단축)**
+    - **평균 지연 시간(Average):** `25.8 ms` **(AS-IS 대비 약 95% 지연 시간 단축)**
+    - ⚠️ **목표 대비 상태:** 이슈 목표(≤ 10ms)에는 아직 미달이며, 추가 최적화(직렬화 비용/네트워크 홉/키 설계 튜닝)가 필요
-| **Average Time** | 539 ms                | **25.8 ms**                  | **`- 95.2% 단축`**   |
+| **Average Time** | 539 ms                | **25.8 ms**                  | **`- 95.2% 단축 (목표 ≤10ms 미달)`** |

Also applies to: 40-47

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md` around
lines 24 - 27, Update the "2차 타격 결과 (Warm Cache / Full Hit) - 최종 지표" section so
it clearly states whether the ≤10ms latency target was met: explicitly note that
the reported 평균 지연 시간 25.8 ms exceeds the ≤10 ms goal, mark the goal as unmet,
and add a brief remediation/next-steps sentence (e.g., investigate cache hit
amplification, tune Redis settings, or schedule follow-up testing). Make the
same change for the analogous block referenced at lines 40-47; refer to the
heading "2차 타격 결과 (Warm Cache / Full Hit) - 최종 지표" and the metric entries "평균 지연
시간(Average): 25.8 ms" and throughput/min-max values so the reviewer can locate
and update the text.

- **에러율(Error %):** `0.0%`

<img width="854" height="252" alt="스크린샷 2026-05-18 오후 7 11 05" src="https://github.com/user-attachments/assets/e9475737-5fbb-4714-a9c4-434bb4c4d7a3" />

### 🔍 성능 최적화 및 워밍(Warming) 효과 분석

1차 타격(394 TPS)에서 2차 타격(993 TPS)으로의 성능 상승은 MSA 환경에서 **캐시 워밍(Cache Warming)** 전략의 효과를 데이터로 보여줍니다. 데이터가 Redis 메모리에 완전히 캐싱된(
Full Hit) 2차 테스트에서는 MongoDB에 대한 추가 I/O가 발생하지 않아, 평균 응답 시간이 25.8ms를 기록했습니다. 이는 대규모 트래픽이 예상되는 이벤트(선착순 오픈 등) 발생 직전에 주요 데이터를
메모리에 미리 적재하는 전략이 서비스 안정성에 직결됨을 시사합니다.

---

## 2. 성능 지표 비교 (AS-IS vs TO-BE)

| 지표 | AS-IS (MongoDB 직접 조회) | TO-BE (Redis Cache Full Hit) | 개선 효과 (증감률) |
|:-----------------|:----------------------|:-----------------------------|:-------------------|
| **Throughput** | 153.5 TPS | **993.0 TPS** | **`+ 646% 수직 상승`** |
| **Average Time** | 539 ms | **25.8 ms** | **`- 95.2% 단축`** |
| **Max Time** | 2,153 ms | **170 ms** | **`- 92.1% 단축`** |
| **Error Rate** | 0.0% | **0.0%** | 유지 (안정성 보장) |

---

## 3. 종합 결론 및 데이터 정합성 방어 전략 (Cache Eviction)

1. **압도적인 읽기 성능 확보:** 인메모리 데이터베이스인 Redis를 활용하여 카탈로그의 읽기 병목을 해소했습니다. 993 TPS라는 수치는 단일 서비스의 성능 향상뿐만 아니라, 이와 같은 방식으로
구성된 API를 동기적으로
호출하는 오더(Order) 서비스의 병목까지 연쇄적으로 해결하는 핵심 키가 되었습니다.
2. **이벤트 기반 정합성(Consistency) 유지:** 성능을 위해 캐시를 도입할 때 가장 경계해야 할 문제는 과거 데이터가 노출되는 'Stale Data' 현상입니다. 이를 방어하기 위해 점주가 상품 정보를
수정하거나(`product.updated`), 품절 처리(`product.status-changed`)를 할 경우, **Kafka 이벤트를 수신하여 즉각적으로 다중 캐시(목록 캐시, 단건 캐시)를 무효화(
`@CacheEvict`)하도록** 설계했습니다.

결과적으로 Miche-Let의 카탈로그 서비스는 1,000 TPS에 육박하는 처리 성능을 확보했으며, Kafka 이벤트 기반 무효화로 데이터 정합성 리스크를 낮췄습니다.
정합성은 운영 환경에서 이벤트 지연/누락 모니터링 지표와 함께 지속 검증이 필요합니다.
Loading