StandardワークフローとExpressワークフローの違い
まずは以下の表にそれぞれの違いをまとめます。
項目 / カテゴリー | Standard Workflows | Express Workflows |
|---|---|---|
最大継続時間 | 1年 | 5分 |
実行開始レート | APIアクションのスロットリング制限を参照 2024年9月現在: バケットサイズ800-1300、リフィルレート150-300/s | APIアクションのスロットリング制限を参照 2024年9月現在: バケットサイズ6000、リフィルレート6000/s |
状態遷移レート | 状態スロットリング制限を参照 2024年9月現在: バケットサイズ800-5000、リフィルレート800-5000/s | 制限なし |
料金 | 状態遷移ごとに課金 | 実行回数、実行時間、メモリに基づいて課金 |
実行履歴 | API、コンソール、CloudWatch Logsを通じて表示・説明・デバッグ可能 | 5分以内の無制限履歴、コンソールとCloudWatch Logsでデバッグ |
実行の意味論 | 1回のみ正確に実行 | 非同期: 最低1回実行、同期: 最大1回実行 |
サービス統合 | すべての統合とパターンに対応 | すべての統合に対応（Job-run (.sync) や Callback (.waitForTaskToken) を除く） |
分散マップ | 対応 | 未対応 |
アクティビティ | 対応 | 未対応 |
Standardワークフローのポイント
- 長時間実行可能で耐久性があり、正確に一度だけ処理されることを保証。
- データの一貫性と信頼性が重要なアプリケーションに適する（例: 金融取引、予約システム、決済システム）。
- 長期間のプロセス（数時間～数ヶ月）にも対応可能。
- 大量のトラフィックに対してはレートリミットの上限に引っかかる可能性が高い
- 状態遷移ごとの課金であるため、大量遷移があるとコストが掛かる
Expressモードのポイント
- 高頻度かつ短期間の処理向けで、スピードとコスト効率を重視。
- 「少なくとも1回」の処理を保証し、重複実行が許容されるシナリオに最適。
- 高スケーラビリティ（1秒あたり数千件）を備え、IoTやリアルタイムデータ処理に適用可能。
選択のポイント
- データの正確性・一貫性が必要 → Standardモード
- 高スループットやリアルタイム性が必要 → Expressモード
- 冪等性の担保が難しい場合、Expressモードは不適切。
StandardワークフローとExpressワークフローを組み合わせる
全体的なオーケストレイターとしてStandardワークフローを配置して長時間の待機処理やコールバックなどの処理はここで担当します。そして、Expressワークフローを内部にネストして配置することで大量の状態遷移が発生するワークフローは実行時間とメモリ使用量に基づいて課金されるExpressワークフローに内包します。
例えば以下のようなユースケースではこのパターンを採用することが出来そうです。
- 全体で5分以上の実行時間が必要となる
- 大量の状態遷移が必要となる
- 全体として、高頻度で実行されるがStandardワークフローのレートリミットに収まる
- 重複処理が許容される（Expressワークフローは同じIDを持つステートマシンが複数実行される場合がある）
特に大量の状態遷移がある部分をExpressワークフローの中で処理させることでコストや処理速度の麺で最適な実装とすることができます。
まとめ
このようにワークフロー全体のプロセスを「遷移時間が多く短時間」なコンポーネントと「処理時間が長く待機時間が多い」コンポーネントに分けることが可能であれば、StandardワークフローとExpressワークフローを組み合わせることでコストや処理スピードの面で効率的なアーキテクチャを実装することが可能になるでしょう。そのままStandardワークフローのみで実装を行っていると思わぬコストが掛かってしまうこともあるサービスです。デザインパターンの一つとして覚えておいて是非活用してもらえると嬉しいです。