問題タブ [azure-storage-queues]

Azure.Storage.Queue を使用してキューからメッセージを取得する場合

可視性タイムアウトを設定できますが、Azure.WebJobs (SDK 0.4.0-beta) 属性を使用して Web ジョブをキューに自動バインドしようとすると、

すなわち

属性に表示タイムアウトを設定する方法はありますか? JobHostConfiguration().Queues にはオプションがないようです。オーバーライドする方法がない場合は、標準の 30 秒ですか?

編集: Azure のストレージ アカウントの "ユーザー" と "パスワード" はどこにありますか? （下記参照）。

私は単にpython3.4のpython sdkでキューを作成しようとしていますが、次のコードを使用しています:

私は得る：

問題は、単一のキューを持つ ubuntu VM の Linux 自動スケーリング ファームを作成しようとしているということです。このキューに x を超えるメッセージが含まれている場合、ファームはスケールアップし、1 つの VM を使用する代わりに、2 つまたは 3 つの VM を使用します。

既に VM があり、可用性セットと負荷分散を構成しましたが、キューで停止しています。

誰かが助けてくれたら、それは素晴らしいことです！

ありがとう

答え

ここでようやく答えが見つかりました Azure アカウント名とアカウント キーはどこにありますか?

私の本当の問題を指摘してくれたMSFTのJason Hoggに感謝します。

現在のプロセスは次のように実行されています。

1.) ユーザーが分析のためにフロントエンド アプリに URL を入力します。

2.) フロントエンドは URL を検証し、URL の属性を含むテーブルに URL のレコードを作成します。

3.) フロント エンドは、URL が処理のどの段階にあるかを追跡するテーブルの行を作成/更新します (各 URL には独自の内部 ID があります)。

3.A) ステータス コードが「queued」ステータスに更新される

---- テーブル定義:

4.) フロント エンドは、送信された URL の内部 ID を含むメッセージを Azure ストレージ キューに送信します。

最初のメッセージがキューに送信された後 ------------>

4.A) ユーザーがクリックする (データを「更新」する) ためのオブジェクトが UI に作成されます。

4.B) 作成されたオブジェクトをユーザーがクリックする (これが発生する可能性が高い) (検証された場合は即座に)

4.C) URL の ID を含む別のメッセージがキューに送信されます。

<--------------------------------

5.) 実行中の Azure Web ジョブ (バックグラウンド タスク) がこれらのメッセージを継続的に取得し、処理を開始します。

6.) Web ジョブは、この URL を処理する準備ができているかどうかを判断します

..... 次の場合、処理を開始する準備ができています

• 新規です (LastUpdated フィールドが null です)
• アイテムに付けられたステータス コードはエラーを表します
• LastUpdated から 15 分が経過しました

..... 次の場合に終了します

• メッセージ内の ID が無効です
• 添付されたステータス コードは、現在処理中であることを示しています。
• LastUpdated から 15 分未満が経過しています

続行しても問題ないと判断されたら...

• 新しい場合、Web ジョブは LastUpdated を Datetime.Now に更新します。
• プロセスの各ステップの開始時に、これを反映するためにステータス コードが更新されます。

• プロセスの最後に、LastUpdated が現在の時刻に更新されます。

• トライキャッチがプロセスを囲んでいます

a.) プロセスがエラーになった場合、それを反映するようにステータス コードが更新されます。

b.) 新しいメッセージが再試行のためにキューにプッシュされます

URL を解析する準備ができているかどうかを判断する関数:

キュー メッセージは、次の関数を介して入力されます。

...ここでの問題は、この継続的に実行されている webjob が一度に複数のメッセージを取得できることです (そして、これを、同じキューから読み取るさらにいくつかの webjobs にスケールアウトしたいと考えています)

関数 IsReadyToParse() が実際に現在の処理状態を反映していることを確認するにはどうすればよいですか?

データベースがステータス コードを「処理中」に更新しようとしているときに、別のスレッドがステータス コードを読み取って、プロセスを続行することを許可した場合はどうなるでしょうか。

かなりの数のレポートを生成する必要があり、レポートの生成には約 5 分かかり、大量のデータと多くの異なるソースがあります。

クライアントはメッセージを Azure ストレージ キューに投稿します。メッセージを処理してレポートを生成する worker ロールがあります。

これをスケールアップしたい場合は、キューからのメッセージを処理してレポートを生成する 10 個のワーカー ロールになるとします。次に、次のようにメッセージをキューに追加します。

• メッセージ 1: 1 から 5 までのレポートを処理します
• メッセージ 2: 6 ～ 11 のレポートを処理します .........
• メッセージ 10: 50 から 55 までのプロセス レポート (範囲が正確ではない可能性があります)

ワーカー ロール 1 が最初のメッセージを受け取り、そのメッセージにロックをかけるが、プロセスに 5 分かかる場合、ロックが期限切れになり、メッセージが再びキューに表示されるため、ワーカー ロール 2 がメッセージを受け取って処理を開始します。 ...など

タスクが長いタスクであることを念頭に置いて、キュー メッセージの消費が 1 回だけ行われることを回避するにはどうすればよいですか?

私の Azure Web ジョブ (コンソール アプリ) の機能は正しく機能しており、キューからメッセージを取得していますが、「時間表示」オプションを制御する方法、または取得されたメッセージをキューから削除する機能が必要です。 .

関数：

プログラムでキューにアクセスするとき、それはあなたが渡すパラメーターであることは知っています。しかし、私はその方法でキューにアクセスしていません。Webjobs アプリケーションで azure SDK を使用してこれを行う正しい方法は何ですか?

編集：

可視性オプションは、ジョブがキューからメッセージを取得してから、メッセージがキューに再び表示されるまでの時間です (プロセスがまだ終了しておらず、失敗したと見なされるため)。私の場合、デフォルトの 30 秒では、プロセスが最後まで実行されるのに十分な時間ではありません。

参照 (セクション: 方法: メッセージをデキューするための追加オプションを活用する): http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-queues/

QueueTrigger新しいメッセージがキューで利用可能になったときに呼び出されるものがあることを知っています。ただし、この「フレームワーク スタイル」の Web ジョブにより、環境を正しく初期化することが複雑になります。

これが、自分でキューをポーリングしたい理由です。基本的なパターンは次のとおりです。

私の質問は、WebJob で継続的に実行する場合、このアプローチに潜在的な問題はありますか? もしそうなら、「フレームワーク スタイル」の Web ジョブを回避するための可能な代替手段は何ですか?

編集

QueueTriggerビクターからのリクエストに応じて、このアプローチを使用したくない理由についての詳細を以下に示します。基本的に2つの理由があります。

1 つ目は既に上で述べたように、フレームワークがQueueTrigger属性を持つメソッドを呼び出すという事実です。これは、すべての初期化をそのメソッドに入れる必要があることを意味します。

Web アプリには 2 段階の IoC コンテナー (アプリケーションごとおよび要求ごと) があり、Web ジョブをできるだけ Web アプリに近づけたいので、その 2 段階の IoC を使用したいと考えています。 Web ジョブでも同様です (アプリケーションごとの IoC は、すべての要求で再利用される重い初期化を行います)。この結果、静的QueueTriggerメソッドからアクセスできるように、アプリケーションごとのコンテナーを静的変数またはシングルトンに配置する必要があります。これは、私が作りたくない設計上の癖です (IMO、Microsoft はこれをやりすぎています。たとえばThread.CurrentCulture、それHttpContext.Currentは本当にアンチパターンであり、テスト容易性を損ないます)。

上記の状況に最適な WebJobs SDK は、インフラストラクチャ (バックオフ タイマー、ポイズン処理など) をサービスとして利用できるようにし、メインの制御フローが常にアプリケーションに残るようにします。これは、SDK のすべての機能で可能である場合とそうでない場合があります。私はそれを判断するのに十分なほど SDK を知りません。

2 つ目の理由は、開発者の利便性です。オフライン環境で作業することもある分散型チームがあります。私がこことここで読んだことから、ストレージ エミュレーターを使用して WebJob アプリケーションをローカルで実行し、メッセージをデキューする可能性はありません。私が今取っている自己ポーリングのアプローチでは、これは魅力のように機能します。