AWS Glue 用のクロスクラウド Lakehouse を設定する

このドキュメントでは、Apache Iceberg 用のクロスクラウド Lakehouse を設定して、 Google Cloud内から AWS Glue カタログのデータを直接クエリする方法について説明します。この機能により、外部データソースを既存の Google Cloud 環境と統合して、データ分析を統合できます。

その後、Lakehouse を使用して、フェデレーション データへのアクセスを管理できます。

始める前に

  1. Lakehouse の概要を確認して、Lakehouse がデータへのアクセスを管理する方法を理解します。
  2. その仕組みについては、クロスクラウド Lakehouse についてをご覧ください。
  3. サポートされているカタログを確認して、テーブル形式の要件とサポートされている構成を確認します。
  4. AWS 管理者に Identity and Access Management(IAM)ロールを作成し、権限ポリシーを構成する権限があることを確認します。
  5. 省略可: Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)間のプライベート相互接続を介してクエリをルーティングする場合は、リモート プロバイダのアカウントが有効になっていること、Cross-Cloud InterconnectまたはPartner Interconnectをプロビジョニングしていること、Cloud Router との BGP セッションを確立していること、両方のクラウド環境で必要な IAM 権限があることを確認します。
  6. Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
  7. Verify that billing is enabled for your Google Cloud project.

  8. Enable the BigLake API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the BigLake API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

必要なロール

クロスクラウド Lakehouse の設定に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

  • Lakehouse カタログを管理する: BigLake 管理者 roles/biglake.admin
  • プライベート相互接続経由でトラフィックを転送する: Compute ネットワーク管理者(roles/compute.networkAdmin)、Service Directory 閲覧者(roles/servicedirectory.viewer)、Service Directory PSC 承認済みサービス(roles/servicedirectory.pscAuthorizedService

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

制限事項と考慮事項

このセクションでは、クロスクラウド Lakehouse の使用に関する制限事項と考慮事項について説明します。

  • サポートされているクラウド プロバイダ: クロスクラウド Lakehouse でのプライベート相互接続の使用は、次のリモート クラウド プロバイダでサポートされています。Amazon Web Services(AWS)。Cross-Cloud InterconnectまたはPartner Interconnectのいずれかを使用できます。
  • ネットワーク ルーティング: プライベート相互接続(お客様所有の CCI や Partner Interconnect など)が構成されていない場合、クエリは公共のインターネット経由でルーティングされます。これにより、リモート クラウド プロバイダからの下り(外向き)料金が増加し、パフォーマンスの予測が難しくなる可能性があります。
  • データの更新速度: フェデレーション カタログの --refresh-interval フラグは、メタデータの同期頻度を決定します。間隔を短くすると、より新しいデータが提供されますが、リモート カタログ プロバイダから追加の API 費用が発生する可能性があります。
  • Iceberg 指標レポート: Iceberg 指標レポートは、フェデレーション カタログでは使用できません。連携カタログにアクセスするときに、Iceberg クライアントで rest-metrics-reporting-enabled プロパティを false に設定します。

全般的なワークフロー

クロスクラウド Lakehouse を設定して使用する一般的な手順は次のとおりです。

  • Cross-Cloud Interconnect を設定する(省略可): Google Cloud VPC とリモート クラウド プロバイダの間にプライベート接続を構成します。
  • 連携を設定する: リモート プロバイダのプレースホルダ信頼ポリシーを使用して IAM ロールを作成し、認証を構成します。次に、Lakehouse にフェデレーション カタログを作成し、信頼ポリシーを更新します。
  • 接続を確認する: Lakehouse がリモート カタログに正常に接続できることを確認します。
  • データをクエリする: BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。詳細については、クロスクラウド Lakehouse を使用するをご覧ください。
  • 権限を構成する: IAM を使用して、フェデレーション データの表示とクエリを実行できるユーザーを管理します。

Cross-Cloud Interconnect を設定する(省略可)

リモート カタログへのクエリは、デフォルトで公共のインターネットを経由します。セキュリティとコンプライアンスの強化、予測可能なパフォーマンスの提供、データ転送費用の削減に役立つプライベート相互接続を使用します。これにより、 Google CloudVirtual Private Cloud(VPC)とリモート クラウド プロバイダのネットワーク(AWS など)の間に専用のプライベート ネットワーク接続が確立されます。

Google Cloud VPC とリモート クラウド プロバイダの VPC(AWS など)の間に、次のいずれかのプライベート相互接続オプションをプロビジョニングして構成できます。

Google Cloud の Cloud Router とリモート クラウド プロバイダの VPC の間に BGP セッションを確立し、ルート交換を確保します。

プライベート クエリを有効にするには、プライベート相互接続を介して、Lakehouse からリモート ストレージ バケット(AWS Amazon S3 バケットなど)へのパスを構成する必要があります。このルーティングを構成するには、次の 2 つのアーキテクチャ フローがあります。

  • 内部リージョン プロキシ ネットワーク ロードバランサのルーティング: このフローでは、Google Cloud 内部リージョン プロキシ ネットワーク ロードバランサを使用して、複数の AWS Elastic Network Interface(ENI)を指すハイブリッド接続ネットワーク エンドポイント グループ(NEG)間でリクエストを分散します。このフローは、ロード バランシング、スケーラビリティ、高可用性に不可欠です。Partner Interconnect には必須であり、ロード バランシング、スケーラビリティ、高可用性を実現するために Cross-Cloud Interconnect に推奨されます。
  • 直接エンドポイント ルーティング: このフローは、Service Directory を単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接接続します。このフローは Cross-Cloud Interconnect でのみ機能し、Partner Interconnect ではサポートされていません。

アーキテクチャ要件に合った構成フローを選択します。

内部リージョン プロキシ ネットワーク ロードバランサ

高可用性とロード バランシングのために、複数の AWS ENI にリクエストを分散するように内部リージョン プロキシ ネットワーク ロードバランサを構成する手順は次のとおりです。

AWS ネットワーキングを構成する

まず、Amazon S3 VPC インターフェース エンドポイント(AWS PrivateLink)を作成します。

  1. AWS VPC コンソールで、Amazon S3 のインターフェース エンドポイントを作成します。
  2. サービス名に「com.amazonaws.<var>AWS_REGION</var>.s3」と指定します。
  3. Direct Connect を介して Google Cloud VPC に接続されている VPC とサブネットを選択します。
  4. セキュリティ グループをエンドポイントに接続して、インバウンド アクセスを制御します。
  5. これにより、選択した各サブネットに Elastic Network Interface(ENI)がプロビジョニングされます。これらの ENI のプライベート IP アドレスをメモします。

次に、セキュリティ グループを構成します。

  • Amazon S3 エンドポイント ENI に関連付けられているセキュリティ グループで、 Google Cloud VPC の関連する IP 範囲からのポート 443 での上り(内向き)TCP トラフィックが許可されていることを確認します。

Google Cloud ネットワーキングを構成する

ハイブリッド エンドポイント用に内部リージョン プロキシ ネットワーク ロードバランサを設定するの手順に沿って操作します。

手順に沿って操作する際は、次の点に注意してください。

  • ハイブリッド接続 NEGNON_GCP_PRIVATE_IP_PORT)を作成し、前に作成した AWS ENI のプライベート IP アドレスを追加します。
  • NEG、ヘルスチェック、転送ルールに TCP ポート 443 を使用します。
  • フェデレーション カタログと同じ Google Cloud リージョンにロードバランサを設定します。

ロードバランサの転送ルールを作成したら、割り当てられた内部 IP アドレスをメモします。これが ILB_IP_ADDRESS です。

Service Directory を構成する

Lakehouse が検出できるように、ILB の IP アドレスを Service Directory に登録します。

  1. リモート クラウドの Namespace を作成します。

    gcloud service-directory namespaces create NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • NAMESPACE: 名前空間の一意の識別子。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
  2. Service Directory 名前空間にサービスを作成します。

    gcloud service-directory services create SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • SERVICE_NAME: サービスの一意の識別子。
  3. サービスで ILB のエンドポイントを作成します。

    gcloud service-directory endpoints create ENDPOINT_NAME \
        --project=PROJECT_ID \
        --namespace=NAMESPACE \
        --service=SERVICE_NAME \
        --location=REGION \
        --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
        --address=ILB_IP_ADDRESS \
        --port=443

    次のように置き換えます。

    • ENDPOINT_NAME: エンドポイントの一意の識別子。
    • PROJECT_NUMBER: Google Cloudプロジェクト番号。--network フラグでプロジェクト番号を使用します。
    • ILB_IP_ADDRESS: ILB 転送ルールの内部 IP アドレス。

直接エンドポイント

トラフィックを単一の AWS インターフェース VPC エンドポイントの IP アドレスに直接転送するようにサービス ディレクトリを構成するには、次の操作を行います。

  1. AWS VPC 内の Amazon S3 用にインターフェース VPC エンドポイントを作成します。このエンドポイントの IP アドレスとポートをメモします。
  2. リモート クラウドの Namespace を作成します。

    gcloud service-directory namespaces create NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • NAMESPACE: 名前空間の一意の識別子。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
    • REGION: Google Cloud のリージョン。例: us-east4これは、フェデレーション カタログと同じリージョンにする必要があります。
  3. Service Directory 名前空間にサービスを作成します。

    gcloud service-directory services create SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION

    次のように置き換えます。

    • SERVICE_NAME: サービスの一意の識別子。
  4. Amazon S3 インターフェース VPC エンドポイントのルーティング情報を含むエンドポイントをサービスに作成します。

    gcloud service-directory endpoints create ENDPOINT_NAME \
        --service=SERVICE_NAME \
        --namespace=NAMESPACE \
        --project=PROJECT_ID \
        --location=REGION \
        --address=S3_VPCE_IP_ADDRESS \
        --port=S3_VPCE_PORT \
        --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK

    次のように置き換えます。

    • ENDPOINT_NAME: エンドポイントの一意の識別子。
    • S3_VPCE_IP_ADDRESS: Amazon S3 インターフェース VPC エンドポイントの IP アドレス。例: 10.0.1.45
    • S3_VPCE_PORT: Amazon S3 インターフェース VPC エンドポイントのポート番号。例: 443
    • PROJECT_NUMBER: Google Cloudプロジェクト番号。--network フラグでプロジェクト番号を使用します。
    • VPC_NETWORK: プライベート相互接続に関連付けられている Google Cloud VPC ネットワーク名。

クロスクラウド連携を設定する

データをクエリするには、リモート AWS カタログに接続する Lakehouse 連携カタログを設定します。

プレースホルダ信頼ポリシーを使用して AWS IAM ロールを作成する

Lakehouse は、カタログの作成後に Google サービス アカウント ID をプロビジョニングします。プレースホルダ信頼ポリシーを使用して AWS IAM ロールを作成します。

  1. trust_policy.json という名前のファイルを作成します。

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "accounts.google.com"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "accounts.google.com:aud": [
                "PLACEHOLDER_VALUE"
              ],
              "accounts.google.com:sub": [
                "PLACEHOLDER_VALUE"
              ]
            }
          }
        }
      ]
    }
  2. AWS CLI コマンドを実行して、プレースホルダ信頼ポリシーでロールを作成します。長時間実行されるジョブで認証情報の有効期限が切れないように、最大セッション時間を 12 時間(43200 秒)に設定することをおすすめします。

    aws iam create-role \
      --role-name AWS_ROLE_NAME \
      --assume-role-policy-document file://trust_policy.json \
      --max-session-duration 43200

    次のように置き換えます。

    • AWS_ROLE_NAME: AWS IAM ロールの名前。例: biglake_glue_federation_role

権限ポリシーを適用する

Lakehouse が AWS リージョンの Glue Data Catalog と S3 バケットにアクセスできるようにする権限ポリシーを IAM ロールに適用します。このポリシーは、AWS Lake Formation S3 テーブル統合を使用する場合に、S3 テーブル バケットへのアクセス権も付与します。デフォルトの AWS Glue データ権限から AWS Lake Formation モデルにアップグレードした場合は、代わりに Lake Formation で追加の権限を付与する必要がある場合があります。

  1. 次のポリシー構成を含む permissions_policy.json という名前のファイルを作成します。

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "GlueRead",
          "Effect": "Allow",
          "Action": [
            "glue:GetCatalog",
            "glue:GetDatabase",
            "glue:GetDatabases",
            "glue:GetTable",
            "glue:GetTables"
          ],
          "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
        },
        {
          "Sid": "S3Read",
          "Effect": "Allow",
          "Action": [
            "s3:ListBucket",
            "s3:GetObject"
          ],
          "Resource": [
            "arn:aws:s3:::*"
          ]
        },
        {
          "Sid": "S3TablesRead",
          "Effect": "Allow",
          "Action": [
            "s3tables:GetTableBucket",
            "s3tables:ListNamespaces",
            "s3tables:GetNamespace",
            "s3tables:ListTables",
            "s3tables:GetTable",
            "s3tables:GetTableMetadataLocation",
            "s3tables:GetTableData"
          ],
          "Resource": [
            "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
          ]
        }
      ]
    }
  2. この権限ポリシーを IAM ロールに関連付けます。

    aws iam put-role-policy \
      --role-name AWS_ROLE_NAME \
      --policy-name AWS_POLICY_NAME \
      --policy-document file://permissions_policy.json

    次のように置き換えます。

    • AWS_ROLE_NAME: AWS IAM ロールの名前。例: biglake_glue_federation_role
    • AWS_POLICY_NAME: 権限ポリシーの名前。例: biglake_glue_permissions
    • AWS_REGION: Glue カタログまたは S3 テーブルが存在する AWS リージョン。例: us-east-1
    • AWS_ACCOUNT_ID: 12 桁の AWS アカウント ID 文字列。例: 123456789012

連携カタログを作成する

gcloud CLI または REST API を使用して、 Google Cloud にフェデレーション カタログを確立します。

AWS 信頼関係の伝播中にメタデータの同期が早期に失敗するのを防ぐには、更新スケジュールを指定せずに(デフォルトの 0s になります)カタログを初期化します。

Google Cloud CLI

公共のインターネット(CCI なし)

CCI を構成しない場合、接続は公共のインターネット経由で安全に転送されます。

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME"

お客様所有(CCI)

プライベート インターコネクト(Dedicated CCI や Partner Interconnect など)を構成した場合は、Lakehouse がトラフィックをプライベートにルーティングするように、Service Directory サービス参照を指定します。

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

REST

curl -s -X POST \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_NAME"'"
      }
    }
  }'

次のように置き換えます。

  • FEDERATED_CATALOG_NAME: フェデレーション カタログの名前。
  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • REGION: 連携カタログが作成される Lakehouse リージョン。例: us-east4
  • GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: ターゲットのウェアハウス カタログの識別子。AWS リージョンの Glue Data Catalog の場合は、12 桁の AWS アカウント ID 文字列を入力します。例: 123456789012リージョンで S3 テーブル バケットを使用するには、AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET と入力します。例: 123456789012:s3tablescatalog/my-table-bucket
  • AWS_ACCOUNT_ID: 12 桁の AWS アカウント ID 文字列。例: 123456789012
  • AWS_REGION: Glue カタログまたは S3 テーブル バケットが存在する AWS リージョン。例: us-east-1
  • AWS_ROLE_NAME: AWS IAM ロールの名前。例: biglake_glue_federation_role
  • NAMESPACE:(省略可)プライベート相互接続の設定時に作成した Service Directory 名前空間。
  • SERVICE_NAME: (省略可)プライベート相互接続の設定時に作成した Service Directory サービス名。

信頼ポリシーを更新する

カタログが作成されると、Lakehouse は一意のサービス アカウントをプロビジョニングします。このサービス アカウントは、カタログ作成レスポンスの biglake-service-account-id フィールドとして返されます。このサービス アカウントを使用して、信頼関係を確立します。

  1. 次のコマンドを実行して、biglake-service-account-id 値をアクティブな bash 変数に抽出します。

    BIGLAKE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format="value(biglake-service-account-id)")
  2. AWS IAM ロールの信頼ポリシーを更新して、プレースホルダを検証済みの Google サービス エージェント ID に置き換えます。条件ブロックは、subaud の両方の一致を検証します。ポリシーを trust_policy_comprehensive.json という名前のファイルに書き込みます。

    cat > trust_policy_comprehensive.json << EOF
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "accounts.google.com"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "accounts.google.com:aud": [
                "$BIGLAKE_SA_ID"
              ],
              "accounts.google.com:sub": [
                "$BIGLAKE_SA_ID"
              ]
            }
          }
        }
      ]
    }
    EOF
  3. 最終的なポリシーを AWS ロールに適用します。

    aws iam update-assume-role-policy \
      --role-name AWS_ROLE_NAME \
      --policy-document file://trust_policy_comprehensive.json

バックグラウンド更新を有効にする

両方のプラットフォームで安全な信頼関係が確立されたら、カタログを更新してバックグラウンド更新(5 分ごと、または 300s 以上)を有効にします。

gcloud CLI

gcloud alpha biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

REST

curl -s -X PATCH \
-H "x-goog-user-project: PROJECT_ID" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
-d '{
  "federated_catalog_options": {
    "refresh_options": {
      "refresh_schedule": {
        "refresh_interval": "300s"
      }
    }
  }
}'

接続を確認する

カタログのバックグラウンド更新サイクルが正常に完了し、Namespace が同期されていることを確認します。

  1. 更新ステータスが成功を示していることを確認します。

    gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --location="REGION"
  2. リモート データベースが同期された Namespace として表示されることを確認します。

    gcloud alpha biglake iceberg namespaces list \
      --catalog="FEDERATED_CATALOG_NAME" \
      --project="PROJECT_ID" \
      --location="REGION"

次のステップ