Gmarket Hadoop Platform Baikal 소개

안녕하세요 Data Platform Engineer 조광진입니다.

저희 Platform Technology 팀은 지난 수년간 On-premise Hadoop 기반의 빅데이터 플랫폼인 'Baikal' 이란 서비스를 사내에 제공하여 전사에서 활용되는 데이터의 수집, 적재, 분석에 대해 편의성을 제공하고 있습니다.

빅데이터 플랫폼 Baikal은 On-premise 에서 Cloud Lakehouse Platform으로 전환을 앞두고 있습니다.
Cloud Lakehouse Platform으로 전환하기 앞서 On-premise Hadoop 기반인 Baikal에 대해 소개하고자 합니다.

---

Gmarket Baikal

Baikal 이란 이름은 잘 아시다시피 러시아 시베리아 남쪽의 있는 세계에서 가장 오래되고 깊은 담수호 이름입니다. 대용량 데이터 분석을 위한 Data Lake 이름으로 Baikal 이란 네이밍은 적절하다고 생각됩니다. Gmarket 의 Transaction, Traffic 등의 다양한 데이터를 통합 분석하며 비즈니스 인사이트를 얻을 수 있는 플랫폼의 역할을 하고 있습니다.

---

Baikal Architecture

Architecture

데이터 처리 흐름에 따라 6개의 Step으로 작성된 Gmarket Baikal Architecture입니다.
크게 Data Source, Message Broker, Data Processing, OLAP, Data Storage, Data Analytic으로 구분했습니다.

Cluster

Baikal Architecture 안에 있는 Cluster의 종류는 총 4개 이며, 각 Cluster의 역할은 아래와 같습니다.

• Hadoop Cluster: Spark 을 제외한 일반적인 Hadoop ecosystem
• Spark Cluser: Spark, Spark Streaming Job
• Druid Cluster: OLAP 서비스를 제공
• Isilon Cluster: HDFS의 Warm/Cold 데이터 백업

---

DataSource 종류와 특징

Baikal 플랫폼에서 처리하는 데이터 종류에 대해 알아보겠습니다.

Traffic Data

Traffic 데이터는 지마켓에 방문한 고객들의 행동을 기록한 행위 데이터입니다. 웹 페이지 혹은 애플리케이션에서 수집된 데이터는 실시간으로 Kafka로 적재되며 데이터 처리는 Spark Streaming, Gobblin 등 별도의 Consumer를 통해서 데이터를 처리합니다. 실시간 분석이 필요한 데이터 경우 Spark Streaming에서 Druid로 전달하여 Superset에서 Realtime 분석을 할 수 있도록 제공합니다.

Transaction Data

Transaction 데이터는 지마켓의 고객들이 제공된 서비스를 이용하면서 발생한 데이터이며 MSSQL, Oracle과 같은 관계형 데이터베이스에 저장되어 있습니다. Transaction 데이터의 종류는 구매, 배송, 상품,할인, 고객의 정보가 저장되어 있으며 데이터 처리는 RDB 에서 HDFS 로 데이터를 전달할 때 Sqoop을 활용합니다.

Cache Data

Redis로 저장된 캐시성 데이터는 Redis의 'RDB' 기능으로 Disk로 데이터를 받아 JSON 형식으로 변환 후 HDFS로 적재하여 Hive에서 조회가 가능하여지도록 합니다.

---

Message Broker

Data Soruce로 부터 데이터를 전송 받아 데이터 처리와 저장을 하기 위해서 Message Broker인 Kafka 를 활용합니다. Kafka는 빠른 속도와 더불어 데이터를 안정적으로 제공할 수 있기에 대부분의 Platform에서 핵심역할을 하고 있습니다.

 

Baikal을 사용하는 사내 여러 서비스에서 Kafka로 데이터를 전송하기 위해 Producer를 직접 개발합니다. 적재된 Kafka에서 데이터를 가져가는 Consumer는 목적에 따라 서비스 관리자 및 개발자들이 직접 Spark Streaming으로 개발하거나 별도의 Consumer를 만들게 됩니다. HDFS로 적재하여 Hive로 데이터를 조회하는 용도라면 저희 팀에서 제공하는 Gobblin 을 통해 Kafka 데이터를 Consuming 합니다.

---

OLAP

사내에서 OLAP(On-Line Analytical Processing) 서비스는 Kylin과 Druid 2가지로 제공합니다. Kylin, Druid는 모두 Hadoop 기반 OLAP이지만 사용 용도에 따라 차이점이 있습니다.

Kylin은 데이터의 어떤 면을 볼 것인지 Cube를 정의하여 결과 데이터를 미리 만들어 수초 이내에 빠르게 조회할 수 있는 서비스입니다. Gmarket에서 Kylin은 Hive에 적재된 데이터를 기반으로 Cube 를 생성하여 MapReduce Engine을 통해 만들어진 결과인 Segment를 생성 후 HBase 로 적재하여 사용자에게 빠르게 필요한 데이터를 제공합니다. Kylin 은 Business에서 무엇을 볼 것인가라는 질문에 대한 답이 정해져 있을 때 적합하며, 일반적인 데이터 탐색 용도로는 적합하지 않습니다. 

 

Druid는 일반적으로 RealTime 기반의 시계열 데이터에 대해 강점을 가진 OLAP 서비스입니다. 시계열 데이터를 장기간 보관하면서 Dimension 갖고 분석하는 데 주로 사용되고 있습니다. Druid의 Deep Storage는 HDFS를 사용하고 있기 때문에 Hadoop Cluster의 HDFS 를 활용하여 Segment를 적재합니다.

---

Data Processing

실시간 데이터 처리가 필요한 서비스 경우 Spark Streaming을 주로 활용합니다. 메모리 기반의 분산 클러스터 컴퓨팅 엔진이므로 메모리에 대한 리소스가 많이 필요하게 됩니다. 따라서 기존 Hadoop Cluster가 갖고 있는 적은 메모리로는 Spark Job 실행시키기에 어려움이 있다고 생각되어 별도의 Spark Cluster 를 구성했습니다. Hadoop Cluster와 마찬가지로 HDFS, Yarn, Zookeeper 기반 위에 Spark이 설치되어 있는 구조입니다. 이를 통해 데이터 파이프 라인을 실시간으로 수집할 수 있게 되었으며 Zeppelin에서 Spark Interpreter를 통해 데이터 엔지니어링을 제공했습니다.

 

Kafka에 적재된 데이터 중 Hive로 데이터 분석이 필요한 데이터는 Gobblin을 통해 HDFS로 Consuming 합니다. Gobblin은 Kafka Offset을 HDFS내에 서 자체적으로 관리하여 Exactly Once로 동작하기에 Kafka Message를 한 번만 가져오게 합니다. 또 한, Kafka to HDFS는 표준화가 되어 있어 추가 개발이 필요하진 않아 Kafka Broker 및 Topic 관련 몇 가지 설정값을 통해 HDFS로 데이터를 적재합니다. Gobblin 역할 대신에 여러 데이터 처리 솔루션이 고민이 되었습니다. NiFi, Sqoop, Storm, Flume 등 각 솔루션 별로 장점이 존재하지만 Gmarket Baikal에서는 Gobblin이 적은 개발 리소스와 운영포인트로 인해 사용이 적합하다고 판단되어 사용하게 되었습니다.

 

Sqoop은 RDBMS, NoSQL 등의 다양한 Data Store에서 HDFS로 데이터를 가져오거나 내보낼 수 있는 양방향 데이터 처리 도구입니다.
Sqoop 옵션으로 Database 연결 문자열, 테이블 이름, 계정 등의 정보를 입력하면 조회 쿼리로 변환되어 MapReduce Job으로 동작합니다. Hue에서 상대적으로 편리하게 Sqoop Jobd을 만들고 Oozie Workflow를 통해 주기적으로 데이터를 가져오거나 내보낼 수 있어 사용자들에게 많은 편의성을 제공했습니다.

---

Data Storage

일반적으로 Data Warehouse 로 Hive와 Operational Data Store로 HBase로 구분하고 있습니다. 다만 Baikal에서는 데이터 흐름상 Data Storage로 Step을 구성하였습니다.

Hive 사용자가 좀 더 쉽게 Hadoop을 사용할 수 있도록 도와주는 서비스입니다. Hive는 SQL Interface로 HDFS 데이터에 Table Schema를 입혀 SQL Query를 통해 데이터에 접근할 수 있습니다. Hive는 SQL Query를 사용하지만, 내부적으로는 Engine에 따라 MapReduce, Tez Job으로 동작하게 됩니다. Baikal에서는 Tez Engine을 사용하고 있습니다.

 

HBase는 주로 Kylin Cube를 Build하여 만들어진 결과인 Segment의 저장소로 사용하고 있습니다. Segment는 Kylin 내부에서 개별 HBase 테이블로 표현되기에 Auto Merge를 적절히 활용해 Cube 당 Segment의 개수를 수십 개 정도로 유지하고 있습니다.

 

HDFS에 적재된 데이터 중에서 사용 빈도가 상대적으로 적어진 데이터를 별도의 Isilon NAS Storage로 저장하는 용도입니다.
HDFS처럼 3 copy로 인해 실제 데이터 용량보다 3배를 차지하는 것이 아니라 Parity 블록을 사용하여 HA를 보장하면서 1.2~1.5배 정도 용량을 차지하여 가용용량 확보에 도움을 줄 수 있습니다. 이렇게 사용 빈도가 적은 데이터를 Isilon 으로 이관함으로써 기존 Hadoop 클러스터에서는 Hot 데이터의 분석을 원활하게 할 수 있게 지원했습니다.

---

Data Analytics

Zeppelin

Zeppelin은 제공되는 여러 Interpreter를 통해 Spark 환경에 접속할 수 있는 웹 서비스입니다. Spark 을 통한 데이터 엔지니어링과 같은 작업을 위해 제공합니다. 그 밖에 JDBC Interpreter를 통해 HiveServer2 연결을 제공하여 SQL로도 데이터를 확인할 수 있도록 지원합니다.

Superset

Superset은 Data Visualization을 위한 웹 서비스입니다. RDBMS, Kylin, Druid 등 다양한 Data Store와 연결하여 사용할 수 있으며 통계성 데이터, 시계열 데이터를 보여줍니다.

Hue

Hadoop 환경에 접속할 수 있는 웹 서비스입니다. Hive Query, HDFS File browser, Oozie Workflow 생성 등 전반적인 Hadoop의 에코 시스템들을 이용하여 서비스하는데 활용할 수 있습니다.

---

회고

프로젝트를 진행할 때 프로젝트에 대한 회고 없이는 프로젝트도 나자신도 성장할 수 없다고 생각합니다. On-premise Hadoop을 운영하면서 겪었던 많은 이슈 중에 Architecture 적으로 아쉬웠던 점 하나를 정리해 보았습니다.

Spark Cluster, Hadoop Cluster 별도 구성의 아쉬움

Baikal은 Hadoop Cluster와 Spark Cluster가 별도로 구성되어 있습니다.  Hadoop Cluster 도입 이후 Spark을 도입하면서 기존 Hadoop Cluster에는 메모리가 많이 부족했기에 디스크가 거의 없이 메모리 스펙 기반의 Spark Cluster를 별도로 구성했습니다. 서로 다른 스펙을 가진 서버이기 때문에 처음에는 하나로 합치지 않고 별도로 구성했습니다.

 

그 당시 두 개의 클러스터를 합치지 않은 이유는 아래와 같습니다.

1. Spark Job 은 메모리가 높은 서버에서만 동작이 필요
2. Spark Cluster 는 디스크가 없기 때문에 Hadoop의 Data Locality 장점을 얻을 수 없음

하지만 지금은 하나의 Cluster로 통합하는 측면이 유리하다고 생각됩니다.

• Yarn Node Label을 활용해 많은 메모리 기반의 Job을 분리해서 메모리 기반의 서버군으로 실행할 수 있습니다.
• Data Locality로 인한 성능 문제는 크게 중요하지 않다고 생각됩니다. MR을 제외한 대부분의 Job이 Tez, Spark으로 메모리 기반이기 때문에 Data Locality보다는 네트워크 환경이 더 중요하다고 생각합니다. 사내 네트워크 환경은 10G 환경이기 때문에 충분히 커버된다고 생각합니다.
• Cluster 통합으로 인해 관리포인트를 줄일 수 있습니다.
• 상대적으로 Spark Cluster의 리소스가 많이 남게 되는데 리소스를 좀 더 효율적으로 활용할 수 있습니다.

---

마치며

글 초반에 언급했듯이 Baikal 서비스는 Cloud Lakehouse Platform 기반인 Databricks로 전환하고 있습니다. 이번 글을 통해 프로젝트에 대해 다시 한번 정리하고 회고를 하면서 차세대 플랫폼은 어떻게 개선해야 할지 고민할 수 있는 좋은 시간이었습니다.

감사합니다.