비용이 많이 드는 Delta Lake S3 스토리지 실수(그리고 해결 방법)

1. 소개: 기반

S3와 같은 클라우드 객체 스토리지는 모든 Lakehouse 아키텍처의 기반입니다. Lakehouse에 저장된 데이터의 소유자는 데이터를 사용하는 시스템이 아닌 바로 귀하입니다. ETL 파이프라인이나 더 많은 사용자의 테이블 쿼리로 인해 데이터 볼륨이 증가함에 따라 클라우드 스토리지 비용도 증가합니다.

실제로 저희는 이러한 스토리지 버킷이 구성되는 방식에서 Delta Lake 테이블에 불필요한 비용을 초래하는 일반적인 문제점들을 확인했습니다. 이러한 습관을 그대로 두면 스토리지 낭비와 네트워크 비용 증가로 이어질 수 있습니다.

이 블로그에서는 가장 흔한 실수에 대해 알아보고, 이를 탐지하고 수정하는 구체적인 방법을 알려드립니다. Databricks Data Intelligence Platform과 AWS 서비스를 모두 활용하는 도구와 전략을 균형 있게 사용할 것입니다.

2. 주요 아키텍처 고려 사항

이 블로그에서는 비용을 최적화할 때 고려할 Delta 테이블용 클라우드 스토리지의 세 가지 측면이 있습니다.

• 객체 대 테이블 버전 관리 - S3와 Delta Lake가 데이터를 버전 관리하는 방법입니다.
• 스토리지 클래스(hot/cool/cold/archive) - 장기간 보관하며 자주 액세스하지 않는 데이터를 위한 저렴한 스토리지입니다.
• 데이터 전송 - S3로 데이터를 읽고 쓰는 비용입니다.

객체 버전 관리와 테이블 버전 관리

객체 버전 관리를 위한 클라우드 네이티브 기능만으로는 Delta Lake 테이블에서 직관적으로 작동하지 않습니다. 사실, 이 두 가지는 데이터 보존이라는 동일한 문제를 서로 다른 방식으로 해결하기 위해 경쟁하므로 근본적으로 Delta Lake와 모순됩니다.

이를 이해하기 위해 Delta 테이블이 버전 관리를 처리하는 방법 을 살펴본 다음 S3의 네이티브 객체 버전 관리와 비교해 보겠습니다.

Delta 테이블의 버전 관리 처리 방법

Delta Lake 테이블은 각 트랜잭션을 _delta_log/ 디렉터리에 매니페스트 파일(JSON 또는 Parquet 형식)로 기록하며, 이 매니페스트는 테이블의 기본 데이터 파일(Parquet 형식)을 가리킵니다. 데이터가 추가, 수정 또는 삭제될 때 새로운 데이터 파일이 생성됩니다. 따라서 파일 수준에서 각 객체는 변경 불가능(immutable)합니다. 이 접근 방식은 효율적인 데이터 액세스와 강력한 데이터 무결성을 위해 최적화되었습니다.

Delta Lake는 모든 변경 사항을 트랜잭션 로그에 일련의 트랜잭션으로 저장하여 데이터 버전을 기본적으로 관리합니다. 각 트랜잭션은 테이블의 새 버전을 나타내며, 사용자는 이를 통해 이전 상태로 시간 이동 하고, 이전 버전으로 되돌리며, 데이터 리니지를 감사할 수 있습니다.

S3에서 객체 버전 관리를 처리하는 방법

S3는 버킷 수준 기능으로 네이티브 객체 버전 관리 도 제공합니다. 활성화된 경우 S3는 객체의 여러 버전을 보관합니다. 객체의 현재 버전은 1개만 있을 수 있으며, 여러 개의 이전 버전이 있을 수 있습니다.

객체를 덮어쓰거나 삭제하면 S3는 이전 버전을 noncurrent 로 표시한 다음 새 버전을 current로 생성합니다. 이를 통해 실수로 인한 삭제나 덮어쓰기로부터 데이터를 보호할 수 있습니다.

이것의 문제점은 두 가지 방식으로 Delta Lake 버전 관리와 충돌한다는 것입니다.

1. Delta Lake는 새로운 트랜잭션 파일과 데이터 파일만 쓰고 덮어쓰지는 않습니다.
   • 스토리지 객체가 Delta 테이블의 일부인 경우,네이티브 Databricks Runtime과 같은 Delta Lake 클라이언트 또는 오픈 소스 Unity Catalog REST API 를 지원하는 엔진을 사용해서만 해당 객체에 대한 작업을 수행해야 합니다.
   • Delta Lake는 테이블 수준 버전 관리 및 시간 이동 기능을 통해 우발적인 삭제로부터 이미 보호 기능을 제공합니다.
2. 트랜잭션 로그에서 더 이상 참조되지 않는 파일을 제거하기 위해 Delta 테이블을 vacuum 합니다.
   • 하지만 S3의 객체 버전 관리 기능 때문에 데이터가 완전히 삭제되지 않고, 대신 요금이 계속 부과되는 최신이 아닌 버전이 됩니다.

스토리지 계층

스토리지 클래스 비교

S3는 저장된 데이터를 위한 유연한 스토리지 클래스 를 제공하며, 이는 핫(hot), 쿨(cool), 콜드(cold), 아카이브(archive)로 크게 분류할 수 있습니다. 이는 데이터에 액세스하는 빈도와 검색하는 데 걸리는 시간을 나타냅니다.

콜드 스토리지 클래스는 데이터를 저장하는 GB당 비용은 더 낮지만, 데이터를 검색할 때는 더 높은 비용과 지연 시간이 발생합니다. Lakehouse 스토리지에도 이점을 활용하고 싶지만, 신중하게 적용하지 않으면 쿼리 성능에 심각한 영향을 미치고, 모든 것을 단순히 S3 Standard에 저장하는 것보다 비용이 더 많이 들 수도 있습니다.

스토리지 클래스 관련 실수

수명 주기 정책을 사용하면 S3는 객체가 생성된 후 일정 기간이 지나면 파일을 다른 스토리지 클래스로 자동 이동할 수 있습니다. S3-IA 와 같은 콜드 티어는 여전히 검색 시간이 빠르기 때문에 표면적으로는 안전한 옵션처럼 보이지만, 이는 정확한 query 패턴에 따라 달라집니다.

예를 들어, created_dt DATE 열로 파티셔닝된 Delta 테이블이 있고 이 테이블이 보고용 골드 테이블로 사용된다고 가정해 보겠습니다. 비용 절감을 위해 30일이 지난 파일을 S3-IA로 이동시키는 수명 주기 정책을 적용합니다. 하지만 애널리스트가 WHERE 절 없이 테이블을 쿼리하거나 더 이전의 데이터를 사용해야 해서 WHERE created_dt >= curdate() - INTERVAL 90 DAYS를 사용하면 S3-IA에 있는 여러 파일을 검색하게 되어 더 높은 검색 비용이 발생합니다. 애널리스트는 자신이 무언가 잘못하고 있다는 사실을 인지하지 못할 수 있지만, FinOps 팀은 S3-IA 검색 비용이 높아진 것을 알아차릴 것입니다.

설상가상으로 90일 후에 객체를 S3 Glacier Deep Archive 또는 Glacier Flexible Retrieval 클래스로 이동한다고 가정해 보겠습니다. 동일한 문제가 발생하지만, 이번에는 사용 전에 복원하거나 해동해야 하는 파일에 액세스하려고 시도하기 때문에 실제로 query가 실패합니다. 이 복원은 일반적으로 클라우드 엔지니어나 플랫폼 관리자가 수행하는 수동 프로세스이며 완료하는 데 최대 12시간이 걸릴 수 있습니다. 또는 1~5분이 소요되는 '신속(Expedited)' 검색 방법을 선택할 수 있습니다. Glacier 아카이브 스토리지 클래스에서 객체를 복원하는 방법에 대한 자세한 내용은 Amazon 문서 를 참조하세요.

곧 이러한 스토리지 클래스 관련 문제를 완화하는 방법을 알아보겠습니다.

데이터 전송 비용

비용이 많이 드는 Lakehouse 스토리지 실수의 세 번째 범주는 데이터 전송입니다. 데이터가 저장된 클라우드 리전, 데이터에 액세스하는 위치, 네트워크 내에서 요청이 라우팅되는 방식을 고려하세요.

S3 버킷과 다른 리전에서 S3 데이터에 액세스하면 데이터 이그레스 비용이 발생합니다. 이는 청구서에서 금방 큰 비중을 차지하는 항목이 될 수 있으며, 고가용성 또는 재해 복구 시나리오와 같이 다중 리전 지원이 필요한 사용 사례에서 더 흔하게 발생합니다.

NAT 게이트웨이

이 범주에서 가장 흔한 실수는 S3 트래픽이 NAT 게이트웨이를 통해 라우팅되도록 하는 것입니다. 기본적으로 프라이빗 서브넷 의 리소스는 트래픽을 퍼블릭 S3 endpoint (예: s3.us-east-1.amazonaws.com)로 라우팅하여 S3에 액세스합니다. 이는 퍼블릭 호스트이므로 트래픽이 서브넷의 NAT 게이트웨이를 통해 라우팅되며, GB당 약 0.045달러의 비용이 발생합니다. 이는 AWS Cost Explorer 의 서비스 = Amazon EC2 및 사용 유형 = NatGateway-Bytes 또는 사용 유형 = <REGION>-DataProcessing-Bytes에서 찾을 수 있습니다.

EC2 인스턴스가 AWS VPC 내에서 시작되므로 이는 Databricks 클래식 클러스터 및 웨어하우스에서 시작된 EC2 인스턴스를 포함합니다. EC2 인스턴스가 NAT 게이트웨이와 다른 가용 영역(AZ)에 있는 경우 GB당 약 $0.01의 추가 비용이 발생합니다. 이는 AWS 비용 탐색기의 Service = Amazon EC2 및 Usage Type = <REGION>-DataTransfer-Regional-Bytes 또는 Usage Type = DataTransfer-Regional-Bytes에서 찾을 수 있습니다.

이러한 워크로드는 일반적으로 S3 읽기 및 쓰기의 주요 원인이므로 이 실수는 S3 관련 비용의 상당 부분을 차지할 수 있습니다. 다음으로, 이러한 각 문제에 대한 기술적 솔루션을 자세히 살펴보겠습니다.

3. 기술 솔루션 세부 설명

NAT Gateway S3 비용 문제 해결

S3 게이트웨이 엔드포인트

S3 트래픽이 NAT Gateway를 사용하거나 공용 인터넷을 통하지 않도록 하는, 아마도 가장 해결하기 쉬운 문제인 VPC 네트워킹부터 시작하겠습니다. 가장 간단한 솔루션은 S3 Gateway Endpoint를 사용하는 것입니다. 이는 VPC와 동일한 리전의 S3 트래픽을 처리하여 NAT Gateway를 우회하는 리전별 VPC Endpoint Service입니다. S3 Gateway endpoint는 엔드포인트 자체나 이를 통해 전송되는 데이터에 대해 비용이 발생하지 않습니다.

스크립트: 누락된 S3 게이트웨이 Endpoint 식별

현재 S3 Gateway Endpoint가 없는 리전 내 VPC를 찾기 위해 다음 Python 스크립트를 제공합니다.

참고: 이 블로그의 이 스크립트 또는 다른 스크립트를 사용하려면 Python 3.9+ 및 boto3 (pip install boto3)가 설치되어 있어야 합니다. 또한 AWS 리소스에 대한 액세스가 필요하므로 Unity Catalog 서비스 자격 증명을 사용하지 않으면 이 스크립트를 Serverless compute에서 실행할 수 없습니다.

스크립트를 check_vpc_s3_endpoints.py 로 저장하고 다음을 사용하여 스크립트를 실행합니다.

다음과 같은 출력이 표시됩니다.

이러한 VPC 후보를 식별한 후에는 AWS 문서 를 참조하여 S3 게이트웨이 Endpoint를 생성하세요.

다중 리전 S3 네트워킹

다중 리전 S3 패턴이 필요한 고급 사용 사례에서는 더 많은 설정 노력이 필요한 S3 인터페이스 엔드포인트를 활용할 수 있습니다. 이러한 액세스 패턴에 대한 자세한 내용과 비용 비교 예시는 다음 전체 블로그를 참조하세요.
https://www.databricks.com/blog/optimizing-aws-s3-access-databricks

클래식 vs Serverless compute

Databricks는 서버리스 Lakeflow Jobs, 서버리스 SQL Warehouse 및 서버리스 Lakeflow Spark Declarative Pipelines 을 포함한 완전 관리형 서버리스 컴퓨트 도 제공합니다. serverless compute를 사용하면 Databricks가 사용자를 대신해 복잡한 작업을 처리하고 S3 트래픽을 S3 게이트웨이 Endpoint를 통해 라우팅합니다!

Serverless 컴퓨팅이 S3로 트래픽을 라우팅하는 방법에 대한 자세한 내용은 Serverless 컴퓨팅 평면 네트워킹 을 참조하세요.

Databricks의 아카이브 지원

Databricks는 S3 Glacier Deep Archive 및 Glacier Flexible Retrieval에 대한 아카이브 지원을 제공하며, 이는 Databricks Runtime 13.3 LTS 이상 버전에서 공개 미리 보기(Public Preview)로 제공됩니다. S3 스토리지 클래스 수명 주기 정책을 구현해야 하지만 이전에 설명한 느리고 비용이 많이 드는 검색을 완화하고 싶다면 이 기능을 사용하세요. 아카이브 지원을 활성화하면 Databricks는 지정된 기간보다 오래된 파일을 무시하게 됩니다.

아카이브 지원은 아카이브된 파일에 액세스하지 않고도 올바르게 응답할 수 있는 query만 허용합니다. 따라서 VIEW들 를 사용하여 쿼리가 이러한 테이블의 아카이브되지 않은 데이터에만 액세스하도록 제한하는 것이 좋습니다. 그렇지 않으면 아카이브된 파일의 데이터가 필요한 query는 여전히 실패하고 사용자에게 자세한 오류 메시지가 제공됩니다.

참고: Databricks는 S3 버킷의 수명 주기 관리 정책과 직접 상호 작용하지 않습니다. 아카이브를 완전히 구현하려면 이 테이블 속성을 일반 S3 수명 주기 관리 정책과 함께 사용해야 합니다. 클라우드 객체 스토리지에 대한 수명 주기 정책을 설정하지 않고 이 설정을 활성화하면 Databricks는 지정된 threshold에 따라 파일을 계속 무시하지만 데이터는 아카이브되지 않습니다.

테이블에서 아카이브 지원을 사용하려면 먼저 다음과 같이 테이블 속성을 설정하세요:

그런 다음 테이블 속성에 지정된 일수와 동일한 기간이 지나면 객체를 Glacier Deep Archive 또는 Glacier Flexible Retrieval로 전환하도록 버킷에 S3 수명 주기 정책을 생성하세요.

문제 있는 버킷 식별

다음으로 비용 최적화를 위한 S3 버킷 후보를 식별합니다. 다음 스크립트는 AWS 계정의 S3 버킷을 반복하고 객체 버전 관리가 활성화되어 있지만 최신이 아닌 버전을 삭제하는 수명 주기 정책이 없는 버킷을 로깅합니다.

스크립트는 다음과 같이 후보 버킷을 출력합니다.

예상 비용 절감

다음으로 Cost Explorer와 S3 Lens 를 사용하여 S3 버킷의 관리되지 않는 이전 버전 객체에 대한 잠재적인 비용 절감액을 추정할 수 있습니다.

Amazon은 S3 사용량에 대한 기본 대시보드를 제공하는 S3 Lens 서비스를 출시했으며, 이는 일반적으로 https://console.aws.amazon.com/s3/lens/dashboard/default에서 사용할 수 있습니다.

먼저 S3 Lens 대시보드 > 개요 > 추세 및 분포로 이동합니다. 기본 메트릭으로는 % noncurrent version bytes를 선택하고, 보조 메트릭으로는 Noncurrent version bytes를 선택합니다. 대시보드 상단에서 계정, 리전, 스토리지 클래스 및/또는 버킷별로 선택적으로 필터링할 수 있습니다.

위 예시에서 스토리지의 40%는 noncurrent 버전 바이트, 즉 약 40TB의 물리적 데이터가 차지하고 있습니다.

다음으로 AWS Cost Explorer로 이동합니다. 오른쪽에서 필터를 변경합니다.

• 서비스: S3(Simple Storage Service)
• 사용 유형 그룹: 해당하는 S3: Storage * 사용 유형 그룹을 모두 선택하세요.
  • S3: Storage - Express One Zone
  • S3: 스토리지 - Glacier
  • S3: 스토리지 - Glacier Deep Archive
  • S3: 스토리지 - 인텔리전트 티어링
  • S3: 스토리지 - One Zone IA
  • S3: 스토리지 - 감소된 중복성
  • S3: 스토리지 - 표준
  • S3: 스토리지 - Standard Infrequent Access

필터를 적용하고 Group By 를 API 운영 으로 변경하여 다음과 같은 차트를 확인하세요:

참고: S3 Lens에서 특정 버킷으로 필터링한 경우 Cost Explorer에서 S3 버킷 이름에 대한 Tag:Name 으로 필터링하여 해당 범위를 일치시켜야 합니다.

이 두 보고서를 결합하면 Delta Lake 테이블에 사용되는 S3 버킷에서 현재 버전이 아닌 바이트를 제거하여 월 평균 S3 스토리지 비용($24,791)의 약 40%인 월 $9,916 를 절감할 수 있다고 추정할 수 있습니다!

최적화 구현

다음으로 2단계 프로세스에 따라 noncurrent 버전에 대한 최적화를 구현하기 시작합니다.

1. 비최신 버전에 대한 수명 주기 정책을 구현합니다.
2. (선택 사항) S3 버킷에서 객체 버전 관리를 비활성화합니다.

비최신 버전을 위한 수명 주기 정책

AWS 콘솔(UI)에서 S3 버킷의 관리 tab으로 이동한 다음 수명 주기 규칙 만들기를 클릭합니다.

규칙 범위를 선택하세요:

• 버킷에 Delta 테이블만 저장하는 경우 '버킷의 모든 객체에 적용'을 선택하세요.
• Delta 테이블이 버킷 내의 접두사로 격리되어 있는 경우 '하나 이상의 필터를 사용하여 이 규칙의 범위 제한'을 선택하고 접두사(예: delta/)를 입력하세요.

다음으로 현재 버전이 아닌 객체 영구 삭제 확인란을 선택하세요.

다음으로, 최신이 아닌 객체가 최신이 아니게 된 후 며칠 동안 보관할지 입력합니다. 참고: 이는 실수로 인한 삭제로부터 보호하기 위한 백업 역할을 합니다. 예를 들어 수명 주기 정책에 7일을 사용하는 경우, 사용하지 않는 파일을 제거하기 위해 Delta 테이블을 VACUUM 할 때 영구적으로 삭제되기 전까지 S3에서 최신이 아닌 버전 객체를 7일 동안 복원할 수 있습니다.

계속하기 전에 규칙을 검토한 다음 '규칙 생성'을 클릭하여 설정을 완료하세요.

Terraform에서 aws_s3_bucket_lifecycle_configuration 리소스를 사용하여 이를 달성할 수도 있습니다.

객체 버전 관리 비활성화

AWS 콘솔을 사용하여 S3 버킷의 객체 버저닝을 비활성화하려면 버킷의 tab 탭으로 이동하여 버킷 버저닝 속성을 편집 하세요.

참고: 버저닝이 활성화된 기존 버킷의 경우 버저닝을 비활성화할 수는 없으며 중단 만 할 수 있습니다. 이렇게 하면 모든 운영에 대한 객체 버전 생성이 중단되지만 기존의 모든 객체 버전은 보존됩니다.

이는 Terraform에서 aws_s3_bucket_versioning 리소스를 사용하여 달성할 수도 있습니다.

향후 배포를 위한 Template

향후 S3 버킷이 모범 사례에 따라 배포되도록 하려면, 다음 리소스를 자동으로 생성하는 unity_catalog_catalog_creation 모듈과 같이 terraform-databricks-sra 에 제공된 Terraform 모듈을 사용하세요.

• Unity Catalog 외부 위치로 설정된 S3 버킷
• Unity Catalog 스토리지 보안 인증으로 설정된 IAM 역할
• 버킷을 기본 관리형 스토리지로 사용하여 새 카탈로그 생성
• S3 버킷 암호화를 위한 고객 관리형 KMS 키
• S3 버전 관리 비활성화
• S3 버킷에 대한 퍼블릭 액세스 비활성화

보안 참조 아키텍처(SRA) 모듈 외에도 Databricks Terraform 공급자 가이드 를 참조하여 새 Workspace를 생성할 때 S3용 VPC Gateway Endpoint를 배포할 수 있습니다.

4. 실제 시나리오

고객은 이 블로그에 설명된 S3 비용 최적화 기술을 적용하여 성능 저하 없이 Lakehouse 스토리지 비용을 크게 절감할 수 있습니다.

First Orion 은 브랜드 커뮤니케이션, 브랜드 메시징 및 고급 통화 보호 솔루션을 제공하는 전기 통신 기술 회사로, 기업과 주요 통신사가 안전하고 개인화된 전화 통화를 제공하는 동시에 소비자를 스캠과 사기로부터 보호하도록 지원합니다. First Orion은 이러한 모범 사례를 사용하여 Unity Catalog S3 버킷을 최적화한 결과, 월 $16k의 스토리지 비용을 절감했습니다.

이러한 스토리지 최적화를 확보하는 데에는 일반적으로 상충 관계가 없습니다. 하지만 수명 주기 정책 및 버전 관리와 같은 S3 구성 변경은 항상 신중하게 수행해야 합니다. 이러한 설정은 재해 복구에 중요한 요소이며, 신중하게 처리하지 않으면 데이터가 영구적으로 손실될 수 있습니다.

5. 핵심 요약

• NatGateway-Bytes 또는 DataProcessing-Bytes 비용이 높게 나오는 경우 S3 Gateway Endpoint가 필요할 수 있습니다.
• Databricks 아카이브 지원을 매우 신중하게 활용하지 않는 한 S3 버킷의 아카이브 스토리지 클래스를 사용하지 마세요.
• Lakehouse 스토리지용 버킷에서 S3 객체 버전 관리를 비활성화하거나, 수명 주기 정책을 사용하여 짧은 기간이 지난 후 최신이 아닌 버전의 객체를 제거하세요.
• 검증된 Terraform 모듈을 활용하여 Delta Lake 스토리지 모범 사례로 새로운 인프라를 배포하여 반복적인 문제를 방지하세요.

6. 다음 단계 및 리소스

지금 바로 Lakehouse 스토리지에 대한 클라우드 스토리지를 최적화해 보세요! 이 블로그에서 제공하는 도구를 사용하여 후보 S3 버킷 및 VPC를 신속하게 식별하세요.

클라우드 스토리지 최적화에 대해 궁금한 점이 있으면 Databricks 계정팀에 문의하세요.

이 권장 사항을 사용하여 공유하고 싶은 성공 사례가 있다면 이 블로그를 공유하고 #databricks #dsa로 저희를 태그해 주세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)