DatabricksにおけるAWS S3アクセスの最適化

[Optimizing AWS S3 Access for Databricks \- The Databricks Blog](https://www.databricks.com/blog/2022/11/08/optimizing-aws-s3-access-databricks.html)の翻訳です。

:::note warn
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

オープンなクラウドネイティブレイクプラットフォームであるDatabricksは、データウェアハウスとデータレイクのベストな機能を組み合わせることで、データ、分析、AIをシンプルにし、データチームが自身のデータとAIのユースケースを容易にデリバリーできる様に設計されています。

データとAIのアプリケーションを構築するという目的のもと、Databricksは2つのコアコンポーネントから構成されています: コントロールプレーンとデータプレーンです。コントロールプレーンはDatabricksによって完全に管理され、Web UI、ノートブック、ジョブ、クエリー、クラスターマネージャから構成されています。データプレーンはお使いのAWSアカウントに存在しており、データを処理するためにDatabricksクラスターが動作しています。
![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-1.png)
*アーキテクチャ概要*

# 概要

皆様が[レイクハウスアーキテクチャ](https://qiita.com/taka_yayoi/items/438f762126f57868aa35)に慣れ親しんでいるのであれば、皆様がクラウドオブジェクトストレージをよく知っていると仮定しても問題ないでしょう。クラウドオブジェクトストアは、他のクラウドデータベースやオンプレミスの代替案よりも、通常は安価に様々な種類のデータを格納できるので、レイクハウスアーキテクチャにおけるキーコンポーネントとなっています。本書では、特に一つのクラウドオブジェクトストア、[Amazon Simple Storage](https://qiita.com/taka_yayoi/items/a26a1fb49c0e217ad10b) (S3)の読み書きにフォーカスします。同様にこのアプローチはAzure DatabricksのAzure Data Lake Storageや、Databricks on Google CloudのGoogle Cloud Storage (GCS)にも適用できます。

Amazon Web Services (AWS)はバーチャルプライベートクラウド(VPC)を設計するための数多くの方法を提供しているので、DatabricksクラスターがS3バケットにアクセスするために取りうる数多くのパスが存在します。

この記事では、最も一般的なS3へのネットワークアクセスアーキテクチャのいくつかとAWSクラウドコストを削減するためにどの様に最適化するのかを議論します。ご自身の[顧客管理VPC](https://qiita.com/taka_yayoi/items/f23bd799e1960e2eccbe)にDatabricksをデプロイした後に、データがすでに存在している場所に可能な限り安価かつシンプルにしたいと考えます。

ここでカバーする5つのシナリオを以下に示します。

- 一つのアベイラビリティゾーン(AZ)に一つのNATゲートウェイ
- 二つのアベイラビリティゾーンに二つのNATゲートウェイ
- S3ゲートウェイエンドポイント
- クロスリージョン - S3ゲートウェイエンドポイントとNAT
- クロスリージョン - S3インタフェースエンドポイント

:::note
**注意**
これらのシナリオをウォークスルーする前に、コストのステージとサンプルのDatabricksワークスペースアーキテクチャを設定したいと思います。

- 見積もりにおいて発生しうるポテンシャルコストをウォークスルーします。これらのコストはUSDであり、AWSリージョンのNorth Virginia (us-east-1)でモデル化されるので、お使いのAWS環境のクラウドコストを保証するものではありません。
- Databricksワークスペースを2つのアベイラビリティゾーン(AZ)にデプロイしているものとします。リージョンのすべてのアベイラビリティゾーンに対してDatabricksワークスペースをデプロイすることができますが、本書の目的に沿う様にシンプルにしています。
:::

# 一つのアベイラビリティゾーン(AZ)に一つのNATゲートウェイ

Databricksで最も頻繁に見かけるアーキテクチャは、クラスターに2つのアベイラビリティゾーンを用い、単体のNATゲートウェイを設置し、S3ゲートウェイエンドポイントは無い構成となります。これで何が悪いのでしょうか？動作しますが、このアーキテクチャではいくつかの課題があります。

1. 単一のAZが障害点となります。もしAZ1に問題が生じた場合、あなたのDatabricksデプロイメントでAZ1にしかNATゲートウェイがなかったとしたら、クラスターがAZ2にあったとしても、あなたの環境は危険にさらされます。
1. AZ1にしかNATゲートウェイが存在しないので、AZ2のクラスターからのトラフィックは、AZ間のデータ課金が発生させます。現時点でのリストプライスは、それぞれの方向で[GBあたり$0.01](https://aws.amazon.com/ec2/pricing/on-demand/)です。
![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-2.png)
*単一のアベイラビリティゾーンに単一のNATゲートウェイ*

このアーキテクチャにおけるデータ転送コストはどうなるでしょうか？

AZ1のクラスターはトラフィックをAZ1のNATゲートウェイにルーティングし、インターネットゲートウェイを出てパブリックのS3エンドポイントに到達します。AZ2のクラスターはAZをまたがってトラフィックを送信しなくてはならず、AZ2からAZ1のNATゲートウェイ、インターネットゲートウェイを出てパブリックのS3エンドポイントに到達します。このため、AZ2はAZ1よりも多いデータ転送コストを引き起こします。

**サンプルシナリオ:** アベイラビリティゾーンごとに5TB、月当たり10TBを処理

- **AZ1のコスト:**
    - NAT GW経由で5120GB = GBあたり\\$0.045 * 5120 = \\$230.40
    - NAT GWは時間当たり\\$0.045 * 月当たり730時間 = \\$32.85
- **AZ2のコスト:**
    - NAT GW経由で5120GB = GBあたり\\$0.045 * 5120 = \\$230.40
    - AZ横断で5120GB = GBあたり\\$0.01 * 5120 = \\$51.20
- **合計:** \\$544.85

[AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html)では、バイト当たりのNAT Gatewayとバイト当たりのリージョン間データ転送(AZ横断データチャージ)の高いコストを目撃することでしょう。

# 二つのアベイラビリティゾーンに二つのNATゲートウェイ

それでは、2つ目のNATゲートウェイを稼働させることでよりコスト効率を高め、可用性を改善できるのでしょうか？
![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-3.png)
*高可用性のためのマルチNATゲートウェイ*

**サンプルシナリオ:** アベイラビリティゾーンごとに5TB、月当たり10TBを処理

- **AZ1のコスト:**
    - NAT GW経由で5120GB = GBあたり\\$0.045 * 5120 = \\$230.40
    - NAT GWは時間当たり\\$0.045 * 月当たり730時間 = \\$32.85
- **AZ2のコスト:**
    - NAT GW経由で5120GB = GBあたり\\$0.045 * 5120 = \\$230.40
    - NAT GWは時間当たり\\$0.045 * 月当たり730時間 = \\$32.85
- **合計:** \\$526.50 (3.5%の節約 = 月当たり\\$18.35)

このことから、NATを追加することでアーキテクチャの可用性を高め、コストを削減することができます。しかし、3.5%は自慢するには少なすぎませんか？より良い方法はないのでしょうか？

# S3ゲートウェイエンドポイント

[S3ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)にようこそ。**お客さまが最もセキュアな方法でS3にアクセスしたいと考え、NATゲートウェイとインターネットゲートウェイを経由したくないと考えることは一般的なアーキテクチャのパターンです。**

この一般的なアーキテクチャパターンによって、AWSはS3ゲートウェイあエンドポイントをリリースしました。これは、リージョナルVPCエンドポイントサービスであり、お使いのS3バケットのリージョンと同じリージョンに作成する必要があります。

以下の図でわかる様に、同じリージョンにあるバケットに対するいかなるS3リクエストはS3ゲートウェイエンドポイントにルーティングされ、完全にNATゲートウェイをバイパスします。ベストな部分は、エンドポイントやエンドポイントを経由するデータに課金が発生しないことです。
![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-4.png)
*S3ゲートウェイエンドポイント*

S3のデータにアクセスするためにNATゲートウェイとインターネットゲートウェイを使わず、S3ゲートウェイエンドポイントを使った際の見積もりコストはどうなるのでしょうか？

- **AZ1のコスト:**
    - S3ゲートウェイエンドポイント経由で5120GB = **無料** = \\$0
    - NAT GWは時間当たり\\$0.045 * 月当たり730時間 = \\$32.85
- **AZ2のコスト:**
    - S3ゲートウェイエンドポイント経由で5120GB = **無料** = \\$0
    - NAT GWは時間当たり\\$0.045 * 月当たり730時間 = \\$32.85
- **合計:** \\$65.70 (87.5%の節約 = 月当たり\\$460.80)

**87.5%の節約**、NATよ、我々は何を話しているんだ？

*バイト当たりのNATゲートウェイとバイト当たりのリージョン間データ転送*が高コストになっているのであれば、[S3ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)によってメリットを得ることができます。すぐにでもS3ゲートウェイエンドポイントを設定し、データ転送コストを削減しましょう！

# クロスリージョン - S3ゲートウェイエンドポイントとNAT

上述した様にS3ゲートウェイエンドポイントはデータが同じリージョンにある場合に動作しますが、複数のリージョンにデータがある場合にはどうなるのでしょうか、これに対して何ができるのでしょうか？

あなたのデータとDatabricksのデータプレーンが同じリージョンに存在する際には、パフォーマンスとコストはベストになります。しかし、これは常に可能とは限りません。別のリージョンにバケットがある場合、トラフィックはどの様に流れるのでしょうか？

以下の図では、Databricksのデータプレーンはus-east-1に存在しますが、S3バケットのデータはus-west-2に存在します。VPCアーキテクチャに手を加えない場合、us-west-2のバケットに対するすべてのトラフィックはNATゲートウェイを経由しなくてはなりません。

*S3ゲートウェイはリージョナルであることを思い出してください！*

![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-5.png)
*クロスリージョン: NATゲートウェイとS3ゲートウェイエンドポイント*

クロスリージョントラフィックのケースでは、コストはどの様になるのでしょうか？

**サンプルシナリオ:** 10TBのクロスリージョン

- NAT GW経由の10TB = 10TB(10,240GB) * GB当たり\\$0.045 = \\$460.80
- クロスリージョンのデータ転送 = 10TB(10,240GB) * GB当たり\\$0.02 = \\$204.80
- **合計:** \\$665.60

# クロスリージョン - S3インタフェースエンドポイント

上述した通り、2021年10月まではNATゲートウェイを通じてパブリックなエンドポイントを使うことなしに、異なるリージョンにあるS3に接続することはシンプルなタスクではありませんでした。

しかし、AWSは自身の[PrivateLink](https://aws.amazon.com/privatelink/)サービスを立ち上げ、すぐに[S3インタフェースエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html)をリリースしました。これによって、管理者は、依然としてVPC、バケット、アカウント、企業のアクセスポリシーを強制しながらも、リージョン間接続に既存のプライベートネットワークを使用することができます。これは、異なるリージョンのVPCにアクセスし、インタフェースエンドポイントにS3のトラフィックを直接ルーティングできることを意味します。

以下の図に示すアーキテクチャを実現するには、いくつかのことが必要となります:

1. 接続したい2つのリージョン間の[VPCピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)(AWS Transit Gatewayを使うこともできますが、この記事の執筆時点では再安価なアーキテクチャであるVPCピアリングを使います)
1. リモートリージョンの[S3インタフェースエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html)
1. S3リクエストをS3インタフェースエンドポイントにルーティングする様にDNSの変更

![](https://cms.databricks.com/sites/default/files/inline-images/db-384-blog-img-6.png)
*クロスリージョン: S3インタフェースエンドポイント*

これで別のリージョンにS3インタフェースエンドポイントを設けましたが、リージョナルS3エンドポイントとNATゲートウェイを比較した際、データ転送コストはどの様になるのでしょうか？

**サンプルシナリオ:** 10TBのクロスリージョン

- インタフェースエンドポイント経由の10TB = 10TB(10,240GB) * GB当たり\\$0.01 = \\$102.40
- S3インタフェースエンドポイント = 時間あたり\\$0.01 * 月当たり730時間 = \\$7.30
- クロスリージョンのデータ転送 = 10TB(10,240GB) * GB当たり\\$0.02 = \\$204.80
- **合計:** \\$314.50(52%節約、月当たり\\$351.10)

# 次にすべきことは？

- バイト当たりのNATゲートウェイとバイト当たりのリージョン間データ転送のコストが高価になっているかどうかを確認するために、[AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html)を活用しましょう。
- 多くの場合、NATゲートウェイよりもS3エンドポイントの方が優れています。Databricksクラスターがアクセスできる様に設定しましょう。[AWS VPC Reachability Analyser](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html)を用いてルーティングをテストすることができます。

データ転送コストの削減の役に立てば幸いです！これらのアーキテクチャのいずれかをさらに詳細に議論したいのであれば、Databricks担当者にご連絡ください。

### Databricks 無料トライアル

[Databricks 無料トライアル](https://databricks.com/jp/try-databricks)