온프레미스 데이터 플랫폼 팀의 데이터 엔지니어가 하는 일(feat. 11번가 데이터 플랫폼 2020년 회고)

잇다에서 데이터 엔지니어 멘토로 활동하면서 직무와 관련해 자주 설명하게 되는 부분은, 데이터 엔지니어가 정확히 어떤 일을 하는지에 관한 부분이었습니다. 해당 직무가 생긴지 오래되지 않았고, 아직도 역할에 대한 요구사항이 발전하고 있는 단계이기에 그러한 설명이 필요할 때마다 찾으려고 해도 잘 정리된 한글 문서를 찾기가 쉽지 않았습니다.

 

그렇기에 이 번 글에서는, 2020년 한 해(정확히는, 2019/09/23 ~ 2020/11/15) 동안 11번가에서 데이터 플랫폼 데이터 엔지니어로 근무하며 작업한 내용을 구조화하여 데이터 엔지니어가 어떠한 일을 하는지 전달드리려고 합니다. 근본적으로 데이터 엔지니어란? 에서 공유드린 관점에 기반해 좀 더 실무적인 사항들을 기술하였습니다.

 

 먼저, 11번가 데이터 플랫폼 팀에 대한 오버뷰를 통해 팀이 어떠한 상황에서 어떤 역할을 담당하고 있는지 전달드리고, 제가 진행한 작업들을 종류별로 살펴보며 데이터 엔지니어 직무에 대해 상세하게 설명드리겠습니다. 그리고 나서 짤막한 개인적인 감상을 더하려고 합니다.

---

11번가 데이터 플랫폼 팀의 역할

데이터 엔지니어는 데이터 상품화를 위한 소프트웨어 엔지니어입니다. 데이터 상품은 잘 정의되고, 관리된 데이터 자체일수도 있고, 그러한 데이터에 기반한 서비스일수도 있습니다. 그리고, 데이터 상품을 사용하는 고객은 내부고객(데이터분석가, 데이터사이언티스트, BI담당자, 기획자, 서비스 개발자 등)과 외부고객이 존재합니다 (데이터 엔지니어란?).

AWS 또는 Azure와 같은 클라우드 환경을 사용하는 경우에, 데이터 엔지니어는 클라우드에서 제공하는 서비스에 기반해 데이터 상품을 제공할 수 있습니다. 하지만, 온프레미스 환경이라면 클라우드 서비스에서 제공하는 것과 유사한 형태로 기본적인 데이터 플랫폼이 구축되고 운영되어야 합니다. 11번가 데이터 플랫폼 팀은 플랫폼 사용자들의 중복 업무를 최소화하기 위해 일부 작업을 대표로 맡아 처리하는 동시에 데이터 플랫폼을 구축하여 self-service가 가능한 형태로 제공하는 역할을 담당하고 있습니다. 그 명확한 구분은 이 글에서 모두 담기는 너무 길어서 위의 링크를 참고하시면 좋을 듯 합니다.

 

또한, 플랫폼을 제공하는 역할을 넘어서 회사 간의 데이터 송수신을 대표로 담당하는 데이터 처리에 대한 역할도 같이 겸하고 있습니다. 말그대로 데이터를 송신하고 수신하는 업무여서 많은 공수가 들지 않는다고 생각하기 쉽지만, 회원의 CI 값을 통해 탈퇴회원의 정보를 삭제하고 송수신 배치의 무결성을 검증하고, 스케쥴 관리하는 등의 작업도 수반되기에 조금 복잡해질 수 있는 작업입니다.

 

---

한 해 동안 진행한 종류별 작업들

진행한 작업을 시간순으로 나열하게 되면, 구조를 파악하기 어려워 고민하다가 데이터 파이프라인을 언급하며 자주 사용하는 4단계 구분(입수, 저장, 가공, 사용)을 통해 구분하여 전달해드리려 합니다.

 

Data Platform

입수

Sqoop 입수 File Format 최적화

데이터 플랫폼이 입수하는 원천 데이터는 3종류(ClickStream, Server Logs, DB)가 있습니다. 그중 DB 데이터 입수를 위해 Sqoop을 사용하고 있는데, 기존에는 CSV 포맷에 Snappy 압축을 사용하고 있었습니다. Parquet과 ORC 등의 포맷과 다양한 압축방법을 적용한다면 여러 장단점이 있음을 인지하고 있었습니다. 그렇기에 아래의 다양한 조사자료를 토대로 내부 성능 테스트를 진행하였습니다.

 

그 결과 Parquet / deflate이 현재 상황에서 적절한 판단이라는 결론을 내렸고, 변경을 통해 디스크 사이즈 감소 및 쿼리 성능 개선이라는 결과를 얻어냈습니다.

 

테스트와 변경 2부분에 대한 언급을 좀 더 드리자면, 테스트는 해당 데이터를 팀만 사용하는 것이 아니라 전사적인 접근이 지속되기에 다양한 상황에 대한 테스트가 필요했습니다. 효율화의 이유를 타당하게 입증하는 것만 아니라 실제 변경을 어떻게 실행해야될지 여러가지 상황에 대한 테스트도 필요했습니다. 그리고 어떻게 시간 단위로 계속 실행되는 배치에 대해 다른 팀이 영향을 받지 않도록 안전하게 변경하는 것도 중요하였는데요. 연관된 여러 시스템을 이해하는 부분과 다양한 배치를 중요도로 나누어 단계별로 변경한 부분이 많이 도움이 되었던 것 같습니다. 

 

 

참고

• The impact of columnar file formats on SQL‐on‐hadoop engine performance: A study on ORC and Parquet
• VCNC Apache Spark에서 컬럼 기반 저장 포맷 Parquet(파케이) 제대로 활용하기
• clairvoyantsoft Big Data File Formats
• An Introduction toBig Data FormatsUnderstanding Avro, Parquet, and ORC

 

아쉬웠던 부분

'마지막까지도 이해되지 않는 부분'들과 '이런 부분은 이렇게 더 처리해놔도 좋지않을까'하는 부분들이 있었습니다:

• Sqoop1 > Spark2.3: 여러 조건으로 테스트를 해보아도, Oracle DB에서 데이터를 가져와 deflate(Spark은 Gzip)으로 쓰는 부분에서 Sqoop이 언제나 2배 가까이 빠른 부분이 잘 이해가 가지 않았습니다. 처음에는 Spark로 대체하기 위한 의도로 '설마 느리겠어?'라는 심정으로 테스트를 했는데, 느려서 기존의 Sqoop을 이용해 deflate로 적재하기로 하였습니다.
• Sqoop이 적재 시, Gzip이 지원되지 않는 부분입니다. Sqoop2도 POC 해봤으나, 운영 상 복잡함이 더해질 듯하여 포기하였고, 결국 원본을 deflate으로 일단 쓰고 읽어서 다시 Gzip으로 쓰기로 하였습니다(rewrite이 null을 ""로 쓰기 위해 필요하였기에).
• 일부 접근이 많고 테이블 사이즈가 큰 clickstream 테이블에 대한 파일 포맷(아래 VCNC 사례와 같이), 파티션, 적재 시 Ordering 등의 최적화는 충분히 다른 많은 사용자에게 영향을 줄 수 있는 부분이기에, 추가적으로 진행해도 좋을 것 같았습니다. 

저장

데이터 및 메타데이터 라이프사이클 관리

데이터를 저장하는 것은 비용을 동반합니다. 온프레미스 환경은 AWS와 같은 클라우드 환경과 같이 1 GB 증가량 당 $0.023와 같은 형태로 비용이 추가되진 않지만, 스토리지용 가용 서버가 부족한 환경에 놓이게 된다면 HDFS와 같은 서비스가 다운되는 상황을 막기 위해 데이터 라이프사이클을 관리하는 것이 매우 중요한 업무가 될 수 있습니다. 

S3에서 객체의 라이프사이클을 관리해주는 것과 달리, HDFS를 사용하는 환경에서는 그러한 기능을 직접 구현해야 하였습니다. 또, 이러한 관리는 단순 서비스의 기능 구현만이 아니라 데이터를 요청한 데이터 사용자와의 협의와 입수 프로세스에 포함하는 등의 커뮤니케이션도 필요한 부분이었습니다. 

먼저, 기능 구현과 관련해서는 기존 Python으로 일부 구현된 것을 리팩토링하고 기능 추가하여 Docker Image 형태로 배포하고 Airflow에서 Schedule할 수 있도록 만들었습니다. 연관된 서비스(또는 데이터)는 Webhdfs, Hive Server, 사원 정보 테이블, 협의한 보관주기 리턴하는 API 등이며, 관련 기능은 아래와 같습니다:

 

• 압축 (raw -> gzip - Hot 데이터 기간이 지난 경우)
• 삭제 (보관주기 지난 파티션, 퇴사자 DB)
• 알림 (미사용 테이블, 개인 HDFS Path에 과도한 디스크 사용)

 

입수 프로세스의 변경은 보관주기를 디폴트로 7일로 가져가고 추가적인 연장이 필요한 경우 프로세스에 따라 협의하여 연장하는 방향으로 변경한 부분입니다. 개인정보의 경우 보관기간이 7일이라는 부분도 고려하여 정하였으며, 초기에 시작된 데이터에 대한 관리가, (자동적으로 생성된) 메타데이터에 대한 관리로 넓어져 불필요한 데이터와 메타데이터(Hive DB 또는 Table)이 없도록 관리하였습니다.

 

아쉬웠던 부분

지금 당장 디스크 사이즈가 터질 수 있다라는 생존과 직결된? 이슈화로 시작되어 진행한 작업이었으나, 진행하면 할수록 기술적인 부분 보다는(결과적으로 기술로 구현될 수는 있으나), 데이터 거버넌스와 관련된 사항이었습니다. 팀 내에서 '거버넌스 파트'로 명칭되어 소속되어 있기도 해서, 개인적으로도 데이터 거버넌스와 같은 부분들이 팀 간의 사일로를 벗어나 좀 더 cross 팀 관점에서 중요하고 간주되고 TF로 진행하면 좋겠다는 생각이 자주 들었던 것 같습니다. 

 

빅데이터 거버넌스(Data Governance)의 정의 및 목적, 그리고 고려사항(및 도구)들

 

구체적인 항목들은 위와 같은 데이터에 대한 라이프사이클, 데이터 품질(Data Quality), 데이터 접근 관리 및 절차(입수요청, 승인 등)에 대한 합의가 데이터 오너, 데이터 사용자, 데이터 운영자 간에 Sync가 잘 맞아서 하나의 흐름을 만드는 것인데요. 많은 부분 일을 하며 발생한 병목이 그러한 기술적인 것을 벗어난 부분에 있었기에 그렇게 느낀 듯 합니다. 데이터 거버넌스와 관련해 고민한 부분은 추후에 다른 글로 공유드려보겠습니다. 

 

또, 다른 한 가지로는 온프레미스 환경에서 끊임없이 발생하는 레거시를 벗어나는 부분에 대한 것입니다. 모든 소프트웨어 아키텍쳐의 고민과 같으나, 온프레미스 환경이고 데이터 플랫폼의 경우 (주관적인 느낌으로 - 좀 더 고민이 필요함) 서비스 간에 좀 더 tight하게 엮여 있어서, 새롭게 나오는 효율적이고 뛰어난 서비스로 이동해가는데 병목이 되었던 것 같습니다. 아키텍쳐에 대한 진화적인 관점은 책 'Building Evolutionary Architectures'에 잘 나와 있기에 'Fundamentals of Software Architecture'와 같이 읽으면서 '아하 모먼트'가 자주 왔던 것 같습니다.

 

 

가공

최적화 (MR to Tez, Pyspark 코드 리팩토링, Intel MKL 적용)

가공에 포함되는 다양한 배치를 최적화하는 작업도 많았던 것 같습니다. 3가지 종류가 있었는데 아래에서 항목별로 전달드리겠습니다.

 

• MR to Tez: 데이터 송수신을 위해 Hive의 대상 테이블들의 특정 컬럼을 읽어서 회원 CI와 같은 테이블과 조인하여 필터링하는 배치가 Mapreduce로 돌아가고 있었습니다. Tez의 경우 MR과 달리 중간 결과를 메모리에 저장하여 OutOfMemoryError가 발생하는 경우가 있었기에 그러한 부분에 대한 대비가 필요했는데요. Tez 메모리 튜닝 또는 Azure 사례 등을 확인하며 테스트를 진행하였고 이상이 없다는 판단하에 일괄적용하여 15 ~ 30% 성능 개선을 얻어냈습니다.
• Pyspark 코드 리팩토링: 타팀의 Pyspark 작업이 데이터 플랫폼에서 운영하는 Yarn 클러스터의 리소스를 너무 많이 사용하여 가장 많은 리소스를 사용하는 작업(Yarn의 memorySeconds 기준)의 튜닝을 진행했습니다. 중요 포인트는 Spark History Server UI를 보고 해석하기, Cartesian을 피하기, Spark SQL에서 명시적으로 Broadcast 힌트 적용, Sort를 위해 Window를 사용하지 않고 UDF와 GroupBy를 통해 우회하기 였는데요. 결과적으로 성능은 소요시간 80%, 메모리 90%, 코어 65% 정도 개선될 수 있었습니다. 추후에 기회가 있으면 상세히 전달드리겠습니다.
• Intel MKL 적용: Python2에만 Intel MKL이 적용되어 있어 테스트를 바탕으로 성능을 확인하고, 상용 클러스터에 변경 적용하는 부분을 진행하였습니다.

 

아쉬웠던 부분

생각나는 한 가지는 여러가지 성능 비교를 통해 '엄청 빠르다'는 dremio의 맛(?)을 못 본 부분입니다. 온프레미스 환경에서 커뮤니티 버젼을 사용하는 부분(아마도 권한이었던 듯)에 한계가 있어서 못했는데요. 비슷하게 Azure에 올라온다던 Photon powered engine도 궁금했던 기억이 나는 것 같습니다.

 

사용

Apache Ranger POC

데이터 접근 관리 개선 테스트 데이터 접근 관리는 기존에 여러 오픈소스와 인하우스가 결합한 형태로 사내 LDAP을 기반으로 관리되고 있었습니다. Hadoop 환경 위에 다양한 엔진과 서비스가 추가되면서 그러한 도구로는 적절한 권한 관리가 어려워 Apache Ranger 테스트를 진행하게 되었습니다. 

Docker에 기반해 로컬에서 Apache Ranger 클러스터와 HDFS, Hive Server, Presto와 연동시키며 테스트를 진행하였고 공유를 통해 다른 팀원 분의 실제 적용을 도왔는데요. Ranger의 경우 문서화가 잘 되어있지 않아 코드를 자세히 보며 그 구현도 살펴볼 수 있었습니다. 이곳에 자세히 기술해 두었습니다.

모니터링 고도화 (HDFS, Hive, Spark, AWS Cost)

기존 인프라 팀에 기반한 모니터링은 Hadoop 환경의 다양한 서비스에 대해서 원하는 형태의 모니터링과 알람을 제공하지 않아 데이터 플랫폼의 중점적인 서비스 모니터링을 위한 통합모니터링 구축을 일부 담당하였습니다. HDFS, Hive, Spark, Yarn 등을 사용하는 것과 다르게 모니터링의 관점으로 바라보게 되면 그 구조를 이해하고 어떤 부분에 대한 모니터링과 알람이 필요한지 생각하게 되어 또 다른 부분에 이해에 도움이 되었습니다. 

• HDFS: Namenode, Datanode, Journalnode의 기본적으로 제공되는 Metric과 목적에 따라 특정 Path(.Trash와 같은 Directory)에 대한 모니터링
• Hive Server: Enabled하여 트래픽, 성공 또는 실패 쿼리 등을 통해 다양한 목적의 알람에 이용
• Spark: Yarn의 다양한 작업과 유사하나 JVM 뿐만 아니라 Pyspark을 많이 사용하기에 Python 메모리 사용에 대한 수집이 필요했습니다. Agent를 통해서 (다른 분이) 구현하였고, 그러한 형태에 대한 설명은 'Monitoring the Dynamic Resource Usage of Scala and Python Spark Jobs in Yarn'에 매우 자세히 나와있습니다. 구축 후에는 데이터 사용자들이 Pyspark에서 할당한 메모리와 사용한 메모리가 나오는 그래프를 보고, 알아서 튜닝할 수 있는 문화가 정착되었는데요. 데이터플랫폼이 좀 더 쾌적하는 데에 많은 부분 기여했습니다.
• AWS Cost: HDFS, Yarn 등의 사용량을 바탕으로 AWS Pricing 정책을 적용하여 대략적인 비용을 계산하는 기능을 추가하였습니다. 크게 HDFS Storage, HDFS Requests(ops), Yarn memorySeconds, Yarn vcoreSeconds를 사용하였습니다.

 

참고

• Evaluation Metrics of Service-Level Reliability Monitoring Rules of a Big Data Service

 

AWS Deequ를 통한 Data Quality POC

마지막에 아주 짧게 진행한 AWS deequ를 통한 데이터 품질 관리 부분입니다. 마지막으로 팀을 떠나면서, 거버넌스 파트가 가져갈 수 있는 먹거리(?)라고 생각해서 확인해보았었는데요. 깊게 테스트하지 않아서 별다른 내용은 없는데, 추후 좀 더 생각을 정리해서 공유해보도록 하겠습니다.

 

 

참고

• Automating Large-Scale Data Quality Verification
• Delivering High Quality Analytics at Netflix    
• Data Sentinel: Automating data validation   
• Implementing Data Quality with Amazon Deequ & Apache Spark

 

아쉬웠던 부분

11번가 이전의 2년간의 데이터 엔지니어 경력이 모두 클라우드 환경이었기에, 온프레미스 환경에서도 기대치는 클라우드에 근접해가자는 방향이었고, 항상 개선할 부분이 느껴지는 순간순간들이었던 것 같습니다.

 

중간에 잠깐 쿠버네티스 환경을 테스트하며 DataDog과 Kube Monitoring 세트 등을 비교하다가, Hadoop 모니터링을 한땀한땀 구현하고 있으면 저장소 빼고는 쿠베로 올리는 방향으로 가자는 이야기가 나올 때마다 설레였었는데요. 기회가 된다면, 좀 더 데이터 플랫폼의 기반 시스템을 고도화하는 부분을 담당할 수 있었으면 재밌을 것 같습니다. 

 

---

올해 그리고 내년...

올해는 11번가에서 데이터 플랫폼에서 데이터 거버넌스 파트의 데이터 엔지니어로 근무하였습니다. 

 

그동안 온프레미스의 다양한 서비스와 내부구조를 탐색하였는데요. 이전 회사에서 AWS만 사용했던 것과 매우 상반되는 경험으로 조금 더 폭 넓게 서비스 하나하나 살펴볼 수 있어서 의미있는 시간이었던 것 같았습니다. 또한, 데이터 엔지니어의 소프트웨어 엔지니어적인 역할 외에 Data Lifecycle, Personal Data, Data Quality, Data Platform 등의 측면을 고민해볼 수 있는 시기였던 것 같습니다.

 

아쉬웠던 부분은, 생각보다 코드를 짜는 시간이 없고, 코드리뷰 등을 통해 고민할 시간이 적었던 부분인데요. 

 

이제 11번가의 Vertical 개발팀의 일원으로 백엔드 엔지니어로 근무하게 되었으니 내년은 좀 더 코드와 웹서비스에 대해 많이 고민하는 시간을 가질 수 있을 것으로 기대합니다. 그것을 목표로 또 어떻게 성장할지 잘 계획을 세워보아야 하겠습니다.