2

Windows Azure でホストされる Web サービスを作成したいと考えています。クライアントは処理のためにファイルをアップロードし、クラウドはそれらのファイルを処理して結果のファイルを生成し、クライアントはそれらをダウンロードします。

HTTP リクエストの処理には Web ロールを使用し、実際の処理にはワーカー ロールを使用し、リクエストの追跡には Azure Queue や Azure Table Storage などを使用すると思います。ユーザーがアップロードしたファイルごとに 1 つの "要求" レコード - Azure テーブル ストレージであると仮定しましょう。

設計上の大きな問題は、1 つのファイルを処理するのに 1 秒から 10 時間かかることです。

ワーカー ロールが開始され、Azure テーブル ストレージにアクセスし、"処理準備完了" とマークされた要求を見つけ、"処理中" とマークされ、実際の処理を開始します。通常はファイルを処理し、リクエストを「処理済み」とマークしますが、予期せず停止した場合はどうなるでしょうか?

私がそれを処理しない限り、リクエストは永遠に「処理中」の状態のままになります。

「処理中」とマークされているが放棄されたリクエストを追跡するにはどうすればよいですか? Windows Azure のどのメカニズムが最も便利でしょうか?

4

4 に答える 4

4

あなたが抱えている主な問題は、キューが今日2時間を超える可視性タイムアウトを設定できないことです。したがって、アクティブな作業が進行中であることを示す別のメカニズムが必要です。ブロブリースをお勧めします。処理するファイルごとに、blob自体または0バイトのマーカーblobをリースします。ワーカーは利用可能なBLOBをスキャンし、それらをリースしようとします。彼らがリースを取得した場合、それはそれが処理されていないことを意味し、彼らは先に進んで処理します。彼らがリースに失敗した場合、別の労働者が積極的にそれに取り組んでいる必要があります。

ワーカーがファイルの処理を完了すると、ファイルをBLOBストレージ内の別のコンテナーにコピーする（または必要に応じて削除する）だけで、再度スキャンされることはありません。

キューメッセージを更新できるようになるまで、ここでの答えはリースだけです。

編集：ここでリースが機能する理由は、リースを30秒ごとにアクティブに維持する必要があるため、誰かが死亡したか、まだ作業中であるかを知ることができる非常に小さなウィンドウがあることを明確にする必要があります。

于 2011-05-20T13:37:34.590 に答える
2

説明する問題は、Azure Queuesで最も適切に処理されます。これは、AzureTableStorageではいかなる種類の管理メカニズムも提供されないためです。

Azure Queuesを使用して、キューのアイテムを取得するときのタイムアウトを設定します（デフォルト：30秒）。キューアイテムを読み取ると（たとえば、「プロセスファイルxがURL yのblobで待機しています」）、そのキューアイテムは指定された期間非表示になります。これは、他のワーカーロールインスタンスが同時にそれを取得しようとしないことを意味します。処理が完了したら、キューアイテムを削除するだけです。

今：あなたがほぼ完了し、キューアイテムをまだ削除していないとしましょう。突然、ロールインスタンスが予期せずクラッシュします（またはハードウェアに障害が発生したか、何らかの理由で再起動されました）。キューアイテム処理コードが停止しました。最終的に、最初にキューアイテムを読み取ってから時間が経過すると、設定したタイムアウト値に相当し、そのキューアイテムが再び表示されます。ワーカーロールインスタンスの1つが再びキューアイテムを読み取り、それを処理できます。

覚えておくべきいくつかのこと：

  • キューアイテムにはデキューカウントがあります。これに注意してください。特定のキューアイテムに対して特定の数のデキューに達したら（制限として3回使用するのが好きです）、オフライン評価のためにこのキューアイテムを「ポイズンキュー」またはテーブルストレージに移動する必要があります-何か問題がある可能性がありますメッセージまたはそのメッセージの処理に関するプロセス。
  • 処理がべき等であることを確認してください（たとえば、副作用なしに同じメッセージを複数回処理できます）
  • キューアイテムは非表示になり、後で表示に戻る可能性があるため、キューアイテムをFIFO順に処理する必要はありません。

編集：ライアンの答えによると、Azureキューメッセージは2時間のタイムアウトで最大になります。Service Busキューメッセージには、はるかに長いタイムアウトがあります。この機能は、数日前にCTPに移行しました。

于 2011-05-20T11:20:16.043 に答える
2

この問題は技術固有の問題ではないと思います。
処理ジョブは長時間実行されるため、これらのジョブは実行中に進行状況を報告することをお勧めします。このようにして、かなりの期間にわたって進行状況が報告されていないジョブは、クリーンアップの明確な候補となり、別のワーカー ロールで再開できます。
進捗を記録し、ジョブスワッピングを行う方法はあなた次第です。1 つの方法は、データベースを記録メカニズムとして使用し、ジョブ進行状況テーブルに ping を送信するエージェント ワーカー プロセスを作成することです。ワーカー プロセスが問題を特定した場合、是正措置を講じることができます。

他のアプローチは、worker ロール ID を長時間実行プロセスに関連付けることです。worker ロールは、ある種のハートビートを使用して健康状態を伝えることができます。
ジョブが長時間実行されていない場合は、ステータス フラグの代わりにジョブの開始時刻にフラグを立て、タイムアウト メカニズムを使用して処理が失敗したかどうかを判断できます。

于 2011-05-20T08:36:28.810 に答える
1

ロールの OnStop() はソリューションの一部である可能性がありますが、呼び出されない状況 (ハードウェア障害) があります。その場合に対処するには、OnStart() で同じ RoleInstanceID を持つすべてを放棄済みとしてマークします。これは、何かがまだ起こっている場合は呼び出されないためです。(幸運なことに、Azure がロール インスタンス ID を再利用していることがわかります。)

于 2011-05-20T07:57:22.557 に答える