멀티테넌트 아키텍처 구축

자체 데이터베이스의 각 테넌트

테넌트의 수가 적고 안정적이며(최대 수백 명) 데이터 요구 사항이 다양하고 액세스 제어 요건이 엄격한 경우, 테넌트당 하나의 데이터베이스를 만드는 것이 좋습니다.

이 접근 방식에는 다음과 같은 이점이 있습니다.

• 보안을 강화하기 위해 데이터베이스 사용자가 테넌트 데이터 액세스를 제한할 수 있습니다. Atlas는 기본적으로 프로젝트당 데이터베이스 사용자를 100명으로 제한합니다.

• 테넌트 전반의 가변 데이터 구조에 대해 고유한 액세스 패턴을 설명하려면 인덱싱을 설정할 수 있습니다.

• 단일 테넌트를 자체 전용 리소스로 이동하려면 전체 테넌트의 격리된 데이터를 새 리소스(예: 다른 cluster)로 마이그레이션하거나 확장할 수 있습니다.

다음과 같은 경우를 생각해 보세요.

• 애플리케이션 계층에 더 많은 복잡성을 추가합니다.

• 테넌트 간에 중복 컬렉션과 인덱스를 보유할 수 있습니다.

• 단일 클러스터에서 대규모로 문제가 발생하는 경우. 각각의 새 컬렉션과 인덱스에 필요한 기본 데이터 파일은 계산 리소스를 소비합니다.

각 테넌트는 동일한 클러스터에 자체 논리적 데이터베이스를 갖고 있습니다. 이 접근 방식을 사용하면 쉽게 사용자 정의하고 강력한 보안을 구현할 수 있습니다. 다른 테넌트에 영향을 주지 않고 한 테넌트에 대한 백업 및 유지 관리 작업을 수행할 수 있습니다.

그러나 이 접근 방식은 설정 작업에 드는 노력과 필요한 컴퓨팅 리소스를 증가시킬 수 있습니다. 테넌트 간의 상호 작용에는 여러 데이터베이스에 대한 연결이 필요합니다. 일부 MongoDB 명령은 동일한 데이터베이스의 컬렉션 간에만 작동합니다.

각 collection과 인덱스는 디스크에 별도의 파일로 저장되는데, 이로 인해 열려 있는 파일 수가 상당히 많고 메모리 사용량이 많아질 수 있습니다. 이 문제를 해결하려면 노드당 데이터 파일 1000개 미만(collection 및 개별 인덱스)을 사용합니다. 자세히 보려면 Collection and Index Limits 참조합니다.

공유 컬렉션이 있는 단일 데이터베이스의 모든 테넌트

테넌트 수가 무한정 증가할 것으로 예상되고, 데이터 구조 및 쿼리 요구 사항이 테넌트 간에 비교적 일관되며, 액세스 제어 요구 사항이 덜 엄격한 경우에는 모든 테넌트에 대해 공유 컬렉션이 있는 단일 데이터베이스를 사용하는 것이 좋습니다.

이 접근 방식에는 다음과 같은 이점이 있습니다.

• 확장성이 뛰어납니다(예:클러스터를 샤딩할 수 있습니다).

• 지속적인 유지 관리를 단순화합니다(예: 새로운 쿼리 패턴에 대해 인덱싱합니다).

다음과 같은 잠재적인 문제를 고려하세요.

• 단일 데이터베이스 사용자가 이 대규모 멀티 테넌트 데이터 풀에 액세스할 수 있습니다.

• 데이터 세분화는 전적으로 논리적이며 애플리케이션 계층에서 시행되어야 합니다.

테넌트는 모두 collection 전체에서 문서를 보유할 수 있습니다. 멀티 테넌시 로직은 용도 계층에 있습니다. 모든 문서에는 tenantId 필드가 있어야 하며, 모든 데이터베이스 쿼리는 해당 필드를 기준으로 필터링해야 합니다. 용도 수준에서 보안을 관리해야 합니다.

장기적으로 확장 문제가 발생할 수 있습니다. 모든 유지 관리 작업은 모든 테넌트에 동시에 영향을 미칩니다. 이 접근 방식은 규모가 같은 소규모 테넌트가 많은 경우에는 잘 적용되지만, 테넌트 규모가 다양한 경우에는 잘 적용되지 않습니다. 또한 각 테넌트에 대한 설정을 사용자 지정하는 것이 어려울 수도 있습니다.

단일 데이터베이스에 자체 컬렉션이 있는 모든 테넌트

자체 컬렉션이 있는 모든 테넌트를 단일 데이터베이스에 넣지 않아야 합니다. 이 접근 방식은 사용자 지정 문제를 방지할 수 있지만 애플리케이션 코딩이 복잡해지고 장기적으로는 확장 문제를 악화시킵니다.