シングルテナントからマルチテナントに切り替えようとしているASP.NETMVC2Azureアプリケーションがあります。私はここStackOverflowで多くのブログや投稿、質問を確認してきましたが、それでもこの特定のアプリに適したものの詳細に頭を悩ませようとしています。
現在、アプリケーションはいくつかの情報をSQL Azureデータベースに保存し、その他の情報をAzureストレージアカウントに保存しています。新しいAzureストレージアカウントとともに、新しいテナント用の新しいデータベースを作成するだけのテナントプロビジョニングコードを作成することを検討しています。これは私に次の質問をもたらします：
このアプローチをローカルでテストするにはどうすればよいですか？私の知る限り、ローカルのAzureStorageEmulatorにはストレージアカウントが1つしかありません。ローカルで他の人を作成できるかどうかはわかりません。これをローカルでテストするにはどうすればよいですか？それとも可能でしょうか？
マルチテナンシーでは考慮すべき多くの側面があり、その1つがデータアーキテクチャです。また、請求、パフォーマンス、セキュリティなどもあります。
データアーキテクチャに関しては、最初にSQLストレージについて調べてみましょう。次のオプションを使用できます。コードがレコードのフィルタリングに使用するCustomerID（または他のID）を追加し、顧客ごとに異なるスキーマコンテナーを使用します（各顧客は、専用スキーマが所有するすべてのデータベースオブジェクトの独自のコピーを持っています）データベース内）、線形シャーディング（各顧客が独自のデータベースを持っている）およびフェデレーション（パフォーマンスとスケーラビリティのニーズに基づいてプログレッシブシャーディングを提供するSQL Azureの機能）。これらのオプションはすべて有効ですが、パフォーマンス、スケーラビリティ、セキュリティ、メンテナンス（バックアップなど）、コスト、そしてもちろんデータベース設計にさまざまな影響を及ぼします。あなたが提供した情報に基づいて、どれを選ぶべきかをあなたに伝えることができませんでした。すでにコードベースがある場合、一部のモデルは他のモデルよりも実装が簡単です。一般的に言えば、線形シャードは最も単純なモデルであり、強力な顧客分離を提供しますが、おそらくすべての中で最も高価です。スキーマベースの分離はそれほど難しくはありませんが、セキュリティ要件を適切に処理する必要があり、このアプローチはシェアードナッシング（同じデータベース上の顧客の場合）ではないため、顧客間のパフォーマンスの問題が発生する可能性があります。最後に、フェデレーションでは顧客IDの使用が必要であり、いくつかの制限があります。ただし、このテクノロジーを使用すると、パフォーマンスの分散と長期的なスケーラビリティをより細かく制御できます（線形シャードのように、フェデレーションはシェアードナッシングアーキテクチャを使用するため）。スキーマベースの分離はそれほど難しくはありませんが、セキュリティ要件を適切に処理する必要があり、このアプローチはシェアードナッシング（同じデータベース上の顧客の場合）ではないため、顧客間のパフォーマンスの問題が発生する可能性があります。最後に、フェデレーションでは顧客IDの使用が必要であり、いくつかの制限があります。ただし、このテクノロジーを使用すると、パフォーマンスの分散と長期的なスケーラビリティをより細かく制御できます（線形シャードのように、フェデレーションはシェアードナッシングアーキテクチャを使用するため）。スキーマベースの分離はそれほど難しくはありませんが、セキュリティ要件を適切に処理する必要があり、このアプローチはシェアードナッシング（同じデータベース上の顧客の場合）ではないため、顧客間のパフォーマンスの問題が発生する可能性があります。最後に、フェデレーションでは顧客IDの使用が必要であり、いくつかの制限があります。ただし、このテクノロジーを使用すると、パフォーマンスの分散と長期的なスケーラビリティをより細かく制御できます（線形シャードのように、フェデレーションはシェアードナッシングアーキテクチャを使用するため）。
ストレージアカウントに関しては、顧客ごとに異なるストレージアカウントを使用することが、間違いなく進むべき道です。個別のストレージアカウントを使用しない場合に直面する主な問題は、単一のストレージアカウントを使用して実行できる1秒あたりの最大トランザクション数などのパフォーマンスの制限です。ただし、ご指摘のとおり、ローカルでのテストは問題になる可能性があります。ただし、これを考慮してください。ローカルエミュレーターはAzureストレージアカウントと100％の同等性を提供しません（一部の機能はエミュレーターでサポートされていません）。したがって、初期開発とトラブルシューティングにはローカルエミュレーターのみを使用します。マルチテナントテストを含む深刻なテストは、実ストレージアカウントを使用して実行する必要があります。これは、アプリケーションを完全にテストできる唯一の方法です。
個別のデータベースを作成するのではなく、単一のSQLデータベース内に異なるオブジェクト名前空間を作成することを検討する必要があります。各テナントは、独自のテーブルのセットを持つことができます。
ストレージの使用方法に応じて、クライアントごとに個別のストレージコンテナまたはメッセージキューを作成できます。
これらの制約があれば、ストレージエミュレーターとローカルSQLインスタンスを使用してローカルでテストできるはずです。
さらに説明が必要な場合はお知らせください。