line·2026년 6월 23일·5분 읽기큐레이션 요약

총 용량 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 및 클라이언트 설정까지 포함한 운영 경계를 함께 설계하는 것이 권장됩니다.

원문 읽기(새 탭에서 열림)

data-platformapache-sparkhdfsapache-hadoop+3

toss·2026년 3월 25일원문

Metric Review, 실행을 이끌다 (새 탭에서 열림)

토스플레이스는 데이터 분석이 실질적인 제품 성장과 사업적 변화로 이어지지 못하는 문제를 해결하기 위해 '메트릭 리뷰(Metric Review)'를 도입했습니다. 메트릭 리뷰는 데이터 분석가가 단순한 리포트 작성자를 넘어 '메트릭 오너(Metric Owner)'로서 조직의 목표와 정렬된 지표를 관리하고, 가설 검증과 실행을 독려하는 핵심 운영 체계입니다. 이를 통해 전사 구성원이 데이터 리터러시를 갖추고 "어떤 지표를 움직일 것인가"를 고민하며 의사결정하는 구조를 확립했습니다. **메트릭 리뷰의 운영 원칙과 분석 사이클** * **OKR 기반의 메트릭 하이어라키(Metric Hierarchy):** 전사 목표인 Key Result를 각 팀의 하위 지표인 드라이버 메트릭(Driver Metric)으로 세분화하여, 무엇이 위협 요소이고 기회인지를 명확히 파악합니다. * **주간 단위의 분석 리듬:** 매주 지표를 검토함으로써 월간 단위로는 놓치기 쉬운 이상 신호를 조기에 포착하고, 수치 변화의 원인을 파고드는 과정에서 데이터 분석가의 도메인 지식을 강화합니다. * **실행으로 연결되는 분석 루프:** 단순 현황 공유에 그치지 않고 '지표 분석 → 가설 검증 → 인사이트 제시 → 실행 독려' 순으로 이어지는 사이클을 반복하며, 탐색적 데이터 분석(EDA)을 통해 도출된 가설을 실제 액션 아이템으로 전환합니다. **실제 사례로 증명된 메트릭 기반의 변화** * **전사 협업 구조 최적화 (Growth Tribe):** 지표를 중심으로 디자이너는 로그 설계 방향을 제안하고, 개발자는 분석에 용이한 서버 테이블 구조를 설계하는 등 전 직군이 목표 지표 달성을 위한 유기적인 협업 체계를 구축했습니다. * **군집 분석을 통한 맞춤형 전략 (POS Tribe):** 대리점별 확산 편차를 해결하기 위해 군집 분석을 수행하고, 설치 비율이 낮은 군집에는 온보딩 강화를, 높은 군집에는 사용성 개선을 제안하는 등 데이터 기반의 정교한 처방을 실행했습니다. * **예측 기반의 공급망 관리 (SCM):** 단말기 출고 및 설치 현황을 모니터링하여 재고 및 발주를 예측함으로써, 유통 구조의 최적화와 비용 절감이라는 실질적인 사업적 성과를 거두었습니다. **데이터 분석가가 지향해야 할 실무 방향** * 화려한 분석 기법보다는 '실행으로 연결되는 분석'에 가치를 두고, 문제를 구조화하며 가설을 검증 가능한 형태로 만드는 것이 중요합니다. * 데이터 분석가는 단순 지원 조직이 아니라 제품과 사업의 임팩트에 집중하는 주체로서, 액션 이후의 검증 지표까지 끝까지 추적하는 책무를 가져야 합니다. * 조직의 언어를 "무엇을 만들까"에서 "어떤 지표를 변화시킬까"로 바꾸는 것이 데이터 리터러시 향상의 본질이며, 이는 꾸준한 메트릭 리뷰를 통해 완성됩니다.

data-platform데이터베이스 설계data-analysisokrs+4

toss·2025년 10월 30일원문

토스 피플 : 데이터를 ‘이해하는’ 구조를 설계합니다 (새 탭에서 열림)

데이터의 품질은 사후 수습이 아닌 생성 단계의 초기 설계에서 결정되며, 특히 AI 시대에는 사람뿐만 아니라 기계도 데이터의 맥락을 완벽히 이해할 수 있는 의미 기반의 구조 설계가 필수적입니다. 토스는 이를 위해 데이터의 생성부터 활용까지 전 과정을 관리하는 'End-to-End 데이터 거버넌스'를 지향하며, 개발 속도를 저해하지 않으면서도 품질을 높이는 유연한 설계 표준을 구축하고 있습니다. 결과적으로 데이터 아키텍처는 단순한 규칙 강제가 아니라 비즈니스의 빠른 변화 속에서 데이터의 정합성을 유지하고 AI와 사람이 신뢰할 수 있는 기반을 만드는 핵심적인 역할을 수행합니다. **데이터 설계의 본질과 품질 관리의 전환** * 데이터의 품질은 분석 단계에서의 정제가 아니라, 데이터가 처음 만들어지는 순간의 설계(Design)에 의해 결정됩니다. * 서비스가 빠르게 변하는 플랫폼 환경에서는 데이터 수습에 에너지를 쏟는 사후 대응보다, 데이터가 생성되는 흐름부터 구조적으로 정리하는 사전 설계가 중요합니다. * '속도'와 '품질'은 대립하는 가치가 아니며, 설계 시 미래의 변화 가능성을 고려한 유연한 기준선을 마련함으로써 두 가치 사이의 균형을 잡아야 합니다. **AI가 이해할 수 있는 의미 중심의 데이터 구조** * 현대의 데이터 아키텍처는 사람뿐만 아니라 AI가 질문하고 분석하는 시대를 대비하여 기계가 읽을 수 있는(Machine-readable) 형태로 진화해야 합니다. * 단순한 메타데이터 관리를 넘어, 데이터 간의 의미 관계를 명확히 하는 '의미 기반 표준 사전'과 '온톨로지(Ontology)'를 도입하여 AI가 맥락을 놓치지 않도록 설계합니다. * 데이터 간의 연결 고리를 명확히 설계함으로써 AI가 스스로 의미를 추론하며 발생할 수 있는 해석 오류를 줄이고 데이터의 신뢰성을 극대화합니다. **실천적인 데이터 거버넌스와 아키텍트의 역할** * 효과적인 거버넌스는 규칙을 강제하는 것이 아니라, "표준을 따르는 것이 오히려 더 편하다"고 느낄 수 있도록 자연스러운 프로세스를 설계하는 것입니다. * 비즈니스의 빠른 사이클 속에서 모든 것을 완벽하게 설계하기보다, 현재 맥락에 맞으면서도 나중에 무리 없이 정리할 수 있는 '확장성 있는 여지'를 남겨두는 전략이 필요합니다. * 데이터 아키텍트는 거창한 담론에서 시작하는 것이 아니라, 작은 구조 하나를 더 낫게 만들고 싶어 하는 데이터 엔지니어와 분석가 모두가 도달할 수 있는 전문 영역입니다. 데이터 아키텍처는 단순히 테이블 명세서를 관리하는 일이 아니라 비즈니스의 복잡도를 구조로 풀어내는 일입니다. 고품질의 데이터를 유지하면서도 개발 속도를 잃지 않으려면, 초기 설계 단계에서부터 AI와 협업할 수 있는 표준 체계를 구축하고 이를 조직 내에서 자연스럽게 수용할 수 있는 '실현 가능한 거버넌스 모델'을 고민해 보는 것이 좋습니다.

data-platformdata-governancedata-architecturedata-modeling+4