Delta Lake 用 S3 バケットで“高くつく”設定ミスとその対策

1. はじめに: 基礎

S3などのクラウドオブジェクトストレージは、あらゆるレイクハウスアーキテクチャの基盤です。レイクハウス に置かれたデータの持ち主は、そのデータを利用するアプリケーションではなく、あくまでデータを管理するあなた自身です。ETLパイプラインや、テーブルにクエリを実行するユーザーが増えることでデータ量が増加するにつれて、クラウドストレージのコストも増加します。

実務の現場では、これらのストレージバケットの設定方法にいくつか典型的な落とし穴があり、そのせいで Delta Lake テーブルのコストを余計に支払ってしまうケースが見られます。こうした設定や運用を放置すると、実際には使っていないデータの保管や不要なデータ転送料が増え、ストレージとネットワークのコストが膨らんでしまいます。

このブログでは、最も一般的なミスを整理し、それを見つけ出して是正するための具体的な手順を紹介します。Databricks Data Intelligence Platform と AWS サービスの両方を活用しながら、ツールと運用ノウハウをバランス良く組み合わせていきます。

2. アーキテクチャに関する主な考慮事項

このブログでは、Delta テーブルのクラウドストレージコストを最適化する際に考慮すべき 3 つの側面について説明します。

• オブジェクトとテーブルのバージョニング - S3 と Delta Lake がデータをどのようにバージョニングするか。
• ストレージクラス (ホット/クール/コールド/アーカイブ) - 長期的でアクセス頻度の低いデータ向けの、より安価なストレージ。
• データ転送 - S3でのデータの読み書きにかかるコスト。

オブジェクトとテーブルのバージョニング

S3 などが提供するクラウドネイティブなオブジェクトバージョニング機能をそのまま使うだけでは、Delta Lake テーブルの動作と素直にかみ合いません。両者は「データをどのように保持・保護するか」という同じ課題を、異なるアプローチで解こうとしているため、結果的に Delta Lake の仕組みとぶつかってしまいます。​

これを整理するために、まず Delta テーブルがどのようにバージョン管理を行っているかを確認し、そのうえで S3 のネイティブなオブジェクトバージョニングと比較していきます。

Deltaテーブルにおけるバージョン管理の仕組み

Delta Lakeテーブルは、各トランザクションをマニフェストファイル（JSONまたはParquet形式）として_delta_log/ディレクトリに書き込みます。そして、これらのマニフェストはテーブル配下の実データファイル（Parquet形式）を指し示します。データが追加、変更、または削除されると、新しいデータファイルが作成されます。したがって、ファイルレベルの各オブジェクトはイミュータブル（不変）です。このアプローチにより、高速で効率的なデータアクセスと、高い信頼性をもつデータ整合性の両立を可能にしています。

Delta Lakeは、すべての変更を一連のトランザクションとしてトランザクションログに保存することで、その仕組み自体がバージョン管理になっています。各トランザクションはテーブルの新しいバージョンに相当しており、ユーザーはタイムトラベルで以前の状態にアクセスしたり、古いバージョンに復元したり、データリネージを監査したりできます。

S3がオブジェクトのバージョニングを処理する方法

S3もまた、バケットレベルの機能としてネイティブのオブジェクトバージョニングを提供しています。有効にすると、S3はオブジェクトの複数のバージョンを保持します。オブジェクトには最新バージョンが1つだけ存在し、それ以外を「非現行バージョン」として管理します。​

オブジェクトが上書きまたは削除されると、S3 は以前のバージョンを非現行としてマークし、新しいバージョンを現行として作成します。これにより、誤って削除や上書きを行ってしまっても、非現在バージョンを参照・復元することで元のデータを取り戻すことができます。

問題は、これが2つの点でDelta Lakeのバージョニングと競合することです:

1. Delta Lakeは、新しいトランザクションファイルとデータファイルを書き出すだけであり、既存ファイルを上書きすることはありません。
   • Deltaテーブルを構成するストレージオブジェクトには、Databricks Runtime のようなネイティブクライアントや、オープンソースの Unity Catalog REST API をサポートするエンジン経由でのみアクセス・操作すべきです。
   • Delta Lakeは、テーブルレベルのバージョニングとタイムトラベル機能により、誤った削除からの保護もそちらで提供しています。
2. トランザクションログで参照されなくなったファイルを削除するために、Delta テーブルのvacuum を実行します。
   • しかし、S3のオブジェクトバージョニング機能があるため、データは完全には削除されません。代わりに、データは非現行バージョンとなります。結果、論理的には不要になったデータに対して引き続き課金されます。

ストレージ階層

ストレージクラスの比較

S3は、保管中のデータを保存するための柔軟なストレージクラスを提供しており、これらはホット、クール、コールド、アーカイブに大別できます。これらは、データがアクセスされる頻度と、その取得にかかる時間を示します。

コールドなストレージクラスは、データを保存するためのGBあたりのコストは低いですが、取得時にはより高いコストとレイテンシーが発生します。これらをレイクハウスのストレージにも活用したいところですが、注意せずに適用すると、クエリーのパフォーマンスに重大な影響を与え、場合によってはすべてをS3 Standardに保存するよりもコストが高くなる可能性があります。

ストレージクラスの間違い

ライフサイクルポリシーを使用すると、S3 はオブジェクトが作成されてから一定期間が経過した後に、ファイルを異なるストレージクラスに自動的に移動できます。S3-IAのようなクール層は、取得時間が依然として速いため、一見すると安全な選択肢のように思えます。しかし、これは厳密なクエリーパターンに依存します。

たとえば、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 クラスに移動するとしましょう。同じ問題が発生しますが、今回は使用前に復元 (解凍) する必要があるファイルにアクセスしようとするため、クエリーは失敗します。この復元は手動のプロセスであり、通常はクラウドエンジニアまたはプラットフォーム管理者が実行します。完了までに最大 12 時間かかる場合があります。または、「迅速」な取得方法を選択することもできます。これには 1～5 分かかります。Glacier アーカイブストレージクラスからオブジェクトを復元する方法の詳細については、Amazon のドキュメントを参照してください。

これらのストレージクラスの落とし穴を軽減する方法については、後ほど見ていきます。

データ転送コスト

高コストなレイクハウスストレージの間違いに関する3番目のカテゴリは、データ転送です。データが保存されているクラウドリージョン、アクセス元、ネットワーク内でのリクエストのルーティング方法を考慮してください。

S3 バケットがあるリージョンとは別リージョンからデータにアクセスすると、そのアクセス分についてデータ転送料（データ egress コスト）が発生します。これは特にマルチリージョン構成（高可用性やディザスタリカバリ用途など）では頻発しやすく、請求書の中で無視できない金額になりがちです。

NAT ゲートウェイ

このカテゴリで最もよくある間違いは、S3 トラフィックを NAT Gateway 経由でルーティングすることです。defaultでは、プライベートサブネット内のリソースは、トラフィックをパブリック S3 endpoint（例: s3.us-east-1.amazonaws.com）にルーティングして S3 にアクセスします。これはパブリックホストであるため、トラフィックはサブネットの NAT Gateway 経由でルーティングされ、1 GB あたり約 0.045 ドルのコストが発生します。これは AWS Cost Explorer の サービス = Amazon EC2 および Usage Type = NatGateway-Bytes または Usage Type = <REGION>-DataProcessing-Bytes で確認できます。

EC2 インスタンスは AWS VPC 内で起動されるため、これには Databricks のクラシッククラスターと warehouse によって起動された EC2 インスタンスも含まれます。お使いの EC2 インスタンスが NAT Gateway とは異なるアベイラビリティーゾーン (AZ) にある場合、1 GB あたり約 0.01 ドルの追加コストも発生します。これは AWS Cost Explorer の サービス = Amazon EC2 および Usage Type = <REGION>-DataTransfer-Regional-Bytes または Usage Type = DataTransfer-Regional-Bytes で確認できます。

これらのワークロードは通常、S3の読み取りと書き込みの大きな部分を占めるため、この間違いがS3関連コストのかなりの割合を占める可能性があります。次に、これらの各問題に対する技術的なソリューションを詳しく見ていきましょう。

3. 技術的ソリューションの内訳

NAT Gateway S3コストの修正

S3 ゲートウェイ Endpoint

まず、おそらく最も簡単に修正できる問題、VPCネットワーキングから始めましょう。これにより、S3トラフィックがNATゲートウェイを使用せず、パブリックインターネットを経由することがなくなります。最も簡単なソリューションは、S3 Gateway Endpointを使用することです。これは、お使いのVPCと同じリージョンのS3トラフィックを処理するリージョナルVPC Endpoint サービスで、NATゲートウェイをバイパスします。S3 ゲートウェイ endpoint では、endpoint 自体や、それを通じて転送されるデータに対して費用はかかりません。

スクリプト：欠落しているS3 Gateway Endpointの特定

以下のPythonスクリプトは、リージョン内で現在S3 Gateway Endpointが設定されていないVPCを特定するためのものです。

注: このブログのこのスクリプトまたはその他のスクリプトを使用するには、Python 3.9以降とboto3 (pip install boto3) がインストールされている必要があります。また、AWS リソースへのアクセスが必要なため、Unity Catalog のサービスクレデンシャル（資格情報）を使用しないと、Serverless コンピュートでこれらのスクリプトを実行できません。

スクリプトをcheck_vpc_s3_endpoints.pyに保存し、次のコマンドでランします:

次のような出力が表示されるはずです:

これらのVPC候補を特定したら、AWSのドキュメントを参照してS3 Gateway Endpointを作成してください。

マルチリージョンS3ネットワーキング

マルチリージョン構成の S3 アクセスパターンが必要となる高度なユースケースでは、追加の構成作業が発生しますが、S3 インターフェイスエンドポイント（AWS PrivateLink for S3）を利用することが可能です。これらのアクセスパターンの詳細およびコスト比較例については、以下のDatabricks ブログをご覧ください:
Optimizing AWS S3 Access with Databricks

Classic vs Serverless Compute

Databricks では、 Serverless Lakeflow Jobs 、 Serverless SQL Warehouses 、 Serverless Lakeflow Spark Declarative Pipelines などの完全マネージド型 Serverless compute も提供しています。Serverless Computeでは、Databricks がお客様に代わってネットワーク経路を管理し、同一リージョン内の S3 へのトラフィックを S3 Gateway Endpoint を通じてプライベートにルーティングします。​

Serverless コンピュートプレーンから S3 へのトラフィックルーティングの仕組みについては、「Serverless compute plane networking」を参照してください。​

Databricks におけるアーカイブサポート

Databricks は、S3 Glacier Deep Archive および Glacier Flexible Retrieval に対応したアーカイブサポート機能を提供しており、Databricks Runtime 13.3 LTS 以降で Public Preview として利用可能です。 S3 ストレージクラスのライフサイクルポリシーを構成する必要がありつつも、アーカイブデータの低速または高コストなリストア処理を軽減したい場合に、この機能の利用が推奨されます。 アーカイブ機能を有効化すると、指定した期間より古いファイルを Databricks がクエリ処理時に無視するように構成されます。

アーカイブサポートでは、アーカイブされたファイルにアクセスすることなく正しく応答できるクエリーのみが許可されます。したがって、これらのテーブルでは、アーカイブされていないデータにのみアクセスするようにクエリーを制限するためにVIEWを使用することを強くお勧めします。そうしない場合、アーカイブされたファイル内のデータを必要とするクエリーは失敗し、ユーザーには詳細なエラーメッセージが表示されます。

注: テーブルにアーカイブサポートを有効化しても、S3 バケットに定義されたライフサイクル管理ポリシーが Databricks によって作成または変更されることはありません。 アーカイブ機能を正しく機能させるには、このテーブルプロパティを基盤となる S3 ライフサイクル管理ポリシーと整合するように構成する必要があります。 クラウドオブジェクトストレージ側にライフサイクルポリシーを設定していない状態でこのプロパティのみを有効にした場合、Databricks は指定したしきい値より古いファイルをクエリから除外しますが、S3 側のオブジェクトのライフサイクルやストレージクラスの変更には関与しません。

テーブルでアーカイブサポートを使用するには、まず次のテーブルプロパティを設定します:

次に、テーブルプロパティで指定された日数と同じ日数が経過した後にオブジェクトを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 ダッシュボードの Overview > Trends and distributionsに移動します。プライマリメトリクスとして % noncurrent version bytes を、セカンダリメトリクスとして Noncurrent version bytes を選択します。ダッシュボードの上部で、アカウント、リージョン、ストレージクラス、バケットで任意にフィルタリングできます。

上記の例では、ストレージの 40%、つまり物理データで約 40 TB が、非現行バージョンのバイトによって占められています。

次に、AWS Cost Explorerに移動します。右側で、フィルターを次のように変更します。

• サービス: S3 (Simple Storage Service)
• 使用タイプグループ: 該当するS3: Storage * usage type グループをすべて選択します。
  • S3: Storage - Express One Zone
  • S3: Storage - Glacier
  • S3: Storage - Glacier Deep Archive
  • S3: Storage - Intelligent Tiering
  • S3: Storage - One Zone IA
  • S3: Storage - Reduced Redundancy
  • S3: Storage - Standard
  • S3: Storage - Standard Infrequent Access

フィルターを適用し、グループで を API operation に変更すると、次のようなグラフが表示されます:

注: S3 Lensで特定のバケットに絞り込んだ場合は、Cost Explorerでタグ:NameをS3バケットの名前にフィルターして、そのスコープを一致させる必要があります。

これら 2 つのレポートを組み合わせると、Delta Lake テーブルに使用されている S3 バケットから非現行バージョンのバイトを削除することで、月間の平均 S3 ストレージコスト ($24,791) の約 40%、つまり月あたり $9,916 を節約できると見積もることができます。

最適化の実装

次に、非現行バージョンの最適化を 2 段階のプロセスで実装します。

1. 非現行バージョン向けのライフサイクルポリシーを実装します。
2. (任意) S3 バケットのオブジェクトバージョニングを無効にします。

非現行バージョン用のライフサイクルポリシー

AWSコンソール (UI) で、S3バケットの「管理」タブに移動し、「ライフサイクルルールを作成する」をクリックします。

ルールのスコープを選択:

• バケットにDeltaテーブルのみが保存されている場合は、「バケット内のすべてのオブジェクトに適用」を選択します。
• Deltaテーブルがバケット内の特定のプレフィックスに分離されている場合は、「1つ以上のフィルターを使用してこのルールの範囲を制限する」を選択し、プレフィックス（例: delta/）を入力します。

次に、[オブジェクトの非現行バージョンを完全に削除 ] チェックボックスをオンにします。

続いて、オブジェクトが非現行バージョンとなった後に保持する日数を指定します。​
この保持期間は、誤った削除操作からの復旧を可能にするバックアップ用途として利用されます。たとえば、ライフサイクルポリシーに 7 日を設定した場合、未使用データファイルを削除するために Delta テーブルで VACUUM を実行しても、そのファイルに対応する S3 非現行バージョンオブジェクトは 7 日間復元可能であり、その後恒久的に削除されます。

続行する前にルールを確認し、次に「ルールを作成」をクリックして設定を完了します。

これはTerraformでaws_s3_bucket_lifecycle_configurationリソースを使用しても実現できます。

オブジェクトバージョニングの無効化

AWS コンソールを使用して S3 バケットのオブジェクトバージョニングを無効にするには、バケットのプロパティタブに移動し、バケットのバージョニングプロパティを編集します。

注: 既存のバケットで一度バージョニングを有効化すると、その後は無効化はできず、一時停止（suspend）のみが可能です。一時停止すると、その後の操作では新しいオブジェクトバージョンは作成されませんが、既に存在しているバージョンはそのまま保持されます。

これはTerraformでaws_s3_bucket_versioningリソースを使用しても実現できます。

将来のデプロイ用Template

今後のS3バケットがベストプラクティスに沿って確実にデプロイされるように、terraform-databricks-sraで提供されているTerraformモジュール（unity_catalog_catalog_creationモジュールなど）を使用してください。このモジュールは、以下のリソースを自動的に作成します:

• Unity Catalog 外部ロケーションとして設定された S3 バケット
• Unity Catalog Storage Credential として設定された IAM ロール
• バケットをデフォルトのマネージドストレージとして使用する、新しいカタログの作成
• S3バケットを暗号化するためのカスタマーマネージドKMSキー
• S3 バージョニングの無効化
• S3バケットへのパブリックアクセスの無効化

Security Reference Architecture (SRA) モジュールに加えて、新しい Workspace の作成時に S3 用の VPC Gateway Endpoint をデプロイするために、Databricks Terraform プロバイダーガイドを参照できます。

4. 実際のシナリオ

このブログで紹介したS3コストを最適化するテクニックを適用することで、顧客はパフォーマンスを損なうことなく、レイクハウスのストレージコストを大幅に削減できます。

First Orion は、ブランドコミュニケーション、ブランドメッセージングと高度な通話保護ソリューションを提供する通信テクノロジー企業で、企業や大手キャリアが安全でパーソナライズされた電話体験を届けながら、同時にユーザーを詐欺・不正行為から保護しています。​同社は、本記事で紹介したベストプラクティスを Unity Catalog の S3 バケットに適用することで、月額 16,000ドル規模のストレージコスト削減を実現しました。

これらのストレージ最適化を確保する上で、通常トレードオフは発生しません。ただし、ライフサイクルポリシーやバージョニングなどの S3 設定の変更は、常に慎重に行う必要があります。これらの設定はディザスタリカバリにおいて重要な要素であり、慎重に取り扱わないと、データが永久に失われる可能性があります。

5. まとめ

• NatGateway-BytesまたはDataProcessing-Bytesのコストが高い場合は、S3 へのトラフィックが NAT Gateway 経由になっていることが原因かもしれません。S3 Gateway エンドポイントの利用をご確認ください。
• Databricksのアーカイブサポートを慎重に活用する場合を除き、S3バケットでアーカイブストレージクラスを使用することは避けてください。
• レイクハウスのストレージとして利用するバケットでは、S3オブジェクトのバージョニングを無効にするか、ライフサイクルポリシーを使用して短期間後に非現行バージョンのオブジェクトを削除することを推奨します。
• 新たなインフラ構築する際は、実績のあるTerraformモジュールを活用し、Delta Lakeストレージのベストプラクティスに沿って新しいインフラをデプロイすることで、同じ問題が繰り返し発生することを防ぐことができます。

6. 次のステップとリソース

レイクハウス向けのクラウドストレージ最適化は、今日からすぐに始められます。本ブログで紹介したツール群を活用し、対象となるS3バケットとVPCをすばやく確認してください。

クラウドストレージの最適化についてご不明な点がありましたら、担当のDatabricksアカウントチームにお気軽にお問い合わせください。

もし、この記事の推奨事項を使用した成功事例がありましたら、ぜひこのブログを共有し、#databricks #dsa のハッシュタグで私たちをタグ付けしてください！