100만건 로그 지연 처리 문의 - 행사 현장 질문

Ask Question
1

이번 “Kubestronaut와 함께하는 커뮤니티 데이” 행사에 현장 질문으로 주신 내용을 공유합니다.

  • 1주일간 로그가 만일 100만건인 경우 내용을 소폭 줄여서 검색, 응답해야할텐데 매우 오래걸릴것으로 예상됩니다. 실무에서는 이런 상황이 충분히 일어날것 같아서 이에 대한 SOP가 있으셨는지 궁금합니다

전문가 Bro님들의 Insight 공유 부탁드립니다.

2

실제 운영 환경에서 1주일 동안 100만 건 규모의 로그를 직접 다뤄본 경험은 없습니다. 다만 OpenSearch의 구조와 일반적으로 알려져 있는 대규모 로그 처리 방식들을 기준으로 보면, 실무에서는 아래와 같은 접근이 자연스럽게 사용될 가능성이 높다고 예상됩니다. 이 내용은 모두 학습과 이해를 바탕으로 한 가정이라는 점을 전제로 정리드립니다.

우선 100만 건 자체는 OpenSearch 관점에서 과도한 양은 아니지만, 조회 방식에 따라 응답 속도 차이가 매우 크게 벌어진다는 점이 중요합니다. 특히 전체 로그를 그대로 모두 가져오는 쿼리는 시간이 오래 걸릴 수 있고, 실무에서는 거의 사용되지 않는 형태라고 알려져 있습니다. 대신 아래와 같은 단계적 절차(SOP 형태)가 많이 활용될 가능성이 있습니다.

첫째, 요약(Aggregation) 기반 탐색을 먼저 수행하는 단계입니다.
로그 전체의 내용보다는 “어디에서 이상이 발생했는가”를 빠르게 찾는 것이 목적이기 때문에, 다음과 같은 집계 쿼리를 먼저 던지는 방식이 일반적입니다.

  • count: 전체 로그 수

  • terms: 서비스/테넌트별 발생량 분포

  • date_histogram: 시간대별 발생량 변화

예를 들어, 7일 동안 100만 건이 있다면, “어제 밤 10시 로그만 갑자기 5배 증가했다” 같은 패턴을 몇 초 안에 파악할 수 있습니다. 이 과정은 반환되는 데이터가 매우 적기 때문에 대용량에서도 안정적으로 동작할 가능성이 높습니다. 흔히 말하는 **‘전체를 보기 전에 지도부터 그려 보는 단계’**라고 생각하면 이해가 쉽습니다.

둘째, 필드 기반으로 강력한 필터링을 먼저 적용하는 방식입니다.
예를 들어 다음과 같은 조건들이 있을 수 있습니다.

  • service: order-service

  • log_level: ERROR

  • message: “timeout”

필터 조건을 좁혀 들어가면 OpenSearch가 탐색해야 할 실제 문서 수가 줄어들기 때문에 조회가 속도 면에서 훨씬 유리해집니다. 이 방식은 실무 SOP에서도 거의 필수 단계로 작동할 가능성이 높습니다.

셋째, Scroll 또는 Search After를 이용한 점진적 페이지 조회 방식입니다.
이를 단순하게 표현하면 “검색 결과를 한꺼번에 가져오는 대신 여러 번 잘라서 스트리밍하듯 받는 방식”입니다.

예를 들어:

  • 한 번에 100만 건을 가져오는 대신

  • 1,000건씩 가져오고

  • 이후 나머지를 Search After 키 값을 이용해 이어서 받는 구조

API 서버나 UI에서도 부담이 적어 실무에서 많이 쓰일 가능성이 있습니다.

넷째, 샘플링(sampling) 기반 분석입니다.
전체 데이터 중 극히 일부(예: 1%)만 먼저 추출하여 패턴을 보고,
그 정보를 기반으로 실제 문제 구간을 좁혀 들어가는 방식입니다.
예를 들어, 100만 건 중 1만 건만 먼저 조회해서

  • 오류 비율이 어느 정도인지

  • 특정 서비스에서 집중되는지

  • 시간대별 이상 징후가 있는지

를 파악한 뒤, 문제 지점만 다시 정확히 조회하면 전체 성능 부담을 크게 줄일 수 있습니다. 대용량 로그를 즉시 탐색해야 하는 상황에서 실무적으로 자주 쓰인다고 알려져 있습니다.

마지막으로, 인덱싱 전략 또는 ILM(수명주기 정책)도 성능에 큰 영향을 미칩니다.
특히 “하루 단위 인덱스 분리”와 같은 구조는 조회 성능 개선에 매우 효과적인 방식입니다.

예를 들어:

  • logs-2025-11-27

  • logs-2025-11-28

  • logs-2025-11-29

이런 형태로 분리되어 있으면, 특정 날짜 범위만 빠르게 검색할 수 있기 때문에
“7일 전체를 한 번에 검색하는 방식”보다 훨씬 빠르게 결과를 얻을 수 있습니다.
여러 로그 시스템에서도 공통적으로 활용되는 최적화 전략입니다.

종합적으로 보면, 실무에서는 **“100만 건 전체를 그대로 읽어오는 방식”보다
“필터링 → 요약(Aggregation) → 필요한 구간만 상세 조회”**라는 흐름이
표준 절차(SOP)에 가깝게 운용될 가능성이 큽니다.

제가 직접 운영해본 경험이 있는 것은 아니지만,
OpenSearch의 내부 구조와 일반적인 로그 처리 관행을 기반으로 보면
이 방식이 가장 합리적이고 실무와 가까운 접근이라고 판단됩니다.