マルチテナント アーキテクチャの構築

独自のデータベース内にいる各テナント

さまざまなデータ要件と厳格なアクセス制御要件を持つ、少数かつ安定した数のテナント（最大数百）がある場合は、テナントごとに 1 つのデータベースを作成することを検討してください。

このアプローチには、次の利点があります。

• セキュリティを強化するために、データベースユーザーはテナント データアクセスを制限できます。Atlas では、デフォルトで プロジェクトごとに 100 人のデータベースユーザーを制限しています。

• テナント全体の可変データ構造のユニークなアクセス パターンを考慮するために、インデックスを設定できる。

• 1 つのテナントを専用のリソースに移動するには、テナント全体の分離されたデータを新しいリソース（別のクラスターなど）に移行またはスケーリングできる。

次のことを考慮してください。

• アプリケーション層の複雑さが増す。

• テナント間で冗長なコレクションとインデックスがある。

• 1 つのクラスターで大規模な問題が発生する。新しいコレクションとインデックスごとに必要な基になるデータファイルは、計算リソースを消費する。

各テナントには、同じクラスター上に独自の 論理 データベースがあります。このアプローチにより、簡単にカスタマイズでき、強力なセキュリティを実現でき、他のテナントに影響を与えることなく、1 つのテナントのバックアップとメンテナンスが可能になります。

ただし、このアプローチではセットアップの労力と必要な計算リソースが増加する可能性があり、テナント間のやり取りには複数のデータベースへの接続が必要です。一部の MongoDB コマンドは、同じデータベース内のコレクション間でのみ機能します。

各コレクションとインデックスは個別のファイルとしてディスクに保存されるため、開いているファイルの数が非常に多くなり、メモリ使用量が増加する可能性があります。これを軽減するには、ノードごとに使用するデータファイル (コレクションと個別のインデックス) を 1000 未満にしてください。詳しくは、「コレクションとインデックスの制限」を参照してください。

1 つのデータベースに登録され、コレクションが共有されるすべてのテナント

テナントの数が無限に増加することが予想され、データ構造とクエリ要件はテナント間で比較的一貫しており、アクセス制御要件がそれほど厳しくない場合は、すべてのテナントに共有コレクションを含む単一のデータベースを使用することを検討してください。

このアプローチには、次の利点があります。

• 高い拡張性（例: クラスターをシャード化できる）

• 継続的なメンテナンスを簡素化（新しいクエリパターンのインデックス作成など）

次の潜在的な問題を考慮してください。

• 単一のデータベース ユーザーが、この大規模なマルチテナント データ プールにアクセスする。

• データのセグメンテーションは純粋に論理的なものであり、アプリケーション層で強制する必要がある。

すべてのテナントはすべてのコレクションにドキュメントを持つことができます。マルチテナンシー・ロジックはアプリケーション層に存在します。すべてのドキュメントには tenantId フィールドが必要で、すべてのデータベースクエリはそのフィールドでフィルタリングする必要があります。アプリケーション レベルでセキュリティを管理する必要があります。

長期的にはスケーリングの問題が発生するかもしれません。実行するメンテナンスは、すべてのテナントに同時に影響します。このアプローチは同じ規模の多数の小規模テナントには適していますが、テナントの規模が異なる場合には適していません。また、テナントごとに設定をカスタマイズするのが難しい場合もあります。

1 つのデータベースに登録され、独自のコレクションを持つすべてのテナント

独自のコレクションを持つすべてのテナントを単一のデータベースに配置することは避けてください。このアプローチはカスタマイズの問題を防止しますが、アプリケーションのコーディングが複雑になり、長期的にはスケーリングの問題が悪化します。