Databricks S3コミットサービス関連の設定

Databricks は、複数のクラスターから Amazon S3 への書き込みを調整するコミットサービスを実行します。このサービスは、Databricksコントロールプレーンで実行されます。セキュリティを強化するために、「直接アップロードの最適化を無効にする」の説明に従って、サービスの直接アップロードの最適化を無効にすることができます。 S3 バケットへのアクセスをさらに制限するには、「特定の IP アドレスへのアクセスを制限する」を参照してください。

S3 コミットサービスに関連する AWS GuardDuty アラートを受信した場合は、「 S3 コミットサービスに関連する AWS GuardDuty アラート」を参照してください。

コミットサービスについて

S3コミットサービスは、特定の場合に単一テーブル上の複数のクラスター間で書き込みの一貫性を保証するのに役立ちます。たとえば、コミットサービスは、Delta LakeよるACIDトランザクションの実装に役立ちます。

デフォルト構成では、Databricks は、コミットサービス API 呼び出しで、コンピュートプレーンからコントロールプレーンに一時的な AWS 資格情報を送信します。インスタンスプロファイルの認証情報は 6 時間有効です。

コンピュートプレーンは S3 に直接データを書き込み、コントロールプレーンの S3 コミットサービスは、コミットログのアップロードを完了 (以下で説明するマルチパートアップロードの完了) することで、同時実行制御を提供します。コミットサービスは S3 からデータを読み取りません。新しいファイルが存在しない場合は、S3 に新しいファイルを配置します。

Databricks コミットサービスによって S3 に書き込まれる最も一般的なデータは、列の最小値や最大値など、データからの統計集計を含む Delta ログです。ほとんどのDelta ログデータは、Amazon S3 マルチパートアップロードを使用してコントロールプレーンから S3 に送信されます。

クラスターがマルチパートデータをステージングして Delta ログを S3 に書き込んだ後、Databricks コントロールプレーンの S3 コミットサービスは、S3 に完了を通知して S3 マルチパートアップロードを完了します。非常に小さな更新のパフォーマンス最適化として、デフォルトでは、コミットサービスは小さな更新をコントロールプレーンから S3 に直接プッシュすることがあります。このダイレクト・アップデートの最適化は使用不可にすることができます。「直接アップロードの最適化を無効にする」を参照してください。

Delta Lakeに加え、次のDatabricks機能も同じS3コミットサービスを使用します。

Amazonは、オブジェクトがまだ存在しない場合にのみオブジェクトを配置する操作を提供していないため、コミットサービスが必要です。Amazon S3は分散システムです。S3が同じオブジェクトに対する複数の書き込みリクエストを同時に受信した場合、最後に書き込まれたオブジェクトを除くすべてのオブジェクトが上書きされます。コミットを一元的に検証する機能がなければ、異なるクラスターからの同時コミットによってテーブルが破損する可能性があります。

S3コミットサービスに関連するAWS GuardDutyアラート

重要

Unity Catalogによって管理されるテーブルへのコミットはGuardDutyアラートをトリガーしません。

AWS GuardDutyを使用し、AWS IAMインスタンスプロファイルを使用してデータにアクセスする場合、GuardDutyはDelta Lake、構造化ストリーミング、Auto Loader、または COPY INTOに関連するデフォルトのDatabricksの動作に対してアラートを作成する可能性があります。これらのアラートは、デフォルトで有効になっているインスタンス認証情報の漏洩検出に関連しています。アラートには、UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWSというタイトルが含まれます。

元のS3データアクセスIAMロールの役割を引き受けるAWSインスタンスプロファイルを作成することで、S3コミットサービスに関連するGuardDutyアラートに対処するようにDatabricksデプロイメントを構成できます。

Instance プロファイルの資格情報を使用する代わりに、この新しい Instance プロファイルでは、クラスターが短期間のトークンの役割を引き受けるように構成できます。この機能は、すべての最近のDatabricks Runtimeバージョンに既に存在しており、クラスターポリシーを介してグローバルに適用できます。

まだ作成していない場合は、S3データにアクセスするための通常のインスタンスプロファイルを作成します。このインスタンスプロファイルは、インスタンスプロファイルの認証情報を使用してS3データに直接アクセスします。

このセクションでは、このインスタンスプロファイルのロールARNを<data-role-arn>と呼びます。
トークンを使用し、データに直接アクセスするインスタンスプロファイルを参照する新しいインスタンスプロファイルを作成します。クラスターは、この新しいトークンベースのインスタンスプロファイルを参照します。「チュートリアル: インスタンスプロファイルを使用して S3 アクセスを設定する」を参照してください。

このインスタンスプロファイルには、S3への直接アクセスは必要ありません。代わりに、データアクセスに使用するIAMロールを引き受けるためのアクセス許可のみが必要です。このセクションでは、このインスタンスプロファイルのロールARNを<cluster-role-arn>と呼びます。
1. 新しいクラスターインスタンスプロファイルのIAMロール（<cluster-role-arn>）にアタッチされたIAMポリシーを追加します。次のポリシーステートメントを新しいクラスターインスタンスプロファイルのIAMロールに追加し、<data-role-arn>をバケットにアクセスする元のインスタンスプロファイルのARNに置き換えます。
```
{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "<data-role-arn>"
}
```
2. 既存のデータアクセスIAMロールに信頼ポリシーステートメントを追加し、<cluster-role-arn> をバケットにアクセスする元のインスタンスプロファイルのARNに置き換えます。
```
{
  "Effect": "Allow",
  "Principal": {
      "AWS": "<cluster-role-arn>"
  },
  "Action": "sts:AssumeRole"
}
```
DBFSを使用せずにS3に直接接続するノートブックコードを使用するには、新しいトークンベースのインスタンスプロファイルを使用し、データアクセスロールを引き受けるようにクラスターを構成します。
- すべてのバケットにS3アクセスできるようにクラスターを構成します。クラスターのSpark設定に以下を追加します。
```
fs.s3a.credentialsType AssumeRole
fs.s3a.stsAssumeRole.arn <data-role-arn>
```
- これは、特定のバケットに対して設定できます。
```
fs.s3a.bucket.<bucket-name>.aws.credentials.provider org.apache.hadoop.fs.s3a.auth.AssumedRoleCredentialProvider
fs.s3a.bucket.<bucket-name>.assumed.role.arn <data-role-arn>
```

ダイレクトアップロードの最適化を無効にする

非常に小規模な更新では、パフォーマンスの最適化のため、コミットサービスにより、デフォルトで小規模な更新をコントロールプレーンからS3に直接プッシュすることがあります。この最適化を無効にするには、Sparkパラメーターspark.hadoop.fs.s3a.databricks.s3commit.directPutFileSizeThresholdを0に設定します。この設定はクラスターのSpark構成に適用することも、クラスターポリシーを使用して設定することもできます。

この機能を無効にすると、小さな更新が常に行われるリアルタイムの構造化ストリーミングクエリーのパフォーマンスに若干影響する可能性があります。本番環境でこの機能を無効にする前に、データを使ってパフォーマンスへの影響をテストすることを検討してください。

特定の IP アドレスへのアクセスを制限する

特定の S3 バケットに特定の IP アドレスからのみアクセスできるように制限できます。たとえば、S3 コミットサービスを含む Databricks コントロールプレーンの IP アドレスと独自の環境のみへのアクセスを制限できます。これにより、資格情報が他の場所から使用されるリスクが軽減されます。「 (オプション) S3 バケットへのアクセスを制限する」を参照してください。