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

10 hours ago 5

들어가며

안녕하세요. LY Corporation에서 대규모 데이터 플랫폼 운영을 담당하고 있는 Hirayama, Numata, Ogasawara, Ogawa입니다.

LY Corporation은 검색·포털과 전자상거래, 메신저, 광고 등 폭넓은 서비스를 지원하기 위해 대규모 데이터 플랫폼을 운영하고 있습니다. 그 핵심인 HDFS(Hadoop Distributed File System)는 기존에 별도로 운영하던 구 LINE Corporation(이하 구 LINE)과 구 Yahoo Japan Corporation(이하 구 Yahoo Japan)의 주요 클러스터를 합쳐 총 용량이 1엑사바이트(Exabyte, EB)를 넘습니다.

이러한 규모의 HDFS를 운영하면서 저희는 크게 두 가지 주제와 마주했습니다.

첫 번째는 HDFS가 중심인 대규모 데이터 플랫폼을 운영하는 관점에서의 과제입니다. 데이터가 증가하면서 발생한 스케일링 제약이나 운영 과정에서 발생한 병목에 어떻게 대응해 왔는지, 그 과정에서 플랫폼을 어떻게 구성하고 사용자의 이용 형태가 어떻게 형성됐는지 정리합니다.

두 번째는 조직 통합에 따른 데이터 플랫폼 간 연계입니다. 서로 다른 설계 철학을 기반으로 구축한 각 데이터 플랫폼을 어떻게 연결해서 데이터를 상호 간에 활용할 수 있게 만들 것인지가 문제였습니다.

이 두 가지는 언뜻 별개의 문제처럼 보이지만, 둘 모두 서로 다른 플랫폼이 구축된 배경과 구성, 이용 형태를 고려하면서 실제 운영 환경을 견딜 수 있도록 설계하고 대응하며 쌓아온 이야기입니다. 규모가 커지면서 발생한 첫 번째 문제에서는 이러한 차이가 용량 관리와 NameNode 부하, 네트워크 영향 등으로 나타났습니다. 조직 통합에 따른 연계에서는 연결 대상과 권한 관리 단위, 데이터 전송 경로를 어떻게 설계할지가 과제로 드러났습니다.

글 전반부에서는 구 LINE과 구 Yahoo Japan에서 각각 대규모 데이터 플랫폼을 어떻게 구성했고 이용 형태가 어떻게 달랐는지 차이를 살펴보고 운영 과정에서 마주친 과제를 소개합니다. 후반부에서는 양측 데이터 플랫폼을 어떻게 연계했는지 설명합니다.

목차는 다음과 같습니다.

파트 1. 구 LINE과 구 Yahoo Japan에서 HDFS 플랫폼을 구성 및 이용해 온 형태와 운영 과제
파트 2. 조직 통합에 따른 데이터 플랫폼 간 연계
향후 전망

파트 1. 구 LINE과 구 Yahoo Japan에서 HDFS 플랫폼을 구성 및 이용해 온 형태와 운영 과제

이 파트에서는 먼저 구 LINE과 구 Yahoo Japan에서 각각 HDFS 플랫폼을 이용 및 운영해 온 모델의 차이를 정리하고, 그 배경에 자리한 HDFS 구성의 차이를 살펴봅니다. 이후 대규모 플랫폼을 운영하면서 실제로 직면한 과제와 대응 방법을 소개하겠습니다.

1.1. 이용 및 운영해 온 모델의 차이

구 LINE과 구 Yahoo Japan은 Apache Hadoop을 운영해 온 방식과 제공해 온 서비스의 폭이 서로 다른 회사였습니다. 따라서 양사에서 운영하는 클러스터는 데이터 접근, 권한 관리, 운영 방식 관점에서 데이터 플랫폼 전체의 설계 철학과 사용 방식에 큰 차이가 있었습니다.

구 LINE에서는 여러 개의 대규모 분석 환경을 오랜 기간 운영해 왔으며, 현재 사용 중인 환경은 이들을 통합하기 위해 Hadoop 3.x 버전 시대에 구축한 것입니다. 초기부터 부문을 넘나드는 다양한 데이터 활용 요구에 대응하고, 새로운 환경으로 원활히 이전하는 것이 미션이었습니다. 따라서 HDFS 권한이나 Apache Ranger를 사용자가 직접 다루게 하는 대신 권한과 데이터 카탈로그를 관리하는 웹 포털을 준비했습니다. 이를 통해 사용자는 Hadoop 내부의 세부 구조를 알지 않고도 DB와 테이블을 중심으로 한 관리 단위 아래에서 권한 신청과 승인을 통합한 역할 기반 구조를 통해 데이터를 안전하게 활용할 수 있었습니다. 이와 동시에 다양한 사용 방식을 지원하기 위한 BI와 리포팅 도구나 ETL 배치 파이프라인 등 여러 시스템도 준비했는데요. 다양한 사용 방식을 지원하는 동시에 기존 클러스터를 매끄럽게 통합하기 위해 Namespace 단위로 그대로 가져온 결과 클러스터 관리가 복잡하다는 문제가 운영 과제로 남았습니다.

구 Yahoo Japan에서는 Hadoop 0.2.x 버전 시대부터 제한된 목적의 대규모 분석을 시작으로 분석 플랫폼을 구축해 활용해 왔습니다. 이후 신규 유스케이스를 수용하고 개별 운영되던 Hadoop 클러스터를 집약해 이전하면서 전사적으로 폭넓게 활용되는 플랫폼으로 발전했고, 안정적으로 운영하기 쉬운 구성으로 정리돼 왔습니다. 사용자가 Hadoop 환경에 접근하기 위한 인터페이스는 필요한 최소한으로 정리돼 있었고, 접근 방식에는 일정한 제약이 있었지만, 진입을 제한함으로써 시스템을 안정적으로 제공하고 사용자를 지원하기 쉽게 구성돼 있었습니다.

구 Yahoo Japan에서는 오랜 기간 운영해 온 단일 HDFS Namespace의 규모가 커지면서 NameNode의 스케일링이 과제가 되었고, 이후 RBF(router-based federation)를 도입해 Namespace를 분할해 다룰 수 있는 구성으로 전환했습니다. 권한 관리 또한 역사적 이유로 현재도 HDFS Permission(POSIX 유사 권한 관리)을 이용하고 있는데요. 이 때문에 현대적 데이터 관리에서 요구하는 유연한 권한 관리와 차이가 발생해 제약으로 작용하고 있습니다.

이와 같은 두 데이터 플랫폼의 차이는 일상 운영 업무에도 영향을 미쳤습니다. 구 LINE에서는 Hadoop 운영 팀이 직접 관리하지 않는 시스템까지 포함해 사용 경로와 권한 신청 구조를 고려하면서 운영을 설계해야 했습니다. 반면 구 Yahoo Japan에서는 저장 위치와 권한 설정을 중심으로 관리하기 쉽게 설계돼 있습니다. 같은 HDFS를 사용하더라도 데이터를 어디에 두는지, 누가 그 데이터를 다루는지, 권한을 어떻게 정비하는지, 설정이나 정책 변경이 누구에게 어떻게 어떤 영향을 주는지와 같은 관점을 정리하는 방식이 서로 달랐습니다.

아래는 두 환경의 이용 및 운영 모델 차이를 정리한 표입니다. 구 LINE과 구 Yahoo Japan은 플랫폼의 구축 배경과, 사용 경로, 권한 관리 및 변경 시 영향 범위에서 다음과 같은 차이가 있었습니다.

관점구 LINE구 Yahoo Japan

발전 경위	여러 분석 환경을 통합하는 플랫폼으로 구축	제한된 용도의 대규모 분석에서 전사 플랫폼으로 발전
사용 경로	포털, 데이터 카탈로그, BI, ETL 등 다수 경로 제공	접근 경로를 좁혀 이용·지원 표준화
권한 관리	HDFS 자체를 의식할 필요 없는 역할 기반 신청·승인 흐름	HDFS Permission을 기준으로 관리
권한 관리 단위	DB/테이블	HDFS Path
Namespace 구성	기존 환경의 Namespace를 가져오면서 통합	단일 Namespace에서 RBF로 분할 구성으로 전환
변경 시 고려 사항	사용 경로와 연계 시스템에 대한 영향 확인 필요	플랫폼 측에서 영향 범위 정리 용이

1.2. HDFS 구성의 차이

구 LINE과 구 Yahoo Japan은 오랜 기간 Hadoop 클러스터를 운영해 왔지만, 발전 경로와 설계 철학에는 많은 차이가 있었습니다. 특히 기술 측면에서 큰 차이는 HDFS 클러스터에서 Namespace를 다루는 방식입니다.

HDFS는 구조의 특성상 규모가 커질수록 파일 시스템의 메타데이터를 관리하는 NameNode가 병목이 되기 쉽습니다. 그래서 구 LINE과 구 Yahoo Japan 모두 스케일링을 위해 Namespace를 여러 개로 분할한 구성을 채택했습니다. 즉, 두 환경 모두 스토리지 전체가 여러 Namespace로 나뉘며, 각 Namespace를 관리하는 NameNode가 2~4대로 이중화돼 있다는 점은 같았습니다.

데이터가 여러 Namespace에 걸쳐 저장되기 때문에 HDFS에 접근할 때에는 대상 데이터가 어느 Namespace에 저장되어 있는지, 어느 NameNode로 연결해야 하는지를 판단할 필요가 있습니다. 또한 실제 데이터를 저장하는 DataNode를 어떤 단위로 배치하고 공유할지도 판단해야 합니다. 이 여러 Namespace를 어떻게 묶고,이중화를 어떻게 구성하며, 실제 데이터가 저장되는 DataNode를 어떤 단위로 보유할지가 구 LINE과 구 Yahoo Japan의 큰 차이입니다.

구 LINE에서는 ViewFS를 사용해 클라이언트 측에서 여러 Namespace를 다루는 구성을 채택했습니다. 이 방식에서는 클라이언트에 설정된 마운트 테이블을 기반으로 프로그램이 실제 경로를 변환해 Namespace를 판별하고, 설정에 따라 적절한 NameNode에 접근합니다. 단순하고 유연한 방식이지만, 각 사용자 측 클라이언트 설정의 정합성을 유지해야 하므로 사내에 다수 존재하는 서비스와 사용자 측에 설정을 반영하는 것이 운영할 때 중요하게 고려해야 할 사항이 됩니다.

또한 구 LINE의 클러스터는 모든 Namespace에서 DataNode를 공유하는 구성입니다. 이 구성은 자원 효율을 높이기 쉽고 스케일 설계도 용이한 반면, 클러스터 구성이 복잡해져 운영할 때 고려해야 할 관점과 수고가 늘어나는 요인이 되기도 합니다. 더불어 사내에 여러 개 존재했던 데이터 분석 플랫폼을 통합해 구축한 경위 때문에 하나의 큰 클러스터 안에서 NameNode와 DataNode 버전이 혼재한다는 점도 상황을 더 복잡하게 만들었습니다.

반면 구 Yahoo Japan에서는 RBF를 이용해 여러 Namespace를 서버 측에서 묶는 구성을 채택했습니다. 이 구성에서는 사용자가 라우터에 접근하면 라우터가 적절한 NameNode로 요청을 분배합니다. 이 방식은 여러 HDFS를 투명하게 다루기 쉬운 반면 라우터 계층 자체의 가용성과 스케일 설계가 중요해집니다. 또한 NameNode 구성에는 Observer NameNode가 포함되어 읽기 부하를 분산하는 설계도 반영되어 있습니다(RBF 도입 시의 자세한 내용은 HDFS Migration from 2.7 to 3.3 and enabling Router Based Federation (RBF) in production 발표 자료를 참고해 주세요).

이 차이는 단순한 HDFS 내부 구성 차이에 그치지 않습니다. 후술할 플랫폼 간 연계에서는 어느 플랫폼으로, 어느 진입점에서, 어떤 설정의 클라이언트로 접근할지가 중요해집니다. 구 LINE처럼 ViewFS로 여러 Namespace를 묶는 경우 클라이언트 측의 마운트 테이블이 올바르게 배포되지 않으면 기대한 Namespace에 도달하지 못합니다. 반면 구 Yahoo Japan처럼 RBF로 여러 Namespace를 묶는 경우 사용자나 작업은 라우터를 진입점으로 접근하므로 라우터 계층의 가용성, 스케일, 네트워크 도달성, 진입점으로서의 제어가 중요해집니다.

이 차이는 파트 2에서 설명할 DistCP(Distributed Copy)를 이용한 플랫폼 간 연계나 접속 경로·권한·운영 흐름 정리에도 영향을 미칩니다.

1.3. 대규모로 운영하면서 직면한 과제

저희는 이처럼 규모가 크면서 복잡한 HDFS 플랫폼을 운영하면서 여러 과제에 직면했습니다. 구 LINE과 구 Yahoo Japan에서 각각 어떤 과제에 직면했고 이를 해결하기 위해 어떻게 접근했는지 살펴보겠습니다.

[구 LINE] 성장하면서 HDFS 규모가 커지며 직면한 다양한 과제

구 LINE의 Hadoop 클러스터는 기존에 존재하던 두 개의 Hadoop 클러스터를 통합해 전사적으로 데이터를 활용하기 위해 구축한 클러스터입니다. 기존 클러스터를 그대로 도입했기 때문에 초기 단계에서 급격히 증가한 케이스는 아니었지만 전사적으로 확산되면서 클러스터 운영 시작 초기부터 이용량이 예상을 웃도며 시기에 따라 여러 자원 부족에 대응해야 했습니다.

초기 단계에서 문제가 된 것은 HDFS 용량의 급속한 압박입니다. 수요 예측에 따라 서버를 증설했지만 예상보다 증가폭이 커서 새로운 서버 납품보다 HDFS 용량이 먼저 부족해질 가능성이 커져 오래된 서버를 일시적으로 재사용하고 이후 새 서버로 교체하는 등 잦은 서버 추가 및 철거 작업이 발생했습니다.

그런데 클러스터 규모가 컸기 때문에 새로운 서버 추가나 일시 추가한 서버의 일괄 철거 등으로 노드 수가 급격히 증감하면 블록 재배치나 HDFS Balancer 때문에 매우 큰 트래픽이 발생합니다. 이 때문에 네트워크 쪽에 혼잡이 발생할 수 있어 특히 운영 초기에는 네트워크 팀과 연계해 네트워크 구성도 고려하며 작업을 진행해야 했습니다.

용량 이슈가 진정된 후 문제된 것은 HDFS 블록 수가 증가하면서 NameNode 힙 사용량이 증가하는 것이었습니다. NameNode는 Namespace 전체의 파일, 디렉터리, 블록 등의 메타데이터를 메모리에서 관리합니다. 따라서 파일 및 블록 수가 증가하면 NameNode 힙 사용량과 처리 부하가 증가합니다. 서버 한 대에 탑재할 수 있는 메모리에는 한계가 있고 힙이 커지면 GC에 걸리는 시간도 길어져 NameNode 동작이 느려지고 불안정해집니다.

이를 해결하기 위해 블록이 많은 테이블을 선별해 사용자와 협력해 이를 줄여 나갔습니다. HDFS의 FSImage를 정기적으로 덤프해 Hive 테이블로 저장하고 있기 때문에 이를 분석하면 어떤 사용자가 어떤 경로에 얼마나 많은 파일 수, 블록 수, 데이터량을 보유하고 있는지 알 수 있습니다. 대상으로는 스몰 파일이 많은 테이블 중 파일 병합만으로 블록 수를 크게 줄일 수 있는 항목으로 한정했습니다. 이를 통해 데이터 삭제 가능 여부나 파티션 설계를 포함한 스키마 변경 같은 판단 없이도 비교적 단순한 조작으로 신속하게 대응할 수 있었습니다.

블록 수 증가에 따른 NameNode 힙 사용량 증가 외에도 NameNode 응답 속도 저하도 종종 발생했습니다. 특히 HDFS의 테이블 데이터 대부분이 저장된 Namespace에서는 항상 대량의 읽기와 쓰기가 발생해 NameNode 응답 속도가 만성적으로 느려지기 쉬웠으며, 이는 Hadoop에서 실행되는 잡 실행 속도에도 영향을 미쳤습니다. 이 문제 역시 앞서 언급한 스몰 파일이 많은 테이블의 파일을 병합하는 게 일정한 효과를 보였습니다. 파일 수와 블록 수를 줄이면 NameNode가 처리하는 메타데이터 양뿐만 아니라 HDFS에 대한 조작 요청 수도 줄어들어 효과가 있었습니다.

한편 부하가 나타나는 양상은 Namespace마다 달랐습니다. 예를 들어 임시 파일이 많이 저장되는 Namespace에서는 평상시 NameNode 부하는 비교적 낮지만 신규 DataNode 추가 시 HDFS Balancer로 인해 급격히 부하가 증가하는 경우가 있었습니다. 이 Namespace에서는 Apache Spark의 스테이징 파일 생성·삭제가 짧은 시간에 빈번히 발생해 NameNode에서 쓰기 락(write lock)이 필요한 메타데이터 업데이트가 지속적으로 발생했습니다. 반면 HDFS Balancer로 인한 블록 이동 시에는 블록 정보 참조 처리가 증가해 읽기 락(read lock)이 길게 유지되는 경우가 있었습니다. 그 결과 파일 생성 및 삭제 등의 업데이트 처리가 지연되어 HDFS 응답 지연으로 이어지기 쉬운 상태였습니다. 초기에는 HDFS Balancer의 병렬도를 높게 설정했으나 DataNode의 디스크 사용 여유를 고려해 지장이 없는 범위까지 병렬도를 낮추고 처리 시간과 클러스터에 미치는 영향의 균형을 맞추는 방식으로 대응했습니다.

지금까지 클러스터가 성장하면서 발생한 과제 중에는 되돌아보면 더 정확한 수요 예측이나 사전 대비로 효율적으로 대응할 수 있었던 과제가 있었을지도 모릅니다. 하지만 실제 운영에서는 이용이 확대되면서 데이터양과 블록 수가 급증하고, DataNode 추가 및 철거에 따라 대량 트래픽이 발생하고, Namespace마다 발생한 부하의 특성이 달라지는 등 예측할 수 없는 변화와 과제에 지속적으로 대응할 필요가 있었습니다. 그 과정에서 중요했던 것은 HDFS의 용량이나 설정만 보는 것이 아니라 클러스터가 실제 어떻게 사용되고 있는지, Hadoop 각 컴포넌트가 내부에서 어떻게 작동하는지, 물리 서버나 네트워크 등의 하위 인프라에 어떤 영향을 주는지를 포함해 파악하는 것이었습니다. 대규모 Hadoop 클러스터 운영에서는 Hadoop 내부뿐만 아니라 전체를 아우르는 관점이 중요했습니다.

[구 Yahoo Japan] 사용자 증가에 따른 HDFS 지연

구 Yahoo Japan의 데이터 플랫폼에서는 데이터량과 사용자 증가에 따라 HDFS 전체 지연이 두드러지기 시작했습니다. 특히 HDFS에 대한 조작 요청 수가 매년 증가하고 있어 클라이언트에서 체감하는 응답 지연도 무시할 수 없는 상태가 되었습니다.

다음 그래프는 2020년부터 2025년까지 HDFS에 대한 조작 요청 수의 추이를 나타냅니다. 보기 쉽게 월별 평균으로 집계했는데 시간의 흐름에 따라 요청 수가 증가하고 있음을 알 수 있습니다.

초기에는 라우터 계층이 병목이라고 생각했습니다. HDFS에서는 쓰기 요청이 Active NameNode에 집중됩니다. 반면 읽기 요청은 Observer NameNode로 분산할 수 있습니다. 그러나 Active NameNode의 부하가 높은 상태에서는 라우터 측에서도 요청 처리 지연이 발생해 요청 대기열인 CallQueue가 막히기 쉽습니다.

따라서 라우터를 늘려 요청 처리를 분산하면 쓰기 요청이 일시적으로 머물더라도 읽기 요청을 Observer NameNode로 유도하기 쉬워 전체 처리량 개선에 도움이 될 것이라고 생각했습니다. 이에 실제로 라우터를 확충한 결과 CallQueue의 정체는 어느 정도 분산되어 일정 부분 개선됐지만, 기대만큼 큰 효과는 얻지 못했습니다.

이유를 조사해 보니 Observer NameNode를 사용하는 클라이언트에서 msync 요청이 대량으로 발생하고 있는 것을 확인했습니다. msync는 Observer NameNode에서 읽기 전에 클라이언트가 Active NameNode 쪽의 갱신 상황을 확인하기 위해 호출하는 처리입니다. 사용자가 증가하면서 이 처리의 실행 횟수가 늘어나 Active NameNode에 부하를 가하고 있었습니다. 즉 읽기 요청 처리 자체는 결국 Active NameNode에 대한 msync 대기의 영향을 받고 있었기에 라우터를 늘려도 근본적인 병목은 해소되지 않았던 것입니다.

이에 저희는 Active NameNode 측의 부하를 분석했습니다. 그 결과 msync 빈도가 지나치게 높다는 점을 파악해 읽기 결과에 영향을 주지 않는 범위 내에서 실행 빈도를 재검토했습니다. 이 대응으로 Active NameNode의 부하가 크게 경감되어 결과적으로 HDFS 전체의 지연 시간도 개선됐습니다.

이 사례에서 얻은 교훈은 '어디에서 처리 대기가 발생하고 있는가'를 올바르게 분석하는 게 중요하다는 것입니다. 표면적으로는 라우터의 CallQueue 정체가 문제로 보였지만 실제로는 그 배후에 있는 Active NameNode의 부하가 본질적인 병목이었습니다. 이는 단순한 스케일 아웃만으로 해결할 수 없었기에 시스템 내부의 의존 관계와 부하 구조를 파악한 후 대책을 세우는 게 중요했습니다.

1.4. 정리

구 LINE과 구 Yahoo Japan의 HDFS 플랫폼은 모두 대규모 데이터 활용을 지원하기 위해 발전해 왔습니다. 그러나 Namespace를 묶는 방식, 사용자에게 보여주는 방식, 권한 관리 단위, 운영 과정에서의 책임 경계에는 큰 차이가 있었습니다.

구 LINE은 ViewFS를 전제로 클라이언트 측에서 Namespace를 해석하는 구성인 반면 구 Yahoo Japan은 RBF를 전제로 Router 측에서 Namespace를 해석하는 구성이었습니다. 또한 구 LINE은 DB/테이블 단위를 중심으로 한 역할 기반 권한 관리가 준비돼 있었던 반면, 구 Yahoo Japan은 HDFS Path 단위를 중심으로 한 권한 관리를 오랜 기간 사용해 왔습니다.

이 때문에 조직 통합 후 양 플랫폼을 연계하려면 단순히 네트워크를 연결해 데이터를 전송할 수 있게 하는 것만으로는 충분하지 않았습니다. 어느 진입점에서 HDFS에 접근할지, 어떤 단위로 권한을 관리할지, 누가 어느 경로로 데이터를 전송할 수 있게 할지를 양측 전제에 맞춰 정리할 필요가 있었습니다.

파트 1에서 본 차이는 파트 2에서 다룰 플랫폼 간 연계 설계에 다음과 같은 영향을 미칩니다.

파트 1에서 드러난 차이파트 2에서의 설계 과제

ViewFS/RBF 등 Namespace 해석 방식과 HDFS 접근 경로의 차이	DistCP 시 접속 대상, 경로 해석, 클라이언트 설정을 어떻게 정리할지
DB/테이블 단위·HDFS Path 단위라는 권한 관리 단위 차이	전송 후 데이터를 어떤 단위로 권한 관리 및 재점검할지
사용 경로와 주변 시스템의 차이	사용자에게 플랫폼 차이를 어디까지 의식하게 할지
운영 과정에서의 책임 경계와 변경 시 영향 범위의 차이	보안, 네트워크, 법무를 포함한 운영 흐름을 어떻게 설계할지

파트 2에서는 이와 같이 전제가 다른 두 데이터 플랫폼을 안전하고 실제 운영 가능한 형태로 연계하기 위해 권한 관리 모델과 데이터 전송 방식을 어떻게 설계했는지 살펴보겠습니다.

파트 2. 조직 통합에 따른 데이터 플랫폼 간 연계

2.1. 조직이 통합되면서 드러난 데이터 플랫폼 간 연계의 과제

조직 통합과 함께 각 플랫폼에서 축적해 온 데이터를 상호 활용해 보다 큰 가치를 창출하는 것이 중요해졌습니다. 통합 데이터 플랫폼을 새로 구축하는 옵션도 있었지만 기존 데이터 플랫폼이 모두 대규모로 운영되고 있었기에 전면 통합은 중장기 관점에서 다뤄야 할 과제였습니다. 따라서 우선 각 플랫폼의 특성을 살리면서 실무에서 필요한 범위에서 연계할 수 있는 상태를 갖추는 것을 목표로 했습니다.

각 플랫폼은 지금까지 서로 다른 상황을 바탕으로 설계 및 운영돼 왔기 때문에 단순히 둘을 연결한다고 플랫폼을 넘나드는 데이터 활용이 실현되지는 않습니다. 데이터 배치와 이용 경로, 권한 관리, 운영 규칙 등의 차이를 고려해 안전과 편의를 모두 갖출 필요가 있습니다.

이때 HDFS 중심의 데이터 플랫폼 간 연계 관점에서 크게 두 가지 과제가 있었습니다.

첫 번째는 ‘서로 다른 플랫폼 간에 어떻게 안전하게 데이터를 전송하고 관리할 수 있는가’입니다.

각 플랫폼은 서로 권한 관리 체계가 달라 권한을 단순 동기화하기는 어렵습니다. 따라서 사용자가 데이터를 안전하게 활용할 수 있게 제공하려면 구 LINE과 구 Yahoo Japan 각 플랫폼에 저장된 데이터에 대해 각 환경의 구조에 맞춰 권한 그룹을 관리하고 운영해야 했습니다.

각 플랫폼은 서로 발전해 온 배경이 달라 권한 관리 철학과 설계의 많은 부분이 달랐습니다. 따라서 양 플랫폼을 넘나들며 데이터를 연계하고 활용하려면 사용자는 양측 권한 관리 및 운영 방식을 모두 이해하고 개별적으로 대응해야 합니다. 이렇게 하면 사용자와 운영자 모두에게 큰 비용이 듭니다. 데이터 상호 활용 촉진과 안전성 확보라는 관점에서 권한 관리 비용을 어떻게 낮출지는 피할 수 없는 과제였습니다.

두 번째는 플랫폼 간 데이터를 연계하는 방식의 효율화입니다.

플랫폼 간 직접 데이터를 주고받을 수 없는 상태라면 데이터를 연계할 때마다 중간 수단이나 여러 단계의 절차가 필요합니다. 이는 처리 시간뿐 아니라 운영 부담과 비용도 증가시킵니다. 또한 이와 같이 일상적으로 데이터를 연계할 때마다 개별 대응이 필요해지면 데이터 플랫폼 간 연계 자체가 데이터 활용의 병목이 됩니다. 전송 대상을 적절히 리뷰한 뒤 데이터 준비와 전송 비용을 낮추는 것은 안전성을 유지하면서 데이터 상호 활용을 추진하는 데 중요한 포인트였습니다.

물론 위 두 과제를 통합 데이터 플랫폼을 구축해서 해결할 수도 있습니다. 그러나 이 정도 규모의 플랫폼을 서로 다른 운영 문화와 설계 철학을 고려해 완전하고 안전하게 통합하려면 큰 비용과 긴 시간이 필요할 것입니다. 따라서 이번 작업에서는 플랫폼을 하나로 합치는 것을 우선 목표로 삼기보다는, 적절한 권한 관리 하에 운영할 수 있게 만드는 것과 플랫폼 간 데이터를 연계할 수 있게 만드는 것을 함께 준비하는 방향을 택했습니다.

다음으로는 권한 관리 과제에 어떻게 대응했는지, 데이터 연계 과제를 위해 어떤 구조를 준비했는지 살펴보겠습니다.

2.2. 플랫폼 간 권한 관리 모델을 어떻게 맞출 것인가

파트 1에서도 언급했듯이 플랫폼별로 데이터 관리와 권한 관리의 전제가 달라 운영 규칙과 사용자 경험에도 차이가 있었습니다.

이 차이는 '누가 데이터의 책임을 지는가', '어떤 단위로 열람 권한을 부여하는가', '누가 신청을 승인하는가' 등 데이터 운영 전반의 사고방식에 영향을 줍니다。

따라서 플랫폼 간 데이터를 주고받을 수 있어도 전송 후에 동일한 사고방식에 기반한 권한 관리 및 재점검 흐름으로 맞추기 어렵고, 사용자는 플랫폼마다 다른 절차와 권한 관리 방식을 이해해야 했습니다。

구 LINE과 구 Yahoo Japan의 권한 관리 사고방식 차이

권한 관리를 통일할 때 가장 먼저 문제된 것은 구 LINE과 구 Yahoo Japan의 권한 관리 사고방식 자체가 달랐다는 점입니다.

특히 큰 차이는 다음 두 가지 관점이었습니다.

누가, 어떤 역할 및 용도로 데이터에 접근하는가
어떤 단위로 데이터 권한을 관리하는가

구 LINE에서는 데이터 활용 목적별로 ‘Project’라는 관리 단위를 만들고 해당 Project를 통해 DB/테이블 단위로 권한을 관리했습니다. 사용자는 Project나 역할을 통해 권한을 얻는 구조로 '누가, 어떤 역할 및 용도로 데이터를 참조하는가'를 정리하기 쉬운 역할 기반 모델이었습니다. 이 방식은 사용 목적과 책임 범위를 파악하기 쉬워 거버넌스 운영과 잘 맞는 구조였습니다.

반면 구 Yahoo Japan에서는 HDFS Path 단위로 권한을 관리했습니다. 각 서비스가 용도에 맞게 자유롭게 데이터를 배치할 수 있어 유연하게 운영할 수 있지만 관리 대상이 늘수록 권한 설정과 재점검이 복잡해지기 쉬운 구조였습니다.

즉 양측은 단순히 사용하는 구조뿐 아니라 '누구에게', '무엇에 대해' 권한을 부여할 것인가라는 전제 자체가 달랐습니다.

사실 테이블 기반 관리 모델은 권한 관리 및 재점검을 일관된 단위로 다루기 쉬워 거버넌스 운영 친화적이었기 때문에 구 Yahoo Japan 측에서도 가능하다면 테이블 기반 권한 관리 모델로 맞추고자 하는 동기가 있었습니다. 그러나 이미 저장 및 운영 중인 구 Yahoo Japan의 데이터를 HDFS Path 기반 관리에서 테이블 기반 관리로 옮기는 것은 그 자체로 큰 과제였습니다. 기존 데이터의 많은 부분을 HDFS Path 전제로 운영하고 있었기에 테이블 기반으로 이전하려면 데이터 배치와 테이블 구조, 작업, 운영 흐름을 재검토해야 했습니다. 이는 사용자 측과 플랫폼 측 모두에게 매우 높은 전환 비용을 발생시킬 것으로 예상됐습니다.

이전 방법과 설계 검토

이와 같은 배경이 있었기에 구 Yahoo Japan의 데이터 플랫폼에 구 LINE의 권한 관리 체계를 어떻게 도입할 것인지는 기존 데이터 구조를 어떻게 다룰지도 포함한 설계 과제로 검토할 필요가 있었습니다。

검토한 이전 방법은 크게 두 가지로 정리할 수 있습니다.

첫 번째는 구 Yahoo Japan 측 구조를 최대한 유지하면서 구 LINE 측 권한 관리 시스템에 맞추는 방법입니다. 이 방법을 적용하면 사용자는 통합 후 공통 도구 및 공통 흐름으로 권한을 관리할 수 있습니다. 또한 사용자 그룹과 신청 흐름을 공통화함으로써 '누가, 어떤 역할 및 용도로 데이터에 접근하는가'라는 역할 기반 관리 모델에 맞추는 것도 가능했습니다.

다만 데이터 관리 단위 자체를 통일하는 것은 아닙니다. 내부적으로는 구 LINE의 테이블 기반 관리와 구 Yahoo Japan의 HDFS Path 기반 관리가 공존하는 상태가 되기 때문입니다. 또한 어떤 데이터가 어떤 기준과 규칙으로 관리되고 있는지 파악하기 어려워 장기적으로 운영 규칙과 사용자 경험이 복잡해질 우려가 있었습니다.

기존 구 Yahoo! JAPAN 구조를 최대한 유지하면서 구 LINE 권한 관리 시스템에 맞추는 방법

두 번째는 구 LINE의 관리 모델에 맞춘 새로운 영역을 구 Yahoo Japan 측에 신설하는 방법입니다. 이 방법에서는 DB/테이블 단위로 관리하기 쉬운 새 영역을 마련하고, 사용자는 대상 데이터를 새 영역으로 이전합니다. 이를 통해 아래 그림에서 보이는 것처럼 HDFS Path 기반의 기존 영역과 테이블 기반의 새 영역을 명확히 분리할 수 있습니다.

구 LINE의 관리 모델에 맞춘 새 영역을 구 Yahoo! JAPAN 측에 신설하는 방법

테이블 단위로 관리 방식을 맞추면 거버넌스 운영을 일관되게 다루기 쉽다는 장점이 있었습니다. 또한 신규 데이터나 플랫폼 간 데이터 연계가 필요한 것부터 단계적으로 적용할 수 있어 사용자 측의 이전 부담 발생 시점을 조절할 수 있다는 것도 장점이었습니다. 반면 사용자 측에는 데이터 이관이나 테이블 재구성 등의 이전 부담이 발생합니다.

최종 설계 판단

최종적으로는 기존 운영에 미치는 영향을 줄이면서 권한 재점검과 감사 대응을 포함한 관리 모델을 단계적으로 통일하기 쉬운 두 번째 안을 채택했습니다. 이번 작업에서 중요한 것은 관리 모델을 일시에 전체에 적용하는 것이 아니라 구 LINE과 구 Yahoo Japan의 설계 철학 차이를 고려한 뒤 거버넌스와 현실적 운영을 모두 만족하는 것이었습니다. 이를 통해 기존 운영을 일괄 교체하지 않고도 플랫폼을 넘나들며 데이터를 다루는 경우에도 같은 사고방식으로 권한을 관리할 수 있는 토대를 마련할 수 있었습니다.

2.3. 플랫폼 간 데이터를 어떻게 연계할 것인가

다음으로 다룰 주제는 설계 철학과 운영 모델이 서로 다른 데이터 플랫폼 간에 인증 및 인가와 운영 통제를 고려하면서 효율적이고 실제로 운영할 수 있는 형태로 데이터를 연계하는 방법입니다.

데이터 연계 개요

지금까지 구 LINE과 구 Yahoo Japan 플랫폼 간에 데이터를 연계할 때에는 플랫폼 외부에 둔 데이터 교환 구조와 Amazon S3를 경유해 데이터를 주고받는 구성을 사용해 왔습니다. 이 방식은 플랫폼 간 결합도를 낮게 유지할 수 있지만 이용 절차나 운영 조정, 사용 비용 측면에서 과제를 안고 있었습니다。

저희는 더 단순하고 신속한 데이터 전송 방식으로 DistCP 활용을 검토했습니다. DistCP는 Hadoop 환경에서 대용량 데이터를 클러스터 간 병렬 분산 복사하는 표준 구조입니다.

이번에 DistCP로 플랫폼 간을 직접 연결할 때는 전송 경로를 개통하는 것 외에 인증 및 인가와 운영 통제, 기술적 측면에서 정리 작업 수행해야 했습니다. 여기서 말하는 인증은 '접속 주체가 누구인지 확인하는 것', 인가는 '확인된 주체에 무엇을 허용할지 정하는 것'을 의미합니다.

인증 및 인가 준비

인증은 구 LINE과 구 Yahoo Japan 각각의 Hadoop 클러스터에서 Kerberos로 인증하고 있으므로, 각 클러스터의 Kerberos KDC 인증 메커니즘을 그대로 사용해 어떤 주체로 접속했는지 특정하는 것을 전제로 했습니다.

특히 이번에는 서로 다른 Kerberos Realm을 넘나드는 인증을 성립시키는 것이 중요했습니다. 이를 위해 Cross-Realm 구성을 전제로 했습니다. 구 LINE과 구 Yahoo Japan은 각각 독립적인 Kerberos KDC를 보유하고 있고 각자 인증을 수행합니다. 이 메커니즘을 살리기 위해 각 Realm 인증을 상호 신뢰해 활용할 필요가 있습니다. Kerberos에는 이를 위한 Cross-Realm라는 메커니즘이 있습니다. KDC 간에 신뢰 관계를 맺어서 서로의 Realm을 신뢰할 수 있게 하는 메커니즘입니다.

추가로 DistCP 사용을 허가한 계정에 대해서는 구 LINE과 구 Yahoo Japan Hadoop 환경에서 사용할 계정 이름을 동일하게 맞췄습니다. 이는 클러스터 간 계정 이름 불일치 문제를 줄일 뿐 아니라 Hadoop 주변 시스템에서도 동일 주체로 취급하기 쉽게 만들기 위한 조치였습니다.

인가 측면에서는 회사 차원에서 허가된 데이터만 전송하는 정책에 따라 실행 가능한 계정을 제한하는 설계를 채택했습니다. 구체적으로는 잡 실행을 관리하는 CapacityScheduler에 DistCP 전용 큐를 마련하고 이 큐에 잡을 제출할 수 있는 계정을 제한했습니다. 또한 DistCP 출발 클러스터와 대상 클러스터에서 계정이 1:1 매칭이 되도록 Kerberos의 auth_to_local을 사용해 계정 이름을 맞췄습니다.

기술적 측면 정리

기술적으로는 OSI 참조 모델의 1계층에서 7계층에 걸친 연결성과 제약, 대역폭 관리가 주요 논점이었습니다. 특히 4계층과 7계층에 주의를 기울였습니다.

4계층에서는 DistCP 전용 큐에 연동된 전용 NodeLabel을 준비했습니다. 전용 NodeLabel이 없는 상태에서 DistCP 잡을 실행하면 다른 Hadoop 클러스터 사용자와 동일한 NodeManager에서 잡이 실행돼 DistCP 실행 시 통신 경로가 클러스터 전체 사용자와 겹칩니다. 전용 NodeLabel이 부여된 NodeManager만 클러스터 간 연결이 가능하도록 하고, 나머지 NodeManager는 네트워크 ACL로 연결을 차단했습니다. 이로 인해 전용 큐에 잡 제출 권한이 없는 계정이 다른 큐로 DistCP 잡을 제출하더라도 4계층에서 통신이 차단되어 잡이 실패합니다.

7계층에서는 Kerberos의 Cross-Realm을 성립시키는 것 외에, 클러스터 간 DistCP 시 오류를 유발할 수 있는 지점(이번 사례에서는 HDFS의 최소 블록 크기 차이 등)을 맞추는 데 주의했습니다. 또한 상호 연결되는 환경마다 네트워크 규칙이나 ACL의 관점이 달라, 필요한 통신을 계층별로 정리해 어느 통신을 개방해야 하는지 명확히 했습니다.

구축 과정에서는 상호 네트워크에 동일한 IP 주소가 사용되는 곳을 발견해 충돌을 피하기 위해 IP가 겹치지 않는 위치에 KDC를 재구축하는 등 개별적으로 준비했습니다. 또한 데이터 플랫폼 간 연계를 실제로 가동하려면 대상 Hadoop 클러스터, 클러스터 간 상호 연결되는 서버, 서버에 적용되는 네트워크 ACL 및 변경 방법, 잡 제출 및 실행 경로 등을 사전에 구체적으로 정리 및 점검해 두는 것이 중요합니다. 구 LINE은 ViewFS를 사용하므로 마운트 테이블을 포함한 클라이언트 설정 파일을 올바르게 배포해 전송 대상 경로가 기대하는 Namespace로 해석되는지 확인했습니다.

어떤 클러스터(운영/검증)를 연결 대상으로 할지, DistCP에 필요한 설정 차이는 무엇인지, 어디에서 잡을 제출할 수 있는지를 정리함으로써 단순한 ‘연결 가능/불가능’을 넘어 실제로 운영 가능한 구성으로 구체화할 수 있었습니다.

대역폭 관리도 중요한 관점입니다. 구 LINE과 구 Yahoo Japan의 Hadoop 클러스터는 서로 다른 데이터 센터에 있으므로 WAN 회선에 과도한 부하를 주지 않도록 스몰 스타트를 기본 원칙으로 삼고, DistCP 잡의 병렬도 및 대역폭 상한을 조정하면서 평상시 트래픽에 영향을 주지 않는 수준으로 단계적으로 운영했습니다.

운영 측 준비

통제 관점에서는 기술적 장치뿐만 아니라 이용 개시까지의 운영 흐름 준비도 중요했습니다. 실제 운영에서는 DistCP 도입 협의 과정에서 보안 책임자 및 네트워크 담당자와의 협의뿐만 아니라, 전송 대상 데이터의 사용 목적 및 개인 정보(프라이버시) 영향 등을 검토해 필요 시 법무 담당자 확인을 거치고, 데이터 전송에 필요한 각종 설정을 한꺼번에 수행하는 흐름을 마련했습니다.

데이터 플랫폼 간 연계에서 중요한 것은 단순히 ‘데이터를 옮길 수 있는가’가 아닙니다. 누가 어떤 권한으로, 어떤 경로를 통해, 어떤 범위의 데이터를 다룰 수 있는지를 인증·인가·운영 통제·네트워크 설계까지 포함해 총체적으로 파악하는 것이 필수입니다.

DistCP는 강력하고 단순한 메커니즘이지만, 서로 다른 배경이 다른 데이터 플랫폼 간에 적용하려면 그 주변의 제약과 운영 흐름까지 포함해 설계해야만 효율적이고 실제 운영 가능한 아키텍처가 됩니다.

2.4. 정리

조직 통합에 따른 데이터 플랫폼 간 연계에서는 단순히 데이터를 전송할 수 있게 하는 것만으로는 충분하지 않았습니다. 실제로는 플랫폼 간에 안전하고 지속적으로 연계할 수 있는 경로를 정비하고, 이를 기반으로 권한 관리와 거버넌스를 어떻게 정비해 나갈지가 중요했습니다.

이번 작업에서는 우선 연계 가능한 경로를 마련하고, 그 사용을 적절한 통제 하에 운영할 수 있도록 함으로써 현실적인 진전을 이뤘습니다. 그 결과 플랫폼 간 데이터 활용을 촉진할 수 있는 토대를 구축할 수 있었습니다.

향후 전망

이번 글에서는 구 LINE과 구 Yahoo Japan이 각각 보유한 대규모 데이터 플랫폼에 대해 클러스터 규모가 커지면서 발생한 운영 과제와, 조직 통합에 따른 플랫폼 간 연계 과제를 소개했습니다.

양쪽에 공통적이었던 것은 단순히 규모를 키우거나 접속 경로를 만드는 것이 아니라 실제 운영을 견딜 수 있는 형태로 하나씩 구체화해야 했다는 점입니다. 용량, NameNode 부하, Namespace 구성, 권한 관리, 인증, 네트워크, 운영 흐름은 각각 독립된 논점처럼 보입니다. 그러나 실제로는 사용자가 안전하게 데이터를 다룰 수 있는 상태를 만들기 위해 상호 영향을 주고받는 설계 요소들이었습니다. 이번 작업에서는 이러한 여러 요소를 단계적으로 정리하고 우선 기존 플랫폼의 특성을 살리면서 연계할 수 있는 토대를 마련했습니다.

아직 데이터 활용을 더욱 촉진하기 위한 편의성 향상, 보다 안전하고 안심할 수 있는 데이터 연계 구조 개선, 데이터 활용 확대에 따른 스케일링 대응 등 해결해야 할 과제가 많이 남아 있습니다.

앞으로도 사용자가 플랫폼의 차이를 의식하지 않고 필요한 데이터를 안전하고 자연스럽게 활용할 수 있는 상태를 목표로 삼겠습니다. 이를 위해 현재의 데이터 플랫폼 간 연계에 남아 있는 제약을 하나씩 풀어서 더욱 통합된 사용 경험을 제공할 수 있도록 만들어 가겠습니다. 또한 중장기적으로는 운영 및 기술 전제를 맞춰 가면서 플랫폼 자체를 통합해 전사적으로 더 사용하기 쉽고 신뢰할 수 있는 데이터 플랫폼을 만들어 나가겠습니다.