Azure App Configuration 모범 사례

  • 아티클

이 문서에서는 Azure App Configuration 사용의 일반적인 패턴 및 모범 사례에 대해 설명합니다.

키 그룹화

App Configuration은 키를 구성하는 두 가지 옵션을 제공합니다.

  • 키 접두사
  • 레이블

두 옵션 중 하나 또는 두 옵션 모두를 사용하여 키를 그룹화할 수 있습니다.

키 접두사는 키의 시작 부분입니다. 이름에 동일한 접두사를 사용하여 키 집합을 논리적으로 그룹화할 수 있습니다. 접두사는 URL 경로와 유사하게 구분 기호 /로 연결된 여러 구성 요소를 포함하여 네임스페이스를 형성할 수 있습니다. 해당 계층은 하나의 App Configuration 저장소에 많은 애플리케이션 및 마이크로 서비스에 대한 키를 저장하는 경우에 유용합니다.

중요한 점은 키는 애플리케이션 코드가 해당 설정의 값을 검색하기 위해 참조하는 키라는 것입니다. 키는 변경되지 않아야 합니다. 그렇지 않으면 매번 코드를 수정해야 합니다.

레이블은 키에 대한 특성입니다. 레이블은 키의 변형을 만드는 데 사용됩니다. 예를 들어 여러 버전의 키에 레이블을 할당할 수 있습니다. 키의 버전은 반복, 환경 또는 일부 다른 컨텍스트 정보일 수 있습니다. 애플리케이션은 다른 레이블을 지정하여 완전히 다른 키 값 집합을 요청할 수 있습니다. 결과적으로 모든 키 참조는 코드에서 변경되지 기본.

키-값 컴퍼지션

App Configuration은 함께 저장된 모든 키를 독립적인 엔터티로 처리합니다. App Configuration은 키 간의 관계를 유추하거나 해당 계층 구조에 따라 키-값을 상속하려고 시도하지 않습니다. 그러나 애플리케이션 코드에서 적절한 구성 스택과 결합된 레이블을 사용하여 여러 키 집합을 집계할 수 있습니다.

예를 살펴보겠습니다. 자산1이라는 설정이 있다고 가정해 보겠습니다. 해당 값은 개발 환경에 따라 달라질 수 있습니다. 빈 레이블과 ‘Development’ 레이블이 있는 ‘Asset1’ 키를 만듭니다. 첫 번째 레이블에서 Asset1의 기본값을 입력하고 후자에 "개발"에 대한 특정 값을 입력합니다.

코드에서 먼저 레이블 없이 키-값을 검색한 다음, "개발" 레이블을 사용하여 동일한 키 값 집합을 두 번째로 검색합니다. 두 번째로 값을 검색하면 키의 이전 값을 덮어씁니다. .NET 구성 시스템을 사용하면 여러 구성 데이터 집합을 서로 위에 "쌓을" 수 있습니다. 키가 둘 이상의 집합에 있는 경우 키를 포함하는 마지막 집합이 사용됩니다. .NET과 같은 최신 프로그래밍 프레임워크를 사용하면 네이티브 구성 공급자를 사용하여 App Configuration에 액세스하는 경우 이 스태킹 기능을 무료로 사용할 수 있습니다. 다음 코드 조각은 .NET 애플리케이션에서 스택을 구현하는 방법을 보여줍니다.

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

다른 환경에 대해 각기 다른 구성을 설정하도록 레이블 사용은 전체 예제를 제공합니다.

외부 데이터에 대한 참조

App Configuration은 일반적으로 구성 파일 또는 환경 변수에 저장하는 모든 구성 데이터를 저장하도록 설계되었습니다. 그러나 일부 유형의 데이터는 다른 원본에 상주하는 데 더 적합할 수 있습니다. 예를 들어 Key Vault, Azure Storage의 파일, Microsoft Entra 그룹의 멤버 자격 정보 또는 데이터베이스의 고객 목록에 비밀을 저장합니다.

외부 데이터에 대한 참조를 키-값에 저장하여 App Configuration을 계속 활용할 수 있습니다. 콘텐츠 형식을 사용하여 각 데이터 원본을 구분할 수 있습니다. 애플리케이션이 참조를 읽을 때 참조된 원본에서 실제 데이터를 로드합니다. 원본에 필요한 권한이 있다고 가정합니다. 외부 데이터의 위치를 변경하는 경우 전체 애플리케이션을 업데이트하고 다시 배포하는 대신 App Configuration에서 참조를 업데이트하기만 하면 됩니다.

App Configuration Key Vault 참조 기능은 이 경우의 예입니다. 기본 비밀 자체가 Key Vault에 남아 있는 동안 필요에 따라 애플리케이션을 업데이트하는 데 필요한 비밀을 사용할 수 있습니다.

App Configuration 부트스트랩

App Configuration 저장소에 액세스하려면 Azure Portal에서 사용할 수 있는 연결 문자열 사용할 수 있습니다. 연결 문자열에는 자격 증명 정보가 포함되어 있으므로 비밀로 간주됩니다. 해당 암호는 Azure Key Vault에 저장해야 하며, 코드를 검색하려면 Key Vault에 인증해야 합니다.

더 나은 옵션은 Microsoft Entra ID에서 관리 ID 기능을 사용하는 것입니다. 관리 ID를 사용하면 App Configuration 저장소에 대한 액세스를 부트스트랩하려면 App Configuration 엔드포인트 URL만 필요합니다. 애플리케이션 코드(예: appsettings.json 파일)에 URL을 포함할 수 있습니다. 자세한 내용은 관리 ID를 사용하여 App Configuration 액세스를 참조하세요.

App Configuration에 대한 Azure Kubernetes Service 액세스

AKS(Azure Kubernetes Service)에서 호스트되는 워크로드에서 Azure 앱 Configuration에 액세스하는 데 사용할 수 있는 옵션은 다음과 같습니다. 이러한 옵션은 일반적으로 Kubernetes에도 적용됩니다.

  • AKS 클러스터에 Azure 앱 Configuration Kubernetes Provider를 추가합니다. Kubernetes 공급자는 클러스터에서 Pod로 실행됩니다. App Configuration 저장소의 키-값 및 Key Vault 참조에서 구성지도 및 비밀을 생성할 수 있습니다. ConfigMap 및 Secret은 애플리케이션 코드를 수정할 필요 없이 환경 변수 또는 탑재된 파일로 사용할 수 있습니다. 동일한 AKS 클러스터에서 여러 애플리케이션을 실행하는 경우 생성된 구성지도 및 비밀에 모두 액세스할 수 있으므로 App Configuration에 대한 개별 요청이 필요하지 않습니다. Kubernetes 공급자는 동적 구성 업데이트도 지원합니다. 가능한 경우 권장되는 옵션입니다.

  • Azure 앱 구성 공급자 라이브러리를 사용하도록 애플리케이션을 업데이트합니다. 공급자 라이브러리는 ASP.NET, .NET, Java Spring, JavaScript/Node.js 및 Python과 같은 많은 프레임워크 및 언어에서 사용할 수 있습니다. 이 방법으로 동적 구성 및 기능 관리를 비롯한 App Configuration의 모든 기능에 액세스할 수 있습니다. 로드할 데이터와 각 애플리케이션에 대한 App Configuration 저장소를 세분화하여 제어할 수 있습니다.

  • Helm을 사용하여 Kubernetes 배포와 통합합니다. 애플리케이션을 업데이트하거나 AKS 클러스터에 새 Pod를 추가하지 않으려면 배포를 통해 Helm을 사용하여 App Configuration에서 Kubernetes 클러스터로 데이터를 가져오는 옵션이 있습니다. 이 방법을 사용하면 애플리케이션이 Kubernetes 변수 및 비밀에서 구성에 계속 액세스할 수 있습니다. 애플리케이션이 새 구성 변경 내용을 통합하도록 할 때마다 Helm 업그레이드를 실행할 수 있습니다.

App Configuration에 대한 App Service 또는 Azure Functions 액세스

App Configuration 공급자 또는 SDK 라이브러리를 사용하여 애플리케이션에서 App Configuration에 직접 액세스합니다. 이 방법으로 동적 구성 및 기능 관리를 비롯한 App Configuration의 모든 기능에 액세스할 수 있습니다. App Service 또는 Azure Functions에서 실행되는 애플리케이션은 다음 방법 중 하나를 통해 App Configuration 저장소에 액세스할 수 있습니다.

  • App Service 또는 Azure Functions에서 관리 ID를 사용하도록 설정하고 App Configuration 저장소에 대한 액세스 권한을 부여합니다. 자세한 내용은 관리 ID를 사용하여 App Configuration에 액세스를 참조하세요.
  • App Service 또는 Azure Functions의 애플리케이션 설정에서 연결 문자열을 App Configuration 저장소에 저장합니다. 보안을 강화하려면 연결 문자열을 Key Vault에 저장하고 App Service 또는 Azure Functions에서 참조합니다.

또한 App Configuration 데이터가 애플리케이션 설정 또는 환경 변수로 애플리케이션에 액세스할 수 있게 만들 수 있습니다. 이 방법을 사용하면 애플리케이션 코드를 변경하지 않아도 됩니다.

App Configuration에 대한 요청 줄이기

App Configuration에 대한 과도한 요청은 제한 또는 초과 요금이 발생할 수 있습니다. 요청 수를 줄이려면 다음을 수행합니다.

  • 특히 구성 값이 자주 변경되지 않는 경우 새로 고침 시간 제한을 늘깁니다. SetCacheExpiration 메서드를 사용하여 새로 고침 제한 시간을 새로 지정합니다.

  • 개별 키를 보는 대신 단일 sentinel 키를 봅니다. sentinel 키가 변경된 경우에만 모든 구성을 새로 고칩니다. 예제는 ASP.NET Core 앱에서 동적 구성 사용을 참조하세요.

  • 변경 내용에 대해 지속적으로 폴링하는 대신 Azure Event Grid를 사용하여 구성이 변경될 때 알림을 받습니다. 자세한 내용은 App Configuration 데이터 변경 알림에 Event Grid 사용을 참조하세요.

  • App Configuration 저장소의 지역 복제를 사용하도록 설정하고 요청을 여러 복제본에 분산합니다. 예를 들어 전역적으로 배포된 애플리케이션에 대해 각 지리적 지역과 다른 저장소를 사용합니다. 각 App Configuration 복제본에는 별도의 요청 할당량이 있습니다. 이 설정은 일시적 및 지역적 중단에 대한 확장성 및 향상된 복원력에 대한 모델을 제공합니다.

구성 데이터를 App Configuration으로 가져오기

App Configuration은 Azure Portal 또는 CLI를 사용하여 현재 구성 파일에서 구성 설정을 대량 으로 가져오는 옵션을 제공합니다. 동일한 옵션을 사용하여 App Configuration에서 키-값을 내보낼 수도 있습니다(예: 관련 저장소 간에 이동). GitHub 또는 Azure DevOps의 리포지토리와의 지속적인 동기화를 설정하려는 경우 GitHub 작업 또는 Azure Pipeline 푸시 작업을 사용하여 App Configuration의 혜택을 누리면서 기존의 원본 제어 방법을 계속 사용할 수 있습니다.

App Configuration의 다중 지역 배포

애플리케이션이 여러 지역에 배포된 경우 App Configuration 저장소의 지역에서 복제를 사용하도록 설정하는 것이 좋습니다. 애플리케이션이 주로 애플리케이션 인스턴스가 배포되는 지역과 일치하는 복제본(replica)을 연결하고 다른 지역의 복제본으로 장애 조치(failover)할 수 있도록 할 수 있습니다. 이 설정은 애플리케이션과 App Configuration 간의 대기 시간을 최소화하고, 각 복제본(replica) 별도의 제한 할당량이 있으므로 부하를 분산하고, 일시적 및 지역적 중단에 대한 애플리케이션의 복원력을 향상시킵니다. 자세한 내용은 복원력 및 재해 복구를 참조하세요.

높은 복원력으로 애플리케이션 빌드

애플리케이션은 종종 구성을 사용하여 시작하므로 Azure 앱 구성의 고가용성이 중요합니다. 향상된 복원력을 위해 애플리케이션은 App Configuration의 안정성 기능을 활용하고 특정 요구 사항에 따라 다음 조치를 취하는 것이 좋습니다.

  • Azure 가용성 영역 지원을 사용하여 지역에서 프로비전합니다. 가용성 영역을 사용하면 애플리케이션이 데이터 센터 중단에 대한 복원력을 줍니다. App Configuration은 추가 비용 없이 모든 고객에게 영역 중복성을 제공합니다. 가용성 영역을 지원하는 지역에서 App Configuration 저장소를 만드는 것이 좋습니다. App Configuration에서 가용성 영역 지원을 사용하도록 설정한 지역 목록을 찾을 수 있습니다.
  • 지역 복제본(replica) 사용하도록 설정하고 애플리케이션이 복제본(replica) 간에 장애 조치(failover)할 수 있도록 허용합니다. 이 설정은 일시적인 오류 및 지역 중단에 대한 확장성 및 향상된 복원력을 위한 모델을 제공합니다. 자세한 내용은 복원력 및 재해 복구를 참조하세요.
  • 안전한 배포 방법을 사용하여 구성을 배포합니다. 잘못되거나 실수로 구성을 변경하면 애플리케이션 가동 중지 시간이 자주 발생할 수 있습니다. 프로덕션에 직접 영향을 주는 구성 변경은 피해야 합니다(예: 가능하면 Azure Portal). SDP(안전한 배포 사례)에서는 점진적 노출 배포 모델을 사용하여 배포로 인한 문제의 잠재적인 폭발 반경을 최소화합니다. SDP를 채택하는 경우 프로덕션에 배포하기 전에 구성 스냅샷 빌드하고 테스트할 수 있습니다. 배포하는 동안 애플리케이션 인스턴스를 업데이트하여 새 스냅샷 점진적으로 선택할 수 있습니다. 문제가 감지되면 LKG(마지막으로 알려진 정상) 스냅샷 다시 배포하여 변경 사항을 롤백할 수 있습니다. 스냅샷 변경할 수 있으므로 모든 배포에서 일관성을 보장합니다. 동적 구성과 함께 스냅샷 활용할 수 있습니다. 응급 구성 재정의 및 기능 플래그에 대한 기본 구성 및 동적 구성에 대한 스냅샷 사용합니다.
  • 애플리케이션에 구성을 포함합니다. 애플리케이션이 항상 구성 복사본에 액세스할 수 있도록 하거나 App Configuration에 대한 런타임 종속성을 모두 방지하려는 경우 빌드 또는 릴리스 시간 동안 App Configuration에서 구성을 가져와서 애플리케이션에 포함할 수 있습니다. 자세한 내용은 APP Configuration을 CI/CD 파이프라인 또는 Kubernetes 배포와 통합하는 예제를 검사.
  • App Configuration 공급자를 사용합니다. 애플리케이션은 네트워킹 문제와 같이 런타임 중에 발생하는 문제를 고려하고 오류에 더 빠르게 대응할 수 있으므로 높은 복원력을 달성하는 데 중요한 역할을 합니다. App Configuration 공급자는 자동 복제본(replica) 검색, 복제본(replica) 장애 조치, 사용자 지정 가능한 시간 제한을 사용한 시작 다시 시도, 구성 캐싱 및 안정적인 구성 새로 고침을 위한 적응 전략을 비롯한 다양한 기본 제공 복원 기능을 제공합니다. 이러한 기능을 활용하려면 App Configuration 공급자를 사용하는 것이 좋습니다. 옵션이 아닌 경우 가장 높은 수준의 복원력을 달성하기 위해 사용자 지정 솔루션에서 유사한 기능을 구현하는 것이 좋습니다.

App Configuration의 클라이언트 애플리케이션

클라이언트 애플리케이션에서 App Configuration을 사용하는 경우 두 가지 주요 요소를 고려해야 합니다. 먼저 클라이언트 애플리케이션에서 연결 문자열 사용하는 경우 App Configuration 저장소의 액세스 키를 공개할 위험이 있습니다. 둘째, 클라이언트 애플리케이션의 일반적인 규모로 인해 App Configuration 저장소에 대한 과도한 요청이 발생할 수 있으므로 초과 요금 또는 제한이 발생할 수 있습니다. 제한에 대한 자세한 내용은 FAQ를 참조하세요.

이러한 문제를 해결하려면 클라이언트 애플리케이션과 App Configuration 저장소 간에 프록시 서비스를 사용하는 것이 좋습니다. 프록시 서비스는 인증 정보를 유출하는 보안 문제 없이 App Configuration 저장소로 안전하게 인증할 수 있습니다. App Configuration 공급자 라이브러리 중 하나를 사용하여 프록시 서비스를 빌드할 수 있으므로 App Configuration으로 전송되는 요청 볼륨을 최적화하기 위해 기본 제공 캐싱 및 새로 고침 기능을 활용할 수 있습니다. App Configuration 공급자 사용에 대한 자세한 내용은 빠른 시작 및 자습서의 문서를 참조하세요. 프록시 서비스는 캐시에서 클라이언트 애플리케이션으로 구성을 제공하며 이 섹션에서 설명하는 두 가지 잠재적인 문제를 방지합니다.

App Configuration의 클라이언트 애플리케이션

다중 테넌트 애플리케이션은 애플리케이션의 공유 인스턴스가 여러 고객 또는 테넌트에 서비스를 제공하는 아키텍처를 기반으로 합니다. 예를 들어 사용자에게 별도의 계정과 사용자 지정 환경을 제공하는 이메일 서비스가 있을 수 있습니다. 애플리케이션은 일반적으로 각 테넌트에 대해 서로 다른 구성을 관리합니다. 다음은 다중 테넌트 애플리케이션에서 App Configuration 사용에 대한 몇 가지 아키텍처 고려 사항입니다.

코드로 구성

코드로 구성은 소스 제어 시스템(예: git 리포지토리)에서 구성 파일을 관리하는 방법입니다. 이 기능은 모든 구성 변경에 대한 추적 가능성 및 승인 프로세스와 같은 이점을 제공합니다. 구성을 코드로 채택하는 경우 App Configuration에는 파일에서 구성 데이터를 관리하고 빌드, 릴리스 또는 CI/CD 프로세스의 일부로 배포하는 데 도움이 되는 도구가 있습니다. 이러한 방식으로 애플리케이션은 App Configuration 저장소에서 최신 데이터에 액세스할 수 있습니다.

  • GitHub의 경우 리포지토리에 대해 앱 구성 동기화 GitHub 작업을 사용하도록 설정할 수 있습니다. 구성 파일의 변경 내용은 끌어오기 요청이 병합될 때마다 App Configuration에 자동으로 동기화됩니다.
  • Azure DevOps의 경우 데이터 동기화를 위한 빌드 또는 릴리스 파이프라인에 Azure 파이프라인 작업인 Azure App Configuration Push를 포함할 수 있습니다.
  • CI/CD 시스템의 일부로 Azure CLI를 사용하여 구성 파일을 App Configuration으로 가져올 수도 있습니다. 자세한 내용은 az appconfig kv import를 참조하세요.

이 모델을 사용하면 App Configuration에 데이터를 커밋하기 전에 유효성 검사 및 테스트 단계를 포함할 수 있습니다. 여러 App Configuration 저장소를 사용하는 경우 구성 데이터를 한 번에 증분 또는 모두 푸시할 수도 있습니다.

다음 단계