1EB HDFS 통합! 두 플랫폼 연계 과제와 해결책
구 LINE과 구 Yahoo Japan의 대규모 HDFS 클러스터를 통합하여 총 용량 1EB 초과 규모의 데이터 플랫폼을 운영하며 스케일링 제약과 운영 병목에 직면함
서로 다른 설계 철학과 운영 방식을 가진 두 HDFS 플랫폼을 데이터 상호 활용을 위해 연계하는 과정에서 권한 관리와 데이터 전송 경로 설계가 주요 과제로 부상함
구 LINE은 ViewFS 기반 클라이언트 해석, 구 Yahoo Japan은 RBF 기반 서버 해석 방식을 사용하며, 권한 관리 모델과 데이터 전송 방식에 대한 설계 결정이 필요했음
구 LINE과 구 Yahoo Japan HDFS 플랫폼의 근본적 차이
구 LINE과 구 Yahoo Japan은 Hadoop 운영 방식과 서비스 범위에서 큰 차이를 보였으며, 이는 HDFS 클러스터의 Namespace 관리 방식과 권한 관리 철학에 영향을 미쳤습니다.
구 LINE: ViewFS 기반 클라이언트 해석 방식을 채택하여 유연성을 확보했으나, 클라이언트 설정 관리의 복잡성이 운영 과제로 남았습니다. 모든 Namespace에서 DataNode를 공유하는 구성은 자원 효율을 높였지만, 버전 혼재로 인한 복잡성을 야기했습니다.
구 Yahoo Japan: RBF(Router-Based Federation) 기반 서버 해석 방식을 사용하여 여러 HDFS를 투명하게 다루기 용이했으나, 라우터 계층의 가용성과 스케일링이 중요해졌습니다. HDFS Permission(POSIX 유사 권한 관리)을 사용하여 현대적 데이터 관리 요구사항과의 차이가 제약으로 작용했습니다.
이러한 차이는 단순히 HDFS 내부 구성뿐 아니라, 플랫폼 간 연계 시 접근 경로, 권한 관리 단위, 데이터 전송 방식 설계에 직접적인 영향을 미쳤습니다.
대규모 HDFS 운영 시 직면한 스케일링 및 성능 병목
두 회사 모두 대규모 HDFS 운영 과정에서 스케일링 제약과 성능 병목 현상에 직면했습니다.
구 LINE: HDFS 용량 부족과 블록 수 증가로 인한 NameNode 힙 사용량 증가 및 응답 속도 저하 문제를 겪었습니다. 이를 해결하기 위해 스몰 파일 최적화 및 Namespace별 부하 특성 분석을 통해 대응했습니다. 특히 임시 파일이 많은 Namespace에서는 빈번한 메타데이터 업데이트로 인한 쓰기 락 경합이 문제가 되었습니다.
구 Yahoo Japan: 사용자 증가에 따른 HDFS 전체 지연이 두드러졌으며, 초기에는 라우터 계층 병목으로 추정했으나 실제 원인은 Observer NameNode로의 과도한 msync 요청이었습니다. Active NameNode 부하 분석을 통해 msync 빈도를 재검토하여 지연 시간을 개선했습니다.
이 경험들은 단순히 스케일 아웃만으로는 해결할 수 없으며, 시스템 내부 의존 관계와 부하 구조 파악의 중요성을 시사합니다.
플랫폼 간 권한 관리 모델 통합의 어려움
조직 통합 후 두 HDFS 플랫폼 간 데이터 연계를 위해 권한 관리 모델 통합은 핵심 과제였습니다. 각 플랫폼은 데이터 관리 및 권한 관리의 전제가 달랐기 때문입니다.
구 LINE: DB/테이블 단위의 역할 기반 권한 관리를 통해 사용 목적과 책임 범위를 명확히 했습니다. 이는 거버넌스 운영에 유리한 모델이었습니다.
구 Yahoo Japan: HDFS Path 단위의 권한 관리를 사용해 유연성을 확보했지만, 관리 대상 증가 시 복잡성이 커지는 단점이 있었습니다.
최종적으로 구 Yahoo Japan 측에 테이블 기반 관리 모델을 위한 새 영역을 신설하는 방식을 채택했습니다. 이는 기존 운영에 미치는 영향을 최소화하면서 거버넌스 운영을 단계적으로 통일하고, 플랫폼 간 데이터 연계 시에도 일관된 권한 관리 사고방식을 적용하기 위한 결정이었습니다.
DistCP를 활용한 플랫폼 간 데이터 연계 아키텍처
플랫폼 간 데이터 연계를 위해 DistCP(Distributed Copy)를 활용한 병렬 분산 복사 방식을 검토했습니다. 이 과정에서 인증, 인가, 운영 통제, 기술적 측면에서의 정리가 필요했습니다.
인증: 각 클러스터의 Kerberos KDC를 활용하고, Cross-Realm 구성을 통해 상호 신뢰 관계를 구축했습니다. DistCP 전용 계정을 동일하게 맞춰 계정 이름 불일치 문제를 줄였습니다.
인가: DistCP 전용 큐를 마련하고 해당 큐에 잡을 제출할 수 있는 계정을 제한했습니다. auth_to_local 설정을 통해 계정 이름을 매칭했습니다.
기술적 측면: 전용 NodeLabel을 준비하여 클러스터 간 통신 경로를 분리하고, OSI 7계층에서 HDFS 최소 블록 크기 차이 등 오류 유발 지점을 맞추는 데 주의했습니다. 또한 WAN 회선 부하를 고려하여 대역폭 관리를 단계적으로 진행했습니다.
이러한 종합적인 설계를 통해 단순한 데이터 전송을 넘어 실제 운영 가능한 아키텍처를 구축했습니다.
대규모 데이터 플랫폼 운영의 통합적 관점
두 회사의 HDFS 플랫폼 운영 경험은 규모가 커지면서 발생하는 과제에 대응하기 위해 Hadoop 내부뿐만 아니라 전체 시스템을 아우르는 관점이 중요함을 보여줍니다.
구 LINE: 용량, NameNode 부하, 블록 수 증가, Namespace별 부하 특성 변화 등 예측 불가능한 변화에 대응하며 물리 서버, 네트워크 등 하위 인프라 영향까지 고려하는 운영이 필요했습니다.
구 Yahoo Japan: 라우터 병목으로 추정되었던 문제가 실제로는 Active NameNode의 msync 부하에서 비롯된 것처럼, 시스템 내부 의존 관계와 부하 구조를 파악하는 것이 근본적인 해결책을 찾는 데 중요했습니다.
결론적으로, 대규모 데이터 플랫폼 운영은 단순히 기술적 구성 요소의 관리가 아니라 사용자 이용 형태, 운영 책임 경계, 데이터 거버넌스 등 복합적인 요소를 고려한 통합적 접근이 필수적입니다.
