AWS GlueのworkflowsからAWS Step Functionsに乗り換えた話

2022年12月1日 10:24

この記事はUMITRON Advent Calendar 2022 1日目の記事です。

こんにちは、UMITRONの宮山（@jkatagi）です。最近はSplatoon3とポケモンバイオレットの両作をプレイして忙しい日々を送っています。さて、今年も昨年に引き続きUMITRONでAdvent Calendarを開催することになりました。嬉しいことにたくさんの方から「Advent Calendar読みました！」という声をいただいております。

UMITRON Advent Calendar 2022 1日目は技術的な話として、AWS GlueのworkflowsからAWS Step Functionsに乗り換えた話を書きます。

UMITRONで取り扱うデータについて

UMITRONでは持続可能な水産養殖を地球に実装するをミッションに、日々いろんなデータを取り扱っています。そのデータは魚の動画像から、地球全体の環境データといった地球規模のデータまで幅広くあります。とりわけ地球全体の環境データにおいては、そのデータサイズから並列分散処理を行う必要があります。

UMITRONではこのデータ処理にSpark（PySpark）を採用しており、実行環境としてAWS Glueを用いています。このAWS Glueを管理するワークフローとして、これまでAWS Glueのworkflowsを用いていました。理由としてはAWS Glue環境においてデフォルトで利用できるためでした。しかしながらAWS Glue + workflowsの組み合わせで数年運用している中で、いくつかの課題が見えてきました。課題は大きく2パターンに分けられ、ワークフローとしての問題と、コードの問題がありました。

Glueのworkflowsの問題とコードの問題

まずはワークフローとしての問題から挙げていきます。

一つ目はAWS Glueのjobが失敗したときに、workflowsのコンソールから当該の実行のjob idに飛べない点です。一応job idは記載されているのですが、AWS Glue Studioというインターフェースから当該のjob idを検索して...という手順を踏まないとなりません。そのため障害発生時のデバッグが難しくななり、再実行も困難になるというのがあります。

二つ目は個別のworkflowの成功可否を判断するのが難しい点です。workflowは個別のjobが正常でも異常でも、終了しさえすればCompletedになります。そのため実行結果を確認するためには、WorkflowRunをboto3などで取得し確認する必要があります。

次にコードの問題として、環境データ生成の過去分実行がしづらいという問題がありました。これは例えば日付などの変数がコード内部で動的に生成されているためでした。

以上の問題を解決するために、ワークフローエンジンの乗り換えと変数を外部から渡すようなアーキテクチャに変更することを検討しました。それを踏まえて社内で調査しつつ、AWSのソリューションアーキテクトの方々と相談し、最終的にAWS Step Functionsに乗り換えることにしました。

AWS Step Functions

AWS Step Functionsは公式では以下のように説明されている、ワークフローサービスです。

AWS Step Functionsは、デベロッパーが AWS のサービスを利用して分散型アプリケーションを構築し、プロセスを自動化し、マイクロサービスのオーケストレーション、データと機械学習のパイプラインを構築できるようにするビジュアルワークフローサービスです。

https://aws.amazon.com/jp/step-functions/

AWS Step Functionsにした理由は、上で挙げた問題を解決するのに加え、以下の理由があります。

フルマネージド
料金が比較的安い
AWSサービス間の連携が簡単

フルマネージド

UMITRONはスタートアップでソフトウェアエンジニアの数も限られ、小規模なチームでアプリケーションの開発・運用をしています。そのような状況ではワークフローを専任で見守る人はいないため、なるべくワークフロー周りで手間がかからないことが重要です。AWS Step Functionsはフルマネージドであるため、ワークフローエンジン自体の監視は不要になります。その結果としてソフトウェアエンジニアは開発・運用に注力できます。

料金が比較的安い

フルマネージドのワークフローエンジンとして、Amazon Managed Workflows for Apache Airflowもあります。しかしながらこちらは最初のインスタンス（スモール）でも1ヶ月立ち上げっぱなしで約365 USD/month かかり、あまり安くないです。一方でAWS Step Functionsなら 0.025 USD/1000回（初回4000回は無料）であるため、状態遷移が少なく小規模なワークフローであれば比較的安価に済みます。

AWSサービス間の連携が簡単

他のワークフローエンジンだとAWSのサービスの呼び出しAPIの種類が限られていることがあります。他方AWS Step FunctionsはAWSのワークフローであるため、サービス間の連携が簡単になっています。

再実行や過去分実行の仕組み

課題となっていた再実行や過去分生成は、以下のように実現しています：

再実行
- AWSコンソールから再実行すればokです
- 実行時のjob idがURlになっており、クリックすると直接AWS Glue Studioに飛べるので、コンソールからのデバッグも容易です
過去分実行
- AWS Step FunctionsのState Machine（ワークフローを記述したもの）はJSONを入力として受け付けられます
  - したがってJSONを外からCLIで与えれば過去分実行できます
  - またState Machineを呼び出すState Machineを組んでもokです

また副次的な効果として、AWS Glueに限らないワークフロー（例えばAWS Fargateの実行管理）もAWS Step Functionsで取り扱うことができるようになりました。実際にAWS Glue以外のワークフローも徐々にAWS Step Functionsへの移行を進めています。

State Machineの組み方

Sate Machineの組み方にはいくつか方法があります。

JSONを書いて定義
Workflow Studioで視覚的に定義
AWS CDK で定義
AWS Step Functions Data Science SDK for Python で定義

弊チームでは以下の手順で行っています。

Workflow Studioで大まかに定義
細かいところをJSONで微修正
完成したらAWS CDKに（手動）翻訳

理由としてはIaCの観点から（弊チームで従来から使用している）AWS CDKで定義するのはマストなのですが、いきなりAWS CDKで書くのは辛いためです（最初は視覚的に定義した方が楽）。

はまりどころ

AWS Step Functionsを使っていて、いくつかのはまりどころがありましたので、ざっと共有します。

State Machineの終了時の挙動

State Machineのデフォルトの挙動は、各StateやTaskが失敗すると他のものも中断し、終了となります。これを防ぐために失敗時には catch して JSONに記録し、最後にまとめてチェックするようにしています。以下の記事が参考になります。

参考：AWS Step Functionsでバッチジョブワークフローの実行基盤を構築する

失敗したところから再開はできない

State Machineは失敗後に再開すると、新規に最初から実行されます。もし途中から実行したい場合は、（上記の参考記事にもあるように）別途DynamoDBなどに各ステップのStatusを記録し、それを参照するようにする必要があります（各ステップでDynamoDBにアクセスし、成功の記録があればそのステップを飛ばすなど）。

ワークフロー定義のJSONにクセがある

State Machine自身もJSONで記述されており（Amazon States Languageという言語）、そちらは公式ドキュメントに記載されているのですが、実行結果の変数の変換などの文法に関する公式ドキュメントは（私が探した限りでは）見つかりませんでした。例えばFargate Containerの実行結果から環境変数・コンテナステータスを取りたい場合、以下のように記載する必要があります（こちらのGitHubレポジトリを参考にしました）。

"Success": {    
  "Type": "Pass",    
  "Parameters": {      
    "Status": "Success",      
    "Environemnt.$": "$.Overrides.ContainerOverrides[0].Environment",      
    "ExitCode.$": "$.Containers[?(@.Name=='jkatagi-test-fargate')].ExitCode"    
  },    
"End": true  
}

このJSONの書き方（ $や @）は JMESPath の記法らしいです。

Stateの使い方は慣れが必要

これは公式ドキュメントを読んだり、簡単なState Machineを組んで実験して慣れました。ただ、どのワークフローエンジンでも固有の概念や文法があるので、ここは仕方がない部分だと思います。

おわりに

AWS Step Functionsに移行してから数ヶ月立ちましたが、今のところ順調に稼働しています。ワークフローエンジンとしての派手さ？はないですが、必要十分な機能を備えているため、個人的に満足しています。この記事を読んでAWS Step Functionsに興味を持っていただけたなら幸いです。

次回はtakc923さんによる「google/gousbを用いたソフトウェアをRaspberry Pi向けにクロスコンパイルする」です、お楽しみに！

ウミトロンでは一緒に働く仲間を募集しております。持続可能な水産養殖を地球に実装するというミッションの元で、私たちと一緒に水産養殖xテクノロジーに取り組みませんか？

https://umitron.com/ja/career.html

https://open.talentio.com/1/c/umitron/requisitions/746

この記事が気に入ったらサポートをしてみませんか？