DB에 로그를 넣었더니 .. -ElasticSearch와 OpenSearch로 검색용 저장소를 분리한 이유

들어가며 — “로그 조회 하나가 왜 이렇게 느릴까?”

처음 로그 수집 기능을 만들었을 때, 저는 아주 자연스러운 선택을 했습니다.

“데이터니까 DB에 넣으면 되겠지.”

• API 요청 로그
• 사용자 행동 로그
• 에러 로그

모두 RDB(MySQL) 에 차곡차곡 쌓았습니다.
초반엔 문제없었습니다. 데이터도 적고, 조회도 단순했으니까요.

하지만 시간이 지나면서 이런 일이 생기기 시작했습니다.

• 특정 키워드가 포함된 로그 검색 → 풀 테이블 스캔
• 날짜 + 조건 검색 → 인덱스가 있어도 느림

“이건 DB 문제가 아니라, 검색 엔진 문제예요.”

이 지점에서 ElasticSearch / OpenSearch 를 도입하게 되었습니다.

---

문제 상황 — DB는 ‘저장’에 강하고, ‘검색’에는 약했다

우리가 겪은 실제 이슈

• 로그 데이터: 하루 수백만 건
• 조회 패턴:
  • 키워드 포함 여부
  • 부분 일치
  • 시간 범위 필터
  • 실시간 집계(count, rate)

DB 기준으로 보면 모두 비효율적인 쿼리였습니다.

 

정확한 값 조회	👍
LIKE / 텍스트 검색	👎
실시간 로그 집계	👎
대용량 append	점점 부담

기획/운영 쪽에서는 이렇게 느꼈습니다.

“로그는 쌓이는데, 막상 사고 나면 찾을 수가 없어요.”

---

원인 분석 — “검색”과 “저장”을 같은 도구로 처리했다

가장 큰 원인은 이거였습니다.

DB를 ‘검색 엔진’처럼 쓰고 있었다

DB는 본질적으로:

• 정합성
• 트랜잭션
• 정확한 조회

에 최적화되어 있습니다.

반면 우리가 필요했던 건:

• 빠른 키워드 검색
• 부분 일치 / 형태소 분석
• 대용량 로그 실시간 집계

이 요구사항에 맞는 도구가 바로
Elasticsearch / OpenSearch 였습니다.

---

ElasticSearch / OpenSearch란?

한 문장으로 정리하면

대용량 데이터를 ‘검색과 분석’에 최적화한 분산 검색 엔진

DB와 가장 큰 차이

 

	DB	ElasticSearch / OpenSearch
목적	저장/정합성	검색/분석
데이터 구조	테이블	인덱스
조회 방식	Row 기반	문서(Document) 기반
텍스트 검색	약함	매우 강함

---

핵심 개념 — 인덱스(Index)를 이해해야 한다

인덱스란?

ElasticSearch/OpenSearch에서 인덱스는 테이블과 비슷하지만 성격이 다릅니다.

• DB 인덱스: 조회 보조 수단
• 검색 엔진 인덱스: 데이터 그 자체

내부적으로는?

검색 엔진은 데이터를 이렇게 저장합니다.

Inverted Index (역색인)

 

"error" → [doc1, doc5, doc20] "timeout" → [doc3, doc5]

즉,

• “이 문서에 어떤 단어가 있나?”  X
• “이 단어가 들어 있는 문서는 뭐지?” O

이 구조 덕분에:

• LIKE 검색이 빠르고
• 부분 일치, 복합 조건 검색이 가능해집니다.

---

검색 vs DB — 언제 어떤 걸 써야 할까

제가 정리한 기준

상황	선택
유저 정보, 결제	DB
정확한 ID 조회	DB
로그, 이벤트, 이력	Elastic/OpenSearch
키워드 검색	Elastic/OpenSearch
실시간 대시보드	Elastic/OpenSearch

둘은 경쟁 관계가 아니라 역할 분리 관계였습니다.

---

실무 적용 — 로그 수집 구조

Before

서비스 -> DB -> 느린조회

After

 

서비스 
├─ DB (정합성 데이터) 
└─ Elastic/OpenSearch (로그/검색)

로그는 append-only 로 검색 엔진에 저장하고,
운영/분석은 여기서 처리하도록 분리했습니다.

---

로그 / 검색 / 대시보드 용도

왜 로그에 잘 맞는가

• 쓰기 위주(append)
• 삭제/수정 거의 없음
• 시간 기반 조회 많음

대시보드 구성

• 에러 발생 추이
• 특정 API 응답 시간
• 상태 코드 분포

이때 많이 함께 쓰는 도구가:

• Kibana (Elastic)
• OpenSearch Dashboards (OpenSearch)

운영팀 반응은 명확했습니다.

“이제 장애 나면 눈으로 바로 보인다.”

---

SIEM / 로그 관제 맥락에서의 Elastic & OpenSearch

SIEM이란?

Security Information and Event Management

• 보안 이벤트 로그 수집
• 이상 징후 탐지
• 침입/공격 패턴 분석

Elastic/OpenSearch는 SIEM에서 이런 역할을 합니다.

 

역할	이유
로그 수집	대용량 처리 가능
검색	침해 패턴 빠른 탐색
집계	시간/유형별 분석
시각화	대시보드 제공

즉,

• 단순 로그 저장소 X
• 운영 + 보안 관제 플랫폼의 핵심 엔진 O

---

ElasticSearch vs OpenSearch — 왜 갈라졌나

배경 요약

• ElasticSearch 라이선스 변경
• AWS 중심으로 OpenSearch 포크

실무 체감 차이

 

	ElasticSearch	OpenSearch
라이선스	상용 기능 많음	Apache 2.0
AWS 연동	제한	매우 좋음
기본 기능	풍부	충분

기능보다는 운영 환경/비용 정책이 선택 기준이었습니다.

---

결과 — 가장 큰 변화는 “운영 대응 속도”

 

	Before	After
장애 분석	수십 분	수 분
로그 검색	쿼리 튜닝	즉시
운영 커뮤니케이션	감	데이터 기반

무엇보다 달라진 점은 이것입니다.

“문제가 생겼을 때, 이제 찾을 수 있다.”

---

배운 점 & 회고

이번 경험에서 얻은 교훈은 명확했습니다.

• DB는 만능이 아니다
• 검색은 전용 엔진이 있다
• 로그는 저장보다 활용이 중요하다

ElasticSearch/OpenSearch는
새로운 기능을 만든 게 아니라,

운영을 ‘설명 가능한 영역’으로 끌어올린 선택이었습니다.

---

마무리 요약

• ElasticSearch / OpenSearch는 검색·분석 특화 엔진
• 인덱스(역색인)가 핵심 개념
• 로그, 검색, 대시보드, SIEM에 특히 적합
• DB와 경쟁하지 말고 역할을 분리하자