Azure App Configuration FAQ

App Configuration을 사용하면 개발자가 애플리케이션 설정을 관리하고 기능 가용성을 제어하는 데 도움이 됩니다. App Configuration은 복잡한 구성 데이터를 사용하는 많은 작업의 간소화를 목표로 합니다.

App Configuration은 다음을 지원합니다.

• 계층 구조 네임스페이스
• 레이블 지정
• 광범위한 쿼리
• 일괄 처리 검색
• 특수 관리 작업
• 기능 관리 사용자 인터페이스

App Configuration은 Key Vault를 보완하며, 대부분의 애플리케이션 배포에서 두 가지를 함께 사용해야 합니다.

App Configuration은 강화된 보안을 제공하지만 애플리케이션 비밀을 저장하기에 가장 좋은 장소는 여전히 Key Vault입니다. Key Vault는 하드웨어 수준 암호화, 세부적인 액세스 정책, 인증서 회전과 같은 관리 작업을 제공합니다.

Key Vault에 저장된 비밀을 참조하는 App Configuration 키 값을 만들 수 있습니다. 자세한 내용은 ASP.NET Core 앱에서 Key Vault 참조 사용을 참조하세요.

예. App Configuration은 전송 중 및 저장 중인 모든 데이터를 항상 암호화합니다. 모든 네트워크 통신은 TLS 1.2 또는 TLS 1.3을 통해 이루어집니다. App Configuration은 Microsoft 관리형 키 또는 고객 관리형 키로 미사용 데이터 암호화를 지원합니다.

Azure App Service를 사용하면 각 App Service 인스턴스의 앱 설정을 정의할 수 있습니다. 해당 설정은 애플리케이션 코드에 환경 변수로 전달됩니다. 원하는 경우 특정 배포 슬롯에 설정을 연결할 수 있습니다. 자세한 내용은 앱 설정 구성을 참조하세요.

반면, Azure App Configuration을 사용하면 여러 앱에서 공유할 수 있는 설정을 정의할 수 있습니다. 여기에는 App Service와 기타 플랫폼에서 실행되는 앱이 포함됩니다. 애플리케이션 코드는 .NET 및 Java용 구성 공급자, Azure SDK 또는 REST API를 통해 직접 이 설정에 액세스합니다.

App Service의 애플리케이션 설정에서 App Configuration 데이터에 대한 참조를 추가할 수 있습니다. App Service와 App Configuration 간에 설정을 가져오고 내보낼 수도 있습니다. 이 기능을 사용하면 기존 App Service 설정에 따라 새로운 App Configuration 저장소를 신속하게 설정할 수 있습니다. App Service 설정을 사용하는 기존 앱과 구성을 공유할 수도 있습니다.

레이블, 콘텐츠 유형, 태그 및 기타 메타데이터와 같은 특성을 포함하여 단일 키 값에 대해 10KB로 제한됩니다.

이 제한은 대부분의 애플리케이션에서 단일 설정을 사용할 때 충분해야 합니다. 설정이 이 제한보다 큰 경우 다른 곳에 데이터를 저장하고 App Configuration에서 해당 데이터의 참조를 추가하는 것을 고려할 수 있습니다.

자세한 내용은 Azure 구독 및 서비스 제한을 참조하세요.

저장소별 수준에서 App Configuration에 액세스할 수 있는 사람을 제어합니다. 서로 다른 권한이 필요한 각 환경에 별도의 저장소를 사용합니다. 이 방법은 최상의 보안 격리를 제공합니다.

환경 간 보안 격리가 필요하지 않은 경우에는 레이블을 사용하여 구성 값을 구분할 수 있습니다. 다른 환경에 대해 각기 다른 구성을 설정하도록 레이블 사용은 전체 예제를 제공합니다.

모범 사례를 참조하세요.

가격 책정 계층에는 다음 두 가지가 있습니다.

• 무료 계층
• 표준 계층

표준 계층이 도입되기 전에 저장소를 만든 경우 일반 공급 시 자동으로 무료 계층으로 이동되었습니다. 표준 계층으로 업그레이드하거나 무료 계층을 유지할 수 있습니다.

저장소를 표준 계층에서 무료 계층으로 다운그레이드할 수는 없습니다. 무료 계층에 새 저장소를 만든 후 구성 데이터를 해당 저장소로 가져올 수 있습니다.

두 App Configuration 계층 모두 구성 설정, 기능 플래그, Key Vault 참조, 구성 스냅샷, 기본 관리 작업, 메트릭 및 로그를 포함한 핵심 기능을 제공합니다.

계층을 선택할 때는 다음을 고려해야 합니다.

• 구독당 리소스: 리소스는 단일 구성 저장소로 구성됩니다. 각 구독은 무료 계층의 지역당 하나의 구성 저장소로 제한됩니다. 표준 계층의 구독은 무제한 개수의 구성 저장소를 사용할 수 있습니다.

• 리소스당 스토리지: 무료 계층에서 각 구성 저장소는 일반 스토리지 10MB와 스냅샷 스토리지 10MB로 제한됩니다. 표준 계층에서 각 구성 저장소는 최대 1GB의 일반 스토리지와 추가로 1GB의 스냅샷 스토리지를 사용할 수 있습니다.

• 수정 기록: App Configuration은 키에 대한 모든 변경 내용의 기록을 저장합니다. 무료 계층에서는 이 기록이 7일 동안 저장됩니다. 표준 계층에서는 이 기록이 30일 동안 저장됩니다.

• 요청 할당량: 무료 계층 저장소는 일일 1,000개 요청으로 제한됩니다. 저장소가 1,000개 요청에 도달하면 자정(UTC)까지 모든 요청에 대해 HTTP 상태 코드 429가 반환됩니다.

  표준 계층 저장소는 시간당 30,000개 요청으로 제한됩니다. 시간당 할당량이 소진되면 요청은 해당 시간이 끝날 때까지 너무 많은 요청을 나타내는 HTTP 상태 코드 429를 반환할 수 있습니다. 할당량을 초과하는 요청이 더 많이 전송될수록 더 높은 비율의 요청이 상태 코드 429를 반환할 수 있습니다.

• 서비스 수준 계약: 표준 계층의 SLA는 가용성 99.9%, 지역 복제를 사용하도록 설정 시 가용성 99.95%입니다. 무료 계층에는 SLA가 없습니다.

• 기능: 두 계층 모두 Microsoft 관리형 키를 사용한 암호화, 액세스 키 또는 Microsoft Entra ID를 통한 인증, Azure RBAC(역할 기반 액세스 제어), 관리 ID, 서비스 태그, 가용성 영역 중복 등의 기능을 포함합니다. 표준 계층은 Private Link 지원, 고객 관리형 키를 사용한 암호화, 일시 삭제 보호, 지역 복제 기능을 포함한 더 많은 기능을 제공합니다.

• 비용: 표준 계층 저장소에는 일일 사용 요금이 청구됩니다. 매일 처음 200,000개 요청이 일일 요금에 포함됩니다. 일일 할당을 초과하는 요청에 대한 초과분 요금도 부과됩니다. 무료 계층 저장소를 사용하기 위한 비용은 없습니다.

언제든지 무료 계층에서 표준 계층으로 업그레이드할 수 있습니다.

저장소를 표준 계층에서 무료 계층으로 다운그레이드할 수는 없습니다. 무료 계층에 새 저장소를 만든 후 구성 데이터를 해당 저장소로 가져올 수 있습니다.

App Configuration에 저장된 고객 데이터는 고객의 App Configuration 저장소가 생성된 지역에 상주합니다. 고객이 해당 지역에 대해 지역 복제를 사용하도록 설정한 경우에만 고객 데이터가 다른 지역으로 복제됩니다. 이 규정은 사용 가능한 모든 지역에 적용됩니다. 고객은 전 세계 어느 위치에서나 데이터를 이동, 복사 또는 액세스할 수 있습니다.

Azure App Configuration은 지역 중단에 대한 향상된 복원력을 위해 지역 복제를 지원합니다.

Azure App Configuration은 단일 데이터 센터 오류로부터 애플리케이션과 데이터를 보호하기 위해 Azure 가용성 영역을 지원합니다. 가용성 영역을 지원하는 모든 지역은 최소 3개의 가용성 영역으로 구성되고, 각 가용성 영역은 물리적으로 독립된 데이터 센터입니다. 복원력을 위해 App Configuration의 이 지원은 추가 비용 없이 모든 고객에 대해 사용하도록 설정됩니다. 다음은 App Configuration에서 가용성 영역 지원을 사용한 지역입니다. 자세한 내용은 Azure의 지역 및 가용성 영역을 참조하세요.

다음은 App Configuration에서 가용성 영역 지원을 사용하도록 설정한 지역입니다.

무료 계층의 구성 저장소는 일일 1,000개 요청으로 제한됩니다. 표준 계층의 구성 저장소는 요청 속도가 시간당 30,000개 요청을 초과할 때 일시적으로 제한될 수 있습니다.

저장소가 표준 계층의 한도에 도달하면 시간이 끝날 때까지 이루어진 일부 요청에 대해 HTTP 상태 코드 429를 반환할 수 있습니다. 응답의 retry-after-ms 헤더는 요청을 다시 시도하기 전 대기 시간(밀리초)을 제안합니다.

애플리케이션에서 HTTP 상태 코드 429 응답이 주기적으로 발생하는 경우 요청 수를 줄이도록 다시 설계하는 것이 좋습니다. 자세한 내용은 App Configuration 요청을 줄이는 방법을 참조하세요.

HTTP 상태 코드 429 응답이 수신되는 경우는 다음과 같습니다.

• 무료 계층에서 저장소의 일일 요청 한도를 초과한 경우
• 표준 계층에서 저장소의 시간별 요청 한도를 초과한 경우
• 과다한 요청으로 인해 일시적 제한이 발생한 경우†
• 과도한 대역폭 사용으로 인한 일시적 제한†.
• 스토리지 할당량이 초과된 경우에 키를 만들거나 수정하려고 한 경우

요청이 실패한 특정 이유는 429 응답의 본문을 확인합니다.

†A 구성 저장소에서 과다한 요청을 수신하거나 과도한 양의 데이터를 전송하는 경우 일시적 제한이 발생할 수 있습니다. Azure SDK, 구성 공급자 라이브러리 및 Azure 파이프라인 작업과 같은 App Configuration 클라이언트는 제한된 요청을 자동으로 다시 시도합니다. 이러한 클라이언트 중 하나를 사용하는 애플리케이션이나 제한된 요청을 다시 시도하는 사용자 지정 클라이언트에서 이러한 일시적 제한이 발견되면 발생해야 합니다.

예를 들어 구성 설정이 1,000개인 애플리케이션이 있다고 가정해 보겠습니다. 애플리케이션은 시작 시 App Configuration의 모든 설정을 로드합니다. 그런 다음, 30초마다 구성 변경에서 sentinel 키를 확인합니다. Kubernetes, App Service 또는 VM 중 어디에서 실행 중이든 관계없이 애플리케이션 인스턴스 50개가 동시에 실행된다고 가정해 보겠습니다.

먼저 구성 모니터링에 대한 요청을 예측해 보겠습니다. 애플리케이션의 각 인스턴스는 30초마다 sentinel 키에 대한 단일 요청을 App Configuration으로 보내므로 한 시간에 120개(=3600/30) 요청을 보냅니다. 애플리케이션 인스턴스가 50개인 경우 애플리케이션은 구성 모니터링을 위해 매시간 총 6,000개(=120x50) 요청을 보냅니다. sentinel 키 요청은 자주 수행되고 대부분이 변경되지 않으므로 대부분의 요청은 저장소의 시간당 할당량 한도에 포함되지 않습니다†.

둘째, 구성 로드/다시 로드에 대한 요청을 예측해 보겠습니다. 애플리케이션은 시작 시 또는 sentinel 키 변경이 감지될 때마다 모든 설정을 로드합니다. App Configuration에 대한 각 요청은 최대 100개의 키-값을 검색할 수 있으므로 모든 설정을 로드하는 데 10개(=1000/100) 요청이 필요합니다. 50개의 애플리케이션 인스턴스가 있는 경우 애플리케이션이 다시 시작되거나 구성을 다시 로드할 때 총 500개(=10x50) 요청을 보냅니다.

마지막으로, 한꺼번에 정리해 보겠습니다. 한 시간 내에 sentinel 키를 두 번 업데이트한 경우 App Configuration 저장소는 해당 시간 동안 총 7,000개(=6,000+500x2) 요청을 받게 됩니다. 이러한 요청 중 약 1,000개(=500x2)의 요청만 사용 가능한 시간당 할당량을 사용합니다. 시간별 제한에 비해 충분한 버퍼가 유지되도록 특정 설정 및 디자인에 맞게 이 예제의 수치를 업데이트합니다. 자세한 내용은 App Configuration 요청을 줄이는 방법을 참조하세요.

†무료 계층 저장소에는 일별 한도에서 제외된 자주 반복되는 요청이 없습니다.

표준 계층의 모든 App Configuration 저장소는 자동으로 일시 삭제 기능을 사용하도록 설정했습니다. 표준 계층 App Configuration 저장소가 삭제되면 해당 이름은 보존 기간 동안 예약됩니다. 보존 기간이 만료되기 전에 동일한 이름으로 저장소를 다시 만들려면 저장소에 영구 삭제 방지가 사용하도록 설정되어 있지 않은 경우 먼저 일시 삭제된 저장소를 제거해야 합니다. 제거 보호를 사용하는 경우 보존 기간이 경과할 때까지 기다려야 합니다. 제거 기능을 사용하거나 동일한 이름의 저장소를 자주 다시 만들어야 하는 경우 보존 기간을 더 짧게 설정합니다. 동일한 이름으로 저장소를 다시 만들어야 하는 워크플로는 구성 저장소 제거와 후속 만들기 사이에 1시간의 간격을 허용해야 합니다. 이 권장 사항은 제거가 요청되면 구성 저장소 리소스의 실제 정리가 비동기적으로 수행되므로 완료하는 데 약간의 추가 시간이 필요하기 때문입니다. 대기할 필요가 없도록 하려면 임시 구성 저장소를 만드는 워크플로에서 고유한 이름을 사용하는 것이 좋습니다.

표준 계층의 모든 App Configuration 저장소는 사용하지 않도록 설정할 수 없는 일시 삭제 기능을 지원합니다. 삭제된 저장소는 보존 기간 내에 복구할 수 있습니다. 실수로 삭제된 App Configuration 저장소를 복구하려면 다음 지침을 따릅니다.

예. Azure Portal 또는 CLI를 통해 App Configuration에서 기능 플래그 및 Key Vault 참조를 관리할 수 있지만 App Configuration SDK를 사용하여 프로그래밍 방식으로 만들고 업데이트할 수도 있습니다. 따라서 사용자 지정된 관리 포털을 작성하거나 CI/CD에서 프로그래밍 방식으로 관리할 수 있습니다. 기능 플래그 및 Key Vault 참조 API는 지원되는 모든 언어의 SDK에서 사용할 수 있습니다. 지원되는 각 언어의 예제는 샘플 링크를 확인하세요.

애플리케이션에서 기능 플래그를 평가하고 사용하려면 .NET 및 Java Spring에서 사용할 수 있는 App Configuration 공급자 및 기능 관리 라이브러리가 필요합니다. 자세한 내용은 빠른 시작 및 자습서 아래의 기능 관리 섹션을 확인하세요.

Spring 프로필은 구성을 포함하는 애플리케이션의 부분을 구분하고, 특정 환경에서만 또는 특정 라이브러리를 사용하는 경우에만 사용하도록 하는 방법을 제공합니다.

Spring 프로필과 일치하도록 키-값의 레이블을 설정하는 것이 좋습니다. 기본적으로 App Configuration Spring 공급자 라이브러리는 레이블 필터가 명시적으로 설정되지 않은 경우 현재 활성 Spring 프로필(${spring.profiles.active})과 일치하는 레이블을 사용하여 키-값을 로드합니다. 활성 Spring 프로필 집합이 없으면 "레이블 없음"이 있는 키-값이 로드됩니다.

예를 들어 프로필 dev 및 prod를 사용하면 다음 레이블에 따라 키-값을 만듭니다.

Spring 프로필이 dev로 설정되면 config.message 값은 Hello from dev가 됩니다. Spring 프로필이 prod로 설정되면 config.message 값은 Hello from prod가 됩니다.

이 기본 동작은 부트스트랩 파일에서 레이블 필터를 설정하여 재정의할 수 있습니다. Spring 공급자 라이브러리는 활성 Spring 프로필에 관계없이 지정된 레이블을 사용하여 키-값을 로드합니다.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

다른 레이블 및 Spring 프로필을 선택하려면 레이블이 없는 모든 키와 Spring 프로필과 일치하는 키를 선택하는 ',${spring.profiles.active}'와 같은 레이블 필터를 사용할 수 있습니다. 중복 키를 찾을 때 가장 오른쪽 레이블이 우선합니다.

버전 3.1.0부터 Microsoft.FeatureManagement 라이브러리를 사용하면 기능 필터를 포함한 기능 관리 서비스를 종속성 주입 기반 .NET 애플리케이션의 범위가 지정된 서비스로 실행할 수 있습니다. 이 기능을 활용하기 위해 다음 코드 조각과 같이 코드의 AddFeatureManagement 호출을 단순히 AddScopedFeatureManagement로 바꿀 수 있습니다.

services.AddScopedFeatureManagement();

기능 필터는 HTTP 요청의 속성에 따라 기능 플래그를 평가할 수 있습니다. 이는 일반적으로 싱글톤 IHttpContextAccessor패턴을 통해 HttpContext를 검사하여 수행됩니다. 그러나 범위가 지정된 서비스를 대신 사용해야 하는 Blazor 서버 애플리케이션에서는 이 패턴이 작동하지 않습니다. 이 경우 AddScopedFeatureManagement 메서드를 사용해야 합니다.

GitHub 알림 리포지토리를 구독합니다.

GitHub에서 직접 연락할 수 있습니다.

• Azure App Configuration 정보