Cloudflare의 통합 데이터 플랫폼 Town Lake
Cloudflare는 내부 데이터 분석 인프라로 사용하는 통합 데이터 플랫폼 Town Lake를 공개했다. 운영(Operational), 빌링(Billing), 보안(Security), 비즈니스 데이터를 단일 플랫폼에서 조회·분석할 수 있도록 설계된 이 시스템은, 기업 규모가 커질수록 필연적으로 직면하는 이기종 데이터 소스 통합 문제를 어떻게 해결할 수 있는지 보여주는 실전 사례다.
레이크하우스 아키텍처 구성
Town Lake는 다음 네 가지 핵심 기술을 조합한 레이크하우스(Lakehouse) 구조로 설계되었다.
- Trino: 분산 SQL 쿼리 엔진으로, 여러 데이터 소스에 대한 통합 쿼리 레이어 역할
- Apache Iceberg: 테이블 포맷 표준으로 스키마 진화, 타임 트래블, ACID 트랜잭션 지원
- R2 (Object Storage): Cloudflare 자체 S3 호환 오브젝트 스토리지로 데이터 레이크의 물리적 저장소
- DataHub: 데이터 카탈로그 및 거버넌스 도구로 메타데이터 관리와 데이터 계보(Lineage) 추적 담당
이 조합은 현재 데이터 엔지니어링 업계에서 "오픈 레이크하우스" 스택으로 주목받는 구성과 거의 일치한다. Trino + Iceberg 조합은 특히 여러 시스템에 흩어진 데이터를 단일 SQL로 조회해야 할 때 강력한 선택지다. 기존 데이터 웨어하우스가 단일 벤더에 종속되는 것과 달리, 오픈 포맷 기반이라 유연한 확장이 가능하다.
빌링 워크로드가 전체 쿼리의 53%
Town Lake에서 처리된 전체 쿼리 약 9만 1천 건 중 빌링 관련 워크로드가 53% 를 차지한다는 점은 주목할 만하다. 일반적으로 빌링 데이터는 정확성과 일관성에 대한 요구가 높고, 다양한 운영 데이터와 조인이 필요하기 때문에 크로스 시스템 쿼리 부하가 집중되는 영역이다.
Java 백엔드 관점에서 보면, 이런 구조는 마이크로서비스 환경에서 각 서비스가 독립 DB를 소유하는 설계와 충돌 없이 공존할 수 있다. 각 서비스의 데이터는 Iceberg 테이블로 익스포트되고, Trino가 이를 연합 쿼리(Federated Query)로 통합한다. 서비스 간 직접 DB 접근 없이도 복잡한 분석 쿼리가 가능해지는 것이다.
-- Trino를 통한 크로스 소스 분석 쿼리 예시
SELECT
b.customer_id,
b.total_amount,
o.request_count,
s.threat_score
FROM billing.invoices b
JOIN operational.usage_stats o ON b.customer_id = o.customer_id
JOIN security.threat_summary s ON b.customer_id = s.customer_id
WHERE b.billing_period = '2025-06';
데이터 거버넌스와 실무 도입 시 고려사항
DataHub를 통한 거버넌스 레이어는 단순 분석 기능을 넘어 데이터 품질 관리와 감사(Audit) 추적을 가능하게 한다. 누가 어떤 데이터를 어떻게 사용했는지 추적할 수 있어야 하는 규제 환경(금융, 의료 등)에서는 이 부분이 핵심 요건이 된다. 메타데이터 카탈로그가 없는 대형 데이터 플랫폼은 운영 시간이 길어질수록 "데이터 스왐프(Data Swamp)"로 전락할 위험이 있다.
백엔드 개발자가 이 아키텍처에서 얻을 수 있는 실무 인사이트는 분명하다. 분석 요건이 늘어날 때 기존 운영 DB에 복잡한 쿼리를 추가하기보다, 오픈 포맷 기반 레이크하우스 레이어를 분리하는 것이 서비스 안정성과 확장성 모두에 유리하다.
정리
- Trino + Apache Iceberg + 오브젝트 스토리지 조합은 이기종 데이터 소스를 단일 SQL로 통합하는 현실적인 오픈 레이크하우스 스택이다
- 마이크로서비스 환경에서 서비스 간 DB 직접 접근 없이 분석 쿼리를 처리하는 연합 쿼리(Federated Query) 패턴으로 활용 가능하다
- DataHub 같은 데이터 카탈로그를 통한 거버넌스 레이어는 플랫폼 규모가 커질수록 필수 요소가 된다