이 문서에서는 Spanner에서 멀티테넌시를 구현할 수 있는 다양한 방법을 설명합니다. 또한 데이터 관리 패턴과 테넌트 수명 주기 관리에 대해서도 설명합니다. 이 문서는 Spanner에 멀티 테넌트 애플리케이션을 관계형 데이터베이스로 구현하는 데이터베이스 설계자, 데이터 설계자, 엔지니어를 대상으로 합니다. 여기에서는 멀티 테넌트 데이터를 저장하기 위한 여러 접근 방식을 간단히 다뤄봅니다. 이 문서 전체에서는 멀티 테넌트 애플리케이션을 액세스하는 항목을 나타내기 위해 '테넌트', '고객', '조직'이라는 용어가 서로 혼용될 수 있습니다. 이 페이지에 제공된 예시는 인사 관리(HR) SaaS 제공업체가 Google Cloud에서 구현한 멀티 테넌트 애플리케이션을 기반으로 합니다. 한 가지 요구사항은 HR SaaS 제공업체의 여러 고객이 멀티 테넌트 애플리케이션에 액세스해야 한다는 점입니다. 이러한 고객을 테넌트라고 합니다.
멀티테넌시
멀티테넌시는 소프트웨어 애플리케이션의 단일 인스턴스나 몇몇 인스턴스에서 여러 테넌트나 고객을 제공할 때를 의미합니다. 이 소프트웨어 패턴은 단일 테넌트나 고객부터 수백 또는 수천까지 확장될 수 있습니다. 이 방식은 기본 인프라가 여러 조직들 간에 공유되는 클라우드 컴퓨팅 플랫폼의 기초가 됩니다.
멀티테넌시를 데이터베이스와 같이 공유 컴퓨팅 리소스를 기반으로 하는 파티셔닝의 한 형태라고 생각할 수 있습니다. 아파트 건물의 입주자를 예로 들 수 있습니다. 입주자는 수도관 및 전선과 같은 인프라를 공유하지만 아파트에 입주자마다 전용 공간이 있습니다. 멀티테넌시는 전부는 아니더라도 거의 대부분 Software as a Service(SaaS) 애플리케이션에 포함됩니다.
Spanner는 Google Cloud에서 일관적이며 분산된 완전 관리형 엔터프라이즈급 데이터베이스로, 관계형 데이터베이스 모델의 이점과 비관계형 수평 확장성이 결합되어 있습니다. Spanner에는 스키마, 강제 데이터 유형, strong consistency, 멀티 문 ACID 트랜잭션, ANSI 2011 SQL을 구현하는 SQL 쿼리 언어와 같은 관계형 시맨틱이 있습니다. Spanner에는 99.999% SLA 가용성과 함께 계획된 유지보수 또는 리전 오류에 대한 다운타임이 없습니다. Spanner는 고가용성과 확장성을 제공하여 최신 멀티 테넌트 애플리케이션도 지원합니다.
테넌트 데이터 매핑 기준
멀티 테넌트 애플리케이션에서 각 테넌트의 데이터는 기본 Spanner 데이터베이스에 있는 여러 아키텍처 접근 방식 중 하나로 격리됩니다. 다음 목록에서는 테넌트의 데이터를 Spanner에 매핑하기 위해 사용되는 여러 아키텍처 접근 방식을 보여줍니다.
- 인스턴스: 테넌트가 하나의 Spanner에 배타적으로 상주하고, 이 테넌트에 대해 데이터베이스가 정확히 한 개 있습니다.
- 데이터베이스: 테넌트가 여러 데이터베이스를 포함하는 단일 Spanner 인스턴스의 데이터베이스에 상주합니다.
- 스키마: 테넌트가 데이터베이스 내 배타적 테이블에 있으며 테넌트 여러 개가 같은 데이터베이스에 배치될 수 있습니다.
- 행: 테넌트 데이터는 데이터베이스 테이블의 행입니다. 이러한 테이블은 다른 테넌트와 공유됩니다.
앞선 기준을 데이터 관리 패턴이라고 합니다. 자세한 내용은 멀티테넌시 데이터 관리 패턴 섹션을 참조하세요. 설명은 다음 기준에 따라 제공됩니다.
- 데이터 격리: 멀티테넌시에서는 여러 테넌트 간의 데이터 격리 수준이 중요한 고려사항입니다. 예를 들면 데이터를 물리적으로 또는 논리적으로 분리해야 하는지, 테넌트의 데이터마다 설정할 수 있는 독립적인 ACL(액세스 제어 목록)이 있는지 여부입니다. 격리는 다른 카테고리의 기준에 따라 선택한 항목에 따라 영향을 받습니다. 예를 들어 특정 규제 및 규정 준수 요구사항에 따라 높은 격리 수준이 필요할 수 있습니다.
- 민첩성: 인스턴스, 데이터베이스, 테이블 또는 행 생성과 관련하여 테넌트에 대한 온보딩 및 오프로딩 작업을 쉽게 수행할 수 있는지를 나타냅니다.
- 작업: 일반 유지보수, 로깅, 백업 또는 재해 복구 작업과 같은 일반 활동, 테넌트별 활동, 데이터베이스 활동, 관리 활동의 가용성이나 복잡성을 나타냅니다.
- 확장: 이후 성장을 위한 원활한 확장 기능을 나타냅니다. 각 패턴 설명에는 패턴에서 지원하는 테넌트 수가 포함되어 있습니다.
- 성능:
- 리소스 격리: 각 테넌트에 배타적 리소스를 할당하고 시끄러운 이웃(noisy neighbor) 현상을 해결하며 각 테넌트의 예측 가능한 읽기 및 쓰기 성능을 지원하는 기능입니다.
- 테넌트당 최소 리소스 수: 테넌트당 평균 최소 리소스 금액입니다. 그렇다고 해서 개별 테넌트마다 최소 이 금액 이상을 지불해야 하는 것은 아닙니다. 모든 테넌트 N개에 대해 최소 N * 금액 이상을 지불해야 합니다.
- 리소스 효율성: 다른 테넌트의 유휴 리소스를 사용하여 전반적인 비용을 절감하는 기능입니다.
- 지연 시간 최적화를 위한 위치 선택: 각 테넌트의 데이터를 테넌트에 가장 적합한 지연 시간을 제공하는 위치에 배치할 수 있도록 각 테넌트에 특정 복제 토폴로지를 선택하는 기능입니다.
- 규제 및 규정 준수: 리소스 및 유지관리 작업을 완전히 격리해야 하는 고도로 규제된 산업 및 국가의 요구사항을 처리할 수 있는 기능입니다. 예를 들어 프랑스의 데이터 상주 요구사항에 따라 개인 식별 정보는 프랑스 내에서만 물리적으로 저장되어야 합니다. 금융 산업에서는 일반적으로 고객 관리 암호화 키(CMEK)를 요구하며 각 테넌트는 자체 암호화 키를 사용할 수 있습니다.
다음 섹션에서는 이러한 기준에 따라 각 데이터 관리 패턴을 자세히 설명합니다. 특정 테넌트 집합에 대해 데이터 관리 패턴을 선택할 때 동일한 기준을 사용합니다.
멀티테넌시 데이터 관리 패턴
다음 섹션에서는 인스턴스, 데이터베이스, 테이블, 행이라는 4가지 기본 데이터 관리 패턴을 설명합니다.
인스턴스
완전한 격리를 제공하기 위해 인스턴스 데이터 관리 패턴은 고유 Spanner 인스턴스 및 데이터베이스에 각 테넌트 데이터를 저장합니다. Spanner 인스턴스는 하나 이상의 데이터베이스를 포함할 수 있습니다. 이 패턴에서는 데이터베이스 하나만 생성됩니다. 앞에서 설명한 HR 애플리케이션의 경우 고객 조직마다 데이터베이스 하나가 있는 개별 Spanner 인스턴스가 생성됩니다.
다음 다이어그램에 표시된 것처럼 데이터 관리 패턴에 인스턴스당 하나의 테넌트가 포함됩니다.
테넌트마다 개별 인스턴스가 있으면 개별Google Cloud 프로젝트를 사용하여 테넌트마다 개별 신뢰 경계를 얻을 수 있습니다. 추가 이점은 각 테넌트의 위치를 기준으로 리전에 따라 또는 여러 리전에 따라 각 인스턴스 구성을 선택할 수 있으므로, 위치 유연성 및 성능을 최적화할 수 있다는 것입니다.
이 아키텍처는 임의의 테넌트 수로 확장될 수 있습니다. SaaS 제공업체는 엄격한 제한 없이 원하는 리전에 인스턴스를 임의의 수로 만들 수 있습니다.
다음 표에서는 인스턴스 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.
| 기준 | 인스턴스 - 인스턴스 데이터 관리 패턴당 테넌트 1개 |
|---|---|
| 데이터 격리 |
|
| 민첩성 |
|
| 작업 |
|
| 확장 |
|
| 성능 |
|
| 규제 및 규정 준수 요구사항 |
|
주요 핵심은 다음과 같습니다.
- 장점: 높은 격리 수준
- 단점: 테넌트당 PU가 최소 100개이므로 가장 큰 운영 오버헤드가 발생하고 비용이 더 많이 발생할 수 있습니다. 테넌트 간에 리소스를 공유할 수 없습니다.
인스턴스 데이터 관리 패턴은 다음 시나리오에 적합합니다.
- 여러 테넌트가 넓은 리전 범위에 분산되어 있고 지역화된 솔루션이 필요합니다.
- 일부 테넌트의 규제 및 규정 준수 요구사항에 따라 더 높은 수준의 보안 및 감사 프로토콜이 요구됩니다.
- 테넌트 크기는 크게 다르므로 볼륨과 트래픽이 높은 테넌트 간의 리소스 공유로 인해 경합과 상호 성능 저하가 발생할 수 있습니다.
데이터베이스
데이터베이스 데이터 관리 패턴에서 각 테넌트는 단일 Spanner 인스턴스 내의 데이터베이스에 상주합니다. 데이터베이스 여러 개가 단일 인스턴스에 상주할 수 있습니다. 테넌트 수에 비해 인스턴스 하나로 부족하면 여러 인스턴스를 만듭니다. 이 패턴은 단일 Spanner 인스턴스가 여러 테넌트 간에 공유된다는 것을 의미합니다.
Spanner에는 인스턴스당 데이터베이스 100개의 엄격한 제한이 적용됩니다. 이러한 제한은 SaaS 제공업체가 고객을 100개 이상으로 확장해야 할 경우 Spanner 인스턴스를 여러 개 만들어 사용해야 한다는 것을 의미합니다.
HR 애플리케이션의 경우 SaaS 제공업체는 Spanner 인스턴스에 개별 데이터베이스가 있는 각 테넌트를 만들고 관리합니다.
다음 다이어그램에 표시된 것처럼 데이터 관리 패턴에 데이터베이스당 하나의 테넌트가 포함됩니다.
데이터베이스 데이터 관리 패턴은 여러 테넌트의 데이터에 대해 데이터베이스 수준에서 논리적 격리를 수행합니다. 하지만 단일 Spanner 인스턴스이므로 지역 파티셔닝 기능을 사용하지 않는 한 모든 테넌트 데이터베이스는 같은 복제 토폴로지와 기본 컴퓨팅 및 스토리지 설정을 공유합니다. Spanner 지역 파티셔닝 기능을 사용하여 여러 위치에 인스턴스 파티션을 만들고 같은 인스턴스의 여러 데이터베이스에 서로 다른 인스턴스 파티션을 사용할 수 있습니다.
다음 표에서는 데이터베이스 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.
| 기준 | 데이터베이스 - 데이터베이스 데이터 관리 패턴당 테넌트 1개 |
|---|---|
| 데이터 격리 |
|
| 민첩성 |
|
| 운영 |
|
| 확장 |
|
| 성능 |
|
| 규제 및 규정 준수 요구사항 |
|
주요 핵심은 다음과 같습니다.
- 장점: 적당한 데이터 격리 수준 및 리소스 격리, 적당한 리소스 효율성 수준, 테넌트마다 자체 백업 및 CMEK 보유 가능
- 단점: 인스턴스당 테넌트 수가 제한되므로 지역 파티셔닝 기능을 사용하지 않으면 위치를 유연하게 선택할 수 없음
데이터베이스 데이터 관리 패턴은 다음 시나리오에 적합합니다.
- 여러 고객이 같은 데이터 상주에 있거나 같은 규제 기관의 영향을 받습니다.
- 테넌트에 시스템 기반 데이터 분리 및 데이터 백업 및 복원 기능이 필요하지만 인프라 리소스 공유가 지원됩니다.
- 테넌트에 자체 CMEK가 필요합니다.
- 비용은 중요한 고려사항입니다. 테넌트당 필요한 최소 리소스 수가 인스턴스 비용보다 적습니다. 테넌트에서 다른 테넌트의 유휴 리소스를 사용하는 것이 좋습니다.
표
테이블 데이터 관리 패턴에서는 단일 스키마를 구현하는 단일 데이터베이스가 테넌트 여러 개에 사용되며 개별 테이블 집합이 각 테넌트의 데이터에 사용됩니다. 테이블 이름에 tenant ID를 프리픽스, 서픽스 또는 이름이 지정된 스키마로 포함하여 이러한 테이블을 구분할 수 있습니다.
각 테넌트의 개별 테이블 집합을 사용하는 이 데이터 관리 패턴은 앞에 설명한 옵션(인스턴스 및 데이터베이스 관리 패턴)에 비해 훨씬 낮은 격리 수준을 제공합니다. 온보딩에는 새 테이블 및 연관된 참조 무결성과 색인 만들기가 포함됩니다.
테이블은 데이터베이스당 5,000개로 제한됩니다. 일부 고객의 경우 이러한 제한으로 인해 애플리케이션 사용이 제한될 수 있습니다.
또한 각 고객에 대해 개별 테이블을 사용함으로써 스키마 업데이트 작업의 백로그가 대량으로 생성될 수 있습니다. 이러한 백로그는 분석하는 데 시간이 오래 걸립니다.
HR 애플리케이션의 경우 SaaS 제공업체는 테이블 이름에 tenant ID를 프리픽스로 포함하여 고객마다 테이블 집합을 만들 수 있습니다. 예를 들면 customer1_employee, customer1_payroll, customer1_department입니다.
또는 테넌트 ID를 이름이 지정된 스키마로 사용하고 테이블 이름을 customer1.employee, customer1.payroll, customer1.department로 지정할 수 있습니다.
다음 다이어그램과 같이 테이블 데이터 관리 패턴에는 각 테넌트의 테이블 집합 하나가 포함됩니다.
다음 표에서는 테이블 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.
| 기준 | 테이블 - 각 테넌트 데이터 관리 패턴의 테이블 집합 하나 |
|---|---|
| 데이터 격리 |
|
| 민첩성 |
|
| 작업 |
|
| 확장 |
|
| 성능 |
|
| 규제 및 규정 준수 요구사항 |
|
주요 핵심은 다음과 같습니다.
- 장점: 적당한 수준의 확장성과 리소스 효율성
- 단점:
- 적당한 수준의 데이터 격리 및 리소스 격리
- 새 지역 파티셔닝 기능을 사용하지 않으면 위치를 유연하게 선택할 수 없습니다.
- 테넌트를 개별적으로 모니터링할 수 없습니다. 사용할 수 있는 유일한 테이블 수준 리소스 사용량 정보는 테이블 크기 통계입니다.
- 테넌트에는 자체 CMEK 및 백업이 있을 수 없습니다.
테이블 데이터 관리 패턴은 다음 시나리오에 적합합니다.
- 법적으로 데이터 분리가 요구되지 않지만 논리적 분리와 보안 제어가 필요한 멀티 테넌트 애플리케이션
- 비용은 중요한 고려사항입니다. 최소 테넌트당 비용은 데이터베이스당 비용보다 저렴합니다.
행
최종 데이터 관리 패턴은 공통 테이블 집합이 포함된 테넌트 여러 개를 제공하며 테이블의 각 행은 특정 테넌트에 속합니다. 이 데이터 관리 패턴은 인프라부터 스키마 및 데이터 모델에 이르기까지 모든 것이 여러 테넌트 간에 공유되는 매우 높은 수준의 멀티테넌시를 나타냅니다. 테이블 내에서 행은 tenant ID를 키의 첫 번째 요소로 사용하여 기본 키를 기준으로 분할됩니다. 확장 관점에서 Spanner는 제한 없이 테이블을 확장할 수 있기 때문에 이 패턴을 가장 잘 지원합니다.
HR 애플리케이션의 경우 급여 테이블의 기본 키는 customerID 및 payrollID의 조합일 수 있습니다.
다음 다이어그램과 같이 행 데이터 관리 패턴에는 여러 테넌트의 테이블 하나가 포함됩니다.
다른 모든 패턴과 달리 행 패턴의 데이터 액세스는 여러 테넌트마다 개별적으로 제어될 수 없습니다. 더 적은 수의 테이블을 사용하면 각 테넌트에 고유 데이터베이스 테이블이 포함되었을 때 스키마 업데이트 작업이 더 빠르게 완료됩니다. 대부분의 경우 이 접근 방식은 온보딩, 오프로딩, 작업을 단순화합니다.
다음 표에서는 행 데이터 관리 패턴이 다른 기준에 미치는 영향을 간략하게 보여줍니다.
| 기준 | 행 - 각 테넌트 데이터 관리 패턴의 행 집합 하나 |
|---|---|
| 데이터 격리 |
|
| 민첩성 |
|
| 작업 |
|
| 확장 |
|
| 성능 |
|
| 규제 및 규정 준수 요구사항 |
|
주요 핵심은 다음과 같습니다.
- 장점: 확장성 높음, 운영 오버헤드 낮음, 간소화된 스키마 관리
- 단점: 리소스 경합이 심함, 각 테넌트의 보안 제어 및 모니터링 부족
이 패턴은 다음 시나리오에 가장 적합합니다.
- 쉬운 유지보수와 비교할 때 엄격한 데이터 보안 격리가 중요 관심사가 아닌 여러 부서의 요구를 충족시키는 내부 애플리케이션
- 동시에 리소스 프로비저닝을 최소화할 때 무료 등급 애플리케이션을 사용하여 테넌트의 리소스 공유 최대화
데이터 관리 패턴 및 테넌트 수명 주기 관리
다음 표에서는 모든 기준에서 여러 데이터 관리 패턴을 대략적으로 비교해서 보여줍니다.
| 인스턴스 | 데이터베이스 | 표 | 행 | |
|---|---|---|---|---|
| 데이터 격리 | 완료 | 높음 | 보통 | 낮음 |
| 민첩성 | 낮음 | 보통 | 보통 | 가장 높음 |
| 작업 편의성 | 높음 | 높음 | 낮음 | 낮음 |
| 확장 | 높음 | 제한됨(한도에 도달할 때 추가 인스턴스를 사용하지 않는 경우) | 제한됨(한도에 도달할 때 추가 데이터베이스를 사용하지 않는 경우) | 가장 높음 |
| 성능1 - 리소스 격리 | 높음 | 낮음 | 낮음 | 낮음 |
| 성능1 - 테넌트당 최소 리소스 수 | 높음 | 중간 높음 | 보통 | 테넌트당 최소 한도 없음 |
| 성능1 - 리소스 효율성 | 낮음 | 높음 | 높음 | 높음 |
| 성능1 - 지연 시간 최적화를 위한 위치 선택 | 높음 | 보통 | 보통 | 보통 |
| 규제 및 규정 준수 | 가장 높음 | 높음 | 보통 | 낮음 |
1 성능은 스키마 설계 및 쿼리 권장사항에 따라 크게 달라집니다. 여기에 표시된 값은 평균적인 기대 값입니다.
특정 멀티 테넌트 애플리케이션에 가장 적합한 데이터 관리 패턴은 해당 기준에 따라 가장 많은 요구사항을 충족시켜 주는 패턴입니다. 특정 기준이 요구되지 않을 경우에는 해당 기준이 있는 행을 무시해도 됩니다.
결합된 데이터 관리 패턴
멀티 테넌트 애플리케이션의 요구사항을 해결하는 데에 단일 데이터 관리 패턴으로 충분한 경우가 종종 있습니다. 이 경우 설계 시 단일 데이터 관리 패턴을 가정할 수 있습니다.
무료 등급, 일반 등급, 엔터프라이즈 등급을 지원하는 멀티 테넌트 애플리케이션과 같이 일부 멀티 테넌트 애플리케이션을 사용하려면 동시에 데이터 관리 패턴 여러 개가 필요합니다.
무료 등급:
- 비용 효율적이어야 함
- 데이터 볼륨 상한선이 있어야 함
- 일반적으로 제한된 기능 지원
- 무료 등급에 적합한 후보는 행 데이터 관리 패턴
- 테넌트 관리가 간단함
- 특정 또는 배타적인 테넌트 리소스를 만들 필요가 없음
일반 등급:
- 특별히 강력한 확장 또는 격리 요구 사항이 없는 결제 클라이언트에 적합합니다.
- 일반 등급에 적합한 후보는 테이블 데이터 관리 패턴이나 데이터베이스 데이터 관리 패턴입니다.
- 테이블과 색인이 테넌트에 대해 배타적입니다.
- 데이터베이스 데이터 관리 패턴에서는 백업이 간소화됩니다.
- 테이블 데이터 관리 패턴에는 백업이 지원되지 않습니다.
- 테넌트 백업이 Spanner 외부의 유틸리티로 구현되어야 합니다.
엔터프라이즈 등급:
- 일반적으로 모든 측면에서 완전한 자율성이 보장되는 고급 등급입니다.
- 테넌트에는 전용 확장과 완전한 격리가 포함된 전용 리소스가 있습니다.
- 인스턴스 데이터 관리 패턴이 엔터프라이즈 등급에 적합합니다.
권장사항은 서로 다른 데이터 관리 패턴을 서로 다른 데이터베이스에서 유지 관리하는 것입니다. 하나의 Spanner 데이터베이스에 여러 데이터 관리 패턴을 결합할 수도 있지만, 이렇게 하면 애플리케이션의 액세스 논리 및 수명 주기 작업을 구현하는 것이 어렵습니다.
애플리케이션 설계 섹션에서는 단일 데이터 관리 패턴이나 데이터 관리 패턴 여러 개를 사용할 때 적용되는 일부 멀티 테넌트 애플리케이션 설계 고려 사항을 설명합니다.
테넌트 수명 주기 관리
테넌트에는 수명 주기가 있습니다. 따라서 멀티 테넌트 애플리케이션 내에서 해당 관리 작업을 구현해야 합니다. 테넌트 만들기, 업데이트, 삭제와 같은 기본 작업 외에도 다음과 같은 추가 데이터 관련 작업을 고려하세요.
테넌트 데이터 내보내기:
- 테넌트를 삭제할 때는 먼저 데이터를 내보내고 데이터 세트를 데이터에 제공하는 것이 좋습니다.
- 행 또는 테이블 데이터 관리 패턴을 사용할 경우 멀티 테넌트 애플리케이션 시스템은 내보내기를 구현하거나 이를 데이터베이스 기능(데이터베이스 내보내기)에 매핑하고 테넌트에 해당하는 데이터의 일부를 가져오는 커스텀 로직을 구현해야 합니다.
테넌트 데이터 백업:
- 인스턴스 또는 데이터베이스 데이터 관리 패턴을 사용하고 개별 테넌트에 대해 데이터를 백업할 때 데이터베이스의 내보내기 또는 백업 기능을 사용합니다.
- 테이블 또는 행 데이터 관리 패턴을 사용하고 개별 테넌트의 데이터를 백업할 경우 멀티 테넌트 애플리케이션에서 이 작업을 구현해야 합니다. Spanner 데이터베이스는 어떤 데이터가 어떤 테넌트에 속해 있는지 확인할 수 없습니다.
테넌트 데이터 이동:
테넌트를 한 데이터 관리 패턴에서 다른 패턴으로 이동(같은 데이터 관리 패턴 내의 테넌트를 인스턴스나 데이터베이스 간에 이동)하려면 데이터를 한 테이블 데이터 관리 패턴에서 추출하고 이 데이터를 새로운 데이터베이스 데이터 관리 패턴에 삽입해야 합니다.
- 애플리케이션 다운타임이 가능한 경우 내보내기/가져오기를 수행합니다.
- 다운타임이 가능하지 않으면 다운타임 없는 데이터베이스 마이그레이션을 수행합니다.
시끄러운 이웃(noisy-neighbor) 상황을 완화하는 것도 테넌트를 이동하는 또 다른 이유입니다.
애플리케이션 설계
멀티 테넌트 애플리케이션을 설계할 때 테넌트 인식 비즈니스 논리를 구현합니다. 즉, 애플리케이션이 비즈니스 논리를 실행할 때마다 알려진 테넌트의 컨텍스트 내에 있어야 합니다.
데이터베이스 관점에서 애플리케이션 설계에서는 테넌트가 있는 데이터 관리 패턴에 대해 각 쿼리가 실행되어야 합니다. 다음 섹션에서는 멀티 테넌트 애플리케이션 설계의 중심 개념을 설명합니다.
동적 테넌트 연결 및 쿼리 구성
테넌트 데이터를 테넌트 애플리케이션 요청에 동적으로 매핑할 때는 매핑 구성이 사용됩니다.
- 데이터베이스 데이터 관리 패턴이나 인스턴스 데이터 관리 패턴의 경우 연결 문자열만으로 테넌트 데이터에 액세스할 수 있습니다.
- 테이블 데이터 관리 패턴의 경우 올바른 테이블 이름을 확인해야 합니다.
- 행 데이터 관리 패턴의 경우 적절한 조건자를 사용하여 특정 테넌트의 데이터를 검색합니다.
테넌트는 4개의 데이터 관리 패턴 중 무엇에든 상주할 수 있습니다. 다음 매핑 구현은 동시에 모든 데이터 관리 패턴을 사용하는 멀티 테넌트 애플리케이션의 일반 사례에 대한 연결 구성을 해결합니다. 제공된 테넌트가 하나의 패턴에 상주할 때 일부 멀티 테넌트 애플리케이션은 모든 테넌트에 대해 하나의 데이터 관리 패턴을 사용합니다. 이 경우는 다음 매핑에 암시적으로 포함됩니다.
직원이 자신의 테넌트 ID로 로그인할 때와 같이 테넌트가 비즈니스 로직을 실행하는 경우 애플리케이션 로직에서 테넌트의 데이터 관리 패턴, 지정된 테넌트 ID의 데이터 위치, 테이블 패턴의 경우 테이블 명명 규칙(선택사항)을 확인해야 합니다.
이 애플리케이션 논리에는 테넌트-데이터 관리 패턴 매핑이 필요합니다. 다음 코드 샘플에서 connection string은 테넌트 데이터가 있는 데이터베이스를 나타냅니다. 이 샘플은 Spanner 인스턴스 및 데이터베이스를 식별합니다. 데이터 관리 패턴 인스턴스 및 데이터베이스의 경우 다음 코드만으로 애플리케이션이 쿼리를 연결하고 실행하는 데 충분합니다.
tenant id -> (data management pattern,
database connection string)
테이블 및 행 데이터 관리 패턴에는 추가 설계가 필요합니다.
테이블 데이터 관리 패턴
테이블 데이터 관리 패턴의 경우 같은 데이터베이스 내에 테넌트 여러 개가 있습니다. 각 테넌트에는 고유 테이블 집합이 있습니다. 테이블은 이름으로 구분됩니다. 어떤 테이블이 어떤 테넌트에 속할지는 결정적입니다.
한 가지 방법은 각 테넌트의 테이블을 테넌트 이름을 따서 지은 네임스페이스에 배치하고 namespace.name으로 테이블 이름을 정규화하는 것입니다. 예를 들어 ID가 356인 테넌트의 네임스페이스 T356 내에 EMPLOYEE 테이블을 배치하면 애플리케이션에서 T356.EMPLOYEE를 사용하여 테이블에 대한 요청을 처리할 수 있습니다.
또 다른 방법은 테이블 이름 앞에 테넌트 ID를 추가하는 것입니다. 예를 들어 EMPLOYEE 테이블은 ID가 356인 테넌트의 T356_EMPLOYEE라고 합니다.
쿼리를 매핑으로 반환된 데이터베이스에 전송하기 전에 애플리케이션에서 tenant
ID 프리픽스를 각 테이블 앞에 추가해야 합니다.
테넌트 ID 대신 다른 텍스트를 사용하려면 테넌트 ID에서 이름이 지정된 스키마 네임스페이스나 테이블 프리픽스로의 매핑을 유지하면 됩니다.
애플리케이션 로직을 간소화하기 위해 한 수준의 간접 참조를 도입할 수 있습니다. 예를 들어 애플리케이션에서 공통 라이브러리를 사용하여 테넌트의 호출에 대한 네임스페이스나 테이블 프리픽스를 자동으로 연결할 수 있습니다.
행 데이터 관리 패턴
행 데이터 관리 패턴에는 비슷한 설계가 필요합니다. 이 패턴에는 단일 스키마가 사용됩니다. 테넌트 데이터는 행으로 저장됩니다. 데이터에 올바르게 액세스하기 위해서는 적합한 테넌트를 선택하도록 각 쿼리에 조건자를 추가합니다.
적합한 테넌트를 찾기 위한 한 가지 방법은 각 테이블에 TENANT라는 열을 두는 것입니다. 데이터 격리를 개선하려면 이 열 값이 기본 키의 일부여야 합니다. 열 값은 tenant ID입니다. 각 쿼리는 AND TENANT = tenant ID 조건자를 기존 WHERE 절에 추가하거나 AND TENANT = tenant
ID 조건자가 있는 WHERE 절을 추가해야 합니다.
데이터베이스에 연결하고 적합한 쿼리를 만들려면 애플리케이션 논리에 테넌트 식별자가 제공되어야 합니다. 이것은 파라미터로 전달되거나 스레드 컨텍스트로 저장될 수 있습니다.
일부 수명 주기 작업에서는 테넌트-매핑 관리 패턴 매핑 구성을 수정해야 합니다. 예를 들어 데이터 관리 패턴 간에 테넌트를 이동할 때, 데이터 관리 패턴 및 데이터베이스 연결 문자열을 업데이트해야 합니다. 또한 테이블 프리픽스를 업데이트해야 할 수 있습니다.
쿼리 생성 및 기여 분석
멀티 테넌트 애플리케이션의 기본 원칙은 여러 테넌트가 단일 클라우드 리소스를 공유할 수 있도록 하는 것입니다. 단일 Spanner 인스턴스에 단일 테넌트가 할당되는 경우를 제외하고 앞에서 설명한 데이터 관리 패턴은 이 카테고리에 포함됩니다.
리소스 공유는 데이터 공유의 범위를 벗어납니다. 모니터링 및 로깅도 공유됩니다. 예를 들어 테이블 데이터 관리 패턴과 행 데이터 관리 패턴에서는 모든 테넌트에 대한 모든 쿼리가 같은 감사 로그에 기록됩니다.
쿼리가 로깅되는 경우 해당 쿼리가 실행된 대상 테넌트를 확인하기 위해 쿼리 텍스트를 검사해야 합니다. 행 데이터 관리 패턴에서는 조건자를 파싱해야 합니다. 테이블 데이터 관리 패턴에서는 테이블 이름 중 하나를 파싱해야 합니다.
데이터베이스 데이터 관리 패턴이나 인스턴스 데이터 관리 패턴에서는 쿼리 텍스트에 어떠한 테넌트 정보도 포함되지 않습니다. 이러한 패턴에 대한 테넌트 정보를 가져오려면 tenant-to-data-management-pattern 매핑 테이블을 쿼리해야 합니다.
쿼리 텍스트를 파싱하지 않고 제공된 쿼리에 대해 테넌트를 확인하여 로그 및 쿼리를 분석하는 것이 더 쉬울 수 있습니다. 모든 데이터 관리 패턴에서 쿼리에 대한 테넌트를 동일하게 식별할 수 있는 한 가지 방법은 tenant ID 및 label(선택사항)이 포함된 주석을 쿼리 텍스트에 추가하는 것입니다.
다음 쿼리는 TENANT 356으로 식별된 테넌트에 대해 모든 직원 데이터를 선택합니다. SQL 구문을 파싱하고 조건자에서 테넌트 ID를 추출하지 않도록 테넌트 ID가 주석으로 추가됩니다. SQL 구문을 파싱할 필요 없이 주석을 추출할 수 있습니다.
SELECT * FROM EMPLOYEE
-- TENANT 356
WHERE TENANT = 'T356';
또는
SELECT * FROM T356_EMPLOYEE;
-- TENANT 356
이 설계에서는 데이터 관리 패턴과 관계없이 테넌트에 대해 쿼리가 실행될 때마다 해당 테넌트에 대해 기여 분석이 수행됩니다. 테넌트가 한 데이터 관리 시스템에서 다른 시스템으로 이동될 경우 쿼리 텍스트가 변경될 수 있지만 기여 분석은 쿼리 텍스트에 동일하게 유지됩니다.
앞의 코드 샘플은 단지 하나의 방법입니다. 또 다른 방법은 라벨 및 값 대신 주석으로 JSON 객체를 삽입하는 것입니다.
SELECT * FROM T356_EMPLOYEE;
-- {"TENANT": 356}
태그를 사용하여 쿼리의 기여도를 테넌트에 부여하고 기본 제공 spanner_sys 테이블에서 통계를 볼 수도 있습니다.
테넌트 액세스 수명 주기 작업
설계 철학에 따라 멀티 테넌트 애플리케이션은 앞에서 설명한 데이터 수명 주기 작업을 직접 구현할 수도 있고 아니면 별도의 테넌트 관리 도구를 만들 수 있습니다.
구현 전략에 관계없이 동시에 실행되는 애플리케이션 논리 없이 수명 주기 작업을 실행해야 할 수 있습니다. 예를 들어 한 데이터 관리 패턴에서 다른 패턴으로 테넌트를 이동할 때는 데이터가 단일 데이터베이스에 없기 때문에 애플리케이션 논리가 실행될 수 없습니다. 데이터가 단일 데이터베이스에 있지 않으면 애플리케이션 관점에서 두 가지 추가 작업이 필요합니다.
- 테넌트 중지: 모든 애플리케이션 논리 액세스를 사용 중지하고 데이터 수명 주기 작업은 허용합니다.
- 테넌트 시작: 애플리케이션 논리가 테넌트의 데이터에 액세스할 수 있고, 애플리케이션 논리와 간섭되는 수명주기 작업은 사용 중지됩니다.
자주 사용되지는 않아도 긴급 테넌트 종료는 또 다른 중요한 수명 주기 작업일 수 있습니다. 위반이 의심되고 애플리케이션 로직은 물론 수명 주기 작업까지 테넌트 데이터에 대한 모든 액세스를 금지해야 할 경우에는 이 종료를 사용합니다. 위반은 데이터베이스 내부 또는 외부에서 시작될 수 있습니다.
긴급 상태를 삭제하는 일치 수명 주기 작업도 사용할 수 있어야 합니다. 이러한 작업은 상호 제어를 구현하기 위해 관리자 2명 이상이 동시에 로그인하도록 요구할 수 있습니다.
애플리케이션 격리
여러 데이터 관리 패턴은 여러 가지 수준의 테넌트 데이터 격리를 지원합니다. 가장 높은 격리 수준(인스턴스)부터 가장 낮은 격리 수준(행)까지 여러 수준의 격리가 가능합니다.
멀티 테넌트 애플리케이션의 컨텍스트에서 비슷한 배포 결정을 내려야 합니다. 동일한 애플리케이션 배포를 사용하여 모든 테넌트가 해당 데이터에 액세스하나요(다른 데이터 관리 패턴 사용 가능)? 예를 들어 단일 Kubernetes 클러스터가 모든 테넌트를 지원할 수 있고, 테넌트가 해당 데이터에 액세스할 때 동일한 클러스터가 비즈니스 논리를 실행합니다.
또는 데이터 관리 패턴의 경우와 같이 다른 테넌트가 다른 애플리케이션 배포에 연결될 수 있습니다. 큰 테넌트는 배타적인 애플리케이션 배포에 액세스할 수 있고, 무료 등급의 작은 테넌트는 애플리케이션 배포를 공유할 수 있습니다.
이 문서에 설명된 데이터 관리 패턴을 해당 애플리케이션 데이터 관리 패턴과 직접 일치시키는 대신 모든 테넌트에서 단일 애플리케이션 배포를 공유하도록 데이터베이스 데이터 관리 패턴을 사용할 수 있습니다. 데이터베이스 데이터 관리 패턴을 지정하고, 이러한 모든 테넌트가 단일 애플리케이션 배포를 공유하도록 할 수 있습니다.
멀티테넌시는 특히 리소스 효율성이 중요한 역할을 수행할 때 중요한 애플리케이션 설계 데이터 관리 패턴입니다. Spanner는 여러 가지 데이터 관리 패턴을 지원합니다. 멀티 테넌트 애플리케이션을 구현할 때 이를 사용하세요. Spanner에는 99.999% SLA 가용성과 함께 계획된 유지보수 또는 리전 오류에 대한 다운타임이 없습니다. 고가용성과 확장성을 제공하여 최신 멀티 테넌트 애플리케이션도 지원합니다.