マルチテナンシーのサポート

シングルテナントアプリをマルチテナントアプリに変換するときに発生する典型的な課題は何ですか？セキュリティとデータの分離が最も重要だと私は思います。他には何がありますか？

私はかなり重要な自動化作業のアーキテクトの1人であり、歴史的にそれは私たちの会社がそれを使用しているだけでした。他の人にも利用してもらいたい。「マルチテナント化」について話すときは常に、あるテナントを持つユーザーを別のテナントが所有するデータから遠ざけることと、あるテナントを持つユーザーが（意図的または意図せずに）別のテナントに影響を与えないようにすることを話し合いますテナントの環境。私が疑問に思っているのは、セキュリティ/データ分離が本当にここでの唯一の主要な懸念であるのか、それとも私たちが考えていない他のいくつかの主要な懸念があるのか​​です。

データのサイロ化に加えて、次の問題が発生する可能性があります

1. 可用性-単一のテナントでは、DoSのみがDoSを実行できますが、データが適切にサイロ化されている場合でも、テナントはリソースを使い果たす可能性があります。
2. ロギング-すべてのログメッセージは単一のテナントを想定しています。テナントごとにログを保存しない限り、ログメッセージの有用性が低下する可能性があります。
3. 同時実行性-シングルテナントのアプリは中程度の負荷で実行される可能性があります。または、いくつかのロックの高い競合により、特定の操作が効率的にシリアル化される場合があります。テナントごとにロックが乗算されると、以前には発生しなかった操作のインターリーブが発生する場合があります。これまで明らかになる可能性が非常に低かった競合状態は、現在現れる可能性があります。
4. リソース競合の新しいソース-以前はn個のソケットとm個のファイルハンドルがあった可能性がありましたが、現在はテナントごとに乗算されます。
5. 構成可能性/下位互換性のトレードオフ-置き換えをロールアウトするときにコンポーネントを廃止する前に、1つのテナントがコンポーネントを要求し、1つのテナントがそれを置き換える古いコンポーネントが無期限に残ることを要求することができます。
6. 召喚状のターゲット-現在、あなたはあなたの会社に関連する問題の召喚状のターゲットです。マルチテナントでは、法的措置の当事者ではない場合でも召喚状の要求に応答する必要がある場合があります。

これらの一部は、すべてのテナントを同じアドレス空間（マシンまたはクラスター）で実行していると想定しています。各テナントがハードウェアでソフトウェアを実行している場合は、上記の一部を無効にして追加できます。

1. デバッグするためにマシンにアクセスすることが難しい。
2. 古いバージョンのサポートリクエスト。
3. サードパーティの請負業者が設定できるようにするリクエスト。
4. 実行するハードウェアに対する制御が少ない。
5. 実行しているOSのパッチ/更新サイクルの制御が少ない。

私の意見では、マルチテナンシーの最大の問題はカスタマイズです。これは、ビジネスアプリケーションを企業に販売する場合に日常的に発生します。独自のスキンを必要とするすべての顧客のような単純なものから、追加のフィールド、ルール、フォーム、レポートを構成する機能まで、さまざまなものがあります。サポートする必要のあるカスタマイズのレベルは、アーキテクチャで重要な役割を果たします。

マイクの答えは非常に良いです。そして、そこにある多くのポイントは、それらがどれほど短いためにそれらの複雑さをほとんど下回っていますので、それらを心に留めてください。

私が付け加えたい1つの点は、新しいテナントを作成（および後で管理）するための優れた管理ツールが必要であることです。使用する物理アーキテクチャによっては、これは簡単なことではなく、見過ごされがちです。サービス製品としてのソフトウェアの利点は、テナントの数が多い場合にのみ効果を発揮するため、これに対応するにはかなりの労力を費やす必要があります。

スリラムの答えを拡張する。テナントごとのカスタマイズはほとんど禁止されています。テナントが変更する可能性のあるすべてのものは構成可能である必要があります。たとえば、ソリューションが少なくともいくつかの主要な領域でのデータフィールドの動的な追加に対応していない場合、カスタマイズの要求が殺到する可能性があります。それは（あなたがそれでは、それはYAGNIに反するとしましょう、あるいは少なくとも、コンフィギュレーションのこのレベルはほとんど重要な要件である少し追加の複雑さの先行投資が実際に完済んいくつかのケースの一つだあり、それを必要とするつもり）。