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

Workday Data Lake へのクロスクラウド接続により、 Google Cloud内で Workday データを直接クエリできます。その後、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.

    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.

    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 ロールを付与するよう管理者に依頼してください。

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

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

サポートされているカタログの詳細

このドキュメントでは、Workday Data Lake を使用してレイクハウスを設定する手順について説明します。他のカタログにアクセスするには、サポートされているカタログをご覧ください。

制限事項と考慮事項

Workday Data Lake にアクセスする際は、次の点に注意してください。

  • 読み取り専用: Lakehouse の連携カタログは、リモート カタログの読み取り専用ビューです。リソースを作成、更新、削除するには、Workday を直接使用する必要があります。
  • ネットワーク ルーティング: 接続とクエリは、公共のインターネット経由で安全にルーティングされます。
  • データの更新速度: --refresh-interval フラグは、Lakehouse がメタデータを同期する頻度を決定します。値は 0s（無効）または 300s（5 分）以上にしてください。カタログ内の名前空間とテーブルの数が増えると、バックグラウンドでのメタデータの更新に時間がかかるようになります。前回の更新が予定された間隔を超えた場合、システムは現在のサイクルをスキップし、次の予定された間隔で再開します。
  • コロケーション: 接続の問題を回避し、レイテンシとデータ転送コストを最小限に抑えるには、Workday インスタンスが存在するリージョンに最も近いGoogle Cloud リージョンに、フェデレーション カタログとリージョン シークレットを作成します。

全般的なワークフロー

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

  1. 連携を設定する: シークレット ベースの認証を構成し、Lakehouse に連携カタログを作成します。
    1. Workday で、統合用の統合システム ユーザー（ISU）と 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. 統合システム ユーザー（ISU）を作成する: 統合システム ユーザーの作成タスクを実行して、Lakehouse がリソースの同期に使用する専用アカウントを作成します。
    2. ISU の Workday Data Lake へのアクセスを有効にする: ISU に Workday Data Lake へのアクセス権を付与します。このアクセス権を有効にするには、Workday サポートにお問い合わせください。このステップは自分で行うことはできません。続行する前に、Workday が Workday テナントでアクセスを構成するまで待ちます。
    3. 統合用の API クライアントを登録する: 統合用の API クライアントを登録するタスクを実行します。
    4. クライアント ID とシークレットを保存する: 次の手順で使用するため、OAuth クライアント ID とシークレットを保存します。
    5. 有効期限のない更新トークンを生成する: インテグレーション用の API クライアントで、インテグレーション用の更新トークンを管理を使用して、ISU の有効期限のない更新トークンを生成します。
    6. 更新トークンを保存する: 生成された更新トークンを次のステップのために保存します。

  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] に移動します。

    [レイクハウスに移動][5]

  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 の連携カタログの名前。

次のステップ