Share via

다중 테넌트 및 Azure Storage

  • 아티클

Azure Storage는 거의 모든 솔루션에서 사용되는 기본 서비스입니다. 다중 테넌트 솔루션은 Blob, 파일, 큐 및 테이블 스토리지에 Azure Storage를 사용하는 경우가 많습니다. 이 페이지에서는 다중 테넌트 솔루션에 유용한 Azure Storage의 몇 가지 기능을 설명한 다음, Azure Storage 사용 방법을 계획할 때 도움이 될 수 있는 지침에 대한 링크를 제공합니다.

다중 테넌트를 지원하는 Azure Storage 기능

Azure Storage에는 다중 테넌트를 지원하는 다양한 기능이 포함되어 있습니다.

공유 액세스 서명

클라이언트 애플리케이션에서 Azure Storage를 사용할 때는 콘텐츠 배달 네트워크 또는 API와 같이 제어하는 다른 구성 요소를 통해 클라이언트 요청을 보내야 하는지 또는 클라이언트가 스토리지 계정에 직접 연결해야 하는지 여부를 고려해야 합니다. 네트워크 에지의 데이터 캐싱을 포함하여 다른 구성 요소를 통해 요청을 보내는 적합한 이유가 있을 수 있습니다. 그러나 경우에 따라 클라이언트 엔드포인트가 직접 Azure Storage에 연결하여 데이터를 다운로드하거나 업로드하는 것이 유리합니다. 이 연결을 사용하면 특히 대형 Blob이나 다수의 파일로 작업하는 경우 솔루션의 성능을 향상시킬 수 있습니다. 또한 백 엔드 애플리케이션과 서버의 부하를 줄이고 네트워크 홉 수를 줄여줍니다. SAS(공유 액세스 서명)를 사용하면 클라이언트 애플리케이션에 Azure Storage의 개체에 대한 액세스 권한을 안전하게 제공할 수 있습니다.

공유 액세스 서명을 사용하여 클라이언트가 수행할 수 있는 작업의 범위와 작업을 수행할 수 있는 개체를 제한할 수 있습니다. 예를 들어 모든 테넌트에 대한 공유 스토리지 계정이 있고 모든 테넌트 A의 데이터를 tenanta라는 Blob 컨테이너에 저장하는 경우 테넌트 A의 사용자만 해당 컨테이너에 액세스하도록 허용하는 SAS를 만들 수 있습니다. 자세한 내용은 격리 모델을 참조하여 스토리지 계정에서 테넌트의 데이터를 격리하는 데 사용할 수 있는 방법을 살펴봅니다.

발레 키 패턴은 애플리케이션 계층에서 제한되고 범위가 지정된 공유 액세스 서명을 발급하는 방법으로 유용합니다. 예를 들어 사용자가 비디오를 업로드할 수 있는 다중 테넌트 애플리케이션이 있다고 가정합니다. API 또는 애플리케이션 계층은 사용자 고유의 인증 시스템을 사용하여 클라이언트를 인증할 수 있습니다. 그런 다음, 지정된 Blob에 비디오 파일을 사용자가 지정한 컨테이너와 Blob 경로에 업로드할 수 있도록 클라이언트에 SAS를 제공할 수 있습니다. 그러면 클라이언트는 스토리지 계정에 파일을 직접 업로드하여 API에서 추가 대역폭과 로드를 방지합니다. Blob 컨테이너에서 데이터를 읽으려고 하거나 스토리지 계정에 있는 다른 컨테이너의 다른 부분에 데이터를 쓰려고 하면 Azure Storage에서 요청을 차단합니다. 구성 가능한 기간 후에 서명이 만료됩니다.

저장된 액세스 정책은 SAS 기능을 확장하므로 여러 공유 액세스 서명을 발행할 때 사용할 수 있는 단일 정책을 정의할 수 있습니다.

ID 기반 액세스 제어

또한 Azure Storage는 Microsoft Entra ID를 사용하여 ID 기반 액세스 제어를 제공합니다. 또한 이 기능을 사용하면 특성 기반 액세스 제어를 사용할 수 있으며 이를 통해 Blob 경로 또는 특정 테넌트 ID로 태그가 지정된 Blob에 보다 세분화된 액세스 권한을 제공할 수 있습니다.

수명 주기 관리

다중 테넌트 솔루션에서 Blob 스토리지를 사용하는 경우 테넌트는 데이터를 보존할 수 있도록 다른 정책을 요구할 수 있습니다. 대용량 데이터를 저장하는 경우 경제적인 목적으로 특정 테넌트의 데이터가 자동으로 쿨 또는 보관 스토리지 계층으로 이동하도록 구성할 수도 있습니다.

수명 주기 관리 정책을 사용하여 모든 테넌트나 테넌트 하위 집합에 Blob 수명 주기를 설정하는 것이 좋습니다. 수명 주기 관리 정책을 Blob 컨테이너나 컨테이너 내 Blob의 하위 집합에 적용할 수 있습니다. 그러나 수명 주기 관리 정책에서 지정할 수 있는 규칙 수는 제한됩니다. 다중 테넌트 환경에서 이 기능 사용을 계획 및 테스트하고 한도를 초과하는 경우 스토리지 계정 여러 개를 배포하는 것이 좋습니다.

변경 불가능한 스토리지

시간 기반 보존 정책을 사용하여 스토리지 컨테이너에서 변경할 수 없는 Blob 스토리지를 구성하는 경우 Azure Storage는 지정된 시간 전에 데이터를 삭제하거나 수정하지 않습니다. 방지는 스토리지 계정 레이어에서 적용되며 모든 사용자에 적용됩니다. 조직 관리자라도 변경할 수 없는 데이터를 삭제할 수 없습니다.

변경이 불가능한 스토리지는 데이터나 레코드를 유지하기 위한 법적 또는 규정 준수 요구 사항이 있는 테넌트를 사용할 때 유용할 수 있습니다. 그러나 테넌트 수명 주기의 컨텍스트 내에서 이 기능을 사용하는 방법을 고려해야 합니다. 예를 들어 테넌트가 오프보딩되고 데이터 삭제를 요청하는 경우 해당 요청을 처리하지 못할 수도 있습니다. 테넌트 데이터에 변경이 불가능한 스토리지를 사용하는 경우 서비스 약관에서 이 문제를 해결하는 방법을 고려합니다.

서버 쪽 동기화

다중 테넌트 시스템에서는 한 스토리지 계정에서 다른 스토리지 계정으로 데이터를 이동해야 하는 경우가 있습니다. 예를 들어 배포 스탬프 간에 테넌트를 이동하거나 분할된 스토리지 계정 세트의 균형을 다시 맞추는 경우 특정 테넌트의 데이터를 복사하거나 이동해야 합니다. 대용량 데이터를 사용하는 경우 데이터를 마이그레이션하는 데 걸리는 시간을 줄어들도록 서버 쪽 복사 API를 사용하는 것이 좋습니다.

AzCopy 도구는 컴퓨터나 가상 머신에서 실행하여 복사 프로세스를 관리할 수 있는 애플리케이션입니다. AzCopy는 서버 쪽 복사 기능과 호환되며 사용자 고유의 솔루션에서 실행할 수 있는 스크립트 가능한 명령줄 인터페이스를 제공합니다. AzCopy는 대용량 데이터를 업로드하고 다운로드하는 데에도 유용합니다.

코드에서 직접 서버 쪽 복사 API를 사용해야 하는 경우 더 작은 Blob으로 작업할 때 URL에서 블록 배치 API, URL에서 페이지 배치 API, URL에서 블록 추가 API 및 URL에서 블록 복사 API를 사용하는 것이 좋습니다.

개체 복제

개체 복제 기능은 원본 및 대상 스토리지 계정 간에 데이터를 자동으로 복제합니다. 개체 복제는 비동기적입니다. 다중 테넌트 솔루션에서 이 기능은 배포 스탬프 간에 또는 지오드 패턴 구현에서 지속적으로 데이터를 복제해야 하는 경우에 유용할 수 있습니다.

암호화

Azure Storage를 사용하면 데이터에 암호화 키를 제공할 수 있습니다. 다중 테넌트 솔루션에서 데이터가 동일한 스토리지 계정에 저장되더라도 테넌트마다 암호화 키를 다르게 정의할 수 있도록 이 기능을 암호화 범위와 결합하는 것이 좋습니다. 이러한 기능을 함께 사용하면 테넌트에서 자체 데이터를 제어할 수 있습니다. 계정을 비활성화해야 하는 경우 암호화 키를 삭제할 수 있으며 해당 데이터에 더 이상 액세스할 수 없습니다.

모니터링

다중 테넌트 솔루션을 사용할 때 각 테넌트의 사용량을 측정해야 하는지, 각 테넌트에 사용되는 스토리지 양(용량) 또는 각 테넌트의 데이터에 수행된 작업 수와 같이 추적해야 하는 특정 메트릭을 정의해야 하는지 여부를 고려합니다. 비용 할당을 사용하여 각 테넌트의 사용 비용을 추적하고 여러 구독에서 차지백을 사용하도록 설정할 수도 있습니다.

Azure Storage는 모니터링 기능을 기본 제공합니다. Azure Storage 계정 내에서 사용할 서비스를 고려하는 것이 중요합니다. 예를 들어 Blob을 사용하는 경우 단일 컨테이너가 아닌 스토리지 계정의 총 용량을 볼 수 있습니다. 반면, 파일 공유를 사용하는 경우 각 폴더의 용량이 아닌 각 공유의 용량을 확인할 수 있습니다.

또한 Azure Storage에 대한 모든 요청을 로깅한 다음, 해당 로그를 집계하고 분석할 수 있습니다. 이렇게 하면 테넌트마다 데이터를 집계하고 그룹화하는 방법에 더 많은 유연성이 제공됩니다. 그러나 Azure Storage에 대한 요청을 대량으로 만드는 솔루션에서는 이 방법을 통해 얻는 이점이 해당 로그 캡처 및 처리와 관련된 비용을 정당화하는지 여부를 고려해야 합니다.

Azure Storage 인벤토리는 Blob 컨테이너의 총 크기를 측정하는 또 다른 방법을 제공합니다.

격리 모델

Azure Storage를 사용하는 다중 테넌트 시스템을 사용하는 경우 사용하려는 격리 수준을 결정해야 합니다. Azure Storage에서는 여러 가지 격리 모델을 지원합니다.

테넌트당 스토리지 계정

테넌트 전용 스토리지 계정을 배포하는 가장 강력한 격리 수준입니다. 이렇게 하면 모든 스토리지 키가 격리되고 독립적으로 회전할 수 있습니다. 이 방법을 사용하면 스토리지 계정마다 적용되는 한도와 할당량이 방지되도록 솔루션을 확장할 수 있지만 단일 Azure 구독에 배포할 수 있는 최대 스토리지 계정 수를 고려해야 합니다.

참고

Azure Storage에는 격리 모델을 선택할 때 고려해야 하는 할당량과 한도가 많이 있습니다. 여기에는 Azure 서비스 한도, 확장성 목표 및 Azure Storage 리소스 공급자에 대한 확장성 목표가 포함됩니다.

또한 Azure Storage의 각 구성 요소는 테넌트 격리에 사용되는 추가 옵션을 제공합니다.

Blob 스토리지 격리 모델

다음 표에는 Azure Storage Blob에 대한 기본 테넌트 격리 모델 간의 차이점이 요약되어 있습니다.

고려 사항 Blob 컨테이너 공유 테넌트당 Blob 컨테이너 테넌트당 스토리지 계정
데이터 격리 낮음-중간. 경로를 사용하여 각 테넌트의 데이터 또는 계층 구조 네임스페이스 식별 중간. 컨테이너 범위 SAS URL을 사용하여 보안 격리 지원 높음
성능 격리 낮음 낮음. 대부분의 할당량 및 제한은 전체 스토리지 계정에 적용됩니다. 높음
배포 복잡성 낮음 중간 높음
운영 복잡성 낮음 중간 높음
예제 시나리오 테넌트당 적은 수의 Blob 저장 테넌트 범위 SAS URL 발급 각 테넌트마다 별도의 배포 스탬프

Blob 컨테이너 공유

Blob 스토리지를 사용할 때 공유 Blob 컨테이너를 사용한 다음, Blob 경로를 사용하여 각 테넌트의 데이터를 구분할 수 있습니다.

테넌트 ID Blob 경로 예제
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

이 방법을 간단하게 구현할 수 있지만 많은 시나리오에서 Blob 경로는 테넌트 간에 충분한 격리를 제공하지 않습니다. 일반적으로 Blob 스토리지에서 디렉터리 또는 폴더의 개념을 제공하지 않기 때문입니다. 즉, 지정된 경로 내 모든 Blob에 대한 액세스를 할당할 수 없습니다. 그러나 Azure Storage는 지정된 접두사로 시작하는 Blob을 나열(열거)하는 기능을 제공합니다. 이 기능은 공유 Blob 컨테이너를 사용하고 디렉터리 수준 액세스 제어가 필요하지 않은 경우에 유용할 수 있습니다.

Azure Storage의 계층 구조 네임스페이스 기능은 디렉터리별 액세스 제어를 포함하여 더욱 강력한 디렉터리 또는 폴더의 개념이 있는 기능을 제공합니다. 이는 공유 Blob 컨테이너가 있지만 단일 테넌트의 데이터에 대한 액세스 권한을 부여하려는 일부 다중 테넌트 시나리오에서 유용할 수 있습니다.

일부 다중 테넌트 솔루션에서는 사용자 인터페이스를 사용자 지정할 수 있는 테넌트 아이콘과 같이 테넌트마다 단일 Blob 또는 Blob 세트만 저장해야 할 수 있습니다. 이러한 시나리오에서는 공유 Blob 컨테이너 하나로 충분할 수 있습니다. 테넌트 식별자를 Blob 이름으로 사용한 다음, Blob 경로를 열거하는 대신 특정 Blob을 읽을 수 있습니다.

공유 컨테이너를 사용하는 경우 테넌트마다 데이터 및 Azure Storage 서비스 사용량을 추적해야 하는지 여부를 고려하고 이를 수행하는 방법을 계획합니다. 자세한 내용은 모니터링을 참조하세요.

테넌트당 Blob 컨테이너

단일 스토리지 계정 내에서 테넌트마다 개별 Blob 컨테이너를 만들 수 있습니다. 스토리지 계정 내에서 만들 수 있는 Blob 컨테이너 수에는 제한이 없습니다.

테넌트마다 컨테이너를 만들면 SAS를 포함하여 Azure Storage 액세스 제어를 사용해 각 테넌트의 데이터에 대한 액세스를 관리할 수 있습니다. 각 컨테이너에서 사용하는 용량을 간편하게 모니터링할 수도 있습니다.

파일 스토리지 격리 모델

다음 표에는 Azure Storage 파일에 대한 기본 테넌트 격리 모델 간의 차이점이 요약되어 있습니다.

고려 사항 공유 파일 공유 테넌트당 파일 공유 테넌트당 스토리지 계정
데이터 격리 약간 높음. 테넌트별 파일 및 디렉터리에 대한 권한 부여 규칙 적용 보통 높음 높음
성능 격리 낮음 낮음-중간. 대부분의 할당량 및 한도는 전체 스토리지 계정에 적용되지만 공유당 수준에서 크기 할당량을 설정합니다. 높음
배포 복잡성 낮음 중간 높음
운영 복잡성 낮음 중간 높음
예제 시나리오 애플리케이션은 파일에 대한 모든 액세스를 제어합니다. 테넌트는 자신의 파일에 액세스합니다. 각 테넌트마다 별도의 배포 스탬프

공유 파일 공유

파일 공유를 사용할 때 공유 파일 공유를 사용한 다음, 파일 경로를 사용하여 각 테넌트의 데이터를 구분할 수 있습니다.

테넌트 ID 파일 경로 예제
tenant-a https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4
tenant-b https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4

SMB(서버 메시지 블록) 프로토콜을 사용하여 통신할 수 있는 애플리케이션을 사용하고 온-프레미스 또는 Azure에서 Active Directory Domain Services를 사용하는 경우 파일 공유는 공유 및 디렉터리/파일 수준 모두에서 권한 부여를 지원합니다.

다른 시나리오에서는 SAS를 사용하여 특정 파일 공유나 파일에 대한 액세스 권한을 부여하는 것이 좋습니다. SAS를 사용하는 경우 디렉터리에 대한 액세스 권한을 부여할 수 없습니다.

공유 파일 공유를 사용하는 경우 테넌트마다 데이터 및 Azure Storage 서비스 사용량을 추적해야 하는지 여부를 고려한 다음, 이를 수행하는 방법을 계획합니다(필요한 경우). 자세한 내용은 모니터링을 참조하세요.

테넌트당 파일 공유

단일 스토리지 계정 내에서 테넌트마다 개별 파일 공유를 만들 수 있습니다. 스토리지 계정 내에서 만들 수 있는 파일 공유 수에는 제한이 없습니다.

테넌트마다 파일 공유를 만들면 SAS를 포함하여 Azure Storage 액세스 제어를 사용해 각 테넌트의 데이터에 대한 액세스를 관리할 수 있습니다. 또한 각 파일 공유에서 사용하는 용량을 간편하게 모니터링할 수 있습니다.

테이블 스토리지 격리 모델

다음 표에는 Azure Storage 테이블에 대한 기본 테넌트 격리 모델 간의 차이점이 요약되어 있습니다.

고려 사항 테넌트별로 파티션 키가 있는 공유 테이블 테넌트당 테이블 테넌트당 스토리지 계정
데이터 격리 낮음. 애플리케이션에서 격리 적용 낮음-중간 높음
성능 격리 낮음 낮음. 대부분의 할당량 및 제한은 전체 스토리지 계정에 적용됩니다. 높음
배포 복잡성 낮음 중간 높음
운영 복잡성 낮음 중간 높음
예제 시나리오 공유 애플리케이션 계층이 있는 대규모 다중 테넌트 솔루션 테넌트 범위 SAS URL 발급 각 테넌트마다 별도의 배포 스탬프

테넌트별로 파티션 키가 있는 공유 테이블

단일 공유 테이블에서 테이블 스토리지를 사용하는 경우 기본 제공되는 분할 지원을 사용하는 것이 좋습니다. 각 엔터티에는 파티션 키가 포함되어 있어야 합니다. 파티션 키에 테넌트 식별자가 적합한 경우가 많습니다.

공유 액세스 서명과 정책을 사용하면 파티션 키 범위를 지정할 수 있으며 Azure Storage는 서명을 포함하는 요청이 지정된 파티션 키 범위에만 액세스할 수 있게 합니다. 이를 통해 신뢰할 수 없는 클라이언트가 다른 테넌트에 영향을 주지 않고 단일 테넌트의 파티션에 액세스할 수 있도록 발레 키 패턴을 구현할 수 있습니다.

대규모 애플리케이션의 경우 각 테이블 파티션과 스토리지 계정의 최대 처리량을 고려합니다.

테넌트당 테이블

단일 스토리지 계정 내에서 테넌트마다 개별 테이블을 만들 수 있습니다. 스토리지 계정 내에서 만들 수 있는 테이블 수에는 제한이 없습니다.

테넌트마다 테이블을 만들면 SAS를 포함하여 Azure Storage 액세스 제어를 사용해 각 테넌트의 데이터에 대한 액세스를 관리할 수 있습니다.

큐 스토리지 격리 모델

다음 표에는 Azure Storage 큐에 대한 기본 테넌트 격리 모델 간의 차이점이 요약되어 있습니다.

고려 사항 공유 큐 테넌트당 큐 테넌트당 스토리지 계정
데이터 격리 낮음 낮음-중간 높음
성능 격리 낮음 낮음. 대부분의 할당량 및 제한은 전체 스토리지 계정에 적용됩니다. 높음
배포 복잡성 낮음 중간 높음
운영 복잡성 낮음 중간 높음
예제 시나리오 공유 애플리케이션 계층이 있는 대규모 다중 테넌트 솔루션 테넌트 범위 SAS URL 발급 각 테넌트마다 별도의 배포 스탬프

공유 큐

큐를 공유하는 경우 적용되는 할당량과 한도를 고려합니다. 요청이 많은 솔루션에서 초당 메시지 2,000개의 대상 처리량이 충분한지 여부를 고려합니다.

큐에서는 분할이나 하위 큐를 제공하지 않으므로 모든 테넌트의 데이터가 섞일 수 있습니다.

테넌트당 큐

단일 스토리지 계정 내에서 테넌트마다 개별 큐를 만들 수 있습니다. 스토리지 계정 내에서 만들 수 있는 큐 수에는 제한이 없습니다.

테넌트마다 큐를 만들면 SAS를 포함하여 Azure Storage 액세스 제어를 사용해 각 테넌트의 데이터에 대한 액세스를 관리할 수 있습니다.

테넌트마다 큐를 동적으로 만들 때 애플리케이션 계층이 각 테넌트의 큐에서 메시지를 사용하는 방법을 고려합니다. 고급 시나리오의 경우 다중 테넌트 솔루션에서 유용할 수 있는 토픽 및 구독, 세션, 메시지 자동 전달과 같은 기능을 지원하는 Azure Service Bus를 사용하는 것이 좋습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • John Downs | 수석 고객 엔지니어, FastTrack for Azure

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다중 테넌시에 대한 스토리지 및 데이터 접근 방식을 검토합니다.