관측 플랫폼의 발전은 격리된 데이터 웨어하우스와 비싼 독점 인덱스에서 데이터 레이크의 유연성과 창고의 성능을 결합한 통합된 레이크하우스 아키텍처로 변화하였습니다. 초기 SaaS 관측 공급자는 Elasticsearch 또는 Splunk 클러스터에 의존했으나 페타바이트 규모에서 기하급수적인 비용 곡선에 직면하고 진정한 다중 테넌트 격리에 어려움을 겪었습니다. Apache Iceberg 및 Delta Lake와 같은 오픈 테이블 형식의 출현은 객체 스토리지에서 원자 거래 및 시간 여행을 가능하게 했으며, Trino와 같은 쿼리 엔진은 클라우드 스토리지에 대한 대화형 SQL을 제공하기 위해 성숙해졌습니다. 이러한 수렴은 단일 공유 인프라로 수천 개의 테넌트를 제공할 수 있는 가능성을 만들었으나, 엄격한 보안 경계를 시행하고 지능형 계층화를 통해 저장 비용을 최적화하면서도 서브 초 지연 시간을 유지하는 새로운 과제가 도출되었습니다.
핵심 문제는 서로 상충하는 요구 사항을 조정하는 것입니다: 다양한 에이전트(Fluentd, Prometheus, OpenTelemetry)로부터 초당 수백만 개의 이벤트를 수집하면서 역사적 데이터의 엑사바이트에 대한 대화형 쿼리 성능을 제공해야 합니다. 전통적인 공유 없음 데이터베이스는 테넌트 간 쿼리 노이즈로 인해 붕괴되며, 테넌트별 격리는 운영 오버헤드를 증가시킵니다. 엄격한 격리는 테넌트 A의 쿼리가 물리적으로 테넌트 B의 데이터를 검색할 수 없도록 요구하지만, 행 수준 보안 필터는 종종 성능 절벽을 도입합니다. 또한, 모든 데이터를 핫 SSD에 저장하는 것은 경제적으로 불가능하지만, 콜드 데이터를 Amazon S3 Glacier로 이동하면 아카이브된 데이터를 갑자기 쿼리할 때 서브 초 SLA를 위반할 위험이 있습니다. 파티션 및 스키마 진화를 추적하는 카탈로그 서비스는 높은 속도의 수집 중 단일 실패 지점이나 처리량 병목 현상을 피하기 위해 분산되어 있어야 합니다.
테이블 형식으로 Apache Iceberg를 사용하고 Amazon S3, Azure Data Lake Storage, 또는 Google Cloud Storage 위에 위치한 계층화된 레이크하우스를 설계합니다. Apache Kafka 또는 Amazon Kinesis를 통해 스트림을 수집하고, Apache Flink 또는 Spark Streaming을 사용하여 적절한 계층에 데이터를 저장합니다: 핫(쿼리 노드의 로컬 NVMe SSD), 웜(S3 Standard), 또는 콜드(S3 Glacier Instant Retrieval). 분산 쿼리 엔진으로 Trino 또는 Presto를 배포하고, 스캔 수준에서 테넌트 경계를 시행하는 행 수준 및 열 수준 보안 정책을 위해 Apache Ranger 또는 AWS Lake Formation으로 구성합니다. 중앙 집중식 병목 현상을 피하기 위해 Hive Metastore 연합 또는 지역 복제를 사용하는 분산 카탈로그를 구현합니다. 자동 계층화는 쿼리 로그를 모니터링하는 ML 기반 히트맵 분석기에 의해 구동되어 자주 접근되는 콜드 데이터를 웜 저장소로 승격시키고 오래된 핫 데이터를 강등시키며, 계층 간 쿼리 투명성을 보장하기 위해 Iceberg에서 메타데이터 포인터를 유지합니다.
상세 예시:
NebulaObservability는 12,000개의 중소기업 고객에게 서비스를 제공하는 SaaS 공급업체로, 월 $2M의 비용을 초래하는 노후화된 Elasticsearch 클러스터를 교체할 필요가 있었습니다. 각 고객은 로그와 메트릭을 매일 2-10TB 생성하여 서브 초 대시보드 로드 시간을 요구하는 애드혹 SQL 분석이 필요합니다. 규제 요구 사항은 고객 A가 타이밍 공격이나 쿼리 오류를 통해 고객 B의 데이터 존재를 유추할 수 없는 엄격한 격리를 의무화합니다. 데이터 보존은 13개월로 요구되지만, 95%의 쿼리는 마지막 72시간에만 히트됩니다. 이전 아키텍처는 한 고객의 대규모 집계 쿼리가 다른 고객의 성능을 저하시키는 "시끄러운 이웃" 문제로 고통받았습니다.
해결책 1: 분산된 ClickHouse 클러스터
테넌트 기반 샤딩을 통한 대규모 ClickHouse 클러스터를 배포하는 것이 고려되었습니다. 장점은 뛰어난 단일 쿼리 성능과 성숙한 SQL 지원이었습니다. 그러나 단점들은 심각했습니다: 페타바이트 규모 클러스터 관리의 운영 복잡성, 성능 저하 없이 행 수준 보안을 시행하기의 어려움, 저장소와 컴퓨트를 독립적으로 확장할 수 없음 등이었습니다. 또한, 테넌트 온보딩 중 ClickHouse 클러스터의 재샤딩은 몇 시간의 다운타임과 수동 개입이 필요했습니다.
해결책 2: 테넌트별 PostgreSQL 및 TimescaleDB
각 테넌트에 대한 격리된 PostgreSQL 인스턴스를 TimescaleDB 확장을 통해 제공하는 것은 완벽한 보안 격리와 간단한 백업 전략을 제공했습니다. 장점은 명백했습니다: 기본 행 수준 보안, GDPR에 대한 테넌트 삭제 용이성, 테넌트 간 간섭 없음 등이었습니다. 단점은 이 접근 방식이 불가능하게 만들었습니다: 12,000개의 데이터베이스 인스턴스 관리의 운영 악몽, 패치 주기 및 연결 풀 고갈, 열 형식에 비해 압축 부족으로 인한 저장 비용 폭발 등이었습니다.
해결책 3: 계층 저장소를 갖춘 연합 레이크하우스
Apache Iceberg 기반의 레이크하우스를 Trino와 자동화된 계층화로 구현하는 것은 최적의 균형을 제공했습니다. 장점은 공유 인프라의 규모의 경제, 사용자의 오류를 방지하는 Iceberg의 숨겨진 파티셔닝, 그리고 S3의 무한한 확장성이 포함되었습니다. Apache Ranger를 통한 행 수준 보안은 쿼리를 수정하지 않고도 세밀한 정책을 가능하게 했습니다. 자동화된 계층화는 콜드 데이터를 S3 Glacier로 이동시키며 저장 비용을 70% 감소시키고 메타데이터를 핫으로 유지했습니다. 단점은 상당한 조정 복잡성을 포함했습니다: 쿼리 계획은 주의 깊은 파티션 프루닝과 계층화 알고리즘의 교육 데이터가 필요했습니다.
선택된 해결책과 이유:
해결책 3은 행성 규모의 요구를 고수하면서 엄격한 격리를 유지하기 때문에 선택되었습니다. Iceberg 형식의 원자적 테이블 메타데이터 업데이트 기능은 잠금 없이 스키마 진화를 가능하게 하여 제로 다운타임 배포에 중요했습니다. Trino의 커넥터 아키텍처는 조건을 S3로 푸시 다운할 수 있게 하여 검색 데이터 감소를 가능하게 했습니다. 자동화된 계층화는 Athena 쿼리 로그에 의해 트리거되는 AWS Lambda 함수를 사용하여 수동 개입 없이 비용 최적화를 보장했습니다. 이 접근 방식은 저장소와 컴퓨트를 분리하여 트래픽 급증 동안 독립적으로 확장할 수 있게 했습니다.
결과:
시스템은 12PB의 활동 데이터에 대해 p99 쿼리 지연 시간을 650ms 달성하며, 피크 시간 동안 50,000개의 동시 쿼리를 지원했습니다. 저장 비용은 이전 Elasticsearch 아키텍처와 비교하여 68% 감소하여 월 $1.36M을 절감했습니다. 자동화된 계층화는 데이터 접근 패턴의 94%를 정확하게 예측했으며, 콜드 저장소에 대한 "캐시 미스"는 단 0.3%에 불과했습니다. 운영 첫 18개월 동안 테넌트 간 데이터 유출과 관련된 보안 사건은 기록되지 않았으며, 분기마다 침투 테스트를 통해 검증되었습니다. 새로운 테넌트를 온보딩하는 것은 30초 미만의 메타데이터 작업으로 진행되었습니다.
자동화된 계층화 알고리즘이 갑자기 접근되는 "웜" 데이터를 잘못 강등할 경우 쿼리 지연 시간 폭발을 어떻게 방지합니까?
후보자들은 종종 예측 메커니즘을 고려하지 않고 반응적 캐싱을 제안합니다. 자세한 답변은 쿼리 접근 로그에 대한 지수 평활법을 사용하여 예측 계층화 시스템을 구현하는 것을 요구하며, 강등되기 전에 밀리초 첫 바이트 지연을 갖는 "미온적" 중간 계층을 S3 Standard-IA에 유지합니다. 또한, Trino와 S3 사이에 Alluxio를 배포하여 예상치 못한 접근 급증을 흡수합니다. 중요한 세부 사항은 "읽기 시 승격"을 구현하는 것입니다: 콜드 데이터에 접근할 때 시스템은 현재 쿼리를 S3 Glacier Instant Retrieval에서 제공하면서 비동기적으로 이를 웜 계층으로 다시 복사합니다.
수천 개의 테넌트 테이블에 대한 스키마 진화를 위한 ACID 일관성을 어떻게 유지합니까 (열 추가)?
대부분의 후보자는 분산 잠금을 제안하지만 이는 "중앙 집중식 병목 현상 없음" 요구 사항을 위반합니다. 올바른 접근 방식은 Apache Iceberg의 낙관적 동시성 제어 및 메타데이터 레이어링을 활용합니다. 각 테넌트 테이블은 독립적인 metadata.json 파일 계보를 가집니다. 스키마 변경은 시퀀스 번호가 증가된 새 메타데이터 파일을 추가하며, 카탈로그(예: AWS Glue)는 현재 메타데이터 파일에 대한 포인터만 저장합니다. 커밋 중에는 작성자가 포인터가 변경되었는지(충돌) 확인하고 필요할 경우 재시도합니다. 이 방식은 테넌트 테이블이 독립적 네임스페이스이기 때문에 전역 잠금을 필요로 하지 않습니다. 드문 테넌트 간 스키마 업데이트(예: 공용 열 추가)의 경우, 원자 트랜잭션보다는 아이도포턴트 DDL 작업을 사용하는 사가 패턴을 사용합니다.
행 수준 보안 계층을 어떻게 설계하여 "슈퍼 테넌트"가 다른 테넌트를 위한 CPU 자원을 고갈시키는 전체 테이블 검색을 수행하지 못하도록 합니까, 이는 서브 초 SLA를 위반합니다?
후보자들은 자주 리소스 거버넌스 메커니즘을 놓칩니다. 해결책은 Trino의 리소스 그룹을 사용하여 테넌트 클래스(프리미엄 vs. 표준)당 하드 CPU 한도 및 메모리 할당량으로 계층화된 리소스 격리를 활용하는 것입니다. 쿼리 비용을 추정하는 입장 통제를 구현하며, 테넌트별 한도를 초과하는 쿼리는 실행되지 않고 대기열에 있거나 거부됩니다. Kubernetes 리소스 할당량을 사용하여 쿼리 엔진 포드를 테넌트별 노드 풀로 분리하여 CPU 고갈을 방지합니다. 마지막으로, 예측 비용을 초과한 장기 실행 스캔에 대한 쿼리 제거 정책을 구현하며, 공통 비용이 높은 집계를 위해 물리적 뷰를 사용하여 심지어 악의적이거나 우발적인 전체 스캔이 다른 테넌트의 지연에 영향을 줄 수 없도록 합니다.