총 용량 1EB 초과! 서로 역사가 다른 두 HDFS를 어떻게 연결할까? 데이터 플랫폼 연계 중 직면한 과제와 설계 결정
Summary
1엑사바이트(EB)급 데이터 공룡들의 만남, LINE과 Yahoo의 HDFS 통합기
서로 다른 철학을 가진 두 거대 데이터 플랫폼을 연결하기 위한 기술적 고군분투와 아키텍처 결정
이 아티클은 구 LINE과 구 Yahoo Japan의 합병으로 탄생한 LY Corporation이 서로 다른 역사와 기술 스택을 가진 두 HDFS 플랫폼을 어떻게 하나로 묶었는지 설명합니다. 총 용량 1EB라는 전례 없는 규모에서 발생하는 운영상의 난제들을 해결하고, 인증 및 권한 관리 체계를 통합하여 안전하고 효율적인 데이터 연계 인프라를 구축한 과정을 상세히 담고 있습니다.
- 011EB 이상의 초거대 HDFS 클러스터를 운영하며 겪은 NameNode 병목 및 스케일링 문제 해결
- 02ViewFS와 RBF로 나뉘었던 Namespace 해석 방식을 Cross-Realm Kerberos 인증으로 통합
- 03역할 기반(Table)과 경로 기반(Path) 권한 모델의 충돌을 해결하기 위한 '하이브리드 신규 영역' 전략
- 04DistCP 전송 시 네트워크 간섭을 방지하기 위한 전용 NodeLabel 및 ACL 설계
- 05msync 빈도 조정을 통한 Active NameNode의 부하 경감 및 읽기 성능 최적화
RECOMMENDATION
대규모 데이터 플랫폼 통합이나 이기종 하둡 클러스터 간의 거버넌스 수립이 고민인 인프라 엔지니어에게 실질적인 설계 가이드를 제공합니다.
The Problem
구 LINE과 구 Yahoo Japan의 합병 이후 총 용량 1EB가 넘는 거대 데이터 플랫폼을 연계해야 했으나, Namespace 관리 방식(ViewFS vs RBF)과 권한 모델(Table-based vs Path-based)의 차이로 인해 직접적인 데이터 상호 활용에 어려움이 있었습니다. 특히 대규모 HDFS 운영 중 발생하는 NameNode의 메모리 부하와 응답 지연 문제는 시스템 안정성을 위협하는 주요 과제였습니다.
The Solution
두 플랫폼 간의 인증을 위해 Cross-Realm Kerberos 체계를 구축하고, DistCP를 활용하여 클러스터 간 직접 데이터 전송 경로를 확보했습니다. Yahoo Japan 측에 LINE의 테이블 기반 권한 모델을 적용한 신규 영역을 생성하여 거버넌스를 일원화하고, 전용 NodeLabel 및 네트워크 ACL 설정을 통해 전송 트래픽을 분리 및 제어했습니다.
The Result
서로 다른 설계 철학을 가진 두 플랫폼 간의 물리적/논리적 연계 토대를 마련하여 데이터 활용 가치를 극대화했으며, msync 빈도 최적화 및 소규모 파일 병합을 통해 NameNode의 부하를 경감하고 시스템 응답 속도를 개선했습니다.
Trade-off
완전한 플랫폼 통합 대신 연계 방식을 선택함에 따라 사용자가 데이터를 새 영역으로 이관해야 하는 초기 비용이 발생했으며, WAN 대역폭 보호를 위해 데이터 전송 속도를 단계적으로 제한 운영해야 하는 제약이 존재합니다.
Key Concepts
More from 라인
View all posts from 라인
LLM Wiki: 코드 기준으로 자동 최신화되는 도메인 지식 SSOT 만들기
LLMSSOTGitHub Actions2일 전
일본어 상품 검색 정확도 높이기: Elasticsearch + Kuromoji에서 OpenSearch + Sudachi로
OpenSearchSudachiElasticsearch1주 전
보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계
LLMMulti-AgentRAG1주 전
개인 AI 활용의 다음 단계는 무엇인가 - LY Corporation에서 AIDD 워크숍을 통해 살펴본 AIDD 조직 도입의 조건
AIDDAI AgentDeveloper Productivity3주 전
Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기
GrafanaLLM AgentObservability1개월 전