카카오의 자체 Hadoop 데이터 레이크가 여러 IDC와 100억 개 파일 규모로 커지며 부딪힌 저장·메타데이터 병목을 어떻게 넘었는지 수치와 함께 정리한다. 저장 용량보다 파일(메타데이터) 개수가 먼저 시스템을 압박한다는 발견이 설계 전환의 축이 된다.
핵심 포인트- 지연 2ms 이내인 세 IDC를 하나의 HDFS 클러스터로 묶고 복제본을 서로 다른 IDC에 배치해, 한 센터가 멈춰도 데이터 접근을 유지하도록 NameNode HA와 블록 배치 정책을 보완
- 자주 안 읽는 아카이브 데이터에 7 데이터 + 5 패리티 블록을 IDC로 분산하는 erasure coding을 적용해 3중 복제 수준 내성을 유지하며 저장 공간 약 43% 절감
- 파일이 1억→4억 개로 늘자 p99 RPC 지연 23ms→117ms, 재시작 17분→66분으로 악화 — 단일 네임스페이스를 더 큰 서버로 버티는 대신 수평 분할을 선택
- Router-Based Federation으로 여러 NameService를 가상 경로로 통합하고 stateless Router가 ZooKeeper 마운트 정보로 요청 전달, 동적·multi-mount로 증설을 단순화하되 공간 기반 분산의 다중 RPC 비용은 워크로드별 정책으로 조정
왜 읽나페타바이트·수십억 파일급 HDFS를 운영하며 NameNode 확장 한계에 부딪힌 데이터 플랫폼 엔지니어에게, 멀티 IDC 복제·EC·Federation 선택 기준을 실측치로 제공.