よくある質問

Q: 複数のタスクを連携させるという形でアプリケーションを設計することの利点は何ですか?Amazon SWF は、この点でどのように役立つのですか?
Amazon SWF では、タスクとはアプリケーション内の論理ステップの呼び出しを表すものです。タスクは「ワーカー」によって処理されます。ワーカーとは、Amazon SWF と相互作用してタスクを受け取り、タスクを処理して、その結果を返すプログラムです。1つのワーカーで、1つのアプリケーション処理ステップを実装します。ワーカーを開発するプログラミング言語はそれぞれ異なっていてもかまいません。また、既存のコンポーネントを再利用してワーカーを作成することも可能です。たとえば、クラウドサービス、エンタープライズアプリケーション、レガシーシステム、さらには単純なスクリプトをワーカーの実装に使用できます。多数のワーカーを、処理するタスクのタイプごとに独立して制御することによって、アプリケーションのスループットを効率的に制御できます。

複数のワーカーにまたがるアプリケーション実行をコーディネートするために、「ディサイダー」と呼ばれるプログラムを任意のプログラミング言語で作成します。このように、処理ステップとそのコーディネートとを分離することによって、アプリケーションが制御された状態で管理できるだけでなく、それぞれを別々にデプロイ、実行、スケーリング、および更新できるので、柔軟性が高まります。ワーカーとディサイダーは、クラウド (Amazon EC2 や Lambda など) にデプロイすることも、会社のファイアウォールの内側にあるマシンにデプロイすることもできます。ワーカーとディサイダーが分離されているので、ビジネスロジックの動的な変更も可能であり、アプリケーションを新しい要件に合わせてすばやく更新できるようになります。たとえば、特定のタスクを除去、スキップ、または再試行する、あるいは新しいアプリケーションフローを作成するには、ディサイダーを変更すればよいのです。

ワーカーとディサイダーを実装することによって、開発者は実際の処理ステップの実行とコーディネートに関連する、差別化が必要なアプリケーションロジックに専念できます。内部的な詳細処理、たとえばタスクを割り当て可能になるまで保管しておく、割り当てられたタスクを監視する、タスクの完了に関する情報を常時更新するといったことは、Amazon SWF によって行われます。Amazon SWF では、実行中の状況を各タスクのレベルで、API やコンソールを通して見ることも可能です。

Q: Amazon SWF を使用すると、どのようなことができるのですか?
Amazon SWF を使用すると、分散するコンポーネントからアプリケーションを構築するときに発生する課題の多くを解決することができます。Amazon SWF と、これに付随する AWS Flow Framework を使用すると、たとえば次のようなことが可能になります。

• 単純なプログラミングコンストラクトを使用して、アプリケーションを非同期プログラムとして作成する。このプログラミングコンストラクトは、リモートで実行するためのタスクを作成する、プログラムの実行時状態をトラッキングするといった、詳細な処理を抽象化するものです。
• アプリケーションの実行状態（どのステップが完了し、どのステップが実行中かなど）の情報を常時更新する。実行状態を保持するためのデータベース、カスタムシステム、アドホックソリューションなどを開発者が用意する必要はありません。
• アプリケーションコンポーネントと通信してコンポーネント間の作業の流れを管理する。Amazon SWF を使用すれば、メッセージングプロトコルを開発者が新たに設計する必要はなく、タスクの消失や重複の心配もありません。
• アプリケーション内のステップのコーディネートを中央集中化する。開発するコーディネートロジックは複数のコンポーネントに分散しているとは限りませんが、1つのプログラムにカプセル化することもできます。
• さまざまなプログラムとコンポーネント、たとえばレガシーシステムやサードパーティのクラウドサービスをアプリケーションに統合する。Amazon SWF ならば、アプリケーションのコンポーネントをどこに、どのような組み合わせでデプロイするかを柔軟に決定できるので、アプリケーションコンポーネントをプライベートのデータセンターからパブリックのクラウドインフラストラクチャに段階的に移行することも可能であり、アプリケーションの可用性やパフォーマンスが移行時に損なわれることはありません。
• 実行が長時間に及ぶ人的タスク（承認、レビュー、調査など）が含まれるワークフローを自動化する。Amazon SWF では、完了までに何日も、あるいは何か月もかかる処理ステップのステータスも確実にトラッキングされます。
• エンドユーザー向けにドメイン固有の言語をサポートするために、Amazon SWF の上にアプリケーションレイヤーを構築する。Amazon SWF では、プログラミング言語を柔軟に選択できるので、XPDL のような専門言語のインタープリタや、カスタマイズしたユーザーインターフェイス（モデリングツールなど）も容易に作成できます。
• 詳細な監査証跡が作成されるほか、アプリケーションの実行中インスタンスすべての可視化も可能です。また、開発するユーザーインターフェイスに Amazon SWF の可視化機能を取り入れるための API も用意されています。

実際に Amazon SWF を使用して構築されたアプリケーションの例としては、動画エンコーディング、ソーシャルコマース、インフラストラクチャのプロビジョニング、MapReduce のパイプライン、ビジネスプロセス管理など、さまざまなものがあります。使用事例の詳細については、SWF で解決できる使用事例をご覧ください。お客様が Amazon SWF を使用している方法については、ケーススタディをご覧ください。

Q: 自社開発ソリューションや既存のワークフロー製品ではなく Amazon SWF を使用するメリットは何ですか?
分散環境内でタスクをコーディネートするためのソリューションを構築するときは、さまざまな変動要素を考慮する必要があります。処理ステップを次に進めていくタスクは、完了までに長時間を要することもあり、時には異常終了やタイムアウトが発生したり、再起動が必要になったりすることがあります。タスク完了までのスループットやレイテンシー（遅延）も、多くの場合は一定ではありません。このような、あらゆる状況のタスクをトラッキングして可視化することは、難しいだけでなく、差別化不要の作業でもあります。アプリケーションやタスクをスケールアップしようとすると、分散システムの困難な問題が浮上します。たとえば、1つのタスクの割り当ては1回だけであることや、予期しない障害や停止が発生してもタスクの結果が確実にトラッキングされることの保証が必要です。Amazon SWF を使用すれば、開発者は差別化が必要なアプリケーションロジック、つまりタスクをどのように処理してどのように連携させるかということに専念できます。

既存のワークフロー製品の中には、専門言語の習得や高コストのデータベースのホスティングを必要とするものも多く、タスクの実行を開発者が制御できないものもあります。このような専門言語では、複雑なアプリケーションの表現が難しく、柔軟性に欠けるために変更の反映に時間がかかることもあります。対照的に、クラウドベースのサービスである Amazon SWF では、一般的なプログラミング言語を使用できるだけでなく、タスクをどこで処理するかを開発者が制御できます。分散アプリケーションに対して疎結合モデルが採用されているため、Amazon SWF では変更の反映もアジャイル（敏速）に行うことができます。

Q: ワーカーとディサイダーとは何ですか?
Amazon SWF では、1つのアプリケーションを実装するのに複数のワーカーと1つのディサイダーを作成します。これらは、Amazon SWF と直接通信します。ワーカーとは、Amazon SWF と相互作用してタスクを受け取り、そのタスクを処理して結果を返すプログラムです。ディサイダーとは、複数のタスクの連携を制御するプログラムです。具体的には、タスクの実行順序、同時実行、およびスケジューリングを、アプリケーションロジックに従って制御します。ワーカーとディサイダーは、Amazon EC2 のようなクラウドインフラストラクチャ上で実行することも、ファイアウォールの内側にあるマシンで実行することもできます。Amazon SWF は、ワーカーとディサイダーとの相互作用を仲介します。したがって、ディサイダーは、Amazon SWF を通してタスクの進行状況を常時知り、新しいタスクを順次作成することができます。同時に、Amazon SWF はタスクの保管、実行可能になったタスクのワーカーへの割り当て、およびタスクの進行状況の監視も行います。タスクの割り当てが1回だけで重複がないことの保証も、Amazon SWF が行います。Amazon SWF がアプリケーションの状態情報を常時保持しているので、ワーカーとディサイダーが実行状態をトラッキングする必要はありません。これらのプログラムは互いに独立して実行でき、スケーリングもすばやく行うことができます。Amazon SWF を使用してアプリケーションを構築するときのステップの詳細については、Amazon SWF 詳細ページの「機能」のセクションをご覧ください。

同じワークフローを Amazon SWF 上で、複数同時に実行することもできます。各実行を「ワークフロー実行」または「実行」と呼びます。実行を区別するために、一意の名前が付けられます。Amazon SWF マネジメントコンソール (または可視化 API) を使用すると、すべての実行の全体的な状況を見ることや、特定の実行をドリルダウンしてタスクレベルの詳細情報を見ることができます。

Q: アプリケーションのプログラミングに関して、Amazon SWF にはどのようなツールがありますか?
AWS の他のサービスと同様に、Amazon SWF にはウェブサービス API のためのコア SDK があります。さらに、Amazon SWF には AWS Flow Framework という SDK もあり、Amazon SWF ベースのアプリケーションを短時間で容易に開発することができます。AWS Flow Framework によってタスクレベルのコーディネートの詳細が抽象化され、親しみやすいプログラミングコンストラクトの形で利用できるようになっています。開発したプログラムを実行するときは、AWS Flow Framework によって Amazon SWF に対する呼び出しやプログラムの実行状況のトラッキング（Amazon SWF が保持している実行履歴を使用）が行われるほか、開発者が作成したコードの各部分を適切なタイミングで起動することも AWS Flow Framework によって行われます。Amazon SWF にアクセスするための直感的なプログラミングフレームワークである AWS Flow Framework を利用すると、アプリケーション全体を、1つのワークフローとして組織化された非同期相互作用の集合としてプログラミングすることができます。詳細については、「AWS Flow Framework とは何ですか?」をご覧ください。

Q: Amazon SWF と AWS Step Functions はどのように使い分ければよいですか?

AWS Step Functions は完全マネージド型のサービスで、視覚的ワークフローを使用して分散アプリケーションやマイクロサービスのコンポーネントを容易にコーディネートできます。ディサイダープログラムを記述する代わりに、JSON でステートマシンを定義します。 AWS のお客様は、新規アプリケーションには Step Functions を利用することを検討してください。Step Functions がニーズに適合しない場合は、Amazon Simple Workflow (SWF) を検討してください。 Amazon SWF では、連携ロジックを完全に制御することが可能ですが、アプリケーションの開発はより複雑になります。選択したプログラミング言語でディサイダープログラムを記述することも、Flow Framework を使用して、自動的に非同期の相互作用を構造化するプログラミングコンストラクトを利用することもできます。AWS では、引き続き Amazon SWF サービス、Flow framework、および Amazon SWF のすべてのお客様へのサポートを提供してまいります。

Q: Amazon SWF と Amazon SQS の違いは何ですか?

Amazon SQS と Amazon SWF はどちらも、アプリケーションやマイクロサービスの統合を容易にするサービスです。

• Amazon Simple Queue Service (Amazon SQS) では、メッセージがアプリケーション間またはマイクロサービス間を移動するときにメッセージを格納するため、信頼性が高く非常にスケーラブルなホスト型キューが提供されます。Amazon SQS では、分散アプリケーションのコンポーネント間でデータを移動することができ、これらのコンポーネントを分離する場合に役立ちます。
• Amazon Simple Workflow Service (Amazon SWF) は、分散アプリケーションの複数コンポーネントにわたって作業の連携をしやすくするウェブサービスです。

Amazon SQS と Amazon SWF の主な違いは以下のとおりです。

• Amazon SWF の API 動作はタスク指向です。Amazon SQS の API 動作はメッセージ指向です。
• Amazon SWF では、アプリケーション内のすべてのタスクとイベントのトラッキングが行われます。Amazon SQS では、アプリケーションレベルのトラッキングを独自に実装する必要があります。特に、アプリケーションで複数のキューを使用する場合です。
• Amazon SWF Console と可視化 API によって、アプリケーションを中心としたビューが提供され、そこで、実行の検索、実行の詳細情報へのドリルダウン、および実行の管理を行うことができます。Amazon SQS では、そのような追加の機能を実装する必要があります。
• Amazon SWF には、タスク間のデータ受け渡し、シグナリング、柔軟なタスク分散など、アプリケーション開発に役立つ機能が多数用意されています。Amazon SQS では、一部のアプリケーションレベルの機能を実装する必要があります。
• サービスの API を呼び出すコア SDK に加えて、Amazon SWF には AWS Flow Framework があり、分散アプリケーションのプログラミングが容易になります。このフレームワークでは、プログラミングコンストラクトを使用して非同期相互作用を組織化します。

分散アプリケーションの調整のための基本的なワークフローを Amazon SQS を使用して構築することもできますが、Amazon SWF では、このような機能を初期状態で使えるように設定されており、アプリケーションレベルのその他の機能も追加されています。

Amazon SQS と Amazon SWF のどちらのソリューションがお客様のニーズに最も適しているか、両方を試してみるようお勧めします。

Q: Amazon SWF で解決できるユースケースには、どのようなものがありますか? 

Amazon SWF が実際に使用されているユースケースとしては、メディア処理、ビジネスプロセス自動化、データ分析、クラウドへの移行、およびバッチ処理があります。例を次に示します。

ユースケース #1: Amazon S3 と Amazon EC2 を使用して動画をエンコーディングする。このユースケースでは、サイズの大きな動画を、ある程度のまとまり（チャンク）に分けて Amazon S3 にアップロードします。このチャンクのアップロードを監視する必要があります。チャンクが1つアップロードされたら、そのチャンクをエンコードするために Amazon EC2 インスタンスの1つにダウンロードします。エンコードされたチャンクは、別の Amazon S3 ロケーションに保管します。このようにしてすべてのチャンクがエンコードされたら、チャンクを結合して1つのエンコード済みファイルを作成し、そのまま Amazon S3 に保管します。チャンクの1つで発生したエンコードエラーが原因で、このプロセスが異常終了することもあります。このような異常終了を検出して対処する必要があります。

Amazon SWF を使用する場合: アプリケーション全体を1つのワークフローとして構築し、各動画ファイルを1つのワークフロー実行として扱います。ワーカーによって処理されるタスクは、「1つのチャンクを Amazon S3 にアップロード」、「1つのチャンクを Amazon S3 から Amazon EC2 インスタンスにダウンロードしてエンコード」、「1つのチャンクを Amazon S3 に戻して保管」、「複数のチャンクを結合して1つのファイルを作成」、および「完成したファイルを Amazon S3 にアップロード」です。このユースケースでは並行処理が可能であるため、ディサイダーは複数のタスクを並行して開始します。アップロードされたチャンクの1つをエンコードするためのタスクを開始するときに、他のチャンクのアップロードが完了するのを待つ必要はありません。あるチャンクを処理するタスクが異常終了したときも、ディサイダーはそのチャンクのみを再実行します。Amazon SWF が保持するアプリケーション状態情報は、ディサイダーによるワークフローの制御に利用できます。ディサイダーは、この情報を使用すると、すべてのチャンクのエンコードが完了したことを検出する、結合するチャンクそれぞれの Amazon S3 ロケーションを抽出するといったことが可能になります。実行の進行状況はいつでも、Amazon SWF Management Console で見ることができます。タスクが異常終了したときは、そのタスクの ID に基づいて失敗したチャンクを特定します。

ユースケース#2: サイズの大きい製品カタログを Amazon Mechanical Turk を使用して処理する。大規模カタログのデータを検証するときに、カタログ内の製品をバッチに分けて処理します。複数のバッチを同時に処理することができます。バッチごとに、製品データをデータセンター内のサーバーから抽出して CSV（カンマ区切り形式）ファイルに変換します。これは、Amazon Mechanical Turk の RUI（Requester User Interface）で要求されている形式です。この CSV をアップロードすると、そのデータを入力として HIT（Human Intelligence Task）が実行されます。HIT が完了したら、生成された CSV を逆変換してデータを元の形式に戻します。この結果を評価し、結果が合格ならば Amazon Mechanical Turk の作業者に報酬が支払われます。HIT の結果が不合格の場合は取り除いて再処理しますが、合格の場合はその結果を使用してカタログを更新します。バッチが処理されるときに、システムは Amazon Mechanical Turk 作業者の質をトラッキングして、報酬をそれに応じて調整する必要があります。不合格の HIT は再びバッチにまとめられて、もう一度パイプラインに送られます。

Amazon SWF を使用する場合: 上記のユースケースは、複数のワークフローのセットとして実装されます。BatchProcess というワークフローによって1つのバッチを処理します。このワークフローでは、ワーカーはデータを抽出し、変換して、Amazon Mechanical Turk を通して送信します。BatchProcess ワークフローの出力は、合格の HIT と不合格の HIT です。これは、他の3つのワークフロー（MTurkManager、UpdateCatalogWorkflow、RerunProducts）の入力として使用されます。MTurkManager ワークフローは、合格 HIT に対する支払いを行うほか、不合格 HIT を担当した作業者への通知や、結果の質を記録するデータベースの更新を行います。UpdateCatalogWorkflow は、合格 HIT に基づいてマスターカタログを更新します。RerunProducts ワークフローは、HIT が不合格となった製品が所定の数に達するまで待機します。その数に達したら、これらの製品を1つのバッチとして BatchProcess ワークフローに送り返します。このカタログ処理全体を実行するのが CleanupCatalog ワークフローです。このワークフローによって、上記のワークフローが子実行として開始されます。明確に定義されたワークフローを組織化することによって、このユースケースの設計と監査が可能になり、製品数が数百万というカタログに対しても一貫した方法で実行することができます。

ユースケース#3: コンポーネントをデータセンターからクラウドに移行する。ビジネスに欠かせないオペレーションがプライベートのデータセンターでホスティングされていますが、全体をクラウドに移行する必要があります。ただし、サービスの中断が発生してはなりません。

Amazon SWF を使用する場合: Amazon SWF ベースのアプリケーションでは、データセンターで実行されるコンポーネントをラッピングするワーカーと、クラウド内で実行されるワーカーとを組み合わせることができます。データセンターワーカーをシームレスに移行するには、同じタイプの新しいワーカーを最初にクラウド内にデプロイします。データセンター内のワーカーは引き続き通常どおり稼働し、並行して新しいクラウドベースのワーカーも稼働します。クラウドベースのワーカーのテストと検証を行うために、作業負荷の一部をクラウドにルーティングします。このテストの期間中も、アプリケーションが中断されることはありません。データセンター内のワーカーは引き続き稼働しているからです。テストの結果が合格ならば、データセンター内のワーカーを段階的に停止し、クラウド内のワーカーをスケールアップして、最終的にすべてのワーカーをクラウドで実行します。このプロセスを、データセンター内の他のすべてのワーカーについても同様に実行すると、アプリケーションを完全にクラウドに移行できます。ビジネス上の理由で、特定の処理ステップを引き続きプライベートのデータセンターで実行する場合は、そのワーカーを引き続きプライベートデータセンターで実行しながらアプリケーションに参加させることが可能です。

Amazon SWF を使用して構築されたその他のアプリケーションやシステムの例については、導入事例をご覧ください。

Q: Amazon は Amazon SWF を自社のアプリケーションに使用していますか?
はい。Amazon 社内では、Amazon SWF がさまざまなプロジェクトに使用されており、1日当たり数百万ものワークフローが実行されています。主なユースケースとしては、Amazon.com や AWS のウェブサイトの背後にある主要ビジネスプロセスや、AWS のさまざまなウェブサービスと API の実装、経営上の意思決定のための MapReduce 分析、ユーザー向けコンテンツ（ウェブページ、動画、Kindle 書籍など）の管理があります。

Q: Amazon SWF の使用を開始するには、どうすればよいですか?
Amazon SWF にサインアップするには、Amazon SWF 詳細ページにアクセスして「今すぐ申し込む」ボタンをクリックしてください。アマゾン ウェブ サービスのアカウントをお持ちでない場合は、画面の表示に従って作成してください。サインアップが完了すると、サンプルのウォークスルーを AWS マネジメントコンソールで実行できるようになります。これは、単純なイメージ変換アプリケーションを Amazon SWF で実行するステップを案内するものです。また、AWS Flow Framework のサンプルをダウンロードすることもできます。これは、このサービスのさまざまな機能について学習するのに役立ちます。Amazon SWF を実際のアプリケーションで使用する方法については、Amazon SWF のドキュメントを参照してください。

Q: Amazon SWF の試用時に利用できるサンプルのワークフローはありますか?
はい。Amazon SWF を使用するのが初めての場合は、AWS マネジメントコンソールにあるサンプルのウォークスルーを試してみてください。このウォークスルーでは、ドメインとタイプの登録、ワークフローとディサイダーのデプロイ、およびワークフロー実行の開始の方法を紹介しています。このウォークスルーで使用されているワーカーとディサイダーのコードをダウンロードして、自分のインフラストラクチャで実行することや、このコードに修正を加えて独自のアプリケーションを作成することもできます。また、AWS Flow Framework のサンプルもダウンロード可能です。このサンプルでは、Amazon SWF を使用する方法を、分散データ処理、Cron ジョブ、アプリケーションスタックデプロイなどのさまざまなユースケースを通して紹介しています。付属のソースコードを読むと、Amazon SWF の機能について、および AWS Flow Framework を使用して分散アプリケーションを構築する方法について詳しく学習できます。

Q: SWF にアクセスするには、どのような方法がありますか?
SWF にアクセスするには、次の方法があります。

• AWS SDK（Java、Ruby、.NET、PHP）
• Java 用 AWS Flow Framework（Java 用 AWS SDK に付属）
• Amazon SWF ウェブサービス API
• AWS マネジメントコンソール
  

Q: 登録とは何ですか?
登録とは、ワークフローやアクティビティのタイプごとに1回だけ実行されるステップです。登録はプログラムから行うことも、Amazon SWF Management Console で行うこともできます。登録時に、アクティビティまたはワークフローのタイプごとに一意のタイプ ID を指定する必要があります。また、ワークフローの実行時に使用されるデフォルトの情報も指定します。たとえば、タイムアウト値や、タスク分散のパラメータです。

Q: ドメインとは何ですか?
SWF では、アプリケーションリソース用に定義される論理的コンテナを「ドメイン」と呼びます。ドメインは AWS アカウントレベルでのみ作成でき、入れ子にすることはできません。ドメインには、任意のユーザー定義名を付けることができます。個々のアプリケーションリソース、たとえばワークフロータイプ、アクティビティタイプ、実行は、それぞれ1つのドメインのみに属します。ワークフローやアクティビティのタイプを登録するときに、どのドメインに登録するかを指定します。実行を開始すると、その実行は自動的に、ワークフロータイプと同じドメイン内に作成されます。リソース識別子（タイプ ID、実行 ID など）が一意である範囲は、1 つのドメインです。つまり、同じ ID を別のドメインで再利用することができます。

Q: アプリケーションリソースが複数の環境やグルーピングに分散している場合は、どのようにして管理するのですか?
ドメインを使用してアプリケーションリソースをまとめると、管理が容易になり、リソースどうしが意図せず干渉することもなくなります。たとえば、開発、テスト、本番の3つの環境のそれぞれに対して別のドメインを作成し、各ドメインの中に該当するリソースを作成します。同じワークフロータイプを各ドメインに登録することもできますが、別のリソースとして各ドメイン内で扱われます。開発用ドメインで設定を変更したり、テスト用ドメインで実行を管理したりするときに、本番用ドメイン内の対応するリソースに影響が及ぶことはありません。

Q: Amazon SWF では、ディサイダーはどのようにしてワークフローをコーディネートするのですか?
ディサイダーは、特殊なタイプのワーカーと見なすことができます。ワーカーと同様に、ディサイダーは任意の言語でプログラミングでき、ディサイダーは Amazon SWF に問い合わせてタスクを受け取ります。ただし、ディサイダーが扱うのは「ディシジョンタスク」と呼ばれる特殊なタスクです。Amazon SWF がディシジョンタスクを発行するのは、ワークフロー実行に遷移（アクティビティタスクの完了やタイムアウトなど）が含まれているときです。ディシジョンタスクは、入力、出力、およびそれまでに開始されたアクティビティタスクの現在の状態に関する情報を保持しています。ディサイダーは、この情報を使用して次のステップ（たとえば新しいアクティビティタスク）を決定し、決定したステップを Amazon SWF に返します。Amazon SWF は、受け取った決定に従って新しいアクティビティタスクを開始し（該当する場合）、監視します。ディシジョンタスクへの応答を継続的に行うことによって、ディサイダーはアクティビティタスクの順序、タイミング、および同時実行を制御し、その結果としてアプリケーション内の処理ステップの実行が制御されます。SWF によって最初のディシジョンタスクが発行されるのは、実行の開始時です。それ以降は、Amazon SWF はディサイダーが下した決定に従って実行を進めていきます。実行が終了するのは、ディサイダーがその実行を完了させると決定したときです。

ディサイダーによる意思決定に役立てるために、SWF はその実行におけるすべてのタスクの詳細を継続的に記録しています。この記録は「履歴」と呼ばれ、各実行に固有です。新しい履歴が作成されるのは、新しい実行が開始したときです。この時点で、履歴に格納されているのは実行の入力データなどの初期情報です。それ以降は、ワーカーによってアクティビティタスクが処理されると、履歴に入力と出力のデータが反映され、最新の状態情報も記録されます。ディサイダーは、ディシジョンタスクを受け取ったときに、その実行の履歴を検査することができます。Amazon SWF によって、履歴にはディシジョンタスク発行時点での実行の状態が正確に反映されています。ディサイダーは、この履歴を使用することによって、この実行でそれまでに何が行われたかを判断して、次のステップを適切に決定することができます。

Q: ワーカーやディサイダーが理解できるタスクのみを受け取るようにするには、どうすればよいですか?
タスクをどのように割り当てるかを、タスクリストを使用して決定します。タスクリストは Amazon SWF のリソースであり、タスクが開始されるとこのリストに追加され、このリストにあるタスクがリクエストされます。タスクリストには、ユーザー定義名が付けられます。1つのタスクリストに含まれるタスクのタイプ ID がすべて同じでなくてもかまいませんが、すべてのタスクがアクティビティタスクであるか、すべてがディシジョンタスクであることが必要です。アクティビティまたはワークフローのタイプを登録するときに、そのタイプのデフォルトのタスクリストを指定します。タスクリストは、実行時に作成することもできます。タスクリストを作成するのに必要な作業は、名前の指定だけです。タスクリストは、次のように使用されます。

• アクティビティタスクを作成するときに、ディサイダーがそのタスクを特定のタスクリストに追加するか、アクティビティタイプのデフォルトのタスクリストに追加します。
• 実行を開始するときに、すべてのディシジョンタスクを特定のタスクリストに追加するか、ワークフロータイプのデフォルトのタスクリストに追加します。
• タスクをリクエストするときに、ディサイダーとワーカーはどのタスクリストからタスクを受け取るかを指定します。そのリストにタスクがある場合は、応答としてそのタスクがタイプ ID とともに送信されます。

開発者は、上記の内容に基づいて、タスクをどのタスクリストに追加するか、および各リストに対してどのプログラムがタスクをリクエストするかを制御します。このようにすると、ワーカーとディサイダーはそれぞれが理解できるタスクだけを受け取るようになります。

Q: AWS Flow Framework とは何ですか?これは、ワークフローのコーディネートにどのように役立つのですか?
AWS Flow Framework とは、Amazon SWF ベースのアプリケーションを短期間で容易に開発するためのプログラミングフレームワークです。このフレームワークでは、タスクレベルのコーディネートと非同期相互作用の詳細が抽象化されて、単純なプログラミングコンストラクトの形で利用できるようになっています。Amazon SWF でワークフローをコーディネートするには、リモートアクションを作成して開始する必要がありますが、このアクションは完了までの時間がそれぞれ異なります（たとえばアクティビティタスク）。また、アクション間の従属関係を正しく実装する必要があります。

AWS Flow Framework を利用すると、コーディネートにおけるこの2つの面を、慣れ親しんだプログラミング概念を使用して手軽に表現することができます。たとえば、アクティビティタスクを作成する処理は、メソッドを1つ呼び出すだけの簡単さです。この呼び出しは AWS Flow Framework によって自動的に、アクティビティタスクを作成するというディシジョンに変換され、Amazon SWF がこのタスクをワーカーに割り当てて、監視し、完了時に報告を返します。このタスクの結果（出力データなど）は、コードの中で利用できるように、メソッド呼び出しの戻り値として返されます。タスクに対する従属関係を表現するには、一般的なメソッド呼び出しのときと同様に、この戻り値をコードの中で使用します。AWS Flow Framework のランタイムは自動的に、タスクが完了するまで待機し、結果が利用可能な状態になって初めて実行を再開します。内部的には、AWS Flow Framework のランタイムがワーカーやディシジョンのタスクを Amazon SWF から受け取って、開発者のプログラムの中の該当するメソッドを適切なタイミングで呼び出し、ディシジョンを組み立てて Amazon SWF に返します。Amazon SWF にアクセスするための直感的なプログラミングフレームワークである AWS Flow Framework を利用すれば、非同期イベントドリブンプログラミングを取り入れたアプリケーション開発が容易になります。

Q: Amazon SWF では、ワーカーとディサイダーはどのようにして通信するのですか?ポーリングプロトコルはリソースを多用しませんか?
一般的なポーリングベースのプロトコルの場合は、開発者が最適なポーリング頻度を見つける必要があります。ポーリング頻度が高すぎると、ポーリングの結果が空である回数が増える可能性があります。その結果、アプリケーションとネットワークのリソースを大量にポーリングに使用していながら、実行を先に進めるうえで意味のある成果が得られないという状況になってしまいます。ポーリングの頻度が低すぎる場合は、メッセージを保持する時間が長くなり、アプリケーション遅延が増加するおそれがあります。

ポーリングに内在する非効率性を解消するために、Amazon SWF ではロングポーリングが採用されています。ロングポーリングを使用すると、ポーリングの結果としてタスクが何も返されない回数が大幅に減少します。ワーカーやディサイダーがタスクを求めて Amazon SWF に対するポーリングを行うときに、タスクが何もない場合は接続が1分間維持されます。この時間が経過する前にタスクが受け取り可能になった場合は、そのタスクがこのロングポーリングリクエストへの応答として返されます。接続が一定の時間維持されるので、その時間が経過するまでは、結果が空であるポーリングが何度も実行されることはなくなります。ロングポーリングならば、プッシュベースのウェブサービスの持つ遅延と効率の面でのメリットを犠牲にすることなく、ポーリングの持つセキュリティとフロー制御の面でのメリットをアプリケーションに活用することができます。

Q: 既存のウェブサービスをワーカーとして使うことはできますか?
ワーカーは、タスクを Amazon SWF から受け取るときと結果を返すときに、標準の HTTP GET リクエストを使用します。既存のウェブサービスをワーカーとして使用するには、ラッパーを作成し、このラッパーでタスクを Amazon SWF から受け取って、ウェブサービスの API を必要に応じて起動し、結果を Amazon SWF に返します。このラッパーの中で、タスクとともに渡された入力データをウェブサービスの API のパラメータに変換してください。同様に、ウェブサービス API からの出力データも、タスクに応じた形式に変換して Amazon SWF に返してください。

Q: Amazon SWF で使用できる言語に関して制限はありますか?
いいえ。ワーカーやディサイダーをプログラミングする言語はどれでもかまいません。ただし、ウェブサービス API を使用して Amazon SWF と通信できることが条件です。AWS SDK は、現時点では Java、.NET、PHP、および Ruby のものがあります。Java 用 AWS SDK には、AWS Flow Framework が含まれています。

Q: ビジネスプロセスのアクティベーション 1 回につき実行が 1 回のみであることが必要です (トランザクション、提出、割り当てなど)。どのようにすればこれを実現できますか?
新しいワークフロー実行を開始するときに、そのワークフロー実行に ID を付与してください。これで、実行を特定のビジネスエンティティやアクション（顧客 ID、ファイル名、シリアル番号など）に関連付けることができます。実行が終了するまでの間はその実行の ID が一意であることは、Amazon SWF によって保証されます。実行が続いている間は、同じ ID を使用して別の実行を開始しようとしても失敗します。このことを利用すると、1つのビジネスアクション（トランザクション、提出、割り当てなど）に対して2つ以上の実行の稼働を許可しないというビジネス上のニーズを満たすことができます。例として、あるウェブサイトの新規ユーザーを登録するワークフローを考えてみます。[送信] ボタンがクリックされたら、そのユーザーの一意のEメールアドレスを使用してその実行に名前を付けます。その実行が既に存在する場合は、その実行を開始するための呼び出しは失敗します。登録処理の進行中にユーザーがこのボタンを2回以上クリックすることもありますが、その場合の競合を防ぐための追加コードは必要ありません。

このワークフロー実行が完了した後は（正常終了か異常終了かにかかわらず）、同じ ID の別のワークフロー実行を開始することができます。このときに、ワークフロー実行は同じ実行 ID で開始されますが、稼働 ID は別のものになります。この稼働 ID は Amazon SWF によって生成されるものであり、同じワークフロー実行 ID の実行が複数ある場合も、稼働 ID で区別できます。Amazon SWF では、このようにワークフロー実行 ID を再利用できるようになっているので、再試行のようなユースケースにも対応可能です。たとえば、上記のユーザー登録の例で、ワークフロー実行がそのユーザーのデータベースレコードを作成する時点で異常終了したとします。このワークフロー実行をもう一度開始するときは、同じ実行 ID（ユーザーのEメールアドレス）を使用できるので、登録再試行のための新しい ID を作成する必要はありません。

Q: Amazon SWF は、アプリケーションのスケーリングにどう役立つのですか?
アプリケーションのスケーリングに関して、Amazon SWF では、アクティビティタイプ別の実行ワーカー数や、ディサイダー1つ当たりの実行インスタンス数を開発者が指定することができます。ワーカーやディサイダーインスタンスの数を増やすと、対応する処理ステップに割り当てられるコンピュートリソースの量を増やすことになり、したがってそのステップのスループットが向上します。自動スケーリングを行う場合は、Amazon SWF から API 経由で提供される実行時データを使用できます。Amazon SWF からのデータの例としては、タスクリスト内のタスクの数があります。この数値が増加しているときは、ワーカーがその作業負荷を処理しきれないおそれがあるため、処理待ちタスクの数がしきい値を超えたら自動的に新しいワーカーを追加するように設定するとよいでしょう。

Q: 多数のミッションクリティカルなアプリケーションを実行しています。これらのアプリケーションをモニタリングし、スケールするには、どのようにすればよいでしょうか?
Management Console に加えて、Amazon SWF には包括的な機能を備えた可視化 API が付属しています。この API を使用して取得した実行時情報に基づいて、すべての実行を監視することや、負荷に応じた実行の自動スケーリングを行うことができます。ワークフロータイプ別に取得できる詳細データとしては、指定した時間範囲内のオープンおよびクローズ済みの実行の数などがあります。この可視化 API を使用して、独自の監視アプリケーションを作成することもできます。

Q: 常時多数の実行が稼働していますが、そのいくつかがたびたび異常終了あるいは停止します。このような問題のある実行を検出してトラブルシューティングするには、どうすればよいですか?
Amazon SWF では、Management Console や可視化 API を使用して実行を検索できるようになっています。さまざまな検索条件を指定できます。たとえば、実行が開始または完了した時間帯や、現在の状態（オープンまたはクローズ済み）、標準的な異常終了モード（タイムアウト、強制終了）があります。複数のワークフロー実行をグループ化するために、タグを5つまで使用できます。このタグを使用して、ワークフロー実行を開始するときに独自のテキストをその実行に関連付けます。AWS Management Console では、このタグをワークフロー実行の検索に使用できます。

停止している可能性のある実行を見つけるには、時間を条件として検索し、開始からの時間が予定よりも長い実行を抽出します。次に、抽出した実行のそれぞれについて、タスクレベルの詳細情報を調べて、開始からの時間が長すぎるか異常終了したタスクがあるかどうかや、単にまだディサイダーがタスクを作成していないのかどうかを特定します。このようにすると、タスクレベルの問題を特定することができます。

Q: 当社には、複数のアプリケーションで使用可能なアクティビティタイプがあります。このアクティビティタイプを複数アプリケーション間で共有することは可能ですか?
はい。複数のアプリケーションで同じアクティビティタイプを共有できます（アプリケーションとそのアクティビティがすべて同じドメイン内に登録されていることが条件）。このことを実装するには、さまざまなディサイダーがそのアクティビティタイプのタスクを作成するときに、同じタスクリストにそのタスクを追加します。そのアクティビティを担当するワーカーは、このタスクリストに対してポーリングを行います。これで、そのアクティビティタイプのワーカーは、さまざまなアプリケーションからのすべてのアクティビティタスクを受け取ることができます。あるアクティビティタスクがどのアプリケーションからのものかがわかるようにしたい場合や、アプリケーションごとに異なるワーカーをデプロイしたい場合は、複数のタスクリストを使用してください。「ワーカーやディサイダーが理解できるタスクだけを受け取るようにするには、どうすればよいですか?」を参照してください。

Q: AWS Identity and Access Management (IAM) を Amazon SWF へのアクセスの管理に使用できますか?
はい。管理者は、IAM ユーザーに Amazon SWF へのアクセス許可を与えることができます。IAM ユーザーは、管理者が指定した SWF ドメインと API にのみアクセス可能です。

Q: ワーカーをファイアウォールの内側で実行することは可能ですか?
はい。ワーカーが Amazon SWF にタスクの有無を問い合わせるときや処理結果を返すときは、標準の HTTP GET リクエストが使用されます。Amazon SWF へのリクエストは必ずワーカー側から行われるので、インバウンドのリクエストを許可するようにファイアウォールを設定する必要はありません。

Q: 自社のビジネスロジックをワーカーやディサイダーとして公開することについて、セキュリティリスクはありませんか?
ワーカーが Amazon SWF にタスクの有無を問い合わせるときや処理結果を返すときは、標準の HTTP GET リクエストが使用されます。したがって、ワーカーのためのエンドポイントを公開する必要はありません。さらに、Amazon SWF からワーカーにタスクが渡されるのは、ディサイダーによってそのタスクが作成されたときだけです。ディサイダーは開発者がプログラミングするので、タスクをいつどのように作成するかは、タスクとともにワーカーに送信される入力データも併せて、開発者が完全に制御できます。

Q: Amazon SWF は、アプリケーション内のタスクを確実にコーディネートする点でどのように役立つのですか?
Amazon SWF には、タスク割り当てを保証する機能があります。タスクが重複することはなく、1つのタスクが割り当てられるのは1回だけです。したがって、あるアクティビティタイプに対して複数のワーカーがある場合（あるいは同じディサイダーのインスタンスが多数ある場合）でも、Amazon SWF から同じタスクが2つ以上のワーカー（または2つ以上のディサイダーインスタンス）に渡されることはありません。さらに、Amazon SWF では、未処理のディシジョンタスクは1つのワークフロー実行に対して一時点で最大1つであることが保証されます。したがって、複数のディサイダーインスタンスを稼働させるときでも、同じワークフロー実行に対して2つのインスタンスが同時に作用することはありません。これらの機能を利用すれば、ワークフローをコーディネートするときにタスクの重複、消失、競合などについて心配する必要はなくなります。

Q: Amazon SWF に登録できるワークフロータイプ、アクティビティタイプ、およびドメインの数はどれくらいですか?
各ドメイン内のワークフロータイプとアクティビティタイプの数は合計10,000までです（登録済みと廃止予定の両方）。AWS アカウント内に作成できる Amazon SWF ドメインは最大100個です（登録済みと廃止予定のドメインを含む）。制限を超えると考えられる場合は、このフォームから Amazon SWF チームにご連絡ください。お客様の状況の説明を記入し、制限の引き上げをリクエストしてください。

Q: 同時に稼働できるワークフロー実行の数に制限はありますか?
一度に稼働できるオープンな実行の数は、1 ドメインにつき最大 100,000 となります。稼働した実行の累積数や Amazon SWF によって保持される実行の数については、制限はありません。制限を超えると考えられる場合は、このフォームから Amazon SWF チームにご連絡ください。お客様の状況の説明を記入のうえ、制限の引き上げをリクエストしてください。

Q: ワークフロー実行が継続する時間の長さに制限はありますか?
1つのワークフロー実行を継続できるのは最大1年間です。ワークフロー実行履歴1つあたりのイベント数は25,000までとなっています。Amazon SWF には、ユースケースの要件がこれらの制限を超える場合でも実行を継続するための機能があり、子ワークフロー実行を使用してアプリケーションを構成することができます。

Q: ワークフロー実行のアイドル状態が長時間続くとどうなりますか?
Amazon SWF では、ワークフロー実行が長時間アイドル状態になっていても、特別なアクションが取られることはありません。アイドル状態の実行に対しては、お客様が設定したタイムアウトが適用されます。たとえば、1つの実行を継続できる時間を最大1日と設定した場合は、アイドル状態の実行はこの1日という制限を超えたときにタイムアウトとなります。アイドル状態の実行に対しては、1つの実行を継続できる時間に関する Amazon SWF の制限（1年間）も適用されます。

Q: ワーカーが 1 つのタスクの処理に費やせる時間の長さはどれくらいですか?
Amazon SWF では、ワーカーが1つのタスクを処理する時間の長さについて、特に制限はありません。お客様が指定したアクティビティタスク継続時間の最大値に基づいてタイムアウトが適用されます。なお、Amazon SWF では、1つの実行が継続できるのは最大1年間となっており、ワーカーが1つのタスクを処理する時間の長さがこれを超えてはなりません。

Q: まだワーカーからリクエストされていないタスクを Amazon SWF が保持する時間の長さはどれくらいですか?
Amazon SWF では、まだワーカーからポーリングされていないタスクを保持する時間の長さについて、特に制限はありません。ただし、アクティビティタイプを登録するときに、デフォルトのタイムアウトを設定できるようになっています。これは、Amazon SWF がそのタイプのアクティビティタスクを保持する時間の長さです。ディサイダーのコードの中で、アクティビティタスクをスケジューリングするときに、デフォルトよりも優先されるタイムアウトを指定することもできます。Amazon SWF では、1つのワークフロー実行が継続できる時間は最大1年間に制限されているため、タイムアウト値が指定されていない場合は、タスクが保持されるのは最大1年間となります。

Q: 1 回のディシジョン発行で複数のアクティビティタスクをスケジューリングすることは可能ですか?
はい。最大 100 個のアクティビティタスクを 1 つのディシジョンでスケジューリングできます。また、複数のディシジョンを 1 つずつ順に発行することも可能です。

Q: 使用できるワーカータスク、シグナル、およびマーカーの数は、ワークフロー実行 1 つあたりと全実行とでそれぞれどれくらいですか?
1つのワークフロー実行で使用されるアクティビティタスク、シグナル、およびタイマーの総数に関して、制限はありません。ただし、現時点では、ワークフロー実行あたりのオープンなアクティビティタスクの数は最大1,000個となっています。これには、作成済みのアクティビティタスクと、ワーカーによる処理中のアクティビティタスクが含まれます。同様に、オープンなタイマーの数はワークフロー実行当たり最大1,000個、オープンな子実行の数はワークフロー実行当たり最大1,000個です。

Q: 1 つのワークフロー実行の中で転送できるデータの量はどれくらいですか?
1つのワークフロー実行の中で転送されるデータの総量に関して、制限はありません。ただし、Amazon SWF の API では、1つの実行の中でデータの受け渡しに使用されるパラメータについて上限が定められています。例えば、アクティビティタスクに渡される入力データ、およびシグナル付きで送信される入力データの大きさはそれぞれ 32,000 文字までとなります。

Q: Amazon SWF では、完了した実行は保持されますか? 保持される場合の長さはどれくらいですか?

Amazon SWF では、完了した実行の履歴はお客様が指定した日数が経過するまで保持されます。指定できる長さは最大90日（約3か月間）です。保持されている間は、履歴にアクセスでき、実行の検索をプログラムから、またはコンソールから行うことができます。

Q: API 呼び出しがスロットリングされるのはどのようなときですか?
低頻度のスパイクに留まらず、ごく短期間に非常に多数の API 呼び出しが行われると、スロットリングが発生することがあります。スロットリングが頻繁に行われる、あるいはアプリケーションの実行中に頻繁にスパイクが発生する場合は、このフォームから Amazon SWF チームにご連絡ください。お客様のご利用状況の説明をご記入のうえ、お客様のアカウントのスロットリング設定変更をリクエストしてください。

Q: Amazon SWF を使用できるのはどのリージョンですか?
Amazon SWF（SWF）は、米国東部（バージニア北部）、米国西部（オレゴン）、米国西部（北カリフォルニア）、欧州（アイルランド）、欧州（フランクフルト）、アジアパシフィック（シンガポール）、アジアパシフィック（東京）、アジアパシフィック（シドニー）、南米（サンパウロ）、および AWS GovCloud（米国）の各リージョンで利用できます。

Q: Amazon SWF は複数のアベイラビリティーゾーンにまたがって使用できますか？
はい。Amazon SWF は、ワークフロー実行履歴などのワークフローに関する詳細情報を 3 つのアベイラビリティーゾーンにわたって管理するので、アベイラビリティーゾーンの 1 つで障害が発生しても、アプリケーションは引き続き Amazon SWF を使用できます。

Q: Amazon SWF サービスアクセスポイントとは何ですか?
アクセスエンドポイントの詳細については、AWS 全般のリファレンスのドキュメントをご参照ください。

Q: 料金は税込み価格ですか?

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちらをご覧ください。