외부 구성 저장소 패턴

구성 정보를 애플리케이션 배포 패키지에서 중앙 위치로 이동합니다. 이렇게 하면 구성 데이터를 더 쉽게 관리하고 제어하며 구성 데이터를 애플리케이션과 애플리케이션 인스턴스에서 공유할 기회를 제공할 수 있습니다.

컨텍스트 및 문제점

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

또한 로컬 구성 파일은 구성을 단일 애플리케이션으로 제한하지만 경우에 따라 여러 애플리케이션에서 구성 설정을 공유하는 것이 유용할 수 있습니다. 그와 같은 사례로는 데이터베이스 연결 문자열, UI 테마 정보, 큐의 URL 및 애플리케이션의 관련 집합이 사용하는 스토리지를 꼽을 수 있습니다.

문제는 특히 클라우드 호스팅 시나리오와 관련해 애플리케이션에서 실행 중인 여러 인스턴스의 로컬 구성 변경 내용을 관리하기가 어렵다는 것입니다. 그 결과 업데이트를 배포하는 동안 여러 구성 설정을 사용하는 인스턴스가 발생할 수 있습니다.

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

솔루션

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

구성 정보를 위해 선택하는 백업 저장소는 일관되고 사용하기 쉬운 액세스를 제공하는 인터페이스를 포함해야 합니다. 인터페이스는 올바르게 형식화된 정보를 구조화된 형식으로 표시해야 합니다. 구현도 구성 데이터를 보호하기 위해 사용자 액세스에 권한을 부여해야 하고 구성의 여러 버전(각각의 구성별로 여러 릴리스 버전을 포함하는 개발, 준비, 프로덕션 등)을 스토리지할 수 있을 정도로 충분히 유연해야 합니다.

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

문제 및 고려 사항

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

허용 가능한 성능, 고가용성, 견고성을 제공하고 애플리케이션 기본 테넌트 및 관리 프로세스의 일부로 백업할 수 있는 백업 저장소를 선택합니다. 클라우드 호스티드 애플리케이션에서 클라우드 스토리지 메커니즘 또는 전용 구성 플랫폼 서비스의 사용은 이런 요구 사항을 충족하는 일반적인 선택입니다.

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

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

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

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

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

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

런타임 중에 애플리케이션 동작을 변경하는 중앙에 저장된 구성은 매우 중요하며 애플리케이션 코드 배포와 동일한 메커니즘을 사용하여 배포, 업데이트 및 관리해야 합니다. 예를 들어 둘 이상의 애플리케이션에 영향을 줄 수 있는 변경 내용은 이 구성을 사용하는 모든 애플리케이션에 적합한지 확인하기 위해 전체 테스트 및 준비된 배포 방법을 사용하여 수행해야 합니다. 관리자가 설정을 편집하여 한 애플리케이션을 업데이트하는 경우 동일한 설정을 사용하는 다른 애플리케이션에 부정적인 영향을 줄 수 있습니다.

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

구성 데이터를 캐싱하면 애플리케이션 런타임 시 외부 구성 저장소의 일시적인 연결 문제를 해결하는 데 도움이 될 수 있지만, 애플리케이션이 처음 시작될 때 외부 저장소가 다운된 경우 일반적으로 문제가 해결되지 않습니다. 애플리케이션이 시작될 때 라이브 값을 검색할 수 없는 경우 애플리케이션 배포 파이프라인이 구성 파일에서 마지막으로 알려진 구성 값 세트를 대체(fallback)로 제공할 수 있는지 확인합니다.

이 패턴을 사용해야 하는 경우

이 패턴은 다음의 경우에 유용합니다.

• 구성 설정이 여러 애플리케이션과 애플리케이션 인스턴스에 공유되는 경우 또는 여러 애플리케이션과 애플리케이션 인스턴스에 표준 구성을 사용해야 하는 경우

• 이미지 저장 또는 복잡한 데이터 유형과 같은 필요한 구성 설정을 모두 지원하지는 않는 표준 구성 시스템

• 애플리케이션에 대한 일부 설정에 대한 보완 저장소로서 애플리케이션이 중앙에 저장된 설정의 일부 또는 전부를 재정의할 수 있도록 할 수 있습니다.

• 여러 애플리케이션의 관리를 단순화하는 방식으로 구성 스토리지에 대한 액세스의 일부 또는 모든 유형을 로그하여 구성 설정의 사용을 선택적으로 모니터링하는 경우

워크로드 디자인

설계자는 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하기 위해 워크로드 디자인에 외부 구성 저장소 패턴을 사용하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

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

Microsoft Azure 호스티드 애플리케이션에서 구성 정보를 외부적으로 저장하기 위한 가능한 선택은 Azure Storage를 사용하는 것입니다. Azure Storage는 복원력이 있고, 고성능을 제공하며, 자동 장애 조치(Failover)로 3번 복제되어 고가용성을 제공합니다. Azure Table Storage는 값에 유연한 스키마를 사용할 수 있는 키/값 저장소를 제공합니다. Azure Blob Storage는 데이터의 유형을 개별적으로 명명된 blob에 보관할 수 있는 계층적 컨테이너 기반 저장소를 제공합니다.

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

다음 예제는 구성 정보를 저장하고 노출하기 위해 Blob 스토리지를 통해 단순화된 구성 저장소를 구상하는 방법을 보여 줍니다. BlobSettingsStore 클래스는 구성 정보를 보유하기 위해 Blob 스토리지를 추상화하고 간단한 ISettingsStore 인터페이스를 구현할 수 있습니다.

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

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

보통 이런 간단한 그림은 모든 구성 설정을 형식화된 값이 아닌 문자열 값으로 표시합니다.

그런 다음, ExternalConfigurationManager 클래스는 BlobSettingsStore 인스턴스 주위에 래퍼를 제공할 수 있습니다. 애플리케이션은 이 클래스를 사용하여 구성 정보를 검색할 수 있습니다. 이 클래스는 Microsoft Reactive Extensions와 같은 항목을 사용하여 시스템이 실행되는 동안 구성에 대한 변경 내용을 게시할 수 있습니다. 또한 추가 복원력과 성능을 제공하기 위해 설정에 대한 캐시 배제 패턴을 구현해야 합니다.

사용량은 다음과 유사할 수 있습니다.

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

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

Azure App Configuration 사용

사용자 지정 구성 저장소를 빌드해야 하는 경우도 있지만 많은 애플리케이션에서 대신 Azure App Configuration을 사용할 수 있습니다. Azure App Configuration은 네임스페이스로 지정할 수 있는 키-값 쌍을 지원합니다. 키는 형식화되고 개별적으로 버전이 지정됩니다. 또한 Azure App Configuration은 구성의 지정 시간 스냅샷을 지원하므로 이전 구성 값을 쉽게 검사하거나 롤백할 수도 있습니다. 애플리케이션을 시작할 때 서비스에 연결할 수 없는 경우 구성 복사본을 애플리케이션과 함께 제공할 수 있도록 구성 값을 내보낼 수 있습니다.

클라이언트 라이브러리

이러한 기능의 대부분은 애플리케이션 런타임과 통합되는 클라이언트 라이브러리를 통해 노출되어 값을 가져오고 캐싱하고, 변경 시 값을 새로 고치고, App Configuration Service의 일시적인 중단을 처리할 수 있습니다.

클라이언트 라이브러리 외에도 구성 동기화 GitHub 작업 및 Azure 앱 구성 끌어오기 및 Azure 앱 구성 푸시 Azure DevOps 작업과 Azure 앱 구성 단계를 빌드 프로세스에 통합합니다.

다음 단계

• 추가 App Configuration 샘플 참조
• Kubernetes 배포와 Azure App Configuration 통합 방법 알아보기
• Azure App Configuration에서 기능 플래그를 관리하는 데 어떻게 도움이 되는지 알아보기