데이터 양식 용어 및 인증 프로세스 이해 작성자: 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

데이터 양식 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은 팀이 정교한 SQL 기반 데이터 파이프라인을 개발하고 운영할 수 있도록 지원하는 Google Cloud Platform(GCP)에서 제공하는 혁신적인 서비스입니다. 이 획기적인 플랫폼은 소프트웨어 엔지니어링 모범 사례를 데이터 파이프라인 수명주기에 원활하게 통합하여 테스트, 환경, 버전 제어, 종속성 관리, 오케스트레이션 및 자동화된 문서화를 포함한 가능성의 세계를 열어줍니다. 기본적으로 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의 가장 인기 있는 기능 중 하나는 개발, 스테이징, 프로덕션과 같은 여러 환경에 코드를 표시하는 기능입니다. 이러한 유연성은 다음과 같은 질문을 제기합니다. 리포지토리를 여러 환경에서 생성해야 합니까, 아니면 단일 환경으로 통합해야 합니까? 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와 독립적으로 유지되고 개인의 이탈이나 변덕에 영향을 받지 않도록 보장합니다. 컴퓨터 사용자를 설정하려면 개인과 연결되지 않은 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은 구현을 위해 기본 서비스 계정을 활용합니다. 데이터 양식 작업이 시작되면 기본 서비스 계정으로 시작됩니다. 컴퓨터 사용자를 생성하고 이를 원격 저장소에 공동 작업자로 추가하고 해당 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에 공동 작업자로 인증하기 위해 컴퓨터 사용자의 신원을 가정합니다. 또한 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=en)[데이터 양식 마이그레이션: Google Cloud](https://cloud.google.com/dataform/docs/migration)[데이터 양식 최고 사례: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)