안녕하세요. HBase 팀 이욱입니다. 저는 16년간 데이터베이스 엔지니어로 일해 왔습니다. DBA(database administrator)의 업무에는 다양한 작업이 있으며, 그중에서 특히 데이터 마이그레이션은 일상다반사처럼 자주 수행하는 작업인데요. 그럼에도 DBA에게는 언제나 힘들고 때론 도전적인 작업입니다. 마이그레이션 작업 중에는 언제든 데이터 유실이나 데이터 정합성 관련 문제가 발생할 수 있기 때문입니다.특히 RDBMS가 아닌 NoSQL인 HBase의 데이터 마이그레이션 작업에는 더욱 많은 공수와 도전이 수반됩니다. 저 역시 RDBMS에서 많은 데이터 마이그레이션 작업을 수행해 왔지만, NoSQL인 HBase 마이그레이션은 클러스터 수가 훨씬 많고 데이터 크기가 수백 테라바이트에서 수백 페타바이트에 달하기 때문에 더욱 어렵습니다.이번 글에서는 최근에 진행한 Anzen 서비스(LINE Official Account 서비스)의 HBase 마이그레이션 작업 과정을 공유하고 작업하면서 얻은 지식을 나누려고 합니다. 이 글이 HBase에서 데이터 마이그레이션 작업을 계획하고 계신 분들께 도움이 되기를 바라며 시작하겠습니다.Anzen 서비스의 HA(high availablitiy) 프로젝트를 진행하게 된 배경은 크게 두 가지입니다.서비스의 고가용성 확보LINE 앱에서는 기업이나 단체, 공공기관 등에서 사용할 수 있는 공식 계정 서비스인 LINE Official Account 서비스를 제공하고 있습니다. 이 서비스에서 각 공식 계정은 Messaging API라는 API를 이용해 메시지를 주고받으며, 이 API에 대한 요청과 결과 로그는 HBase에 저장합니다.이 로그는 LINE Official Account의 각 사용자에게 얼마의 비용을 청구할지 산정하는 데 사용하는 중요한 데이터인데요. 이전에는 장애가 발생하면 이 데이터가 유실돼 정확한 데이터를 산출할 수 없는 문제가 발생했었습니다. 이에 IDC 장애나 자연재해 발생 시에도 서비스를 지속할 수 있도록 HA 환경을 구축하기로 결정했습니다.기존에 사용하던 Cloudera 제품의 라이선스 비용이 날로 증가하며 점점 부담이 커지고 있었습니다. 이에 라이선스 비용을 줄이고 기술을 내재화하기 위해 오픈소스로 전환하는 것을 검토했고, 내부에서 Apache HBase를 이용해 준비하며 테스트한 결과 내재화에 성공해(참고: HBase 오픈소스 전환을 위한 HBH(HitBase Handler) 개발기) 마이그레이션 프로젝트가 시작됐습니다.HBase는 대용량 데이터를 처리할 수 있는 분산형 NoSQL 데이터베이스로, 수평적 확장성이 뛰어납니다. 수십억 개의 행과 열을 효율적으로 처리할 수 있으며, 저비용으로 확장할 수 있습니다. RDBMS와 달리 스키마가 유연하고, 비정형 데이터를 쉽게 저장할 수 있어 빅데이터 처리에 적합합니다. 칼럼 기반 저장 방식을 사용하기 대문에 조회와 쓰기 속도가 빠릅니다. HBase는 특히 빅데이터를 처리하거나 실시간으로 데이터를 처리해야 하는 시스템에서 RDBMS보다 더 적합한

SK플래닛의 Hadoop 기반 Data Integration Cluster(이하 DIC)는 서비스의 다양한 데이터를 수집하고 분석하는 데 사용합니다. 데이터의 분석을 수행할 때는 새로운 정보나 인사이트를 위해 다른 테이블과의 조인 및 변환을 통해 파생 데이터를 생성하며, 파생 데이터를 생성하는 여러 방법 중 Hive Query 형태로 로직을 만들고 Oozie, Airflow를 통해 스케줄을 관리하는 형태가 가장 많이 사용되고 있습니다.하지만, 이 방법의 단점은 변환하려는 Hive 테이블의 데이터가 더 추가되지 않는 완전한 상태여야 합니다. 그래서 날짜 단위로 파티션이 나누어진 Hive 테이블은 데이터가 추가되지 않는 +1일 이후에 파생 데이터를 생성합니다. 자정이 넘은 새벽 시간에 파생 데이터 생성 작업을 하는 주요 이유이기도 합니다.+1일 이후에 파생 데이터가 생성된다는 것은 분석할 데이터가 늦어지는 것이므로 새로운 인사이트를 얻거나 고객에게 제공할 새로운 서비스도 지연됨을 의미합니다. 위와 같은 고민으로 데이터를 수집하는 동시에 파생 데이터도 생성하는 방법에 대해서 고민하게 되었습니다.파생 데이터 생성시간 단축의 핵심은 ‘데이터의 실시간 처리’입니다. DIC로 유입되는 많은 실시간 데이터의 변환과 적재를 효율적으로 관리하는 시스템의 필요성을 느끼게 되었는데요. 'Streaming Platform as as Service'를 지향하는 서비스로서 몇 가지의 목표를 세우게 되었습니다.• 가상의 그래프 형태로 데이터의 흐름을 표현하며 데이터 파이프라인의 설정을 UI로 손쉽게 시각화한다.• 배치 작업에서 사용하던 Hive Query를 재사용할 수 있게 한다.• 데이터 파이프라인 별로 필요한 만큼 리소스를 조정한다.• 다양한 저장소로 적재하는 기능을 갖는다.• 데이터 파이프라인의 모니터링 및 이상 유무를 감지한다.위와 같은 특징을 가진 'Router'라는 서비스를 개발하였습니다.[그림 2]는 Router에서 데이터 파이프라인을 설정한 화면입니다.Router의 데이터 파이프라인은 2개의 vertex를 하나의 edge로 연결한 'directed graph' 형태로 표현합니다. vertex는 데이터가 존재하는 저장소를, edge는 저장소의 데이터 변환을 의미합니다. 2개의 vertex는 위치에 따라 'source vertex'와 'target vertex'로 명칭하는데, source vertex는 원본 데이터, target vertex는 edge에 의해 변환된 데이터에 해당됩니다. 데이터가 계속 흘러간다는 의미로 '스트리밍 데이터'라는 표현을 많이 쓰는데요, Router는 edge들을 연속적으로 연결해서 이 스트리밍 데이터의 흐름을 쉽게 파악할 수 있습니다.[그림 2] Router 데이터 파이프라인Router의 가진 기능을 크게 2가지고 분류하고 기능을 확장하는 형태로 구현되었습니다. 데이터를 저장하는 기능은 Connect, 변환은 Processor로 명칭하고 각각 Kafka Connect와 Spark을 사용했습니다.• Connect• Kafka C

이번 글에서는 먼저 카프카 커넥트에 대해 간략한 소개를 하고, 3.5 버전부터 새롭게 추가된 카프카 커넥트 오프셋 관리 기능에 대해 소개하고자 합니다.글은 총 2부로 나누어 작성하며, 먼저 1부에서는 카프카 커넥트가 무엇이고 동작 방식에 대해 간략하게 소개하고,다음으로 이어지는 2부에서 카프카 커넥트 오프셋 관리 기능에 대해 소개하겠습니다.카프카 커넥트는 아파치 카프카(Apache Kafka)와 다른 시스템 간에 데이터를 보내고 받을 수 있는 도구입니다.소스 시스템에서 카프카로 데이터를 스트리밍 하거나 카프카에서 싱크 시스템으로 데이터를 스트리밍 하는 것에 중점을 두며,고품질, 안정성, 고성능 등을 제공하여, 사용자 및 관리자가 유연하게 사용할 수 있습니다.뿐만 아니라, REST API를 제공하여 별도의 코드 작성 없이 사용자가 원하는 커넥터를 생성, 삭제 등을 할 수 있는 장점도 가지고 있습니다.위 그림(출처: 컨플루언트)은 카프카와 카프카 커넥트 및 데이터 시스템들의 관계를 나타낸 그림입니다.좌측에 위치한 데이터 시스템들을 소스(source)라고 하고, 우측의 시스템들을 싱크(sink)라고 자주 표현합니다.그림의 내용을 조금 더 자세히 설명하자면, 소스 시스템의 데이터를 카프카 커넥트를 통해 카프카로 전송하고, 카프카에 저장된 데이터는 카프카 커넥트를 통해 싱크 시스템으로 전송합니다.카프카를 중심으로 두고, 양 종단의 외부 시스템 사이에서 카프카 커넥트가 데이터 전송 처리하는 역할을 담당합니다.대략적인 카프카 커넥트의 역할에 대해 이해가 되셨나요? 다음에서 설명할 카프카 커넥트의 동작으로 넘어가기 전에 커넥트 관련 용어에 대해 간단히 정리하겠습니다.카프카 커넥트에서 사용되는 몇 가지 용어들이 있는데, 이 부분은 커넥트를 이해하는데 필요한 부분이므로 숙지한다면, 커넥트를 이해하는데 도움 됩니다.• None 커넥터(connector): 외부 시스템과 카프카 커넥트 런타임 간의 인터페이스 역할, 태스크들을 관리하며, 소스 커넥터와 싱크 커넥터로 구분• None 태스크(task): 실제 카프카와 시스템 사이에서 데이터를 가져오거나 보내는 작업을 처리• None 워커(worker): 커넥터 및 태스크를 실행하는 프로세스• None 컨버터(converter): 커넥터와 데이터를 보내거나 받는 시스템 간의 데이터 포맷 간에 레코드를 시리얼라이즈 또는 디시리얼라이즈 처리• None 트랜스폼(transform): 레코드를 보내거나 받을 때 레코드를 간단한 로직으로 변환앞에서 본 그림과 같이 데이터를 가지고 있는 소스 시스템이 매우 다양합니다.커넥트가 이렇게 다양한 시스템들을 다루기 위해서는 다양한 종류의 커넥터(connector)들이 존재합니다.대표적인 커넥터를 소개하자면, JDBC 커넥터, HDFS 커넥터, ES 커넥터, S3 커넥터 등이 있습니다.그 외 다양한 커넥터들도 있는데, 커넥터들은 Confluent Hub에서 확인할 수 있습니다.그리고, 이러한 커넥터들은 크게 소스 커넥터와 싱크 커넥터로 분류합니다.소스 시스템과 가깝게 위치한 커넥터를

본 글에서는 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) 정보도 실시