[Elasticsearch] AWS t3.micro에서 Elasticsearch 검색 쿼리 최적화하기

비용 절감을 위해 AWS 프리티어 범위 내인 t3.micro(2 vCPU, 1GiB RAM) 인스턴스를 엘라스틱서치 서버로 채택했다. 이는 엘라스틱서치를 운영하기에 매우 타이트한 조건이다.

OS와 Docker의 기본 점유율을 제외하면 엘라스틱서치의 핵심인 JVM 힙 메모리에 할당할 수 있는 자원은 약 500MB 내외에 불과하다. 한글 형태소 분석기인 Nori나 N-gram 같은 토크나이저를 추가하면 검색 성능을 높여주지만 인덱싱 시점에 메모리 점유율이 상승하여 OOM(Out Of Memory) 발생 위험이 커질 수 있다. 따라서 인덱스 구조는 가볍게 유지하되 쿼리 수준에서 리소스 부하를 최소화하는 전략을 선택했다.

 

1. 테스트 환경 및 목적

이번 실험은 제한된 시스템 자원 내에서 서비스 로직이 포함된 실제 API 호출 시 검색 방식에 따른 CPU 점유율 변화를 측정하는 것을 목표로 삼았다.

• 환경: AWS t3.micro (1GB RAM) / Docker 기반 Elasticsearch
• 목표: 서비스 로직(정렬, 필터 포함)이 포함된 실제 API 호출 시 검색 방식에 따른 CPU 점유율 측정
• 검증 방법: 매 요청 전 캐시 초기화(_cache/clear) 후 20회 연속 호출 
• 데이터 규모 : 500건
• 비교 방식: Wildcard vs Match Phrase Prefix (토크나이저 없이 포함 검색 구현)

 

2. 검색 방식별 CPU 점유율 측정 결과

회차	Wildcard (origin)	Match Phrase Prefix (최적화)	비고
1회	1.74%	1.43%
2회	2.10%	1.89%
3회	1.88%	4.32%
4회	1.34%	1.59%
5회	1.95%	1.15%
6회	7.29%	2.00%
7회	2.09%	1.68%
8회	33.02% (Peak)	1.43%	Wildcard 테스트 중 GC 발생
9회	1.90%	1.65%
10회	1.20%	1.61%
11회	1.31%	1.70%
12회	5.21%	1.94%
13회	1.30%	1.45%
14회	1.77%	1.57%
15회	1.95%	1.25%
16회	1.97%	37.98% (Peak)	Prefix 테스트 중 GC 발생
17회	2.12%	2.00%
18회	2.61%	1.53%
19회	1.87%	1.62%
20회	2.09%	1.18%

 

 

3. 최종 성능 비교

지표 항목	Wildcard (Full Scan)	Match Phrase Prefix (Index Scan)	성과
전체 평균 점유율	3.84%	3.55%	-
순수 쿼리 평균 (Peak 제외)	2.30%	1.74%	약 24.5% 개선
최고 피크 점유율 (Peak)	33.02%	37.98%	노이즈 확인

 

4. 고찰

• 시스템 노이즈
  • 8회차와 16회차에서 발생한 30% 이상의 스파이크는 (1) 8회 단위의 명확한 주기성을 보이며 (2) 쿼리 복잡도의 변화가 없는 상태에서 발생했다는 점에서 쿼리 연산 부하가 아닌 서버 내부의 JVM 가비지 컬렉션 부하가 검색 시점과 겹친 현상으로 예상된다.
• 성능 비교
  • 노이즈를 제외한 순수 쿼리 실행 비용에서 Match Phrase Prefix 방식이 일관되게 낮은 수치(1.74%)를 기록하며 와일드카드 대비 리소스 효율이 높음을 알 수 있었다.
• 확장성
  
  • 현재는 데이터 규모가 작아 0.5%p 내외의 근소한 차이를 보이지만 데이터가 급증할수록 시간복잡도가 O(N)인 Wildcard보다 O(log N)인 Prefix 방식의 효율성이 극대화 될 것으로 생각된다.