OpenSearch 성능을 10배 끌어올리는 설계 전략: 인덱스, 샤딩, 쿼리 최적화까지 실무 가이드

OpenSearch는 강력한 검색 엔진이지만,
👉 설계를 잘못하면 “빠른 DB”가 아니라 “느린 로그 저장소”가 된다.

실무에서 자주 발생하는 문제:

• 검색 속도 지연
• 샤드 과다로 인한 성능 저하
• 메모리 부족
• 클러스터 불안정

이 문제의 대부분은
👉 인덱스 구조, 샤딩 전략, 쿼리 설계에서 발생한다.

---

📌 OpenSearch 성능을 결정하는 3가지 핵심

---

1. 인덱스 설계 (Index Design)

OpenSearch는 DB가 아니라
👉 검색을 위한 데이터 구조 (Inverted Index) 기반이다.

❌ 잘못된 설계

모든 데이터를 하나의 index에 저장

 

문제:

• mapping 충돌
• 검색 성능 저하
• 관리 어려움

---

✅ 권장 설계

logs-2026-03
products
users
orders

 

👉 기준:

• 도메인별 분리
• 시간 기반 분리 (로그)
• read/write 패턴 기준

---

핵심 포인트

• index는 테이블이 아니라 검색 전략 단위
• mapping은 초기에 확정 (동적 mapping 최소화)

---

2. 샤딩 전략 (Sharding Strategy)

샤드는 성능과 직결된다.

❌ 잘못된 설계

shard = 많을수록 좋다

 

문제:

• 메모리 과다 사용
• GC 증가
• cluster overhead 증가

---

✅ 권장 설계

• shard 크기: 20GB ~ 50GB
• shard 수: 최소화
• replica: 장애 대비

primary shard: 3
replica: 1

 

---

핵심 포인트

👉 샤드는 “병렬 처리 단위”이지 “많을수록 좋은 것”이 아니다

---

3. 쿼리 최적화 (Query Optimization)

검색 성능의 50%는 쿼리에서 결정된다.

---

❌ 잘못된 쿼리

 

{
"query": {
"match": {
"content": "search keyword"
}
}
}

 

문제:

• scoring 계산 비용 큼
• 불필요한 full-text 검색

---

✅ 권장 쿼리

 

{
"query": {
"bool": {
"filter": [
{ "term": { "status": "ACTIVE" }},
{ "range": { "createdAt": { "gte": "now-7d" }}}
]
}
}
}

 

👉 장점:

• filter는 캐시됨
• scoring 없음 → 빠름

---

핵심 포인트

• filter 우선 사용
• match 최소화
• keyword 필드 적극 활용

---

📌 성능을 좌우하는 추가 전략

---

4. Mapping 설계

❌ 잘못된 설계

모든 필드 text 타입

 

---

✅ 권장

name: text + keyword
status: keyword
price: long

 

👉 이유:

• keyword → exact match
• text → full-text 검색

---

5. Bulk Indexing 사용

단건 insert 반복은 성능 저하 원인

POST /_bulk

 

👉 효과:

• 네트워크 비용 감소
• indexing 속도 향상

---

6. Refresh Interval 조정

기본값:

1초

 

문제:

• write 성능 저하

👉 해결

refresh_interval: 30s

 

👉 효과:

• indexing 성능 향상

---

7. Doc Value / Fielddata 관리

문제:

• 메모리 폭증

👉 해결:

• text field에 fielddata 사용 금지
• keyword 기반 aggregation

---

8. Hot-Warm 아키텍처

Hot → 최근 데이터
Warm → 오래된 데이터

 

👉 효과:

• 비용 절감
• 성능 유지

---

📌 실무 아키텍처 예시

[ Client ]
↓
[ API Gateway ]
↓
[ Service ]
↓
┌──────────────┐
│ OpenSearch │
└──────────────┘

 

👉 흐름:

• DB → OpenSearch로 데이터 색인
• 검색은 OpenSearch만 사용

---

📌 절대 하면 안 되는 설계

---

❌ 1. DB처럼 사용

• 트랜잭션 기대
• JOIN 기대

👉 OpenSearch는 검색 엔진이다

---

❌ 2. 모든 데이터를 다 넣기

• 필요 없는 필드까지 색인
• index size 증가

---

❌ 3. 샤드 과다

• 성능 오히려 저하

---

❌ 4. 실시간 집착

• refresh 과도하게 짧게

---

📌 실무 체크리스트

---

• index 도메인별 분리
• shard 크기 20~50GB 유지
• filter 기반 쿼리 사용
• keyword/text 구분
• bulk indexing 적용
• refresh interval 조정
• 불필요 필드 제거

---

📌 결론

OpenSearch 성능은
👉 하드웨어가 아니라 설계에서 결정된다

잘 설계하면:

• 초고속 검색
• 안정적인 클러스터
• 확장성 확보

잘못 설계하면:

• 느린 응답
• 장애 발생
• 운영 지옥

---

📌 한 줄 정리

👉 “OpenSearch는 DB가 아니라 검색 엔진이다 — 설계가 성능을 결정한다”