背景情報
企業顧客が一連のデータ アプリケーションをクラウド上に展開するプロセスでは、多くの場合、データ開発チームがスクリプトの内容を担当し、その背後にある一連のクラウド リソースの管理は、通常、クラウドの運用および保守の機能チームによって実装されます。 IaC (Infrastructre as Code) を通じて。ただし、データ開発チームが対応するスクリプト コンテンツを開発してデプロイする場合、Glue や Lambda リソースの追加や変更など、クラウド上のリソースの変更が必然的に発生します。その結果、機能境界で 2 つのチーム間の緊密な結合が生じました。データ開発チームの反復コンテンツは、対応する IaC 運用および保守のためにクラウド運用および保守チームに要件を提出する必要があり、これにより、両当事者の作業負荷が増加します。
| Amazon クラウド テクノロジー開発者コミュニティは、開発者にグローバルな開発テクノロジー リソースを提供します。技術ドキュメント、開発事例、技術コラム、トレーニングビデオ、アクティビティやコンテストなどがあります。中国の開発者が世界最先端のテクノロジー、アイデア、プロジェクトとつながることを支援し、優れた中国の開発者やテクノロジーを世界のクラウド コミュニティに推奨します。まだ注目/お気に入りをしていない場合は、これを見たときに慌てずにクリックして、ここを技術の宝庫にしてください。 |
最適化スキームの概要
データ アプリケーション コードの追加と変更によって双方に生じる追加のプレッシャーを軽減するために、この記事では、データ アプリケーションの追加、変更、展開のプロセスにおける主要なプロセスを最適化するケースから始めます。データ開発チームは、対応する Terraform モジュールをインターフェイスの形式で提供し、Amazon CodePipeline または EventBridge 駆動のイベント モードと連携して CI/CD パイプラインを実装します。
この場合、クラウド運用保守チームは IaC モジュールのデプロイと運用保守を担当し、IaC コードのリリースと管理に Terraform Cloud Workspace を使用します。データ開発チームは、特定の ETL タスク シナリオ用の Glue スクリプトを開発し、CodeCommit を使用してコード管理を行い、CodeBuild を使用して CI/CD コンテンツを実装し、最後に CodePipeline または EventBridge を介して CI/CD パイプラインのシリアル接続を実現する責任を負います。2 つのチームは協力して、次のシナリオを実現します。
「企業の人事部門は、ダウンストリーム データ アプリケーションのためにデータ ソースを MySQL に取り込む必要があります。データ エンジニアが Glue スクリプトの開発を完了したら、クラウド運用および保守チームが開発した Glue テンプレートを使用して、新しい Glue スクリプト (Python シェル) を作成します。 template) リソースをバッチで作成します。後続のデータ エンジニアが Glue スクリプトを作成または変更すると、この一連のパイプラインは CodeCommit で変更されたコンテンツを自動的にキャプチャし、そのコンテンツを s3 に同期できます。s3 の変更は、新規/更新リソースをトリガーする機能を直接反映します。 IaC 開発/クラウド運用チームが関与することなく、Terraform で実行できます。」
以下の最適化計画では、クラウド上でデータ アプリケーションを開発および保守する際の、クラウド運用保守チームとデータ開発チームの責任範囲を明確に定義します。
実装手順
(1) 統一されたプロセスと規範
CI/CD パイプラインの実装方法、Glue スクリプトのアップロードと保存方法、リソースに必要な構成情報 (インスタンス タイプ、必要な IAM 権限など) を含む、データ開発チームとクラウド運用保守チーム間の主要なプロセスと手順を確認します。 、ネットワーク）お待ちください。
(2) Terraformスクリプト開発
クラウド運用および保守チームは、構成パラメーター、リソースの追加/変更のためのコードを含む、Glue リソースの IaC スクリプトの開発を担当します。開発したコンテンツはglue-etlディレクトリに一律に配置されます。このディレクトリの内容の例は次のとおりです。
|____glue-etl
| |____output.tf
| |____data.tf
| |____main.tf
| |____Readme.md
| |____policy.tf
| |____variables.tfクラウド運用保守チームは、glue-etl モジュール ( module ) をカプセル化し、Terraform Cloud の対応するワークスペースに公開します。
上記の glue-etl モジュールには次のものが含まれています。
- tf には、このモジュールによって出力された一連のパラメーターが含まれています。
- tf には、現在のリージョン、現在のユーザー情報、Glue スクリプトがアクセスする必要があるデータベースの Secret Manager キー文字列、Glue リソースのデプロイに必要なサブネット グループなど、Amazon 環境内のいくつかの既存のリソースへの参照が含まれています。必要な情報。
- tf には、Glue の実行に必要な IAM ロールに対応する関連する IAM ポリシー コレクションが含まれています。
- tf には、このモジュールを呼び出すためにユーザーが渡す必要がある一連の構成パラメーターが含まれています。
スペースの問題のため、上記の .tf の特定のコード内容は省略されています。
(3) s3 コンテンツの変更を監視する
クラウド運用およびメンテナンス チームが glue-etl モジュールの開発を完了し、それを Terraform Workspace にアップロードした後、データ開発チームは .tf ファイルを初期化し、local キーワードを使用してスクリプトをパス (例:変数bucket_name、job_path_prefix、line_of_business)を.tfファイルに追加します。
locals {
bucket_name = "sample-bucket-glueetl"
job_path_prefix = toset(["hr-mysql-source1-python-scripts"])
line_of_business = "hr-department"
}2 番目のステップは、Terraform によって提供される data.aws_s3_bucket_objects を通じて s3 上の Glue スクリプトのストレージ パスを取得することです。
data "aws_s3_bucket_objects" "glue_job_objects_for_people_mdm_staging" {
for_each = local.job_path_prefix
bucket = local.bucket_name
prefix = "${local.line_of_business}/${each.key}"
}次に、Glue モジュールに必要な入力パラメータを設定します。次の例は、文字列操作を通じて Glue ジョブ名をアップロードされたスクリプト名にマッピングする方法を示しています (マッピング ルールはカスタマイズできます。この例では、.py ファイルのプレフィックスが Glue ジョブ名として使用されています。図 8 を参照)。 、そして -name-map のローカル変数のジョブに入れられます。実際のアプリケーションでは、モジュールの入力パラメータとして複数のローカル変数を構成する必要がある場合があります。
locals {
job_name_map = {
for job_prefix in
[for job_name in
[for py_name in data.aws_s3_bucket_objects.glue_job_objects_for_people_mdm_staging["hr-mysql-source1-python-scripts"].keys : split("/", py_name)[2]
] : split(".", job_name)[0]
] : job_prefix => "${job_prefix}.py" if job_prefix != "" }
}最後に、Terraform Cloud Workspace でモジュール (この例では glue-etl) を呼び出して、特定の仕様の Glue Python シェル スクリプトをバッチで作成します。
module "glue-etl-type1" {
source = "app.terraform.io/repo/glue-etl/aws"
subnet_list = ["subnet-1","subnet-2","subnet-3"]
bucket_name = local.bucket_name
line_of_business = local.line_of_business
secret_manager_id = "some-secretmanager-id"
if_connection = true
conn_name = local.connection_name_staging
glue_job_name_list_for_python = local.job_name_map
max_concurrent_runs_for_python = 4
max_retries_for_python = 0
}(4) CodeBuild主導のCI/CDパイプラインの実装
この記事では EventBridge を使用して CodeCommit と CodeBuild を直列に接続していますが、使用習慣に応じて Amazon CodePipeline を選択して同じ機能を実現することもできます。開始する前に、対応する Amazon CodeCommit と CodeBuild が初期化されていることを確認してください。
以下に示すように、CodeCommit ウェアハウスの追加および変更イベントによってトリガーされる EventBridge ルールを設定します。
{
"source": [
"aws.codecommit"
],
"detail-type": [
"CodeCommit Repository State Change"
],
"detail": {
"event": [
"referenceCreated",
"referenceUpdated"
]
}
}このルールの入力トランスフォーマーを構成し、次のように入力パスと入力テンプレートをそれぞれ定義します。
{"referenceType":"$.detail.referenceType","region":"$.region","repositoryName":"$.detail.repositoryName","account":"$.account","referenceName":"$.detail.referenceName"}
{"environmentVariablesOverride": [
{
"name": "REFERENCE_NAME",
"value": <referenceName>
},
{
"name": "REFERENCE_TYPE",
"value": <referenceType>
},
{
"name": "REPOSITORY_NAME",
"value": <repositoryName>
},
{
"name": "REPO_REGION",
"value": <region>
},
{
"name": "ACCOUNT_ID",
"value": <account>
}
]}CI/CD パイプラインの特定のプロセスを反映するように buildspec.yml を構成します。この例では、パイプラインのコンテンツには次のものが含まれます。
- コード内で必要な git-remote-codecommit およびその他の Python 依存関係 (この例では、Makefile を使用して依存関係をインストールします) またはコマンド (この例では Terraform など) をインストールします。
- コード品質検査、構文検査、セキュリティ脆弱性スキャン、単体テストなど、ETL スクリプトまたは .tf ファイル コードの CI プロセスを実現します。
- CI プロセスが終了したら、CodeCommit の更新されたコードを、Glue コンテンツが保存されている s3 パスに同期します。s3 が更新コードを受信したら、次の操作を実行します。
- Terraform の構文チェック ( terraform fmt、validate、lint )
- リソース変更チェック (terraform plan)
- 最終リリース (terraform 適用)
AWS CodeBuildversion: 0.2
env:
variables:
TF_VERSION: "1.0.6"
phases:
install:
runtime-versions:
python: 3.8
commands:
- pip install git-remote-codecommit
- make install
pre_build:
commands:
- echo Hello pre build
- cd /usr/bin
- "curl -s -qL -o terraform.zip https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip"
- unzip -o terraform.zip
- cd -
build:
commands:
- echo build
- make format
- make lint
- make test
- env
- git clone -b $REFERENCE_NAME codecommit::$REPO_REGION://$REPOSITORY_NAME
- dt=$(date '+%d-%m-%Y-%H:%M:%S');
- echo "$dt"
- aws s3 sync . s3://sample-bucket-glueetl/hr-mysql-source1-python-scripts/
- terraform init
- terraform fmt -recursive
- terraform validate
- terraform apply -auto-approve
post_build:
commands:
- echo post build
- echo "terraform fmt & validate apply completed on `date`"
- echo "Makefile completed on `date`"buildspec.yml ファイルを対応する CodeCommit ウェアハウスにアップロードし、新しい CodeBuild プロジェクトを作成してウェアハウスを指定し、EventBridge をイベント トリガーとして使用して CodeCommit コンテンツの変更を監視し、イベントを CodeBuild に出力して CI/CD パイプラインの完全なセットを実装します。 。スキーマは次のようになります。
予防
- 上記のソリューションを実装するには、さまざまな Amazon サービス間のアクセス権限と、必要な IAM ロールの実行権限が十分であるかどうかに注意する必要があります。
- この記事で説明する方法では、構成が異なる Glue スクリプトのリソースの作成を完全に自動化することはできません。データ開発チームは、必要に応じて、対応する Terraform モジュールを再度呼び出し、上記のプロセスを繰り返す必要があります。
- この記事で提供されるソリューションは、Amazon Code コンポーネントを使用してコードのバージョンとリリースを管理するシナリオのみを対象としています。外部コード管理コンポーネントと CI/CD ツールについては、この記事ではこれ以上説明しません。
要約する
この記事では、特定のケースを通じて、データ開発者が Terraform Cloud Workspace を通じてリモート IaC モジュール (モジュール) を呼び出し、EventBridge によって駆動される Amazon CodeCommit および Amazon CodeBuild と組み合わせて CI/CD パイプラインを開発し、データ アプリケーション スクリプトの変更を自動的にキャプチャし、対応するスクリプトを作成することを示します。クラウド リソースをバッチで管理します。データ アプリケーションに関連するリソース管理とコード変更リリース プロセスを自動化することで、クラウド運用保守チームはコード資産の追加/変更によってもたらされる管理プレッシャーを軽減します。データ アプリケーションでの追加のコード変更を気にする必要がなくなりました。一方、データ開発チームは、コード変更によるクラウド上のリソースへのその後の影響を心配することなく、コード開発と ETL スクリプトの運用および保守に集中できます。
参照文書
[1] Amazon Code コンポーネントを使用してデータを s3 に自動バックアップする
[2] Input Transformer を使用して EventBridge イベント情報をカスタマイズする
この記事の著者
毛元斉
Amazon プロフェッショナル サービス チームのデータ サイエンティスト。クラウド データ プラットフォーム設計における統計学習、機械学習、データ マイニング、および関連コンサルティング サービスを担当します。サービス業には医療、金融、無人運転などが含まれ、開発・運用・保守において豊富な経験を積んでおります。
リャン・ユー
Amazon プロフェッショナル サービス チームの DevOps コンサルタント。主に DevOps テクノロジーの実装を担当します。特にクラウド ネイティブ サービスと関連テクノロジーに熱心です。余暇には、スポーツや家族との旅行を楽しんでいます。