외부 구성 저장소 패턴

애플리케이션 배포 패키지에서 중앙 위치로 구성 정보를 이동합니다. 이 방법은 구성 데이터를 보다 쉽게 관리 및 제어하고 애플리케이션 및 애플리케이션 인스턴스 간에 구성 데이터를 공유할 수 있도록 합니다.

컨텍스트 및 문제점

대부분의 애플리케이션 런타임 환경에는 애플리케이션을 사용하여 배포하는 파일에 구성 정보가 포함됩니다. 경우에 따라 애플리케이션을 배포한 후 이러한 파일을 편집하여 애플리케이션의 동작을 변경할 수 있습니다. 그러나 구성을 변경하려면 애플리케이션을 다시 배포해야 합니다. 다시 배포하면 허용되지 않는 가동 중지 시간 및 기타 관리 오버헤드가 발생하는 경우가 많습니다.

또한 로컬 구성 파일은 구성을 단일 애플리케이션으로 제한합니다. 일부 시나리오에서는 여러 애플리케이션에서 구성 설정을 공유할 수 있습니다. 예를 들어 데이터베이스 연결 문자열, UI 테마 정보 및 관련 애플리케이션 집합이 사용하는 큐 및 스토리지의 URL이 있습니다.

애플리케이션의 여러 실행 중인 인스턴스에서 로컬 구성의 변경 내용을 관리하는 것은 어렵습니다. 챌린지로 인해 업데이트 배포 중에 다른 구성 설정을 사용하는 경우가 발생할 수 있습니다.

애플리케이션 및 구성 요소를 업데이트하려면 구성 스키마를 변경해야 할 수도 있습니다. 많은 구성 시스템은 다른 버전의 구성 정보를 지원하지 않습니다.

솔루션

구성 정보를 외부 스토리지에 저장하고 구성 설정을 빠르고 효율적으로 읽고 업데이트하는 데 사용할 수 있는 인터페이스를 제공합니다. 외부 저장소의 유형은 애플리케이션의 호스팅 및 런타임 환경에 따라 달라집니다. 클라우드 호스팅 시나리오에서 외부 스토리지는 일반적으로 클라우드 기반 스토리지 서비스 또는 전용 구성 서비스입니다. 호스트된 데이터베이스 또는 기타 사용자 지정 시스템일 수도 있습니다.

구성 정보에 대해 선택한 백업 저장소에는 일관되고 사용하기 쉬운 액세스를 제공하는 인터페이스가 있어야 합니다. 올바르게 형식화되고 구조화된 형식으로 정보를 노출해야 합니다. 구현은 구성 데이터를 보호하기 위해 사용자의 액세스 권한을 부여해야 할 수도 있습니다. 각 구성의 여러 릴리스 버전을 포함하여 개발, 스테이징 및 프로덕션과 같은 여러 버전의 구성을 저장할 수 있을 만큼 유연해야 할 수 있습니다.

많은 기본 제공 구성 시스템은 애플리케이션이 시작될 때 데이터를 읽은 다음 메모리에 데이터를 캐시하여 빠른 액세스를 제공하고 애플리케이션 성능에 미치는 영향을 최소화합니다. 사용하는 백업 저장소의 유형과 이 저장소의 대기 시간에 따라 외부 구성 저장소 내에서 캐싱 메커니즘을 구현할 수 있습니다. 자세한 내용은 캐싱 지침을 참조하세요. 다음 다이어그램에서는 선택적 로컬 캐시가 있는 외부 구성 저장소 패턴의 개요를 보여 줍니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

• 허용되는 성능, 고가용성 및 견고성을 제공하는 백업 저장소를 선택합니다. 애플리케이션 유지 관리 및 관리 프로세스에서 백업할 수 있는지 확인합니다. 클라우드 호스팅 애플리케이션에서 클라우드 스토리지 메커니즘 또는 전용 구성 플랫폼 서비스를 사용하여 이러한 요구 사항을 충족합니다.

• 백업 저장소의 스키마를 디자인하여 보유할 수 있는 정보 형식의 유연성을 허용합니다. 형식화된 데이터, 설정 컬렉션, 여러 버전의 설정 및 애플리케이션에 필요한 기타 기능과 같은 모든 구성 요구 사항에 대한 기능을 제공하는지 확인합니다. 스키마는 요구 사항이 변경될 때 더 많은 설정을 지원하도록 쉽게 확장할 수 있어야 합니다.

• 백업 저장소의 물리적 기능, 구성 정보를 저장하는 방법과 관련되는 방식 및 성능에 미치는 영향을 고려합니다. 예를 들어 구성 정보가 포함된 XML 문서를 저장하려면 구성 인터페이스 또는 애플리케이션이 문서를 구문 분석하여 개별 설정을 읽어야 합니다. 구문 분석하면 설정을 업데이트하는 방법이 복잡해지지만 설정을 캐싱하면 읽기 성능 저하를 상쇄하는 데 도움이 될 수 있습니다.

• 구성 인터페이스에서 구성 설정의 범위 및 상속을 제어하는 방법을 고려합니다. 예를 들어 조직, 애플리케이션 및 컴퓨터 수준에서 구성 설정의 범위를 지정해야 할 수 있습니다. 구성 인터페이스는 다른 범위에 대한 액세스를 제어하도록 위임하고 개별 애플리케이션이 설정을 재정의하도록 방지하거나 허용해야 할 수 있습니다.

• 구성 인터페이스가 형식화된 값, 컬렉션, 키-값 쌍 및 속성 모음과 같은 필수 형식으로 구성 데이터를 노출할 수 있는지 확인합니다.

• 설정에 오류가 포함되거나 백업 저장소에 없는 경우 구성 저장소 인터페이스가 어떻게 동작하는지 고려합니다. 기본 설정 및 로그 오류를 복원해야 할 수 있습니다. 또한 구성 설정 키 또는 이름의 대/소문자 구분, 이진 데이터를 저장 및 처리하는 방법 및 null 또는 빈 값을 처리하는 방법을 고려합니다.

• 구성 데이터를 보호하고 적절한 사용자 및 애플리케이션에만 액세스 권한을 부여하는 방법을 고려합니다. 구성 저장소 인터페이스는 일반적으로 이 기능을 제공하지만 사용자 및 애플리케이션이 적절한 권한 없이 백업 저장소의 데이터에 직접 액세스할 수 없도록 해야 합니다. 구성 데이터를 읽고 쓰는 데 필요한 권한 간에 엄격한 분리를 보장합니다. 또한 구성 설정의 일부 또는 전체를 암호화해야 하는지 여부와 구성 저장소 인터페이스에서 이 암호화를 구현하는 방법을 고려합니다.

  또한 감사 로깅을 설정하여 구성 값을 읽거나 수정하는 사람과 이러한 작업이 발생하는 시기를 기록해야 합니다. 구성 데이터의 로컬 대체 복사본에 동일한 감사 요구 사항을 적용합니다.

• 민감하지 않은 구성 값을 비밀과 구분합니다. 구성 설정에서 기능 플래그 및 엔드포인트와 같은 일상적인 설정을 유지합니다. 연결 문자열, API 키, 인증서 및 암호와 같은 비밀을 암호화 및 제어된 액세스를 제공하는 전용 비밀 관리 시스템에 저장합니다.

• 런타임 중에 애플리케이션 동작을 변경하는 중앙 집중식으로 저장된 구성은 매우 중요합니다. 애플리케이션 코드를 배포하는 데 사용하는 것과 동일한 메커니즘을 사용하여 배포, 업데이트 및 관리합니다. 예를 들어 완전히 테스트된 단계별 배포 방법을 사용하여 둘 이상의 애플리케이션에 영향을 줄 수 있는 변경 내용을 수행하여 변경 내용이 이 구성을 사용하는 모든 애플리케이션에 적합한지 확인해야 합니다. 관리자가 설정을 편집하여 한 애플리케이션을 업데이트하는 경우 동일한 설정을 사용하는 다른 애플리케이션에 부정적인 영향을 줄 수 있습니다. Azure App Configuration 같은 제품은 수정 기록, PITR(지정 시간 복구), 변경할 수 없는 스냅샷 및 점진적 출시 패턴과 같은 기본 제공 기능을 통해 이러한 위험을 완화하는 데 도움이 됩니다.

• 애플리케이션이 구성 정보를 캐시하는 경우 구성이 변경되면 애플리케이션에 경고해야 합니다. 이 정보가 주기적으로 자동으로 새로 고쳐지도록 캐시된 구성 데이터에 대한 만료 정책을 구현할 수 있습니다. 애플리케이션은 변경 내용을 확인하고 구현합니다.

• 캐시된 구성 데이터는 외부 구성 저장소가 애플리케이션 런타임에 경험하는 일시적인 연결 문제를 해결하는 데 도움이 될 수 있지만, 이 방법은 일반적으로 애플리케이션이 시작될 때 외부 저장소가 다운된 경우 문제를 해결하지 못합니다. 애플리케이션 배포 파이프라인이 시작 시 애플리케이션이 라이브 값을 검색할 수 없을 때 사용할 구성 파일의 마지막으로 알려진 구성 값 집합을 제공할 수 있는지 확인합니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

• 여러 애플리케이션 또는 인스턴스에서 구성 설정을 공유하거나 여러 애플리케이션 간에 표준 구성을 적용해야 합니다.

• 표준 구성 시스템은 이미지 또는 복잡한 데이터 구조와 같은 모든 필수 설정 유형을 지원하지 않습니다.

• 애플리케이션이 중앙에 저장된 일부 또는 전부 값을 재정의할 수 있도록 하면서 일부 설정에 대한 보완 저장소가 필요합니다.

• 여러 애플리케이션에서 관리를 간소화하고 필요에 따라 구성 저장소에 대한 액세스를 기록하여 구성 사용량을 모니터링해야 합니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

• 구성은 간단하고, 하나의 애플리케이션에 로컬이며, 일반 릴리스 주기 동안에만 변경됩니다. 이 경우 외부 구성 저장소는 불필요한 운영 복잡성을 추가할 수 있습니다.

워크로드 디자인

워크로드 디자인에서 외부 구성 저장소 패턴을 사용하여 Azure Well-Architected 프레임워크 핵심 요소 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

예시

다음 예제에서는 Azure 외부 구성 저장소 패턴을 구현하는 방법을 보여 줍니다. 첫 번째 예제에서는 App Configuration 및 클라이언트 라이브러리를 사용합니다. 두 번째 예제에서는 특수한 구현이 필요한 시나리오에 사용자 지정 백업 저장소를 사용합니다.

App Configuration

대부분의 애플리케이션은 사용자 지정 구성 저장소 대신 App Configuration 을 사용할 수 있습니다. App Configuration은 네임스페이스를 적용할 수 있는 키-값 쌍 을 지원합니다. 또한 App Configuration은 실행 중인 인스턴스에 위험 없이 구성 변경 내용을 검사, 롤백 또는 점진적으로 배포할 수 있도록 변경할 수 없는 구성 스냅샷 을 지원합니다.

스냅샷 참조를 사용하여 코드를 변경하거나 다시 배포하지 않고 런타임 시 애플리케이션이 스냅샷 간에 전환할 수 있도록 합니다. 애플리케이션이 시작될 때 서비스에 연결할 수 없는 경우 사용할 백업으로, 애플리케이션과 함께 전송되도록 구성 값을 내보낼 수 있습니다.

App Configuration에서 키 와 값 은 유니코드 문자열이며 각 키-값 쌍에는 레이블 기반 변형 및 콘텐츠 형식과 같은 선택적 메타데이터가 있습니다. 콘텐츠 형식을 사용하여 JSON 또는 기본 제공 App Configuration 형식과 같은 값을 애플리케이션에서 해석하는 방법을 설명합니다. 또한 App Configuration은 이전 키-값 쌍을 검토하고 복구하는 데 도움이 되는 PITR을 사용하여 수정 기록을 유지합니다.

복원력을 위해 가용성 영역을 지원하는 지역에 저장소를 프로비전하고 지역 복제 를 설정하여 지역 가동 중단 시 가장 가까운 복제본에서 읽고 복제본 엔드포인트 간에 전환하도록 애플리케이션을 구성할 수 있습니다. Azure Key Vault 참조를 사용하여 자격 증명을 구성 저장소에 직접 저장하는 대신 Key Vault에 비밀을 저장하고 App Configuration에서 이를 참조합니다. 연결 문자열 대신 관리 ID 및 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 App Configuration에 애플리케이션을 인증합니다.

AKS(Azure Kubernetes Service) 실행되는 워크로드의 경우 App Configuration Kubernetes Provider는 워크로드 컨테이너의 코드를 변경하지 않고도 저장소에서 직접 ConfigMaps 및 비밀을 생성할 수 있습니다. App Configuration을 사용하여 안전한 배포 사례에서 대상 출시 및 변형 기반 실험을 비롯한 기능 플래그를 관리할 수도 있습니다.

네트워크 격리를 위해 App Configuration에 대한 개인 엔드포인트를 사용하여 클라이언트 트래픽이 Azure Private Link를 통해 개인 IP 주소에 머물도록 하십시오. 프라이빗 액세스를 설정한 후 공용 액세스 권한을 해제하여 퍼블릭 엔드포인트 노출을 줄일 수 있습니다. 지역 복제 배포에서 단일 프라이빗 엔드포인트는 모든 복제본에 연결할 수 있지만 지역 복원력을 높이기 위해 각 복제본 지역에 대한 프라이빗 엔드포인트를 프로비전하고 그에 따라 DNS(도메인 이름 시스템)를 설정할 수 있습니다.

클라이언트 라이브러리

클라이언트 라이브러리는 이전의 많은 기능을 제공합니다. 클라이언트 라이브러리는 애플리케이션 런타임과 통합되어 값을 가져오고 캐시하고, 변경 시 값을 새로 고치고, App Configuration에서 일시적인 중단을 처리할 수 있습니다.

다음 App Configuration 동기화 GitHub 액션 및 기본 제공 Azure Pipelines 작업도 사용할 수 있습니다.

• 앱 구성 내보내기
• 앱 구성 가져오기

사용자 지정 백업 저장소 예제

Azure가 호스팅하는 애플리케이션에서 Azure Storage를 사용하여 구성 정보를 외부에 저장할 수 있습니다. 이 방법은 복원력과 고성능을 제공합니다. 기본적으로 Storage는 단일 데이터 센터 내에서 데이터를 세 번 복제합니다. 지역 간 지리적 중복성을 위해 수동 장애 조치 기능을 지원하는 지역 복제를 설정할 수 있습니다. Azure Table Storage 값에 유연한 스키마를 사용할 수 있는 키-값 저장소를 제공합니다. Azure Blob Storage 개별적으로 명명된 Blob에 모든 형식의 데이터를 저장할 수 있는 계층적 컨테이너 기반 저장소를 제공합니다.

이 패턴을 구현할 때는 Blob Storage 추상화하고 애플리케이션 내에서 설정을 노출해야 합니다. 또한 런타임에 업데이트를 확인하고 해당 업데이트에 응답하는 방법을 결정해야 합니다.

다음 예제에서는 간단한 구성 저장소 및 Blob Storage 사용하여 구성 정보를 저장하고 노출하는 방법을 보여줍니다. BlobSettingsStore 클래스는 구성 정보를 보관하기 위한 Blob Storage 추상화합니다. 간단한 ISettingsStore 인터페이스를 구현합니다.

public interface ISettingsStore
{
    Task<ETag> GetVersionAsync();
    Task<Dictionary<string, string>> FindAllAsync();
}

이 인터페이스는 구성 저장소가 보유하는 구성 설정을 검색하는 메서드를 정의하고 최근 구성 설정 수정 사항을 검색하는 데 사용할 수 있는 버전 번호를 포함합니다. 클래스는 BlobSettingsStore Blob의 ETag 속성을 사용하여 버전 관리 구현을 구현할 수 있습니다. ETag Blob을 쓸 때마다 속성이 자동으로 업데이트됩니다.

클래스는 BlobSettingsStore 인스턴스를 감싸는 ExternalConfigurationManager 래퍼를 제공합니다. 애플리케이션은 이 클래스를 사용하여 구성 정보를 검색할 수 있습니다. 이 클래스는 Microsoft 반응형 확장 같은 변경 알림 메커니즘을 사용하여 시스템이 실행되는 동안 구성 업데이트를 게시할 수 있습니다. 또한 더 나은 복원력과 성능을 제공하기 위해 설정에 대한 Cache-Aside 패턴을 구현합니다.

다음 예제에서는 ExternalConfigurationManager 클래스의 구현 예제를 보여줍니다.

static void Main(string[] args)
{
    // Start monitoring configuration changes.
    ExternalConfiguration.Instance.StartMonitor();

    // Get a setting.
    var setting = ExternalConfiguration.Instance.GetAppSetting("someSettingKey");
    …
}

다음 단계

• 애플리케이션 구성 예제
• Helm을 사용하여 Kubernetes 배포와 App Configuration 통합
• App Configuration에서 기능 플래그 관리
• 캐싱 지침
• 앱 구성 모범 사례

관련 리소스

• Cache-Aside 패턴