1. 로그를 저장할 때 관계형 DB만으로 충분할까?
로그는 하루에도 매우 많이 쌓일 수 있는 텍스트 중심 데이터다.
예를 들어 아래 같은 특징이 있다.
- 양이 많다.
- 문자열 검색이 많다.
- 시간 범위 조건이 자주 붙는다.
- 특정 단어, trace id, 에러 메시지를 빨리 찾아야 한다.
이런 이유 때문에 로그 저장과 검색을 MySQL 같은 관계형 DB만으로 처리하는 것은 가능하더라도, 검색/분석 용도에는 불리할 수 있다.
중요한 점은 “관계형 DB를 절대 쓰면 안 된다”가 아니라는 점이다.
정확한 표현은 아래에 가깝다.
관계형 DB도 로그 저장 자체는 가능하다.
하지만 대규모 로그의 검색과 분석에는 Elasticsearch 같은 검색 엔진이 더 적합한 경우가 많다.
Elastic 공식 문서는 Elasticsearch를 distributed search and analytics engine이라고 설명한다. [1]
즉, Elasticsearch는 태생부터 “빠르게 찾고 분석하는 것”에 초점이 있는 도구다.
2. 로그에서 자주 하는 작업은 무엇일까?
로그를 쌓아두는 목적은 단순 저장이 아니라, 나중에 찾고 분석하기 위해서다.
예를 들어 실무에서는 아래 같은 질문을 자주 던진다.
- 오전 9시 이후
ERROR로그만 보고 싶다. - 특정 사용자 ID가 들어간 요청을 찾고 싶다.
NullPointerException이 포함된 로그만 보고 싶다.- 특정 trace id로 전체 요청 흐름을 따라가고 싶다.
이런 작업은 보통 “행 하나를 정확히 PK로 조회”하는 관계형 DB의 전형적인 강점과는 조금 다르다. 오히려 텍스트 기반 검색, 필터링, 집계, 탐색이 더 중요하다.
즉, 로그는 아래 성격이 강하다.
정형 트랜잭션 데이터보다는
검색과 분석 중심의 이벤트 데이터
3. 왜 Elasticsearch가 로그에 잘 맞을까?
Elasticsearch는 검색과 분석을 위해 설계된 엔진이다.
Elastic 공식 사이트는 Elasticsearch가 logs, metrics, security data 같은 다양한 데이터를 검색하고 분석하는 데 쓰인다고 설명한다. [2]
로그 관점에서 보면 Elasticsearch가 잘 맞는 이유는 아래와 같다.
- 텍스트 검색이 빠르다.
- 대량 데이터에서 필터링이 쉽다.
- 집계(aggregation)와 분석이 강하다.
- Kibana 같은 시각화 도구와 바로 연결된다.
즉, “로그를 넣고 나중에 빨리 찾아야 하는 상황”에 적합하다.
4. Elasticsearch는 왜 텍스트 검색이 빠를까?
핵심 개념은 Inverted Index(역인덱스)다.
Elastic 공식 문서는 full-text search가 동작할 때, Elasticsearch가 토큰으로 분석한 뒤 inverted index를 만든다고 설명한다. 그리고 inverted index는 각 token이 어떤 document에 들어 있는지 매핑하는 자료구조라고 설명한다. [3]
즉, 아래처럼 이해하면 된다.
문서 1: error happened in payment
문서 2: waiting api success
문서 3: payment timeout error
이걸 거꾸로 보면,
error -> 문서 1, 문서 3
payment -> 문서 1, 문서 3
waiting -> 문서 2
처럼 단어 기준으로 문서를 찾을 수 있게 된다.
이 구조 덕분에 특정 단어가 들어간 로그를 빠르게 찾을 수 있다.
즉, 로그 검색 관점에서는 아래 차이가 생긴다.
- 그냥 긴 문자열을 처음부터 끝까지 매번 훑는 방식보다
- 단어 기준으로 미리 정리된 색인을 보고 찾는 방식이
- 검색에 더 유리하다
5. “관계형 DB는 첫 페이지부터 끝까지 다 뒤진다”는 표현은 맞을까?
완전히 정확한 표현은 아니다.
관계형 DB도 인덱스가 있고, 일부 full-text 검색 기능도 제공할 수 있다. 즉, 무조건 모든 데이터를 처음부터 끝까지 순차 탐색한다고 단정하면 과하다.
다만 로그처럼 아래 조건이 겹치면 검색 엔진이 더 자연스럽다.
- 텍스트 검색이 많다.
- 부분 단어/토큰 기반 탐색이 많다.
- 대량 문서에서 빠른 필터링이 필요하다.
- 집계와 시각화가 자주 필요하다.
즉, 비교를 더 정확히 쓰면 아래가 맞다.
관계형 DB는 트랜잭션 처리와 정형 데이터 관리에 강하고,
Elasticsearch는 검색과 분석 중심의 로그 데이터 처리에 더 적합한 경우가 많다.
6. “1억 건도 0.1초”처럼 말해도 될까?
그렇게 고정 수치로 말하면 안 된다.
검색 속도는 아래 조건에 따라 크게 달라진다.
- 데이터 구조
- 매핑 방식
- 샤드 수
- 쿼리 종류
- 하드웨어 자원
- 캐시 상태
Elastic 공식 문서도 Elasticsearch를 search and analytics engine이라고 설명하지만, 특정 건수에서 항상 몇 초 안에 끝난다고 고정 보장하지는 않는다. [1][2]
따라서 성능 설명은 아래처럼 쓰는 편이 정확하다.
Elasticsearch는 inverted index와 분산 검색 구조를 바탕으로
대규모 로그에서도 빠른 검색과 분석에 적합하다.
즉, “엄청 빠르다”는 방향은 맞지만, 1억 건이면 0.1초 같은 숫자는 근거 없이 일반화하면 안 된다.
7. 로그에서 Elasticsearch를 쓰면 무엇이 좋아질까?
로그 수집 관점에서 Elasticsearch를 쓰면 아래 작업이 쉬워진다.
- 특정 단어 포함 로그 검색
- 시간 범위 필터링
- 로그 레벨별 집계
- 서비스별 에러 비율 확인
- Kibana를 통한 시각화
Elastic의 로그 탐색 문서도 Elasticsearch에 적재된 로그를 Discover에서 검색, 필터링, 분석할 수 있다고 설명한다. [4]
즉, Elasticsearch는 단순 저장소가 아니라 “로그를 탐색 가능한 데이터”로 다루게 해주는 역할을 한다.
8. 그래서 우리 목적에는 왜 적절할까?
이번 로그 수집 맥락에서 중요한 것은 Elasticsearch를 깊게 배우는 것이 아니라, 왜 이 도구를 로그 저장소로 쓰는지가 이해되는 것이다.
핵심은 아래와 같다.
- 로그는 텍스트 중심 데이터다.
- 로그는 검색과 분석이 중요하다.
- Elasticsearch는 검색과 분석 엔진이다.
- Kibana와 붙이면 시각화까지 가능하다.
즉, 로그 수집과 시각화를 배우는 입문 단계에서는 Elasticsearch를 “로그를 저장하고 찾고 분석하기 좋은 검색 엔진”으로 이해하면 충분하다.
정리
로그 저장에 관계형 DB를 사용할 수는 있지만, 대규모 로그의 검색과 분석에는 Elasticsearch가 더 적합한 경우가 많다.
핵심만 정리하면 아래와 같다.
- 로그는 양이 많고 텍스트 검색이 중요하다.
- Elasticsearch는 distributed search and analytics engine이다.
- Elasticsearch는 inverted index를 활용해 텍스트 검색에 유리하다.
- 로그 분석에서는 저장보다 검색, 필터링, 집계, 시각화가 더 중요하다.
- 그래서 Elasticsearch는 로그 수집 시스템의 중심 저장소로 자주 사용된다.
즉, Elasticsearch를 로그에 쓰는 이유는 “데이터베이스라서”가 아니라, “검색과 분석 엔진이라서”라고 이해하면 된다.
출처
- Elastic, “Elasticsearch”, https://www.elastic.co/elasticsearch
- Elastic Docs, “The Elastic Stack”, https://www.elastic.co/docs/get-started/the-stack
- Elastic Docs, “How full-text search works”, https://www.elastic.co/docs/solutions/search/full-text/how-full-text-works
- Elastic Docs, “Explore logs in Discover”, https://www.elastic.co/docs/solutions/observability/logs/discover-logs