🗂

AWS Step Functions + Lambdaで整った実行環境を構築する

2022/11/11に公開

AWS

はじめに

エビリーのプロダクト開発本部でエンジニアをしている高田と申します。
本記事ではStep Functions + AWS Lambdaの構成で、整った実行環境を実装していきます。

初めに整った実行環境と呼ぶにはどのような条件を満たすべきか検討します。
その後整った実行環境を実際に実装していくことで、より運用面に優れたシステムを構築していきます。

整った実行環境とは

Step functionsでの実行環境をシンプルに構築する場合、AWSのリファレンスやチュートリアルをなぞり、AWSコンソールからステートマシンの定義や設定をすることが一番の近道となります。
一方でこれを実運用に乗せることを考え始めると様々な課題が浮上してきます。

リソース・コードのバージョン管理が困難
AWS側でのUI変更のたびに運用手順の見直しが必要となる
開発・本番環境の同一性を保つことが困難
変更をAWS上に反映しなければ動作確認ができない
複数メンバーでの継続的な開発・運用が困難

本記事では上記の課題を解消した実行環境を整った実行環境と呼ぶことにします。

以下では整った実行環境と呼ぶためにはどのような条件を満たすべきか検討していきます。

1. リソースがコードで管理されていること

AWSリソースを単純にAWSコンソールから構築した場合、以下のような運用面の不都合が発生します。

構築のし直しや別環境での構築が困難
変更内容をバージョン管理できない

そのため開発環境・本番環境の切り分けや複数メンバーでの開発を前提とした継続的な開発のためには、リソースのコード化が必須となります。

2. デプロイがコマンドから実行できること

デプロイに複雑な手動操作が要求される場合、開発メンバー間の習熟度の差やAWSコンソール側のUI変更によっては対応が困難になります。

そのため可能な限りシンプルなコマンドを実行するだけでデプロイを実行できる環境を構築することが重要です。

3. ローカル実行環境があること

コードの修正をAWS上に反映しないと確認できない場合、細かな変更のたびに動作確認のためのデプロイが求められます。
そのため特にデバッグのフェーズにおいて、AWS利用料金の増加やデプロイの待ち時間増加による開発効率の低下などの弊害が生じてきます。

これを防ぐために、ローカルでの実行環境を構築して動作が保証できた上でデプロイできる環境が重要です。

整えていく

以下を実装したコードをこちらに公開しています。

1. リソースをコードで管理する

AWSリソースを管理するフレームワークは、主なものだけで以下のような選択肢があります。

本記事ではTypeScriptで実装されたコードのビルド・デプロイが簡単なAWS CDKを採用します。

基本的には公式のガイドをなぞることでAWS CDKの実行環境を構築できます。AWS CDKを使った環境構築ではAWS CloudFormationが使われるため、技術的背景を知りたい方はCloudFormation側のドキュメントも併せてご確認ください。

上記の手順通りに進めると aws-cdk-lib のライブラリを利用したコードが作成されます。
一方で他の方の記事を検索すると @aws-cdk/core を利用した記法も見受けられます。

これは@aws-cdk/coreがAWS CDK v1を利用した記法、aws-cdk-libがAWS CDK v2を利用した記法であるという違いがあります。本記事ではv2を利用するため公式のガイドに則った実装を行なっています。

2. デプロイをコマンドから実行する

AWS CDKでリソースを定義した場合 cdk deploy コマンドからデプロイできるようになります。
コマンドの実行環境によっては profile の指定が必要になるため、package.json に定義すると運用が楽になります。

例: profile名が aws である場合

"scripts": {
    "deploy": "cdk deploy --profile aws",
}

3. ローカル実行環境を構築する

ローカルで実行できる環境を立てるため、本記事ではStep Functions、Lambdaそれぞれを実行するdockerコンテナを立てることにしました。

AWS Lambda実行コンテナ

CDK自体にはLambdaのローカル実行機能は無いため、上述したフレームワークのSAMを利用します。

Lambda起動時にjsonまたはyaml形式のCloudFormationテンプレートファイルを読み込ませる必要がありますが、CDKを利用しているため開発者側では定義してません。

そのためCDKで自動生成されるテンプレートファイルを参照するようにします。cdk synth コマンドを実行、または cdk deploy コマンドを用いて一度デプロイすることでテンプレートファイルを cdk.out ディレクトリの下に生成できます。

Step Functions実行コンテナ

Step Functionsの実行環境はAWS公式からdocker image (amazon/aws-stepfunctions-local)が配布されているため、本記事ではこれを利用します。
コンテナ構築時に定義する AWS_ACCESS_KEY_ID 等の環境変数はダミーの値で問題ありません。

実行環境立ち上げのため、初めにテンプレートファイルからステートマシンの定義箇所を抜き出したjson形式のファイル(asl)を作成する必要があります。

本記事では cdk-asl-extractor ライブラリを用いて該当箇所を抜き出します。これはステートマシンに変更が入るたびに必要な処理であり、再実行しやすくするため package.json 内に create-template としてコマンドを定義しています。

"scripts": {
    "create-template": "cdk synth & npx cdk-asl-extractor cdk.out/FetchYoutubeDataStatemachineStack.template.json"
},

cdk.out/FetchYoutubeDataStatemachineStack.template.json の箇所はプロジェクトのStack名によって変化します。Stack名が分からない場合は一度 cdk synth を実行し、cdk.out 以下に出力されたテンプレートファイル名を参照してください。

ステートマシンの定義ファイルが作成された後、Step Functionsのステートマシン作成・実行・実行結果の取得コマンドを実行することで動かすことができます。
これらのスクリプトは statemachine 以下に作成しています。

ステートマシン作成: 環境立ち上げ時・ステートマシン変更時に実行する必要がある

aws stepfunctions --endpoint http://localhost:8083 create-state-machine --name "LocalStatemachine" --role-arn "arn:aws:iam::012345678901:role/DummyRole" --definition file://asl-0.json

ステートマシン実行

aws stepfunctions --endpoint http://localhost:8083 start-execution --state-machine arn:aws:states:ap-northeast-1:123456789012:stateMachine:LocalStatemachine --input file://events/input.json

ステートマシン実行結果の取得

aws stepfunctions --endpoint http://localhost:8083 list-executions --state-machine arn:aws:states:ap-northeast-1:123456789012:stateMachine:LocalStatemachine

まとめ

本記事ではStep Functions + Lambdaの実行環境を、実運用上の課題を解消した形での実装を紹介しました。

課題が何であるかを整理した上で、リソースのコード管理・デプロイのコマンド実行・ローカル実行環境の構築に着目して実装しました。