업무상 중요한 여정을 막 시작하는 경우 이 아키텍처를 참조로 사용합니다. 워크로드는 퍼블릭 엔드포인트를 통해 액세스되며 다른 회사 리소스에 대한 프라이빗 네트워크 연결이 필요하지 않습니다.
Azure의 중요 업무용 워크로드를 위한 아키텍처 패턴
이 문서에서는 Azure의 중요 업무용 아키텍처에 대한 주요 패턴을 제공합니다. 디자인 프로세스를 시작할 때 이 패턴을 적용한 다음 비즈니스 요구 사항에 가장 적합한 구성 요소를 선택합니다. 이 문서에서는 북쪽 star 디자인 접근 방식을 권장하고 일반적인 기술 구성 요소가 있는 다른 예제를 포함합니다.
다음 특성을 염두에 두고 주요 디자인 영역을 평가하고, 기본 구성 요소를 사용하는 중요한 사용자 및 시스템 흐름을 정의하고, Azure 리소스 및 해당 구성의 매트릭스를 개발하는 것이 좋습니다.
특성 | 고려 사항 |
---|---|
수명 | 솔루션의 다른 리소스를 기준으로 리소스의 예상 수명은 어떻게 됩니까? 리소스가 전체 시스템 또는 지역의 수명을 초과하거나 수명을 공유해야 하나요? 아니면 일시적이어야 하나요? |
시스템 상태 | 이 계층의 지속형 상태는 안정성 또는 관리 효율성에 어떤 영향을 미치나요? |
도달률 | 리소스를 전역으로 배포해야 하나요? 리소스가 전역적으로 또는 해당 지역 내에 있는 다른 리소스와 통신할 수 있나요? |
종속성 | 다른 리소스에 대한 종속성은 무엇인가요? |
확장 한도 | 해당 리소스의 예상 처리량은 무엇인가요? 해당 수요에 맞게 리소스에서 얼마나 큰 스케일을 제공하나요? |
가용성/재해 복구 | 이 계층의 재해로 인한 가용성에 미치는 영향은 무엇인가요? 시스템 중단 또는 지역화된 용량 또는 가용성 문제만 발생합니까? |
중요
이 문서는 Azure Well-Architected 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.
핵심 아키텍처 패턴
전역 리소스
특정 리소스는 각 지역 내에 배포된 리소스에서 전역적으로 공유됩니다. 일반적인 예로는 여러 지역에 트래픽을 분산하고, 전체 애플리케이션에 대한 영구 상태를 저장하고, 리소스를 모니터링하는 데 사용되는 리소스가 있습니다.
특성 | 고려 사항 |
---|---|
수명 | 이러한 리소스는 오래 지속될 것으로 예상됩니다(임시가 아닌 경우). 그들의 수명은 시스템의 수명이거나 그 이상입니다. 리소스는 가동 중지 시간이 없는 업데이트 작업을 지원한다고 가정할 때 현재 위치 데이터 및 컨트롤 플레인 업데이트로 관리되는 경우가 많습니다. |
시스템 상태 | 이러한 리소스는 적어도 시스템의 수명 동안 존재므로 이 계층은 종종 전역, 지역 복제 상태를 저장해야 합니다. |
도달률 | 리소스는 전역적으로 배포되고 해당 리소스를 호스트하는 지역에 복제되어야 합니다. 이러한 리소스는 대기 시간이 짧고 원하는 일관성으로 지역 또는 기타 리소스와 통신하는 것이 좋습니다. |
종속성 | 리소스를 사용할 수 없는 것이 글로벌 오류의 원인이 될 수 있으므로 리소스는 지역 리소스에 대한 종속성을 피해야 합니다. 예를 들어 단일 자격 증명 모음에 보관된 인증서 또는 비밀은 자격 증명 모음이 있는 지역에 실패가 있는 경우 전역에 영향을 미칠 수 있습니다. |
확장 한도 | 종종 이러한 리소스는 시스템의 싱글톤 인스턴스이며 시스템 전체의 처리량을 처리할 수 있도록 크기를 조정할 수 있어야 합니다. |
가용성/재해 복구 | 지역 및 스탬프 리소스는 글로벌 리소스를 사용할 수 있습니다. 전체 시스템의 상태를 위해 글로벌 리소스를 고가용성 및 재해 복구로 구성하는 것이 중요합니다. |
지역 스탬프 리소스
스탬프에는 비즈니스 트랜잭션 완료에 참여하는 애플리케이션 및 리소스가 포함됩니다. 스탬프는 일반적으로 Azure 지역에 대한 배포에 해당합니다. 지역에는 두 개 이상의 스탬프가 있을 수 있습니다.
특성 | 고려 사항 |
---|---|
수명 | 리소스는 스탬프 외부의 지역 리소스가 계속 지속되는 동안 동적으로 추가하고 제거될 수 있도록 수명이 짧을 것(임시)으로 예상됩니다. 사용자에게 더 많은 복원력, 규모, 근접성을 제공하기 위해서는 임시 특성이 필요합니다. |
시스템 상태 | 스탬프는 임시이며 배포할 때마다 제거되므로 스탬프는 가능한 한 상태 비저장이어야 합니다. |
도달률 | 지역 및 전역 리소스와 통신할 수 있습니다. 그러나 다른 지역 또는 다른 스탬프와의 통신은 피해야 합니다. |
종속성 | 스탬프 리소스는 독립적이어야 합니다. 지역 및 글로벌 종속성이 있어야 하지만 동일하거나 다른 지역의 다른 스탬프에 있는 구성 요소에 의존해서는 안 됩니다. |
확장 한도 | 처리량은 테스트를 통해 설정됩니다. 전체 스탬프의 처리량은 성능이 가장 낮은 리소스로 제한됩니다. 스탬프 처리량은 다른 스탬프로의 장애 조치(failover)로 인한 높은 수준의 수요를 예측해야 합니다. |
가용성/재해 복구 | 스탬프의 일시적인 특성으로 인해 스탬프를 다시 배포하여 재해 복구를 수행합니다. 리소스가 비정상 상태인 경우 스탬프를 전체적으로 제거하고 다시 배포할 수 있습니다. |
지역 리소스
시스템에는 지역에 배포되지만 스탬프 리소스보다 오래 지속되는 리소스가 있을 수 있습니다. 예를 들어 스탬프를 포함하여 지역 수준에서 리소스를 모니터링하는 가시성 리소스입니다.
특성 | 고려 사항 |
---|---|
수명 | 리소스는 지역의 수명을 공유하고 스탬프 리소스를 라이브로 실행합니다. |
시스템 상태 | 지역에 저장된 상태는 지역의 수명을 초과하여 살 수 없습니다. 지역 간에 상태를 공유해야 하는 경우 전역 데이터 저장소를 사용하는 것이 좋습니다. |
도달률 | 리소스를 전역적으로 배포할 필요가 없습니다. 다른 지역과의 직접 통신은 가능한 한 피해야 합니다. |
종속성 | 리소스는 전역 리소스에 종속될 수 있지만 스탬프는 수명이 짧으므로 스탬프 리소스에는 종속될 수 없습니다. |
확장 한도 | 지역 내의 모든 스탬프를 결합하여 지역 리소스의 스케일 제한을 결정합니다. |
중요 업무용 워크로드에 대한 기준 아키텍처
이러한 기준 예제는 중요 업무용 애플리케이션에 권장되는 북쪽 star 아키텍처 역할을 합니다. 기준은 컨테이너화 및 애플리케이션 플랫폼용 컨테이너 오케스트레이터 사용을 강력하게 권장합니다. 기준은 AKS(Azure Kubernetes Service)를 사용합니다.
-
기준 아키텍처
-
네트워크 컨트롤이 있는 기준
이 아키텍처는 기준 아키텍처를 기반으로 합니다. 이 디자인은 인터넷에서 워크로드 리소스로의 무단 공용 액세스를 방지하기 위해 엄격한 네트워크 제어를 제공하도록 확장되었습니다.
-
Azure 랜딩 존의 기준
이 아키텍처는 더 광범위한 organization 내 통합이 필요한 엔터프라이즈 설정에서 워크로드를 배포하는 경우에 적합합니다. 워크로드는 중앙 집중식 공유 서비스를 사용하고, 온-프레미스 연결이 필요하며, 엔터프라이즈 내의 다른 워크로드와 통합됩니다. Corp. 관리 그룹에서 상속되는 Azure 랜딩 존 구독에 배포됩니다.
-
App Services를 사용하는 기준
이 아키텍처는 App Services를 기본 애플리케이션 호스팅 기술로 고려하여 기준 참조를 확장하여 컨테이너 배포에 사용하기 쉬운 환경을 제공합니다.
디자인 영역
제공된 디자인 지침을 사용하여 최적의 솔루션에 도달하기 위해 주요 디자인 결정을 탐색하는 것이 좋습니다. 자세한 내용은 주요 디자인 영역이란?을 참조하세요.
다음 단계
중요 업무용 애플리케이션 시나리오를 디자인하기 위한 모범 사례를 검토합니다.