Azure에서 중요 업무용 워크로드를 위한 디자인 방법론
모든 클라우드 플랫폼에서 중요 업무용 애플리케이션을 빌드하려면 상당한 기술 전문 지식과 엔지니어링 투자가 필요합니다. 특히 다음과 관련된 복잡성이 매우 많기 때문에
- 클라우드 플랫폼 이해
- 올바른 서비스 및 컴퍼지션 선택
- 올바른 서비스 구성 적용
- 활용된 서비스 운영 및
- 최신 모범 사례 및 서비스 로드맵에 지속적으로 부합합니다.
이 디자인 방법론은 이러한 복잡성을 탐색하고 최적의 대상 아키텍처를 생성하는 데 필요한 디자인 결정을 알리는 데 도움이 되는 디자인 경로를 쉽게 따르기 위해 노력합니다.
1 - 비즈니스 요구 사항을 위한 디자인
모든 중요 업무용 워크로드에 동일한 요구 사항이 있는 것은 아닙니다. 이 디자인 방법론에서 제공하는 검토 고려 사항 및 디자인 권장 사항은 다양한 애플리케이션 시나리오에 대해 서로 다른 디자인 결정과 장단을 가져올 것으로 예상합니다.
안정성 계층 선택
안정성은 상대적 개념이며 모든 워크로드가 적절하게 신뢰할 수 있도록 하려면 이를 둘러싼 비즈니스 요구 사항을 반영해야 합니다. 예를 들어 99.999% 가용성 SLO(서비스 수준 목표)가 있는 중요 업무용 워크로드는 SLO가 99.9%인 다른 덜 중요한 워크로드보다 훨씬 높은 수준의 안정성이 필요합니다.
이 디자인 방법론은 가용성 SLO로 표현된 안정성 계층의 개념을 적용하여 필요한 안정성 특성을 알려줍니다. 아래 표에서는 일반적인 안정성 계층과 연결된 허용된 오류 예산을 캡처합니다.
| 안정성 계층(가용성 SLO) | 허용된 가동 중지 시간(주) | 허용되는 가동 중지 시간(월) | 허용되는 가동 중지 시간(연도) |
|---|---|---|---|
| 99.9% | 10분, 4초 | 43분 49초 | 8시간 45분 56초 |
| 99.95% | 5분 2초 | 21분 54초 | 4시간 22분 58초 |
| 99.99% | 1분 | 4분 22초 | 52분 35초 |
| 99.999% | 6초 | 26초 | 5분 15초 |
| 99.9999% | <1초 | 2초 | 31초 |
중요
가용성 SLO는 이 디자인 방법론에서 단순한 작동 시간 이상으로 간주하지만, 알려진 정상 애플리케이션 상태에 비해 일관된 수준의 애플리케이션 서비스로 간주됩니다.
초기 연습에서 독자는 허용되는 가동 중지 시간을 결정하여 대상 안정성 계층을 선택하는 것이 좋습니다. 특정 안정성 계층의 추구는 궁극적으로 디자인 경로와 포괄된 디자인 결정에 상당한 영향을 줍니다. 이로 인해 다른 대상 아키텍처가 생성됩니다.
이 이미지는 다양한 안정성 계층 및 기본 비즈니스 요구 사항이 특히 지역 배포 및 활용된 글로벌 기술 수와 관련하여 개념 참조 구현을 위한 대상 아키텍처에 미치는 영향을 보여 줍니다.
RTO(복구 시간 목표) 및 RPO(복구 지점 목표)는 필요한 안정성을 결정할 때 더욱 중요한 측면입니다. instance 경우 1분 미만의 애플리케이션 RTO를 달성하려는 경우 백업 기반 복구 전략 또는 활성-수동 배포 전략이 충분하지 않을 수 있습니다.
2 - 디자인 원칙을 사용하여 디자인 영역 평가
이 방법론의 핵심에는 다음으로 구성된 중요한 디자인 경로가 있습니다.
각 디자인 영역 내에서 결정된 결정의 영향은 다른 디자인 영역과 디자인 결정에서 반향을 일으킬 것입니다. 제공된 고려 사항 및 권장 사항을 검토하여 관련 디자인 영역 내에서 장단점이 발생할 수 있는 포괄적인 결정의 결과를 더 잘 이해합니다.
예를 들어 대상 아키텍처를 정의하려면 주요 구성 요소에서 애플리케이션 상태를 가장 잘 모니터링하는 방법을 결정하는 것이 중요합니다. 의사 결정을 내리는 데 도움이 되는 개요 권장 사항을 사용하여 상태 모델링 디자인 영역을 검토하는 것이 좋습니다.
3 - 첫 번째 중요 업무용 애플리케이션 배포
이 방법론을 기반으로 디자인 결정을 설명하는 이러한 참조 아키텍처를 참조하세요.
팁
아키텍처는 디자인 권장 사항을 보여 주는 중요 업무용 온라인 구현을 통해 뒷받침됩니다.
프로덕션 등급 아티팩트 모든 기술 아티팩트가 프로덕션 환경에서 사용할 준비가 되었으며 모든 엔드 투 엔드 운영 측면이 고려됩니다.
실제 경험에 뿌리를 두고 있습니다. 모든 기술 결정은 Azure 고객의 경험과 이러한 솔루션 배포에서 배운 교훈에 따라 결정됩니다.
Azure 로드맵 맞춤 중요 업무용 참조 아키텍처에는 Azure 제품 로드맵과 일치하는 자체 로드맵이 있습니다.
4 - Azure 랜딩 존에서 워크로드 통합
Azure 랜딩 존 구독은 중앙 집중식 거버넌스가 필요한 엔터프라이즈 배포를 위한 공유 인프라를 제공합니다.
중요 업무용 애플리케이션에 필요한 연결 사용 사례를 평가하는 것이 중요합니다. Azure 랜딩 존은 서로 다른 관리 그룹 범위로 구분된 두 개의 기본 아키타입(온라인 또는 Corp.)을 지원합니다.
온라인 구독
중요 업무용 워크로드는 Azure 랜딩 존 아키텍처의 나머지 부분에 대한 직접적인 회사 네트워크 연결 없이 독립적인 솔루션으로 작동합니다. 애플리케이션은 정책 기반 거버넌스 를 통해 추가로 보호되며 정책을 통해 중앙 집중식 플랫폼 로깅과 자동으로 통합됩니다.
기준 아키텍처 및 중요 업무용 온라인 구현은 온라인 접근 방식과 일치합니다.
Corp. subscription
Corp. 구독에 배포된 경우 중요 업무용 워크로드는 연결 리소스를 제공하기 위해 Azure 랜딩 존에 따라 달라집니다. 이 방법을 사용하면 다른 애플리케이션 및 공유 서비스와 통합할 수 있습니다. 공유 서비스 플랫폼의 일부로 미리 존재하는 일부 기본 리소스를 중심으로 설계해야 합니다. 예를 들어 지역 배포 스탬프는 Corp. 구독에 존재하기 때문에 더 이상 임시 Virtual Network 또는 Azure 프라이빗 DNS 영역을 포함해서는 안 됩니다.
이 사용 사례를 시작하려면 Azure 랜딩 존 참조 아키텍처의 기준 아키텍처를 사용하는 것이 좋습니다.
팁
이전 아키텍처는 중요 업무용 연결된 구현을 통해 뒷받침됩니다.
5 - 샌드박스 애플리케이션 환경 배포
디자인 작업과 동시에 Mission-Critical 참조 구현을 사용하여 샌드박스 애플리케이션 환경을 설정하는 것이 좋습니다.
이렇게 하면 대상 아키텍처를 복제하여 디자인 결정의 유효성을 검사할 수 있는 실습 기회를 제공하므로 디자인 불확실성을 신속하게 평가할 수 있습니다. 대표적인 요구 사항 적용 범위로 올바르게 적용된 경우 진행을 방해할 수 있는 가장 문제가 있는 문제를 발견하고 이후에 해결할 수 있습니다.
6 - Azure 로드맵을 사용하여 지속적으로 발전
이 디자인 방법론을 사용하여 설정된 애플리케이션 아키텍처는 최적화된 지속 가능성을 지원하기 위해 Azure 플랫폼 로드맵에 따라 계속 진화 해야 합니다.
다음 단계
중요 업무용 애플리케이션 시나리오에 대한 디자인 원칙을 검토합니다.