로그 모니터링 시스템은 서비스 운영을 위해서 반드시 필요한 시스템입니다. 로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용됩니다. 네이버도 Elasticsearch 기반의 로그 모니터링 시스템을 구축했으며, 수천 대의 서버로 수 페타바이트 규모의 로그 데이터를 저장하고 있습니다. 최근 들어 서비스 규모가 확장되고 저장해야 하는 로그 데이터의 규모와 트래픽 양이 급속도로 증가하면서 Elasticsearch 기반의 로그 모니터링 시스템은 비용 문제와 더불어 확장성 문제에 직면하게 됐습니다.네이버는 저비용으로 대용량의 로그 데이터를 수집할 수 있도록 Apache Iceberg(이하 Iceberg)를 도입한 신규 컴포넌트 Alaska를 개발해 네이버의 로그 모니터링 시스템 플랫폼 NELO에 적용했습니다. 이 글에서는 기존 로그 모니터링 시스템의 문제와 Iceberg의 특징을 소개하고, Alaska의 작동 방식과 Alaska를 NELO에 적용한 이후의 변화를 소개합니다.Elasticsearch 기반 기존 로그 모니터링 시스템의 한계Elasticsearch를 기반으로 구축된 기존 로그 모니터링 시스템의 구조를 간략하게 도식화하면 다음 그림과 같습니다.클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후 Elasticsearch에 저장됩니다. Elasticsearch는 SSD 타입의 스토리지로 구성된 Hot 계층(Hot Tier)과 HDD 타입의 스토리지로 구성된 Warm 계층(Warm Tier)으로 구분되어 있습니다. 로그 데이터는 Hot 계층에 3일간 저장된 후 Warm 계층으로 이동되어 최대 90일까지 저장됩니다. 이렇게 Hot 계층과 Warm 계층의 두 단계로 나누어 데이터를 저장하면 검색이 빈번하게 일어나지 않는 데이터를 효율적이면서 저비용으로 저장할 수 있습니다.기존 로그 모니터링 시스템은 수년간 이와 같은 구조로 운영되었습니다. 그동안 데이터가 증가함에 따라 Warm 계층에 저장된 데이터의 크기도 급증했습니다. Elasticsearch는 단일 클러스터로 저장할 수 있는 데이터의 크기에 제한이 있기 때문에 다수의 Elasticsearch 클러스터를 구성해 클러스터 수준에서 확장을 진행했습니다. 그 과정에서 모든 클러스터가 한계 수준까지 도달해 운영 장애를 빈번하게 겪었습니다. 연간 수십억 원의 인프라 사용 비용도 부담이 되었습니다. 두 계층으로 구성된 Elasticsearch 클러스터는 더 이상 로그를 효율적으로 저장할 수 있는 구조가 아니게 되었습니다. 새로운 타입의 데이터 저장 스토리지의 필요성Warm 계층에 저장된 데이터의 크기가 급증하는 이유에는 장기간 로그의 저장에 대한 요구 사항도 있습니다. 기존 로그 모니터링 시스템은 Elasticsearch에 최대 90일까지 로그 데이터를 저장할 수 있게 허용했습니다. 하지만 서비스의 법적 요구 사항 등의 이유로 예외로 1년 이상의 로그 데이터 저장을 허용하고 있었습니다. 기존 로그 모니터링 시스템이 한계에 도달하면서

본 글에서는 SK 플래닛의 Data Lake이자 빅데이터 플랫폼인 DIC(Data Integration Cluster)에서 진행한 데이터 리드 타임 단축을 위한 실시간 데이터 전달 강화 과제를 소개하고자 합니다. 이 프로젝트에서는 스트림 데이터의 실시간 처리와 오픈소스 Trino를 전사 데이터 분석 엔진으로 활용하여 데이터 전달 시간을 획기적으로 줄였습니다. 따라서 이번 글에서는 Trino를 활용한 전사 데이터 분석 및 조회 시스템 구축 사례에 대해 자세히 설명하고자 합니다.SK플래닛은 고객에 대한 깊은 이해를 바탕으로 데이터 기반의 다양한 서비스를 개발하며 차별화된 가치를 제공하기 위해 2014년부터 전사적으로 서비스 데이터를 통합해 왔습니다. 이를 위해 회사의 모든 정보를 On-Premises 환경의 Hadoop 클러스터로 통합하였으며, 로그 및 실시간 데이터는 Kafka 클러스터를 통해 처리 후 Hadoop에 저장됩니다. 이렇게 통합된 자료를 효과적으로 분석하고 활용하기 위해, Hadoop Eco 기반의 오픈소스 솔루션과 Data Infrastructure 팀이 자체 개발한 도구들을 사내 여러 부서에 제공하고 있습니다. 아울러 데이터 처리와 분석 작업을 보다 유연하게 수행하기 위해 Kubernetes 클러스터를 구축하여 활용 중입니다.이러한 솔루션들은 회사 내부적으로 DIC(Data Integration Cluster)라고 불리며, 데이터를 적재하고 활용할 수 있는 통합 환경을 제공하는 다양한 웹 및 WAS 시스템으로 구성되어 있습니다. 현재 SK플래닛의 전 구성원 중 20% 이상이 이 시스템을 적극 활용하고 있으며, 주요 서비스 분석, 인사이트 도출, 마케팅 및 타겟팅 활동에 중요한 역할을 담당하고 있습니다. 특히 DIC는 실명 기반 마케팅과 비실명 기반 타겟팅 광고에도 필수적인 기능을 수행하고 있습니다.빅데이터 플랫폼인 DIC에 입수되는 데이터는 크게 3가지 종류로 구성됩니다.이 중 사내 데이터는 다음의 두 가지 유형으로 구분됩니다.이 데이터는 주로 RDBMS(예: MySQL, Oracle)로 관리되며, Hadoop 클러스터의 HDFS(Hadoop Distributed File System)에 복제되어 저장됩니다. 운영계 데이터는 일별 또는 시간별로 주기적으로 스냅샷 형태로 HDFS에 적재됩니다. 이러한 방식으로 정기적으로 적재하는 이유는 과거와 현재 데이터를 쉽게 비교할 수 있어 데이터 분석에 유리하기 때문입니다.HDFS는 데이터를 추가하는 형태에 적합하므로, 운영계 데이터는 업데이트보다는 새로운 정보를 계속 쌓아가는 구조로 관리됩니다. 이는 사내 전체 데이터의 약 80%를 차지합니다.이 데이터는 사내 서비스에서 수집된 사용자 로그 데이터를 의미하며, 실시간으로 수집되어 즉시 분석과 처리가 가능합니다. 이를 위해 각 애플리케이션에는 데이터 수집을 위한 SDK(Rake)가 설치되어 있으며, 이 정보를 실시간으로 Kafka로 전송합니다.또한, 서버에서 직접 전송되는 데이터(Rake Kafka)와 로그(LogAgent) 정보도 실시

2023년 9월 13일 수요일, 스파크 선정릉점에서 ‘Trino meetup’을 성황리에 마무리하였습니다.이번 meetup은 지난 5월에 이어 두번째로 열린 Trino meetup행사로실시간 아키텍쳐에서 Trino의 활용방안, Trino에서 사용하고 있는 Online aggregation 개념, 그리고 Trino의 무중단 서비스 구현 방안을 공유하는 자리였고이를 위해 SKT엔지니어 3명이 발표를 해주셨습니다.발표 주제는 지난번보단 좀 더 엔지니어 레벨에서 들으면 좋을만한 내용들에 포커싱 되었었습니다.이번 행사는 비가 옴에도 지난 1차때보다 더 많은 분들이 와주셔서 놀라웠습니다.행사는 3명의 발표자가 각각의 주제를 가지고 발표하고 이에 대한 Q&A를 하는 방식으로 진행하였으며주제는 다음과 같았습니다.• None Trino를 위한 실시간 Kappa 아키텍처 (SKT 이상현)밋업 후에 참가자들에게 받은 피드백은 대체적으로 호의적이었으며 다음 meetup에도 참여할 의향이 있음을 보였습니다.• None 행사에 대한 만족도 : 4.58점 (5점 만점)• None 현재 Trino를 사용중입니까? : 사용중 (45%), 고려중(19%), 아니다(36%)• None• None Trino를 위한 실시간 Kappa 아키텍처 : 만족도 : 4.5점, 난이도: 3.45• None Trino속 online aggregation : 만족도 : 4.08점, 난이도 : 3.10• None Non-disruptive update Trino Cluster : 만족도 : 4.32점, 난이도 : 3.66앞으로의 계획지난번과 마찬가지로 일정 주기로 Trino관련 meetup이나 행사를 하려고 하고 있습니다.지금까지는 주로 SKT에서 발표하는 식으로 진행되고 있는데 다음번에는 Trino를 사용하고있는 다른 회사나 개발자분들이 참여하셔서 더 다양한 관점과 내용들로 채울수 있도록 하겠습니다.마지막으로 행사를 준비하고 진행하신 모든분들께 진심으로 감사합니다.

2023년 5월 18일 목요일, 스파크 선정릉점에서 첫번째 ‘Trino meetup’을 성황리에 마무리되었습니다.이번 meetup은 국내에서 처음으로 개최되는 Trino관련 행사로 Trino에 적용 사례와 개발방향, 그리고 미래의 Data Service 방식와 이를 위한 Trino에 사용방법들에 대해서 공유 자리였고이를 위해 Starburst Co founder인 Matt Fuller와 SKT Data Engineer 2명이 각각의 주제로 발표를 하고 질의응답을 받는 식으로 진행하였습니다.발표 주제가 로드맵이나 Data Serving방식 같은 큰 주제부터 Trino 사용시 성능향상을 위해 알아야할것들을 코드레벨로 설명하는 디테일한 내용들을 포함하고 있어다양한 사람들이 흥미를 가질만한 내용들이었습니다.Meetup 현장행사는 3명의 발표자가 각각의 주제를 가지고 발표하고 이에 대한 Q&A를 하는 방식으로 진행하였으며주제는 다음과 같았습니다.Trino Today and Tomorrow (Matt Fuller, Co-Founder at Starburst) - Zoom Building Bridge 2 Data Service : 데이터가 생성되는 시점에 ETL 없이 Data Lake 로 구성하려면 우리는 무엇을 해야할까? (SKT 안성화) 수집하지 마세요. 연결하세요 : Trino 에서 데이터 저장소와 상호작용하는 방식을 알아보자 (SKT 이용환)다양한 내용들을 포함하고 있었던 만큼 쉬는 시간에도 별도 Q&A가 진행될 정도로 많은 질문들이 있었으며질문에 내용들로 미루어 짐작컨데 Trino에 도입을 진지하게 고민하거나 현재 사용중인 조직들이 많타는걸 알 수 있었습니다.참가자 피드백밋업 후에 참가자들에게 받은 피드백은 대체적으로 호의적이었으며 다음 meetup에도 참여할 의향이 있음을 보였습니다.행사에 대한 만족도 : 4.55점 (5점 만점)다음 meetup에서 참여할 의향이 있으신가요? : 96.8%(참여할 의향이 있다)다음 희망 주제 : 활용사례 (43%), 내부구조 (31%), 튜닝(19%)앞으로의 계획정기적으로 Trino관련 meetup또는 관련 행사를 하려고 기획중입니다. 다음 행사때는 참가자분들의 피드백을 통해 더 나은 행사를 준비할 수 있도록 하겠습니다.마지막으로 행사를 준비하고 진행하신 모든분들과 참여해주신 모든분들께 진심으로 감사드립니다.