Azure WebjobsとAzure Functions：選択方法

トリガーを使用するAzure Webジョブをいくつか作成し、Azure Functionsについて学習しました。

私が理解しているところから、Azure関数はAzure Webjobsの機能と重複しているようであり、FunctionとWebjobのどちらを選択するかを理解するのが困難です。

• Webjobsとは異なり、関数はトリガーのみが可能で、継続的なプロセスを実行するようには設計されていません（ただし、継続的な関数を作成するコードを記述できます）。

• 多くの言語（C＃、node.js、pythonなど）を使用してWebジョブと関数を記述できますが、Azureポータルから関数を記述できるため、関数のテストとデプロイを簡単かつ迅速に開発できます。

• WebジョブはApp Service Webアプリ、APIアプリ、またはモバイルアプリのコンテキストでバックグラウンドプロセスとして実行されますが、関数はクラシック/動的Appサービスプランを使用して実行されます。

• スケーリングに関しては、動的アプリサービスプランを使用でき、単一の関数をスケーリングできるので、関数はより多くの可能性を提供するようですが、Webジョブの場合はWebアプリ全体をスケーリングする必要があります。

つまり、確かに価格の違いがあります。既存のWebアプリを実行している場合は、それを使用して追加費用なしでWebジョブを実行できますが、既存のWebアプリがなく、キューをトリガーするコードを記述する必要がある場合Webジョブまたは関数を使用する必要がありますか？

選択する必要があるときに留意すべき他の考慮事項はありますか？

App Serviceには、いくつかのオプションがあります。Logic AppsやAzure Automationについては触れません。これらもこの分野に関係しています。

Azure Webジョブ

この記事は正直に言って最良の説明ですが、ここで要約します。

オンデマンドWebジョブ（別名）。スケジュールされたWebジョブ（別名）。トリガーされたWebジョブ

トリガーされるWebジョブは、URLが呼び出されたとき、またはscheduleプロパティがschedule.jobに存在するときに1回実行されるWebジョブです。スケジュールされたWebジョブは、スケジュールに基づいてURLを呼び出すために作成されたAzureスケジューラジョブを持つWebジョブですが、前述のように、scheduleプロパティもサポートしています。

概要：

• + 実行可能/オンデマンドスクリプト
• + スケジュールされた実行
• - .scmエンドポイント経由でトリガーする必要があります
• - スケーリングは手動です
• - VMは常に必要です

継続的なWebジョブ（非SDK）

これらのジョブは永遠に実行され、クラッシュしたときに起こします。これらを機能させるには、Always Onを有効にする必要があります。つまり、基本層以上で実行する必要があります。

概要：

• + 実行可能ファイル/スクリプトは常に実行されています
• - 常時オンが必要-基本階層以上
• - VMは常に必要です

WebJobs SDKを使用した継続的なWebジョブ

これらは「機能のWebジョブ」の観点からは何もありません。基本的に、私たちが作成したこの甘いSDKは、単純なトリガーに基づいてコードを実行できるようにするWebジョブをターゲットにしています。これについては後で詳しく説明します。

概要：

• + 実行可能ファイル/スクリプトは常に実行されています
• + より豊富なロギング/ダッシュボード
• + 長時間実行タスクとともにサポートされるトリガー
• - 常時オンが必要-基本階層以上
• - スケーリングは手動で設定できます
• - 始めるのは少し面倒かもしれません
• - VMは常に必要です

Azure WebJobs SDK

Azure WebJobs SDKは、WebJobsプラットフォーム機能とは完全に別のSDKです。WebJobで実行するように設計されていますが、実際にはどこでも実行できます。サポートは最善の努力にすぎませんが、私たちには、Workerロールで、さらにはpremまたは他のクラウドでそれらを実行するお客様がいます。

SDKは、イベントに反応してコードを簡単に実行し、サービスなどにバインドすることを目的としています。簡単です。これは一部のドキュメントで正直に説明されていますが、その中心は「イベント」+「コード」の性質です。また、いくつかの優れた拡張性の作業も行いましたが、それは主要な目的の二次的なものです。

概要：

• これらのほとんどは上記のとおりです
• +何でも拡張して実行できます。フルコントロール。
• - HTTPのものは少し不安定ですが、動作します

Azure関数

Azure Functionsは、WebJobs SDKのコアな目的を取り入れ、それをサービスとしてホストし、他の言語で簡単に使い始めることを目的としています。ここでは「サーバーレス」の概念も紹介します。そうすることは非常に理にかなっているためです。SDKがどのようにスケーリングするかを理解しているため、インテリジェントなことができます。

Azure Functionsは、非常に厳密に管理されたエクスペリエンスです。私たちはあなた自身のホストをもたらすことをサポートしていません。現在、カスタム拡張機能はサポートしていませんが、現在調査中です。私たちはあなたができることとできないことについて意見を述べていますが、私たちが可能にすることについては、それらは洗練されており、使いやすく、管理が簡単です。

ただし、Functionsを改善するために行った "フレームワーク"作業のほとんどは、WebJobs SDKを経由します。たとえば、新しいNuGet for WebJobsをアップロードします。これにより、ログ記録の速度が大幅に向上します。これにより、WebJobs SDKユーザーにとってパフォーマンスに大きなメリットがあります。関数を「WebJobs SDK as a Service」として出荷する際に、私たちは実際に多くのエクスペリエンスの問題を改善しました。

• + 多くの言語がサポートされています
• + フルマネージドの動的スケーリング
• + 接続などを管理するUXを備えた使いやすいポータル。
• - ホストはカスタマイズできません（まだ）
• ~ 別の「アプリ」で実行されます。これは、リポジトリでの設定が必要ですが、長期的なメンテナンスがはるかに簡単になります。
• ~ いいえ、ツーリングない（まだ）いくつかのツールは、アルファまたはプレビューに今ある- https://www.npmjs.com/package/azurefunctions （更新2017年2月：プレビューで利用できるようになりましAzureの機能のためのVisual Studioツールのhttps：//blogs.msdn .microsoft.com / webdev / 2016/12/01 / visual-studio-tools-for-azure-functions /）

関数は私たちの最新かつ最高のものであるため、私はおそらく偏見がありますが、自分の方法で関数のより多くの短所を撮影してください。

私はおそらくもう少し詳細なブログを公開することになるでしょうが、私はこのフォーラムのためにこれをできるだけ簡潔に保つように努めました。

WebJobs SDKに基づくAzure Functionsであり、WebJobsで既に利用可能な機能のほとんどを提供しますが、いくつかの新しいクールな機能を備えています。

トリガーに関しては、Webジョブで既に利用可能なもの（サービスバス、ストレージキュー、ストレージBLOB、CRONスケジュール、WebHooks、EventHub、ファイルクラウドストレージプロバイダーなど）に加えて、Azure関数をAPIとしてトリガーできます。また、HTTP呼び出しにはkudu資格情報は必要ありませんが、Azure ADおよびサードパーティのIDプロバイダーを介して認証できます。

出力に関しては、関数がHTTP経由で呼び出されたときに関数が応答を返すことができるという唯一の違いがあります。

どちらも、bash（.sh）、バッチ（.bat / .cmd）、C＃、F＃、Node.Js、PHP、PowerShell、Pythonなど、さまざまな言語をサポートしています。

現在プレビューにある関数であるため、ツールはまだ理想的ではありません。しかし、マイクロソフトはそれに取り組んでいます。うまくいけば、現在Visual StudioでWebジョブを実行する場合と同じように、関数をローカルで開発およびテストするのと同じ柔軟性を得られます。

関数によってもたらされる最も重要で優れた利点は、「サーバーレス」モデルを備えた動的サービスプランを使用する代わりの方法です。このモデルでは、VMインスタンスやスケーリングを管理する必要がありません。すべて管理されています。さらに、専用のインスタンスがないことにより、実際に使用したリソースに対してのみ支払います。

ここでの2つの詳細な比較：https : //blog.kloud.com.au/2016/09/14/azure-functions-or-webjobs/

HTH :)

ドキュメントによると、Azure FunctionsにはWebJobsにはない次の機能があります。

• 自動スケーリング（CPUとメモリは実行時に決定されたニーズに従ってスケーリングされます）
• 従量制料金（App Serviceプランではなく消費プラン）
• その他のトリガーイベント（WebHooksなど）
• ブラウザー内での開発（Visual Studioは引き続き可能）
• F＃サポート

簡単に言うと、Azure Functionsは新しい動物です。App Serviceプランをまだお持ちでない場合は、長期的にはWebジョブで開始する方が良い理由がないため、関数を使用します（関数ツールはまだ安定していない可能性があります）。

上記の長くて少し古い投稿にもう2点追加したいと思います。Azure関数で消費プランを選択した場合、制限は次のとおりです

10分を超えるジョブを実行する場合は、webjobsを選択します。Azure関数は、デフォルトで5分間のみ実行されます。プロセスが5分を超えると、azure関数がタイムアウト例外をスローします。host.jsonでタイムアウトを10分に増やすことができます。

注：アプリサービスプランのazure関数を使用している場合は、タイムアウトの問題はありません。

区別するもう1つの理由は、azure関数を使用すると、マシン（コンテナー）がその場で作成され、使用すると破棄されるため、最初の開始時間が遅くなります。

コールドスタートを回避するため、azure関数アプリはプレミアムプランをリリースしました。このプランでは、1つのインスタンスが常に実行され、負荷に基づいて関数アプリがスケーリングを開始し、1つのインスタンスと他のインスタンスの使用量に基づいて請求されます。

私はこの答えでゲームに非常に遅れていることに気づきましたが、これはまだGoogleでトップの検索結果であるため、コストの観点から厳密にこのトピックについていくつかのガイダンスを提供したいと思いましたあるため、OPにはコストに関する懸念があるようですので。ここには、技術的な制限と各サービスの動作の詳細について説明する素晴らしい回答がすでにいくつかあるので、それらの回答を再ハッシュすることはしません。

「無料」で実行するものが絶対に必要な場合（既にWebアプリに対して支払ったものに追加費用がかからないなど）、次の2つのオプションがあります。

1. Webジョブ-既存のWebアプリと一緒にデプロイされ、Webアプリと同じリソースを使用します。ウェブジョブを使用するための追加の金銭的コストはありませんが、すでに述べたように、ウェブアプリのパフォーマンスコストにつながる可能性があるいくつかの制限があります。
2. 機能-消費プランを使用すると、一定量の無料実行が割り当てられます。この記事の執筆時点での数は実際には非常に多く、100万回の無料実行が行われています。ただし、100万の実行制限は、問題を引き起こす可能性のある制限ではありません。400K GB-s（ギガバイト秒）です。これは基本的に、関数が使用するメモリ量に、実行する秒数を掛けた計算です（こちらの料金ページの公式計算をご覧ください）。この無料の割り当てがすぐに使い果たされることに驚かれることでしょう。

コストを心配しているが、コストがまったくないという制限がない場合は、より多くのオプションを利用できます。

1. 機能-比較的安価な価格で、消費プランまたはアプリサービスプランのいずれかで実行できます。ただし、GB-s課金モデルを覚えておいてください。消費プランを使用していて、頻繁に「重い」作業を行っている場合、大きな請求書に驚かれるかもしれません。
2. クラウドサービス-主にOPがそれについて尋ねなかったため、このオプションは代替手段として説明されていません。しかし、これも実行可能なオプションです。クラウドサービスは、最終的にはクラウドで実行されるVMにすぎないため、必要なバックグラウンドジョブを実行でき、それらはかなりうまくスケールアップ/スケールダウンします（ただし、実行のために独自のトリガーを配線する必要がありますが、webjobs / functionsに比べて少し不便です） ）。使用するかどうかに関係なくインスタンスごとに支払うため、初期コストが高くなりますが、絶えず実行する必要のあるジョブがあり、多くの「重い」リフティングを行っている場合は、クラウドサービスの方が適している可能性があります。私の意見では、固定価格のVMを実行およびギガバイト秒よりも管理/監視する方が簡単だからです。

いくつかの特定のシナリオを読むことに興味があり、なぜ私が他のシナリオ（ウェブジョブ、関数、クラウドサービス）を選択するのかについて興味がある場合は、最近、ウェブジョブvs関数vsクラウドサービスに関するブログ投稿を書いたところです。

主な考慮事項は、Azure関数がv2.0で廃止されたバージョン1以降の完全な.NET Frameworkのサポートを終了し、現在プレビュー版のv3.0で変更されないことです。😔

• ドキュメンテーションはここでこれを明確にします、

• 行い、このフィードバック応答は、

• このgithubの問題/応答と同様に。

一方、この強力な武装アプローチは、Azure WebJobsにはありませんでしたが、まだ適用されていません。

WebJobs SDKのバージョン3.xは、.NET Coreアプリと.NET Frameworkコンソールアプリの両方をサポートしています。

AppServiceとWebJobs SDKの上に構築された2つのAzure関数の共通点と相違点を教えてください。WebJobs SDKは、Azureの機能がより構造化されており、開発者の責任が少ない一方で、より自由に操作できるようにします。

共通点を見ると、どちらも関数指向プログラミングモード、トリガー/入力/出力のバインディングを使用し、外部ライブラリをサポートしており、ローカルで実行およびデバッグできます。

違い

|-----------------------|------------------|
|      Functions        |     Web Jobs     |
|-----------------------|------------------|
|Can support HTTP       | Can't support HTTP
|                       |  requests        |
|-----------------------|------------------|
|Supports a variety of  | Traditional .NET |
|languages/tools        | developer        |
|                       | experience       |
|-----------------------|------------------|
|Bindings are configured| Config files are |
|using attributes       | used             |
|-----------------------|------------------|
|Scale is managed by    | Scale is managed |
|Azure                  | by user          |
|-----------------------|------------------|
|Limited control over   |Host can be       |
|host                   |controlled by user|
--------------------------------------------