AWS Glue のクロスクラウド接続を設定する

AWS Glue Data Catalog へのクロスクラウド接続を使用すると、 Google Cloud内からそのカタログのデータを直接クエリできます。この機能により、外部データソースを既存のGoogle Cloud 環境と統合して、データ分析を統合できます。

接続を設定すると、ファイルを移動することなく、Lakehouse で連携 Apache Iceberg テーブルをクエリして管理できます。

始める前に

1. レイクハウスの概要を確認して、レイクハウスがデータへのアクセスを管理する方法を理解する。
2. クロスクラウド データへのアクセスを読んで、その仕組みを理解する。
3. サポートされているカタログを確認して、サポートされている構成を確認します。
4. 省略可: Google CloudVirtual Private Cloud（VPC）ネットワークと AWS VPC 間のプライベート相互接続を介してクエリの読み取りまたはバックグラウンド メタデータの更新をルーティングする場合は、有効な AWS アカウントがあることを確認し、専用 Cross-Cloud Interconnect または パートナー Cross-Cloud Interconnect をプロビジョニングして、Cloud Router との BGP セッションを確立します。また、両方のクラウド環境で必要な Identity and Access Management（IAM）権限があることを確認します。
Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the API

必要なロール

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

• レイクハウス カタログを管理する: BigLake 管理者 （roles/biglake.admin）
• Private Interconnect 経由でトラフィックをルーティングする（ユーザー）: Compute ネットワーク管理者 （roles/compute.networkAdmin）
• Private Interconnect 経由でトラフィックをルーティングする（カタログ サービス アカウント）:
  • Service Directory 閲覧者 （roles/servicedirectory.viewer）
  • Service Directory PSC 承認済みサービス （roles/servicedirectory.pscAuthorizedService）

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

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

制限事項と考慮事項

このセクションでは、クロスクラウド データにアクセスする際の制限事項と考慮事項について説明します。

• VPC Service Controls: 連携カタログ エンドポイントまたは基盤となる Cloud Storage バケットを含むプロジェクトが VPC Service Controls サービス境界内にある場合は、下り（外向き）ルールまたは上り（内向き）ルールを構成する必要があります。詳細については、連携カタログ エンドポイントで VPC Service Controls を使用するをご覧ください。
• Cross-Cloud Interconnect でサポートされているクラウド プロバイダ: プライベート相互接続を使用してクエリ転送、バックグラウンド メタデータの更新、またはその両方をルーティングすることは、AWS でサポートされています。Dedicated Cross-Cloud Interconnect またはパートナー Cross-Cloud Interconnect を使用できます。
• ネットワーク ルーティング: クエリ転送またはバックグラウンド メタデータ更新用にプライベート相互接続を構成しない場合、対応するトラフィックは TLS を使用して公共のインターネット経由でルーティングされます。公共のインターネット経由でクエリの読み取りをルーティングすると、リモート クラウド プロバイダからの下り（外向き）料金が高くなり、パフォーマンスの予測が難しくなる可能性があります。
• 読み取り専用: Lakehouse の連携カタログは、リモート カタログの読み取り専用ビューです。リソースの操作（リソースの作成、更新、削除など）はサポートされていないため、リモート カタログで直接実行する必要があります。
• データの更新速度: 連携カタログの --refresh-interval フラグによって、メタデータの同期頻度が決まります。値は 0s（無効）または 300s（5 分）以上にする必要があります。カタログのバックグラウンド メタデータ更新は、名前空間とテーブル リソースが多いほど時間がかかることがあります。前の更新がオーバーランすると、現在の更新はスキップされ、次の更新は次の間隔でスケジュールされます。クエリは、最後に同期されたカタログ メタデータを使用します。そのため、リモート カタログで行われた変更（新しいテーブル、スキーマの更新、新しく commit されたデータなど）は、次のバックグラウンド メタデータの更新が完了するまで Lakehouse に表示されません。
• レイクハウス キャッシュ: クロスクラウド キャッシュはデフォルトで無効になっています（--cross-cloud-cache=disabled）。キャッシュは、連携カタログレベルまたは接続レベルで有効または無効にできます。顧客管理の暗号鍵（CMEK）はキャッシュ保存ではサポートされていません。キャッシュに保存されたファイルは Google-owned and Google-managed encryption keysを使用して暗号化されます。クエリ内のテーブルに constraints/gcp.restrictNonCmekServices 組織のポリシーの制約が適用されている場合、そのクエリのキャッシュは自動的に無効になります。詳細については、インテリジェント キャッシュ保存をご覧ください。
• データ所在地とコンプライアンス: 連携カタログまたは接続でクロスクラウド キャッシュを有効にすると、Lakehouse はクエリが実行される Google Cloud リージョンにキャッシュ ファイルを一時的に保存します。リモート クラウド ファイルが別の管轄区域にある場合は、クロスリージョン キャッシュを有効にする前に、組織のデータ所在地とコンプライアンスの要件を満たしていることを確認してください。

全般的なワークフロー

クロスクラウド データにアクセスする一般的な手順は次のとおりです。

• Cross-Cloud Interconnect を設定する（省略可）: Google Cloud VPC ネットワークと AWS VPC の間にプライベート接続を構成します。
• 連携を設定する: AWS でプレースホルダ信頼ポリシーを使用して IAM ロールを作成し、認証を構成します。次に、Lakehouse で連携カタログを作成し、信頼ポリシーを更新します。
• 接続を確認する: Lakehouse がリモート カタログに接続できることを確認します。
• データのクエリを実行する: 4 つの部分からなる PROJECT_ID.CATALOG_NAME.NAMESPACE.TABLE 命名規則を使用して、BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。必要に応じて、連携カタログでクロスクラウド キャッシュを有効にすると、クロスクラウドの下り（外向き）費用を削減し、後続のクエリを高速化できます。詳細については、リモートデータにクエリを実行するをご覧ください。
• 権限を構成する: IAM を使用して、連携データを表示およびクエリできるユーザーを管理します。

Cross-Cloud Interconnect を設定する（省略可）

デフォルトでは、クエリデータの読み取りとバックグラウンド メタデータの更新は、TLS を使用して公共のインターネット経由で行われます。ネットワーク分離の強化、予測可能なレイテンシの提供、データ転送費用の削減を支援するために、 Google CloudVPC ネットワークとリモート クラウド ネットワーク（AWS VPC）の間にプライベート相互接続を構成できます。

次のいずれかのプライベート相互接続オプションをプロビジョニングできます。

• 専用の Cross-Cloud Interconnect: 専用の物理接続。
• Partner Cross-Cloud Interconnect: サポートされているサービス提供者を介した AWS への接続。

Google Cloudの Cloud Router とリモート クラウド ネットワークの間に BGP セッションを確立して、ルート交換を有効にします。

セキュリティと費用の要件に応じて、次のトラフィック パスのいずれかまたは両方に対して Cross-Cloud Interconnect 経由のプライベート ルーティングを構成できます。

• クエリ転送（--service-directory-name）: BigQuery またはオープンソース エンジンからのクエリ読み取りをリモート オブジェクト ストレージ（Amazon S3）にルーティングします。これにより、クロスクラウドの下り（外向き）料金を削減し、クエリ レイテンシを予測可能な状態に保つことができます。
• バックグラウンド メタデータ更新（--metadata-service-directory-name）: Lakehouse ランタイム カタログからリモート AWS Glue Data Catalog プライベート エンドポイントに、コントロール プレーンのバックグラウンド メタデータ更新リクエストと認証リクエストをルーティングします。たとえば、リモート カタログがパブリック インターネット アクセスを制限している場合です。

クエリ転送とバックグラウンド メタデータ更新の両方を Cross-Cloud Interconnect 経由でルーティングする場合は、リモート ストレージ エンドポイントとリモート カタログ エンドポイントに対して、プライベート エンドポイント、ルーティング、Service Directory サービスの手順を 1 回ずつ完了します。両方の Service Directory サービスは、連携カタログと同じ Google Cloud リージョンに存在する必要があります。また、同じプロキシ専用サブネットと Service Directory 名前空間を共有できます。

Service Directory からリモート プライベート エンドポイントにトラフィックをルーティングするには、次の 2 つのアーキテクチャ フローのいずれかを使用します。

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

アーキテクチャの要件に一致する構成フローを選択します。

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

リモート プライベート エンドポイント IP アドレスにリクエストを分散する内部リージョン プロキシ ネットワーク ロードバランサを構成する手順は次のとおりです。

リモート クラウドのプライベート エンドポイントを構成する

Cross-Cloud Interconnect を介して Google Cloud VPC ネットワークに接続するリモート ネットワークとサブネットにプライベート エンドポイントを作成し、各エンドポイントに割り当てられたプライベート IP アドレスをメモします。

• プライベート クエリ転送（リモート オブジェクト ストレージ）の場合: AWS VPC に Amazon S3 のインターフェース VPC エンドポイント（com.amazonaws.AWS_REGION.s3）を作成し、プロビジョニングされた ENI のプライベート IP アドレスをメモします。
• プライベート バックグラウンド メタデータ更新（リモート カタログ）の場合: AWS VPC に AWS Glue のインターフェース VPC エンドポイント（com.amazonaws.AWS_REGION.glue）を作成し、プロビジョニングされた ENI のプライベート IP アドレスをメモします。
• インバウンド セキュリティ ルール: プライベート エンドポイントに接続されている AWS セキュリティ グループが、 Google Cloud VPC CIDR の範囲からのポート 443 でのインバウンド TCP トラフィックを許可していることを確認します。ヘルスチェックと転送されたトラフィックを許可するには、 Google Cloud プロキシ専用サブネットの CIDR 範囲を含めます。

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

重要: このセクションのすべての Google Cloud リソース（ヘルスチェック、ハイブリッド NEG、バックエンド サービス、ロードバランサ）は、Cross-Cloud Interconnect VLAN アタッチメントが配置されているリージョンにデプロイする必要があります。異なるリージョンにある場合、トラフィックはリモート エンドポイントにルーティングされません。

次のコマンドを実行して、内部ロードバランサを構成します。クエリ転送とバックグラウンド メタデータの更新の両方を Cross-Cloud Interconnect 経由でルーティングする場合は、ストレージ エンドポイントとカタログ エンドポイントに個別のバックエンド サービス、ターゲット TCP プロキシ、転送ルールを構成します。高度な構成については、ハイブリッド エンドポイント用の内部リージョン プロキシ ネットワーク ロードバランサを設定するをご覧ください。

注: 開始する前に、リージョンの VPC ネットワークにプロキシ専用サブネットが構成されていることを確認してください。まだ作成していない場合は、次のコマンドで作成します。

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

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

• PROXY_SUBNET_NAME: プロキシ専用サブネットの名前。
• PROXY_SUBNET_RANGE: VPC ネットワーク内の未使用の CIDR の範囲（例: 10.129.0.0/23）。

重要: Cloud Router は、BGP を使用してプロキシ専用サブネットを自動的にアドバタイズしません。リモート エンドポイントからのレスポンス トラフィックがロードバランサにルーティングされるように、カスタムルート アドバタイズを使用して PROXY_SUBNET_RANGE をリモート ネットワークにアドバタイズするように Cloud Router を手動で構成する必要があります。

1. リージョン TCP ヘルスチェックを作成します。

   gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
       --region=REGION \
       --port=443

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

   • HEALTH_CHECK_NAME: ヘルスチェックの名前。
   • REGION: Google Cloud リージョン（例: us-east4）。

2. ハイブリッド接続ネットワーク エンドポイント グループ（NEG）を作成し、エンドポイントを追加します。

   ゾーンごとにハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT）を作成します。

   gcloud compute network-endpoint-groups create NEG_NAME \
       --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
       --zone=ZONE \
       --network=VPC_NETWORK

   リモート エンドポイント ENI のプライベート IP アドレスをハイブリッド NEG に追加します。

   gcloud compute network-endpoint-groups update NEG_NAME \
       --zone=ZONE \
       --add-endpoint="ip=REMOTE_ENDPOINT_IP,port=443"

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

   • NEG_NAME: ハイブリッド NEG の名前。
   • ZONE: Google Cloud ゾーン（例: us-east4-a）。このゾーンは、Cross-Cloud Interconnect VLAN アタッチメントのリージョン内に存在する必要があります。
   • VPC_NETWORK: VPC ネットワークの名前。
   • REMOTE_ENDPOINT_IP: そのゾーンのリモート ストレージまたはリモート カタログのプライベート エンドポイントのプライベート IP アドレス。

   リモート エンドポイントに複数のプライベート IP アドレスがゾーンに分散している場合は、これらのコマンドを繰り返してハイブリッド NEG を作成し、各ゾーンのエンドポイントを追加します。

3. バックエンド サービスを作成して構成します。

   内部マネージド ロード バランシングを使用してリージョン バックエンド サービスを作成します。

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --protocol=TCP \
       --region=REGION \
       --health-checks=HEALTH_CHECK_NAME \
       --health-checks-region=REGION

   ハイブリッド NEG をバックエンド サービスに追加します。

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --region=REGION \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=ZONE \
       --balancing-mode=CONNECTION \
       --max-connections=MAX_CONNECTIONS

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

   • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
   • NEG_NAME: 前の手順で作成したハイブリッド NEG の名前。
   • ZONE: Google Cloud ゾーン（例: us-east4-a）。
   • MAX_CONNECTIONS: バックエンドの最大同時接続数（例: 100）。

   作成したハイブリッド NEG ごとに add-backend コマンドを繰り返します。

4. ロードバランサのフロントエンドを構成します。

   ターゲット TCP プロキシを作成します。

   gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --region=REGION

   ターゲット プロキシにトラフィックをルーティングする転送ルールを作成します。

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=VPC_NETWORK \
       --subnet=VPC_SUBNET \
       --ports=443 \
       --region=REGION \
       --target-tcp-proxy=TARGET_PROXY_NAME \
       --target-tcp-proxy-region=REGION \
       --allow-global-access

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

   • TARGET_PROXY_NAME: ターゲット プロキシの名前。
   • FORWARDING_RULE_NAME: 転送ルールの名前。
   • VPC_SUBNET: VPC サブネットワークの名前。

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

Service Directory を構成する

Lakehouse が内部ロードバランサを検出してプライベートにルーティングできるように、内部ロードバランサの IP アドレスを Service Directory に登録します。クエリ転送とバックグラウンド メタデータの更新に別々のロードバランサ転送ルールを構成した場合は、転送ルールの IP アドレスごとに個別の Service Directory サービスとエンドポイントを作成します。

1. リモート プライベート エンドポイントの名前空間を作成します。

   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: サービスの固有識別子（バックグラウンド メタデータ更新エンドポイントを登録する場合は、METADATA_SERVICE_NAME などの別のサービス名を作成します）。

3. サービスにロードバランサ転送ルールのエンドポイントを作成します。

   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: ロードバランサの転送ルールの内部 IP アドレス。

直接エンドポイント

Dedicated Cross-Cloud Interconnect を介して単一のリモート プライベート エンドポイント IP アドレスにトラフィックを直接ルーティングするように Service Directory を構成する手順は次のとおりです。

1. リモート クラウド ネットワークにプライベート エンドポイントを作成します。

   • 非公開クエリ転送の場合: AWS VPC に Amazon S3 のインターフェース VPC エンドポイント（com.amazonaws.AWS_REGION.s3）を作成します。
   • プライベート バックグラウンド メタデータ更新の場合: AWS VPC に AWS Glue のインターフェース VPC エンドポイント（com.amazonaws.AWS_REGION.glue）を作成します。

   各エンドポイントのプライベート IP アドレスとポート（443）をメモし、AWS セキュリティ グループが Google Cloud VPC ネットワークからのポート 443 でインバウンド TCP トラフィックを許可していることを確認します。

2. リモート プライベート エンドポイントの名前空間を作成します。

   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: サービスの固有識別子（バックグラウンド メタデータ更新エンドポイントを登録する場合は、METADATA_SERVICE_NAME などの別のサービス名を作成します）。

4. リモート プライベート エンドポイントのプライベート IP アドレスとポートを使用して、サービスにエンドポイントを作成します。

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

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

   • ENDPOINT_NAME: エンドポイントの固有識別子。
   • REMOTE_ENDPOINT_IP: リモート ストレージまたはリモート カタログのプライベート エンドポイントのプライベート IP アドレス（例: 10.0.1.45）。
   • REMOTE_ENDPOINT_PORT: リモート プライベート エンドポイントのポート番号（例: 443）。
   • PROJECT_NUMBER: Google Cloudプロジェクトの番号。--network フラグでプロジェクト番号を使用します。
   • VPC_NETWORK: プライベート相互接続に関連付けられている Google CloudVPC ネットワーク名。

連携を設定する

データにクエリを実行するには、リモートの AWS Glue Data Catalog に接続する 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 ロールの名前。例: lakehouse_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 という名前のファイルを作成します。

   重要: 使いやすくするため、次の AWS IAM ポリシーには制限付きの Resource 要素がありません。アーキテクチャに必要な特定の Glue リソース、S3 バケット、S3 テーブル バケットへのアクセスを制限することをおすすめします。

   {
     "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:*"
         ]
       }
     ]
   }

   AWS Key Management Service（KMS）でホストされている顧客管理の鍵を使用して AWS Glue、Amazon S3、Amazon S3 テーブルのリソースを暗号化している場合は、リソースを復号するための KMS 鍵アクセスを許可するステートメントを追加する必要があります。

   # ...
   {
     "Sid": "GlueS3S3TablesKmsDecrypt",
     "Effect": "Allow",
     "Action": [
         "kms:Decrypt"
     ],
     "Resource": [
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_glue",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3_tables"
     ]
   }
   # ...

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 ロールの名前。例: lakehouse_glue_federation_role
   • AWS_POLICY_NAME: 権限ポリシーの名前。例: lakehouse_glue_federation_policy
   • AWS_REGION: Glue カタログまたは S3 テーブルが存在する AWS リージョン。例: us-east-1
   • AWS_ACCOUNT_ID: 12 桁の AWS アカウント ID 文字列。例: 123456789012

連携カタログを作成する

Google Cloud コンソールまたは Google Cloud CLI を使用して、連携カタログを作成します。

注: AWS Glue 連携カタログを確立する場合、glue_catalog_info（または --glue-warehouse フラグ）内の warehouse プロパティは、S3 バケット URI ではなく、12 桁の AWS アカウント ID 文字列または S3 テーブル バケット カタログに設定する必要があります。AWS Glue Iceberg REST エンドポイントは、アカウント ID を直接使用してウェアハウス カタログを解決します。

AWS 信頼関係の伝播中にバックグラウンド メタデータの更新が実行されて失敗となることを防ぐため、更新スケジュール（デフォルトは 0s）を指定せずにカタログを初期化します。

コンソール

連携カタログを作成するには:

1. Google Cloud コンソールで [Lakehouse] に移動します。

   [レイクハウス] に移動

2. [ カタログを作成] をクリックします。

3. [連携カタログ] をクリックします。

   [カタログの構成] セクションが表示されます。

4. [連携カタログのソース] で [AWS Glue] を選択します。

5. [データのロケーション] で、連携カタログを作成する Lakehouse リージョンを選択します。例: us-east4レイテンシを最小限に抑えるには（公共のインターネット経由でも）、AWS リージョンに最も近い Google Cloud リージョンを選択します。

6. [続行] をクリックします。

   [接続の詳細] セクションが表示されます。

7. [リモート カタログの詳細] セクションの [AWS ウェアハウス] フィールドに、AWS アカウント ID または S3 テーブル バケット カタログを入力します。例: 123456789012 や 123456789012:s3tablescatalog/my-table-bucket。

8. [AWS region] フィールドに、AWS リージョンを入力します。例: us-east-1

9. [AWS ロール ARN] フィールドに、AWS ロール ARN を入力します。形式は次のようにします: arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME。

10. [トランスポート層] で、[パブリック インターネット] または [専用プライベート相互接続] を選択します。[専用プライベート相互接続] を選択した場合は、次のフィールドを構成します。

    • [サービス ディレクトリ名] フィールドに、トランスポート Service Directory サービスのパスを projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME の形式で入力します。
    • 省略可: Cross-Cloud Interconnect を介してカタログ メタデータを非公開で同期するには、[メタデータ サービス ディレクトリ名] フィールドに、メタデータ Service Directory サービスへのパスを projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME の形式で入力します。

11. [作成] をクリックします。

gcloud

パブリック インターネット（CCI なし）

Cross-Cloud Interconnect を構成しない場合、接続は TLS を使用して公共のインターネット経由で行われます。

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

お客様所有（CCI）

プライベート相互接続 (専用またはパートナークロスクラウド相互接続) を構成した場合は、プライベートクエリ転送 (--service-directory-name)、プライベートバックグラウンドメタデータ更新 (--metadata-service-directory-name)、またはその両方について、サービスディレクトリのサービス参照を指定します。gcloud biglake iceberg catalogs update を実行して、既存のカタログにいずれかのフラグを追加または更新することもできます。

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME"

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

• FEDERATED_CATALOG_NAME: 連携カタログの名前。
• PROJECT_ID: 実際の Google Cloud プロジェクト ID。
• REGION: 連携カタログが作成される Lakehouse リージョン。これは、Service Directory の名前空間およびリージョン シークレットと同じリージョンにする必要があります。
• 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 ロールの名前。例: lakehouse_glue_federation_role
• NAMESPACE_FILTERS: 省略可。連携する Namespace のカンマ区切りリスト。例: ns1,ns2省略すると、Lakehouse にはすべての名前空間が含まれます。
• CROSS_CLOUD_CACHE_MODE: 省略可。連携カタログでクロスクラウド キャッシュを有効にするかどうか（enabled または disabled）。デフォルトは disabled です。enabled に設定すると、Lakehouse はカタログのGoogle Cloud リージョンにリモート ファイルをキャッシュに保存します。詳細については、インテリジェント キャッシュ保存をご覧ください。
• プライベート相互接続（Cross-Cloud Interconnect）を使用している場合は、次の Service Directory 参照のいずれかまたは両方を指定します（Cross-Cloud Interconnect 経由でそのトラフィック レイヤをルーティングしない場合は、どちらかのフラグを省略します）。
  • SERVICE_DIRECTORY_NAMESPACE と SERVICE_NAME: リモート オブジェクト ストレージへのプライベート クエリ転送用に作成した Service Directory の Namespace とサービス名。
  • METADATA_SERVICE_DIRECTORY_NAMESPACE と METADATA_SERVICE_NAME: 限定公開のバックグラウンド メタデータ更新用に作成した Service Directory の名前空間とサービス名。

信頼ポリシーを更新する

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

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

   LAKEHOUSE_SA_ID=$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
     --project="PROJECT_ID" \
     --format="value(biglake-service-account-id)")

2. AWS IAM ロールの信頼ポリシーを更新して、プレースホルダを確認済みの Google サービス エージェント ID に置き換えます。condition ブロックは、sub と aud の両方の一致を検証します。ポリシーを 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": [
               "$LAKEHOUSE_SA_ID"
             ],
             "accounts.google.com:sub": [
               "$LAKEHOUSE_SA_ID"
             ]
           }
         }
       }
     ]
   }
   EOF

3. 最終的なポリシーを AWS ロールに適用します。

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

   注: AWS IAM の変更が反映されるまでに数分かかることがあります。

バックグラウンドでのメタデータの更新を有効にする

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

gcloud

gcloud 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"
        }
      }
    }
  }'

プライベート相互接続の設定を完了する（Cross-Cloud Interconnect のみ）

クエリ転送、バックグラウンド メタデータの更新、またはその両方をプライベート相互接続（Dedicated または Partner Cross-Cloud Interconnect）を介してルーティングする場合は、Service Directory を介して接続を検出して認可する権限を Lakehouse カタログ サービス アカウントに付与する必要があります。トランスポート Service Directory サービスとメタデータ Service Directory サービスが異なる Google Cloud プロジェクトでホストされている場合は、Service Directory サービスをホストする各プロジェクトにこれらのロールを付与します。

注: カタログ サービス アカウントは、内部の Google Cloud サービス エージェントです。Google Cloud コンソールのプロジェクトのサービス アカウント リストには表示されない場合がありますが、ロールを手動で割り当てることができます。

コンソール

1. Google Cloud コンソールで、[IAM] ページに移動します。

   [IAM] に移動

2. [アクセス権を付与]（または [追加]）をクリックします。

3. [新しいプリンシパル] フィールドに、Lakehouse カタログ サービス アカウントのメールアドレスを入力します。このメールアドレスを取得するには、カタログを記述します（gcloud タブをご覧ください）。

4. [ロール] メニューで、[Service Directory 閲覧者]（roles/servicedirectory.viewer）を選択します。

5. [別のロールを追加] をクリックし、[Service Directory PSC 承認済みサービス]（roles/servicedirectory.pscAuthorizedService）を選択します。

6. [保存] をクリックします。

gcloud

Service Directory サービスをホストするプロジェクトのカタログのサービス アカウントに、必要なロールを付与します。

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

接続を確認する

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

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

   gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
     --project="PROJECT_ID"

2. 名前空間が同期されていることを確認します。

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

次のステップ

• リモートデータをクエリする。
• 連携カタログ エンドポイントで VPC Service Controls を使用する。
• クロスクラウド データアクセスのトラブルシューティング。