私は多くの部門別クライアント サーバー アプリケーションを開発してきましたが、現在、これらのアプリケーションの 1 つを SaaS モデルに移行する作業を開始する準備ができています。私はいくつかの基本的な Web 開発を行ってきましたが、SaaS アーキテクチャに関しては初心者です。
アーキテクチャを設計しようとして頭に浮かぶ最初の質問の 1 つは、シングル テナンシーとマルチ テナンシーの問題です。それぞれの長所と短所は、アプリケーションの種類と必要な規模によって大きく異なります。そのため、アプリケーションと規模のニーズについて以下に説明したいと思います。アーキテクチャをどのように開始すべきかについて他の人がコメントできることを願っています。
クライアント サーバー アプリケーションは現在、Firebird データベースと Windows アプリケーションで構成されています。データベースには、4 つのプライマリ テーブルに数千のレコードを含む約 20 のテーブルと、さまざまなルックアップおよび関連テーブルに数百のレコードが含まれています。レコードの数は少ないですが、データベースには大きな BLOB を含めることができるため、サイズが大きくなる可能性があります。各顧客は独自のデータベースをセットアップし、組織内の少数のユーザーがそれに接続しています。データベース スキーマを更新すると、新しい Windows アプリケーションがリリースされ、データベース スキーマがチェックされ、必要に応じて更新が適用されます。
SaaS アプリケーションの場合、私は年間数百 (数千または数百万ではなく) の新規顧客向けに設計しています。私が最初に考えたのは、マルチテナンシー モデルを使用して更新を簡単にすることでした (シャットダウンして 1 つのデータベースに更新を適用してから起動する)。一方、シングル テナンシー モデルは、一度に顧客のグループに更新を展開する手段を提供し、データ破損のリスクを分散します。つまり、データベースに問題が発生した場合、影響を受けるのは 1 人の顧客ではなく、1 人の顧客です。すべての顧客。このアイデアで、ログイン時に単一の顧客データベースに接続する単一の Web フロントエンドを持つことを考えていました。したがって、新しい顧客がアカウントを作成すると、新しいデータベースが作成されます (各顧客は、顧客の必要に応じて複数のユーザーを持つ独自のデータベースを持ちます)。
このモデルでは、データベースの更新には、スキーマの変更を適用するために各データベースを通過するプロセス、または現在使用されているクライアント サーバー モデルと同様のスキーマの更新を開始するためのログイン時のトリガーが必要です。
クライアントサーバーからSaaSに移植された同様のアプリケーションの情報を誰か教えてもらえますか? または、考慮すべき指針を提供しますか? 基本的に、部門別アプリケーションを採用し、それを複数の顧客向けのセルフサービス Web サイトとして利用できるようにするアーキテクチャの例を探しています。提案、リソースなどをありがとう。