クラウドサービス

Amazon Simple Workflow Service (SWF)

長時間にわたる業務フローを、状態をAWS側で保持しながらワーカーに振り分けて確実に進める、SWFはタスク調整に特化した古参のワークフロー基盤。新規はStep Functionsが基本。

中級SAA-C03DVA-C02信頼性運用上の優秀性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. 履歴を保持し、決定者と処理ワーカーを調停する。
  2. 処理コードと調整コードを利用側で動かす。
  3. 既存資産との互換性がなければ Step Functions を先に検討する。

解決する課題

  • 数時間から数日にわたる長時間の業務フローの進行状態を、自前のDBやコードで管理すると複雑になる
  • 複数の処理ステップ(人手の作業や外部システム連携を含む)を確実に順序立てて進めたい
  • 処理を担うワーカーが分散・多数でも、どのタスクを誰が実行中かを取りこぼさず調整したい
  • 失敗や遅延が起きたとき、どこまで進んだかを後から追跡できるようにしたい

主要概念と用語

  • ワークフロー: 一連のタスクの流れ全体の定義。1回の実行をワークフロー実行と呼ぶ
  • ドメイン: ワークフローやタスクをまとめる論理的なくくり(名前空間)
  • アクティビティタスク: 実際の処理単位。これを担うプログラムをアクティビティワーカーと呼ぶ
  • デシジョンタスク: 次に何をするかを判断する単位。これを担うのがデサイダー(決定者)
  • タスクリスト: ワーカーがタスクを受け取るためのキューのような仕組み
  • 実行履歴: 各実行で発生したイベントの記録。SWFが保持し進行状況を表す

仕様・制限・クォータ

  • ワークフロー実行は最長 1 年、履歴は最大 25,000 イベント。どちらも引き上げ不可
  • ワーカーはロングポーリングでタスクを取得する。状態管理はSWF側が担い、ワーカーはステートレスに保てる
  • 1 ドメインの実行中ワークフローは既定 100,000、タスクリストの同時ポーラーは最大 1,000
  • 入出力とシグナルは 32,768 文字、API要求全体は 1 MB が上限
  • SWF自体はワークフローの実行ロジックを保持しない。判断はデサイダーのコードが行う点が大きな特徴
新規設計での位置づけ

SWF は現在も利用できますが、決定者とワーカーの常駐運用が必要です。既存 SWF 資産との互換性が不要なら、宣言的で可視化された Step Functions を先に評価します。

内部の仕組み

横にスクロール

SWFが実行履歴から決定タスクを作り、利用側のデサイダーが次の処理を返し、アクティビティワーカーが実処理と心拍を返す循環経路と、タイムアウト、再割り当て、重複副作用、履歴上限、責任境界を示す図
SWF は履歴とタスク調停を担います。決定者・ワーカーの稼働と副作用の冪等性は利用側の責任です。

SWFは状態の保持役として振る舞います。ワークフロー実行が始まると、SWFは進行に応じてデシジョンタスクをタスクリストに置き、デサイダーがそれをポーリングで受け取ります。デサイダーは実行履歴を見て「次に何をすべきか」を判断し、その決定(例えばアクティビティの開始やワークフローの完了)をSWFへ返します。すると今度はアクティビティタスクがタスクリストに置かれ、アクティビティワーカーが受け取って実処理を行い、結果を返します。SWFはこれらのイベントをすべて実行履歴に記録し、ワーカーやデサイダーが落ちても状態を失いません。処理ロジックはあくまでワーカー側のコードに置かれ、SWFはタスクの配布と状態の保持に徹します。

一つのワークフロー実行で同時に開く決定タスクは一つだけです。一方、アクティビティが外部へ副作用を出した後、完了応答の前にタイムアウトすると、決定者が同じ業務処理を再度予定し得ます。長時間処理は心拍を送り、業務IDによる条件付き更新で副作用を冪等にします。履歴が増える処理は ContinueAsNew で新しい実行へ継ぎます。

ワーカーはステートレスに

状態はSWF側が実行履歴として保持するため、ワーカーやデサイダー自身は状態を持たずに作れます。プロセスが再起動してもポーリングを再開すれば続きから処理を進められます。

設計パターン / ベストプラクティス

  • 決定と実行の分離: 判断ロジックはデサイダー、実処理はアクティビティワーカーに分け、責務を明確にする
  • 冪等なアクティビティ: タスクが再実行されても結果が壊れないよう、処理は冪等に設計する
  • タスクリストで負荷分散: 同じタスクリストを複数ワーカーがポーリングし、水平にスケールさせる
  • タイムアウトの設定: タスクやワークフローに適切なタイムアウトを設け、ハングを検知・回復できるようにする
  • 新規はStep Functionsを検討: 宣言的な定義と可視化が要るなら、まずStep Functionsで設計し直せないか検討する

運用・監視

  • 各ワークフロー実行の進行状況と実行履歴をコンソールやAPIで確認し、どこで止まったかを追う
  • CloudWatchメトリクスで実行数・失敗数・タスクの滞留状況を監視する
  • タスクが処理されず滞留する場合は、対応するワーカーが起動・ポーリングしているかをまず疑う
  • タイムアウトが頻発するなら、設定値とワーカーの処理時間・台数を見直す

コスト

  • 開始したワークフロー実行、タスク・タイマー・シグナル・マーカー、実行中または保持中の日数で課金される
  • 長期間保持される実行が積み上がると費用に効くため、完了した実行は適切にクローズする
  • 大量・短時間のイベント処理が主目的なら、課金体系の異なる他サービスのほうが適することがある

セキュリティ

  • IAMでドメインやワークフローへのアクセス、ワーカーが呼べるAPIを最小権限に絞る
  • ドメイン単位で対象を分離し、環境やチームごとに権限境界を引く
  • 通信はTLSで保護される。タスクの入出力に機微なデータを含める場合は内容の取り扱いに注意する
  • アクティビティの実処理がVPC内リソースを呼ぶ場合は、ワーカー側のネットワーク設定で制御する

関連サービス・比較

観点SWFStep 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
カテゴリ
アプリ統合
難易度
intermediate
関連資格
SAA-C03 / DVA-C02
設計柱
reliability / operational

判断チェックリスト

  • 自社の用途が「アプリ統合 / reliability」に近いか確認する。
  • 強みである「履歴を保持し、決定者と処理ワーカーを調停する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合reliabilityoperationalSAA-C03DVA-C02