다음을 통해 공유

Azure App Configuration 모범 사례

  • 아티클

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

키 그룹화

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

  • 키 접두사
  • 레이블

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

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

명심해야 할 점은 키가 애플리케이션 코드에서 해당 설정의 값을 검색하기 위해 참조하는 것이라는 것입니다. 키를 변경해서는 안 되고, 변경 시에는 코드를 수정해야 합니다.

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

키-값 컴포지션

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

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

코드에서 먼저 레이블 없는 키-값을 검색한 다음, ‘Development’ 레이블을 사용하여 동일한 키-값 집합을 다시 검색합니다. 키 값을 다시 검색할 때 키의 이전 값은 덮어쓰기됩니다. .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 엔드포인트 URL만으로 App Configuration 저장소에 대한 액세스를 부트스트랩할 수 있습니다. 애플리케이션 코드(예: appsettings.json 파일)에 URL을 포함할 수 있습니다. 자세한 내용은 관리 ID를 사용하여 App Configuration 액세스를 참조하세요.

App Configuration에 대한 Azure Kubernetes Service 액세스

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

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

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

  • Helm을 사용하여 Kubernetes 배포와 통합. 애플리케이션을 업데이트하거나 AKS 클러스터에 새 Pod를 추가하지 않으려면 배포를 통해 Helm을 사용하여 App Configuration에서 Kubernetes 클러스터로 데이터를 가져오는 옵션이 있습니다. 이러한 방식으로 애플리케이션은 Kubernetes 변수 및 Secret에서 구성에 계속 액세스할 수 있습니다. 애플리케이션이 새 구성 변경 내용을 통합하도록 할 때마다 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으로 보내는 과도한 요청은 대역폭 제한 또는 추가 요금을 발생시킬 수 있습니다. 요청 수를 줄이려면 다음을 수행합니다.

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

App Configuration에서는 Azure Portal 또는 CLI를 사용하여 현재 구성 파일에서 구성 설정을 대량으로 가져올 수 있는 옵션을 제공합니다. 동일한 옵션을 사용하여 App Configuration에서 키-값을 내보낼 수도 있습니다(예: 관련 저장소 간에 이동). GitHub 또는 Azure DevOps에서 구성을 코드로 채택하고 구성을 관리하는 경우 GitHub Actions 또는 Azure Pipeline 푸시 작업을 사용하여 진행 중인 구성 파일 가져오기를 설정할 수 있습니다.

App Configuration에서 여러 하위 지역 배포

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

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

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

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

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

다음 단계