다중 테넌트 SaaS 데이터베이스 테넌시 패턴
적용 대상: 
Azure SQL Database
이 문서에서는 다중 테넌트 SaaS 애플리케이션에 사용할 수 있는 다양한 테넌트 모델을 설명합니다.
다중 테넌트 SaaS 애플리케이션을 디자인할 때 여러분의 애플리케이션에 가장 잘 맞는 테넌시 모델을 신중하게 선택해야 합니다. 테넌시 모델은 각 테넌트의 데이터가 스토리지에 매핑되는 방식을 결정합니다. 선택한 테넌트 모델은 애플리케이션 디자인 및 관리에 영향을 줍니다. 나중에 다른 모델로 전환하는 것은 비용이 많이 드는 경우가 있습니다.
A. SaaS 개념 및 용어
SaaS(Software as a Service) 모델에서 회사는 소프트웨어에 대한 라이선스를 판매하지 않습니다. 대신, 각 고객은 회사에 임대료를 지불하여 각 고객을 회사의 테넌트로 만듭니다.
임대료를 지불하는 대가로 각 테넌트는 SaaS 애플리케이션 구성 요소에 대한 액세스를 받고 해당 데이터가 SaaS 시스템에 저장됩니다.
테넌시 모델이라는 용어는 테넌트의 저장된 데이터를 구성하는 방법을 나타냅니다.
- 단일-테넌트: 각 데이터베이스는 한 테넌트의 데이터만을 저장합니다.
- 다중 테넌트: 각 데이터베이스는 (데이터 개인 정보를 보호하는 메커니즘을 사용하여) 별도 다중 테넌트의 데이터를 저장합니다.
- 하이브리드 테넌시 모델도 사용할 수 있습니다.
B. 적절한 테넌시 모델을 선택하는 방법
일반적으로 테넌트 모델은 애플리케이션의 기능에 영향을 주지 않지만 전체 솔루션의 다른 측면에 영향을 줄 수 있습니다. 다음 조건은 각 모델을 평가하는 데 사용됩니다.
확장성:
- 테넌트의 수
- 테넌트당 저장소
- 스토리지 집계
- 워크로드
테넌트 격리: 데이터 격리 및 성능(한 테넌트의 워크로드가 다른 테넌트에 영향을 주는지 여부)
테넌트당 비용: 데이터베이스 비용
개발 복잡성:
- 스키마 변경
- 쿼리 변경 내용(패턴에 필요).
운영 복잡성
- 성능 모니터링 및 관리
- 스키마 관리,
- 테넌트 복원
- 재해 복구.
사용자 지정 가능성: 테넌트 관련 또는 테넌트 클래스 관련 스키마 사용자 지정에 대한 지원 용이성
테넌시 토론은 데이터 계층에 초점을 맞췄습니다. 그러나 한편 애플리케이션 계층을 고려합니다. 애플리케이션 계층은 모놀리식 엔터티로 처리됩니다. 애플리케이션을 여러 개의 작은 구성 요소로 나누는 경우 선택한 테넌트 모델이 변경될 수 있습니다. 일부 구성 요소는 테넌트 및 사용된 스토리지 기술 또는 플랫폼에 대해 다른 구성 요소와 다르게 처리할 수 있습니다.
C. 단일 테넌트 데이터베이스를 사용하는 독립 실행형 단일 테넌트 앱
애플리케이션 수준 격리
이 모델에서 전체 애플리케이션은 각 테넌트에 대해 한 번씩 반복적으로 설치됩니다. 앱의 각 인스턴스는 독립 실행형 인스턴스이므로 다른 독립 실행형 인스턴스와 상호 작용하지 않습니다. 앱의 각 인스턴스에는 하나의 테넌트만 있으므로 하나의 데이터베이스만 필요합니다. 테넌트에는 데이터베이스 자체가 모두 있습니다.
각 앱 인스턴스는 별도 Azure 리소스 그룹에 설치됩니다. 소프트웨어 공급업체 또는 테넌트가 리소스 그룹을 소유하는 구독을 소유할 수 있습니다. 테넌트가 소유한 구독에 속할 수 있습니다. 두 경우 모두 공급업체는 테넌트에 대한 소프트웨어를 관리할 수 있습니다. 각 애플리케이션 인스턴스는 해당 데이터베이스에 연결하도록 구성됩니다.
각 테넌트 데이터베이스는 단일 데이터베이스로 배포됩니다. 이 모델은 가장 큰 데이터베이스 격리를 제공합니다. 그러나 격리를 위해서는 최대 부하를 처리하기 위해 각 데이터베이스에 충분한 리소스를 할당해야 합니다. 다른 리소스 그룹이나 다른 구독에 배포된 데이터베이스에 탄력적 풀을 사용할 수 없다는 점도 중요합니다. 이러한 제한으로 인해 이 독립 실행형 단일 테넌트 앱 모델은 전체 데이터베이스 비용 관점에서 가장 비용이 많이 드는 솔루션입니다.
공급업체 관리
공급업체는 앱 인스턴스가 다른 테넌트 구독에 설치된 경우에도 모든 독립 실행형 앱 인스턴스의 모든 데이터베이스에 액세스할 수 있습니다. 액세스는 SQL 연결을 통해 수행됩니다. 이 인스턴스 간 액세스를 통해 공급업체는 보고 또는 분석을 위해 스키마 관리 및 데이터베이스 간 쿼리를 중앙 집중화할 수 있습니다. 이러한 종류의 중앙 집중식 관리를 원하는 경우 테넌트 식별자를 데이터베이스 URI(유니폼 리소스 식별자)에 매핑하는 카탈로그를 배포해야 합니다. Azure SQL Database는 카탈로그를 제공하기 위해 함께 사용되는 분할 라이브러리를 제공합니다. 분할 라이브러리는 공식 명칭이 탄력적 데이터베이스 클라이언트 라이브러리입니다.
D. 테넌트별 데이터베이스가 있는 다중 테넌트 앱
이러한 다음 패턴은 모두 단일 테넌트 데이터베이스에 해당하는 많은 데이터베이스를 포함하는 다중 테넌트 애플리케이션을 사용합니다. 새 데이터베이스는 각 새 테넌트에 대해 프로비전됩니다. 애플리케이션 계층은 노드당 더 많은 리소스를 추가하여 수직으로 확장됩니다. 또는 더 많은 노드를 추가하여 앱이 수평으로 확장됩니다. 크기 조정은 워크로드를 기반으로 하며 개별 데이터베이스의 수 또는 규모와는 독립적입니다.
테넌트에 대한 사용자 지정
독립 실행형 앱 패턴과 마찬가지로 단일 테넌트 데이터베이스를 사용하면 강력한 테넌트 격리가 이루어집니다. 해당 모델이 단일 테넌트 데이터베이스만 지정하는 앱에서는 해당 데이터베이스에 대한 스키마를 테넌트에 맞게 사용자 지정하고 최적화할 수 있습니다. 이 사용자 지정은 앱의 다른 테넌트에 영향을 주지 않습니다. 테넌트는 모든 테넌트에 필요한 기본 데이터 필드 이외의 데이터가 필요할 수 있습니다. 또한 추가 데이터 필드에는 인덱스가 필요할 수 있습니다.
테넌트당 데이터베이스를 사용하면 하나 이상의 개별 테넌트에 대한 스키마를 사용자 지정하는 것이 간단합니다. 애플리케이션 공급업체는 대규모 스키마 사용자 지정을 신중하게 관리하기 위한 절차를 설계해야 합니다.
탄력적 풀
데이터베이스가 동일한 리소스 그룹에 배포되면 탄력적 풀로 그룹화할 수 있습니다. 풀은 여러 데이터베이스에서 리소스를 공유하는 비용 효율적인 방법을 제공합니다. 이러한 풀 옵션은 발생하는 최대 사용량을 수용할 수 있을 만큼, 각 데이터베이스를 크게 유지하는 것보다 더 저렴한 방법입니다. 풀된 데이터베이스는 리소스에 대한 액세스를 공유하지만 높은 수준의 성능 격리를 달성할 수 있습니다.
Azure SQL Database는 공유를 구성, 모니터링 및 관리하는 데 필요한 도구를 제공합니다. 풀 수준 및 데이터베이스 수준의 성능 메트릭은 Azure Portal 및 Azure Monitor 로그를 통해 사용할 수 있습니다. 메트릭은 집계 및 테넌트별 성능 모두에 대한 훌륭한 인사이트를 제공할 수 있습니다. 개별 데이터베이스를 풀 간에 이동하여 예약된 리소스를 특정 테넌트에 제공할 수 있습니다. 이러한 도구를 사용하여 비용 효율적인 방식으로 좋은 성능을 보장할 수 있습니다.
테넌당 데이터베이스의 작업 규모 조정
Azure SQL Database에는 100,000개가 넘는 데이터베이스와 같은 대규모 데이터베이스를 관리하도록 설계된 많은 관리 기능이 있습니다. 이러한 기능은 테넌트당 데이터베이스 패턴을 그럴듯하게 만듭니다.
예를 들어 시스템에 1000개 테넌트 데이터베이스가 유일한 데이터베이스라고 가정합니다. 데이터베이스에 20개의 인덱스가 있을 수 있습니다. 시스템이 단일 테넌트 데이터베이스를 1,000개로 변환하는 경우 인덱스 수량은 20,000으로 증가합니다. 자동 튜닝의 일부로 Azure SQL Database에서 자동 인덱싱 기능을 기본적으로 사용하도록 설정됩니다. 자동 인덱싱은 20,000개의 모든 인덱스와 지속적인 만들기 및 삭제 최적화를 관리합니다. 이러한 자동화된 작업은 개별 데이터베이스 내에서 발생하며 다른 데이터베이스의 유사한 작업에 의해 조정되거나 제한되지 않습니다. 자동 인덱싱은 사용량이 적은 데이터베이스와 사용 중인 데이터베이스에서 인덱스를 다르게 처리합니다. 이 대규모 관리 작업을 수동으로 수행해야 하는 경우 이러한 유형의 인덱스 관리 사용자 지정은 테넌트당 데이터베이스 규모에서 실용적이지 않습니다.
잘 스케일링되는 기타 관리 기능에는 다음이 포함되었습니다.
- 기본 제공 백업
- 고가용성.
- 디스크 암호화
- 성능 원격 분석
Automation
관리 작업은 devops 모델을 통해 스크립팅하고 제공할 수 있습니다. 애플리케이션에서 작업을 자동화하고 노출할 수도 있습니다.
예를 들어 단일 테넌트를 이전 시점으로 복구하는 것을 자동화할 수 있습니다. 복구는 테넌트만 저장하는 단일 테넌트 데이터베이스를 복원해야 합니다. 이 복원은 관리 작업이 각 개별 테넌트의 세분화된 수준에 있음을 확인하는 다른 테넌트에 영향을 주지 않습니다.
E. 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱
사용 가능한 또 다른 패턴은 다중 테넌트 데이터베이스에 여러 테넌트를 저장하는 것입니다. 애플리케이션 인스턴스에는 여러 개의 다중 테넌트 데이터베이스가 있을 수 있습니다. 다중 테넌트 데이터베이스의 스키마에는 지정된 테넌트에서 데이터를 선택적으로 검색할 수 있도록 하나 이상의 테넌트 식별자 열이 있어야 합니다. 또한 스키마에 일부 테넌트에서만 사용되는 소수의 테이블이나 열이 필요할 수도 있습니다. 그러나 정적 코드 및 참조 데이터는 한 번만 저장되고 모든 테넌트에서 공유됩니다.
테넌트 격리가 희생됨
데이터: 다중 테넌트 데이터베이스를 사용하게 되면 테넌트 격리 효과가 떨어질 수밖에 없습니다. 여러 테넌트 데이터는 하나의 데이터베이스에 함께 저장됩니다. 개발하는 동안 쿼리가 둘 이상의 테넌트에서 데이터를 노출하지 않도록 합니다. SQL Database는 쿼리에서 반환된 데이터 범위가 단일 테넌트로 지정될 수 있게 행 수준 보안을 지원합니다.
처리: 다중 테넌트 데이터베이스는 모든 테넌트에서 컴퓨팅 및 스토리지 리소스를 공유합니다. 데이터베이스 전체를 모니터링하여 데이터베이스가 허용 가능한 성능을 발휘하는지 확인할 수 있습니다. 그러나 Azure 시스템은 개별 테넌트에서 이러한 리소스의 사용을 모니터링하거나 관리하는 기본 제공 방법이 없습니다. 따라서 다중 테넌트 데이터베이스는 시끄러운 인접 항목이 발생할 위험이 증가합니다. 여기서 한 과활성 테넌트의 워크로드는 동일한 데이터베이스에 있는 다른 테넌트의 성능 환경에 영향을 줍니다. 더 많은 애플리케이션 수준 모니터링은 테넌트 수준 성능을 모니터링할 수 있습니다.
비용 절감
일반적으로 다중 테넌트 데이터베이스는 테넌트당 비용이 가장 낮습니다. 단일 데이터베이스의 리소스 비용은 동일한 크기의 탄력적 풀보다 낮습니다. 또한 테넌트에 제한된 스토리지만 필요한 시나리오의 경우 잠재적으로 수백만 개의 테넌트를 단일 데이터베이스에 저장할 수 있습니다. 탄력적 풀에는 수백만 개의 데이터베이스가 포함될 수 없습니다. 그러나 풀당 1,000개의 데이터베이스를 포함하는 솔루션에는 1,000개의 풀이 있으며 관리가 어려울 위험이 있는 수백만 개의 규모에 도달할 수 있습니다.
다중 테넌트 데이터베이스 모델의 두 가지 변형은 다음에 설명되며, 분할된 다중 테넌트 모델은 가장 유연하고 확장 가능합니다.
F. 단일 다중 테넌트 데이터베이스가 포함된 다중 테넌트 앱
가장 간단한 다중 테넌트 데이터베이스 패턴은 단일 데이터베이스를 사용하여 모든 테넌트에 대한 데이터를 호스트합니다. 더 많은 테넌트가 추가되면 더 많은 스토리지 및 컴퓨팅 리소스로 데이터베이스가 확장됩니다. 이 강화에는 항상 궁극적인 확장 제한이 존재하지만 제한 수준이 필요한 것을 충족할 수 있습니다. 그러나 해당 제한에 도달하기 훨씬 전에 데이터베이스는 관리하기 어려워집니다.
개별 테넌트에 초점을 맞춘 관리 작업은 다중 테넌트 데이터베이스에서 구현하는 것이 더 복잡합니다. 그리고 대규모로 이러한 작업을 하는 경우 기다릴 수 없을 정도로 느려질 수 있습니다. 한 테넌트만을 대상으로 하는 데이터의 지정 시간 복원을 그 예로 들 수 있습니다.
G. 샤딩된 멀티테넌트 데이터베이스를 사용하는 다중 테넌트 앱
대부분의 SaaS 애플리케이션은 한 번에 한 테넌트의 데이터에만 액세스합니다. 이 액세스 패턴을 사용하면 테넌트 데이터를 여러 데이터베이스 또는 분할된 데이터베이스에 분산할 수 있습니다. 여기서 하나의 테넌트에 대한 모든 데이터가 하나의 분할된 데이터베이스에 포함됩니다. 다중 테넌트 데이터베이스 패턴과 분할 모델을 함께 사용하면 거의 무제한으로 확장할 수 있게 됩니다.
분할 관리
분할은 디자인 및 운영 관리에 복잡성을 더합니다. 테넌트와 데이터베이스 간에 매핑을 유지 관리할 카탈로그가 필요합니다. 또한 분할된 데이터베이스 및 테넌트 채우기를 관리하려면 관리 절차가 필요합니다. 예를 들어, 분할된 데이터베이스를 추가 및 이동하고 분할된 데이터베이스 간에 테넌트 데이터를 이동하기 위한 절차를 계획해야 합니다. 크기를 조정하는 한 가지 방법은 새 분할된 데이터베이스를 추가하고 새 테넌트로 채우는 것입니다. 다른 시간에는 밀도가 낮은 분할된 데이터베이스를 밀도가 낮은 두 분할된 데이터베이스로 분할할 수 있습니다. 여러 테넌트가 이동되거나 사용이 중단된 후에 부분적으로 채워진 분할된 데이터베이스를 함께 병합할 수 있습니다. 병합하면 리소스 사용률이 비용 효율적으로 높아집니다. 또한 분할된 데이터베이스 간에 테넌트를 이동하여 작업 부하를 분산할 수도 있습니다.
SQL 데이터베이스는 분할 라이브러리 및 카탈로그 데이터베이스와 함께 작동하는 분할/병합 도구를 제공합니다. 제공된 앱은 분할된 데이터베이스를 분할 및 병합할 수 있으며 분할된 데이터베이스 간에 테넌트 데이터를 이동할 수 있습니다. 또한 앱은 이러한 작업 중에 카탈로그를 기본 영향을 받는 테넌트를 이동하기 전에 오프라인으로 표시합니다. 이동 후 앱은 새 매핑을 사용하여 카탈로그를 다시 업데이트하고 테넌트가 다시 온라인 상태로 표시합니다.
더 작은 데이터베이스를 보다 쉽게 관리
분할된 다중 테넌트 솔루션은 테넌트를 여러 데이터베이스에 걸쳐 분산하여 관리가 보다 용이한 더 작은 데이터베이스가 생성됩니다. 예를 들어 특정 테넌트를 이전 시점으로 복원하려면 이제 모든 테넌트를 포함하는 더 큰 데이터베이스가 아닌 백업에서 단일 작은 데이터베이스를 복원해야 합니다. 데이터베이스 크기 및 데이터베이스당 테넌트 수를 선택하여 워크로드와 관리 작업의 균형을 맞출 수 있습니다.
스키마의 테넌트 식별자
사용되는 분할 방법에 따라 데이터베이스 스키마에 추가적인 제약 조건이 적용될 수 있습니다. SQL Database 분할/병합 애플리케이션을 사용하려면 스키마에 일반적으로 테넌트 식별자인 분할 키가 포함되어야 합니다. 테넌트 식별자는 모든 분할된 테이블의 기본 키 맨 앞에 나오는 요소입니다. 테넌트 식별자를 사용하여 분할/병합 애플리케이션은 특정 테넌트와 연결된 데이터를 빠르게 찾아서 이동할 수 있습니다.
분할된 데이터베이스에 대한 탄력적 풀
분할된 다중 테넌트 데이터베이스는 탄력적 풀에 배치할 수 있습니다. 일반적으로 하나의 풀에 많은 단일 테넌트 데이터베이스를 둘 경우 소스의 다중 테넌트 데이터베이스에 많은 테넌트를 두는 것보다 비용 효율적입니다. 다중 테넌트 데이터베이스는 비교적 덜 활동적인 테넌트가 많이 있을 때 더 유용합니다.
H. 하이브리드 분할된 다중 테넌트 데이터베이스 모델
하이브리드 모델에서는 모든 데이터베이스의 스키마에 테넌트 식별자가 있습니다. 데이터베이스는 모두 둘 이상의 테넌트 저장이 가능하며 데이터베이스를 분할할 수 있습니다. 따라서 스키마 관점에서 보면 모두가 다중 테넌트 데이터베이스입니다. 그러나 실제로 이러한 데이터베이스 중 일부는 하나의 테넌트만 포함합니다. 관계없이 지정된 데이터베이스에 저장된 테넌트 수량은 데이터베이스 스키마에 영향을 주지 않습니다.
테넌트 이동
언제든지 특정 테넌트를 자체 다중 테넌트 데이터베이스로 이동할 수 있습니다. 언제든지 마음을 바꾸고 테넌트를 여러 테넌트가 포함된 데이터베이스로 다시 이동할 수 있습니다. 새 데이터베이스를 프로비전할 때 새 단일 테넌트 데이터베이스에 테넌트를 할당할 수도 있습니다.
하이브리드 모델은 식별 가능한 테넌트 그룹의 리소스 요구량이 큰 차이를 보일 때 특히 유용합니다. 예를 들어 무료 평가판에 참여하는 테넌트가 테넌트를 구독하는 것과 동일한 높은 수준의 성능을 보장하지 않는다고 가정합니다. 이 정책은 평가판 단계의 테넌트가 모든 평가판 테넌트 간에 공유되는 다중 테넌트 데이터베이스에 저장될 수 있습니다. 평가판 테넌트가 기본 서비스 계층을 구독하는 경우 테넌트는 테넌트 수가 적을 수 있는 다른 다중 테넌트 데이터베이스로 이동할 수 있습니다. 프리미엄 서비스 계층 비용을 지불하는 구독자는 자체적인 새 단일 테넌트 데이터베이스로 이동될 수 있습니다.
풀
이 하이브리드 모델에서 구독자 테넌트용 단일 테넌트 데이터베이스를 리소스 풀에 배치하여 테넌트별 데이터베이스 비용을 줄일 수 있습니다. 이 작업은 테넌트별 데이터베이스 모델에서도 수행됩니다.
I. 테넌시 모델 비교
다음 표에는 주요 테넌시 모델 간의 차이점이 요약되어 있습니다.
| 측정 | 독립 실행형 앱 | 테넌트당 데이터베이스 | 분할된 다중 테넌트: |
|---|---|---|---|
| Scale | 보통 (1-100s) | 높음 (1-100,000s) | 무제한 (1-1,000,000s) |
| 테넌트 격리 | 높음 | 높음 | 낮음, 단일 테넌트의 경우는 예외입니다(MT 데이터베이스에만 단독으로 존재하는 경우). |
| 테넌트별 데이터베이스 비용 | 높은; 최대 크기로 조정됩니다. | 낮은; 풀 사용 중 | 가장 낮음, MT 데이터베이스의 소규모 테넌트용. 리소스 그룹을 소유합니다. |
| 성능 모니터링 및 관리 | 테넌트별로 구분되는 경우만 해당 | 집계 + 테넌트당 | 집계. 단일 항목에 대해서만 테넌트별로 구분됩니다. |
| 개발 복잡성 | 낮음 | 낮음 | 중간, 분할로 야기됩니다. |
| 운영 복잡성 | 낮은-높음. 개별적으로는 단순하고 전체적으로는 복잡합니다. | 낮은-중간. 패턴은 대규모로 복잡성을 해결합니다. | 낮은-높음. 개별 테넌트 관리가 복잡합니다. |