Amazon MQ とワークフロー管理(Step Functions / SWF)
業界標準プロトコルに対応したAmazon MQの特徴と、Step FunctionsおよびSWFによるワークフロー管理サービスの違い・使い分けを整理します。
Amazon MQ:業界標準プロトコル対応のメッセージブローカー
Amazon MQは、業界標準のAPIやプロトコルを利用してメッセージブローカーを利用できる、マネージド型サービスです。Apache ActiveMQおよびRabbitMQのエンジンタイプをサポートしており、次のようなプロトコルに対応しています。
- JMS(Java Message Service)
- AMQP 0-9-1 / AMQP 1.0
- MQTT
- OpenWire
- STOMP
SQSやSNSがAWS独自のAPIを持つのに対し、Amazon MQはこれらの業界標準プロトコルをそのままサポートする点が最大の特徴です。そのため、オンプレミス環境で稼働中のActiveMQやRabbitMQベースのアプリケーションを、コードの変更を最小限に抑えたままAWSへ移行したい場合に適しています。すでにSQSやSNSでシステムを新規構築できる場合は、まずAWSネイティブなSQS/SNSの利用を検討し、既存プロトコルへの依存が強い場合にAmazon MQを検討するという判断が基本になります。
Amazon MQの高可用性構成では、アクティブ/スタンバイのブローカーを異なる2つのアベイラビリティーゾーンに配置し、冗長ペアとして構成します。また、Amazon EFSと同期的に通信することで、メッセージデータの永続化を実現しています。
ワークフロー管理サービスの必要性
複数のAWSサービスや処理ステップを順序立てて実行し、途中の分岐・並列処理・リトライ・エラーハンドリングを管理したい場合、個々のLambda関数やアプリケーションコード内でその制御ロジックを実装すると、コードが複雑になりがちです。AWSは、こうしたワークフローの定義・実行・可視化を専用に扱うサービスとして、AWS Step FunctionsとAmazon Simple Workflow(SWF)を提供しています。
AWS Step Functions
Step Functionsは、AWS Lambda関数やAWSの複数のサービスをビジネスプロセスとして配列できる、サーバーレスのワークフロー作成・管理サービスです。
ワークフローは、Amazon States Language(ASL)というJSON形式の言語でステートマシンとして定義します。定義したステートマシンは、コンソール上でビジュアルなフローとして表示され、各ステップの実行状況を確認できます。
例えば、並行して2つの処理を実行し、両方が完了してから次のステップに進むワークフローは、次のように定義できます。
{
"Comment": "2つの処理を並行実行し、完了後に次のステートへ進む例",
"StartAt": "ParallelTasks",
"States": {
"ParallelTasks": {
"Type": "Parallel",
"Next": "NotifyCompletion",
"Branches": [
{
"StartAt": "ResizeImage",
"States": {
"ResizeImage": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"End": true
}
}
},
{
"StartAt": "ExtractMetadata",
"States": {
"ExtractMetadata": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"End": true
}
}
}
]
},
"NotifyCompletion": {
"Type": "Task",
"Resource": "arn:aws:states:::sns:publish",
"End": true
}
}
}
このステートマシンの実行フローを図にすると、次のようになります。
Step Functionsと連携できるサービス
Step Functionsは、Amazon States Languageから直接次のようなサービスを呼び出し、その結果に基づいて処理を分岐させることができます。
- AWS Lambda関数の呼び出し
- AWS Batchジョブの実行と、結果に基づく後続処理
- Amazon DynamoDBへの項目挿入・取得
- Amazon ECSタスクの実行と完了待機
- Amazon SNSへのトピック発行
- Amazon SQSへのメッセージ送信
- AWS GlueやAmazon SageMakerのジョブ管理
- 別のStep Functionsワークフローの起動
逆に、Step Functions自体は次のようなサービスから呼び出すことができます。
- AWS Lambda
- Amazon API Gateway
- Amazon EventBridge
- AWS CodePipeline
- AWS IoTルールエンジン
- 別のAWS Step Functions
なお、標準でサポートされていないサービスについては、アクティビティ機能を使ってカスタムに設定することも可能です。
Step Functionsには、実行時間や特性の異なる2種類のワークフロータイプがあります。
- Standardワークフロー:最大1年間の長時間実行に対応し、実行履歴を確認できます。注文処理や承認フローなど、実行頻度が比較的低く、確実な実行履歴の追跡が必要な処理に向いています。
- Expressワークフロー:短時間・高スループットの実行に最適化されています。IoTデータの処理やストリーミングデータの変換など、大量のイベントを高頻度で処理する用途に向いています。
Amazon Simple Workflow(SWF)
SWFは、Step Functionsの前身にあたるワークフロー管理サービスで、並行または連続したステップを持つバックグラウンドジョブを構築・実行・スケールするために使われます。
SWFのワークフローでは、「ディサイダー」と呼ばれるプログラムが決定ロジックを担い、実際の処理を行う「アクティビティワーカー」とステップを分離して構成します。ワーカーアプリケーションはEC2インスタンスやオンプレミスサーバー上で実行され、AWS Flow Frameworkを利用してJavaやRubyのコードで構築・実行します。
例えば、通知メールに送信ジョブを流すシステムの受注処理フローを考えると、注文確認・決済処理・配送処理・完了記録といった各ステップを、それぞれ異なるワーカー(サーバーや人手によるオペレーション)に分散して実行させることができます。
Step Functions と SWF の使い分け
現在は、SWFでのみサポートされる一部の特殊な処理を除けば、新規のアプリケーションではAWS Step Functionsの利用が推奨されています。
| 項目 | Step Functions | SWF |
|---|---|---|
| 定義方法 | JSON形式のステートマシンで記述 | ディサイダープログラムで決定ロジックを記述 |
| 実行基盤 | Step Functions上でサーバーレスに実行 | ワーカーはEC2やオンプレミスサーバー上で実行 |
| 開発言語 | 特定言語に依存しない | Java/Ruby(AWS Flow Framework)に依存 |
| 可視化 | ビジュアルなワークフロー表示が標準 | 別途可視化の仕組みが必要 |
| 推奨度 | 新規アプリケーションで推奨 | 特殊なユースケースでのみ利用を検討 |
SWFの利用が適するのは、ワークフローの途中で外部からの介入信号を受け取る必要がある場合や、あるプロセスが完了した結果を呼び出し元の親プロセスへ返す必要がある場合など、Step Functionsの標準的なモデルでは表現しづらい、より複雑な制御が求められるケースに限られます。それ以外のワークフローは、実装のシンプルさと可視化のしやすさから、Step Functionsを選択するのが基本方針です。
重要ポイント
- ▸Amazon MQはJMS/AMQP/MQTT/STOMPなど業界標準プロトコルに対応したマネージド型メッセージブローカー
- ▸オンプレミスのActiveMQ/RabbitMQ環境をAWSへ移行する場合に適する
- ▸Step Functionsはステートマシンをビジュアルに定義できるサーバーレスのワークフローサービス
- ▸SWFはStep Functionsの前身にあたる旧世代のワークフローサービス
- ▸新規アプリケーションでは基本的にSWFよりStep Functionsが推奨される
このトピックの学習を完了しますか?
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
連携サービス に関連するトピックを続けて確認できます。