Cloudflare의 데이터 플랫폼과 그 위에 구축한 AI 에이전트 이야기
Cloudflare는 여러 데이터베이스와 스트림에 흩어진 데이터를 하나의 SQL 인터페이스로 통합하기 위해 데이터 레이크하우스 플랫폼 **Town Lake**를 구축했다. Town Lake는 신선하고 정확한 원천 데이터와 빠른 분석용 샘플 데이터를 함께 제공하며, 권한 관리·PII 탐지·감사 기능을 기본으로 포함한다. 그 위에 자연어로 질문하면 감사 가능한 답을 제공하는 AI 데이터 에이전트 **Skipper**를 구축해 데이터 접근성을 높이려 했다. ## 데이터 파편화와 접근성 문제 - Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고 330개 이상의 도시, 120개 이상의 국가에서 네트워크를 운영한다. - 데이터가 다음과 같은 다양한 시스템에 분산되어 있었다. - Postgres: 계정 및 업무 메타데이터 - ClickHouse: 분석 이벤트 - BigQuery: 집계 데이터 - R2: 원시 로그 - Kafka: 실시간 이벤트 스트림 - 시스템마다 인증 방식, 쿼리 언어, 보존 기간이 달라 간단한 질문에도 여러 시스템을 알고 있어야 했다. - 올바른 테이블과 조인 방법이 조직 내 암묵지에 의존했다. - 예를 들어 ClickHouse의 사용량 테이블과 Postgres의 고객 차원 테이블을 연결하려면 별도의 고객 ID 변환 규칙을 알아야 했다. - 기존 분석 파이프라인은 초당 7억 건 이상의 이벤트를 처리하기 위해 데이터를 샘플링했다. - 대시보드에는 적합하지만 청구 금액 계산이나 보안 조사처럼 정확한 전체 데이터가 필요한 작업에는 부적합했다. - 일부 내부 리포팅 시스템은 외부 업체와 다른 클라우드에 의존하고 있어 비용과 운영상 종속성도 발생했다. ## 구축 목표 - 적절한 권한과 업무상 필요가 있는 모든 직원이 Cloudflare 데이터를 한곳에서 조회할 수 있도록 했다. - 사용 목적에 따라 서로 다른 데이터 품질을 제공하려 했다. - 청구·보안 조사: 신선하고 정확한 비샘플링 데이터 - 대시보드·탐색: 빠른 응답을 위한 다운샘플링 데이터 - PII를 자동으로 식별하고 민감한 테이블은 기본적으로 제한했다. - 모든 데이터 접근을 감사할 수 있도록 하고, 권한을 일정 기간 동안만 부여하도록 설계했다. - R2, Workers, Cloudflare Access, Workflows 등 Cloudflare 자체 제품 위에 플랫폼을 구축했다. - 최종적으로 SQL을 몰라도 자연어로 데이터를 조회할 수 있는 인터페이스를 제공하는 것이 목표였으며, 이것이 Skipper로 이어졌다. ## Town Lake의 데이터 레이크하우스 구조 Town Lake는 오브젝트 스토리지에 저장된 데이터를 쿼리 엔진으로 조회하고, 메타데이터 계층을 통해 데이터베이스처럼 사용하는 레이크하우스 구조다. - **Apache Trino** - 통합 쿼리 엔진으로 사용된다. - 하나의 SQL 쿼리에서 Postgres, ClickHouse, R2의 Iceberg 테이블을 함께 조인할 수 있다. - 필터를 ClickHouse로 푸시하고, Postgres의 계정 차원 데이터와 R2의 청구 집계 데이터를 결합하는 식으로 쿼리를 최적화한다. - **R2 Data Catalog와 Apache Iceberg** - 차갑거나 따뜻한 데이터를 R2에 저장한다. - Iceberg의 스키마 변경, 시점 조회(time travel), 파티션 변경, 데이터 컴팩션 기능을 활용한다. - 오래된 데이터는 분 단위에서 시간 단위, 다시 일 단위로 집계해 저장 비용을 줄인다. - Parquet 파일을 R2에 저장하면 동일한 데이터를 OLAP 데이터베이스에 보관하는 것보다 비용이 낮다. - **DataHub** - 테이블, 컬럼, 소유 팀, 데이터 계보(lineage), 용어집 정보를 관리한다. - 사용자가 특정 테이블의 의미를 물으면 컬럼 설명, 담당 팀, 상위 입력 테이블, 하위 소비 테이블까지 제공한다. ## 권한 관리와 데이터 거버넌스 - **Lifeguard**가 데이터 접근 제어를 담당한다. - 접근 규칙은 D1에 저장하고, 내부 접근 관리 시스템에서 사용자·그룹 정보를 동적으로 가져온다. - 이 정보를 결합해 JSON 정책을 생성하고 Trino가 HTTP를 통해 읽도록 한다. - Skipper와 Gateway에도 기본적인 권한 정보를 전달해 쿼리가 실행된 뒤가 아니라 진입 단계에서 접근을 차단할 수 있다. - 권한을 업무 목적과 기간에 맞춰 부여함으로써 민감 데이터에 대한 불필요한 상시 접근을 줄인다. - 데이터 접근 기록을 남겨 누가 어떤 데이터에 접근했는지 감사할 수 있도록 했다. ## PII 자동 탐지 - **Skimmer**는 테이블의 모든 컬럼을 지속적으로 검사하는 PII 탐지 스캐너다. - 각 컬럼에서 행을 샘플링하고 Workers AI를 이용해 PII 포함 여부를 분류한다. - 이를 통해 데이터 카탈로그에 민감도 정보를 자동으로 반영하고, 민감한 테이블이나 컬럼의 기본 접근 정책을 강화할 수 있다. ## 자연어 데이터 에이전트 Skipper - Skipper는 Town Lake 위에서 동작하는 AI 데이터 에이전트다. - 사용자가 영어로 질문하면 관련 데이터와 메타데이터를 찾아 SQL 기반 답변을 생성한다. - 데이터 위치, 테이블 구조, 조인 관계, 권한을 사용자가 직접 알 필요를 줄이는 것이 목적이다. - 자연어 질의의 예시는 다음과 같다. - 최근 분기의 매출 기준 상위 100개 고객 조회 - 특정 ASN에서 발생한 고위험 Bot Management 이벤트 검색 - 일정 금액 이상 지출한 고객의 청구 지원 티켓 분석 - 답변은 단순한 생성형 응답이 아니라 데이터에 근거하고 감사 가능한 형태여야 한다는 점이 중요하다. ## 실용적인 시사점 데이터 플랫폼을 구축할 때는 저장소 통합만으로는 충분하지 않다. 통합 쿼리 엔진, 메타데이터 카탈로그, 데이터 계보, 세분화된 권한 관리, PII 탐지, 감사 기능을 함께 설계해야 데이터가 실제 조직 전체에서 활용된다. 또한 정확성이 필요한 업무와 속도가 중요한 분석 업무에 동일한 데이터 처리 방식을 적용하지 않고, 목적에 따라 원천 데이터와 샘플 데이터를 구분하는 전략이 효과적이다.
원문 읽기(새 탭에서 열림)