[D2] Elasticsearch 기반 로그 모니터링 시스템의 한계와 Apache Iceberg 요약 및 배경지식 정리

Naver D2 "NELO Alaska: 대용량 로그 데이터 저장을 위한 Apache Iceberg 도입기" 요약 및 배경 지식들을 정리해 두었습니다.

자세한 내용을 링크 글을 참고해 주세요.

 

 

Kafka와 Elasticsearch

로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용된다.

[ 클라이언트 ] 
    │
    ▼
[ Kafka (로그 데이터 수집) ] → 로그 데이터를 빠르게 수집하고 Elasticsearch로 전송
    │
    ▼
[ Elasticsearch ]
    │
    ├── [ Hot 계층 (SSD) ] → 최신 데이터 3일간 저장
    │
    ▼
[ Warm 계층 (HDD) ] → 최대 90일까지 저장

클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후 Elasticsearch에 저장된다.

 

 

Kafka

• 분산 메시지 큐(Messafe Queue) 또는 이벤트 스트리밍 플랫폼
• 대용량 데이터를 빠르게 수집하고 처리하는 역할을 한다.
• 주요 특징
  • Publisher-Subscriber 모델
    • 데이터를 보내는 Producer(생산자) 와 데이터를 소비하는 Consumer(소비자) 구조
    • Producer가 데이터를 특정 Topic(토픽)에 전송하면, Consumer가 해당 토픽을 구독하여 데이터를 가져감
  • 고성능 & 대용량 처리
    • 로그 데이터, 트랜잭션 데이터, 실시간 이벤트 데이터 처리에 적합
    • 초당 수백만 개의 메시지를 처리할 수 있음
  • 내구성과 장애 허용성(Fault-Tolerance)
    • 브로커(Broker) 여러 개로 구성하여 데이터를 복제(replication) 함으로써 장애에 강함
  • 분산 아키텍처
    • 데이터가 여러 파티션(Partition) 으로 나뉘어 저장되므로 확장성이 뛰어남
• Kafka가 하는 역할
  • 클라이언트(앱, 서버) → Kafka에 로그 데이터 저장 → 이후 Elasticsearch로 전달

 

Hot/Warm 계층

• Hot/Warm 계층(Hierarchy Storage, Tiered Storage) 개념은 Elasticsearch(ELK 스택)에서 데이터 저장 전략을 설명하는 공식 용어로 사용된다.

 

Hot 계층(Hot Tier)

• 빠른 검색과 실시간 분석이 필요한 데이터를 저장하는 계층
• SSD를 사용하여 빠른 읽기/쓰기 성능을 제공
• 주로 최근 3일 이내의 최신 데이터가 저장됨
• 검색이 빈번하게 발생하는 데이터
• Hot 계층의 역할
  • 최신 로그 데이터 저장 → 빠르게 검색 → 일정 기간 후 Warm 계층으로 이동

 

Warm 계층 (Warm Tier)

• 검색이 자주 일어나지 않는 오래된 데이터를 저장하는 계층
• 상대적으로 느린 HDD를 사용하여 비용 절감
• 최대 90일까지 데이터 저장 가능
• Warm 계층의 역할
  • Hot 계층에서 3일 지난 데이터 이동 → 저장 공간 절약 & 비용 절감 → 필요할 때만 검색

 

---

 

비효율적인 Elasticsearch 사용

서비스의 법적 요구 사항 등의 이유로 예외적으로 1년 이상 장기간 로그 데이터를 저장하게 되다 보니 Warm 계층에 저장된 데이터의 크기가 급증하게 되었다.

사용자들의 검색 요청 로그를 분석한 결과 95% 쿼리가 당일에 발생한 데이터에 대한 것이었고, 99%의 쿼리가 일주일 이내의 데이터를 위한 것이었다.

Elasticsearch는 일반적으로 데이터 저장과 쿼리 계산을 위한 컴퓨팅을 같은 노드에서 담당하고 있기 때문에 이렇게 거의 검색되지 않는 데이터를 저장하는 것은 효율적인 일이 아니다. 

 

 

문제 해결

이러한 문제를 해결하려면 Elasticsearch에는 검색이 자주 일어나는 단기간의 데이터만 저장하고, 장기간 데이터를 저장할 새로운 스토리지가 필요하다는 판단이 들었다.

Elasticsearch를 대체하는 신규 스토리지에서는 데이터 저장을 위한 스토리지와 검색을 위한 컴퓨팅을 분리한다는 아이디어를 기본으로 설계를 시작했다.

Iceberg를 이용해 로그 데이터 저장을 위한 새로운 타입의 스토리지를 구현한 컴포넌트인 Alaska를 개발해 적용했다.

 

---

Apache Iceberg

• 대규모 데이터 레이크에서 테이블 형식으로 데이터를 관리하는 오픈소스 테이블 포맷
  • 데이터 레이크(Data Lake): 정형(structured), 반정형(semi-structured), 비정형(unstructured) 데이터를 원본 그대로 저장하는 대규모 저장소를 의미
  • 쉽게 말하면, 기존 db는 정형화된 테이블 구조에 맞춰 데이터를 저장해야 하지만, 데이터 레이크는 모든 형태의 데이터를 가공하지 않고 원본 그대로 저장할 수 있는 저장소이다.
• 특징
  • ACID 트랜잭셔 지원
    • Iceberg는 스냅샷을 기반으로 트랜잭션을 지원하여 데이터 정합성 유지.
  • Schema Evolution
    • 테이블의 스키마를 중단 없이 변경 가능.
  • Hidden partitioning
    • 자동 파티셔닝을 통해 사용자가 신경 쓰지 않아도 최적의 데이터 쿼리 성능을 제공함.

 

---

신규 로그 모니터링 시스템의 구조

• Iceberg를 기반으로 개발한 새로운 로그 모니터링 시스템은 기존 Elasticsearch 기반의 로그 모니터링 시스템을 대체하는 것이 아니다.
• Elasticsearch에는 실시간 모니터링이 필요한 짧은 기간의 로그를 저장하고, 장기간 보관이 필요한 데이터는 새로운 스토리지를 활성화해 저장하도록 설계했다.
• 기존 로그 모니터링 시스템에서는 Kafka에 적재된 로그 데이터를 Elasticsearch에 인덱싱하는 방식을 사용했었다. 신규 로그 모니터링 시스템도 동일한 Kafka 토픽으로부터 데이터를 읽어 Iceberg 테이블 포맷으로 저장한다.
  • 실시간 검색/모니터링이 필요하지 않은 데이터는 Elasticsearch에 저장하지 않고 직접 Iceberg로 저장.

 

데이터 프로세싱

• 신규 로그 모니터링 시스템은 데이터 프로세싱을 위해서 Kappa Architecture를 따르고 있다.
  • 즉, 실시간으로 저장되고 있는 로그 데이터 테이블에 사용자가 접근해 데이터를 조회할 수 있는 구조이다.
• Iceberg의 오픈 테이블 포맷은 ACID 트랙잭션을 지원하기 때문에 실시간으로 읽고 쓰기 가능.
• 이러한 구조로 짧은 지연 시간 안에 데이터 조회가 가능해짐.

 

 

Kappa Architecture vs Lambda Architecture

전통적인 Lambda Architecture는 배치 처리(batch)와 스트림 처리(stream)를 동시에 사용하는 구조입니다.
하지만 Kappa Architecture는 배치 처리를 제거하고 스트림 처리만 사용하는 방식입니다.

비교 항목Lambda ArchitectureKappa Architecture

데이터 처리 방식	배치 + 스트림 병행	스트림 처리만 사용
데이터 저장소	배치용(보통 Hadoop) + 실시간용	단일 스트림 저장소
유지보수	복잡함 (이중 코드 필요)	단순함 (하나의 코드)
데이터 정합성	배치와 스트림 간 동기화 필요	실시간 데이터로 정합성 유지

 

 

 

* 데이터 적재, 데이터 최적화, Iceberg REST 카탈로그와 데이터 연동, 데이터 쿼리, 적용 결과에 대한 내용은 실제 해당 글을 참고해 주세요.