AWS Step Functions

は、複数の処理をステートマシン (状態と遷移の定義) としてつなぐのワークフローサービスです。データパイプラインでは、ジョブ、のステップ、のクエリ、へのロード、の処理を順に動かし、失敗したら再試行して通知する、という流れを1か所で管理します。

DEA では、Standard と Express の選び分け、ジョブの完了を待つ統合 (.sync)、大量ファイルを並列で処理する分散マップ、Retry と Catch によるエラー処理が問われます。

Point

State Machine = ステートマシン (状態機械) です。「今どの状態にいて、次にどの状態へ進むか」を定義したものです。
ASL = Amazon States Language の略で、ステートマシンを JSON で書く言語です。
.sync は「同期 (synchronous)」の略で、ジョブが終わるまで待つ呼び出し方です。
和訳
- State: 状態
- Weblio英和辞書「state」

概要

では、処理の1つ1つを「ステート」として定義し、矢印でつなぎます。各ステートの入力と出力、成否は実行履歴として残るため、どこで失敗したかをコンソールのグラフで確認できます。

試験では、「で運用負荷を抑えての手順を管理したい」「ジョブの完了を待って次に進みたい」「数百万のファイルを並列で処理したい」という要件で Step Functions を選びます。

主要技術

①Standard ワークフローと Express ワークフロー ⚠️ 頻出

観点	Standard	Express
最長の実行時間	1 年	5 分
実行の保証	1 回だけ (exactly-once)	非同期は少なくとも1回 (at-least-once)、同期は多くても1回 (at-most-once)
実行履歴	に 90 日保持され、コンソールやで確認できます	Logs へ出力して確認します
統合のパターン	Request Response、ジョブの完了待ち (.sync)、コールバック (.waitForTaskToken)	Request Response のみ
失敗した実行の再開 (redrive)	対応	非対応
課金	状態遷移の回数	実行回数、実行時間、メモリ
向く処理	のように長く、各ステップの完了を待つ処理	IoT やストリームのイベントを大量に短時間で処理する

データパイプラインの ETL は、ジョブやのステップのように数分から数時間かかり、完了を待つ必要があるため、Standard を選ぶのが基本です。Express は、や API から来る大量の小さなイベントを、5 分以内に変換して書き込むような処理に向きます。

⚠️ 頻出: 「Glue ジョブの完了を待ってから次の手順に進みたい」「実行が数時間かかる」は Standard です。Express は 5 分を超えられず、.sync も使えません。

②サービス統合と .sync

の Task ステートは、を間に挟まずに AWS のサービスを直接呼べます。呼び方 (統合パターン) は3つです。

パターン	動き	データパイプラインでの例
Request Response (既定)	を呼び、応答を受け取ったらすぐ次へ進みます	に通知を送る、に1件書く
ジョブの実行 (.sync)	ジョブを起動し、完了するまで待ってから次へ進みます	の StartJobRun、のステップ追加、の StartQueryExecution、のジョブ
コールバック (.waitForTaskToken)	タスクトークンを渡して一時停止し、外部から SendTaskSuccess が返るまで待ちます	人の承認、外部システムの処理完了を待つ

.sync に対応するサービスには、AWS Glue、、Amazon EMR (EMR on 、EMR Serverless を含む)、Amazon Athena、AWS Batch、/、Amazon EKS、、などがあります。

一方、 Data API のように .sync の最適化統合がない API は、AWS 統合で呼び出します。SDK 統合は 200 を超えるサービスの API を呼べますが、ジョブの完了待ちはできません。そのため、ExecuteStatement を呼んだ後、Wait ステートと DescribeStatement の呼び出しを繰り返して状態を確かめるループを組みます。

⚠️ 頻出: 「Lambda で Glue ジョブを起動し、別の Lambda で完了をしている。コードを減らしたい」は、Step Functions の Glue 統合 (.sync) に置き換えます。

③Map ステートと分散マップ

Map ステートは、配列の要素ごとに同じ処理を繰り返します。2つのモードがあります。

モード	入力	並列度	向く場面
インライン	前のステートから渡された配列	同時に最大 40	数十件のテーブルやパーティションを順に処理する
分散 (Distributed Map)	のオブジェクト一覧、S3 上の CSV/JSON/JSON Lines/ ファイル、S3 インベントリなど	1 回の Map Run で子ワークフローを最大 10,000 並列	数百万のファイルやレコードを並列で処理する

分散マップは、各反復を子ワークフローとして実行し、その結果を S3 にまとめて書き出せます。子ワークフローの一部が失敗しても、許容する失敗の割合 (しきい値) を設定して処理を続けられます。失敗した子ワークフローだけを後から redrive することもできます。

ステートの入出力は 1 つあたり 256 KiB までです。大きなデータそのものをステート間で渡すのではなく、S3 のパスを渡し、データは S3 に置くように設計します。

④Retry と Catch ⚠️ 頻出

Task、Parallel、Map のステートには、失敗したときの扱いを宣言できます。

フィールド	役割	設定する内容
Retry	同じステートをやり直します	対象のエラー名 (States.TaskFailed、States.Timeout など)、最初の待ち時間 (IntervalSeconds)、待ち時間の倍率 (BackoffRate)、最大回数 (MaxAttempts)、待ち時間の上限 (MaxDelaySeconds)、ジッター
Catch	Retry で回復しなかったときに別のステートへ移ります	対象のエラー名、移る先 (通知、後片付け、補償処理)

一時的なエラー (、ネットワークの瞬断) は Retry でしながら再試行し、それでも失敗したら Catch で通知や失敗の記録へ進む、という2段構えが基本です。

さらに、Standard ワークフローには redrive があります。失敗、中止、タイムアウトで終わった実行を、終了から 14 日以内であれば、同じ入力のまま失敗したステップから再開できます。成功したステップは再実行されません。redrive は元の実行と同じ定義で動くため、ステートマシンの定義を直した場合は新しい実行を始めます。

Point

Backoff = 後退する の意味です。指数バックオフは、再試行のたびに待ち時間を 2 倍、4 倍と伸ばしていく方法です。
Jitter = ゆらぎ です。待ち時間にばらつきを入れ、多数のクライアントが同時に再試行して再び混雑するのを防ぎます。
Redrive は「もう一度走らせる」意味で、失敗した実行を途中から再開する機能です。

⑤変数と JSONata、データの受け渡し

ステート間のデータは、前のステートの出力が次のステートの入力になる形で受け渡されます。加えて、変数 (Assign) で値を保存しておき、後のどのステートからでも参照できます。たとえば、最初に決めた処理対象の日付を変数に入れ、途中のステートを経由せずに最後のロードで使えます。

データの抽出と変換の記法には、従来の JSONPath に加えて JSONata を選べます。JSONata では、ステートの中で文字列の結合、計算、条件式を書けるため、整形のためだけのを減らせます。

⑥サーバーレスワークフローの実装と保守

のワークフローを長く安全に運用するために、次の機能を使います。

機能	内容	使いどころ
バージョンとエイリアス	ステートマシンの定義をバージョンとして公開し、エイリアスで参照します。エイリアスは2つのバージョンへ実行を割合 (例: 90% と 10%) で振り分けられます	新しい定義を一部の実行で試し、問題があれば元のバージョンへ戻します。
のと	ExecutionsFailed、ExecutionsTimedOut、ExecutionThrottled などを監視します	失敗やを検知してで通知します。
CloudWatch Logs への出力	実行履歴をログとして残します	Express の履歴の確認に必須です。
の実行状態の変化イベント	実行が FAILED、TIMED_OUT などになったイベントを受け取ります	失敗したら自動で通知や後処理を行います。
でのデプロイ	、、でステートマシンと関連リソースをまとめて定義します	環境ごとに同じワークフローを再現します (#28)。
TestState	1つのステートだけを単体で試します	デプロイ前に入出力の加工を確かめます。

実行の起動は、EventBridge のルールや EventBridge Scheduler から行うのが一般的です。にファイルが届いたら起動する場合は、S3 のイベントを EventBridge に送り、ルールのターゲットにステートマシンを指定します。

試験対策

①判断マトリクス

問題文のキーワード	選ぶ機能	理由
の手順を順に実行、ジョブの完了を待つ	Standard ワークフロー + .sync	1 年まで実行でき、・・の完了を待てます。
大量の短いイベントを高で処理、5 分以内	Express ワークフロー	実行回数と時間の課金で、大量の短い処理が安くなります。
数百万のオブジェクトを並列に処理	分散マップ	S3 の一覧やファイルを直接入力にし、最大 10,000 並列で処理します。
一時的な失敗を再試行し、最終的な失敗は通知	Retry () + Catch →	宣言だけで再試行と通知を組めます。
失敗した実行を、成功した手順をやり直さずに再開	redrive	失敗したステップから同じ入力で再開します。
人の承認や外部システムの完了を待つ	.waitForTaskToken (Standard)	タスクトークンが返るまで一時停止します。
のを実行して終わりを待つ	Redshift Data の統合 + Wait + DescribeStatement のループ	Data API には .sync の最適化統合がありません。
大きなデータをステート間で渡したい	S3 に置いてパスを渡す	入出力は 256 KiB までです。

②よくある誤答

数時間かかるを Express で作ること。Express は 5 分が上限で、.sync も使えません。
完了待ちのためにですること。.sync の統合や Wait ステートを使います。
再試行を Lambda のコードの中に書くこと。Retry フィールドで宣言すれば、ワークフローの定義として見える形で管理できます。
をの代わりに「きっかけ」として考えること。起動のきっかけは EventBridge、手順の管理は Step Functions です。