![[팀네이버 컨퍼런스 DAN25] NELO Alaska: 장기 로그 보존을 위한 Iceberg 도입과 운영 - 20x 비용 절감과 확장성 향상](https://i.ytimg.com/vi/AD34anaXKEI/maxresdefault.jpg)
[팀네이버 컨퍼런스 DAN25] NELO Alaska: 장기 로그 보존을 위한 Iceberg 도입과 운영 - 20x 비용 절감과 확장성 향상
DAN 2025 네이버 · YouTube
AI 핵심 요약
NELO는 로그 트래픽 증가로 Elasticsearch 클러스터의 비용과 확장성 한계에 부딪혔지만, 실제 쿼리 대부분이 최근 데이터에 집중되는 반면 장기 보존은 보안·규제상 필요하다는 점을 확인했다. 이에 오브젝트 스토리지와 Apache Iceberg를 기반으로 컴퓨팅과 저장을 분리하고, Trino SQL 검색을 제공하는 장기 로그 저장소 Alaska를 구축했다. 수만 개 테이블에 데이터를 적재하기 위해 Iceberg SDK 기반 파이프라인과 카탈로그를 직접 구현하고, 작은 파일 컴팩션·스냅샷 정리·보존 기간 관리도 운영했다. 그 결과 Elasticsearch 보존 기간을 줄이면서 최대 5년 보존을 지원했고, 발표에 따르면 단위 비용을 약 20배 낮추고 인프라 비용을 절감했으며, 운영 과정에서는 커밋 실패와 지연 도착 로그를 고려한 검증·복구 설계가 중요하다는 교훈을 얻었다.
- 로그 조회 빈도와 보존 의무를 따로 분석하면, 고비용 검색 엔진에 모든 데이터를 보관해야 하는지 판단할 수 있다.
- Iceberg SDK를 직접 활용하면 수만 개 테이블로의 데이터 팬아웃과 커밋 흐름을 서비스 요구에 맞게 제어할 수 있다.
- 작은 파일은 쿼리 성능과 오브젝트 스토리지 운영에 부담을 주므로, 적절한 파일 크기와 주기적인 컴팩션을 설계해야 한다.
- 커밋 충돌과 지연 도착 로그를 고려해 재시도·중복 처리·컴팩션 범위를 정하고, 데이터 유실 방지 경로를 마련해야 한다.
- 테이블 포맷이나 라이브러리 버전을 올릴 때는 오류 주입 테스트로 실패 상황을 검증한 뒤 적용하는 것이 안전하다.
소개
[팀네이버 컨퍼런스 DAN25] NELO Alaska: 장기 로그 보존을 위한 Iceberg 도입과 운영 - 20x 비용 절감과 확장성 향상 본 세션에서는 NAVER의 전사 로깅 플랫폼 NELO에서 장기 로그 보존을 위해 오브젝트 스토리지와 Apache Iceberg 테이블 포맷, Trino 기반 SQL 검색을 도입해 ~20× 비용 절감과 높은 확장성을 달성한 사례를 공유합니다. 4 PiB+ 데이터를 운용하던 기존 Elasticsearch 중심 구조에서 실제 쿼리 분포와 보존 요구 간의 불일치를 정량 분석하고, 스토리지/컴퓨팅 분리·오픈 포맷·저비용 스토리지를 축으로 한 NELO Alaska 아키텍처를 설계·구현·운영한 경험을 중심으로 다룹니다. 목차 1. 배경 & 문제 정의 - NELO 소개: 사내 서비스/인프라/보안 모니터링을 담당, ES 클러스터 (4 PiB+, ~4,000대) - 기존 보존 전략의 한계: 인덱스 중심 구조의 비용, 샤드·리밸런스...
비슷한 학습 자료
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] What's In Our Infra: 대규모 트래픽을 수용하기까지
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] What's In Our Infra: 대규모 트래픽을 수용하기까지 네이버는 50여 개국에서 유입되는 수백만 규모의 트래픽을 24/7 안정적으로 처리하고 있습니다. 본 세션은 대규모 이벤트 운영 경험을 바탕으로 지연·장애·비용 문제를 해결하기 위한 엔지니어링 사례와 그 과정에서 얻은 교훈을 다룹니다. 아울러 한계를 넘어서기 위한 새로운 도전인 NVELOP(NAVER Velocity Platform) 의 배경과 방향을 소개합니다. 목차 1. Intro - 네이버 글로벌 라이브 스트리밍 플랫폼의 인프라 구성 개요 - 서비스 콘셉트와 챌린지 2. 무중단 서비스를 위한 엔지니어링 사례 - 대규모 트래픽 분산·제어 전략 - 전송 플랫폼 **최적화(Tune-in) **사례 - **Observability **도입 3. NVELOP (NAVER Velocity Platform) 방향 - 기존 플랫폼 한계 ...
데브옵스 · 인프라 네트워크
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] 기본기가 경쟁력이다 : 네이버가 Ncloud Storage를 만든 이유 네이버의 기존 Object Storage를 대체하고, 네이버 클라우드 플랫폼의 Object Storage와 Archive Storage 서비스를 대체하는 Ncloud Storage를 만들게 된 배경과 앞으로의 방향을 공유합니다. 목차 1. 기존 네이버 스토리지 시스템의 한계 - OwFS, Nubes의 설계 철학 - 시장의 흐름 2. 기존 NCP Object Storage의 한계 - 기능, 성능, 비용, 안정성 측면 3. S3 API 선택 이유 - S3 API - 개방성 4. 스토리지 기술에 진심인 네이버 - 스토리지는 플랫폼 비즈니스의 기본 - 기반 기술에 대한 장기적인 투자자인 네이버 - 개방형 생태계를 위한 기술 제공 5. Ncloud Storage를 어떻게 만들었나 6. 향후 계획 대상 - 대량의 ...
데이터베이스 클라우드
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] 하루 수백억 건을 처리하는 똑똑한 로그 파이프라인 만들기: 비용·성능·안정성 삼박자 네이버 전사 로그(최대 초당 수백만건, 하루 수백억건의 로그)를 수집/처리하는 로그 파이프라인 Logiss를 소개하고, Logiss에서 겪은 문제점들과 해결책들을 공유합니다. Storm + kafka 환경에서 multi topology를 적용하는 방법과 이를 통해 안정적인 무중단 배포가 가능해진 파이프라인과 지능형 파이프라인의 도입으로 낮시간의 피크 트래픽을 한가한 시간으로 분산시킨 방법, 장애 상황에서 로그의 우선 순위에 따른 차등된 처리 방식, 샘플링 기능으로 저장소를 효율적으로 이용할 수 있게된 방법을 알려드립니다. 목차 1. Logiss 시스템 소개 - Storm, Kafka, Logstash, OpenSearch로 구성된 파이프라인 아키텍처 - 네이버 서비스 전반에서 발생하는 로그를 수집, 하루 수백억 건의 로그를 실시간 처리...
데이터베이스 데브옵스 · 인프라
컨퍼런스 DAN 2025
[팀네이버 컨퍼런스 DAN25] 데이터 활용을 수 십 배 빠르게! KREAM의 데이터 Lakehouse 구축기 이 세션에서는 KREAM 데이터 플랫폼의 핵심 기반인 Lakehouse를 개발한 배경과 기술적 세부사항, 그리고 그로 인해 가능해진 변화들을 공유합니다. KREAM의 Lakehouse는 Kafka Ecosystem, Spark, Flink, Iceberg(HDFS), Hive Metastore, Trino, Airflow 등의 데이터 처리 기술을 활용하여 구축되었습니다. 메인 서비스 DB에서 실시간으로 발생하는 데이터와 하루 N억 건 이상의 유저 행동 데이터를 통합해, 데이터가 필요한 사내 모든 구성원들이 보다 빠르고 효율적으로 데이터를 획득·활용할 수 있게 되었습니다. Lakehouse를 개발하면서 겪은 고민과 경험들을 공유합니다. 목차 1. Lakehouse 도입 배경 2. Lakehouse 설계 & 기술 선택 3. Lakehouse 구성요소 & 데이터 파...
데이터베이스 데브옵스 · 인프라
컨퍼런스 엔지니어링데이 2025
늘어가는 조회트래픽 Elasticsearch로 분산시키기
컨퍼런스 엔지니어링데이 2025
네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. [발표 내용] 점점 늘어가던 플레이스 조회트래픽을 메인DB로부터 Elasticsearch(Opensearch)로 분산한 경험을 공유합니다. (#Elasticsearch #Opensearch #트래픽 분산 #CQRS #slow query #feature toggle #feature flag #자동 fallback) [강의 대상] * 트래픽 분산 및 Elasticsearch(Opensearch)에 관심이 있으신 분들 * 난이도 : 하~중하 (트래픽 분산경험 / ES 운용경험이 없으신 주니어 개발자분들도 이해하시기 좋은 정도) [목차] * 조회 DB 도입 배경 - 기존 리뷰조회 flow - 호출량이 점점 늘어가던 플랫폼, 증가하는 조회필터 / 정렬조건 - DB 인덱스 추가의 한계 - 조회용 DB를 도입한다면? * Elasticsearch를 조회DB로...
백엔드 데이터베이스
