1. 문제상황 ** 배경 ** - 대용량 트래픽 처리를 검증하기 위해 **약 97억 건(기존 대비 6.2배)**의 로그를 적재하여 스트레스 테스트를 진행했습니다. 이 과정에서 기존 검색 엔진의 심각한 성능 한계가 드러났습니다. **주요 현상** - **Gateway Timeout (3분):** 대용량 데이터 검색 시 쿼리 응답이 3분을 초과하여 연결이 끊기는 현상 빈번 발생. - **UI Freezing:** 리스트(목록)와 통계(차트)를 동기식으로 호출하는 구조로 인해, 무거운 집계 연산이 끝날 때까지 화면 전체가 멈추는 사용자 경험 저하 또한 발생. 2. 기술적 원인 분석 기존 코드 분석 결과, 인덱싱 효율을 저하시키는 **Antipattern**을 발견했습니다. -1. Full Scan 유발 - 모든 필드에 대해 `keyword*` (Leading Wildcard) 검색 수행. - 숫자형 데이터(Port, SID)까지 문자열로 처리하여 인덱스 탐색 효율 저하. -2. 고비용 집계 연산 - 단순 요약 정보를 위해 4개 필드(`Src/Dst IP`, `Port`)에 대해 동시에 **Cardinality(고유 개수 계산)** 수행. - Cardinality는 메모리(HyperLogLog++)와 CPU를 과도하게 소모하며, 데이터 양에 비례해 부하가 급증함. 3. 해결 전략 전략 1: ES 쿼리 구조 최적화 - "무조건적인 전수 조사"에서 **"타입별 최적화 및 표본 조사"**로 패러다임을 전환했습니다. 전략 2: 쿼리 분리 및 병렬 처리 - **Query Splitting:** 무거운 집계(Aggs, Size: 0)와 가벼운 리스트(Hits, Size: 1000) 쿼리를 물리적으로 분리. - **Parallel Execution:** 독립적인 비동기 호출로 리스트 데이터를 즉시 렌더링(TTFB 단축)하여 체감 속도 개선. 5. 정량적 성과 - 데이터 처리량 기준 약 297%의 성능 향상을 달성했습니다. $성과 의의$ 로그 데이터가 폭발적으로 증가하는 환경에서도 소프트웨어 레벨의 튜닝(Cardinality 제거, Term 쿼리, 병렬 아키텍처)만으로 시스템의 처리 한계를 획기적으로 확장했습니다.

웹 페이지 성능 개선