TL

Cloud Service

Amazon Simple Workflow Service (SWF)

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

中級SAA-C03DVA-C02信頼性運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 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内リソースを呼ぶ場合は、ワーカー側のネットワーク設定で制御する

関連サービス・比較

観点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側に残り進行状況と失敗箇所を後から追える。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
アプリ統合
難易度
intermediate
関連資格
SAA-C03 / DVA-C02
設計柱
reliability / operational

判断チェックリスト

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

次に確認する観点

アプリ統合reliabilityoperationalSAA-C03DVA-C02