AWS Step Functions

1. サービス概要¶

AWS Step Functions は、サーバーレスなワークフローオーケストレーションサービス。
JSON ベースの状態機械(State Machine)で、複数の AWS サービスやカスタムタスクをシーケンス化・分岐・並列実行し、可観測性の高いビジネスロジックを構築できる。

手動でのコード書き換えや複雑なエラー処理ロジックを組み込むことなく、エラーリトライ、待機、並列処理、条件分岐などの高度なフロー制御が行える。

ユースケースには、

マイクロサービス間オーケストレーション
データ処理パイプラインの自動化
機械学習ワークフロー
長期実行バッチジョブ
イベント駆動型アプリケーション

などが挙げられる。

2. 主な特徴と機能¶

2.1 状態機械とステートタイプ¶

ワークフローは「状態機械」として定義し、各ステート(State)で処理を定義する。

タスク(State Machine 内で特定の AWS サービス呼び出しや Lambda 実行)
Choice(条件分岐)
Parallel(並列処理)
Map(反復処理)
Wait(待機)
Pass(データパス操作のみ)
Succeed/Fail(ワークフロー終了)

など、多様なステートを提供する。

2.2 ワークフロータイプ（Standard と Express）¶

Standard ワークフロー: 長期実行（最大 1 年）、ステップごとの履歴保存、複雑なロジックに最適。
Express ワークフロー: 短時間・高スループットのイベント処理用、コスト最適化しやすく、ログは CloudWatch Logs に出力。

2.3 サービス統合¶

Step Functions は

Lambda
SNS
SQS
DynamoDB
ECS
Glue
Athena
SageMaker

など、多くの AWS サービスとネイティブに統合。
「サービス統合パターン」を通じてタスクステート内で AWS サービス API を直接呼び出せるため、追加のコード不要で複雑なワークフローが実現可能。

2.4 エラー処理とリトライ、キャッチ¶

各タスクでエラーが発生した場合、リトライポリシーを定義し、特定のエラー時に再試行回数・待機時間を設定可能。
Catch ハンドラーで失敗時のフォールバックシナリオ（異なるステートへの遷移）を定義でき、堅牢なエラー処理が実現できる。

2.5 データパス操作と入力・出力加工¶

パス(Path)、入力変換(InputPath, OutputPath, ResultPath)を用いて、ステート間で渡すデータを柔軟にフィルタリング・変換可能。
不要なデータを削除、JSON 構造の一部を抽出、結果を組み合わせるなど、複雑なデータ操作が定義ファイルのみで実現できる。

3. アーキテクチャおよび技術要素¶

デベロッパーが Amazon States Language（ASL）で JSON 定義を記述し、状態機械を作成。
状態機械は Standard または Express ワークフローのいずれかを選択。
タスクステートで AWS サービスを統合し、条件や並列処理を定義。
実行開始後、Step Functions は定義通りにワークフローをオーケストレーション。
実行履歴やメトリクスはマネジメントコンソールや CloudWatch で確認可能。

4. セキュリティと認証・認可¶

IAM ロール: Step Functions はワークフローから呼び出すサービスへのアクセスを IAM ロールで制御。必要な最小権限を付与するベストプラクティスが推奨。
VPC 統合: VPC 内リソースにアクセスする場合は、VPC エンドポイントや特定の Task 実行環境でプライベートアクセス可能。
暗号化: 入出力データを含めて CloudWatch Logs へ出力する場合、ロググループの KMS 暗号化でデータ保護可能。

5. 料金形態¶

Step Functions の料金は主に実行数とステート遷移数に基づく。

Standard ワークフロー: ステート遷移数に応じて課金。実行履歴の保持も含まれる。
Express ワークフロー: 実行回数と処理期間、リソース使用時間に基づく低コストモデル。
IAM・KMS などの追加コスト: KMS 等の利用に伴うコストが別途発生。

6. よくあるアーキテクチャ・設計パターン¶

マイクロサービスオーケストレーション: 複数 Lambda や ECS タスクを条件分岐やエラーリトライ付きで接続。
データ処理パイプライン: S3→Glue→Athena→SNS といった一連の処理を Step Functions で自動化。
ML ワークフロー: SageMaker ジョブの開始、完了待ち、結果処理を可視化・制御。
複雑なビジネスロジック: エラー時の代替フロー、分岐条件、並列処理を定義し、再利用可能なビジネスロジックを確立。

7. 設定・デプロイ手順（ハンズオン例）¶

Step Functions コンソールで「State Machine を作成」を選択。
ASL(JSON)で状態定義を記述、またはワークフロービルダーで可視的に定義。
IAM ロールを指定し、タスクで呼び出すサービスへのアクセス権を付与。
ワークフロー開始(Execute)後、実行履歴やグラフィカルな表示で進行状況を確認。
必要に応じて Express ワークフローで高スループットイベント処理、Standard で長期実行タスクをサポート。

8. 試験で問われやすいポイント¶

8.1 Standard vs Express ワークフロー¶

Standard は長期実行と詳細履歴、Express は短時間・高スループット重視。

8.2 ステートタイプ（Task、Choice、Parallel、Map、Wait など）¶

各ステートの役割と使いどころ、データパス操作方法。

8.3 エラー処理とリトライ、キャッチ¶

エラー時の再試行戦略とフォールバックステート設定。

8.4 サービス統合パターン¶

直接 API 呼び出し（.sync, .waitForTaskToken パターンなど）で AWS サービスをオーケストレーション。

8.5 セキュリティと IAM ロール¶

Step Functions がタスクで使用するサービスにアクセスするためのロール設定。

8.6 料金モデル理解¶

Standard はステート遷移数、Express は実行回数と実行時間。

8.7 データパス操作と入力・出力フィルタ¶

InputPath, OutputPath, ResultPath でデータ加工。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: 長期間実行され、各ステップの履歴を詳細に保持するワークフロータイプは何？
A: Standard ワークフロー。
Q: タスクステートでエラーが発生した場合、特定のエラーで再試行する方法は？
A: タスク定義内の"Retry"フィールドでエラー名、最大試行回数、待機時間などを定義している。
Q: 並列に複数のブランチを同時実行するにはどのステートを使うか？
A: Parallel ステートを使用。
Q: Step Functions で Lambda を呼び出す際、コード変更なしに API 直接呼び出しを行う仕組みを何と呼ぶか？
A: サービス統合パターン(AWS SDK 統合)と呼ぶ。
Q: データから特定のフィールドのみを取り出して次ステートに渡すにはどうするか？
A: InputPath や OutputPath で JSON から必要なフィールドを抽出する。