Yimian는 디지털 상거래 데이터를 전문으로 하는 선도적인 AI 기반 데이터 분석 제공업체입니다. 비즈니스 전략, 제품 개발 및 디지털 상거래 운영에 대한 실시간 인사이트를 제공합니다. 많은 고객은 프로크터 앤드 갬블, 유니리버, 마스 등 미용, 메이크업, F&B, 애완동물, 자동차 분야의 산업 리더들입니다.
초기 기술 아키텍처는 온프레미스 데이터 센터에서 CDH(Cloudera Distributed Hadoop)를 사용하여 구축된 빅데이터 클러스터였습니다. 비즈니스가 성장함에 따라 데이터 양이 급격히 증가했습니다.
확장 주기가 길고, 컴퓨팅 및 스토리지 리소스가 맞지 않으며, 유지 관리 비용이 높은 등의 문제를 해결하기 위해 데이터 아키텍처를 변환하고 클라우드로 마이그레이션하기로 결정하였습니다. 스토리지-컴퓨팅 분리 방식을 채택했습니다. 신중한 평가 후 Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS)를 선택했습니다.
현재 JuiceFS를 통해 컴퓨팅-스토리지 분리 아키텍처를 구현하여 전체 스토리지 용량을 두 배로 늘렸습니다. 특히, 성능에 큰 영향을 주지 않았으며 운영 비용이 크게 감소했습니다.
이 글에서는 Hadoop을 클라우드로 마이그레이션하기 위한 우리의 아키텍처 설계를 공유하고, 왜 JuiceFS+EMR+OSS를 선택했는지, 그리고 이 새로운 아키텍처로부터 어떻게 이익을 얻었는지 설명합니다. 이 게시물을 통해 유사한 과제에 직면한 분들에게 가치 있는 인사이트를 제공하고자 합니다.
기존 아키텍처와 과제
점점 커지는 애플리케이션 요구를 충족하기 위해 수백 개의 대형 웹사이트에서 데이터를 크롤링하고 있으며, 현재 500개를 초과하였습니다. 시간이 지남에 따라 많은 양의 원시, 중간 및 결과 데이터를 축적했습니다. 웹사이트 크롤링과 고객 기반을 계속 확장함에 따라 데이터 양이 급속하게 증가하여 성장하는 요구를 수용하기 위해 하드웨어를 확장하기로 결정했습니다.
원래 아키텍처
다음 그림은 데이터 센터에서 CDH 기반 빅데이터 클러스터를 구축한 기존 아키텍처를 보여줍니다:
- 핵심 구성 요소로는 Hive, Spark, HDFS가 있었습니다.
- Kafka를 포함한 여러 데이터 생산 시스템이 클러스터로 데이터를 공급했습니다.
- Kafka와 함께 TiDB, HBase, MySQL 등의 다른 스토리지 솔루션을 사용했습니다.
데이터는 상류 애플리케이션 시스템과 데이터 수집 시스템에서 시작되어 Kafka에 기록되었습니다. Kafka Connect 클러스터를 사용하여 데이터를 HDFS에 동기화했습니다.
이 아키텍처 위에 다양한 작업을 관리하는 사용자 정의 데이터 개발 플랫폼인 OneWork를 개발하였으며, 이러한 작업은 Airflow를 통해 예약되고 작업 큐에서 처리되었습니다.
고통의 지점
직면한 과제는 다음과 같습니다:
- 애플리케이션 데이터의 급격한 성장과 장기적인 확장 사이클: 2016년에 배포된 우리의 CDH 클러스터는 2021년에 페타바이트 규모의 데이터를 처리하게 되었습니다. 그러나 데이터 성장은 종종 하드웨어 계획을超過하였고, 6개월마다 자주 확장을 하게 되었습니다. 이는 많은 자원과 시간을 소모하게 되었습니다.
- 저장-계산 결합과 용량 계획의 어려움: 전통적인 Hadoop 아키텍처의 저장과 계산의 밀접한 결합은 저장 또는 계산 요구에 따라 독립적으로 확장하고 계획하는 것을 어렵게 만듭니다. 예를 들어, 저장 공간을 확장하려면 불필요한 계산 자원을 구매해야 합니다. 이는 비효율적인 자원 배분을 초래합니다.
- CDH 버전 업그레이드에 대한 두려움: 우리의 CDH 버전은 오래되었고, 안정성과 호환성에 대한 우려로 업그레이드에 주저했습니다.
- 높은 운영 비용: 약 200명의 직원을 가진 우리는 단 하나의 전職 운영 직원만을 두고 있었습니다. 이는 무거운 업무 부담을 가져왔습니다. 이를 완화하기 위해, 우리는 더 안정적이고 간단한 아키텍처를 찾아보았습니다.
- 단일 데이터 센터의 결함: 단일 데이터 센터에 저장된 모든 데이터는 장기적인 위험을 초래했습니다. 케이블 손상이나 기타 문제가 발생할 경우, 단일 데이터 센터는 단일 결함 지점을 만듭니다.
새로운 아키텍처의 요구 사항
우리의 도전 과제를 해결하고 성장하는 요구를 충족시키기 위해, 우리는 몇 가지 아키텍처 변화를 결정했습니다. 업그레이드를 고려한 주요 측면은 다음과 같습니다:
- 클라우드 도입, 弾性 확장성, 운영 유연성: 클라우드 서비스를 활용하면 운영을 간소화할 수 있습니다. 예를 들어, 클라우드 기반 저장소를 활용하면 애플리케이션에 집중하면서 유지보수 작업을 피할 수 있습니다. 또한, 클라우드 리소스는 장비 배포와 시스템 구성에 소요되는 시간 없이 弾性 확장성을 가능하게 합니다.
- 저장소-컴퓨트 분리: 우리는 저장소와 컴퓨트를 분리하여 더 나은 유연성과 성능을 달성하려 했습니다.
- 오픈 소스 구성 요소 선호, 벤더 경찰 피하기: 클라우드 서비스를 사용하지만, 특정 벤더에 대한 의존도를 최소화하려 했습니다. AWS Redshift를 고객 서비스에 사용하는 동안, 내부 운영에는 오픈 소스 구성 요소를 선호했습니다.
- 기존 솔루션과의 호환성, 비용과 리스크 통제: 우리의 목표는 현재 솔루션과의 호환성을 보장하여 개발 비용과 애플리케이션에 미치는 영향을 최소화하는 것이었습니다.
왜 우리는 JuiceFS+EMR+OSS를 선택했는가
여러 솔루션을 평가한 후, 우리는 EMR+JuiceFS+OSS를 저장소-컴퓨트 분리된 빅데이터 플랫폼을 구축하고 온프레미스 데이터 센터를 클라우드로 점진적으로 이전하기로 선택했습니다.
이 구성에서, 오브젝트 스토리지가 HDFS를 대체하고, JuiceFS는 POSIX와 HDFS 프로토콜을 지원하기 때문에 프로토콜 계층으로 사용됩니다. 맨 위에는 Hive, Impala, Spark, Presto/Trino 등을 포함한 반 관리형 Hadoop 솔루션인 EMR을 사용합니다.
阿里巴巴云 vs. 다른 공공 클라우드
신중한 평가 후, 우리는 다음과 같은 이유로 AWS와 Azure보다 Alibaba Cloud를 선택했습니다:
- 근접성: 알리바바 클라우드의 동일 도시 내 가용 영역은 낮은 레이턴시와 감소된 네트워크 비용을 보장합니다.
- 포괄적인 오픈소스 구성 요소: 알리바바 클라우드 EMR은 Hadoop과 관련된 다양한 오픈소스 구성 요소를 제공합니다. 우리는 Hive, Impala, Spark, Hue를 많이 사용하지만, Presto, Hudi, Iceberg 등과의 원활한 통합도 제공합니다. 연구 중에 EMR이 Impala를 기본적으로 포함하는 유일한 서비스라는 사실을 알게 되었으며, AWS와 Azure는 더 낮은 버전을 제공하거나 수동 설치 및 배포를 요구합니다.
JuiceFS vs. JindoFS
JuiceFS란?
JuiceFS는 고성능의 오픈소스, 클라우드 네이티브, 분산 파일 시스템입니다. 이는 전체 POSIX 호환성을 제공하여 다양한 플랫폼과 지역에서 객체 스토리지를 거대한 로컬 디스크로 사용할 수 있게 합니다.
JuiceFS는 데이터-메타데이터 분리된 아키텍처를 채택하여 분산 파일 시스템 디자인을 가능하게 합니다. JuiceFS를 사용하여 데이터를 저장할 때, 데이터는 Amazon S3과 같은 객체 스토리지에 지속되며, 메타데이터는 Redis, MySQL, TiKV, SQLite 등의 데이터베이스에 저장될 수 있습니다.
POSIX 외에도 JuiceFS는 HDFS SDK와 완벽하게 호환되어 HDFS를 저장-계산 분리용으로 원활하게 대체할 수 있습니다.
JuiceFS를 JindoFS보다 선택한 이유
다음과 같은 고려 사항들에 따라 JuiceFS를 JindoFS보다 선택하였습니다:
- 저장 설계: JuiceFS는 데이터 및 메타데이터 분리 저장 구조를 채택하여 분산 파일 시스템 설계를 가능하게 합니다. 데이터는 객체 저장소에 지속되고, 메타데이터는 Redis, MySQL, TiKV, SQLite 등 다양한 데이터베이스에 저장될 수 있어 더 높은 유연성을 제공합니다. 반면 JindoFS의 메타데이터는 EMR 클러스터의 로컬 하드 디스크에 저장되어 유지 관리, 업그레이드 및 이전이 불편합니다.
- 저장 유연성: JuiceFS는 다양한 저장 솔루션을 제공하여 다른 스키마 간의 온라인 마이그레이션을 지원하고 이식성을 증가시킵니다. JindoFS 블록 데이터는 OSS만 지원합니다.
- 오픈 소스 커뮤니티 지원: JuiceFS는 오픈 소스 커뮤니티를 기반으로 하며 모든 공용 클라우드 환경을 지원합니다. 이는 향후 멀티 클라우드 아키텍처로의 확장을 용이하게 합니다.
전체 아키텍처 설계
데이터 센터의 하둡 클러스터에는 여전히 일부 응용 프로그램이 유지될 예정이므로 하이브리드 클라우드 아키텍처를 사용합니다. 아래 그림에 표시된 것처럼.
아키텍처 그림에서:
- 위에는 Airflow와 OneWork가 있으며 분산 배포를 지원하므로 수평으로 쉽게 확장할 수 있습니다.
- 왼쪽에는 전통적인 CDH 아키텍처를 사용하는 IDC와 일부 Kafka 클러스터가 있습니다.
- 오른쪽에는 알리바바 클라우드에 배포된 EMR 클러스터가 있습니다.
IDC와 EMR 클러스터는 고속 전용 회선으로 연결됩니다.
새로운 아키텍처의 혜택
저장-계산 분리의 이점
저장-계산 분리 구현에 따라 총 저장 용량이 두 배가 되었으나 계산 자원은 안정적으로 유지되었습니다. 가끔씩 일시적인 작업 노드를 필요에 따라 활성화합니다. 우리 시나리오에서는 데이터 양이 급격히 증가하는 반면 쿼리 요구는 안정적입니다. 2021년부터 데이터 양이 두 배로 늘었습니다. 초기 단계부터 현재까지 계산 자원에 대해 최소한의 변경만 있었으며, 특정 애플리케이션 요구에 따라 탄력적인 자원과 일시적인 작업 노드를 가끔씩 활성화하는 것을 제외했습니다.
성능 변화
주로 오프라인 계산을 위한 대규모 일괄 처리가 주요 애플리케이션 시나리오인 경우, 성능에 큰 영향은 없었습니다. 그러나 PoC 단계에서 임시 Impala 쿼리의 응답 시간이 개선되는 것을 관찰했습니다.
PoC 단계에서 몇 가지 간단한 테스트를 진행했습니다. 그러나 다양한 영향 요인으로 인해 결과를 정확하게 해석하기 어렵습니다:
- HDFS에서 JuiceFS로의 전환
- 구성 요소 버전 업그레이드
- Hive 엔진의 변경
- 클러스터 부하의 변경
이 모든 것으로 인해 이전 CDH 배포와의 성능 차이에 대한 확실한 결론을 내리기 어렵습니다.
사용 편의성과 안정성
JuiceFS에 문제를 만난 적이 없습니다.
EMR을 사용하는 동안 사소한 문제가 있었습니다. 전반적으로 CDH는 더 안정적이고 사용자 친화적으로 인식됩니다.
구현 복잡성
우리 시나리오에서 가장 시간이 많이 소요되는 과정은 증분 듀얼 라이트와 데이터 검증입니다. 회고하면, 검증에 과도하게 투자했고 이를 단순화할 수 있습니다.
복잡성에 영향을 미치는 다양한 요인:
- 응용 시나리오 (오프라인/실시간, 테이블/작업 수, 상위 응용 프로그램)
- 구성 요소 버전
- 지원 도구 및 보조금
미래 계획
우리의 미래 계획에는 다음이 포함됩니다:
- 나머지 응용 프로그램들을 클라우드로 계속 이전합니다.
- JuiceFS+OSS를 사용한 콜드/핫 계층 저장 전략 탐색. JuiceFS 파일은 OSS에서 완전히 분해되어 파일 수준 계층화를 구현하기 어렵습니다. 현재 접근 방식은 JuiceFS에서 콜드 데이터를 OSS로 이전하고, 아카이브 저장으로 설정하고, 사용에 영향을 미치지 않고 Hive 테이블 또는 파티션의 LOCATION을 수정합니다.
- 데이터 양이 증가하고 Redis 사용에 압력이 있다면 향후 TiKV 또는 다른 엔진으로 전환을 고려할 수 있습니다.
- EMR의 탄력적 컴퓨팅 인스턴스를 탐색하여 응용 프로그램 서비스 수준 계약을 충족하면서 사용량 비용을 줄입니다.
Source:
https://dzone.com/articles/migrating-hadoop-to-the-cloud-2x-storage-capacity