데이터는 사용자와 고객의 중요한 비즈니스 정보를 나타내기 때문에 솔루션에서 가장 중요한 부분으로 간주됩니다. 따라서 데이터를 신중하게 관리하는 것이 중요합니다. 다중 테넌트 시스템에 대한 스토리지 또는 데이터 구성 요소를 계획할 때 테넌트의 데이터를 공유하거나 격리하는 방법을 결정해야 합니다.
이 문서에서는 다중 테넌트 시스템에 데이터를 저장하는 방법을 결정할 때 솔루션 설계자에게 필수적인 주요 고려 사항 및 요구 사항에 대한 지침을 제공합니다. 그런 다음, 스토리지 및 데이터 서비스에 다중 테넌트를 적용하기 위한 몇 가지 일반적인 패턴과 피해야 할 몇 가지 안티패턴을 제안합니다. 마지막으로, 몇 가지 특정 상황에 대한 대상 지침을 제공합니다.
주요 고려 사항 및 요구 사항
Azure Well-Architected Framework의 핵심 요소에 맞게 다양한 관점에서 스토리지 및 데이터 서비스에 사용하는 방법을 고려하는 것이 중요합니다.
확장
데이터를 저장하는 서비스를 사용할 때는 테넌트 수와 저장하는 데이터 볼륨을 고려해야 합니다. 적은 수의 테넌트(예: 5개 이하)가 있고 각 테넌트에 소량의 데이터를 저장하는 경우 스케일링 성능이 뛰어난 데이터 스토리지 접근 방식을 계획하거나 데이터 리소스를 관리하는 완전히 자동화된 접근 방식을 구축하는 데 많은 노력이 낭비될 수 있습니다. 하지만 성장함에 따라 데이터 및 스토리지 리소스의 크기를 조정하고 관리에 자동화를 적용하는 명확한 전략을 통해 점점 더 많은 이점을 얻을 수 있습니다. 테넌트가 50개 이상이거나 해당 수준의 규모에 도달하려는 경우 스케일링을 주요 고려 사항으로 사용하여 데이터 및 스토리지 접근 방식을 디자인하는 것이 특히 중요합니다.
스케일링할 범위를 고려하고 해당 수준의 규모에 맞게 데이터 스토리지 아키텍처 접근 방식을 명확하게 계획합니다.
성능 예측 가능성
다중 테넌트 데이터 및 스토리지 서비스는 특히 노이지 네이버 문제에 취약합니다. 테넌트가 서로의 성능에 영향을 줄 수 있는지 여부를 고려하는 것이 중요합니다. 예를 들어 테넌트에 시간이 지남에 따라 사용 패턴의 최대 사용량이 겹치나요? 모든 고객이 매일 동시에 솔루션을 사용하나요, 아니면 요청이 균등하게 분산되나요? 이러한 요소는 디자인해야 하는 격리 수준, 프로비저닝해야 하는 리소스의 양, 테넌트 간에 리소스를 공유할 수 있는 정도에 영향을 줍니다.
이 결정의 일부로 Azure의 리소스 및 요청 할당량을 고려하는 것이 중요합니다. 예를 들어 테넌트의 모든 데이터를 포함하도록 단일 스토리지 계정을 배포한다고 가정합니다. 초당 특정 수의 스토리지 작업을 초과하는 경우 Azure Storage는 애플리케이션의 요청을 거부하고 모든 테넌트에 영향을 줍니다. 이를 제한 동작이라고합니다. 제한된 요청을 모니터링하는 것이 중요합니다. 자세한 내용은 Azure 서비스에 대한 다시 시도 지침을 참조하세요.
데이터 격리
다중 테넌트 데이터 서비스를 포함하는 솔루션을 디자인할 때는 일반적으로 서로 다른 옵션과 데이터 격리 수준이 있으며, 각각 고유한 이점과 장단점이 있습니다. 다음은 그 예입니다.
- Azure Cosmos DB를 사용하는 경우 각 테넌트에 대해 별도의 컨테이너를 배포할 수 있으며 여러 테넌트 간에 데이터베이스와 계정을 공유할 수 있습니다. 또는 필요한 격리 수준에 따라 각 테넌트에 대해 서로 다른 데이터베이스 또는 계정을 배포하는 것이 좋습니다.
- Blob 데이터에 Azure Storage를 사용하는 경우 각 테넌트에 대해 별도의 Blob 컨테이너를 배포하거나 별도의 스토리지 계정을 배포할 수 있습니다.
- Azure SQL을 사용하는 경우 공유 데이터베이스에서 별도의 테이블을 사용하거나 각 테넌트에 대해 별도의 데이터베이스 또는 서버를 배포할 수 있습니다.
- 모든 Azure 서비스에서 단일 공유 Azure 구독 내에서 리소스를 배포하는 것을 고려하거나 여러 Azure 구독(테넌트당 하나)을 사용할 수 있습니다.
모든 상황에서 작동하는 단일 솔루션은 없습니다. 선택하는 옵션은 여러 가지 요인과 테넌트 요구 사항에 따라 달라집니다. 예를 들어 테넌트가 특정 규정 준수 또는 규정 표준을 충족해야 하는 경우 더 높은 수준의 격리를 적용해야 할 수 있습니다. 마찬가지로 고객의 데이터를 물리적으로 격리하기 위한 상업적 요구 사항이 있거나 노이지 네이버 문제를 방지하기 위해 격리를 적용해야 할 수 있습니다. 또한 테넌트가 자체 암호화 키를 사용해야 하거나, 개별 백업 및 복원 정책이 있거나, 데이터가 서로 다른 지리적 위치에 저장되어 있어야 하는 경우 다른 테넌트에서 격리하거나 비슷한 정책을 가진 테넌트와 그룹화해야 할 수 있습니다.
구현의 복잡성
구현의 복잡성을 고려하는 것이 중요합니다. 요구 사항을 충족하면서 아키텍처를 최대한 간단하게 유지하는 것이 좋습니다. 스케일링할 때 점점 더 복잡해지는 아키텍처나 개발 및 유지 관리할 리소스나 전문 지식이 없는 아키텍처에 커밋하지 마세요.
마찬가지로 솔루션이 많은 테넌트로 스케일링할 필요가 없거나 성능 또는 데이터 격리에 대한 우려가 없는 경우 솔루션을 단순하게 유지하고 불필요한 복잡성을 추가하지 않는 것이 좋습니다.
다중 테넌트 데이터 솔루션의 특정 관심사는 지원하는 사용자 지정 수준입니다. 예를 들어 테넌트가 데이터 모델을 확장하거나 사용자 지정 데이터 규칙을 적용할 수 있나요? 이 요구 사항을 미리 디자인해야 합니다. 개별 테넌트에 대한 사용자 지정 인프라를 포크하거나 제공하지 않습니다. 사용자 지정된 인프라는 크기를 조정하고, 솔루션을 테스트하고, 업데이트를 배포하는 기능을 억제합니다. 대신 기능 플래그 및 다른 형태의 테넌트 구성을 사용하는 것이 좋습니다.
관리 및 운영의 복잡성
솔루션을 운영하려는 방법과 다중 테넌트 접근 방식이 운영 및 프로세스에 미치는 영향을 고려합니다. 예시:
- 관리: 일반 기본 테넌트 활동과 같은 테넌트 간 관리 작업을 고려합니다. 여러 계정, 서버 또는 데이터베이스를 사용하는 경우 각 테넌트에 대한 작업을 어떻게 시작하고 모니터링하나요?
- 모니터링 및 계량: 테넌트 모니터링 또는 계량의 경우 솔루션이 메트릭을 보고하는 방법과 요청을 트리거한 테넌트에 쉽게 연결할 수 있는지 여부를 고려합니다.
- 보고: 격리된 테넌트 간에 데이터를 보고하려면 각 데이터베이스에서 개별적으로 쿼리를 실행한 다음 결과를 집계하는 대신 각 테넌트가 중앙 집중식 데이터 웨어하우스에 데이터를 게시해야 할 수 있습니다.
- 스키마 업데이트: 스키마를 적용하는 데이터베이스를 사용하는 경우 자산 전체에 스키마 업데이트를 배포하는 방법을 계획합니다. 애플리케이션에서 특정 테넌트의 데이터베이스 쿼리에 사용할 스키마 버전을 어떻게 알고 있는지 고려합니다.
- 요구 사항: 테넌트의 고가용성 요구 사항(예: 가동 시간 서비스 수준 계약 또는 SLA) 및 재해 복구 요구 사항(예: 복구 시간 목표, RTO, 복구 지점 목표 또는 RPO)을 고려합니다. 테넌트의 기대치가 다른 경우 각 테넌트의 요구 사항을 충족할 수 있나요?
- 마이그레이션: 테넌트가 다른 유형의 서비스, 다른 배포 또는 다른 지역으로 이동해야 하는 경우 어떻게 마이그레이션합니까?
비용
일반적으로 배포 인프라에 대한 테넌트 밀도가 높을수록 해당 인프라를 프로비저닝하는 비용이 낮아질 수 있습니다. 그러나 공유 인프라는 노이지 네이버 문제와 같은 문제의 가능성을 증가하므로 장단점이 신중하게 고려됩니다.
고려해야 할 접근 방식 및 패턴
Azure 아키텍처 센터의 여러 디자인 패턴은 다중 테넌트 스토리지 및 데이터 서비스와 관련이 있습니다. 하나의 패턴을 일관되게 따르도록 선택할 수 있습니다. 또는 패턴 혼합 및 일치를 고려할 수 있습니다. 예를 들어 대부분의 테넌트에 다중 테넌트 데이터베이스를 사용할 수 있지만 더 많은 비용을 지불하거나 비정상적인 요구 사항이 있는 테넌트에 대해 단일 테넌트 스탬프를 배포할 수 있습니다. 마찬가지로 스탬프 내에서 다중 테넌트 데이터베이스 또는 분할된 데이터베이스를 사용하는 경우에도 배포 스탬프를 사용하여 스케일링하는 것이 좋습니다.
배포 스탬프 패턴
배포 스탬프 패턴을 사용하여 다중 테넌트 솔루션을 지원하는 방법에 대한 자세한 내용은 개요를 참조하세요.
공유 다중 테넌트 데이터베이스 및 파일 저장소
공유 다중 테넌트 데이터베이스, 스토리지 계정 또는 파일 공유를 배포하고 모든 테넌트에서 공유하는 것이 좋습니다.
이 방법은 인프라에 대한 테넌트의 밀도가 가장 높으므로 모든 접근 방식에서 가장 낮은 비용으로 제공되는 경향이 있습니다. 또한 관리, 백업 및 보안을 위한 단일 데이터베이스 또는 리소스가 있기 때문에 관리 오버헤드를 줄이는 경우가 많습니다.
그러나 공유 인프라를 사용하는 경우 고려해야 할 몇 가지 주의 사항이 있습니다.
- 크기 조정 제한: 단일 리소스를 사용하는 경우 해당 리소스의 지원되는 규모와 제한을 고려합니다. 예를 들어 하나의 데이터베이스 또는 파일 저장소의 최대 크기 또는 최대 처리량 한도는 아키텍처가 단일 데이터베이스에 의존하는 경우 결국 하드 차단이 됩니다. 이 패턴을 선택하기 전에 달성해야 하는 최대 규모를 신중하게 고려하고 현재 및 향후 제한과 비교합니다.
- 노이즈 이웃:노이즈 네이버 문제는 특히 사용량이 많거나 다른 테넌트보다 더 높은 워크로드를 생성하는 테넌트가 있는 경우 요인이 될 수 있습니다. 이러한 효과를 완화하기 위해 제한 패턴 또는 속도 제한 패턴을 적용하는 것이 좋습니다.
- 각 테넌트 모니터링: 활동을 모니터링하고 단일 테넌트에 대한 소비 량을 측정하는 데 어려움이 있을 수 있습니다. Azure Cosmos DB와 같은 일부 서비스는 각 요청에 대한 리소스 사용량에 대한 보고를 제공하므로 이 정보를 추적하여 각 테넌트에 대한 소비를 측정할 수 있습니다. 다른 서비스는 동일한 수준의 세부 정보를 제공하지 않습니다. 예를 들어 파일 용량에 대한 Azure Files 메트릭은 프리미엄 공유를 사용하는 경우에만 파일 공유 차원별로 사용할 수 있습니다. 그러나 표준 계층은 스토리지 계정 수준에서만 메트릭을 제공합니다.
- 테넌트 요구 사항: 테넌트에는 보안, 백업, 가용성 또는 스토리지 위치에 대한 요구 사항이 다를 수 있습니다. 이러한 구성이 단일 리소스의 구성과 일치하지 않는 경우 이를 수용하지 못할 수 있습니다.
- 스키마 사용자 지정: 관계형 데이터베이스 또는 데이터의 스키마가 중요한 다른 상황에서 작업하는 경우 테넌트 수준 스키마 사용자 지정이 어렵습니다.
분할 패턴
분할 패턴에는 각각 하나 이상의 테넌트 데이터가 포함된 분할된 데이터베이스라는 여러 개의 개별 데이터베이스를 배포하는 작업이 포함됩니다. 배포 스탬프와 달리 분할된 데이터베이스는 전체 인프라가 중복되었음을 의미하지는 않습니다. 솔루션에서 다른 인프라를 복제하거나 분할하지 않고 데이터베이스를 분할할 수도 있습니다.
분할은 파티셔닝과 밀접한 관련이 있으며 용어는 종종 서로 바꿔서 사용됩니다. 가로, 세로, 기능 데이터 파티셔닝 지침을 고려합니다.
분할 패턴은 매우 많은 수의 테넌트로 스케일링할 수 있습니다. 또한 워크로드에 따라 분할된 데이터베이스에 대한 테넌트의 고밀도를 달성할 수 있으므로 비용이 매력적일 수 있습니다. 분할 패턴을 사용하여 Azure 구독 및 서비스 할당량, 제한, 제약 조건을 해결할 수도 있습니다.
Azure Cosmos DB와 같은 일부 데이터 저장소는 분할 또는 파티셔닝에 대한 기본 지원을 제공합니다. Azure SQL과 같은 다른 솔루션을 사용하는 경우 분할 인프라를 빌드하고 지정된 테넌트에 대해 요청을 올바른 분할된 데이터베이스로 라우팅하는 것이 더 복잡할 수 있습니다.
또한 분할을 사용하면 테넌트 수준 구성 차이를 지원하고 고객이 자체 암호화 키를 제공할 수 있습니다.
각 테넌트에 대한 전용 데이터베이스가 있는 다중 테넌트 앱
또 다른 일반적인 방법은 각 테넌트에 대한 전용 데이터베이스를 사용하여 단일 다중 테넌트 애플리케이션을 배포하는 것입니다.
이 모델에서 각 테넌트의 데이터는 다른 테넌트와 격리되며 각 테넌트에 대해 어느 정도의 사용자 지정을 지원할 수 있습니다.
각 테넌트에 전용 데이터 리소스를 프로비저닝하기 때문에 이 방법의 비용은 공유 호스팅 모델보다 높을 수 있습니다. 그러나 Azure는 여러 테넌트에서 개별 데이터 리소스를 호스팅하는 비용을 공유하기 위해 고려할 수 있는 몇 가지 옵션을 제공합니다. 예를 들어 Azure SQL을 사용하는 경우 탄력적 풀을 고려할 수 있습니다. Azure Cosmos DB의 경우 데이터베이스에 대한 처리량을 프로비저닝할 수 있으며 각 컨테이너에 대해 성능이 보장되어야 하는 경우에는 이 방법이 적절하지 않지만 해당 데이터베이스의 컨테이너 간에 처리량이 공유됩니다.
이 방법에서는 데이터 구성 요소만 각 테넌트에 대해 개별적으로 배포되므로 솔루션의 다른 구성 요소에 대해 고밀도를 달성하고 해당 구성 요소의 비용을 줄일 수 있습니다.
각 테넌트에 대해 데이터베이스를 프로비저닝할 때 자동화된 배포 방법을 사용하는 것이 중요합니다.
지리적 노드 패턴
지리적 노드 패턴은 다중 테넌트 솔루션을 포함하여 지리적으로 분산된 솔루션을 위해 특별히 설계되었습니다. 높은 부하와 높은 수준의 복원력을 지원합니다. Geode 패턴을 구현하는 경우 데이터 계층은 지리적 지역 간에 데이터를 복제본(replica) 수 있어야 하며 다중 지리 쓰기를 지원해야 합니다.
Azure Cosmos DB는 이 패턴을 지원하기 위해 다중 마스터 쓰기를 제공하고 Cassandra는 다중 지역 클러스터를 지원합니다. 다른 데이터 서비스는 일반적으로 상당한 사용자 지정 없이는 이 패턴을 지원할 수 없습니다.
피해야 할 안티패턴
다중 테넌트 데이터 서비스를 만들 때 크기를 조정하지 않는 상황을 방지하는 것이 중요합니다.
관계형 데이터베이스의 경우 다음이 포함됩니다.
- 테이블 기반 격리. 단일 데이터베이스 내에서 작업하는 경우 각 테넌트에 대한 개별 테이블을 만들지 마세요. 단일 데이터베이스는 이 방법을 사용할 때 매우 많은 수의 테넌트만 지원할 수 없으며 데이터를 쿼리, 관리, 업데이트하기가 점점 더 어려워집니다. 대신 테넌트 식별자 열이 있는 단일 다중 테넌트 테이블 집합을 사용하는 것이 좋습니다. 또는 위에서 설명한 패턴 중 하나를 사용하여 각 테넌트에 대해 별도의 데이터베이스를 배포할 수 있습니다.
- 열 수준 테넌트 사용자 지정. 단일 테넌트에만 적용되는 스키마 업데이트를 적용하지 않습니다. 예를 들어 단일 다중 테넌트 데이터베이스가 있다고 가정합니다. 특정 테넌트의 요구 사항을 충족하기 위해 새 열을 추가하지 마세요. 적은 수의 사용자 지정에 허용될 수 있지만 고려해야 할 사용자 지정이 많으면 빠르게 관리가 불가능해집니다. 대신 전용 테이블의 각 테넌트에 대한 사용자 지정 데이터를 추적하도록 데이터 모델을 수정하는 것이 좋습니다.
- 수동 스키마 변경. 단일 공유 데이터베이스만 있는 경우에도 데이터베이스 스키마를 수동으로 업데이트하지 마세요. 적용한 업데이트를 쉽게 추적할 수 있으며 더 많은 데이터베이스로 스케일 아웃해야 하는 경우 적용할 올바른 스키마를 식별하기가 어렵습니다. 대신 자동화된 파이프라인을 빌드하여 스키마 변경 내용을 배포하고 일관되게 사용합니다. 전용 데이터베이스 또는 조회 테이블의 각 테넌트에 사용되는 스키마 버전을 추적합니다.
- 버전 종속성. 애플리케이션이 단일 버전의 데이터베이스 스키마에 종속되는 것을 방지합니다. 크기를 조정하면 서로 다른 테넌트에 대해 서로 다른 시간에 스키마 업데이트를 적용해야 할 수 있습니다. 대신 애플리케이션 버전이 하나 이상의 스키마 버전과 이전 버전과 호환되는지 확인하고 파괴적인 스키마 업데이트를 방지합니다.
데이터베이스
다중 테넌트에 유용할 수 있는 몇 가지 기능이 있습니다. 그러나 이러한 서비스는 모든 데이터베이스 서비스에서 사용할 수 없습니다. 시나리오에 사용할 서비스를 결정할 때 필요한지 여부를 고려합니다.
- 행 수준 보안은 공유 다중 테넌트 데이터베이스의 특정 테넌트 데이터에 대한 보안 격리를 제공할 수 있습니다. 이 기능은 Azure SQL 및 Postgres Flex에서 사용할 수 있지만 MySQL 또는 Azure Cosmos DB와 같은 다른 데이터베이스에서는 사용할 수 없습니다.
- 데이터에 대한 자체 암호화 키를 제공하는 테넌트 지원을 위해 테넌트 수준 암호화가 필요할 수 있습니다. 이 기능은 Always Encrypted의 일부로 Azure SQL에서 사용할 수 있습니다. Azure Cosmos DB는 계정 수준에서 고객 관리형 키를 제공하고 Always Encrypted도 지원합니다.
- 리소스 풀링을 사용하면 여러 데이터베이스 또는 컨테이너 간에 리소스와 비용을 공유할 수 있습니다. 이 기능은 Azure SQL의 탄력적 풀과 관리형 인스턴스 및 Azure Cosmos DB 데이터베이스 처리량에서 사용할 수 있지만 각 옵션에는 알고 있어야 하는 제한 사항이 있습니다.
- 분할 및 파티셔닝은 일부 서비스에서 다른 서비스보다 더 강력한 기본 지원을 제공합니다. 이 기능은 논리적 및 물리적 파티셔닝을 사용하여 Azure Cosmos DB와 PostgreSQL 하이퍼스케일에서 사용할 수 있습니다. Azure SQL은 기본적으로 분할을 지원하지는 않지만 이러한 유형의 아키텍처를 지원하는 분할 도구를 제공합니다.
또한 관계형 데이터베이스 또는 기타 스키마 기반 데이터베이스를 사용하는 경우 기본 데이터베이스를 기본 때 스키마 업그레이드 프로세스를 트리거해야 하는 위치를 고려합니다. 데이터베이스의 작은 자산에서 배포 파이프라인을 사용하여 스키마 변경 내용을 배포하는 것이 좋습니다. 확장함에 따라 애플리케이션 계층에서 특정 데이터베이스에 대한 스키마 버전을 검색하고 업그레이드 프로세스를 시작하는 것이 더 나을 수 있습니다.
파일 및 Blob Storage
스토리지 계정 내에서 데이터를 격리하는 데 사용하는 방법을 고려합니다. 예를 들어 각 테넌트에 대해 별도의 스토리지 계정을 배포하거나 스토리지 계정을 공유하고 개별 컨테이너를 배포할 수 있습니다. 또는 공유 Blob 컨테이너를 만든 다음, Blob 경로를 사용하여 각 테넌트에 대한 데이터를 구분할 수 있습니다. Azure 구독 제한 및 할당량을 고려하고, 향후 요구 사항을 지원하기 위해 Azure 리소스를 스케일링하도록 성장을 신중하게 계획합니다.
공유 컨테이너를 사용하는 경우 테넌트가 서로의 데이터에 액세스할 수 없도록 인증 및 권한 부여 전략을 신중하게 계획합니다. 클라이언트에 Azure Storage 리소스에 대한 액세스 권한을 제공하는 경우 발레 키 패턴을 고려합니다.
비용 할당
공유 데이터 서비스를 사용하기 위해 소비를 측정하고 테넌트에 비용을 할당하는 방법을 고려합니다. 가능하면 고유한 메트릭을 계산하는 대신 기본 제공 메트릭을 사용하는 것을 목표로 합니다. 그러나 공유 인프라를 사용하면 개별 테넌트에 대한 원격 분석을 분할하기가 어려워지며 애플리케이션 수준 사용자 지정 계량도 고려해야 합니다.
일반적으로 Azure Cosmos DB 및 Azure Blob Storage 같은 클라우드 네이티브 서비스는 특정 테넌트에 대한 사용량을 추적하고 모델링하는 보다 세부적인 메트릭을 제공합니다. 예를 들어 Azure Cosmos DB는 모든 요청 및 응답에 대해 사용된 처리량을 제공합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- John Downs | 수석 고객 엔지니어, FastTrack for Azure
기타 기여자:
- Paul Burpo | 주요 고객 엔지니어, Azure용 FastTrack
- Daniel Scott-Raynsford | 파트너 기술 전략가
- Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.
다음 단계
다중 테넌트 및 특정 Azure 서비스에 대한 자세한 내용은 다음을 참조하세요.