총 용량 1EB 초과! 서로 역사가 다른 두 HDFS를 어떻게 연결할까? 데이터 플랫폼 연계 중 직면한 과제와 설계 결정

구 LINE과 구 Yahoo Japan의 HDFS 플랫폼(총 용량 1EB 이상)을 통합하면서 직면한 기술적 과제와 아키텍처 설계 결정을 정리한 글이다. 두 조직은 ViewFS(클라이언트 측 Namespace 관리)와 RBF(서버 측 Namespace 통합)로 완전히 다른 철학으로 HDFS를 구축했으며, NameNode 성능 최적화, Kerberos Cross-Realm 인증, DistCP 기반 데이터 연계를 설계해 이를 연결했다.

핵심 포인트

구 LINE은 ViewFS로 클라이언트 측에서 다중 Namespace를 관리하고 DB/테이블 단위 권한 관리를 사용했다
구 Yahoo Japan은 RBF로 서버 측에서 Namespace를 통합하고 HDFS Path 기반 권한 관리를 사용했다
Observer NameNode의 msync 호출 빈도 최적화가 라우터 증설보다 HDFS 지연의 근본 해결책이었다
권한 통합은 신규 영역 신설 방식을 선택해 기존 구조를 유지하면서 점진적 통합을 가능하게 했다
DistCP + Kerberos Cross-Realm + CapacityScheduler 전용 큐로 플랫폼 간 데이터 연계를 구성했다

상세 정리

플랫폼 차이: 구 LINE은 ViewFS(클라이언트 측 다중 Namespace)와 DB/테이블 권한 관리, 구 Yahoo Japan은 RBF(서버 측 Namespace 통합)와 HDFS Path 권한 관리로 구조가 이질적이었다
NameNode 성능 문제(LINE): 데이터 급증으로 NameNode 힙 메모리 부하가 증가하고, 파일 수 증가에 따른 성능 저하가 발생해 스몰 파일 병합으로 대응했다
HDFS 지연 문제(Yahoo Japan): 사용자 증가로 HDFS 지연이 발생했고, 라우터 증설보다 Observer NameNode의 msync 호출 빈도 최적화가 근본 해결책이었다
권한 통합 설계: 기존 구조 유지(호환성 높음) vs 신규 영역 신설(점진적 통합 가능) 두 안을 검토해 신규 영역 신설을 선택했다
데이터 연계: DistCP로 플랫폼 간 대용량 데이터를 복사하고, Kerberos Cross-Realm으로 상호 인증을 구성했다
접근 통제: CapacityScheduler 전용 큐로 연계 트래픽을 격리해 기존 워크로드에 영향을 최소화했다
네트워크 보안: OSI 계층 1~7 전반에서 보안 및 대역폭을 관리하고, 보안/법무/네트워크 담당자가 협력해 운영 흐름을 정립했다
교훈: 1EB 규모 분산 시스템 통합은 기술적 연결을 넘어 용량, 성능, 보안, 거버넌스를 총체적으로 설계해야 한다

왜 읽나대규모 HDFS 페더레이션 통합, NameNode 성능 최적화, 플랫폼 간 Kerberos 인증 설계를 다루는 데이터 인프라/플랫폼 엔지니어에게 실전 아키텍처 결정 참고자료다.

LY Corporation 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

총 용량 1EB 초과! 서로 역사가 다른 두 HDFS를 어떻게 연결할까? 데이터 플랫폼 연계 중 직면한 과제와 설계 결정

이 글과 비슷한

엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례