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

LY Corporation은 구 LINE과 구 Yahoo Japan의 HDFS 클러스터를 통합해 1EB를 넘는 데이터 플랫폼을 운영하고 있습니다. 두 플랫폼은 같은 HDFS를 사용했지만 Namespace 구성, 권한 관리, 사용자 접근 방식이 달라 운영·연계 설계에서 서로 다른 과제가 발생했습니다. 대규모 환경에서는 단순한 용량 증설보다 NameNode 메타데이터, 소규모 파일, Balancer 트래픽, 클라이언트 접근 경로를 함께 관리해야 한다는 것이 글의 결론입니다.

구 LINE과 구 Yahoo Japan의 운영 모델 차이

• 구 LINE

  • 여러 분석 환경을 통합한 Hadoop 3.x 기반 플랫폼을 구축했습니다.
  • 사용자가 HDFS 권한이나 Apache Ranger를 직접 다루지 않도록 웹 포털을 제공했습니다.
  • DB·테이블 중심의 데이터 카탈로그와 역할 기반 권한 신청·승인 구조를 사용했습니다.
  • BI, 리포팅, ETL 등 다양한 사용 방식을 지원했지만, 기존 클러스터를 Namespace 단위로 통합하면서 관리 복잡성이 증가했습니다.

• 구 Yahoo Japan

  • Hadoop 0.2.x 시절부터 제한된 목적의 대규모 분석 플랫폼을 운영했습니다.
  • 접근 인터페이스를 최소화하고 사용 방식에 일정한 제약을 둬 안정적인 운영과 사용자 지원을 우선했습니다.
  • 단일 Namespace가 커지면서 NameNode 확장에 한계가 생기자 RBF(Router-Based Federation)를 도입했습니다.
  • 권한 관리는 여전히 HDFS Permission(POSIX 유사 모델)을 사용해 현대적인 세밀한 권한 관리에는 제약이 있습니다.

• 같은 HDFS라도 데이터 위치, 사용자 접근 경로, 권한 변경의 영향 범위, 운영팀의 개입 방식이 크게 달랐습니다.

Namespace 구성과 접근 방식의 차이

• 두 플랫폼 모두 NameNode 병목을 피하기 위해 여러 Namespace로 HDFS를 분할했습니다.
• 각 Namespace는 2~4대의 NameNode로 이중화했지만, Namespace와 DataNode를 묶는 방식은 달랐습니다.

구 LINE: ViewFS와 DataNode 공유

• ViewFS를 사용해 클라이언트의 마운트 테이블에서 실제 Namespace와 NameNode를 결정했습니다.
• 유연하고 단순하지만 모든 사용자와 서비스에 올바른 마운트 설정을 배포·유지해야 합니다.
• 여러 Namespace가 DataNode를 공유해 자원 효율은 높지만 클러스터 구성과 운영이 복잡해졌습니다.
• 통합 과정에서 NameNode와 DataNode 버전이 혼재한 점도 운영 부담을 키웠습니다.

구 Yahoo Japan: RBF 기반 서버 측 라우팅

• 사용자는 Router에 접속하고, Router가 적절한 Namespace와 NameNode로 요청을 분배합니다.

• 클라이언트 설정을 단순화하고 여러 HDFS를 투명하게 연결하기 쉽습니다.

• 대신 Router 계층의 가용성, 확장성, 네트워크 도달성, 진입점 제어가 중요합니다.

• Observer NameNode를 활용해 읽기 부하도 분산했습니다.

• 이 차이는 플랫폼 간 데이터 복사에서도 중요합니다.

  • ViewFS 환경은 클라이언트 마운트 테이블과 설정 배포가 핵심입니다.
  • RBF 환경은 Router를 통한 접근 경로와 Router 계층의 안정성이 핵심입니다.

구 LINE에서 발생한 용량과 네트워크 문제

• 전사적 활용이 확대되면서 예상보다 빠르게 HDFS 용량이 부족해졌습니다.
• 신규 서버 납품 전까지 기존의 오래된 서버를 임시 재사용하고, 이후 서버를 교체하는 작업이 반복됐습니다.
• DataNode를 대규모로 추가하거나 제거하면 HDFS Balancer와 블록 재배치가 대량의 네트워크 트래픽을 발생시켰습니다.
• 따라서 서버 변경 작업은 HDFS뿐 아니라 네트워크 구성과 혼잡 가능성까지 고려해 네트워크팀과 협력해야 했습니다.

블록 증가와 NameNode 부하

• NameNode는 파일·디렉터리·블록 메타데이터를 메모리에 보관하므로 파일과 블록 수가 증가할수록 힙 사용량과 처리 부하가 커집니다.
• 힙이 지나치게 커지면 GC 시간이 길어지고 NameNode 응답 지연과 불안정성이 발생합니다.
• 특히 소규모 파일이 많은 Hive 테이블이 주요 원인이었습니다.
• 해결을 위해:
  • FSImage를 정기적으로 덤프해 Hive 테이블로 저장했습니다.
  • 사용자별 경로, 파일 수, 블록 수, 데이터량을 분석했습니다.
  • 삭제나 스키마 변경이 필요 없는 테이블을 우선 선정했습니다.
  • 파일 병합으로 파일 수와 블록 수를 줄였습니다.
• 파일 병합은 메타데이터 규모뿐 아니라 HDFS 요청 횟수도 줄여 잡 실행 속도와 NameNode 응답성을 개선했습니다.

Namespace별 부하 특성과 Balancer 조정

• 부하는 Namespace마다 다르게 나타났습니다.
• 임시 파일이 많은 Namespace에서는 평상시 부하는 낮지만 DataNode 추가 시 Balancer가 급격한 부하를 유발했습니다.
• Apache Spark의 스테이징 파일은 짧은 시간에 생성·삭제되며 NameNode의 write lock을 빈번하게 발생시켰습니다.
• Balancer의 블록 이동은 블록 정보 조회를 늘리고 read lock을 오래 유지해 파일 생성·삭제를 지연시킬 수 있었습니다.
• 초기에는 Balancer 병렬도를 높였지만, DataNode 디스크 여유와 서비스 영향을 고려해 병렬도를 낮추고 처리 시간과 안정성 사이의 균형을 맞췄습니다.

조직 통합과 플랫폼 연계

• 조직 통합 후에는 서로 다른 설계 철학의 데이터 플랫폼을 연결해야 했습니다.
• 주요 설계 과제는 다음과 같습니다.
  • 어느 플랫폼과 Namespace를 연결할 것인가
  • 권한 관리 단위를 어떻게 맞출 것인가
  • 어떤 접속 경로와 진입점을 사용할 것인가
  • DistCP 등으로 데이터를 어떤 경로로 전송할 것인가
  • 네트워크 도달성과 운영 책임을 어떻게 나눌 것인가
• 글의 후반부에서는 플랫폼 간 권한 모델 통합과 DistCP 기반 데이터 연계 방식을 다룰 예정이지만, 제공된 본문은 해당 설명이 시작되기 전에 끝나 있습니다.

대규모 HDFS를 운영할 때는 용량 증설만으로 문제를 해결하기 어렵습니다. 파일·블록 수를 지속적으로 관찰하고 소규모 파일을 줄이며, DataNode 변경과 Balancer의 네트워크 영향을 사전에 통제해야 합니다. 또한 플랫폼 통합 시에는 ViewFS와 RBF의 접근 모델 차이, 권한 체계, Router 및 클라이언트 설정까지 포함한 운영 경계를 함께 설계하는 것이 권장됩니다.