1. 전체 구조 개요

LogLens의 로그 파이프라인은 고객 서버(로그 생성·수집) 와 AI 분석 서버(로그 처리·정규화·저장) 를 분리한 구조로 설계했습니다.

1.1 구조 설명

고객 서버에서는 LogLens 라이브러리와 Fluent Bit, 그리고 제공되는 설정 파일들을 적용하면
애플리케이션·데이터베이스·인프라 로그가 자동으로 수집됩니다.

Fluent Bit은 이 로그들을 실시간으로 파싱·정규화한 뒤 Kafka로 전송하며,
고객 서버에서는 추가적인 운영 부담 없이 최소한의 설정만으로 로그 수집 환경을 구축할 수 있습니다.

전송된 로그는 AI 분석 서버에서 Logstash를 통해 한 번 더 정제되고,
OpenSearch에 저장되어 검색·조회·집계·AI 분석 등에 활용됩니다.
이를 통해 고객 서버의 부하를 최소화하면서도, 대량의 로그를 안정적으로 처리할 수 있는 구조를 제공합니다.

1.2 데이터 흐름 요약

1단계: 로그 생성 (고객 서버)

Application → 파일 로그 생성 (/logs/be/*.log, /logs/fe/*.log, /logs/infra/mysql/*.log)

2단계: 로그 수집 및 전송 (고객 서버)

Fluent Bit → 파일 읽기 → 파싱 → 정규화 → Kafka 전송 (ai.loglens.store:9092)

3단계: 로그 처리 (AI 분석 서버)

Kafka → Logstash → 추가 정규화 → OpenSearch 인덱싱

4단계: 분석 및 조회

OpenSearch ← FastAPI ← LogLens Web API ← React Dashboard

2. 고객 서버 영역

3. AI 서버 영역

4. 로그 처리 흐름

5. 정리 및 향후 계획

5.1 아키텍처 핵심 요약

LogLens 로그 파이프라인의 핵심 설계 원칙과 달성한 목표를 정리합니다.

5.1.1 설계 목표 달성

고객 서버 관점

Zero-Code-Change: 라이브러리 추가만으로 로그 수집
경량 운영: Fluent Bit (CPU 0.5코어, 메모리 512MB)
민감 정보 보호: 어노테이션 기반 자동 마스킹
로그 소유권 보장: 파일 기반 수집으로 원본 로그 보관

AI 서버 관점

확장 가능한 구조: Kafka, Logstash, OpenSearch 독립 확장
안정성 확보: 7일 버퍼링, 장애 시 자동 복구
AI 분석 인프라: KNN Vector + FastAPI 기반

5.2 현재 한계 및 개선 방향

현재 구현의 한계점과 향후 개선 계획을 정리합니다.

5.2.1 성능 최적화

현재 상태

단일 인스턴스 운영 (Kafka 1대, Logstash 1대, OpenSearch 1대)
처리량 병목: Logstash (Worker 4개)

개선 계획

Kafka: 1대 → 3대 클러스터 (파티션 증설)
Logstash: 1대 → 3대 (Worker 총 12개)
OpenSearch: 1대 → 5대 클러스터 (샤드 분산)

예상 효과: 처리량 3~5배 증가, 고가용성 확보

5.2.2 모니터링 강화