2017-01-09 10 views
1

私が働く会社では、データベースが分離されている複数の組織のCRMシステムを開発してホストしています。つまり、クライアントはFacebookに似た1つの大きなデータベースを共有していません。しかし、同じCRMソフトウェアです。キャッシングのような他のシステムの側面はすべて、組織固有のものです。複数の組織のシステム設計

私たちはサーバーをAWSに移行しているため、インフラストラクチャについて考える機会がありました。

私たちのベースシステムはCodeIgniterフレームワークを使用して書かれているので、単一のインスタンスを作成し、ホスト名/ユーザーアカウントに応じて関連するデータベース認証情報を添付することで、同じCRMのインスタンスを複数持つ代わりにCRMは専用のURLを介してアクセスされます)。例えば。ユーザーAがB社の仕事をしている場合は、B社のデータベースに接続し、C社の会社には接続しません。この例は、バージョニング管理にも役立ちます。

他の人が同様の経験をしているのか、そしてインスタンスを完全に分離しておくか、真の「ソフトウェアとしてのソフトウェア」単一インスタンスメソッドに移行するのが一般的な感じかと思いますか?

答えて

0

本当にDBサイズとトラフィックに依存します。多くのトラフィックがある場合は、別のDBがあれば、より多くのリソースが必要な場合や、管理が簡単な場合に、独自のサーバーインスタンスに簡単に移動できます。多くのトラフィックがない場合は、1つのDBを使用できますが、会社固有の何かを行う必要がある場合は危険です。コードを使用すると、インスタンスごとに個別に変更をロールアウトする必要がなくなるため、単一のインスタンスを維持するのがはるかに容易になります。サーバーが容量に達すると、ロードバランサーをたたき、同じwebserver()念頭に置いて、DBは別々のサーバーに置く必要があります。

+0

データベースサイズは比較的小さく、組織あたり5 GBです。私は、組織にマップして関連するデータベースの資格情報を読み込む追加のユーザー認証層を検討する可能性が最も高いです。その後、誰もがhttps:// crm。[x] .comを介してアクセスできるようにします。 - 私はロードバランサを見てきましたが、単一のドメインがはるかに単純です。 – aldocx

+0

専用のURLを使用している場合は、負荷分散が複雑になる可能性がありますが、必要な場合にはまだ可能です。ソリューションそのものについては、マルチクライアントプロジェクトの場合と同じように、1つのアプリケーションと専用データベース、すべてのクライアントでコアロジックが同じであれば、ユーザーグループごとにDB接続を処理するだけです。 – Auris

0

このスレッドの著者はすでに回答を受け入れています。しかし、私はmulti-tenant architectureを読むことをお勧めします。ここでは、個々の企業をテナントとして関連付けることができます。

0

含むマルチtencancyまたはシングルテナントアーキテクチャを選択する際のいくつかの重要な考慮事項、あります

  • セキュリティ - あなたが効果的にデータを分離することができ、アクセス、アクセス許可などのマルチテナント環境での使用
  • インフラストラクチャのコスト - 1人のテナントでサーバ/プラットフォームのキャパシティを効果的に活用できるでしょうか? AWSでは、スケーリングがこれを助けることができます。
  • ライセンスコスト - シングルテナント環境では、追加のライセンスコストがかかります(通常、サーバーの数が多いほどライセンス数が増えます)。
  • 実装および保守に要する労力 - 単一テナントソリューションでは、導入管理とインフラストラクチャの維持にかなりの労力が必要ですか?
関連する問題