AWSクラウド基盤アーキテクトの松井です。コンテナ、サーバレス、IaC、CI/CDなどの最新技術を駆使し、お客様に最適なAWSアーキテクチャを提案・構築しています。
AWSは、AWSリソースをコード化し、構築・管理できるサービスIaC（Infrastructure as Code）を提供しています。AWSのIaC向けサービスといえば、AWS CloudFormationですが、開発者がより効率的に構築・管理できるツールとして、AWS SAM（AWS Serverless Application Model）やAWS CDK（AWS Cloud Development Kit）なども提供されているため、IaC導入の敷居が低くなり、IaCを取り入れた事例が多くなってきていると感じています。
本コラムでは、3回に渡り、IaC化に最適なAWS CDKを活用して、AWSマネージドサービスであるAWS GlueのCI/CD環境構築を行います。今回は①＜検討編＞として、AWS GlueのCI/CD環境構築のための構成を検討します。
- 検討編（AWS GlueのCI/CD構成の検討）★今回
- 構築：環境デプロイ編（AWS GlueのCI/CD環境の構築とAWS Glueのデプロイ）
- 構築：テスト・承認編（AWS GlueのCI/CD環境に自動テストと承認を追加）
※AWS CDK、AWS Glue、CI/CDについては末尾の用語解説集をご参照ください。
AWS GlueのCI/CD環境構築
AWS Glueは、ソースコードをデプロイすれば即時利用できるマネージドサービスです。AWS Lambdaと近いサービスですが、AWS LambdaにはAWS SAM CLIといったテストやデプロイを容易にできるツールが存在するのに対して、AWS Glueでは類似するサービスが提供されていません。そのため、AWS Glueをデプロイする場合には、環境構築とコードデプロイをそれぞれ実行しなければならない、などの手間が生じます。そこで、AWSのCI/CD関連サービスを用いることで簡単にデプロイできるかを調査するため、AWS GlueのCI/CD環境構築を行いました。
AWSの公式手順では、AWS CloudFormationを活用した構築手順が紹介されています。AWS CDKを用いたケースや、環境単位で設定値を分ける方法など細かい説明はなかったため、本コラムではそれらにも少し踏み込んで解説します。
CI/CD環境構築の進め方
今回のCI/CD環境構築の進め方は以下のとおりです。
[1] ソースアクション
AWS GlueジョブのスクリプトコードとAWS CDKのコードをリポジトリにプッシュ
[2] ビルドアクション（開発環境）
AWS CDKのコードを開発環境向けのAWS CloudFormationテンプレートに変換
[3] デプロイアクション（開発環境）
AWS CloudFormationのテンプレートを利用して開発環境向けにAWS Glueジョブをデプロイ
[4] テストアクション（開発環境）
AWS Glueのジョブを実行
[5]承認アクション
テスト結果の確認＋本番環境へのデプロイ承認（手動作業）
[6] ビルドアクション（本番環境）
AWS CDKのコードを本番環境向けのAWS CloudFormationテンプレートに変換
[7] デプロイアクション（本番環境）
[1][6]のコード群を利用して本番環境向けにAWS Glueジョブをデプロイ
上記を構成図として表現したものが下図です。
それぞれのステップで実施する設定や動作について解説します。
[1] ソースアクション
AWS GlueジョブのスクリプトコードとAWS CDKのコードをリポジトリにプッシュ
本コラムではソースコード管理のリポジトリとしてAWS CodeCommitを利用しますので、AWS CodeCommitにプッシュされたことをトリガーにCI/CDのプロセスが稼働するようにします。また、リポジトリにプッシュするコードには、AWS Glueジョブを構築するAWS CDKのコードと、AWS Glueジョブで実行するPythonコードを含み、次の工程にそのソースコードファイル群（アーティファクト）を渡します。
[2] ビルドアクション（開発環境）
AWS CDKのコードを開発環境向けのAWS CloudFormationテンプレートに変換
開発環境向けのAWS CloudFormationテンプレートを作成します。（AWS CDKのソースコードには、予め環境単位でリソースの名称や一部設定が切り替わる仕掛けをしておきます。）AWS CDKのソースコードはそのままでは利用できないので、AWS CodeBuildを利用して、[1]から受け取ったアーティファクトに含まれるAWS CDKのソースコードを、開発環境向けのAWS CloudFormationのテンプレートに変換します。
[3] デプロイアクション（開発環境）
AWS CloudFormationのテンプレートを利用して開発環境向けにAWS Glueジョブをデプロイ
[2]で準備したテンプレートを利用して開発環境向けにAWS Glueジョブをデプロイします。また、AWS Glueジョブは、ジョブで実行するソースコードをAmazon S3に配置する必要があるため、[1]でプッシュしたAWS GlueジョブのPythonコードをAWS Glueジョブで定義したAmazon S3バケットの所定のパスにアップロードします。本来であればこの2つの工程は別々で実行しなければならないのですが、AWS CodePipelineを利用することで1つのアクションとしてまとめて実行できます。
[4] テストアクション（開発環境）
AWS Glueジョブを実行
[3]で作成した開発環境向けのAWS Glueジョブを実行して、正常に終了するかテストします。AWS Glueジョブの実行結果を取得できる仕組みを利用して実行結果を確認し、成功した場合のみ次の工程に進むようにします。また、AWS CodeBuildに搭載されている、テスト結果をレポート化してレビューしやすくする機能を利用します。
[5]承認アクション
テスト結果の確認＋本番環境へのデプロイ承認（手動作業）
本番環境へデプロイする前に、関係者が[4]のテスト結果を確認する仕掛けとして、承認プロセスを挟むことができます。テストが成功した後、Amazon SNSに登録されているメールアドレスに対して承認依頼のメールが送信されます。受信した担当者は、そのメールからテストおよびデプロイ内容を確認し、問題がなければ次の工程に進むように承認作業を行います。
[6] ビルドアクション（本番環境）
AWS CDKのコードを本番環境向けのAWS CloudFormationテンプレートに変換
AWS CDKの、環境単位でリソースの名称や一部設定が切り替わる仕掛けを使って、本番環境向けのAWS CloudFormationテンプレートを作成します。
[7] デプロイアクション（本番環境）
AWS CloudFormationのテンプレートを利用して本番環境向けにAWS Glueジョブをデプロイ
[6]で準備したテンプレートを利用して本番環境向けにAWS Glueジョブをデプロイします。
CI/CD構成のメリットと補足事項
CI/CD構成のメリット
・開発時の効率的なデプロイ
AWS Glueジョブのソースコードの更新と、AWS Glueジョブ自体の更新にはそれぞれ異なる作業が必要になります。開発時にはそれらの更新頻度が高いことを考えると、より効率的に開発を進めることが望ましいため、ソースコードをプッシュするだけでそれらがデプロイ（更新）できるように構成しました。（[3]）
・本番環境移行時の承認
本番環境のデプロイは第三者（責任者）などの承認が必要なケースもあると思います。今回は、本番環境デプロイ前に承認プロセスを挟めるような構成としました。（[5]）
補足事項
・[4]のテストは、実際に構築した環境を動かして確認していますが、コスト面が気になる、またはローカルテストと同じ環境でテストを行いたい場合には、AWS CodeBuild上でAWS Glueの環境を構築してテストを実行させることが可能です。
ご興味がある方は、以下のAWS公式ブログをご参照ください。
・本コラムのCI/CD構成は、同じAWSアカウント内に本番環境をデプロイするようにしていますが、もし本番環境用のアカウントなど別アカウントにデプロイしたい場合には、本番環境用アカウントに[7]の工程を含むAWS CodePipelineを構築し、[6]で作成したアーティファクトを参照できるようにした上で、開発環境用アカウントのAWS CodePipelineから本番環境用アカウントのAWS CodePipelineを実行することで可能になります。
手順については、以下のAWS公式ドキュメントをご参照ください。
・本コラムでは、AWS CDKを活用して、3つのAWS CloudFormationのスタックを作成しており、すべて同じリポジトリで管理するようにしています。
- CicdForGlueStack：AWS GlueをデプロイするためのCI/CD環境を管理するスタック
- GlueJobStack-dev：開発用のAWS Glue環境を管理するスタック
- GlueJobStack-prod：本番用のAWS Glue環境を管理するスタック
GicdForGlueStackはローカル環境からAWS CDK CLIを実行してCI/CD環境を構築します。GlueJobStack-{dev/prod}は、GicdForGlueStackで構築したCI/CD環境から（[3][7]）それぞれデプロイされるようになっています。なお、GicdForGlueStackとGlueJobStackはデプロイするタイミングが異なるため、別々に管理することが望ましいと思いますので、AWS CDKのソースを分けた管理方法はまた別の機会に検討したいと思います。
・[5]では承認の通知のみを送信していますが、AWS CodePipelineの中でエラーや完了のステータスも通知したい場合には、通知ルールを設定することで可能になります。
通知対象を増やしたい場合には以下のAWS公式ドキュメントをご参照ください。
さいごに
今回ご紹介したCI/CDの構成は、すべてのユーザーにとって最適というわけではありません。CI/CDの構成を検討する場合、正解を求めてしまいがちですが、この分野においては「銀の弾丸などない」のです。試行錯誤しながら、それぞれのプロジェクトに合った構成へと改善していく必要があります。今回ご紹介した構成が、皆様のCI/CD導入において少しでも参考になれば幸いです。
次回から、今回ご紹介したCI/CD構成を、実際にAWS CDKを用いて構築する手順を解説します。②＜構築：環境デプロイ編＞では開発環境をデプロイする[3]までの手順を、③＜構築：テスト・承認編＞では[4]以降の自動テストや手動承認の手順を解説します。
ぜひご覧ください。
用語解説
・AWS CDK
馴染みのあるプログラム言語を利用してAWSリソースを構築・管理できるツールです。AWS CDKでは高レベルで抽象化されたコンストラクトパッケージが多数提供されており、AWS CloudFormationよりも少ないコード量でAWSリソースを定義できます。AWS CDKでコーディングしたソースコードは、最終的にAWS CloudFormationテンプレートに変換され、AWS CDKのコマンドを通してデプロイできます。現在対応している言語はTypeScript、JavaScript、Python、Java、C#です。その他の言語も将来的には提供する計画が立てられているようです。
・AWS Glue
データ分析を行うために必要なデータ抽出、変換、ロードの一連の処理（通称ETL）を簡単に実行するためのマネージドサービスです。プログラムコードまたはAWSより提供されているGUIを利用して一連の処理を定義すれば、サーバを用意することなく、すぐにETL処理を実行できます。AWS GlueにはETLを容易に実装するために様々な機能が提供されていますが、本コラムでは、ETL処理をPythonなどのプログラムで実行するジョブ機能を利用しています。
・CI/CD（Continuous Integration／Continuous Delivery）
製品のリリースを効率的かつ安定的に実行するために、ソースコードの修正箇所の管理からビルド、テスト、リリースまでの工程を自動化する開発手法です。従来の手動運用ではヒューマンエラーや冗長的な作業の繰り返しによる非効率さなどの課題があるかと思いますが、CI/CDではそれらの課題を克服し、開発効率や品質を上げることができるメリットが備わっています。AWSでは、CI/CD向けのサービスを多数提供しており、Gitリポジトリ同様にソースコードを管理するAWS CodeCommit、ソースコードのビルドやテストをマネージドが環境で実行できるAWS CodeBuild、Amazon EC2やAmazon ECSなどのコンピューティングサービスにアプリケーションをデプロイするAWS CodeDeploy、ソースのプッシュからアプリケーションのデプロイまでの一連の流れを管理するAWS CodePipelineなどが存在しています。最近では、CI/CDだけでなく、IDEやコードリポジトリ、課題管理など開発において必要なツールを一元構築および管理できる、Amazon CodeCatalystというサービスも提供されています。
次の記事はこちら
AWS CDKを活用した効率的なAWS GlueのCI/CD環境構築②＜構築：環境デプロイ編＞
富士ソフトのAWS関連サービスについて、詳しくはこちら
アマゾンウェブサービス(AWS)
