Workday Data Lake のクロスクラウド接続を設定する

Workday Data Lake へのクロスクラウド接続により、 Google Cloud内で Workday データを直接クエリできます。この機能は、外部データソースを既存のGoogle Cloud 環境と統合することで、データ分析を統合します。

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

ユースケース

Lakehouse を Workday Data Lake に接続すると、次のような主要なユースケースがサポートされます。

  • 分析を統合する: Workday の人事データと報酬データをGoogle Cloud データと関連付けます。たとえば、販売と割り当てのコンテキストを提供します。
  • Google Cloud エコシステムを活用する: たとえば、Google のエージェント フレームワークと BigQuery ML および Workday HR データを使用して、従業員の定着率を予測します。
  • リアルタイムのコピーなしデータをストリーミングする:Google Cloud に保存されているロジスティクス データと在庫データとともに、Workday の調達データと買掛金データを分析して、サプライ チェーンの非効率性をレポートし、ベンダーのコストを最適化します。

始める前に

  1. レイクハウスの概要を確認して、レイクハウスがデータへのアクセスを管理する方法を理解します。
  2. その仕組みについては、クロスクラウド データへのアクセスについてをご覧ください。
  3. サポートされているカタログを確認して、互換性を確認します。
  4. リージョン Secret Manager シークレットを使用して Workday Data Lake で認証する方法について説明します。
  5. このドキュメントの説明に沿って認証を設定するには、Workday Data Lake 管理者に確認してください。管理者は、Workday サポートに連絡して Data Lake へのアクセスを有効にする必要がある場合があります。この場合、解決に時間がかかることがあります。
  6. Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

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

  8. Enable the BigLake, Secret Manager APIs, if any are 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 APIs

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

  10. Enable the BigLake, Secret Manager APIs, if any are 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 APIs

    11.

必要なロール

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

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

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

制限事項と考慮事項

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

  • 読み取り専用: Lakehouse の連携カタログは、リモート カタログの読み取り専用ビューです。リソース操作（リソースの作成、更新、削除など）は対象外です。リモート カタログで直接実行する必要があります。
  • データの更新速度: 連携カタログの --refresh-interval フラグは、メタデータの同期頻度を決定します。値は 0s（無効）または 300s（5 分）以上にしてください。カタログのバックグラウンド メタデータの更新は、Namespace とテーブル リソースが多いほど時間がかかることがあります。前回の更新がオーバーランした場合、現在の更新はスキップされますが、次の更新は次の間隔でスケジュールされます。
  • Lakehouse キャッシュ保存: Lakehouse キャッシュ保存は、すべてのクロスクラウド クエリで自動的に有効になり、 Google Cloudにデータブロックをローカルに保存することで下り（外向き）費用を削減します。顧客管理の暗号鍵（CMEK）はキャッシュ保存では対象外です。キャッシュに保存されたデータは Google-owned and Google-managed encryption keysを使用して暗号化されます。クエリ内のテーブルに constraints/gcp.restrictNonCmekServices 組織のポリシーの制約が適用されている場合、そのクエリのキャッシュ保存は自動的に無効になります。詳細については、インテリジェント キャッシュ保存をご覧ください。
  • データ所在地とコンプライアンス: Google Cloud リージョンに連携カタログまたは接続を作成すると、キャッシュに保存されたデータがそのターゲット リージョンに保存されます。リモート クラウドデータが別の地域の適用法令にある場合は、クロスリージョン キャッシュ保存が組織のデータ所在地と規制遵守の要件を満たしていることを確認してください。

全般的なワークフロー

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

  1. 連携を設定する: シークレット ベースの認証を構成し、Lakehouse に連携カタログを作成します。
    1. Workday で、データレイクと Workday API の認証情報を設定します。
    2. Workday API 認証情報を使用して、Secret Manager にシークレットを作成します。
    3. Lakehouse に連携カタログを作成し、カタログ サービス アカウントにシークレットへのアクセス権を付与します。
  2. 接続を確認する: Lakehouse がリモート カタログに接続してメタデータを同期できることを確認します。
  3. データをクエリする: BigQuery または Managed Service for Apache Spark を使用して、連携データに対してクエリを実行します。詳細については、リモートデータにクエリを実行するをご覧ください。
  4. 権限を構成する: Identity and Access Management（IAM）を使用して、フェデレーション データを表示してクエリできるユーザーを管理します。

連携を設定する

データをクエリするには、リモートの Workday Data Lake に接続する Lakehouse 連携カタログを設定する必要があります。

認証を構成する

連携では、リージョン Secret Manager の Secret に安全に保存されている認証情報を使用して、リモートの Workday Data Lake に対する認証が必要です。

  1. Workday で、次の操作を行います。

    1. データレイクを設定します。
    2. データレイクの API クライアントを登録します（更新トークン付与）。
    3. データレイクでセキュリティとテーブル エクスポートを設定します。

    このプロセスを完了するためのエンドツーエンドの手順については、Workday Data Lake のスタートガイドをご覧ください。

  2. 前の手順で取得した認証情報を使用して、credentials.json という名前の JSON ファイルを作成します。

    {
  "client_id": "CLIENT_ID",
  "client_secret": "CLIENT_SECRET",
  "refresh_token": "REFRESH_TOKEN"
}

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

    • CLIENT_ID: Workday API Client for Integrations の OAuth クライアント ID。
    • CLIENT_SECRET: Workday API Client for Integrations の OAuth クライアント シークレット。
    • REFRESH_TOKEN: Workday ISU 用に生成された有効期限のない更新トークン。

  3. Secret Manager のリージョン エンドポイントを構成します。

    デフォルトでは、Secret Manager はグローバル エンドポイントを使用します。接続の問題を回避し、レイテンシとデータ転送コストを最小限に抑えるには、シークレットとカタログを同じリージョンに作成します。デフォルトのグローバル エンドポイントをリージョン シークレットでオーバーライドするには、次のコマンドを実行します。

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/

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

    • REGION: Secret Manager のシークレットを保存する Google Cloud リージョン。例: us-east4

  4. ペイロードを Secret Manager にアップロードします。

    gcloud secrets create WORKDAY_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json

  5. 認証情報の漏洩を防ぐため、credentials.json ファイルを安全に削除します。

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

    • WORKDAY_SECRET_NAME: Secret Manager 内の Workday シークレットの一意の名前（例: workday-api-credentials、workday-data-lake-secret）。
    • REGION: シークレットを作成する Google Cloud リージョン（us-east4 など）。
    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。

連携カタログを作成する

gcloud CLI を使用して連携カタログを作成するには、次のコマンドを実行します。

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="workday" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME" \
    --workday-base-url="WORKDAY_BASE_URL" \
    --workday-tenant="WORKDAY_TENANT" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

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

  • FEDERATED_CATALOG_NAME: Lakehouse の連携カタログの名前。
  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • REGION: 連携カタログを作成する Lakehouse リージョン（例: us-east4）。レイテンシとデータ転送費用を最小限に抑えるには、Workday インスタンスに最も近い Google Cloudリージョンを選択します。このリージョンは、シークレットを保存したリージョンと同じである必要があります。
  • WORKDAY_SECRET_NAME: Secret Manager の Workday シークレットの名前。
  • WORKDAY_BASE_URL: Workday インスタンスのベース URL。たとえば、impl-services1.wd12.myworkday.com や wd501.myworkday.com です。
  • WORKDAY_TENANT: Workday テナント名。
  • REFRESH_INTERVAL: 省略可。カタログの情報を更新する頻度を指定します。この値は期間として設定します（例: 300s、5m）。間隔を短くすると、データの更新頻度は高くなりますが、API 呼び出しの費用が増加する可能性があります。間隔を長くすると費用を抑えることができますが、クエリされたデータが最新のデータセットを反映していない可能性があります。省略した場合、更新間隔はデフォルトで 5 分（300s）になります。値を 0s に設定すると、バックグラウンドでのメタデータの更新が無効になります。
  • NAMESPACE_FILTERS: 省略可: 統合する Namespace のカンマ区切りリスト（例: finance,hr）。省略すると、Lakehouse にすべての名前空間が含まれます。

認証の設定を完了する

カタログを作成すると、Lakehouse は一意のサービス アカウントをプロビジョニングします。これは、リソースの説明で biglake-service-account として識別されます。

このサービス アカウントに、先ほど作成したシークレットに対する Secret Manager のシークレット アクセサー ロール（roles/secretmanager.secretAccessor）を付与する必要があります。新しい IAM ポリシーが有効になるまでに数分かかることがあります。

コンソール

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

    [レイクハウス] に移動

  2. Workday 用に作成した連携カタログの名前をクリックします。

  3. [カタログの詳細] ページの警告バナーで、[シークレット権限を付与] をクリックします。

    Lakehouse は、プロビジョニングされたサービス アカウントにシークレットの roles/secretmanager.secretAccessor ロールを付与します。

gcloud CLI

  1. カタログのサービス アカウントにシークレットへのアクセス権を付与します。

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding WORKDAY_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
      --role="roles/secretmanager.secretAccessor"

  2. 連携カタログ サービス アカウントが Secret にアクセスできることを確認するには、次のコマンドを実行します。

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy WORKDAY_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION"

    出力で、biglake-service-account サービス アカウントに roles/secretmanager.secretAccessor ロールが付与されていることを確認します。

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

  • REGION: Secret Manager シークレットを保存し、フェデレーション カタログを作成した Google Cloud リージョン（us-east4 など）。
  • WORKDAY_SECRET_NAME: Secret Manager の Workday シークレットの名前。
  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • FEDERATED_CATALOG_NAME: Lakehouse の連携カタログの名前。

接続を確認する

バックグラウンドのメタデータの更新が正常に完了し、Namespace とテーブルが同期されたことを確認します。

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

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

  2. Namespace が同期されていることを確認します。

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

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

  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • FEDERATED_CATALOG_NAME: Lakehouse の連携カタログの名前。

次のステップ