1

スケーラビリティのために Web アプリケーションを Windows Azure に移行することを検討していますが、アプリケーションをどのように分割するのが最善かを考えています。

私のシナリオは典型的なものであり、次のようになると思います。私のアプリケーションでは、ユーザーが生データをアップロードでき、これが処理され、レポートが生成されます。その後、ユーザーは生データを確認し、レポートを表示できます。

これまでのところ、私は web ロールと worker ロールを考えています。ただし、VHD は読み取り/書き込みアクセス権を持つ単一のインスタンスにマウントできることを理解しているため、Web ロールとワーカー ロールの両方が共通のファイル ストアにアクセスする必要があります。したがって、Web ロールと 2 つの別個のワーカー ロールが必要になる可能性があります。1 つは処理用、もう 1 つはファイル ストアの読み取りと書き込み用です。これは良いアプローチですか？

役割間の配管を想像するのが難しく、このパーティショニング間の通信によって引き起こされるオーバーヘッドが懸念されるため、ここでの入力を歓迎します。

4

2 に答える 2

2

Stuart の優れた回答に加えて、Blob は最大 200 GB のサイズで何でも保存できます。耐久性のあるディレクトリ構造全体を保持する必要がある場合、または保持したい場合は、わずか数行のコードで VHD をマウントできます。これは、他のドライブと同様に、アプリがやり取りできる NTFS ボリュームです。

あなたの場合、Web アプリは vhd をマウントし、それに対する唯一のライターになる必要があるため、vhd はうまく適合しません。また、複数の Web ロール インスタンスがある場合 (SLA が必要で、スケーリングが必要な場合)、ライターは 1 つしか持てません。この場合、個々のブロブははるかによく適合します。

Stuart が述べたように、これは非常に正常で一般的なパターンです。ここでも、わずか数行のコードで、ストレージ SDK を呼び出して、BLOB ストレージからインスタンスのローカル ディスクにファイルをコピーできます。その後、通常のファイル IO 操作を使用してファイルを処理できます。レポートが完成したら、さらに数行のコードを使用して、レポートを新しい BLOB にコピーできます (ほとんどの場合、Web ロールが参照する既知のコンテナー内)。

これをさらに一歩進めて、個々のアップロードされたファイルを識別する行キーと、完成したレポートへの URI を表す 3 番目のフィールドを使用して、顧客ごとにパーティション分割された Azure テーブルに行を挿入できます。これにより、Web アプリが顧客の完成したレポートを表示するのは簡単になります。

于 2011-03-20T20:00:28.667 に答える
1

BLOB ストレージは、多くのロールとロール インスタンスがアクセスできるファイルを格納する最も簡単な場所であり、特別なアクセスを必要とするものはありません。

提案されている通常のパターンは次のようです。

  • Web ロールのインスタンスを使用して raw ファイルをアップロードできるようにする
  • これらの Web ロール インスタンスは、処理を行わずに HTTP 呼び出しを返します。未加工のファイルを BLOB ストレージに保存し、「do this work メッセージ」をキューに追加します。
  • Worker ロール インスタンスは、キューからメッセージを取得し、未加工の BLOB を読み取り、作業を実行し、レポート結果を保存してから、キューからメッセージを削除します。
  • ユーザーがレポートを要求すると、すべての Web ロールがレポートにアクセスできるようになります。

これが "推奨される通常のパターン" であり、最初の Azure PDC (このトレーニング コースでも使用されています) の写真アップロード/サムネイル生成アプリなどで実装されていることがわかります。2 ページ目まで続きます。

もちろん、実際には、処理するデータのサイズとタイプによっては、このパターンに基づいて構築する必要がある場合があります。

于 2011-03-20T19:45:17.473 に答える