AWS Step Functions のエラーハンドリングを実装しよう
山口 正徳 (AWS Community HERO)
こんにちは！AWS Community Hero の山口 (@kinunori) です。AWS サービスを利用した分散形アプリケーションやワークフローを構成する際に便利な AWS Step Functions をご存知でしょうか ? 私は自動化可能な定期処理やバッチ処理を構築する際に AWS Step Functions を活用しています。
この記事では AWS Step Functions を利用する際のポイントの 1 つとなるエラーハンドリングについて紹介します。
AWS Step Functions のエラーハンドリング
AWS Step Functions のエラーハンドリングを実現する一例として、以下のような方法があります。[ⅰ]
- ステート内のエラーハンドラーを利用する
- ステート内の処理リトライを利用する
- Choice ステートを利用する
- Amazon EventBridge を利用する
1. エラー時のステート遷移を利用したエラーハンドリング
AWS Step Functions では、エラーが発生した場合のステート遷移をカスタマイズすることができます。いわゆる try-catch による例外処理をイメージしていただけると分かりやすいかと思います。
以下にワークフロースタジオを用いた設定例を記載します。
ステートにて「エラー処理」タブより、「エラーをキャッチ」項目からキャッチャー (Catcher) を追加します。
キャッチャー (Catcher) では「Errors」にて エラー名 を選択し、「Fallback state」にエラー時に遷移させるステートを選択します。エラー処理を行うステートにて必要な場合には、「ResultPath」にてエラー時のデータを input データとして渡すことが可能です。
エラーキャッチを利用することで、例外エラーが発生した場合に、特定のステートへ処理をジャンプさせたり、エラー時のデータを使用してエラー処理用のステートを実行することなどができます。キャッチは複数設定することができますので、エラー名ごとにエラー処理を切り替えることが可能です。
またエラーキャッチは Parallel フロー、Map フローに対しても適用できるため、並列処理や繰り返し処理における例外処理にも利用できます。
画像をクリックすると拡大します
2. ステート内の処理リトライを利用したエラーハンドリング
Step Functions のリトライは、ステートマシンの中でネットワークエラー、タイムアウト、同時実行数の制限などステートが失敗した場合にリトライを行うために使用します。
以下にワークフロースタジオを用いた設定例を記載します。
ステートにて「エラー処理」タブより、「エラー時に再試行」項目から再試行者 (Retrier) を追加します。再試行者 (Retrier) には「Errors」にてリトライの実施対象とする エラー名 を選択します。
リトライには、インターバル (Interval)、最大リトライ回数 (Max attempts)、
リトライごとの待ち時間を増加するために使用する係数 (Backoff rate) をそれぞれ指定可能です。これら 3 つの設定を組み合わせることにより、エクスポネンシャルバックオフを実装し、リトライによる負荷増加を防ぎ、リトライを効率的に行うことができます。[ⅱ]
リトライを使用することでステートマシンの実行をより強固にすることができます。ただし、リトライの頻度が高すぎると、ステートの遷移数や実行時間が増えてしまい、ステートマシンの実行コストが増加する可能性があるため、適切なリトライ回数と間隔を設定することが重要です。
画像をクリックすると拡大します
3. Choice フローを利用した処理ハンドリング
ステート処理としては正常と返却されているものの、処理によって生成されたデータによって正常または異常を判断したい場合には、Choice フローを利用した処理ハンドリングで実現できます。エラーハンドリングだけに利用するものではありませんが、意図しない状況で処理が進んでしまうことを防ぐことが可能です
例えば、特定の Amazon EC2 インスタンスが存在することが前提となっている処理がある場合に、EC2 DescribeInstances アクション と Choice フローを組み合わせることによって、該当の EC2 インスタンスが存在しないことによる例外エラーや処理の空振りを防ぐことができます。
以下にワークフロースタジオを用いた設定例を記載します。
例では、Choice フローにて EC2 DescribeInstances の実行結果よりEC2インスタンスの存在有無を確認するため、DescribeInstances より任意のJSONPathにデータが存在するかどうかを判定条件としています。データが存在する場合にはスナップショット取得処理へ移行し、データが存在しない場合には例外処理を行う Lambda 関数の Invoke ステートへ移行するように指定しています。
Choice フローは 2 つ以上の条件を設定できるため、複数の条件に分岐した例外処理を構成することも可能です。
画像をクリックすると拡大します
4. Amazon EventBridge を利用したエラーハンドリング
前述の 1. エラー時のステート遷移を利用したエラーハンドリング、2. ステート内の処理リトライを利用したエラーハンドリング で紹介したように、Step Functions が提供しているエラーハンドラーを使用してエラーを処理できますが、EventBridge ルールを使用することで、エラーハンドラーに依存せずにエラー情報を取得することができます。
EventBridge ルールを利用したエラーハンドリングでは、ステートごとのエラーハンドリングは行えませんが、ステートマシンの実行結果に対するエラーハンドリングを行うことが可能です。ステートマシンの処理結果 (ステータス) が失敗 (FAILED)、中断 (ABORTED) やタイムアウトなどの場合に、何かしらのエラー処理を行う際に便利です。
例えば、下記のようにイベントパターンを設定した EventBridge ルールを作成し、ターゲットにチャット通知を処理する Lambda 関数を設定することで、ステートマシンの処理結果 (ステータス) が失敗 (FAILED) だった場合に、EventBridge ルールを通じて Lambda 関数を起動し、チャットへ通知することができます。
{
"source": [
"aws.states"
],
"detail-type": [
"Step Functions Execution Status Change"
],
"detail": {
"status": [
"FAILED",
"TIMED_OUT",
"ABORTED"
]
}
}EventBridge ルールを使用することで、Step Functions のエラーハンドラーに依存せずに、より柔軟なエラーハンドリングを実現することができます。
ただし、EventBridge ルールを使用する場合には、エラーが発生した場合に Lambda 関数を起動するため、実行時間やコストなどが増加する可能性があるため、適切な設計が必要です。
まとめ
Step Functions のエラーハンドリングについて紹介しました。
Design for Failure という考えもあるようにシステムすべてにおいて言えることですが、Step Functions も例外ではなく、必ずしも処理成功を約束するものではありません。
構築したワークフローの実行をより強固にするためにはエラーハンドリングを考慮した実装も必要となります。
この記事が Step Functions を活用する皆さまの手助けになれば幸いです。
最後まで読んでいただき、ありがとうございました。
[ⅰ] 記載している方法以外のエラーハンドリングも存在しますが、ここでは一例として記載しています。
[ⅱ] ワークフロースタジオを利用する場合は、Lambda Invoke アクションなど一部のステートにはリトライがデフォルトで設定されています。
筆者プロフィール
山口 正徳
フォージビジョン株式会社 / AWS Community Hero
大手 SIer 、フリーランスを経て、クラウドインテグレーションを手掛けるフォージビジョン株式会社にインフラエンジニアとして入社。現在、同社で AWS 事業部長を務める。
JAWS DAYS 2014 への参加をきっかけに AWS に興味を持ち、2016 年から本格的に AWS を使いはじめる。2018 年から JAWS-UG 千葉支部の運営に携わるように。現在「APN Ambassador / 2020 APN AWS Top Engineers」であり、全世界共通の認定プログラムである AWS 公式の「APN Ambassador」のひとりでもある。
AWS を無料でお試しいただけます