다중 테넌트 SaaS 데이터베이스 테넌시 패턴

적용 대상: Azure SQL Database

이 문서에서는 다중 테 넌 트 SaaS 응용 프로그램에 사용할 수 있는 다양 한 테 넌 트 모델을 설명 합니다.

다중 테넌트 SaaS 애플리케이션을 디자인할 때 애플리케이션의 요구에 가장 잘 맞는 테넌시 모델을 신중하게 선택해야 합니다. 테 넌 시 모델은 각 테 넌 트의 데이터가 저장소에 매핑되는 방식을 결정 합니다. 선택한 테넌시 모델은 애플리케이션 디자인 및 관리에 영향을 줍니다. 나중에 다른 모델로 전환하려고 하면 비용이 많이 들 수도 있습니다.

A. SaaS 개념 및 용어

Saas(Software as a Service) 모델에서 회사는 소프트웨어에 대한 라이선스 를 판매하지 않습니다. 대신 각 고객은 회사에 임대료를 지불하여 각 고객을 회사의 테넌트 로 만듭니다.

각 테넌트는 임대료를 지불하는 대가로 SaaS 애플리케이션 구성 요소에 대한 액세스 권한을 받고, SaaS 시스템에 해당 데이터를 저장합니다.

테넌트 모델 이라는 용어는 테넌트의 저장된 데이터가 구성되는 방법을 가리킵니다.

  • 단일 테 넌 트:   각 데이터베이스는 하나의 테 넌 트 에서만 데이터를 저장 합니다.
  • 다중 테 넌 트:   각 데이터베이스는 데이터 개인 정보 보호를 위한 메커니즘을 사용 하 여 여러 개별 테 넌 트의 데이터를 저장 합니다.
  • 하이브리드 테넌트 모델도 사용할 수 있습니다.

B. 적절한 테넌시 모델을 선택하는 방법

일반적으로 테넌시 모델은 애플리케이션의 기능에 영향을 주지 않지만 전체 솔루션의 다른 측면에 영향을 주기 쉽습니다. 각 모델을 평가하는 데 다음 기준이 사용됩니다.

  • 향상

    • 테넌트의 수
    • 테넌트당 스토리지
    • 집계한 스토리지
    • 워크로드
  • 테 넌 트 격리:   데이터 격리 및 성능 (한 테 넌 트의 워크 로드가 다른 테 넌 트에 영향을 주는지 여부)

  • 테 넌 트 당 비용:   데이터베이스 비용.

  • 개발 복잡성:

    • 스키마 변경 내용
    • 쿼리 변경 내용(패턴에 필요)
  • 운영 복잡성:

    • 성능 모니터링 및 관리
    • 스키마 관리입니다.
    • 테넌트 복원
    • 재해 복구
  • 사용자 지정 가능성:   테 넌 트 특정 또는 테 넌 트 클래스 전용의 지원 스키마 사용자 지정의 용이성

테넌시 관련 논의는 데이터 계층에 중점을 둡니다. 그렇지만 잠시 동안 애플리케이션 계층을 생각해보세요. 애플리케이션 계층은 단일 엔터티로 취급됩니다. 애플리케이션을 많은 작은 구성 요소로 나눌 경우 선택하는 테넌시 모델이 달라질 수 있습니다. 테넌시와 사용되는 스토리지 기술 또는 플랫폼을 고려해서 일부 구성 요소를 다른 구성 요소와 다르게 취급할 수 있습니다.

C. 단일 테넌트 데이터베이스를 포함하는 독립 실행형 단일 테넌트 앱

애플리케이션 수준 격리

이 모델에서는 전체 애플리케이션이 각 테넌트에 한 번씩 반복해서 설치됩니다. 앱의 각 인스턴스는 독립 실행형 인스턴스이므로 다른 독립 실행형 인스턴스와 상호 작용하지 않습니다. 앱의 각 인스턴스에는 테넌트가 1개만 있으므로 데이터베이스가 1개만 필요합니다. 테넌트에는 자체 데이터베이스가 있습니다.

정확히 하나의 단일 테넌트 데이터베이스가 있는 독립 실행형 앱 디자인

각 앱 인스턴스는 별도 Azure 리소스 그룹에 설치됩니다. 리소스 그룹은 소프트웨어 공급업체 또는 테넌트에서 소유한 구독에 속할 수 있습니다. 두 경우 모두 공급업체는 테넌트의 소프트웨어를 관리할 수 있습니다. 각 애플리케이션 인스턴스는 해당 데이터베이스에 연결되도록 구성됩니다.

각 테넌트 데이터베이스는 단일 데이터베이스로 배포됩니다. 이 모델은 가장 큰 데이터베이스 격리를 제공합니다. 하지만 격리를 위해서는 각 데이터베이스에 최대 부하를 처리하기 위한 충분한 리소스가 할당되어야 합니다. 다른 리소스 그룹이나 다른 구독에 배포된 데이터베이스에 탄력적 풀을 사용할 수 없다는 점도 중요합니다. 이러한 제한으로 인해 이 독립 실행형 단일 테넌트 앱은 전체적인 데이터베이스 비용 관점에서 가장 비싼 솔루션을 모델링하게 됩니다.

공급업체 관리

공급업체는 앱 인스턴스가 다른 테넌트 구독에 설치된 경우에도 모든 독립 실행형 앱 인스턴스의 모든 데이터베이스에 액세스할 수 있습니다. 이러한 액세스는 SQL 연결을 통해 구현됩니다. 이 인스턴스 간 액세스를 통해 공급업체는 스키마 관리와 보고 또는 분석을 위한 데이터베이스 간 쿼리를 중앙 집중식으로 관리할 수 있습니다. 이러한 종류의 중앙 집중식 관리가 필요한 경우 데이터베이스 URI에 테넌트 식별자를 매핑하는 카탈로그를 배포해야 합니다. Azure SQL Database는 카탈로그를 제공 하는 데 함께 사용 되는 분할 라이브러리를 제공 합니다. 분할 라이브러리는 공식 명칭이 Elastic Database 클라이언트 라이브러리입니다.

D. 테넌트별 데이터베이스가 있는 다중 테넌트 앱

이러한 다음 패턴은 모두 단일 테넌트 데이터베이스에 해당하는 많은 데이터베이스를 포함하는 다중 테넌트 애플리케이션을 사용합니다. 새 데이터베이스는 각 새로운 테넌트용으로 프로비전됩니다. 애플리케이션 계층의 경우 노드당 더 많은 리소스를 추가하여 수직으로 규모를 확장 합니다. 또는 노드를 더 추가하여 앱을 수평으로 스케일 아웃 합니다. 크기 조정은 워크로드를 기준으로 하며, 개별 데이터베이스의 수나 크기와는 별개입니다.

테넌트별 데이터베이스가 있는 다중 테넌트 앱 디자인

테넌트에 맞게 사용자 지정

독립 실행형 앱 패턴처럼 단일 테넌트 데이터베이스를 사용하면 강력한 테넌트 격리가 구현됩니다. 해당 모델이 단일 테넌트 데이터베이스만 지정하는 앱에서는 해당 데이터베이스에 대한 스키마를 테넌트에 맞게 사용자 지정하고 최적화할 수 있습니다. 이 사용자 지정은 앱의 다른 테넌트에 영향을 주지 않습니다. 모든 테넌트에 필요한 기본 데이터 필드 이외의 데이터가 테넌트에 필요할 수도 있습니다. 또한 추가 데이터 필드에 인덱스가 필요할 수도 있습니다.

테넌트별 데이터베이스를 사용하면 하나 이상의 개별 테넌트에 대한 스키마를 쉽게 사용자 지정할 수 있습니다. 애플리케이션 공급업체는 스키마 사용자 지정을 전반적으로 신중하게 관리하기 위한 절차를 디자인해야 합니다.

탄력적 풀

같은 리소스 그룹에 배포되는 데이터베이스는 탄력적 풀로 그룹화할 수 있습니다. 풀은 많은 데이터베이스에서 리소스를 공유하는 비용 효율적인 방법을 제공합니다. 이러한 풀 옵션은 발생하는 최대 사용량을 수용할 수 있을 만큼, 각 데이터베이스를 크게 유지하는 것보다 더 저렴한 방법입니다. 풀링된 데이터베이스는 리소스에 대한 액세스를 공유하지만 높은 수준의 성능 격리를 달성할 수 있습니다.

탄력적 풀을 사용하여 테넌트별 데이터베이스가 있는 다중 테넌트 앱 디자인

Azure SQL Database는 공유를 구성, 모니터링 및 관리하는 데 필요한 도구를 제공합니다. 풀 수준 및 데이터베이스 수준 성능 메트릭은 Azure Portal 및 Azure Monitor 로그를 통해 사용할 수 있습니다. 이러한 메트릭을 통해 집계 및 테넌트별 성능을 보다 잘 이해할 수 있습니다. 개별 데이터베이스를 풀 간에 이동하여 특정 테넌트에 예약된 리소스를 제공할 수 있습니다. 이러한 도구를 사용하여 비용 효율적인 방식으로 좋은 성능을 보장할 수 있습니다.

테넌당 데이터베이스의 작업 규모 조정

Azure SQL Database에는 10만 개 이상의 데이터베이스와 같이 대규모 데이터베이스를 대규모로 관리 하도록 설계 된 많은 관리 기능이 있습니다. 이러한 기능은 테넌트별 데이터베이스 패턴을 적절히 지원합니다.

예를 들어, 시스템에 1000 테넌트 데이터베이스가 유일한 데이터베이스로 사용된다고 가정합니다. 이 데이터베이스에는 20개의 인덱스가 있을 수 있습니다. 시스템이 1000개의 단일 테넌트 데이터베이스를 포함하는 방식으로 변환될 경우 인덱스 수는 20,000개로 증가합니다. 자동 조정의 일부로 Azure SQL Database 자동 인덱싱 기능이 기본적으로 사용 하도록 설정 되어 있습니다. 자동 인덱싱은 20,000개의 모든 인덱스와 지속적인 생성 및 삭제 최적화를 자동으로 관리합니다. 이러한 자동화된 작업은 개별 데이터베이스 내에서 발생하며 다른 데이터베이스의 비슷한 작업에 따라 조정되거나 제한되지 않습니다. 자동 인덱싱은 덜 바쁜 데이터베이스와 바쁜 데이터베이스에서 인덱스를 다르게 처리합니다. 이러한 방대한 관리 작업을 수동으로 처리해야 한다면 테넌트별 데이터베이스 수준에서 이러한 유형의 인덱스 관리 사용자 지정을 수행하는 것은 비현실적인 일일 것입니다.

잘 확장되는 다른 관리 기능은 다음과 같습니다.

  • 기본 제공 백업
  • 고가용성.
  • 디스크 암호화
  • 성능 원격 분석

Automation

관리 작업은 devops 모델을 통해 스크립팅하고 제공할 수 있습니다. 애플리케이션에서도 작업을 자동화하고 노출할 수 있습니다.

예를 들어, 이전 시점으로의 단일 테넌트 복구를 자동화할 수 있습니다. 테넌트를 저장하는 하나의 단일 테넌트 데이터베이스만 복원하면 복구가 이루어집니다. 이 복원이 다른 테넌트에는 영향을 미치지 않으며, 관리 작업은 각 개별 테넌트의 정밀하게 세분화된 수준에서 진행될 수 있습니다.

E. 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱

사용 가능한 또 다른 패턴은 다중 테넌트 데이터베이스에 여러 테넌트를 저장하는 것입니다. 애플리케이션 인스턴스는 제한 없는 수의 다중 테넌트 데이터베이스를 포함할 수 있습니다. 다중 테넌트 데이터베이스의 스키마에는 특정 테넌트의 데이터를 선택적으로 검색할 수 있도록 하나 이상의 테넌트 식별자 열이 있어야 합니다. 또한 스키마에 일부 테넌트에서만 사용되는 소수의 테이블이나 열이 필요할 수도 있습니다. 그러나 정적 코드 및 참조 데이터는 한 번만 저장된 후 모든 테넌트에서 공유됩니다.

테넌트 격리 효과는 제한됩니다.

데이터:   다중 테 넌 트 데이터베이스는 테 넌 트 격리를 반드시 sacrifices 합니다. 다중 테넌트의 데이터는 하나의 데이터베이스에 함께 저장됩니다. 개발 중에 쿼리가 둘 이상의 테넌트에 있는 데이터를 절대 노출하지 않는지 확인하세요. SQL Database는 쿼리에서 반환된 데이터 범위가 단일 테넌트로 지정될 수 있게 행 수준 보안을 지원합니다.

처리:   다중 테 넌 트 데이터베이스는 모든 테 넌 트에서 계산 및 저장소 리소스를 공유 합니다. 데이터베이스을 전반적으로 모니터링하여 만족스러운 성능을 나타내는지 확인할 수 있습니다. 그러나 Azure 시스템에는 이러한 리소스에 대한 개별 테넌트 사용을 모니터링하거나 관리할 수 있는 기본 제공 방법이 없습니다. 따라서 다중 테넌트 데이터베이스는 주변 환경을 혼잡하게 하기 쉽습니다. 즉, 한 테넌트에서 과도한 워크로드가 발생할 경우 같은 데이터베이스에 있는 다른 테넌트의 성능에도 영향을 주게 됩니다. 추가 애플리케이션 수준 모니터링으로 테넌트 수준의 성능을 모니터링할 수 있습니다.

비용 절감

일반적으로 다중 테넌트 데이터베이스는 테넌트당 비용이 가장 낮습니다. 단일 데이터베이스의 리소스 비용은 같은 크기의 탄력적 풀의 리소스 비용보다 더 낮습니다. 또한 테넌트가 제한된 스토리지만 필요로 하는 시나리오에서는 수백만 개의 테넌트가 단일 데이터베이스에 저장될 수 있습니다. 탄력적 풀은 수백만 개의 데이터베이스를 포함할 수 없습니다. 그러나 풀당 1,000개의 데이터베이스를 포함하는 솔루션은 수백만 규모에 도달하여 관리하기 어려워질 수 있습니다.

다음에서는 가장 유연하고 확장이 용이한 분할된 다중 테넌트 모델을 사용하여 다중 테넌트 데이터베이스 모델의 두 가지 변형에 대해 설명합니다.

F. 단일 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱

가장 단순한 다중 테넌트 데이터베이스 패턴은 단일 데이터베이스를 사용하여 모든 테넌트에 대한 데이터를 호스트합니다. 더 많은 테넌트가 추가되면 더 많은 스토리지 및 컴퓨팅 리소스로 데이터베이스 규모가 확장됩니다. 항상 궁극적으로 규모 제한이 적용되긴 하지만 처음에는 이러한 규모 확장만 해결되면 충분할 수 있습니다. 그러나 곧 이러한 제한에 도달하게 되고 데이터베이스를 관리하기 어려워집니다.

각 개별 테넌트에 초점을 맞춘 관리 작업을 다중 테넌트 데이터베이스에서 구현하려고 하면 좀 더 어렵습니다. 또한 이러한 작업은 전반적으로 너무 느릴 수 있습니다. 한 테넌트만을 대상으로 하는 데이터의 지정 시간 복원을 그 예로 들 수 있습니다.

G. 공유되는 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱

대부분의 SaaS 애플리케이션은 한 번에 한 테넌트의 데이터에만 액세스합니다. 이 액세스 패턴을 사용하면 테넌트 데이터가 여러 데이터베이스 간에 또는 분할된 데이터베이스에서 분산될 수 있습니다. 후자의 경우 한 테넌트의 모든 데이터가 하나의 분할된 데이터베이스에 포함됩니다. 다중 테넌트 데이터베이스 패턴과 분할 모델을 함께 사용하면 거의 무제한으로 확장할 수 있게 됩니다.

공유되는 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱 디자인

분할된 데이터베이스 관리

분할을 사용하면 디자인 측면과 운영 관리 측면에서 복잡해집니다. 테넌트와 데이터베이스 간에 매핑을 유지 관리할 카탈로그가 필요합니다. 또한 분할된 데이터베이스 및 테넌트 채우기를 관리하기 위한 관리 절차도 필요합니다. 예를 들어, 분할된 데이터베이스를 추가 및 이동하고 분할된 데이터베이스 간에 테넌트 데이터를 이동하기 위한 절차를 계획해야 합니다. 크기를 조정하는 한 가지 방법은 새 분할된 데이터베이스를 추가하고 새 테넌트로 채우는 것입니다. 조밀하게 채워진 분할된 데이터베이스를 2개의 덜 채워진 분할된 데이터베이스로 분할할 수도 있습니다. 여러 테넌트가 이동되거나 사용이 중단된 후에 부분적으로 채워진 분할된 데이터베이스를 함께 병합할 수 있습니다. 이렇게 병합하면 좀 더 비용 효율적인 리소스 사용률이 구현됩니다. 또한 분할된 데이터베이스 간에 테넌트를 이동하여 작업 부하를 분산할 수도 있습니다.

SQL Database는 분할 라이브러리 및 카탈로그 데이터베이스와 함께 작동하는 분할/병합 도구를 제공합니다. 제공된 앱은 분할된 데이터베이스를 분할 및 병합할 수 있으며 분할된 데이터베이스 간에 테넌트 데이터를 이동할 수 있습니다. 또한 이 앱은 이러한 작업 동안 카탈로그를 유지 관리하며, 영향을 받은 테넌트를 이동하기 전에 오프라인으로 표시합니다. 이동 후에 앱은 새 매핑으로 카탈로그를 다시 업데이트하고 테넌트를 다시 온라인으로 표시합니다.

데이터베이스가 작아야 더 쉽게 관리할 수 있음

분할된 다중 테넌트 솔루션은 테넌트를 여러 데이터베이스에 걸쳐 분산하여 관리가 보다 용이한 더 작은 데이터베이스가 생성됩니다. 예를 들어, 특정 테넌트를 이전 시점으로 복원하면 모든 테넌트를 포함하는 더 큰 데이터베이스가 아니라 더 작은 단일 데이터베이스를 백업에서 복원하게 됩니다. 워크로드 및 관리 업무의 균형을 유지하기 위해 데이터베이스 크기 및 데이터베이스당 테넌트 수를 선택할 수 있습니다.

스키마의 테넌트 식별자

사용하는 분할 방법에 따라, 데이터베이스 스키마에 추가 제약 조건이 적용될 수 있습니다. SQL Database 분할/병합 애플리케이션에서는 스키마에 일반적으로 테넌트 식별자에 해당하는 분할 키가 포함되어야 합니다. 테넌트 식별자는 모든 분할된 테이블의 기본 키 맨 앞에 나오는 요소입니다. 테넌트 식별자를 사용하여 분할/병합 애플리케이션은 특정 테넌트와 연결된 데이터를 빠르게 찾아서 이동할 수 있습니다.

분할된 데이터베이스에 대한 탄력적 풀

분할된 다중 테넌트 데이터베이스는 탄력적 풀에 배치될 수 있습니다. 일반적으로 하나의 풀에 많은 단일 테넌트 데이터베이스를 둘 경우 소스의 다중 테넌트 데이터베이스에 많은 테넌트를 두는 것보다 비용 효율적입니다. 다중 테넌트 데이터베이스는 비교적 덜 활동적인 테넌트가 많이 있을 때 더 유용합니다.

H. 하이브리드 분할된 다중 테넌트 데이터베이스 모델

하이브리드 모델에서는 모든 데이터베이스의 스키마에 테넌트 식별자가 있습니다. 데이터베이스는 항상 둘 이상의 테넌트를 저장할 수 있으며 분할될 수 있습니다. 따라서 스키마 관점에서 보면 모두가 다중 테넌트 데이터베이스입니다. 그렇지만 실제로 이러한 데이터베이스의 일부는 하나의 테넌트만 포함합니다. 그렇더라도 하나의 특정 데이터베이스에 저장되는 테넌트의 수는 데이터베이스 스키마에 영향을 주지 않습니다.

테넌트 이동

언제든지 특정 테넌트 자체 다중 테넌트 데이터베이스로 이동할 수 있습니다. 또한 언제든지 마음이 바뀌면 테넌트를 여러 테넌트가 포함된 데이터베이스로 다시 이동할 수 있습니다. 또한 새 데이터베이스를 프로비전할 때 새로운 단일 테넌트 데이터베이스에 테넌트를 할당할 수 있습니다.

하이브리드 모델은 식별 가능한 테넌트 그룹의 리소스 요구량이 큰 차이를 보일 때 특히 유용합니다. 예를 들어 평가판에 참여하는 테넌트가 구독 테넌트와 동일한 높은 수준의 성능을 보장하지 못할 경우를 가정해보세요. 정책에 따라 평가 단계에 있는 테넌트가 모든 평가 테넌트 간에 공유되는 다중 테넌트 데이터베이스에 저장되어야 할 수도 이습니다. 평가판 테넌트가 기본 서비스 계층을 구독하면 더 적은 수의 테넌트를 포함할 수 있는 다른 다중 테넌트 데이터베이스로 이동될 수 있습니다. 프리미엄 서비스 계층 비용을 지불하는 구독자는 자체적인 새 단일 테넌트 데이터베이스로 이동될 수 있습니다.

이 하이브리드 모델에서 구독자 테넌트용 단일 테넌트 데이터베이스를 리소스 풀에 배치하여 테넌트별 데이터베이스 비용을 줄일 수 있습니다. 테넌트별 데이터베이스 모델에서도 이 작업을 수행할 수 있습니다.

9. 테넌시 모델 비교

다음 표에서는 주 테넌시 모델 간의 차이점을 요약해서 보여 줍니다.

측정 독립 실행형 앱 테넌트별 데이터베이스 분할된 다중 테넌트
확장 중간
1-100s
매우 높음
1-100,000s
제한 없음
1-1,000,000s
테넌트 격리 매우 높음 높음 낮음, 단일 테넌트의 경우는 예외입니다(MT db에만 단독으로 존재하는 경우).
테넌트별 데이터베이스 비용 높음, 최대 크기에 맞게 조정됩니다. 낮음. 풀이 사용됩니다. 가장 낮음. MT DB의 작은 테넌트용입니다.
성능 모니터링 및 관리 테넌트별로 구분되는 경우만 해당 집계 + 테넌트별 집계, 단일 항목에 대해서만 테넌트별로 구분됩니다.
개발 복잡성 낮음 낮음 중간, 분할로 야기됩니다.
운영 복잡성 높음-낮음 개별적으로는 단순하고 전체적으로는 복잡합니다. 낮음-중간 패턴으로 전체적인 복잡성을 해결합니다. 높음-낮음 개별 테넌트 관리가 복잡합니다.
 

다음 단계