マルチテナンシーまたはマルチインスタンス?


11

私はWebベースのSaaSソリューションを構築しようとしており、マルチテナンシーまたはマルチインスタンスを使用するかどうかわからないところに行きました。私が達成しようとしていることと、それぞれのアプローチの長所と短所(読んだことによると私の意見)について説明しようと思います。どちらか一方のアプローチで何かを見逃した場合に備えて、提案を含めてください。

私が構築しようとしているアプリケーションは、前述したように、企業がアカウントを作成できるSaaSソリューションであり、各アカウント/企業には独自のユーザー、顧客、製品、サービスなどがあります。各ユーザー; 会社の従業員は誰ですか。1つのアカウント/会社に関連するユーザーは、その会社の顧客、製品、およびサービスにのみアクセスできます。企業は無制限の数の顧客、製品、サービスを持つことができるため、各企業には独自のデータセンターが必要です。

そのため、共有データベース(ログインのためにすべてのユーザーの資格情報を保存する)と複数のデータベース共有スキーマ(アカウント/会社ごとのデータベース)を作成することにしました。基本的に、マルチテナント

次に、誰かが代わりにマルチインスタンスを使用することを提案しました。そこでは、各会社が他の会社から完全に分離されたアプリケーションの独自のインスタンス(つまり、コード、ライブラリ、データベース、フレームワークなど)を持ちます。これは、各テナントのユーザーが会社のデータにのみアクセスできることを確認する必要がある追加のレイヤーを処理する必要がないため、より良いように聞こえます。私がこのアプローチを達成するためにDockerに依存していることを言及するのは良いことだと思います(私は以前にそれを使用したことがありません)が、機能が不足していると思います(詳細は後で説明します)将来必要になるでしょう(少なくとも私はしませんでした)少し検索しても見つかりません)。

ただし、どちらのアプローチにも長所と短所があるため、どちらのアプローチを選択するか決定できませんでした。ここにリストがありますが、両方の知識が不足しているので、私にはわかりません。私が知らないことや、Webで見つけられなかった問題の解決策がある可能性があります。[各アプローチには私が1つずつ比較した順序付けられたリスト]

マルチテナンシー

  1. 共有ホスト/ハードウェア、共有コード、およびマルチデータベース。
  2. それはだ簡単にコードと修正のバグの機能(共有コード)を拡張します。
  3. ハードウェアを拡張する(クラウドサービスを使用できる)か、コードに変更を加えずに個々のテナントのデータベースを別のシステムに移動するのは困難です。
  4. 最も重要なことは、前述したように、ユーザーが実際に自分の会社に属していて、他の会社の情報にアクセスしていないことを確認するために、システムに追加のレイヤーを追加する必要があります。

マルチインスタンス

  1. 共有または非共有のホスト/ハードウェア、インスタンスごとのコード、インスタンスごとのデータベース。
  2. それはだ難しく(あなたは1つのインスタンスまたはドッカーコンテナに機能/機能を追加し、他の人にそれを展開することができドッカーでそれを行う方法がある場合、私はわからない)機能や修正のバグを拡張します。
  3. それはだ簡単に別のホスト/ハードウェアに全体のインスタンスを移動すること。
  4. インスタンスとして、各インスタンスは独自のデータベースを持っているので、そのレイヤーを処理する必要はありません。

(各テナントのインスタンスを手動で作成するなどして)手動で何かを実行したい場合は、長所と短所のすべてが冗長であり、それがDockerソリューションを疑う理由です。質問の理由。解決策を参照して質問に答えていただければ幸いです。なぜこのアプローチが他のアプローチよりも優れていると思いますか。

それが役立つ場合(多分?)、バックエンド(すべてRESTful)のメインフレームワークとしてLaravelを使用しています。


すべてを1つのデータベースに入れることもできます。資格情報を単一のデータベースに格納している場合、残りのデータを分割する意味はわかりません。
GrandmasterB

各テナントのデータを分離するポイントを逃したと思います。共有データベースはログイン専用です。
Asher

いいえ、私は要点を見ました。そのようにすると、単一のデータベースを使用する場合と比較して、不必要な複雑さ以外の何かが得られるということに同意しません。
GrandmasterB

各テナントには膨大な量のデータ(顧客、サービス、製品など)があるため、パフォーマンスとセキュリティの懸念から、各テナントデータを異なるデータセンター/データベースに分離したいと思います。
Asher、2015

@Anas 2つのオプションのいくつかを決めましたか?なぜ?アンスウェアは、同じ質問をしている人に役立ちます(いいね)
alecardv

回答:


8

私は今、まったく同じ質問をしている。

私はマルチインスタンスの単一テナンシーソリューションに傾いていますが、最終的な決定はまだ下していません。私の考えをいくつか共有させてください。

マルチテナントアーキテクチャの主な歴史的利点は、相互化(単一のOS、単一のデータベース、単一のアプリケーションレイヤー)によるインフラストラクチャリソースのより良い使用と、前述のリソースのより良い占有(あるユーザーが離れているときに別のユーザーが同じリソースを使用できる)です。 。

また、ソフトウェアのライフサイクルを大幅に簡素化します。新しいバージョンを1つのインスタンスにデプロイすると、すべての顧客が同時に更新されます。

ただし、クラウドテクノロジーの最近の進歩により、マルチインスタンス(顧客ごとのインスタンス)アーキテクチャで最初のクラスの利点がほぼ利用可能になったようです(ここではJelasticのようなプラットフォームについて具体的に考えていますが、他にも確かなものがあります。同じ機能を提供します):

  • コンテナーベースのPaaS
  • コンテナー(弾性コンテナー)のプロビジョニングと自動スケーリング

したがって、ハードウェアとプラットフォームの管理は、もはやソフトウェアプロバイダーの懸念事項ではありません。リソースは、インフラストラクチャレベルとプラットフォームレベルで以前よりもはるかに効率的に相互化されています

マルチインスタンスのオーバーヘッドは依然として存在しますが(一部のアプリとミドルウェアは1つではなくN回実行されます)、インスタンスごとに個別の(仮想)マシンを使用する場合よりもはるかに低くなります。とにかくデータベースを共有できます(インスタンスごとに1つのスキーマ、DBサーバーごとにいくつかのスキーマ)

また:

  • PaaS APIを介して新しいインスタンスの作成の自動化が可能
  • 新しいバージョンのデプロイメントの自動化は、PaaS APIを介して可能であり、ダウンタイムはありません(いくつかの作業を行う必要があります)
  • スケーリングは常にアウトであり、アップすることはありません。インスタンスレベルでの巨大なデータセットについて心配する必要はありません。

もちろん、これらすべてを自動的に管理するある種の中央サービス(たとえば、新しいユーザーがアカウントを作成するときにインスタンスを作成する)が必要です。これにより、支払いとライセンスの問題、インスタンス間の相互作用なども管理されます。この中央サービスは非常に複雑で開発が難しい場合がありますが、良い点は、事前に実装する必要がないことです(今のところ、一方、マルチテナントは最初からアプリにベイクする必要があります。

これにより、非常に早い段階(インベスティング前)のスタートアッププロジェクトでシングルテナントを開発することの最終的な利点がわかります。

  • 同じバージョン(またはほぼ同じバージョン)のアプリをオンプレミスで仮想アプライアンスまたはDockerコンテナーとして、または顧客管理マシンにデプロイすることもできます(一部の企業はまだクラウドに消極的であり、初期段階のスタートアップが重要なアーリーアダプターを押し出す)
  • 限られたリソースでアプリケーションを迅速に入手でき(アプリケーションレイヤーとデータベーススキーマはそれほど複雑ではありません)、アーリーアダプター向けの「ダム」シングルインスタンスシングルテナント製品(MVP)を最初に入手し、アプリのビジネス価値を示すことができます。潜在的な投資家に、そしてすべてのクラウドオートメーションを後で追加します
  • データのセキュリティを心配している顧客にとっての売りの議論と見なすことができます。すべての顧客が独自のスキーマまたはデータベースさえ持っているので、データはよりよくカプセル化されます。「流出」のはるかに少ないリスク

注意:ここでは明らかに、顧客がビジネス(それぞれ複数のユーザーがいる)であり、個人ではないビジネスアプリを考えています。個々のユーザーごとにアプリの個別のインスタンスを実行しても意味がありません(またはそうでしょうか?)


4

両方のオプションのサポートも可能です(複数のインスタンスにわたるテナントのプール)。

私は自然の孤立の複数インスタンスの原因を支持します。各顧客のインスタンスは独自のプロセスで実行され、そのデータは独自のデータベースに分離されます。必要に応じて、顧客/インスタンスごとにインスタンスを新しいバージョンにアップグレードできます。

テナントベースのシステムには情報セキュリティのリスクがあります。"WHERE tenantId = x"句を忘れるのがいかに簡単かを考えてください。テナント対応システムを使用する主な理由は、パフォーマンスであり、プロセスは重量があります。プロセスを共有することにより、1台のマシンからより多くを得ることができます。これは、32ビットの世界では、より多くのRAMを搭載した64ビットのマシンで使用されていると思うのです。

マルチインスタンスシステムでは、データベースやWebアプリケーションインスタンスなどの環境を作成および構成するために、もう少しツールが必要になる可能性があります。単一インスタンスの展開でも、このスクリプトを作成する必要があると主張できます。これを行うには、開発環境とテスト環境をセットアップする機能のような他の特典もあります

あなたがそれを主張できるようになるまで、私はテナントの機能を省きます(エンジニアリングコストとプロセス共有によって(ハードウェア)インフラストラクチャに節約されたお金)。


私はLaravelのEloquent ORMを使用するので、情報セキュリティリスクは問題にはなりません(十分な注意が必要です)。私の懸念は、この場合にどのアプローチがより適しているか、そしてなぜですか?...そして「マルチインスタンス」の場合、機能を追加するときに使用できるツール(各インスタンスがDockerコンテナーイメージであることを考慮して)は何ですか?(Docker関連のツールを使用して)残りのすべてのインスタンスにデプロイする方法は?
Asher

私は@Joppeに完全に同意します。ここでさらにいくつかのポイントを示します。1.顧客は他のすべてのアプリケーションと同時にアプリケーションをアップグレードしてもよいですか?一部のお客様には、アプリケーションをアップグレードする前に長いテストサイクルを必要とするルールがあります。他の人は常に最新の状態を保ち、ベンダーのテストに依存したいと考えています。マルチテナンシーは悪夢になる可能性があります。2.リスク:データの機密性のレベルはどのくらいですか?Joppeが述べたように、フィルタリングを忘れて機密データを他人に公開するのは簡単です。マルチテナンシーではあなたは訴えられるかもしれません、マルチインスタンスでは、あなたは責任を委任しようとするかもしれません。;)
Danilo Tommasina 2015
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.