쿼리 튜닝을 통해 피드 개선하기

들어가며

안녕하세요, 노머스 백엔드팀에 합류한 임두현입니다.

노머스는 fromm이라는 소통 앱을 서비스하고 있습니다. 그 중 채널이라는 서비스가 있는데, 채널은 아티스트와 팬들이 게시글과 댓글을 통해 소통하며, 라이브, 공지사항, 다시보기 등 해당 아티스트가 소속된 그룹의 정보를 볼 수 있는 공간입니다.

첫 업무로 부하테스트를 진행하면서 채널에서 높은 부하와 latency가 발생한다는 것을 파악했고, 이에 문제의 원인을 분석하고 개선하기로 했습니다.

문제 분석

RDS에는 성능 개선 도우미라는 기능이 있어 부하를 많이 차지하는 쿼리를 확인할 수 있습니다.

이 도구를 통해 분석한 결과, 문제가 되는 쿼리는 팬 피드를 불러오는 쿼리였습니다. 다양한 비즈니스 요구사항이 추가되면서 팬 피드 조회 쿼리에 여러 관계(relation)가 추가되어 부하가 발생한 것입니다.

개발 과정에서 기존 기획에 없던 요구사항이나 추가 기획이 맞물려 기존 API의 성능이 저하되는 경우를 자주 볼 수 있습니다. 이러한 상황에서 기존 비즈니스 로직을 유지하면서 쿼리 튜닝을 통해 문제를 해결하기로 결정했습니다.

해결 방법

1단계: 인덱스 검증

첫 번째로 가장 기본적인 튜닝 방법은 인덱스 활용 여부를 검증하는 것입니다.

어떤 인덱스가 존재하는지 파악해야 쿼리에 맞춰 최적화가 되고 있는지 알 수 있기 때문에 인덱스 확인은 중요합니다. 인덱스를 활용하고 있음에도 쿼리 성능에 부하가 걸린다면 쿼리를 분할하거나 방식을 변경하는 조치가 필요하므로, EXPLAIN ANALYZE 명령어를 통해 쿼리의 실행 계획을 파악하는 것이 인덱스 검증의 첫 단계입니다.

EXPLAIN ANALYZE 사용 시나리오

• 쿼리 성능이 느려진 이유를 찾을 때
• 인덱스가 제대로 활용되는지 확인할 때
• JOIN 최적화가 필요한지 판단할 때

EXPLAIN ANALYZE를 통해 쿼리를 확인한 결과, 적절한 인덱스를 활용하지 않고 있었습니다. 테이블의 인덱스를 확인한 결과 적절한 인덱스가 설정되어 있지 않다는 것을 파악했고, 성능 개선을 위한 체크리스트를 작성했습니다.

개선 체크리스트

1. 최적화된 인덱스 추가
2. 비즈니스 로직 확인
3. 쿼리 구조 개선
4. 부하를 일으킬 수 있는 서비스 구조 체크

2단계: 쿼리 구조 분석

해당 쿼리가 위치한 코드를 분석한 결과, TypeORM을 사용하는 백엔드에서 단순 확인 로직이 JOIN절로 구성되어 있었습니다.

문제가 되는 쿼리를 자세히 조사해보니, 처음에는 요청한 게시물을 가져올 때 유저의 신고 데이터를 LEFT JOIN해서 reportedPost.id IS NULL 조건을 거는 부분이 있었습니다. 이 부분이 성능 부하의 주요 원인으로 추측되었습니다.

-- 기존 쿼리 (문제가 되는 부분)
SELECT feedPost.*
FROM feed_posts feedPost
LEFT JOIN reported_feed_posts reportedPost
  ON feedPost.id = reportedPost.post_id
  AND reportedPost.user_id = ?
  AND reportedPost.active = true
WHERE feedPost.channel_id = ?
  AND feedPost.active = true
  AND reportedPost.id IS NULL  -- 이 부분이 성능 이슈 발생
ORDER BY feedPost.created_at DESC

쿼리 튜닝 원칙

쿼리 튜닝에는 다음과 같은 기본 원칙들이 있습니다:

1. 좌변 가공 금지: WHERE절에서 컬럼을 함수로 가공하지 않기
2. 적절한 조인 방식 선택: 단순 확인용이라면 JOIN < IN < EXISTS 순으로 성능 유리
3. NULL 처리: NULL 값에 대한 적절한 처리
4. 조인 순서 최적화: INNER JOIN 시 작은 테이블부터 연산
5. 명시적 Alias 작성: 중복을 방지하고 가독성 향상
6. UNION 활용: 복잡한 WHERE절 대신 UNION 사용 고려
7. VIEW 활용: 복잡한 연산의 경우 VIEW를 통한 단순화

왜 2번 원칙을 적용했는가?

기존 쿼리에서 LEFT JOIN + IS NULL 패턴은 **“신고되지 않은 게시물만 가져오기”**라는 단순한 확인 로직이었습니다. 이런 경우 JOIN보다는 서브쿼리를 사용하는 것이 더 효율적입니다:

• JOIN 방식의 문제점: 모든 게시물에 대해 신고 테이블과 조인 후 NULL 체크
• 서브쿼리 방식의 장점: 신고된 게시물 ID만 먼저 추출 후 제외하는 방식으로 더 직관적이고 빠름

따라서 2번 원칙에 따라 JOIN절을 NOT IN 서브쿼리 방식으로 변경하여 쿼리를 개선하기로 했습니다.

기술적 고려사항

원래는 EXISTS절을 사용하려 했으나, 테스트 환경의 제약으로 NOT IN절을 선택했습니다. 실제 프로덕션에서는 다음과 같은 차이점이 있습니다:

• EXISTS: NULL 값 처리에 안전하고, 대용량 데이터에서 일반적으로 더 빠름
• NOT IN: NULL 값이 있으면 예상치 못한 결과 발생 가능, 하지만 작은 데이터셋에서는 충분히 효율적

제약사항과 트레이드오프

백엔드 팀은 테스트 코드를 중시하며 모든 서비스에 테스트 코드를 작성합니다. 현재 pg-mem을 통해 가볍고 빠른 테스트 구조를 구축하고 있었는데, pg-mem의 한계로 EXISTS절을 해석하지 못하는 문제가 있었습니다.

이로 인해 두 가지 선택지가 있었습니다:

1. 테스트 구조를 변경하고 EXISTS절을 사용하여 최적화
2. 성능상 약간의 손해를 감수하고 NOT IN절로 개선

의사결정 과정

개발에서 중요한 것은 기술적 완벽함과 비즈니스 효율성 사이의 균형입니다. 단순히 요구사항만 구현하는 것이 아니라, 해당 기능의 엣지 케이스와 개발 방향성을 비용 측면에서 효율적으로 판단해야 합니다.

NOT IN절 변경과 인덱스 추가에 비해 테스트 구조 변경은 상당한 공수가 필요하므로, NOT IN절과 인덱스 추가 방식으로 개선하기로 결정했습니다.

구현 과정

목적이 정해지면 개선 과정은 명확합니다:

1. 쿼리 구조 개선
2. 개선된 쿼리에 맞는 인덱스 추가

먼저 쿼리를 개선하고, 개선된 쿼리에 맞춰 인덱스를 추가하는 순서로 진행했습니다. 이를 위해 기존 인덱스 현황을 파악하고, 어떤 방식으로 쿼리를 개선할지 계획을 세웠습니다.

서브쿼리 활용 방식

NOT IN절을 활용하는 방식은 다음과 같습니다:

• 서브쿼리를 통해 필터링할 데이터를 먼저 추출
• 메인 쿼리의 SELECT를 단순화하여 성능 향상

개선 전 쿼리 (JOIN 방식)

// 기존 JOIN 방식 - 성능 이슈 발생
const feedPosts = await this.dataSource
  .getRepository(FeedPost)
  .createQueryBuilder("feedPost")
  .leftJoin(
    "feedPost.reportedPosts",
    "reportedPost",
    "reportedPost.user_id = :userId AND reportedPost.active = :active"
  )
  .where("feedPost.channel_id = :channelId")
  .andWhere("feedPost.active = :active")
  .andWhere("reportedPost.id IS NULL") // 신고되지 않은 게시물만
  .orderBy("feedPost.created_at", "DESC")
  .limit(20)
  .getMany();

개선 후 쿼리 (서브쿼리 방식)

// 개선된 NOT IN 서브쿼리 방식
const reportedPostIdsSubQuery = this.dataSource
  .getRepository(ReportedFeedPost)
  .createQueryBuilder("reportedFeedPost")
  .select("reportedFeedPost.post_id")
  .where(`reportedFeedPost.user_id = :userId`)
  .andWhere("reportedFeedPost.active = :active");

const feedPosts = await this.dataSource
  .getRepository(FeedPost)
  .createQueryBuilder("feedPost")
  .where("feedPost.channel_id = :channelId")
  .andWhere("feedPost.active = :active")
  .andWhere(`feedPost.id NOT IN (${reportedPostIdsSubQuery.getQuery()})`)
  .orderBy("feedPost.created_at", "DESC")
  .limit(20)
  .setParameters({ channelId, userId, active: true })
  .getMany();

참고: NULL 값 처리

// 일반적으로 NOT IN 사용 시 NULL 안전성을 위한 추가 조건이 필요하지만
// 이 경우 post_id가 FeedPost.id를 참조하는 FK이므로 NULL 값이 없어 생략 가능
.andWhere(`feedPost.id NOT IN (${reportedPostIdsSubQuery.getQuery()})`)

// 만약 FK 제약이 없다면 다음과 같이 NULL 처리 필요:
// .andWhere(`feedPost.id NOT IN (${reportedPostIdsSubQuery.getQuery()})
//            OR (${reportedPostIdsSubQuery.getQuery()}) IS NULL`)

인덱스 최적화

개선된 쿼리에 맞춰 다음 인덱스를 추가했습니다:

추가된 인덱스

-- FeedPost 테이블 복합 인덱스
CREATE INDEX CONCURRENTLY idx_feedpost_channel_active_created
ON feed_posts (channel_id, active, created_at DESC);

인덱스 설계 고려사항

• CONCURRENTLY 옵션: 서비스 중단 없이 인덱스 생성
• 컬럼 순서: WHERE절에서 가장 선택적인 컬럼을 앞에 배치
• DESC 정렬: 최신 게시물 조회 패턴에 맞춰 created_at을 내림차순으로 설정

성능 개선 결과

응답 시간 개선

개선 전

개선 후

데이터베이스 부하 개선

실측 성능 개선 결과

쿼리 구조 개선과 인덱스 추가를 통해 실제 측정된 성능 향상은 다음과 같습니다:

• 응답 시간: 평균 6.3초 → 0.4초 (약 94% 개선)
• CPU 사용률: 평균 75% → 5% (약 93% 감소)

이러한 개선을 통해 사용자들이 피드를 훨씬 빠르게 로딩할 수 있게 되었고, 서버 리소스 사용량도 크게 줄어들었습니다. 개선 전후 비교 영상과 RDS 부하 그래프에서 확인할 수 있듯이 상당한 성능 향상을 달성했습니다.

경험을 통해 얻은 교훈

이번 쿼리 튜닝 작업을 통해 몇 가지 중요한 인사이트를 얻었습니다:

1. 성능 모니터링의 중요성: RDS 성능 개선 도우미 같은 도구를 활용한 지속적인 모니터링이 문제를 조기에 발견하는 핵심
2. 현실적 접근의 가치: 기술적 완벽함보다는 현실적이고 실행 가능한 개선이 더 큰 가치를 창출
3. 체계적 문제 해결: 인덱스 검증 → 쿼리 분석 → 구조 개선 → 성능 측정의 단계적 접근이 효과적
4. 제약사항 인정: 테스트 환경의 한계 같은 실무적 제약을 인정하고 최선의 대안 선택

쿼리 튜닝 시 주의사항

인덱스 추가 시 고려할 점

인덱스는 조회 성능을 크게 향상시키지만, 몇 가지 트레이드오프가 있습니다:

• 쓰기 성능 영향: 새로운 데이터가 추가되거나 수정될 때마다 인덱스도 함께 업데이트되어야 하므로 INSERT/UPDATE 성능이 저하될 수 있습니다
• 스토리지 사용량: 복합 인덱스는 추가적인 디스크 공간을 차지하므로 스토리지 비용이 증가합니다
• 유지보수 비용: 인덱스가 많아질수록 관리 포인트가 늘어나고, 성능 모니터링이 복잡해집니다

NOT IN vs EXISTS 선택 기준

이번 프로젝트에서 EXISTS 대신 NOT IN을 선택했지만, 일반적인 선택 기준은 다음과 같습니다:

-- 작은 서브쿼리 결과셋 (< 1000건): NOT IN 사용 가능
-- 큰 서브쿼리 결과셋 (> 1000건): EXISTS 권장
-- NULL 값 가능성: 항상 EXISTS 사용 권장

특히 NOT IN은 서브쿼리 결과에 NULL이 포함되면 예상치 못한 결과를 반환할 수 있으므로 주의가 필요합니다. 다만 이번 경우처럼 FK 제약조건이 있어 NULL 값이 보장되지 않는다면 추가 처리 없이 사용해도 안전합니다.

성능 튜닝 접근 순서

경험상 다음 순서로 접근하는 것이 효과적입니다:

1. 인덱스 최적화: 가장 적은 비용으로 큰 효과를 얻을 수 있는 방법입니다. 기존 쿼리를 거의 수정하지 않고도 성능 향상이 가능합니다
2. 쿼리 구조 개선: 중간 정도의 효과를 기대할 수 있지만, 코드 수정과 테스트가 필요합니다
3. 캐싱 도입: 높은 성능 향상을 기대할 수 있지만, 캐시 무효화 전략 등 복잡성이 증가합니다
4. 하드웨어 업그레이드: 즉시 효과를 볼 수 있지만 비용이 가장 높고, 근본적인 해결책은 아닙니다

마무리하며

개발 과정에서 하나의 API에 다양한 요구사항이 추가되면서 예상치 못한 성능 이슈가 발생할 수 있습니다. 개발자는 자신이 작성한 코드에 대해 지속적으로 검토하고 개선해 나가는 것이 중요합니다.

fromm 사용자들이 더 빠르고 안정적인 서비스를 이용할 수 있도록 지속적인 성능 개선에 노력하겠습니다.

감사합니다!