[BE] 인기 해시태그 조회 기능 성능 측정

[YehyeokBang]

기능 설명

인기 해시태그는 UI상 가장 잘보이는 위치고, 모두의 보따리에 접속하면 꼭 호출되는 기능입니다.

클라이언트가 화면 전환 시마다 해당 API를 요청한다고 가정하면, 전체 트래픽 중 상당 비율을 차지하게 됩니다.
특히 이 API는 검색이나 생성 같은 추가 액션 없이 자동 호출되는 특성 때문에 부하의 주요 원인이 될 가능성이 높습니다.

문제 인식

현재 인기 해시태그는 매 요청마다 집계 쿼리를 수행하고 있습니다.
데이터가 누적될수록 쿼리 부하가 커지고, 결과적으로 응답 지연 및 DB 병목이 발생할 위험이 있습니다.

어떻게 할 것인가?

우선 실제 쿼리 부하를 검증하여 문제를 수치적으로 확인할 예정입니다.

이후 병목이 확인된다면, 아래와 같은 방법을 고민하고 적용해볼 예정입니다.

• 캐싱 도입: 자주 조회되는 집계 결과를 일정 시간 동안 메모리에 저장
• 반정규화: 실시간 집계 대신 사전 계산된 데이터를 별도 컬럼/테이블에 유지
• 집계 테이블 도입: 주기적으로 갱신되는 통계 테이블을 활용하여 조회 부하 완화

기대 효과

• 모두의 보따리 화면 진입 시 트래픽 급증 상황에서도 안정적인 응답 유지

추가 맥락

No response

체크리스트

• 기존에 제안된 유사한 기능이 없는지 확인했습니다.

[YehyeokBang]

실행 쿼리

SELECT
    h.id AS hashtagId,
    h.name AS hashtagName,
    COUNT(bth.id) AS usageCount
FROM hashtag h
INNER JOIN bottari_template_hashtag bth ON bth.hashtag_id = h.id
WHERE bth.deleted_at IS NULL
  AND bth.created_at >= '2025-10-13 12:00:00'
GROUP BY h.id, h.name
ORDER BY usageCount DESC, h.id DESC
LIMIT 100; -- 애플리케이션 검증으로는 1에서 100까지 가능

테스트 환경

template_count	hashtag_count	link_count
1000000	500178	3551901

• AWS EC2 t4g.micro 환경에서 docker 컨테이너로 띄워둔 MySQL 8.0.x 버전

테스트 결과

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	bth	null	ALL	FKgkdc255c9dvub5pwx8tppy4h9	null	null	null	3285209	3.33	Using where; Using temporary; Using filesort
1	SIMPLE	h	null	eq_ref	PRIMARY,UKtnicok67w95ajkoau49jeg9fm	PRIMARY	8	bottari.bth.hashtag_id	1	100	null

실행 계획 요약

위 더미 데이터 기준으로 약 4.9초 소요
bottari_template_hashtag 테이블 전체(355만 건) 스캔 (인덱스 사용 X)
355만 건 중에서 조건(집계 기간)에 맞는 35015건만 추출 (99%의 데이터를 읽고 버림)
임시 테이블을 생성하여 GROUP BY, COUNT 처리

-> Limit: 100 row(s)  (actual time=4903..4903 rows=100 loops=1)
    -> Sort: usageCount DESC, h.id DESC, limit input to 100 row(s) per chunk  (actual time=4903..4903 rows=100 loops=1)
        -> Table scan on <temporary>  (actual time=4891..4896 rows=33786 loops=1)
            -> Aggregate using temporary table  (actual time=4891..4891 rows=33786 loops=1)
                -> Nested loop inner join  (cost=460148 rows=109496) (actual time=14.2..4672 rows=35015 loops=1)
                    -> Filter: ((bth.deleted_at is null) and (bth.created_at >= TIMESTAMP'2025-10-13 12:00:00') and (bth.hashtag_id is not null))  (cost=339767 rows=109496) (actual time=11.2..1928 rows=35015 loops=1)
                        -> Table scan on bth  (cost=339767 rows=3.29e+6) (actual time=11.2..1578 rows=3.55e+6 loops=1)
                    -> Single-row index lookup on h using PRIMARY (id = bth.hashtag_id)  (cost=0.999 rows=1) (actual time=0.0781..0.0781 rows=1 loops=35015)

[YehyeokBang]

이전 쿼리는 bottari_template_hashtag 테이블 전체 355만 건을 스캔한 뒤,
그중 3만5천 건만 사용했기 때문에 실제로는 99%의 데이터가 불필요하게 읽힌(읽히고 버려짐) 상태였음

해결 방법

CREATE INDEX idx_bth_created_deleted_hashtag
  ON bottari_template_hashtag (created_at, deleted_at, hashtag_id);

선택도가 높은 created_at을 선두로 배치함
deleted_at은 보조 필터, hashtag_id는 조인 및 GROUP BY 보조함

결과

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	bth	null	range	FKgkdc255c9dvub5pwx8tppy4h9,idx_bth_created_deleted_hashtag	idx_bth_created_deleted_hashtag	18	null	67886	10	Using where; Using index; Using temporary; Using filesort
1	SIMPLE	h	null	eq_ref	PRIMARY,UKtnicok67w95ajkoau49jeg9fm	PRIMARY	8	bottari.bth.hashtag_id	1	100	null

요약

Full Scan → Index Range Scan으로 변경
스캔 범위는 약 355만 → 6.7만 row 수준으로 축소
쿼리 수행 시간: 약 4.9초 → 0.2초 내외로 단축

-> Limit: 10 row(s)  (actual time=205..205 rows=10 loops=1)
    -> Sort: usageCount DESC, h.id DESC, limit input to 10 row(s) per chunk  (actual time=205..205 rows=10 loops=1)
        -> Table scan on <temporary>  (actual time=194..200 rows=33786 loops=1)
            -> Aggregate using temporary table  (actual time=194..194 rows=33786 loops=1)
                -> Nested loop inner join  (cost=16243 rows=6789) (actual time=0.631..148 rows=35015 loops=1)
                    -> Filter: ((bth.deleted_at is null) and (bth.created_at >= TIMESTAMP'2025-10-13 12:00:00') and (bth.hashtag_id is not null))  (cost=13867 rows=6789) (actual time=0.616..21.1 rows=35015 loops=1)
                        -> Covering index range scan on bth using idx_bth_created_deleted_hashtag over ('2025-10-13 12:00:00.000000' <= created_at AND NULL <= deleted_at)  (cost=13867 rows=67886) (actual time=0.613..14.4 rows=35015 loops=1)
                    -> Single-row index lookup on h using PRIMARY (id = bth.hashtag_id)  (cost=0.25 rows=1) (actual time=0.00341..0.00344 rows=1 loops=35015)

이후 고려할 점

created_at이 계속 증가하므로, 시간이 지날수록 range scan 범위는 커질 수 있음
향후 데이터 증가 시점에서는 롤링 테이블 분리(최근 데이터만 유지) 또는 집계 테이블/캐싱 전략으로 read 부하를 분리 가능함

[YehyeokBang]

요약

초기 테스트에서는 DB 부하가 병목 지점으로 확인되었음
bottari_template_hashtag 테이블에 인덱스가 없었고, HikariCP 풀 사이즈가 비효율적으로 설정되어 있었음
이에 따라 애플리케이션의 CPU는 여유가 있었지만, DB 인스턴스 CPU 사용률이 높게 나타남

인덱스 최적화와 커넥션 풀 조정만으로 약 7배 성능 향상을 달성했고,
병목 구간이 DB에서 애플리케이션 계층으로 이동하며, 전반적인 처리 효율이 균형을 이루게 됨

환경

• t4g.micro
  • vCPU: 2
  • 메모리(GiB): 1
  • Swap(GB): 2
• 데이터
  • bottari_template_hashtag: 350,000건
  • bottari_template: 100,000건
  • hashtag: 50,000건

부하 테스트

VU 200, 모두의 보따리 조회 및 약간의 클릭 시나리오

• 평균 RPS: 26.99
• P95: 6s
• P99: 11s

애플리케이션 인스턴스 CPU

DB 인스턴스 CPU

애플리케이션은 안정적이지만 DB에서 병목 발생이라고 예상함

---

인덱스 추가 및 Hikari Connection Pool 사이즈 조정 (개선)

• bottari_template_hashtag 인덱스 추가 (created_at, deleted_at, hashtag_id)
• maximum-pool-size: 5 (default 설정 10에서 변경)
  • DB 동시 처리 한계를 초과했다고 판단하여 커넥션 풀을 줄임
• minimum-idle: 5

VU 200, 모두의 보따리 조회 및 약간의 클릭 시나리오

• 평균 RPS: 189.97
• P95: 279ms
• P99: 476ms

애플리케이션 인스턴스 CPU

DB 인스턴스 CPU

DB 부하가 크게 감소했고, 애플리케이션 인스턴스의 CPU 사용률이 약 70% 수준까지 상승하며 리소스 활용이 개선됨

[YehyeokBang]

추가 검증

DB 부하를 줄일 수 있다면, 전반적인 조회 성능을 더욱 향상시킬 수 있을 것 같다.
인기 해시태그는 자주 변경되지 않는 데이터이기 때문에, 1시간 정도의 지연이 발생하더라도 큰 문제가 되지 않는다.
즉, 약간의 데이터 불일치가 허용되는 캐시 친화적인 특성을 지니고 있다.

환경

개발 및 운영 환경은 구성과 리소스 스펙이 다르므로,
아래의 테스트 결과는 절대적인 수치보다는 성능 변화의 경향성을 파악하는 용도로 보는 것이 적절합니다.

• 로컬 환경
  • 다른 변수 최소화 (실행 중인 프로세스, 시작 온도 등)
• DB와 Redis는 컨테이너로 실행 (이전 부하테스트와 같은 버전)

DB 컨테이너의 CPU 사용량
평균: 289.93% | 최대: 384.98%

DB 컨테이너의 CPU 사용량
평균: 30.39% | 최대: 89.84%

Redis 컨테이너의 CPU 사용량
평균: 1.35% | 최대: 3.49%

결과 요약

구분	평균 CPU 사용률	최대 CPU 사용률
캐시 미적용 (MySQL)	289.93%	384.98%
캐시 적용 (MySQL)	30.39%	89.84%

• 평균 CPU 사용률 약 89.5% 감소 (약 9.5배 개선)
• 최대 CPU 사용률 약 76.7% 감소 (약 4.3배 개선)

캐싱 적용 후, 테스트 환경에서 평균 RPS가 약 3배(117 → 345) 증가했다.
DB 컨테이너의 CPU 부하가 크게 감소했고, 조회 중심 트래픽에 대해 Redis 캐싱의 효과를 명확히 확인할 수 있었다.

추가적인 고려

현재 부하 테스트 결과, Redis에서 부하가 급격히 증가하는 현상은 관찰되지 않았다.
다만 향후 다른 조회성 데이터를 캐싱할 계획이 있다면, 그때 Redis의 리소스 사용량을 함께 모니터링할 필요가 있다.

Redis에 저장되는 데이터의 용량은 현재 기준 약 6KB 수준으로,
인기 해시태그 기능 특성상 전체 사용자가 공유하는 소수의 키만 생성되기 때문에
메모리 사용 측면에서 큰 문제는 없을 것으로 판단된다.

다만 TTL(만료 정책) 에 대한 세부 설정은 추후 트래픽 패턴과 데이터 갱신 주기에 맞춰
조정이 필요할 것으로 보인다.

[YehyeokBang]

캐시가 만료되는 경우 (부하 테스트, 캐시 스탬피드 현상)

14:45:18~ 부근에서 캐시에 저장된 데이터를 만료시키는 것으로 테스트 환경 구축함
여러 요청이 동시에 키가 없는 것을 확인하고 DB를 확인하러 가면서 일시적인 DB 컨테이너의 CPU 부하 발생

해결 방법

다양한 방법이 존재함

• 만료 전 캐시에 데이터를 미리 적재하는 방법 (스케줄링을 통한 캐시 웜업 등)
• @Cacheable(value = "popularHashtags", sync = true) sync를 활용하여 프레임워클 레벨에서 키에 락을 걸고 제어하는 방법
• 등...