マルチテナンシーのサポート
シングルテナントアプリをマルチテナントアプリに変換するときに発生する典型的な課題は何ですか？セキュリティとデータの分離が最も重要だと私は思います。他には何がありますか？
私はかなり重要な自動化作業のアーキテクトの1人であり、歴史的にそれはそれを使用している私たちの会社でした。他の人も利用できるようにしたい。 「マルチテナント化」について話すときは常に、あるテナントを持つユーザーを別のテナントが所有するデータから遠ざけることと、あるテナントを持つユーザーが別のテナントに（意図的または不注意で）影響を与えないようにすることを話し合います。テナントの環境。ここで私が疑問に思っているのは、セキュリティ/データの分離だけが本当にここでの唯一の主要な懸念であるのか、それとも私たちが考えていない他のいくつかの主要な懸念があるのかです。
データのサイロ化に加えて、次の問題が発生する可能性があります
- 可用性-単一のテナントでは、DoSのみがDoSを実行できますが、データが適切にサイロ化されている場合でも、テナントはリソースを使い果たす可能性があります。
- ロギング-すべてのログメッセージは単一のテナントを想定しています。テナントごとにログを保存しない限り、ログメッセージの有用性が低下する可能性があります。
- 同時実行性-シングルテナントアプリは中程度の負荷で実行される可能性があります。または、いくつかのロックの高い競合により、特定の操作が効率的にシリアル化される場合があります。テナントごとにロックが乗算されると、以前には発生しなかった操作のインターリーブが発生する場合があります。これまで明らかになる可能性が非常に低かった競合状態は、現在現れる可能性があります。
- リソース競合の新しいソース-以前はn個のソケットとm個のファイルハンドルがあった可能性がありましたが、現在はそのテナントごとに増加しています。
- 構成可能性/下位互換性のトレードオフ-置き換えをロールアウトするときにコンポーネントを廃止する前に、1つのテナントがコンポーネントを要求し、1つのテナントがそれを置き換える古いコンポーネントが無期限に残ることを要求することができます。
- 召喚状の対象-現在、あなたは会社に関連する問題の召喚状の対象です。マルチテナントでは、法的措置の当事者ではない場合でも召喚状の要求に応答する必要がある場合があります。
これらの一部は、すべてのテナントを同じアドレス空間（マシンまたはクラスター）で実行していると想定しています。各テナントがハードウェア上でソフトウェアを実行している場合は、上記の一部を無効にして追加できます。
- デバッグするためにマシンにアクセスすることが難しい。
- 古いバージョンのサポートリクエスト。
- サードパーティの請負業者が設定できるようにするリクエスト。
- 実行するハードウェアに対する制御が少ない。
- 実行しているOSのパッチ/更新サイクルの制御が少ない。
私の意見では、マルチテナントの最大の問題はカスタマイズです。これは、ビジネスアプリケーションを企業に販売する場合に日常的に発生します。独自のスキンを必要とするすべての顧客のような単純なものから、追加のフィールド、ルール、フォーム、レポートを構成する機能まで、さまざまなものがあります。サポートする必要のあるカスタマイズのレベルは、アーキテクチャで重要な役割を果たします。
マイクの答えは非常に良いです。そして、そこにある多くのポイントは、それらがどれほど短いためにそれらの複雑さをほとんど下回っていますので、それらを心に留めてください。
私が付け加えた1つのポイントは、新しいテナントを作成（および後で管理）するための優れた管理ツールが必要であることです。使用する物理アーキテクチャによっては、これは簡単なことではなく、見過ごされがちです。サービス製品としてのソフトウェアの利点は、テナントの数が多い場合にのみ効果を発揮するため、これに対応するにはかなりの労力を費やす必要があります。
スリラムの答えを拡張する。テナントごとcustomizationはほとんど禁止されています。テナントが変更する可能性のあるすべてのものはconfigurableである必要があります。例えば。ソリューションが少なくともいくつかの主要な領域でのデータフィールドの動的な追加に対応していない場合、カスタマイズの要求が殺到する可能性があります。これは、少し複雑な前払いが実際に効果を発揮する数少ないケースの1つです（YAGNIに反すると言うか、少なくとも、このレベルの構成はほとんど重要な要件なので、必要なのはareが必要です）それ）。