Cloudflare의 통합 데이터 플랫폼 Town Lake: 레이크하우스 아키텍처 실전 사례
Cloudflare는 내부 운영에 사용하는 통합 데이터 플랫폼 Town Lake를 공개했다. 이 플랫폼은 운영 데이터, 빌링, 보안, 비즈니스 데이터를 단일 환경에서 분석할 수 있도록 설계된 레이크하우스(Lakehouse) 구조로, 분산된 이기종 데이터 소스를 하나의 쿼리 레이어로 통합한 실전 사례다. 4년차 이상의 백엔드 개발자라면 이 아키텍처가 단순한 데이터 웨어하우스나 데이터 레이크와 어떻게 다른지, 그리고 왜 이 조합이 선택되었는지를 주목할 필요가 있다.
핵심 기술 스택: Trino + Iceberg + R2 + DataHub
Town Lake의 아키텍처는 네 가지 컴포넌트의 조합으로 구성된다.
- Trino: 분산 SQL 쿼리 엔진으로, 여러 데이터 소스를 단일 SQL 인터페이스로 페더레이션 쿼리할 수 있게 해준다. JDBC 커넥터 기반으로 PostgreSQL, Object Storage, Kafka 등 다양한 소스를 연결한다.
- Apache Iceberg: 오브젝트 스토리지 위에서 ACID 트랜잭션, 스키마 진화, 타임 트래블 쿼리를 지원하는 오픈 테이블 포맷이다. 단순 Parquet 적재 대비 운영 편의성이 크게 향상된다.
- R2 (Cloudflare Object Storage): AWS S3 호환 오브젝트 스토리지로, Iceberg 테이블의 실제 데이터가 저장되는 레이어다. 스토리지와 컴퓨팅을 분리하는 레이크하우스 패턴의 핵심이다.
- DataHub: 데이터 거버넌스와 메타데이터 관리를 담당하며, 누가 어떤 데이터를 어떻게 사용하는지 추적한다.
-- Trino를 통한 크로스 시스템 페더레이션 쿼리 예시
SELECT b.customer_id, b.total_amount, o.request_count
FROM billing.iceberg_catalog.invoices b
JOIN operational.postgres.traffic_logs o
ON b.customer_id = o.customer_id
WHERE b.billing_date >= DATE '2025-01-01'
위와 같이 서로 다른 카탈로그(Iceberg, PostgreSQL)에 걸친 JOIN 쿼리를 단일 SQL로 실행할 수 있다는 점이 레이크하우스 + 페더레이션 엔진 조합의 실질적 이점이다.
빌링 워크로드가 53%를 차지하는 이유와 시사점
전체 약 9만 1천 건의 쿼리 중 빌링 관련 워크로드가 53%를 차지한다는 수치는 단순한 통계가 아니다. 빌링 시스템은 정확성, 감사 가능성, 이력 추적이 동시에 요구되기 때문에 분석 쿼리 빈도가 높을 수밖에 없다. 특히 Iceberg의 타임 트래블 기능은 특정 시점의 데이터 스냅샷을 조회할 수 있어, 청구 오류 추적이나 월말 정산 감사에 직접적으로 활용 가능하다.
// Java에서 Iceberg REST Catalog 연결 예시 (Spark/Trino 설정 참고)
Map<String, String> properties = new HashMap<>();
properties.put("uri", "https://catalog.example.com");
properties.put("warehouse", "s3://my-r2-bucket/warehouse");
RESTCatalog catalog = new RESTCatalog();
catalog.initialize("my_catalog", properties);
백엔드 개발자 입장에서 주목할 점은, 이 플랫폼이 OLTP 시스템(운영 DB)을 건드리지 않고 분석 워크로드를 분리했다는 것이다. 운영 DB에 직접 집계 쿼리를 날리는 대신 Iceberg 레이어로 데이터를 적재하고 Trino로 분석하는 패턴은, 운영 시스템의 부하를 보호하는 동시에 복잡한 크로스 도메인 분석을 가능하게 한다.
데이터 거버넌스: DataHub의 역할
분산 데이터 환경에서 가장 어려운 문제 중 하나는 "이 데이터가 정확한가, 누가 책임지는가" 를 파악하는 것이다. DataHub는 데이터 리니지(lineage), 소유권, 스키마 변경 이력을 추적해 이 문제를 해결한다. 팀 규모가 커질수록 데이터 거버넌스 부재로 인한 장애나 컴플라이언스 리스크가 급증하기 때문에, 플랫폼 설계 초기부터 메타데이터 관리 레이어를 포함하는 것이 중요하다. Town Lake 사례는 분석 플랫폼 구축 시 기술 스택뿐 아니라 거버넌스 도구를 함께 선택해야 함을 보여준다.
정리
- Trino + Iceberg + Object Storage 조합의 레이크하우스 아키텍처는 스토리지-컴퓨팅 분리와 크로스 시스템 페더레이션 쿼리를 동시에 실현하는 검증된 패턴이다.
- 빌링처럼 감사 추적이 중요한 도메인에서는 Iceberg의 타임 트래블과 ACID 보장이 실질적인 운영 이점을 제공한다.
- 분석 플랫폼 설계 시 DataHub 같은 메타데이터·거버넌스 레이어를 초기부터 포함하는 것이 장기적 유지보수성과 컴플라이언스 대응의 핵심이다.