ブロブSAS WCFとパフォーマンス

Question

このlinkはパフォーマンスについて語り、ポータルをバイパスします。私にとって、認証するWCFサービスはポータルに似ています。

軽量サービスは、クライアントを必要に応じて認証し、 は、SASを生成します。クライアントは、SASを受信すると、 ストレージアカウントリソースに、 SASで定義された権限とSASが許可する期間だけ直接アクセスできます。 SASは、 フロントエンドプロキシサービスを通じてすべてのデータをルーティングする必要性を軽減します。

アプリケーションは、Azure ADを使用してAzureアプリケーションでホストされているWFCサービスと通信する、厚い.NET WPFクライアントです。

これは文書管理アプリケーションであり、ファイル転送が大変です。検索と検索の結果は、比較的少量のトラフィックです。レスポンシブにするには検索が必要です。

SASをファイルのアップロードとダウンロードに使用するのは最適ですか？
もう1つの方法は、WCFサービス経由でファイルをアップロードしてダウンロードすることです。
どちらかといえば何が問題になるでしょうか？

私の考えは、WCFサービスからの応答を維持するためにファイルを保持したいと考えています。

これが別の質問であれば問題ありません。クライアントは、一度に検索結果1000を取得します。 SASの有効期限が長かったとしても、結果が何時間も残っていれば期限切れになる可能性があります。 SASがプロパティバインディングの場合、期限切れのSASを検出するにはどうすればよいですか？各ファイルには、アプリケーション内で固有のIDがあります。ゲットにSASをリクエストするほうが良いでしょうか？

ユーザーは、検索結果の情報に基づいて、検索結果のほとんどすべてのファイルにアクセスすることができます。彼らはいくつかの大きな検索を実行してカウントを取得し、ゼロのファイルにアクセスするかもしれません。

Answer 1

ファイルのアップロードとダウンロードにSASを使用するのは最適化されていませんか？

私はそうは思わない。 SASを使ってファイルをアップロード/ダウンロードすることは、私には分かります。

他のオプションは、WCF サービスを介してファイルをアップロードしてダウンロードすることです。どちらかのためにいくつかの落とし穴は何ですか？

SASベースのアプローチを使用する最大の利点は、データがWCFサービス経由でルーティングされることなくAzure Storageと直接対話していることです。したがって、サービスを軽量に保つことができ、スケーリングの目的であまりにも多くのインフラストラクチャを背後に置かないようにすることができます。 SASの場合、WCFサービスは単にBLOB上のSAS要求を取得し、クライアントアプリケーションがファイルのアップロードに使用できるBLOBのSAS URLを返します。

SASでは、懸念事項の1つは、SAS URLの共有と意図しないオーディエンスの手に渡る可能性があります。しかし、短期間のSASトークンを維持し、SAS上でIP ACLを適用することによって、この懸念を緩和することができます。

---

あまり情報は、アプリケーション（特に検索部）について、共有されているが、私は、ファイルに関する情報は、リレーショナル・データベースのいくつかの種類に保管されており、実際のファイルは、BLOBストレージに保管されていることを推測しています。私は、検索結果の一部としてSASトークンを生成することから離れ、必要に応じてそれらを生成するだけです。ユーザーがファイルをアップロードしようとすると、実際のアップロードプロセスの直前にアップロード用のSAS URLが取得されます。同様に、ユーザーがファイルをダウンロードしているときは、その時点でファイルのSAS URLが取得され、ダウンロードが実行されます。