データ フォームの用語と認証プロセスを理解する | Kabir Akande 2024 年 5 月 |

データフォームの用語と認証フローを理解する: GCP サービスである Dataform は、エンジニアリングのベスト プラクティスを組み込み、ワークフロー オーケストレーションを自動化することでデータ パイプラインを合理化します。 Dataform は、ワークスペース内のコードを整理し、構成を管理し、環境を定義することにより、効率的なデータ変換と構造化データの出力を可能にします。この記事では、開発ワークスペース、リリース構成、ワークフロー構成などの主要な Dataform 用語を詳しく説明し、サービス アカウントと偽装を使用した認証プロセスについて説明します。

MLOps: Data Pipeline Orchestration

MLOps: データ パイプライン オーケストレーション

A Comprehensive Guide to Dataform Terminologies and Authentication Flow

データフォーム用語と認証フローの包括的なガイド

Part 1 of Dataform 101: Fundamentals of a Single Repo, Multi-Environment Dataform with Least-Privilege Access Control and Infrastructure as Code Setup

Dataform 101 のパート 1: 単一リポジトリの基礎、最小権限のアクセス制御とコード設定としてのインフラストラクチャを備えた複数環境のデータフォーム

Introduction

導入

Dataform is an innovative service offered by Google Cloud Platform (GCP) that empowers teams to develop and operationalize sophisticated, SQL-based data pipelines. This groundbreaking platform seamlessly integrates software engineering best practices into the data pipeline lifecycle, unlocking a world of possibilities, including testing, environments, version control, dependency management, orchestration, and automated documentation. Essentially, Dataform serves as a serverless, SQL workflow orchestration engine within the GCP ecosystem. It ingests raw data, transforms it with the utmost engineering rigor, and produces meticulously structured data ready for consumption.

Dataform は、Google Cloud Platform (GCP) が提供する革新的なサービスで、チームが洗練された SQL ベースのデータ パイプラインを開発および運用できるようにします。この画期的なプラットフォームは、ソフトウェア エンジニアリングのベスト プラクティスをデータ パイプラインのライフサイクルにシームレスに統合し、テスト、環境、バージョン管理、依存関係管理、オーケストレーション、自動ドキュメントなどの可能性の世界を解き放ちます。基本的に、Dataform は GCP エコシステム内でサーバーレスの SQL ワークフロー オーケストレーション エンジンとして機能します。生データを取り込み、最大限の厳密なエンジニアリングで変換し、すぐに使用できる綿密に構造化されたデータを生成します。

Dataform Terminologies

データフォーム用語

Navigating the world of Dataform can be a daunting task, especially for those new to its terminologies. To bridge this knowledge gap, let's delve into some key terms that will serve as a compass on your Dataform journey:

Dataform の世界をナビゲートすることは、特にその用語に慣れていない人にとっては、困難な作業になる可能性があります。この知識のギャップを埋めるために、Dataform の取り組みにおいて羅針盤として機能するいくつかの重要な用語を詳しく掘り下げてみましょう。

Development Workspaces:

開発ワークスペース:

Similar to local GitHub branches, Dataform development workspaces provide an editable copy of the main Dataform repository code. Within these workspaces, code development and experimentation flourish. When the time comes to share your masterpiece with the world, simply commit and push your changes, and voilà, a remote branch will emerge, mirroring your development workspace.

ローカルの GitHub ブランチと同様に、Dataform 開発ワークスペースは、メインの Dataform リポジトリ コードの編集可能なコピーを提供します。これらのワークスペース内では、コードの開発と実験が盛んに行われます。傑作を世界と共有するときが来たら、変更をコミットしてプッシュするだけで、開発ワークスペースをミラーリングするリモート ブランチが表示されます。

Release Configuration:

リリース構成:

Dataform seamlessly blends .sqlx scripts with JavaScript (.js) for data transformations and logic. To ensure the codebase is standardized and reproducible, Dataform employs a compilation process that transforms it into a machine-readable JSON config file. The orchestrator behind this compilation process is none other than release configuration. At a predetermined time, Dataform will diligently check out the code from a remote repository (which can be configured to target any branch) and weave its transformation magic, generating the JSON config file.

Dataform は、データ変換とロジックのために .sqlx スクリプトと JavaScript (.js) をシームレスにブレンドします。コードベースが標準化され、再現可能であることを保証するために、Dataform はコードベースを機械可読な JSON 構成ファイルに変換するコンパイル プロセスを採用しています。このコンパイル プロセスの背後にあるオーケストレーターは、リリース構成にほかなりません。あらかじめ決められた時間に、Dataform はリモート リポジトリ (任意のブランチをターゲットにするように構成可能) からコードを熱心にチェックアウトし、その変換マジックを織り込んで JSON 構成ファイルを生成します。

Workflow Configuration:

ワークフロー構成:

The output of release configuration – the JSON config file – serves as the foundation for workflow configuration. This configuration dictates when the config file should be executed, who should execute it, and where the config file's output should reside.

リリース構成の出力 (JSON 構成ファイル) は、ワークフロー構成の基礎として機能します。この構成は、構成ファイルをいつ実行するか、誰が実行するか、および構成ファイルの出力をどこに置くかを決定します。

Since workflow configuration relies heavily on the JSON config file generated by release configuration, it's imperative to ensure that it runs after release configuration. This ensures that the latest changes are reflected in the BigQuery (BQ) tables without delay. If scheduled simultaneously, workflow configuration may utilize the previous compilation, resulting in a lag in reflecting the most up-to-date changes in the BQ tables until the next workflow configuration run.

ワークフロー構成はリリース構成によって生成された JSON 構成ファイルに大きく依存しているため、リリース構成後に確実に実行されるようにすることが不可欠です。これにより、最新の変更が遅延なく BigQuery (BQ) テーブルに反映されます。同時にスケジュールされた場合、ワークフロー構成は以前のコンパイルを利用する可能性があり、その結果、次回のワークフロー構成が実行されるまで BQ テーブルに最新の変更が反映されるのに遅れが生じます。

Environments:

環境:

One of Dataform's most sought-after features is its ability to manifest code into multiple environments, such as development, staging, and production. This flexibility poses a question: should repositories be created in multiple environments or consolidated into a single environment? Google, in its infinite wisdom, has weighed the pros and cons in its Dataform best practices section. This article will demonstrate how to configure Dataform for staging and production environments, with data materialized into both environments from a single repository.

Dataform の最も人気のある機能の 1 つは、開発、ステージング、運用などの複数の環境にコードをマニフェストできる機能です。この柔軟性により、リポジトリは複数の環境で作成する必要があるのか​​、それとも 1 つの環境に統合する必要があるのか​​という疑問が生じます。 Google は、その無限の知恵により、Dataform のベスト プラクティス セクションでメリットとデメリットを比較検討しています。この記事では、単一のリポジトリから両方の環境に実体化されたデータを使用して、ステージング環境と本番環境用に Dataform を構成する方法を説明します。

Authentication

認証

Authentication within Dataform can be a labyrinthine maze, especially when navigating multiple environments. To shed light on this intricate matter, we will delve into the specifics of staging and production environments.

Dataform 内の認証は、特に複数の環境をナビゲートする場合、迷路のような迷路になる可能性があります。この複雑な問題を解明するために、ステージング環境と実稼働環境の詳細を詳しく掘り下げていきます。

Dataform Authentication Flow:

データフォーム認証フロー:

The diagram below captures the intricate dance of authentication within Dataform:

以下の図は、Dataform 内での複雑な認証のダンスを示しています。

[Image of Dataform authentication flow]

【Dataform認証フローのイメージ】

Machine User:

マシンユーザー:

Dataform requires credentials to access GitHub when retrieving code stored on a remote repository. While using individual credentials is an option, the recommended path is to employ a machine user within an organization. This strategy ensures that Dataform's pipeline orchestration remains independent of individual identities and is not susceptible to their departure or whims. Setting up a machine user involves creating an identity that is not tied to an individual and using it to establish a GitHub account. For Dataform, a personal access token (PAT) is generated for the machine user account and safely tucked away as a secret in GCP's secret manager. The machine user should also be added as an outside collaborator to the Dataform remote repository with read and write access. We will unravel how Dataform is configured to access this secret in the Terraform code. If the user opts to use their own identity instead of a machine user, a token should be generated using the steps outlined here.

Dataform では、リモート リポジトリに保存されているコードを取得するときに、GitHub にアクセスするための認証情報が必要です。個別の資格情報を使用することもできますが、推奨される方法は、組織内でマシン ユーザーを雇用することです。この戦略により、Dataform のパイプライン オーケストレーションが個人のアイデンティティから独立し、個人の逸脱や気まぐれの影響を受けにくくなります。マシン ユーザーのセットアップには、個人に関連付けられていない ID の作成と、それを使用した GitHub アカウントの確立が含まれます。 Dataform の場合、マシンのユーザー アカウントに対してパーソナル アクセス トークン (PAT) が生成され、GCP のシークレット マネージャーにシークレットとして安全に保管されます。マシン ユーザーは、読み取りおよび書き込みアクセス権を持つ Dataform リモート リポジトリに外部コラボレーターとして追加する必要もあります。 Terraform コードでこのシークレットにアクセスするように Dataform がどのように構成されているかを解明します。ユーザーがマシン ユーザーではなく自分の ID を使用することを選択した場合は、ここで概説する手順を使用してトークンを生成する必要があります。

GitHub Authentication Flow:

GitHub の認証フロー:

Dataform leverages its default service account for implementation. When a Dataform action is initiated, it commences with the default service account. Assuming you have created a machine user, added them as a collaborator to the remote repository, and securely stored their PAT as a secret in GCP's secret manager, let's delve into the authentication process:

Dataform は、デフォルトのサービス アカウントを実装に利用します。 Dataform アクションが開始されると、デフォルトのサービス アカウントで開始されます。マシン ユーザーを作成し、リモート リポジトリにコラボレーターとして追加し、PAT を GCP のシークレット マネージャーにシークレットとして安全に保存したと仮定して、認証プロセスを詳しく見てみましょう。

1. Extracting the Secret: The default service account requires the secretAccessor role to extract the secret from the secret manager.
2. Impersonating the Machine User: Armed with the secret, the default service account can now impersonate the machine user. Since the machine user is a collaborator on the remote Git repository, the default service account inherits access to the repository.

[Image of GitHub authentication workflow]

シークレットの抽出: デフォルトのサービス アカウントには、シークレット マネージャーからシークレットを抽出するために SecretAccessor ロールが必要です。マシン ユーザーの偽装: シークレットを準備したデフォルトのサービス アカウントは、マシン ユーザーになりすますことができます。マシン ユーザーはリモート Git リポジトリのコラボレーターであるため、デフォルトのサービス アカウントはリポジトリへのアクセスを継承します。[GitHub 認証ワークフローのイメージ]

Development Workspace Authentication:

開発ワークスペースの認証:

When execution is initiated from the development workspace, the default service account assumes the identity of the staging environment's custom service account to manifest the output within the staging environment. To successfully impersonate the staging environment's custom service account, the default service account must possess the iam.serviceAccountTokenCreator role. This role empowers the default service account to craft a short-lived token, akin to the PAT used to impersonate the machine user, for the staging custom service account and, thus, impersonate it. Consequently, the staging custom service account inherits all the necessary permissions to modify BQ tables, which are then inherited by the default service account when it impersonates the staging custom service account.

開発ワークスペースから実行が開始されると、デフォルトのサービス アカウントはステージング環境のカスタム サービス アカウントの ID を想定して、ステージング環境内で出力をマニフェストします。ステージング環境のカスタム サービス アカウントを正常に偽装するには、デフォルトのサービス アカウントが iam.serviceAccountTokenCreator ロールを所有している必要があります。このロールにより、デフォルトのサービス アカウントは、ステージング カスタム サービス アカウントに対して、マシン ユーザーの偽装に使用される PAT に似た有効期間の短いトークンを作成し、それを偽装できるようになります。その結果、ステージング カスタム サービス アカウントは、BQ テーブルを変更するために必要なすべてのアクセス許可を継承し、その後、ステージング カスタム サービス アカウントを偽装するときに、デフォルトのサービス アカウントによってこれらのアクセス許可が継承されます。

Workflow Configuration Authentication:

ワークフロー構成の認証:

After successfully retrieving the code from the repository, release configuration generates a compiled config JSON file, which workflow configurations utilize to generate data. To commit this data to production BQ tables, the default service account requires the iam.serviceAccountTokenCreator role on the production custom service account. Similar to the process employed for the staging custom service account, the production service account is granted all the necessary permissions to modify production environment BQ tables, which are inherited by the default service account when it impersonates the production custom service account.

リポジトリからコードを正常に取得した後、リリース構成はコンパイルされた構成 JSON ファイルを生成し、ワークフロー構成はこれを利用してデータを生成します。このデータを実稼働 BQ テーブルにコミットするには、デフォルトのサービス アカウントには実稼働カスタム サービス アカウントの iam.serviceAccountTokenCreator ロールが必要です。ステージング カスタム サービス アカウントに使用されるプロセスと同様に、運用環境の BQ テーブルを変更するために必要なすべてのアクセス許可が運用サービス アカウントに付与されます。これらのアクセス許可は、運用カスタム サービス アカウントを偽装するときにデフォルトのサービス アカウントによって継承されます。

Conclusion

結論

In summary, the default service account plays a pivotal role in Dataform's authentication architecture. It assumes the identity of the machine user to authenticate with GitHub as a collaborator, leveraging the machine user's PAT. It also authenticates with the staging and production environments by impersonating their respective custom service accounts using short-lived tokens generated with the serviceAccountTokenCreator role. Armed with this newfound understanding, we can confidently embark on the journey of provisioning Dataform within GCP using Terraform. Stay tuned for Part 2 of this article, where we will tackle this very subject. In the meantime, feel free to explore the code repository for further insights.

要約すると、デフォルトのサービス アカウントは、Dataform の認証アーキテクチャにおいて極めて重要な役割を果たします。マシン ユーザーの PAT を利用して、GitHub でコラボレーターとして認証するマシン ユーザーの ID を前提とします。また、serviceAccountTokenCreator ロールで生成された有効期間の短いトークンを使用して、それぞれのカスタム サービス アカウントになりすまして、ステージング環境と運用環境で認証します。この新たな理解を武器に、Terraform を使用して GCP 内で Dataform をプロビジョニングする旅に自信を持って乗り出すことができます。この記事のパート 2 では、まさにこのテーマに取り組みますので、ご期待ください。それまでの間、さらなる洞察を得るためにコード リポジトリを自由に探索してください。

References:

参考文献:

• [Dataform: Google Cloud](https://cloud.google.com/dataform?hl=en)
• [Dataform Migration: Google Cloud](https://cloud.google.com/dataform/docs/migration)
• [Dataform Best Practices: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)

[データフォーム: Google Cloud](https://cloud.google.com/dataform?hl=ja)[データフォームの移行: Google Cloud](https://cloud.google.com/dataform/docs/migration)[データフォームベストプラクティス: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)