マルチテナントアーキテクチャに移行するための設計

Question

現在、マルチテナンシーをサポートするように製品コードを再設計しています。

現在、実装は、1つの製品展開が1人の顧客のみに対応するようになっています。

したがって、アプリケーションデータは1人の顧客にのみ対応します。このデータ（アプリケーションに対してグローバル）は、ハッシュテーブル、リスト、およびDBの形式です。複数のスレッドがこのデータを利用します。完全なコードはCで書かれています。

ここで、マルチテナントアーキテクチャに移行するため、アプリケーションコードは複数の顧客のデータを格納する必要があります。アプリケーションに保存されているデータは顧客ごとに分離する必要があるため、この要件に最適なアーキテクチャの種類を把握したいと思います。 C++も使用できるので、ここでいくつかのOOPの概念を採用することを考えています。しかし、このアイデアがどれほど優れているかはわかりません。モジュール性は、OOP = Cを介したオファーであり、したがってそれらの行を検討しますが、同時に、多くの変更を必要とする現在の実装で膨大な量になるため、これを最小限に抑えることも重要です。

上記のすべての目的を達成するための最良のアプローチは何でしょうか？これを行う他の方法はありますか？

user53019 · Answer

バブルバースト：マルチテナントアーキテクチャへの移行は、コード内でOOPを利用することとは直交する側面です。はい、そうです。アプリケーションコードを更新する必要がありますが、プログラミングの全体的なスタイルを必ずしも変更する必要はありません。

そして今、実際の答えについて：

マルチテナント環境への移行にはつの幅広いアプローチがあります。私はあなたがあなたの問題を解決するために混合アプローチを望んでいると思います。これは、システム管理オーバーヘッド間の最適なバランスを表しています。作成する追加のコード。およびデータベースのメンテナンス。

混合アプローチは、データへのアクセスを制御するために authorization チェックを持つ単一の共有スキーマを使用することです。

この混合マルチテナンシーを取得する最も簡単な方法は、アクセス制御が必要なさまざまなデータベーステーブルに所有権を表す列を追加することです。また、ユーザーまたはグループを、アクセスが許可されているデータベース所有者IDにリンクするアクセス許可テーブルがまだない場合は、アクセス許可テーブルを作成する必要があります。

アプリケーション内で、アクセス制限を反映するようにクエリを更新する必要があります。すでにセキュリティ/承認レイヤーがある場合、これはかなり簡単に追加できます。そうでない場合は、データベースのクエリに最も近いアプリケーション内のポイントを見つけて、そこにチェックを追加してください。これは、ある種のデータアクセス層を持つことであなたの生活が本当に楽になる場所です。

ストアドプロシージャを使用するのに十分賢い場合は、クエリを変更するのがさらに簡単です。アプリケーションはすでにストアドプロシージャを抽象インターフェイスとして扱っているため、承認コントロールの追加はアプリケーションに対して透過的です。

別のオプションは、クライアントに基づいてビューを作成することです。これを機能させるのは少し難しいですが、ユーザーまたはグループがアクセスを許可されているビューを示す同様のアクセス許可テーブルを作成できます。実行時、またはおそらく制御するある種の構成を通じて、クエリはどのビューに対して実行できるかが通知されます。

データベースにデータを書き込むときは、所有権がデータと一緒に記録されていることを確認する必要があります。これはクエリと同様のプログラム上の課題ですが、個々のユーザーではなく、クライアントグループIDに所有権を割り当てることをお勧めします。例外は、クライアントのビジネスを表す一般的なユーザーがいる場合です。

データベーススキーマ内に、クライアントに割り当てることができるオブジェクト内のデータを整理するための構造がない場合は、それを作成することを検討してください。 ClientAがアクセスできる数十億行のデータの代わりに、ObjectAが所有するClientAに属する数億行のデータがあります。システム内に複雑な数のオブジェクトがある場合、オブジェクトの所有権を抽象化すると、アクセスクエリの一部を簡略化できます。

驚いたことに、マルチテナント環境に移行するためのそれについてです。明らかに、痛みは細部にあります。セキュリティメカニズムが期待どおりに動作していることを検証するために、ユニットテストと統合テストを実施することをお勧めします。

OOPとモジュール性について-あなたの一般的な考えは順調に進んでいます。ただし、Cのような構造化言語内でOOの原則を使用できることに注意してください。そのコードスタイルを維持するには、より多くのガバナンスが必要ですが、探しているモジュール性の利点のいくつかを得ることができます。にとって。

データアクセス層がまだない場合は、今がデータアクセス層の導入を検討するときです。 DALがあると、そのロジックを1つの領域にカプセル化し、DBアクセスをアプリケーションの他の部分から切り離すことができます。これらの原則を実装すると、将来の変更をより簡単に実行できるようになります。

単一のDBMS内でクライアントごとに完全なDBスキーマを使用するなど、マルチテナンシーには他のアプローチがあります。複数のスキーマがあると、必要な承認/所有権の変更の一部がバイパスされます。ただし、欠点は、このアプローチでははるかに大きなDBMSサーバーが必要になる可能性があることです。

もう1つのオプションは、データを分離するために、クライアントごとに完全なDBMSを使用できることです。ここでも、セキュリティの変更の一部をバイパスしますが、より多くのサーバーを維持する必要があります。このオプションでは、スキーマ間の参照整合性が問題になります。

ただし、質問のコンテキストは、共有DBを備えたマルチテナントを探していることを示唆しているため、これらのアプローチについては説明しませんでした。