다중 테넌트 및 Azure App Configuration

Azure App Configuration을 사용하면 애플리케이션의 구성 설정을 저장할 수 있습니다. Azure App Configuration을 사용하면 외부 구성 저장소 패턴을 쉽게 구현할 수 있습니다. 이 문서에서는 다중 테넌트 시스템으로 작업할 때 유용한 Azure App Configuration의 일부 기능을 설명하고 다중 테넌트 솔루션에서 Azure App Configuration을 사용하는 방법에 대한 지침 및 예를 제공합니다.

격리 모델

저장소는 Azure App Configuration 서비스의 단일 인스턴스를 나타냅니다.

멀티테넌트 솔루션에서는 일반적으로 두 가지 유형의 설정이 있습니다.

• 공유 설정은 여러 테넌트에 적용되는 설정으로, 글로벌 설정이나 배포 스탬프 내의 모든 테넌트에 적용되는 설정이 여기에 해당합니다. 전역 설정은 공유 App Configuration 저장소에 저장하는 것이 가장 좋습니다. 이 방식을 따르면 설정 값이 변경될 때 업데이트해야 하는 위치의 수를 최소화할 수 있습니다. 이 방식은 또한 설정이 동기화되지 않을 수 있는 위험을 최소화합니다.

• 테넌트별 설정(예: 각 테넌트의 데이터베이스 이름 또는 내부 식별자). 또는 특정 테넌트에서 보고된 문제를 진단하고 해당 테넌트에서 진단 로그를 수집해야 하는 경우와 같이 각 테넌트에 대해 서로 다른 로그 수준을 지정할 수 있습니다. 여러 테넌트에 대한 테넌트별 설정을 단일 저장소로 결합할지 또는 각 테넌트에 대한 저장소를 배포할지 여부를 선택할 수 있습니다. 이 결정은 요구 사항을 기반으로 해야 합니다. 솔루션이 여러 테넌트에 대해 단일 공유 애플리케이션 계층을 사용하는 경우 테넌트별 저장소를 사용하면 얻을 수 있는 이점이 거의 없습니다. 그러나 테넌트별 애플리케이션 인스턴스를 배포하는 경우 테넌트별 구성 저장소를 배포하여 동일한 방식을 미러링하도록 선택할 수 있습니다.

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

공유 매장

전체 솔루션에 대해 공유 Azure 앱 구성 저장소를 배포하거나 각 스탬프에 대해 하나씩 배포할 수 있습니다. 그런 다음 테넌트의 모든 설정에 대해 동일한 저장소를 사용할 수 있으며 키 접두사 또는 레이블을 사용하여 구분할 수 있습니다.

테넌트당 많은 양의 데이터를 저장해야 하거나 많은 수의 테넌트로 크기 조정해야 하는 경우 단일 저장소에 대한 리소스 제한을 초과할 위험이 있습니다. 이 시나리오에서는 배포 및 관리 비용을 최소화하기 위해 공유 저장소 집합에서 테넌트를 분할할 수 있는지 여부를 고려합니다.

이 방식을 따르는 경우 적용되는 리소스 할당량 및 한도를 이해해야 합니다. 특히 사용하는 서비스 계층의 총 저장 한도에 유의하고 시간당 최대 요청을 초과하지 않도록 합니다.

테넌트당 저장소

대신 각 테넌트에 대해 Azure App Configuration 저장소를 배포하도록 선택할 수 있습니다. Azure App Configuration 표준 계층을 사용하면 구독에 무제한으로 저장소를 배포할 수 있습니다. 그러나 이 방식은 더 많은 리소스를 배포하고 구성해야 하기 때문에 관리하기가 더 복잡한 경우가 많습니다. 또한 배포하는 각 매장 리소스에 대한 요금이 있습니다.

다음 상황 중 하나에 해당하는 경우 테넌트별 상점을 고려합니다.

• 키가 각 테넌트에 대해 별도인 고객 관리 암호화 키를 사용해야 합니다.
• 테넌트는 구성 데이터가 다른 테넌트의 데이터와 완전히 격리되어야 합니다. Azure App Configuration에 대한 액세스 권한은 저장소 수준에서 제어되므로 별도의 저장소를 배포하여 별도의 액세스 권한을 구성할 수 있습니다.

다중 테넌트를 지원하는 Azure App Configuration의 기능

다중 테넌트 애플리케이션에서 Azure App Configuration을 사용하는 경우 테넌트별 설정을 저장하고 검색하는 데 사용할 수 있는 몇 가지 기능이 있습니다.

키 접두사

Azure App Configuration에서는 애플리케이션 설정을 나타내는 키-값 쌍으로 작업합니다. 키는 구성 설정의 이름을 나타냅니다. 키에 계층적 명명 구조를 사용할 수 있습니다. 다중 테넌트 솔루션에서는 테넌트 식별자를 키의 접두사로 사용하는 것이 좋습니다.

예를 들어, 애플리케이션의 로깅 수준을 나타내는 설정을 저장해야 한다고 가정합니다. 단일 테넌트 솔루션에서는 이 설정의 이름을 LogLevel로 지정할 수 있습니다. 다중 테넌트 솔루션에서 테넌트 1의 경우 tenant1/LogLevel, 테넌트 2의 경우 tenant2/LogLevel 등과 같은 계층적 키 이름을 사용하도록 선택할 수 있습니다.

Azure App Configuration을 사용하면 긴 키 이름을 지정하여 계층 구조의 여러 수준을 지원할 수 있습니다. 긴 키 이름을 사용하기로 선택한 경우 키 및 값의 크기 제한을 이해해야 합니다.

단일 테넌트의 구성을 애플리케이션에 로드할 때 키 접두사 필터를 지정하여 해당 테넌트의 키만 로드할 수 있습니다. 또한 애플리케이션에서 키를 사용할 수 있도록 하기 전에 키에서 키 접두사를 잘라내도록 Azure App Configuration용 공급자 라이브러리를 구성할 수 있습니다. 키 접두사를 자르면 애플리케이션에 해당 테넌트의 값이 로드된 일관된 키 이름이 애플리케이션에 표시됩니다.

레이블

Azure App Configuration은 레이블도 지원하므로 동일한 키를 사용하여 별도의 값을 가질 수 있습니다.

레이블은 종종 버전 관리, 여러 배포 환경 작업 또는 솔루션의 다른 용도로 사용됩니다. 테넌트 식별자를 레이블로 사용할 수는 있지만 그 이후에는 다른 용도로 레이블을 사용할 수 없습니다. 따라서 멀티테넌트 솔루션의 경우 일반적으로 테넌트별 설정을 관리할 때는 키 접두사를 사용하고, 다른 용도로는 레이블을 사용하는 것이 좋습니다.

각 테넌트에 대해 레이블을 사용하기로 결정한 경우 애플리케이션은 레이블 필터를 사용하여 특정 테넌트에 대한 설정만 로드할 수 있습니다. 이 방식은 각 테넌트에 대해 별도의 애플리케이션 배포가 있는 경우 유용할 수 있습니다.

애플리케이션 쪽 캐싱

Azure App Configuration으로 작업할 때 설정을 사용할 때마다 로드하는 대신 애플리케이션 내에서 설정을 캐시하는 것이 중요합니다. Azure App Configuration 공급자 라이브러리는 설정을 캐시하고 자동으로 새로 고칩니다.

또한 애플리케이션이 단일 테넌트 또는 모든 테넌트에 대한 설정을 로드할지 여부를 결정해야 합니다.

테넌트 기반이 커짐에 따라 모든 테넌트에 대한 설정을 함께 로드하는 데 필요한 시간과 메모리가 증가할 수 있습니다. 따라서 대부분의 상황에서 애플리케이션에 필요할 때 각 테넌트에 대한 설정을 개별적으로 로드하는 것이 좋습니다.

각 테넌트의 구성 설정을 개별적으로 로드하는 경우 애플리케이션은 각 설정 집합을 다른 설정과 별도로 캐시해야 합니다. .NET 애플리케이션에서는 인메모리 캐시를 사용하여 테넌트의 IConfiguration 개체를 캐시한 다음 테넌트 식별자를 캐시 키로 사용하는 것을 고려하세요. 메모리 내 캐시를 사용하면 요청 시마다 구성을 다시 로드할 필요가 없지만 애플리케이션이 메모리 압력 상태에 있는 경우 캐시가 사용하지 않는 인스턴스를 제거할 수 있습니다. 각 테넌트의 구성 설정에 대한 만료 시간을 구성할 수도 있습니다.

참가자

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

보안 주체 작성자:

• John Downs | 소프트웨어 수석 엔지니어

기타 기여자:

• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure
• Zhenlan Wang | 수석 소프트웨어 엔지니어링 관리자, Azure App Configuration

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

다음 단계

다중 테넌트 지원에 대한 배포 및 구성 방법을 검토합니다.