すべての顧客用のマルチテナントアプリまたは個別のインスタンス
Webアプリを販売しているとします。複数の顧客が関与するデータや操作はありません。各顧客は完全に独立しています。
どのように配置しますか？
1）顧客ごとに1つのインスタンスをデプロイします。つまり、さまざまなサーバー/仮想マシン/クラウドなどで多数の小さなアプリを実行および管理しています。
2）さまざまな顧客自身を管理するマルチテナントアプリを作成し、1つの大きなアプリを管理し、クラウドでスケーリングします。あなたは基本的にユーザー名/パスのペアを販売しています。
または、私が知らない3番目のアプローチ。
選択は明確です（誰もがこの2番目の方法を行っているように）、またはそれらのモデル間の賛否両論の多くの考慮事項がありますか？
あなたがしなければならないいくつかのトレードオフがあります：
1。専用インスタンス
利点：
- 追加の開発も概念的な作業も必要ありません（製品を市場に出すための時間とコストの削減）
- すべての顧客は完全に独立しています。つまり、技術的な柔軟性（場所、ボリュームの価格などに応じてホスティング設備を選択できます）、カスタマイズ可能性（顧客は特別にカスタマイズされたバージョンを要求できます）、およびセキュリティの向上（リスクはありません）顧客が他の顧客のデータにアクセスしたり、SQLインジェクション攻撃のような1人の顧客の損害が他の顧客に影響を与えたりする可能性があります。
- 顧客が望む場合は、顧客が同じ製品を自分のプレミスにインストールするように提供できます。
Inconvence：
- 規模の節約はありません。これらすべてのサーバーを管理する必要があります。つまり、すべての新規顧客に技術的なオーバーヘッドが発生します（インストールだけでなく、監視、セキュリティパッチ、必要な追加のディスク容量の予測など）。
- 高価なメンテナンス：製品の新しいリリースが発生した場合のアップグレード手順は、顧客ごとに繰り返す必要があります。
2。マルチテナントアーキテクチャ
利点：
- mainainへの単一のソフトウェア
- 事業の規模の経済
- つまり、最終的には費用対効果が高く、顧客の価格が安くなります（または、マージンが高くなります）。
不便：
- あなたは顧客のカスタマイズ性に制約があります。
- 開発への初期投資の増加：マルチテナンシーを設計する必要があります（見た目ほど簡単ではありません）。設計する機能は、さまざまな顧客の潜在的なバリアントを考慮する必要があります
- より高い運用リスク（例：大量+潜在的なボトルネック+クロスカスタマーセキュリティリスク+問題がすべての顧客に同時に影響する可能性があることを考慮して、スケーラビリティとパフォーマンス管理を確実にする必要があります）
3。その他の代替手段：マイクロサービス？
3番目のシナリオは、アプリケーションをより小さな microservices にカットすることです。スケーラビリティは最大化されます。顧客ごとにサービスを分割するか、マルチテナンシーを選択するかは、あなた次第ですが、アーキテクチャ全体は、これらの選択が比較的簡単になるように設計されています。アプリケーションには完全なリエンジニアリングが必要です。
推奨事項
オプション1は、大規模な顧客が少数の場合、または非常に迅速に市場に出なければならない場合の一時的な解決策として選択する方法だと思います。
オプション2は、クライアントが多く、規模の経済を実現したい場合には、より合理的な選択のように思えます。
オプション2を選択するが、スケーラビリティの問題が予想される場合は、オプション3が適しています。膨大な数のクライアントが予想される場合は、このアプローチに直接進んでください。
複数のテナンシーをサポートするようにアプリを構築する場合、将来の技術担当者はそれを展開する方法について選択することになります。シングルテナントインスタンスを要求する顧客を見つけた場合は、それらをサポートできます。 infosecの理由でこのアプローチを好む顧客もいます。
同時に、マルチテナント操作を実行できるようになります。これは、顧客を集めることでアプリケーションを拡張するのに役立ちます。これにはいくつかの部分があります。
- 技術的なスケーリング。単一のインスタンスを使用する顧客が増えると、ボトルネックや競合状態について正直になります。多くの小規模なインスタンスではこれらの問題に直面しない可能性があります。また、sysadminとバックアップ作業を行うと、時間も楽になります。
- ビジネスのスケーリング。マルチテナントシステムは、トライアルや小規模な顧客を経済的に処理できます。
- 顧客の成功に応じたスケーリング。顧客があなたの製品を気に入って、すべてのサプライヤーにそれを使用することを要求したい場合はどうなりますか？マルチテナントでは、それは顧客リストのアップロードです。シングルテナントでは、それはインスタンスのリギングがたくさんあります。
マルチテナントは、アプリの設計に進むための方法です。それは選択肢を開いたままにします。
私が取り組んだすべてのアプリケーションで2つの開発が発生するのを見ました。
- 機能は、支払いを希望する1人の特定の顧客にのみ必要です。最も成功したスタートアップでさえ、この機能は抵抗するのが難しいので、時間のプレッシャーのためにアプリのコードベースは発散します。ある時点で、それらはマージできなくなり、マルチテナントソフトウェアが成功した場合、単一のテナンシーがそのまま残ります。さらに悪いことに、複数のソフトウェアを管理するために多くのメンテナンス作業が必要になりました。
- 最小の経済圏（鉱山はニュージーランド）であっても、すべての部門のレコードにアクセスできるある種の企業スーパーユーザーを必要とする顧客にすぐに出会う一方で、部下の複数のテナンシーは別々に保つ必要があります。これは、マルチテナンシーアプリケーション全体とまったく同じであるため、いずれにしてもビルドする必要があります。
選択はまったく明確ではなく、ハイブリッドアプローチを簡単に実行できます。たとえば、Atlassianでは、サーバーでツール（Jira、Bitbucketなど）を使用できますが、独自のサーバーにインストールすることもできます。
顧客ごとに1つのインスタンスの欠点は、すべての更新をすべての顧客にプッシュする必要があることですが、そうするかどうかを選択できる場合があります。すべてのお客様が絶えず変化するアプリケーションに満足しているわけではないことに注意してください。ただし、すべてを管理できるわけではありません。バックアップ、サーバーオペレーティングシステムなどについて考えてみてください。数十の競合ポイントが考えられます。
急速に進化するアプリケーションでは、中央のアプリが理にかなっていると思います。それはあなたにちょうど別のタイプの頭痛を与えるでしょう。そして、あなたが何かを台無しにすると、すべての顧客が同時に影響を受けます。
補足：ユーザーのデータを個別のデータベースに保持することは、central-app-approachでは意味があるかもしれません。また、顧客ごとに個別のインストールを行うこともできますが、データセンターの制御された環境で、完全な制御を維持できます。オプションの数に応じて複雑さが指数関数的に増大することを常に覚えておいてください。