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

Question

私はウェブベースのSaaSソリューションを構築しようとしています、そして私はマルチテナンシーまたはマルチインスタンスを使用するかどうかわからない道にぶつかりました。私が何であるかを説明しようとします達成しようとすることと、それぞれのアプローチの長所と短所（読んだ内容によると、私の意見です）あるアプローチで他のアプローチよりも何かを逃した場合の提案を含めてください。

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

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

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

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

マルチテナンシー：

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

マルチインスタンス：

共有または非共有のホスト/ハードウェア、インスタンスごとのコード、インスタンスごとのデータベース。
機能を拡張したりバグを修正したりするのは難しい（1つのインスタンスまたはDockerコンテナーに機能/機能を追加できるDockerでそれを行う方法があるかどうかはわかりません、他のユーザーに展開します）。
インスタンス全体を別のホスト/ハードウェアに移動するのは簡単です。
インスタンスとして、各インスタンスは独自のデータベースを持っているので、その層を処理する必要はありません。

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

それが役立つと思われる場合（たぶん？）、バックエンドのメインフレームワークとして Laravel を使用しています（すべてRESTful）。

Pierre Henry · Answer

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

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

マルチテナントアーキテクチャの主な歴史的利点は、インフラストラクチャリソースのより良い使用法によるmutualization（単一のOS、単一のデータベース）、単一のアプリケーション層）と前記リソースのより良い占有（1人のユーザーが離れているとき、別のユーザーが同じリソースを使用することができます）。

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

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

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

そのため、ハードウェアとプラットフォームの管理は、ソフトウェアプロバイダーの関心事ではなくなりました。 リソースは、インフラストラクチャとプラットフォームレベルで以前よりもはるかに効率的に相互化されます。

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

また：

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

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

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

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

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

Joppe · Answer

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

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

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

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

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