Spanner에서 멀티테넌시 구현

이 문서에서는 Spanner에서 멀티테넌시를 구현하기 위한 여러 방법을 설명합니다. 또한 데이터 관리 패턴과 테넌트 수명 주기 관리에 대해서도 설명합니다.

멀티테넌시는 소프트웨어 애플리케이션의 단일 인스턴스 또는 일부 인스턴스가 멀티 테넌트 또는 고객에 서비스를 제공할 때를 의미합니다. 이 소프트웨어 패턴은 단일 테넌트 또는 고객으로부터 수백 또는 수천까지 확장될 수 있습니다. 이 접근 방식은 기본 인프라가 여러 조직들 간에 공유되는 클라우드 컴퓨팅 플랫폼의 기초가 됩니다.

멀티테넌시를 데이터베이스와 같이 공유 컴퓨팅 리소스를 기반으로 하는 파티션 나누기라고 생각할 수 있습니다. 시설 인프라를 공유하지만 전용 거주 공간을 갖고 있는 아파트 건물의 거주자와도 같습니다. 멀티테넌시는 전부는 아니더라도 거의 대부분의 Software as a service(SaaS) 애플리케이션에 포함됩니다.

이 문서는 Spanner에 멀티 테넌트 애플리케이션을 관계형 데이터베이스로 구현하는 데이터베이스 설계자, 데이터 설계자, 엔지니어를 대상으로 합니다. 여기에서는 멀티 테넌트 데이터를 저장하기 위한 여러 접근 방식을 간단히 다뤄봅니다. 이 문서 전체에서는 멀티 테넌트 애플리케이션을 액세스하는 항목을 나타내기 위해 '테넌트', '고객', '조직'이라는 용어가 서로 혼용될 수 있습니다.

이 문서에서는 하나의 예시로 Google Cloud에서 멀티 테넌트 애플리케이션을 구현하는 인사 관리(HR) SaaS 제공업체를 사용합니다. 이 예시에서 HR SaaS 제공업체의 일부 고객은 멀티 테넌트 애플리케이션에 액세스해야 합니다. 이러한 고객을 테넌트라고 부릅니다.

Spanner는 Google Cloud에서 완전히 관리되고, 일관적이고, 분산된 형태의 엔터프라이즈급 데이터베이스이며, 관계형 데이터베이스 모델의 이점과 비관계형 수평적 확장성을 결합할 수 있게 해줍니다. Spanner에는 스키마, 강제 적용되는 데이터 유형, strong consistency, 다중 문 ACID 트랜잭션, ANSI 2011 SQL을 구현하는 SQL 쿼리 언어와 같은 관계형 의미 체계를 갖습니다.

Spanner는 99.999% SLA 가용성과 함께 계획된 유지보수 또는 리전 오류에 대해 제로 다운타임을 제공합니다. 고가용성 및 확장성을 제공하여 최신의 멀티 테넌트 애플리케이션을 지원합니다. 이 문서에서는 Spanner로 멀티테넌시를 구현하기 위한 여러 아키텍처 접근 방식을 설명합니다.

테넌트 데이터 매핑 기준

멀티 테넌트 애플리케이션에서 각 테넌트의 데이터는 기본 Spanner 데이터베이스에 있는 여러 아키텍처 접근 방식 중 하나로 격리됩니다. 다음 목록에서는 테넌트의 데이터를 Spanner에 매핑하기 위해 사용되는 여러 아키텍처 접근 방식을 보여줍니다.

인스턴스: 테넌트가 하나의 Spanner에 배타적으로 상주하고, 이 테넌트에 대해 데이터베이스가 정확히 한 개 있습니다.
데이터베이스: 테넌트가 여러 데이터베이스를 포함하는 단일 Spanner 인스턴스의 데이터베이스에 상주합니다.
스키마: 테넌트가 데이터베이스 내의 배타적 테이블에 상주하며, 여러 테넌트를 동일한 데이터베이스에 배치할 수 있습니다.
테이블: 테넌트 데이터가 데이터베이스 테이블의 행입니다. 이러한 테이블은 다른 테넌트와 공유됩니다.

위에 표시된 기준을 데이터 관리 패턴이라고 부릅니다. 자세한 내용은 멀티테넌시 데이터 관리 패턴 섹션을 참조하세요. 설명은 다음 기준에 따라 제공됩니다.

격리: 멀티테넌시에서는 멀티 테넌트 간 데이터 격리 수준이 중요합니다. 격리는 기타 카테고리를 기준으로 선택된 항목에 따라 영향을 받습니다. 즉, 특정 규제 및 규정 준수 요구사항에 따라 높은 격리 수준이 필요할 수 있습니다.
민첩성: 인스턴스, 데이터베이스, 테이블 생성과 관련해서 테넌트에 대한 온보딩 및 오프로딩 작업을 쉽게 수행할 수 있는지를 나타냅니다.
작업: 일반 유지보수, 로깅, 백업, 재해 복구 작업 등 일반 작업, 테넌트 관련 작업, 데이터베이스 작업 및 관리 작업의 가용성 또는 복잡성을 나타냅니다.
확장: 이후 성장을 위한 원활한 확장 기능을 나타냅니다. 각 패턴 설명에는 해당 패턴으로 지원되는 테넌트 수가 포함되어 있습니다.
성능: 각 테넌트에 배타적 리소스를 할당하고, 시끄러운 이웃(noisy neighbor) 현상을 해결하고, 각 테넌트에 대해 예측 가능한 읽기 및 쓰기 성능 지원 기능을 나타냅니다.
규제 및 규정 준수: 리소스 및 유지보수 작업의 완전한 격리를 요구하는 규제 수준이 높은 업계 및 국가의 요구사항을 해결할 수 있는 기능을 나타냅니다. 예를 들어 프랑스 데이터 상주 요구사항에 따르면 개인 식별 정보가 물리적으로 프랑스 내에 배타적으로 저장되어야 합니다.

다음 섹션에서는 이러한 기준에 따라 각 데이터 관리 패턴을 자세히 설명합니다. 특정 테넌트 집합에 대해 데이터 관리 패턴을 선택할 때 동일한 기준을 사용합니다.

멀티테넌시 데이터 관리 패턴

다음 섹션에서는 인스턴스, 데이터베이스, 스키마, 테이블이라는 4개의 기본 데이터 관리 패턴에 대해 설명합니다.

인스턴스

완전한 격리를 제공하기 위해 인스턴스 데이터 관리 패턴은 고유 Spanner 인스턴스 및 데이터베이스에 각 테넌트 데이터를 저장합니다. Spanner 인스턴스는 하나 이상의 데이터베이스를 포함할 수 있습니다. 이 패턴에서는 데이터베이스 하나만 생성됩니다. 앞에서 설명한 HR 애플리케이션의 경우 각 고객 조직에 대해 하나의 데이터베이스가 있는 개별 Spanner 인스턴스가 생성됩니다.

다음 다이어그램에 표시된 것처럼 데이터 관리 패턴에 인스턴스당 하나의 테넌트가 포함됩니다.

인스턴스 데이터 관리 패턴은 인스턴스당 단일 테넌트를 저장합니다.

각 테넌트에 대해 개별 인스턴스를 지정하면 개별 Google Cloud 프로젝트를 사용하여 여러 테넌트에 대해 개별 신뢰 경계를 얻을 수 있습니다. 추가 이점은 각 테넌트의 위치를 기준으로 리전에 따라 또는 여러 리전에 따라 각 인스턴스 구성을 선택할 수 있으므로, 위치 유연성 및 성능을 최적화할 수 있다는 것입니다.

이 아키텍처는 임의 개수의 테넌트로 쉽게 확장될 수 있습니다. SaaS는 엄격한 제한 없이 원하는 리전에서 임의 개수의 인스턴스를 만들 수 있습니다.

다음 표에서는 인스턴스 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.

기준	인스턴스 - 인스턴스 데이터 관리 패턴당 테넌트 1개
격리	최대 격리 수준 데이터 리소스 공유 없음
민첩성	온보딩 또는 오프로딩 시 상당한 수준의 설정 또는 해제 필요: Spanner 인스턴스 인스턴스별 보안 인스턴스별 연결 코드형 인프라(IaC)를 통해 온보딩 및 오프로딩을 자동화할 수 있음
작업	각 테넌트의 독립 백업 별도의 유연한 백업 일정 운영 오버헤드 높음 관리 및 유지보수할 인스턴스 수 많음(확장, 모니터링, 로깅 및 성능 조정)
확장	확장성이 높은 데이터베이스 노드 추가로 무제한 성장 테넌트 수 무제한 각 테넌트에 사용 가능한 Spanner 인스턴스
성능	개별 인스턴스의 각 테넌트 리소스 경합 없음 각 테넌트에 대한 맞춤 성능 조정 및 문제 해결
규제 및 규정 준수 요구사항	특정 리전에 데이터 저장 비즈니스 또는 정부 요구에 따라 특정 보안, 백업, 감사 프로세스 구현

주요 핵심은 다음과 같습니다.

장점: 높은 격리 수준
단점: 가장 큰 운영 오버헤드

인스턴스 데이터 관리 패턴은 다음 시나리오에 적합합니다.

여러 테넌트가 넓은 리전 범위에 분산되어 있고 지역화된 솔루션이 필요합니다.
일부 테넌트의 규제 및 규정 준수 요구사항에 따라 더 높은 수준의 보안 및 감사 프로토콜이 요구됩니다.
각 테넌트의 크기가 서로 크게 달라서 볼륨 및 트래픽이 높은 테넌트 간의 리소스 공유로 인해 경합 및 상호 성능 저하가 일어날 수 있습니다.

데이터베이스

데이터베이스 데이터 관리 패턴에서 각 테넌트는 단일 Spanner 인스턴스 내의 데이터베이스에 상주합니다. 여러 데이터베이스가 단일 인스턴스에 상주할 수 있습니다. 테넌트 수에 비해 인스턴스 하나로 부족하면 여러 인스턴스를 만듭니다. 이 패턴은 단일 Spanner 인스턴스가 여러 테넌트 간에 공유된다는 것을 의미합니다.

Spanner에는 인스턴스당 데이터베이스 100개의 엄격한 제한이 적용됩니다. 이러한 제한은 SaaS 제공업체가 고객을 100개 이상으로 확장해야 할 경우 Spanner 인스턴스를 여러 개 만들어 사용해야 한다는 것을 의미합니다.

HR 애플리케이션의 경우 SaaS 제공업체는 Spanner 인스턴스에서 개별 데이터베이스가 있는 각 테넌트를 만들고 관리합니다.

다음 다이어그램에 표시된 것처럼 데이터 관리 패턴에 데이터베이스당 하나의 테넌트가 포함됩니다.

데이터베이스 데이터 관리 패턴이 데이터베이스당 하나의 테넌트를 저장합니다.

데이터베이스 데이터 관리 패턴은 여러 테넌트의 데이터에 대해 데이터베이스 수준에서 논리적 격리를 수행합니다. 하지만 단일 Spanner 인스턴스이기 때문에 모든 테넌트 데이터베이스가 동일한 리전 구성 및 기본 컴퓨팅과 스토리지 설정을 공유합니다.

다음 표에서는 데이터베이스 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.

기준	데이터베이스 - 데이터베이스 데이터 관리 패턴당 테넌트 1개
격리	데이터베이스 수준에서 완전한 논리적 격리 기본 인프라 리소스 공유
민첩성	데이터베이스 및 모든 특정 보안 제어를 만들거나 삭제하기 위한 작업 필요 IaC를 통한 온보딩 및 오프로딩 자동화 지원
작업	각 테넌트의 독립 백업 유연한 일정 예약 인스턴스 패턴과 비교할 때 낮은 운영 오버헤드 하나의 인스턴스로 최대 100개 데이터베이스 모니터링
확장	확장성이 높은 데이터베이스 무제한 인스턴스 수천 개의 노드 허용 인스턴스당 데이터베이스 100개 제한 테넌트 100개마다 새 Spanner 인스턴스 만들기
성능	여러 데이터베이스 간 리소스 경합 Spanner 인스턴스 노드 간 데이터베이스 분산 데이터베이스 간 인프라 공유 시끄러운 이웃(Noisy neighbor)으로 성능 영향
규제 및 규정 준수 요구사항	특정 데이터 상주 규제 요구사항을 충족시키기 위해 위치 리전이 인스턴스 리전과 일치해야 함

주요 핵심은 다음과 같습니다.

장점: 높은 격리 수준
단점: 인스턴스당 테넌트 수 제한, 위치 유연성 없음

데이터베이스 데이터 관리 패턴은 다음 시나리오에 가장 적합합니다.

프랑스 또는 영국과 같이 여러 고객이 동일한 데이터 거주지에 있고, 동일한 규제 기관의 영향을 받습니다.
테넌트에 시스템 기반 데이터 분리 및 백업/복원이 필요하지만, 인프라 리소스 공유가 지원됩니다.

스키마

스키마 데이터 관리 패턴에서는 단일 스키마를 구현하는 단일 데이터베이스가 멀티 테넌트에 사용되며, 개별 테이블 집합이 각 테넌트의 데이터에 사용됩니다. 이러한 테이블은 테이블 이름에 tenant ID를 프리픽스 또는 서픽스로 포함하여 구분될 수 있습니다.

각 테넌트에 대해 개별 테이블 집합을 사용하는 이 데이터 관리 패턴은 앞에 설명한 옵션(인스턴스 및 데이터베이스 관리 패턴)에 비해 훨씬 낮은 격리 수준을 제공합니다. 이 패턴은 또한 온보딩을 단순화합니다. 여기에는 새 테이블과 연관된 참조 무결성 및 인덱스 만들기가 포함됩니다.

한 가지 중요한 주의 사항은 Identity and Access Management(IAM)를 통한 Spanner에 대한 액세스 권한이 인스턴스 또는 데이터베이스 수준에서만 제공된다는 것입니다. 테이블 수준에서는 액세스 권한이 제공될 수 없습니다. 또한 데이터베이스당 테이블이 5,000개로 제한됩니다. 많은 고객들에 있어서 이러한 제한은 애플리케이션 사용에 영향을 줍니다.

또한 각 고객에 대해 개별 테이블을 사용함으로써 스키마 업데이트 작업의 백로그가 대량으로 생성될 수 있습니다. 이러한 백로그는 분석하는 데 시간이 오래 걸립니다.

HR 애플리케이션의 경우 SaaS 제공업체는 customer1_employee, customer1_payroll, customer1_department와 같이 테이블 이름에 tenant ID를 프리픽스로 사용해서 각 고객에 대해 테이블 집합을 만들 수 있습니다.

다음 다이어그램에 표시된 것처럼 스키마 데이터 관리 패턴에는 각 테넌트에 대해 하나의 테이블 집합이 포함됩니다.

스키마 데이터 관리 패턴에는 각 테넌트에 대해 하나의 테이블 집합이 포함됩니다.

다음 표에서는 스키마 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.

기준	스키마 - 각 테넌트 데이터 관리 패턴에 대해 하나의 테이블 집합을 포함합니다.
격리	낮은 격리 수준 테이블 수준 보안 없음
민첩성	고객 온보딩이 간편함 새 테이블 만들기 연결된 키 및 색인 만들기 고객 오프로딩은 테이블 삭제를 의미함 데이터베이스 내에 잇는 다른 테넌트에 대해 일시적으로 부정적인 성능 영향을 줄 수 있음
작업	테넌트에 대한 개별 작업 없음 백업, 모니터링, 로깅을 개별 애플리케이션 기능 또는 유틸리티 스크립트로 구현해야 함
확장	수천 개 노드 무제한 테넌트 성장 단일 데이터베이스에 5,000개 테이블만 포함 가능 각 데이터베이스에 있는 테넌트의 floor(5,000/<테넌트의 테이블 수>) 수만 데이터베이스가 5,000개 테이블을 초과할 경우 추가 테넌트에 대한 새 데이터베이스 추가
성능	높은 수준의 리소스 경합 발생 가능 각 테이블 집합에 대해 색인을 개별적으로 설계하여 성능 향상 보장
규제 및 규정 준수 요구사항	특정 데이터 상주 규제 요구사항을 충족시키기 위해 위치 리전이 일치해야 함 특정 보안 구현 및 제어 감사로 동일 데이터베이스에 있는 모든 테넌트에 영향을 줌

주요 핵심은 다음과 같습니다.

장점: 온보딩이 간편함
단점: 운영 오버헤드 높고, 테이블 수준에서 보안 제어 없음

스키마 데이터 관리 패턴은 다음 시나리오에 가장 적합합니다.

쉬운 유지보수와 비교할 때 엄격한 데이터 보안 격리가 중요 관심사가 아닌 여러 부서의 요구를 충족시켜 주는 내부 애플리케이션
법률 또는 규제 요구사항에 따라 엄격한 데이터 분리가 필요하지 않은 멀티 테넌트 애플리케이션

각 집합이 하나의 테넌트를 나타내는 여러 테이블 집합을 만들 수 있지만, 이 방식은 데이터베이스의 관점에서 가장 이상적이지 않은 패턴입니다. 주요 이유는 테이블이 명명 규칙을 따라야 하기 때문입니다. 애플리케이션 및 모든 데이터베이스 도구(예를 들어 IDE 및 스키마 마이그레이션 도구)가 명명 규칙을 이해해야 합니다. 또한 테넌트당 테이블 수가 비교적 큰 경우, 스키마 데이터 관리 패턴이 그에 따른 확장을 제공하지 않습니다.

더 나은 방법은 테넌트당 데이터베이스 하나로 이동하고 인스턴스 수를 늘리거나 테이블 데이터 관리 패턴으로 이동하는 것입니다.

테이블

최종 데이터 관리 패턴은 공통 테이블 집합으로 여러 테넌트에 서비스를 제공합니다. 각 테이블에는 여러 테넌트에 대한 데이터가 포함됩니다. 이 데이터 관리 패턴은 인프라부터 스키마 및 데이터 모델까지 모든 것이 여러 테넌트 간에 공유되는 매우 높은 멀티테넌시 수준을 나타냅니다. 테이블 내에서 행은 tenant ID를 키의 첫 번째 요소로 사용하여 기본 키를 기준으로 분할됩니다. 확장 관점에서 Spanner는 제한 없이 테이블을 확장할 수 있기 때문에 이 패턴을 가장 잘 지원합니다.

HR 애플리케이션의 경우 급여 테이블의 기본 키는 customerID 및 payrollID의 조합일 수 있습니다.

다음 다이어그램에 표시된 것처럼 테이블 데이터 관리 패턴에 여러 테넌트에 대해 하나의 테이블이 포함됩니다.

테이블 데이터 관리 패턴은 여러 테넌트에 대해 하나의 테이블을 사용합니다.

스키마 패턴과 비슷하게, 이 테이블 패턴의 데이터 액세스는 여러 테넌트에 대해 개별적으로 제어될 수 없습니다. 더 적은 수의 테이블을 사용하면 각 테넌트에 고유 데이터베이스 테이블이 포함되었을 때 스키마 업데이트 작업이 더 빠르게 완료됩니다. 대부분의 경우 이 접근 방식은 온보딩, 오프로딩, 작업을 단순화합니다.

다음 표에서는 테이블 데이터 관리 패턴이 여러 기준에 미치는 영향을 간단히 보여줍니다.

기준	테이블 - 여러 테넌트 데이터 관리 패턴에 대해 테이블 1개
격리	낮은 격리 수준 테넌트 수준 보안 없음
민첩성	온보딩 시 데이터베이스 측에서 설정이 필요하지 않음 애플리케이션이 기존 테이블에 데이터를 직접 기록할 수 있음 오프로딩은 테이블에서 고객의 행 삭제를 의미함
작업	백업, 모니터링, 로깅을 포함하여 테넌트에 대한 개별 작업 없음 테넌트 수 증가에 따라 오버헤드 증가가 거의 없음
확장	수천 개 노드로 확장 모든 수준의 테넌트 성장 수용 가능 무제한 테넌트 수 지원
성능	패턴이 Spanner 컨텍스트에서 효과적으로 작동 내부 분산 스토리지, 처리, 부하 분산을 이 패턴으로 쉽게 수행 가능 기본 키 공간을 신중하게 설계하지 않으면 시끄러운 이웃(noisy neighbor)과 같은 높은 수준의 리소스 경합 발생 가능 동시 실행 및 배포 방지 가능 권장사항을 따르는 것이 중요 테넌트 데이터를 삭제하면 로드에 일시적 영향을 줄 수 있음
규제 및 규정 준수 요구사항	특정 데이터 상주 규제 요구사항을 충족시키기 위해 위치가 일치해야 함 패턴이 시스템 수준 파티션 나누기를 제공할 수 없음(인스턴스 또는 데이터베이스 패턴과 비교) 특정 보안 구현 및 제어 감사가 모든 테넌트에 영향을 줌

주요 핵심은 다음과 같습니다.

장점: 확장성 높음, 운영 오버헤드 낮음
단점: 리소스 경합 높음, 각 테넌트에 대한 보안 제어 부족

이 패턴은 다음 시나리오에 가장 적합합니다.

쉬운 유지보수와 비교할 때 엄격한 데이터 보안 격리가 중요 관심사가 아닌 여러 부서의 요구를 충족시켜 주는 내부 애플리케이션
동시에 리소스 프로비저닝을 최소화할 때 무료 등급 애플리케이션 기능을 사용하여 테넌트에 대한 리소스 공유 최대화

데이터 관리 패턴 및 테넌트 수명 주기 관리

다음 표에서는 모든 기준에서 여러 데이터 관리 패턴을 대략적으로 비교해서 보여줍니다.

	인스턴스	데이터베이스	스키마	테이블
격리	완전	완전	낮음	가장 낮음
민첩성	낮음	보통	보통	가장 높음
작업 편의성	높음	높음	낮음	낮음
확장	높음	제한됨	잠재적으로 매우 제한됨	높음
성능*	높음	보통	보통	잠재적으로 높음
규제 및 규정 준수	가장 높음	높음	낮음	낮음

* 성능은 스키마 설계 및 쿼리 권장사항에 따라 크게 달라집니다. 여기에 표시된 값은 평균적인 기대 값입니다.

특정 멀티 테넌트 애플리케이션에 가장 적합한 데이터 관리 패턴은 해당 기준에 따라 가장 많은 요구사항을 충족시켜 주는 패턴입니다. 특정 기준이 요구되지 않을 경우에는 해당 기준이 있는 행을 무시해도 됩니다.

결합된 데이터 관리 패턴

멀티 테넌트 애플리케이션의 요구사항을 해결하는 데에 단일 데이터 관리 패턴으로 충분한 경우가 종종 있습니다. 이 경우 설계 시 단일 데이터 관리 패턴을 가정할 수 있습니다.

하지만 무료 등급, 일반 등급, 엔터프라이즈 등급을 지원하는 멀티 테넌트 애플리케이션과 같이 일부 멀티 테넌트 애플리케이션에는 동시에 여러 개의 데이터 관리 패턴이 필요합니다.

무료 등급:
- 비용 효율적이어야 함
- 데이터 볼륨 상한선이 있어야 함
- 일반적으로 제한된 기능 지원
- 무료 등급에 적합한 후보는 테이블 데이터 관리 패턴입니다.
  - 테넌트 관리가 단순함
  - 특정 또는 배타적인 테넌트 리소스를 만들 필요가 없음
일반 등급:
- 특별히 강력한 확장 또는 격리 요구 사항이 있지 않은 결제 클라이언트에 적합합니다.
- 일반 등급에 적합한 후보는 스키마 데이터 관리 패턴 또는 데이터베이스 데이터 관리 패턴입니다.
  - 테이블 및 색인이 테넌트에 대해 배타적임
  - 데이터베이스 데이터 관리 패턴에서 백업이 쉬움
  - 스키마 데이터 관리 패턴에서 백업이 지원되지 않음
    - 테넌트 백업이 Spanner 외부의 유틸리티로 구현되어야 함
엔터프라이즈 등급:
- 일반적으로 모든 측면에서 완전한 자율성이 지원되는 고급 계층
- 전용 확장 및 완전한 격리를 포함하는 전용 리소스가 테넌트에 포함됨
- 엔터프라이즈 등급에는 인스턴스 데이터 관리 패턴이 적합합니다.

권장사항은 서로 다른 데이터 관리 패턴을 서로 다른 데이터베이스에서 유지 관리하는 것입니다. 하나의 Spanner 데이터베이스에 여러 데이터 관리 패턴을 결합할 수도 있지만, 이렇게 하면 애플리케이션의 액세스 논리 및 수명 주기 작업을 구현하는 것이 어렵습니다.

애플리케이션 설계 섹션에서는 단일 데이터 관리 패턴 또는 여러 데이터 관리 패턴을 사용할 때 적용되는 일부 멀티 테넌트 애플리케이션 설계 고려 사항을 설명합니다.

테넌트 수명 주기 관리

테넌트에는 수명 주기가 있습니다. 따라서 멀티 테넌트 애플리케이션 내에서 해당 관리 작업을 구현해야 합니다. 테넌트 만들기, 업데이트, 삭제와 같은 기본 작업 외에도 다음과 같은 추가 데이터 관련 작업을 고려하세요.

테넌트 데이터 내보내기:
- 테넌트를 삭제할 때는 데이터를 먼저 내보내고 데이터 세트를 여기에 제공하는 것이 좋습니다.
- 테이블 또는 스키마 데이터 관리 패턴을 사용할 때 멀티 테넌트 애플리케이션 시스템이 내보내기를 구현하거나 이를 데이터베이스 기능(데이터베이스 내보내기)에 매핑해야 합니다.
테넌트 데이터 백업:
- 인스턴스 또는 데이터베이스 데이터 관리 패턴을 사용하고 개별 테넌트에 대해 데이터를 백업할 때 데이터베이스의 내보내기 또는 백업 기능을 사용합니다.
- 스키마 또는 테이블 데이터 관리 패턴을 사용하고 개별 테넌트에 대해 데이터를 백업할 때 멀티 테넌트 애플리케이션이 이 작업을 구현해야 합니다. Spanner 데이터베이스는 어떤 데이터가 어떤 테넌트에 속하는지 구분할 수 없습니다.
테넌트 데이터 이동:
- 한 데이터 관리 패턴에서 다른 패턴으로 테넌트를 이동하거나 동일한 데이터 관리 패턴 내에서 인스턴스 또는 데이터베이스 간에 테넌트를 이동하기 위해서는 테이블 데이터 관리 패턴에서 데이터를 추출하고 이 데이터를 데이터베이스 데이터 관리 패턴에 삽입하는 과정이 필요합니다.
  - 애플리케이션 다운타임이 가능한 경우 내보내기/가져오기를 수행합니다.
  - 다운타임이 가능하지 않으면 다운타임 없는 데이터베이스 마이그레이션을 수행합니다.
- 시끄러운 이웃(noisy-neighbor) 상황을 완화하는 것도 테넌트를 이동하는 또 다른 이유입니다.

애플리케이션 설계

멀티 테넌트 애플리케이션을 설계할 때 테넌트 인식 비즈니스 논리를 구현합니다. 즉, 애플리케이션이 비즈니스 논리를 실행할 때마다 알려진 테넌트의 컨텍스트 내에 있어야 합니다.

데이터베이스 관점에서 애플리케이션 설계에서는 테넌트가 있는 데이터 관리 패턴에 대해 각 쿼리가 실행되어야 합니다. 다음 섹션에서는 멀티 테넌트 애플리케이션 설계의 중심 개념을 설명합니다.

동적 테넌트 연결 및 쿼리 구성

테넌트 데이터를 테넌트 애플리케이션 요청에 동적으로 매핑할 때는 매핑 구성이 사용됩니다.

데이터베이스 데이터 관리 패턴 또는 인스턴스 데이터 관리 패턴의 경우 연결 문자열만으로 테넌트 데이터에 충분히 액세스할 수 있습니다.
스키마 데이터 관리 패턴의 경우 올바른 테이블 이름을 확인해야 합니다.
테이블 데이터 관리 패턴의 경우 데이터베이스에 대해 쿼리를 실행해야 합니다. 적절한 조건자를 사용하여 특정 테넌트의 데이터를 가져옵니다.

테넌트는 4개의 데이터 관리 패턴 중 무엇에든 상주할 수 있습니다. 다음 매핑 구현은 동시에 모든 데이터 관리 패턴을 사용하는 멀티 테넌트 애플리케이션의 일반 사례에 대한 연결 구성을 해결합니다. 제공된 테넌트가 하나의 패턴에 상주할 때 일부 멀티 테넌트 애플리케이션은 모든 테넌트에 대해 하나의 데이터 관리 패턴을 사용합니다. 이 경우는 다음 매핑에 암시적으로 포함됩니다.

직원이 자신의 테넌트 ID로 로그인할 때와 같이 테넌트가 비즈니스 논리를 실행하는 경우 애플리케이션 논리는 해당 테넌트의 데이터 관리 패턴, 지정된 테넌트 ID에 대한 데이터 위치, 선택적으로 테이블 명명 규칙(스키마 패턴의 경우)을 확인해야 합니다.

이 애플리케이션 논리에는 테넌트-데이터 관리 패턴 매핑이 필요합니다. 다음 코드 샘플에서 connection string은 테넌트 데이터가 있는 데이터베이스를 나타냅니다. 이 샘플은 Spanner 인스턴스 및 데이터베이스를 식별합니다. 데이터 관리 패턴 인스턴스 및 데이터베이스의 경우 다음 코드만으로 애플리케이션이 쿼리를 연결하고 실행하는 데 충분합니다.

tenant id -> (data management pattern,
             database connection string,
             [table_prefix])

스키마 및 테이블 데이터 관리 패턴에는 추가 설계가 필요합니다.

스키마 데이터 관리 패턴

스키마 데이터 관리 패턴의 경우 동일한 데이터베이스 내에 여러 테넌트가 있습니다. 각 테넌트에는 고유 테이블 집합이 있습니다. 테이블은 해당 이름으로 구분됩니다. 어떤 테이블이 어떤 테넌트에 속할지는 결정적입니다.

한 가지 방법은 테이블 이름 앞에 테넌트 ID를 추가하는 것입니다. 예를 들어 EMPLOYEE 테이블은 ID가 356인 테넌트에 대해 T356_EMPLOYEE라고 불립니다. 매핑으로 반환된 데이터베이스에 쿼리를 전송하기 전 애플리케이션이 Ttenant ID 프리픽스를 각 테이블 앞에 추가해야 합니다.

또 다른 접근 방식은 테넌트에 대해 올바른 테이블을 찾을 수 있도록 쿼리에 사용되는 매핑 앞에 table_prefix를 추가하는 것입니다.

혼합 접근 방식도 가능합니다. 데이터 관리 패턴이 스키마 패턴이고 테이블 프리픽스가 비어 있으면 테이블 이름에 테넌트 ID를 추가하는 기본 매핑이 사용됩니다.

테이블 데이터 관리 패턴

테이블 데이터 관리 패턴에는 비슷한 설계가 필요합니다. 이 패턴에는 단일 스키마가 사용됩니다. 테넌트 데이터는 행으로 저장됩니다. 데이터에 올바르게 액세스하기 위해서는 적합한 테넌트를 선택하도록 각 쿼리에 조건자를 추가합니다.

적합한 테넌트를 찾기 위한 한 가지 방법은 각 테이블에 TENANT라는 열을 두는 것입니다. 열 값은 tenant ID입니다. 각 쿼리는 AND TENANT = tenant ID 조건자를 기존 WHERE 절에 추가하거나 WHERE 절에 AND TENANT = tenant ID 조건자를 추가해야 합니다.

데이터베이스에 연결하고 적합한 쿼리를 만들려면 애플리케이션 논리에 테넌트 식별자가 제공되어야 합니다. 이것은 매개변수로 전달되거나 스레드 컨텍스트로 저장될 수 있습니다.

일부 수명 주기 작업에서는 테넌트-매핑 관리 패턴 매핑 구성을 수정해야 합니다. 예를 들어 데이터 관리 패턴 간에 테넌트를 이동할 때, 데이터 관리 패턴 및 데이터베이스 연결 문자열을 업데이트해야 합니다. 또한 테이블 프리픽스를 업데이트해야 할 수 있습니다.

쿼리 생성 및 기여 분석

멀티 테넌트 애플리케이션의 기본 원칙은 여러 테넌트가 단일 클라우드 리소스를 공유할 수 있도록 하는 것입니다. 단일 Spanner 인스턴스에 단일 테넌트가 할당되는 경우를 제외하고 앞에서 설명한 데이터 관리 패턴은 이 카테고리에 포함됩니다.

리소스 공유는 데이터 공유의 범위를 벗어납니다. 모니터링 및 로깅도 공유됩니다. 예를 들어 테이블 데이터 관리 패턴 및 스키마 데이터 관리 패턴에서는 모든 테넌트에 대한 모든 쿼리가 동일한 감사 로그에 기록됩니다.

쿼리가 로깅되는 경우 해당 쿼리가 실행된 대상 테넌트를 확인하기 위해 쿼리 텍스트를 검사해야 합니다. 테이블 데이터 관리 패턴에서는 조건자를 파싱해야 합니다. 스키마 데이터 관리 패턴에서는 테이블 이름 중 하나를 파싱해야 합니다.

데이터베이스 데이터 관리 패턴 또는 인스턴스 데이터 관리 패턴에서는 쿼리 텍스트에 테넌트 정보가 포함되지 않습니다. 이러한 패턴에 대해 테넌트 정보를 가져오려면 테넌트-데이터 관리 패턴 매핑 테이블을 쿼리해야 합니다.

쿼리 텍스트를 파싱하지 않고 제공된 쿼리에 대해 테넌트를 확인하여 로그 및 쿼리를 분석하는 것이 더 쉬울 수 있습니다. 모든 데이터 관리 패턴에서 쿼리에 대한 테넌트를 동일하게 식별할 수 있는 한 가지 방법은 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}

테넌트 액세스 수명 주기 작업

설계 철학에 따라 멀티 테넌트 애플리케이션은 앞에서 설명한 데이터 수명 주기 작업을 직접 구현할 수도 있고 아니면 별도의 테넌트 관리 도구를 만들 수 있습니다.

구현 전략에 관계없이 동시에 실행되는 애플리케이션 논리 없이 수명 주기 작업을 실행해야 할 수 있습니다. 예를 들어 한 데이터 관리 패턴에서 다른 패턴으로 테넌트를 이동할 때는 데이터가 단일 데이터베이스에 없기 때문에 애플리케이션 논리가 실행될 수 없습니다. 데이터가 단일 데이터베이스에 있지 않으면 애플리케이션 관점에서 두 가지 추가 작업이 필요합니다.

테넌트 중지: 모든 애플리케이션 논리 액세스를 사용 중지하고 데이터 수명 주기 작업은 허용합니다.
테넌트 시작: 애플리케이션 논리가 테넌트의 데이터에 액세스할 수 있고, 애플리케이션 논리와 간섭되는 수명주기 작업은 사용 중지됩니다.

자주 사용되지는 않아도 긴급 테넌트 종료는 또 다른 중요한 수명 주기 작업일 수 있습니다. 위반이 의심되고 애플리케이션 논리는 물론 수명 주기 작업까지 테넌트 데이터에 대한 모든 액세스를 금지해야 할 경우 이 종료를 사용합니다. 위반은 데이터베이스 내부 또는 외부에서 시작될 수 있습니다.

긴급 상태를 삭제하는 일치 수명 주기 작업도 사용할 수 있어야 합니다. 이러한 작업은 상호 제어를 구현하기 위해 둘 이상의 관리자가 동시에 로그인하도록 요구할 수 있습니다.

애플리케이션 격리

여러 데이터 관리 패턴은 여러 가지 수준의 테넌트 데이터 격리를 지원합니다. 가장 높은 격리 수준(인스턴스)부터 가장 낮은 격리 수준(테이블)까지 여러 수준의 격리가 가능합니다.

멀티 테넌트 애플리케이션의 컨텍스트에서 비슷한 배포 결정을 내려야 합니다. 동일한 애플리케이션 배포를 사용하여 모든 테넌트가 해당 데이터에 액세스하나요(다른 데이터 관리 패턴 사용 가능)? 예를 들어 단일 Kubernetes 클러스터가 모든 테넌트를 지원할 수 있고, 테넌트가 해당 데이터에 액세스할 때 동일한 클러스터가 비즈니스 논리를 실행합니다.

또는 데이터 관리 패턴의 경우와 같이 다른 테넌트가 다른 애플리케이션 배포에 연결될 수 있습니다. 큰 테넌트는 배타적인 애플리케이션 배포에 액세스할 수 있고, 무료 등급의 작은 테넌트는 애플리케이션 배포를 공유할 수 있습니다.

이 문서에 설명된 데이터 관리 패턴을 해당 애플리케이션 데이터 관리 패턴과 직접 일치시키는 대신 모든 테넌트가 단일 애플리케이션 배포를 공유하도록 데이터베이스 데이터 관리 패턴을 사용할 수 있습니다. 데이터베이스 데이터 관리 패턴을 지정하고, 이러한 모든 테넌트가 단일 애플리케이션 배포를 공유하도록 할 수 있습니다.

멀티테넌시는 특히 리소스 효율성이 중요한 역할을 수행할 때 중요한 애플리케이션 설계 데이터 관리 패턴입니다. Spanner는 여러 가지 데이터 관리 패턴을 지원합니다. 멀티 테넌트 애플리케이션을 구현할 때 이를 사용하세요. Spanner의 매우 높은 확장성 및 엄격한 SLA와 함께 대규모 멀티 테넌트 애플리케이션 배포에 이상적인 데이터베이스입니다.

다음 단계

Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기