From 1f9250130491a454bbcee53fa98d960863e93b1a Mon Sep 17 00:00:00 2001
From: ji-circle <sp202401jw@gmail.com>
Date: Mon, 18 May 2026 19:49:54 +0900
Subject: [PATCH 1/2] =?UTF-8?q?docs:=20=EC=B9=B4=ED=83=88=EB=A1=9C?=
 =?UTF-8?q?=EA=B7=B8=20=EC=B5=9C=EC=A2=85=20=EB=B6=80=ED=95=98=ED=85=8C?=
 =?UTF-8?q?=EC=8A=A4=ED=8A=B8?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...O-BE_2.0_Redis_Cache_Performance_Report.md | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md

diff --git a/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
new file mode 100644
index 0000000..d7eeb84
--- /dev/null
+++ b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
@@ -0,0 +1,60 @@
+# 📊 [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`
+    - **에러율(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차 테스트에서는 물리적인 Disk I/O가 0으로 수렴하면서, 평균 응답 시간이 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에 육박하는 극한의 속도와 100%의 데이터 정합성을 동시에 만족하는 완성도 높은 아키텍처로 진화했습니다.

From 7a5c55cbaf112c3e1fa852ea351daa269208d0c7 Mon Sep 17 00:00:00 2001
From: ji-circle <sp202401jw@gmail.com>
Date: Mon, 18 May 2026 20:39:47 +0900
Subject: [PATCH 2/2] =?UTF-8?q?fix:=20=EC=B9=B4=ED=83=88=EB=A1=9C=EA=B7=B8?=
 =?UTF-8?q?=20=EC=B5=9C=EC=A2=85=20=EB=B6=80=ED=95=98=ED=85=8C=EC=8A=A4?=
 =?UTF-8?q?=ED=8A=B8=20=EB=82=B4=EC=9A=A9=20=EC=88=98=EC=A0=95?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...alog_TO-BE_2.0_Redis_Cache_Performance_Report.md | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
index d7eeb84..7b77c97 100644
--- a/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
+++ b/docs/performance/Catalog_TO-BE_2.0_Redis_Cache_Performance_Report.md
@@ -9,7 +9,7 @@
 
 > **테스트 목적:** 카탈로그 메인 화면 및 단건 조회 API에 Redis 캐시(`@Cacheable`)를 적용한 후, Disk I/O 한계를 돌파하여 목표치인 200 TPS를 안정적으로 상회하는지 검증합니다.
 
-### 📌 부하테스트 타격 결과 (JMeter)
+### 📌 부하테스트 결과 (JMeter)
 
 이번 테스트에서는 캐시 적중 상태에 따라 명확한 성능 차이가 나타나는 'Cache Warming' 현상이 뚜렷하게 관측되었습니다.
 
@@ -31,9 +31,9 @@
 
 ### 🔍 성능 최적화 및 워밍(Warming) 효과 분석
 
-1차 타격(394 TPS)에서 2차 타격(993 TPS)으로의 극적인 성능 상승은 MSA 환경에서 **캐시 워밍(Cache Warming)** 전략이 얼마나 필수적인지를 데이터로 증명합니다. 데이터가 Redis
-메모리에 완벽하게 캐싱된(Full Hit) 2차 테스트에서는 물리적인 Disk I/O가 0으로 수렴하면서, 평균 응답 시간이 25.8ms의 속도를 기록했습니다. 이는 대규모 트래픽이 예상되는 이벤트(선착순
-오픈 등) 발생 직전에 주요 데이터를 메모리에 미리 적재하는 전략이 시스템 생존에 직결됨을 시사합니다.
+1차 타격(394 TPS)에서 2차 타격(993 TPS)으로의 성능 상승은 MSA 환경에서 **캐시 워밍(Cache Warming)** 전략의 효과를 데이터로 보여줍니다. 데이터가 Redis 메모리에 완전히 캐싱된(
+Full Hit) 2차 테스트에서는 MongoDB에 대한 추가 I/O가 발생하지 않아, 평균 응답 시간이 25.8ms를 기록했습니다. 이는 대규모 트래픽이 예상되는 이벤트(선착순 오픈 등) 발생 직전에 주요 데이터를
+메모리에 미리 적재하는 전략이 서비스 안정성에 직결됨을 시사합니다.
 
 ---
 
@@ -50,11 +50,12 @@
 
 ## 3. 종합 결론 및 데이터 정합성 방어 전략 (Cache Eviction)
 
-1. **압도적인 읽기 성능 확보:** 인메모리 데이터베이스인 Redis를 활용하여 카탈로그의 읽기 병목을 완벽하게 제거했습니다. 993 TPS라는 수치는 단일 서비스의 성능 향상뿐만 아니라, 이와 같은 방식으로
+1. **압도적인 읽기 성능 확보:** 인메모리 데이터베이스인 Redis를 활용하여 카탈로그의 읽기 병목을 해소했습니다. 993 TPS라는 수치는 단일 서비스의 성능 향상뿐만 아니라, 이와 같은 방식으로
    구성된 API를 동기적으로
    호출하는 오더(Order) 서비스의 병목까지 연쇄적으로 해결하는 핵심 키가 되었습니다.
 2. **이벤트 기반 정합성(Consistency) 유지:** 성능을 위해 캐시를 도입할 때 가장 경계해야 할 문제는 과거 데이터가 노출되는 'Stale Data' 현상입니다. 이를 방어하기 위해 점주가 상품 정보를
    수정하거나(`product.updated`), 품절 처리(`product.status-changed`)를 할 경우, **Kafka 이벤트를 수신하여 즉각적으로 다중 캐시(목록 캐시, 단건 캐시)를 무효화(
    `@CacheEvict`)하도록** 설계했습니다.
 
-결과적으로 Miche-Let의 카탈로그 서비스는 1,000 TPS에 육박하는 극한의 속도와 100%의 데이터 정합성을 동시에 만족하는 완성도 높은 아키텍처로 진화했습니다.
+결과적으로 Miche-Let의 카탈로그 서비스는 1,000 TPS에 육박하는 처리 성능을 확보했으며, Kafka 이벤트 기반 무효화로 데이터 정합성 리스크를 낮췄습니다.  
+정합성은 운영 환경에서 이벤트 지연/누락 모니터링 지표와 함께 지속 검증이 필요합니다.