로그 모니터링 시스템은 서비스 운영을 위해서 반드시 필요한 시스템입니다. 로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 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년 이상의 로그 데이터 저장을 허용하고 있었습니다. 기존 로그 모니터링 시스템이 한계에 도달하면서

들어가며서비스 내에서 발생하는 다양한 활동을 추적하고, 이를 통해 보안, 규정 준수, 문제 해결을 지원하는 로그는 기업 운영에 필수적인 요소입니다. 특히, 전자 계약과 같은 민감한 데이터를 다루는 B2B 서비스에서는 사용자 활동을 정확하고 신뢰성 있게 기록하는 것이 중요합니다.그러나 로그에 충분한 데이터가 없는 경우 분석이나 활용에 제한적일 수 있습니다. 예를 들어, 문서 ID만 있는 로그의 경우 어떤 문서인지 직관적으로 이해하기 어렵습니다. 이런 부분들을 해결하기 위해 로그 인리치먼트를 적용할 수 있습니다. 로그 인리치먼트란 로그에 메타데이터나 컨텍스트를 추가하여 로그를 풍부하게 만드는 과정입니다.이 글에서는 감사로그 프로젝트를 수행하면서 로그 인리치먼트를 어떻게 설계하고 구현했는지에 대해 공유하려고 합니다.아키텍처동기 방식 VS 비동기 방식로그 인리치먼트를 구현하는 방식은 동기 방식과 비동기 방식으로 나눌 수 있습니다.동기 방식의 경우 데이터 일관성과 정합성이 높지만, 생성 시점에 외부 시스템에 대한 의존성이 발생할 수 있습니다. 그리고 합성에 필요한 데이터를 동기적으로 가져와야 하므로 성능 문제가 발생할 수 있습니다.비동기 방식의 경우 로그를 생성하는 시점에는 외부 시스템에 대한 의존성이 없기 때문에 성능을 유지할 수 있지만 이후 프로세스에서 비동기적으로 합성이 필요하기 때문에 별도 시스템 구축이 필요합니다. 또한 생성과 합성의 시점이 다르기 때문에 데이터 정합성에 대한 이슈도 발생할 수 있습니다.모두싸인은 비동기 방식을 사용하였고, 그 이유는 다음과 같습니다모두싸인은 마이크로 서비스 아키텍처를 도입하고 운영하고 있습니다. 마이크로 서비스에서는 서비스 간의 의존성이 높아지면 성능 문제나 시스템 복잡도에 따른 관리 비용 이슈 등이 따라오게 됩니다. 또한 생성되는 로그들이 수억 건 이상이기 때문에 이 중 감사로그를 필터링하더라도 동기적으로 처리하는 경우 서비스 성능에 문제를 야기 시킬 수 있었습니다.메타데이터 저장소비동기 방식을 선택함에 따라 메타데이터 합성은 서비스가 아닌 별도의 시스템으로 분리되지만, 여전히 메타데이터 정보들은 서비스에 존재하고 있습니다. 이를 가장 쉽게 처리하는 방법은 서비스에 직접적으로 메타데이터를 호출하는 방법입니다. 하지만, 이 경우 로그 시스템과 서비스 간의 의존성과 서비스 성능 등 여러 가지 사이드 이펙트가 발생하게 됩니다.또한 로그 생성 시점과 합성 시점이 분리됨에 따라 그사이에 리소스 삭제로 인해 합성이 실패하는 이슈도 존재했습니다. 예를 들어 “유저(루카스)가 문서(근로계약서)를 읽었다.”라는 감사로그를 생성하는 도중에 문서가 삭제될 수 있습니다. 이 경우 원시 로그에 있는 유저ID, 문서ID를 기반으로 유저명(루카스), 문서명(근로계약서)을 가지고 오는 과정에서 데이터가 존재하지 않기 때문에 합성할 수 없게 됩니다.그래서 저희는 메타데이터 저장소를 구성하고 합성 시점에 이를 활용하는 방법을 선택했습니다. 이를 위해 각 서비스에 존재하는 메타데이터를 어떻게 동기화할 것인지에 대한 추가적인 고민이 필요

Kafka Connect와 JDBC 커넥터를 이용해 DB 데이터를 쉽게 Kafka로 전송하는 방법과 발생 가능한 문제를 해결하는 방법을 공유합니다.안녕하세요. 컬리 데이터베이스개발팀 김소라입니다. 현재 컬리는 다양한 서비스와 시스템 운영을 위해 여러 종류의 데이터베이스를 사용하고 있습니다. 하지만 각 데이터베이스의 구조와 처리 방식이 달라 관리가 복잡하고 활용하기 어렵기 때문에, 데이터를 하나의 분석 플랫폼으로 통합하는 다양한 파이프라인을 운영하고 있습니다. 그 중 오늘은 카프카 커넥트(Kafka Connect)를 활용한 데이터 파이프라인에 대해 설명해드리려고 합니다.Kafka Connect는 카프카 메시징 시스템을 기반으로 다양한 데이터 소스 시스템, 예를들어 RDBMS, NoSQL 혹은 csv와 같은 파일이나 로그 등의 데이터 소스에서 발생한 이벤트를 다른 데이터 타겟 시스템으로 별도의 코딩 없이 실시간으로 전달할 수 있는 Kafka Component 중 하나입니다.카프카 커넥트의 가장 큰 장점으로는 별도의 코딩없이 파이프라인 구성이 가능하다는 점 입니다. 다양한 데이터 소스 시스템의 이벤트를 별도의 kafka client를 이용한 코딩 없이 json 형태의 config만 정의하면 카프카를 통해 안전하게 다른 시스템에 동기화할 수 있습니다. 그래서 반복적인 데이터 파이프라인을 구성할 때 유리합니다.또한 카프카 커넥트는 다양한 데이터 소스와 시스템 간의 연동을 지원하는 커넥터를 제공합니다. 최근 오픈 소스의 활성화와 클라우드 서비스의 확산으로 데이터 소스 시스템의 종류가 급격히 다양해졌는데, 이에 맞춰 카프카 커넥트는 여러 종류의 커넥터를 지원하며, 오픈 소스로도 제공되고 있습니다. 이를 통해 비용 절감은 물론 필요에 따라 커스터마이징도 가능합니다.이러한 장점들은 서로 다른 서비스 간 데이터 연동이나 운영 데이터베이스의 데이터를 스테이징 영역으로 복사하는 등의 다양한 상황에 유용하게 활용될 수 있습니다. 컬리 또한 다양한 소스 데이터베이스의 데이터를 카프카 메시지로 바꿔 타겟 시스템에 적재하는 데이터 파이프라인 구성에 활용하고 있습니다.• 카프카 커넥트(Kafka Connect) 는 커넥터로 구성되어있는 프레임워크이며 커넥터를 동작시키는 역할을 합니다.• 커넥터(Connector) 는 카프카 커넥트 내부의 실제 메시지 파이프라인이며 데이터를 실질적으로 처리하는 태스크(task)들을 관리합니다.• 태스크(Task) 는 실제로 데이터를 가져오거나 넣는 일을 수행하는 단위로, thread 레벨로 수행됩니다.• 워커(Worker) 는 카프카 커넥트 프로세스가 실행되는 서버 또는 인스턴스를 의미합니다.config를 제출해 데이터 처리가 호출되면 워커 내부의 커넥터들에 의해 테스크들이 생성되고 파이프라인이 구동됩니다. 그 후 테스크 내부에서 카프카와의 전송이 가능하도록 메시지 형식과 포맷을 변환하여, 외부 시스템과 카프카 간에 데이터를 전송합니다.위의 그림은 데이터를 변환하는 구조를 나타낸 그림입니다. 커넥터 인스턴스에서 소스 시스템의 데이터를

안녕하세요. Enablement Engineering 팀에서 SRE(site reliability engineer)로 일하고 있는 어다희입니다.저희 팀은 LINE 서비스를 보다 높은 성능으로 효율적이고 안전하게 사용자에게 제공할 수 있도록 다방면에서 'Enablement'를 지원하는 역할을 수행합니다. 구체적으로 미디어 플랫폼에 대한 사이트 안정성 엔지니어링(Site Reliability Engineering)과 더불어 트래픽의 시작점이라고 할 수 있는 GSLB(global server load balancing)와 CDN(content delivery network) 관련 업무를 담당하고 있습니다.이번 글에서는 신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성에 이어서 미디어 플랫폼에 SLI/SLO를 정의해 운영 업무에 적용한 후기를 공유해 보려 합니다.서비스가 아닌 플랫폼에 SLI/SLO를 도입하기LY에는 LINE 및 LINE 패밀리 서비스에서 사용되는 사진과 동영상 등을 저장 및 가공하고 딜리버리하는 미디어 플랫폼인 OBS가 있습니다. OBS는 LINE의 많은 서비스 중 미디어를 사용하는 대부분의 서비스에서 사용하는 대표 플랫폼 중 하나입니다. 예를 들어 LINE 앱 대화방에서 주고받는 미디어 메시지는 전부 OBS를 사용합니다. 그러므로 이 플랫폼의 신뢰성(reliability)은 굉장히 중요하며, 최종 사용자에게 더 좋은 품질의 서비스를 제공할 수 있도록 SLI(service level indicator)/SLO(service level objective)를 정의하게 되었습니다.대부분의 SLI/SLO는 '서비스'를 기준으로 설정합니다. 사용자 입장에서 신뢰성을 측정하기 위해서는 서비스 내부에서 사용되는 '플랫폼'보다는 서비스를 기준으로 측정하는 것이 용이하기 때문입니다. 하지만 OBS의 경우 약 160개에 이르는 다양한 LINE 서비스에서 사용하고 있으며, 이 플랫폼의 문제는 곧 각 서비스의 문제로 직결될 수 있기 때문에 별도로 SLI/SLO를 정의하게 되었습니다.플랫폼의 CUJ를 어떻게 정의할 것인가?위와 같은 배경으로 시작했으나 CUJ(critical user journey) 설정부터 서비스와 다른 벽에 부딪혔습니다. CUJ에 대한 자세한 설명은 1편에서 확인할 수 있는데요. 이 글을 시작으로 접하시는 분들을 위해 간 단히 설명하면 아래와 같습니다.• 사용자가 서비스를 사용하는 과정 혹은 흐름을 정의한 것을 '사용자 여정(user journey)'이라고 부르며, 사용자 여정 중 핵심 기능 및 서비스에 대한 여정을 '핵심 사용자 여정(critical user journey, CUJ)'이라고 부릅니다.• 동영상 서비스에서 '사용자가 서비스에서 동영상을 재생하기 위해 거치는 과정'이나, 메시징 서비스에서 '사용자가 메시지를 전송하기 위해 거치는 흐름' 혹은 '친구를 추가할 때 거치는 과정' 등이 사용자 여정입니다.플랫폼은 API를 통해 기능을 제공하는데 이를 각 서비스에서 어느 로직에 어떻게 사용하는지 일일이 확인하는