Cloud Service
Amazon Simple Workflow Service (SWF)
長時間にわたる業務フローを、状態をAWS側で保持しながらワーカーに振り分けて確実に進める、SWFはタスク調整に特化した古参のワークフロー基盤。新規はStep Functionsが基本。
- 1.決定者とワーカーにタスクを振り分け長時間処理の状態を保持する。
- 2.実行履歴がAWS側に残り進行状況と失敗箇所を後から追える。
- 3.新規設計はStep Functionsが推奨でSWFは既存資産の保守が中心。
解決する課題
- 数時間から数日にわたる長時間の業務フローの進行状態を、自前のDBやコードで管理すると複雑になる
- 複数の処理ステップ(人手の作業や外部システム連携を含む)を確実に順序立てて進めたい
- 処理を担うワーカーが分散・多数でも、どのタスクを誰が実行中かを取りこぼさず調整したい
- 失敗や遅延が起きたとき、どこまで進んだかを後から追跡できるようにしたい
主要概念と用語
- ワークフロー: 一連のタスクの流れ全体の定義。1回の実行をワークフロー実行と呼ぶ
- ドメイン: ワークフローやタスクをまとめる論理的なくくり(名前空間)
- アクティビティタスク: 実際の処理単位。これを担うプログラムをアクティビティワーカーと呼ぶ
- デシジョンタスク: 次に何をするかを判断する単位。これを担うのがデサイダー(決定者)
- タスクリスト: ワーカーがタスクを受け取るためのキューのような仕組み
- 実行履歴: 各実行で発生したイベントの記録。SWFが保持し進行状況を表す
仕様・制限・クォータ
- ワークフロー実行は最長で年単位の長期間にわたって保持・継続できる設計
- ワーカーはロングポーリングでタスクを取得する。状態管理はSWF側が担い、ワーカーはステートレスに保てる
- 実行履歴のイベント数や、保持できる実行数などには上限(クォータ)がある
- SWF自体はワークフローの実行ロジックを保持しない。判断はデサイダーのコードが行う点が大きな特徴
SWFは古参のサービスで、現在のAWSは新規のワークフロー用途にStep Functionsを推奨しています。SWFは主に既存資産の保守対象と捉え、新規はStep Functionsを基本に検討するのが安全です。
内部の仕組み
SWFは状態の保持役として振る舞います。ワークフロー実行が始まると、SWFは進行に応じてデシジョンタスクをタスクリストに置き、デサイダーがそれをポーリングで受け取ります。デサイダーは実行履歴を見て「次に何をすべきか」を判断し、その決定(例えばアクティビティの開始やワークフローの完了)をSWFへ返します。すると今度はアクティビティタスクがタスクリストに置かれ、アクティビティワーカーが受け取って実処理を行い、結果を返します。SWFはこれらのイベントをすべて実行履歴に記録し、ワーカーやデサイダーが落ちても状態を失いません。処理ロジックはあくまでワーカー側のコードに置かれ、SWFはタスクの配布と状態の保持に徹します。
状態はSWF側が実行履歴として保持するため、ワーカーやデサイダー自身は状態を持たずに作れます。プロセスが再起動してもポーリングを再開すれば続きから処理を進められます。
設計パターン / ベストプラクティス
- 決定と実行の分離: 判断ロジックはデサイダー、実処理はアクティビティワーカーに分け、責務を明確にする
- 冪等なアクティビティ: タスクが再実行されても結果が壊れないよう、処理は冪等に設計する
- タスクリストで負荷分散: 同じタスクリストを複数ワーカーがポーリングし、水平にスケールさせる
- タイムアウトの設定: タスクやワークフローに適切なタイムアウトを設け、ハングを検知・回復できるようにする
- 新規はStep Functionsを検討: 宣言的な定義と可視化が要るなら、まずStep Functionsで設計し直せないか検討する
運用・監視
- 各ワークフロー実行の進行状況と実行履歴をコンソールやAPIで確認し、どこで止まったかを追う
- CloudWatchメトリクスで実行数・失敗数・タスクの滞留状況を監視する
- タスクが処理されず滞留する場合は、対応するワーカーが起動・ポーリングしているかをまず疑う
- タイムアウトが頻発するなら、設定値とワーカーの処理時間・台数を見直す
コスト
- 主にワークフロー実行数と、保持されるタスク・実行履歴などのリソースに応じた課金が基本
- 長期間保持される実行が積み上がると費用に効くため、完了した実行は適切にクローズする
- 大量・短時間のイベント処理が主目的なら、課金体系の異なる他サービスのほうが適することがある
セキュリティ
- IAMでドメインやワークフローへのアクセス、ワーカーが呼べるAPIを最小権限に絞る
- ドメイン単位で対象を分離し、環境やチームごとに権限境界を引く
- 通信はTLSで保護される。タスクの入出力に機微なデータを含める場合は内容の取り扱いに注意する
- アクティビティの実処理がVPC内リソースを呼ぶ場合は、ワーカー側のネットワーク設定で制御する
関連サービス・比較
| 観点 | SWF | Step Functions |
|---|---|---|
| 定義方法 | ワーカーのコードで判断 | 状態機械を宣言的に定義 |
| 可視化 | 実行履歴を参照 | 実行をグラフで可視化 |
| 運用負荷 | デサイダーの自前実装が必要 | マネージドで運用が軽い |
| 位置づけ | 古参で保守中心 | 新規ワークフローの標準 |
ハンズオン / CLI例
# ドメインを登録する(ワークフローをまとめる名前空間)
aws swf register-domain \
--name OrderProcessing \
--workflow-execution-retention-period-in-days "30"
# 登録済みのドメイン一覧を確認する
aws swf list-domains --registration-status REGISTERED
# 指定ドメインで実行中のワークフローの件数を確認する
aws swf count-open-workflow-executions \
--domain OrderProcessing \
--start-time-filter '{"oldestDate": 1700000000}'
AWS Service
Amazon Simple Workflow Service (SWF)を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
アプリ統合
比較で見る軸
クラウド: AWS / カテゴリ: アプリ統合 / 難易度: intermediate
導入後に効く点
実行履歴がAWS側に残り進行状況と失敗箇所を後から追える。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- アプリ統合
- 難易度
- intermediate
- 関連資格
- SAA-C03 / DVA-C02
- 設計柱
- reliability / operational
判断チェックリスト
- 自社の用途が「アプリ統合 / reliability」に近いか確認する。
- 強みである「決定者とワーカーにタスクを振り分け長時間処理の状態を保持する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。