pile·
인프라 / DevOps·LY CorporationLY Corporation·

총 용량 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
LY Corporation 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  2. 인프라 / DevOps·vercel-blogVercel Blog·

    Vercel CLI 드라이런 배포로 실제 배포 전 구성 미리 확인하기

    Vercel CLI v54.17.2부터 vercel deploy --dry 명령으로 실제 파일 업로드 없이 배포 구성을 미리 검사할 수 있다. 프레임워크 감지 결과, 포함/제외 파일 목록, 디렉터리 크기 분포, 콘텐츠 해시까지 사전에 확인하고 나서 배포를 결정할 수 있어 의도치 않은 배포 실패를 예방한다.

    #deployment#ci-cd#vercel-cli+1