マルチテナントアプリケーションとは正確には何ですか?


13

オンラインで利用可能な定義によると、「マルチテナンシーは、ソフトウェアアプリケーションの単一のインスタンスが複数の顧客にサービスを提供するアーキテクチャです」です。つまり、私はレストランまたは学校のWebサイトを所有しており、学校の管理製品を購入したときに提供する資格情報を使用して、自分のデータでアプリケーションを使用するために別のレストランまたは学校へのアクセスを提供します。私のウェブサイトと同様のようですschoolmanagement.comと私のような別の学校のクライアントに異なるサブドメインを提供school1.schoolmanagement.comschool2.schoolmanagement.comが、コードは、これらのサブドメインの両方の背後に同じです。両方の学校の機能やテーマは異なり、それぞれのデータベースに依存しています。だから私は提供する必要がありますschoolmanagement.comそれぞれのURLなどへのログイン資格情報Iリダイレクトに基づいてログインのために、私のクライアントのログイン一度school1.schoolmanagement.com

これは、マルチテナントアプリケーションについての私の理解です。私の理解は正しいですか?私が通過できるオンラインマルチテナントアプリケーションはありますか?


1
「実行可能なオンラインマルチテナントアプリケーションはありますか」とはどういう意味ですか?ソースを取得するか、テナントとして試すか、ホストとして実行しますか?お気づきのように、ドメインホスティングは一般的なマルチテナントの例であり、大規模なホスト企業と小規模なホスト企業の両方に対応しています。Google Apps for Business(または現在のブランドが何であれ)も、かなり広く普及しているマルチテナントアプリです。
クリスチャンH

1
これまでのところ、あなたは正しい道を進んでいます。マルチテナンシーはデータの所有権に関するものです。データはテナン(所有者)によってセグメント化されます。単純な理由から、アプリケーションの使用は同じでした。規模の経済です。データストレージも同じでも、テナンごとに異なっていてもかまいません。データはテナンの間で共有アクセス可能ではありません(または、通常、それらは共有されていません。
Laiv

@KristianHドメインホスティングの例をありがとう、私はそれを手に入れました。
Nomi Ali

@Laivでは、クライアントごとに異なるデータベースを使用して、独自の個別の構成を設定できますか?
Nomi Ali

2
はい。それが(IMO)の望ましい方法です。しかし、それはまた高価なものです。私が異なるデータベースと言うとき、それらは次の可能性があります:a)同じRDBMS内の異なるスキーマまたはdbインスタンス、またはb)完全に異なるRDBMS。
Laiv

回答:


8

はい、それだけです。しかし、ウィキペディアの定義は十分に一般的ではありません。多層アーキテクチャや、SOAやマイクロサービスなどの新しい形式のアーキテクチャには対応していません。

マルチテナンシーとは、ソフトウェアシステムデータ分離に関するものです。いくつかの例:

  • 一意のデータベースを備えた多層システムは、マルチテナントにすることができます。例:SAPシステムは、データベースバックエンドと、スケーラブルな方法でWebサービスを公開するいくつかのWebアプリケーションサーバーで構成されています。これはマルチテナントです。実行中のソフトウェアのインストールを変更せずに新しい顧客を追加できます。また、複数の顧客がお互いを知らなくてもシステムを使用できます。データは完全に分離されます(独自のテクノロジー)。
  • システムは、Webサービスを実行する1つまたは複数のプロセスで構成され、異なるドメイン名を介して異なる顧客に公開されます(ただし、サーバー上で実行するプロセスと同じです)。データの分離は、個別のデータベースで実現されます。間違いなくマルチテナントです。
  • マイクロサービスシステムは、それぞれ独自のマイクロデータベースを使用して、疎結合された複数のWebサービスのセットを同様に実行できます。スケールアップするために必要な場合は、同じマイクロサービスの新しいクローンを開始できます。それらは、いくつかの登録機能を介してピアを検出し、自動的にそれらに接続して、単一のアプリケーションの動作をユーザーに提供します。次に、2つのシナリオが考えられます。
    • 新しい顧客にサービスを提供する場合、新しい別個のマイクロサービスセットを開始し、1人の顧客のマイクロサービスが同じ顧客に関連するマイクロサービスにのみ接続するように編成する必要がある場合、それはシングルテナントです。
    • ただし、実行中のインスタンスを使用して新しい顧客にサービスを提供できる場合(および新しいマイクロサービスはパフォーマンスのためにのみ必要です)、それはマルチテナントです。

1

はい、あなたの理解は基本的に正しいです。アプリケーションは複数の顧客によって共有され、各顧客のデータはデータベースに混在しています。異なる顧客のデータを同じデータベースに混在させることなく同じコードを共有することは、おそらくマルチテナントとは見なされません。


2
@NomiAliいいえ、そのマルチテナントは考慮しません。これは、顧客ごとに個別の環境を排除することです。マルチテナントの利点の1つは、データベースとソフトウェアがすべての顧客向けに同時にアップグレードされることです。1つの展開で、全員が最新バージョンです。あなたが話していることは、独自の個別のインストールを持っているすべての顧客です。共有コードベースはあるがデータベースが異なる可能性があると思いますが、DBの変更に細心の注意を払う必要があり、コストが高くなり、マルチテナントの目的に反するため、それは愚かです。
アンディ

1
@NomiAli顧客ごとのスキーマには、顧客ごとのデータベースよりもさらに多くの欠点があります。スキーマ名を変更するだけで同じスクリプトを実行する必要があるため、管理がさらに難しくなります。これも不可能ではありませんが、マルチテナントアプリケーションのポイントは、ソフトウェアベンダーのコストを削減することです。あなたが求めていることはそれらを押し上げます。
アンディ

2
それで、すべてのテナンを保持している私の孤独なデータベースがクラッシュしたり、侵害されたりした場合...コスト削減はどこに行くのでしょうか?そして、すべてのテナントがリソースとパフォーマンスの異なるニーズを持っている場合はどうなりますか?データストレージにアクセスしたい場合はどうなりますか?... はい。テナンごとの異なるデータストアと異なるスキーマはマルチテナシーです。ここで、お客様に提供したいビジネス戦略とサービスは、実装の詳細よりも重要です。マルチテナンシーは機能であり、差分値です。お客様のニーズに近いほど良いです。
Laiv

2
それはあなたが興味かもしれないsoftwareengineering.stackexchange.com/q/340531/222996
LAIV

4
マルチデータベースの側面を少し誇張します。複数のデータベースは単なる設計上の決定です。複数のデータベースで同じスキーマを共有し、スクリプトを使用してすべてを同時に更新することができます。すべてのマルチテナントアプリケーションは、各顧客のデータを他の顧客から分離する必要があります。これを実行するメカニズムは、実装の詳細であり、所望の分離の程度などの要因に依存して、等
ロバート・ハーベイ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.