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 가격 책정 페이지를 참조하세요.

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

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

• 용도: 무료 계층은 비프로덕션 환경에서 서비스를 평가하기에 적합하므로 비용 없이 해당 기능을 탐색할 수 있습니다. 표준 계층은 중간 규모의 프로덕션 사용 사례에 맞게 조정되어 성능과 비용 효율성의 균형을 제공합니다. 대용량 또는 엔터프라이즈 수준 프로덕션 요구 사항의 경우 프리미엄 계층은 최고 수준의 성능 및 확장성을 제공하여 부하가 많은 경우에도 애플리케이션이 원활하게 실행되도록 합니다.

• 구독당 리소스: 리소스는 단일 구성 저장소로 구성됩니다. 각 구독은 무료 계층의 지역당 하나의 구성 저장소로 제한됩니다. 구독은 표준 및 프리미엄 계층에서 무제한의 구성 저장소를 가질 수 있습니다.

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

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

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

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

  프리미엄 계층 저장소는 요청에 대한 할당량 제한이 없으므로 저장소에 대한 액세스가 차단되지 않습니다.

• 처리량: 모든 계층의 App Configuration 저장소에는 처리량이 허용됩니다. 이 허용량을 초과하는 요청은 HTTP 상태 코드 429 응답을 받습니다. 무료 계층의 저장소에는 보장된 처리량이 없습니다.

  표준 계층의 저장소는 실행 속도† 읽기 요청에 대해 초당 최대 300개 요청(RPS) 및 쓰기 요청에 대해 최대 60개의 RPS를 허용합니다.

  프리미엄 계층의 저장소는 실행 속도† 읽기 요청에 대해 최대 450 RPS, 쓰기 요청에 대해 최대 100개의 RPS를 허용합니다.

  † 실행 속도는 일반적으로 지정된 기간 동안 제한하지 않고 App Configuration 저장소에서 처리하는 평균 요청 수로 측정됩니다.

• 서비스 수준 계약: 무료 계층에는 SLA가 없습니다. 표준 계층에는 지역 복제를 사용하도록 설정된 99.9%의 가용성 및 99.95%의 SLA가 있습니다. 프리미엄 계층에는 지역 복제를 사용하도록 설정된 99.9%의 가용성 및 99.99%의 SLA가 있습니다.

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

• 비용: 무료 계층 저장소를 사용하는 데 드는 비용은 없습니다.

  표준 계층 저장소에는 매일 처음 200,000개의 요청이 포함된 일일 사용 요금이 부과됩니다. 이 일일 할당을 초과하는 요청에는 초과분 요금이 발생합니다.

  프리미엄 계층 저장소에는 일일 사용 요금이 부과되며 복제본도 포함됩니다. 원본에 대한 처음 800,000개 요청과 매일 복제본에 대한 처음 800,000개의 요청이 일일 요금에 포함됩니다. 이 일일 할당을 초과하는 요청은 초과분 요금이 발생합니다.

예를 들어 무료 계층에서 표준 또는 프리미엄 계층으로 또는 표준 계층에서 프리미엄 계층으로 언제든지 App Configuration 저장소를 업그레이드할 수 있습니다.

예를 들어 프리미엄 계층에서 표준 계층으로 또는 표준 계층에서 무료 계층으로 App Configuration 저장소를 다운그레이드할 수 없습니다. 그러나 원하는 계층에 새 저장소를 만든 다음 구성 데이터를 해당 저장소를 가져올 수 있습니다.

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

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

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

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

App Configuration 저장소에는 계층에 따라 다른 요청 할당량이 있습니다. 무료 계층 저장소는 하루에 1,000개의 요청으로 제한되고 표준 계층 저장소는 시간당 30,000개의 요청으로 제한되며 프리미엄 계층 저장소에는 요청 제한이 없으므로 중단 없는 액세스가 보장됩니다.

App Configuration 저장소에는 해당 계층에 따라 처리량 허용량이 있습니다. 무료 계층 저장소는 처리량을 보장하지 않습니다. 표준 계층 저장소는 읽기 작업에 대해 초당 최대 300개의 RPS(요청 수)를 지원하고 쓰기 작업에는 최대 60개의 RPS를 지원합니다. 프리미엄 계층 저장소는 읽기 작업에는 최대 450 RPS, 쓰기 작업에는 최대 100개의 RPS를 지원합니다.

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

먼저 구성 모니터링에 대한 요청을 예측해 보겠습니다. 애플리케이션의 각 인스턴스는 30초마다 Sentinel 키에 대한 하나의 요청을 App Configuration에 보내므로 1시간 안에 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) 요청만 표준 계층 저장소에 사용 가능한 시간당 할당량을 사용합니다. 시간당 할당량 한도에 대해 충분한 버퍼를 갖도록 이 예제의 숫자를 특정 설정 및 디자인과 일치하도록 업데이트합니다.

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

애플리케이션은 다음과 같은 상황에서 HTTP 상태 코드 429 응답을 받을 수 있습니다.

• 무료 계층의 저장소에 대한 일일 요청 할당량을 초과합니다.
• 표준 계층의 저장소에 대한 시간당 요청 할당량을 초과합니다.
• 모든 계층의 저장소에 대한 처리량 허용량을 초과합니다.
• 모든 계층의 저장소에 대한 대역폭 허용량을 초과합니다.
• 스토리지 할당량을 초과할 때 키값을 만들거나 수정하려고 합니다.

요청이 실패한 특정 이유는 429 응답의 본문을 확인합니다. Azure Monitor App Configuration 저장소에 대한 로그를 수집하고 요청 할당량 사용량 메트릭에 대한 경고를 설정할 수도 있습니다.

App Configuration 클라이언트가 정상적으로 처리하므로 순간적인 HTTP 상태 코드 429 응답을 수신하면 일반적으로 아무런 피해도 발생하지 않습니다. 그러나 애플리케이션에 HTTP 상태 코드 429 응답이 정기적으로 발생하는 경우 다음 옵션을 고려합니다.

• 스토어를 프리미엄 계층으로 업그레이드: 이 계층은 요청에 대한 할당량 제한이 없으며 스토리지 할당량이 증가하고 처리량 허용량이 증가했습니다.
• App Configuration Providers 사용: 공급자에는 다른 많은 복원력 기능과 함께 기본 제공 재시도 및 캐싱 기능이 있습니다. 모든 최신 향상된 기능을 위해 최신 버전의 공급자로 업데이트해야 합니다.
• 애플리케이션이 쓰기 요청을 보내야 하는 경우 App Configuration SDK을 사용합니다. SDK는 공급자만큼 기능이 풍부하지 않을 수 있지만 HTTP 상태 코드 429 응답 및 기타 일시적인 오류에서 자동으로 다시 시도합니다.
• App Configuration Providers 또는 SDK를 사용할 수 없는 경우 사용자 지정 클라이언트 재시도 논리를 포함합니다. 응답의 retry-after-ms 헤더는 요청을 다시 시도하기 전에 제안된 대기 시간(밀리초)을 제공합니다.
• 여러 클라이언트 인스턴스 요청 분산: 이렇게 하면 App Configuration 저장소에서 최대 처리량을 달성할 수 있습니다.
• App Configuration에 대한 요청 줄이기: 요청 수를 최소화하기 위해 지침을 따릅니다.
• 애플리케이션 복원력 개선: 장애 조치(failover) 및 부하 분산을 허용하도록 지역 복제를 통합하는 것이 좋습니다. 복원력이 뛰어난 애플리케이션 빌드하는 모범 사례를 확인합니다.

표준 및 프리미엄 계층의 모든 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 정보