핵심 성과 요약

<aside>

• 평균 처리 시간: 194.6s → 15.6s (약 92% 단축)

  

</aside>

<aside>

• 초당 처리량(TPS): 5.1 → 64.4 (약 12.5배 향상)

  

</aside>

1. 문제 상황 및 분석

병목 현상 발생

실시간 대테러 관제 시스템 운영 중, 데이터가 22만 건 이상 누적된 ****환경에서 특정 인물의 최신 동선을 조회하는 API의 응답 속도가 평균 194초 소요되는 성능 저하가 발생했습니다.

원인 분석

병목이 발생하는 쿼리의 실행 계획을 분석한 결과, 인덱스가 부재하여 비효율적인 탐색이 이루어지고 있음을 확인했습니다.

• 실행 계획 결과: type: ALL (Full Table Scan)
• 스캔 행 수: 약 220,000 Rows (전체 데이터 스캔)
• 분석: 적절한 인덱스가 없어 디스크 I/O가 과도하게 발생하고 있었습니다.

2. 인덱스 도입 전략

데이터베이스 인덱스는 조회 성능을 향상시켜주는 도구이지만, INSERT, UPDATE, DELETE와 같은 데이터 변경 작업이 발생할 때마다 인덱스 트리를 재정렬해야 하는 오버헤드가 발생합니다.

기술 서적 **'Real MySQL'**에서는, 테이블에 레코드를 1개 추가하는 비용을 1이라고 할 때, 인덱스에 키를 추가하는 비용은 약 1.5 정도라고 말했습니다. 즉, 인덱스가 하나 늘어날 때마다 쓰기 작업의 비용은 가중되기에, 무분별한 생성보다는 명확한 기준에 따른 전략적 접근이 필요합니다.

따라서 저는 이번 프로젝트에서 다음과 같은 4가지 핵심 기준을 수립하여 인덱스 생성 여부를 결정했습니다.

인덱스 생성 여부를 결정하는 4가지 기준

1. 카디널리티
   • 데이터의 중복도가 낮고 고유한 값이 많을수록 인덱스의 효율이 높아집니다.
   • 성별(남/여)과 같이 중복도가 높은 컬럼보다는 주민번호나 ID처럼 기수성이 높은 컬럼을 우선순위에 두었습니다.
2. 선택도
   • 일반적으로 쿼리의 결과가 전체 데이터의 5~10% 미만일 때 인덱스를 타는 것이 효율적입니다.
     • 예를 들어 데이터가 100만 건인데 조회 결과가 50만 건이라면, 인덱스를 거쳐 데이터 블록을 찾아 랜덤 I/O를 하는 비용보다 테이블 전체를 읽는 풀 스캔 비용이 더 저렴할 수 있음을 고려했습니다.