Azure 랜딩 존의 중요 업무용 기준 아키텍처

이 참조 아키텍처는 중앙 집중식 공유 서비스를 사용하고, 온-프레미스 연결이 필요하고, 엔터프라이즈의 다른 워크로드와 통합되는 중요 업무용 워크로드를 배포하는 방법에 대한 지침을 제공합니다. 이 지침은 조직의 애플리케이션 팀에 속한 워크로드 소유자를 위해 작성되었습니다.

조직에서 회사 관리 그룹을 상속하는 Azure 애플리케이션 랜딩 존에 워크로드를 배포하려고 하는 경우가 있습니다. 워크로드는 중앙의 팀에서 관리하는 Azure 플랫폼 랜딩 존에 미리 프로비저닝된 공유 리소스와 통합되어야 합니다.

이 방법의 최대 안정성은 사용자와 플랫폼 팀이 책임을 공유한다는 것입니다. 중요 업무용 워크로드가 예상대로 작동하려면 중앙에서 관리되는 구성 요소가 매우 안정적이어야 합니다. 워크로드에 영향을 주는 중앙 집중식 서비스의 사용 불가 문제가 플랫폼 수준에서 완화되도록 플랫폼 팀과 신뢰할 수 있는 관계가 형성되어야 합니다. 하지만 팀은 목표를 달성하기 위해 플랫폼 팀과 함께 요구 사항을 추진할 책임이 있습니다.

이 아키텍처는 네트워크 제어 기능이 있는 중요 업무용 기준 아키텍처를 기반으로 합니다. 이 문서를 진행하기 전에 기준 아키텍처를 숙지하는 것이 좋습니다.

주요 디자인 전략

중요 업무용 기준 위에 다음 전략을 적용합니다.

• 중요 경로

  아키텍처의 모든 구성 요소를 똑같이 신뢰할 필요는 없습니다. 중요 경로에는 워크로드가 중단되거나 성능이 저하되는 일이 없도록 계속해서 작동 상태를 유지해야 하는 구성 요소가 포함됩니다. 해당 경로를 간결하게 유지하면 실패 지점이 최소화됩니다.

• 구성 요소의 수명 주기

  중요한 구성 요소의 수명 주기는 0에 가까운 가동 중지 시간이라는 목표 달성에 영향을 주므로 고려해야 합니다. 구성 요소는 필요할 때 만들고 제거할 수 있는 임시 또는 단기 리소스일 수도 있고, 시스템 또는 지역과 수명을 공유하는 비 임시 또는 장기 리소스일 수도 있습니다.

• 외부 종속성

  실패 지점을 유발할 수 있는 구성 요소 및 프로세스에 대한 외부 종속성을 최소화합니다. 이 아키텍처에는 팀 외부의 다양한 팀이 소유한 리소스가 있습니다. 이러한 구성 요소(중요한 구성 요소인 경우)는 이 아키텍처의 범위에 속합니다.

• 구독 토폴로지

  Azure 랜딩 존은 단일 구독 토폴로지를 의미하지 않습니다. 모든 환경에서 워크로드 안정성 요구 사항을 수용하도록 플랫폼 팀과 함께 구독 공간을 미리 계획하세요.

• 중요한 경로에 대한 자율적 가시성

  팀이 데이터 컬렉션(특히 중요 경로)을 신속하게 쿼리하고 수정 작업을 수행할 수 있는 전용 모니터링 리소스를 마련합니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

이 아키텍처의 구성 요소는 네트워크 제어 기능이 있는 중요 업무용 기준 아키텍처와 동일합니다. 간결한 설명만 제공됩니다. 자세한 내용은 연결된 문서를 참조하세요. Azure 서비스에 대한 제품 설명서는 관련 리소스를 참조하세요.

전역 리소스

이러한 리소스는 애플리케이션 랜딩 존 구독에 있습니다. 전역 리소스는 장기 리소스이며 시스템의 수명을 공유합니다. Azure 서비스 및 해당 구성은 기준 전역 리소스와 동일하게 유지됩니다.

지역 네트워킹 리소스

이러한 리소스는 플랫폼 랜딩 존 구독과 애플리케이션 랜딩 존 구독에 있습니다. 기준 아키텍처는 사용자가 소유한 모든 리소스를 배포합니다. 그러나 이 아키텍처에서 연결 구독을 통해 제공되는 네트워킹 리소스는 플랫폼 랜딩 존의 일부로 프로비저닝됩니다.

이 문서의 지역 허브 가상 네트워크 섹션을 참조하세요.

지역 스탬프 리소스

이러한 리소스는 애플리케이션 랜딩 존 구독에 있습니다. 이러한 리소스는 전역 리소스를 제외한 그 어떤 것도 다른 리소스와 공유하지 않습니다.

대부분의 Azure 서비스와 해당 구성은 플랫폼 팀이 미리 프로비저닝하는 네트워킹 리소스를 제외하고 기준 스탬프 아키텍처와 동일하게 유지됩니다.

이 문서의 지역 스포크 가상 네트워크 섹션을 참조하세요.

외부 리소스

워크로드는 온-프레미스 리소스와 상호 작용합니다. 그 중 일부는 워크로드의 중요 경로(예: 온-프레미스 데이터베이스)에 있습니다. 워크로드의 전체 복합 SLA(서비스 수준 계약)를 결정할 때 이러한 리소스 및 이러한 리소스와의 통신을 고려합니다. 모든 통신은 연결 구독을 통해 진행됩니다. 워크로드가 도달할 수 있지만 중요한 것으로 간주되지 않는 기타 외부 리소스가 있습니다.

배포 파이프라인 리소스

유효한 것으로 확인된 스탬프를 일관적인 방식으로 배포하려면 중요 업무용 애플리케이션의 빌드 및 릴리스 파이프라인을 완전히 자동화해야 합니다. 이러한 리소스는 기준 배포 파이프라인과 동일하게 유지됩니다.

지역 모니터링 리소스

이러한 리소스는 애플리케이션 랜딩 존 구독에 있습니다. 전역 리소스 및 지역 리소스에 대한 모니터링 데이터는 독립적으로 저장됩니다. Azure 서비스 및 해당 구성은 기준 모니터링 리소스와 동일하게 유지됩니다.

이 문서의 모니터링 고려 사항 섹션을 참조하세요.

관리 리소스

프라이빗 컴퓨팅 클러스터 및 기타 리소스에 액세스하기 위해 이 아키텍처는 프라이빗 빌드 에이전트 및 점프 박스 가상 머신 인스턴스를 사용합니다. Azure Bastion은 점프 박스에 대한 보안 액세스를 제공합니다. 스탬프 내의 리소스는 기준 관리 리소스와 동일하게 유지됩니다.

네트워킹 고려 사항

이 디자인에서 워크로드는 애플리케이션 랜딩 존에 배포되며 플랫폼 랜딩 존의 페더레이션 리소스에 연결해야 합니다. 그 목적은 온-프레미스 리소스 액세스, 송신 트래픽 제어 등입니다.

네트워크 토폴로지

플랫폼 팀은 전체 조직의 네트워크 토폴로지를 결정합니다. 이 아키텍처에서는 허브 스포크 토폴로지를 사용하는 것으로 가정합니다. 대안으로 Azure Virtual WAN을 사용할 수 있습니다.

지역 허브 가상 네트워크

연결 구독에는 전체 조직에서 공유하는 리소스가 있는 허브 가상 네트워크가 포함되어 있습니다. 이러한 리소스는 플랫폼 팀에서 소유하고 유지 관리합니다.

중요 업무용의 관점에서 이 네트워크는 임시 리소스가 아니며, 이러한 리소스는 중요 경로에 있습니다.

Azure 리소스	목적
Azure ExpressRoute	온-프레미스에서 Azure 인프라로의 프라이빗 연결을 제공합니다.
Azure Firewall	송신 트래픽을 검사하고 제한하는 NVA 역할을 합니다.
Azure DNS	프레미스 간 이름 확인을 제공합니다.
VPN Gateway	공용 인터넷을 통해 원격 조직 분기를 Azure 인프라에 연결합니다. 복원력을 추가하기 위한 백업 연결 대안으로도 작동합니다.

리소스는 각 지역에 프로비저닝되고 스포크 가상 네트워크에 피어링됩니다(다음에 설명). NVA, 방화벽 규칙, 회람 규칙, VPN Gateway로 ExpressRoute 장애 조치(failover), DNS 인프라 등의 업데이트를 이해하고 동의해야 합니다.

지역 스포크 가상 네트워크

애플리케이션 랜딩 존에는 Azure Virtual Network가 지역별로 2개 이상 미리 프로비저닝되며, 이러한 네트워크는 지역 스탬프에서 참조합니다. 이러한 네트워크는 장기 네트워크입니다. 둘 중 하나는 프로덕션 트래픽을 처리하고, 다른 하나는 vNext 배포를 대상으로 합니다. 이 방식을 사용하면 안정적이고 안전하게 배포할 수 있습니다.

운영 가상 네트워크

운영 트래픽은 별도의 가상 네트워크에 격리됩니다. 이 가상 네트워크는 장기 네트워크이며 워크로드 소유자의 소유입니다. 이 아키텍처는 네트워크 제어 기능이 있는 기준 아키텍처와 동일한 디자인을 유지합니다.

운영 네트워크와 스포크 네트워크 간에 피어링이 없습니다. 모든 통신은 Private Link를 통해 이루어집니다.

분산된 책임

아키텍처의 각 디자인 요소를 어느 팀이 담당하는지 명확하게 이해합니다. 다음은 주요 영역입니다.

IP 주소 계획

워크로드를 실행하는 데 필요한 크기를 추정한 후에는 플랫폼 팀이 네트워크를 적절하게 프로비저닝할 수 있도록 플랫폼 팀과 협력합니다.

플랫폼 팀

• 피어링에 참여하는 가상 네트워크의 고유 주소를 제공합니다. 예를 들어 온-프레미스 및 워크로드 네트워크의 주소가 겹치면 운영이 중단될 수 있습니다.

• 런타임 및 배포 리소스를 충분히 포함할 수 있는 IP 주소 공간을 할당하고, 장애 조치(failover)를 처리하고, 확장성을 지원합니다.

미리 프로비저닝된 가상 네트워크와 피어링이 워크로드의 예상 확장 속도를 감당할 수 있어야 합니다. 플랫폼 팀과 함께 이러한 확장 속도를 정기적으로 평가해야 합니다. 자세한 내용은 Azure 연결을 참조하세요.

지역 스포크 네트워크 서브넷

워크로드 소유자는 지역 가상 네트워크에서 서브넷을 할당하는 역할을 합니다. 서브넷과 그 안에 있는 리소스는 임시로 사용됩니다. 주소 공간은 확장 속도를 감당할 수 있을 만큼 충분히 커야 합니다.

• 프라이빗 엔드포인트 서브넷 트래픽이 가상 네트워크에 도달하면 네트워크 제어 기능이 있는 기준 아키텍처와 마찬가지로 네트워크 내 PaaS 서비스와의 통신이 프라이빗 엔드포인트를 사용하여 제한됩니다. 이러한 엔드포인트는 전용 서브넷에 배치됩니다. 프라이빗 엔드포인트에 대한 개인 IP 주소는 해당 서브넷에서 할당됩니다.

• 클러스터 서브넷 워크로드의 확장성 요구 사항은 서브넷에 할당해야 하는 주소 공간의 양에 영향을 줍니다. AKS 노드 및 Pod가 스케일 아웃되면 이 서브넷의 IP 주소가 할당됩니다.

네트워크 구분

권한 없는 액세스로 인해 워크로드의 안정성이 손상되지 않도록 적절한 세그먼트를 유지해야 합니다.

이 아키텍처는 NSG(네트워크 보안 그룹)를 사용하여 서브넷과 연결 구독의 트래픽을 제한합니다. NSG는 지원되는 서비스에 ServiceTags를 사용합니다.

플랫폼 팀

• Azure Network Manager 정책을 통해 NSG를 사용하도록 강제합니다.

• 워크로드 디자인을 인지합니다. 스탬프 사이에는 직접 트래픽이 없습니다. 지역 간 흐름도 없습니다. 이러한 경로가 필요한 경우 트래픽이 연결 구독을 통해 이동해야 합니다.

• 다른 워크로드에서 시작되는 불필요한 허브 트래픽이 중요 업무용 워크로드로 전달되지 않게 합니다.

지역 스탬프의 송신 트래픽

각 지역 스포크 네트워크에서 나가는 모든 트래픽은 지역 허브 네트워크의 중앙 Azure Firewall을 통해 라우팅됩니다. 중앙 Azure Firewall은 트래픽을 검사한 후 허용하거나 거부하는 다음 홉 역할을 합니다.

플랫폼 팀

• 해당 사용자 지정 경로에 대한 UDR을 만듭니다.

• 애플리케이션 팀이 새 경로 테이블이 없는 서브넷을 만들지 못하도록 차단하는 Azure 정책을 할당합니다.

• 워크로드의 요구 사항에 따라 경로를 확장할 수 있도록 애플리케이션 팀에 적절한 RBAC(역할 기반 액세스 제어) 권한을 부여합니다.

다중 지역 중복성

중요 업무용 워크로드는 지역 가동 중단을 견딜 수 있도록 여러 지역에 배포해야 합니다. 플랫폼 팀과 협력하여 인프라가 신뢰할 수 있는지 확인합니다.

플랫폼 팀

• 지역별로 중앙 네트워킹 리소스를 배포합니다. 중요 업무용 디자인 방법론을 사용하려면 지역 격리가 필요합니다.

• 한 지역의 성능이 저하된 플랫폼 리소스가 다른 지역의 워크로드에 영향을 주지 않도록 애플리케이션 팀과 협력하여 숨은 지역 종속성을 파악합니다.

DNS 확인

연결 구독은 프라이빗 DNS 영역을 제공합니다. 그러나 중앙 집중식 접근 방식에서는 워크로드 소유자의 사용 사례와 관련이 있을 수 있는 DNS 요구 사항을 고려하지 않을 수도 있습니다. 워크로드 소유자의 고유한 DNS 영역을 프로비저닝하고 지역 스탬프에 연결합니다. 애플리케이션 팀이 DNS를 소유하지 않으면 Azure Cosmos DB와 같은 전역 리소스의 프라이빗 링크 관리가 어려워집니다.

플랫폼 팀

• Azure 프라이빗 DNS 영역을 애플리케이션 팀에 위임하여 애플리케이션 팀의 사용 사례를 다룹니다.

• 지역 허브 네트워크의 경우 애플리케이션 팀에서 관리하는 프라이빗 DNS 영역을 지원하도록 DNS 서버 값을 기본값(Azure에서 제공)으로 설정합니다.

환경 디자인 고려 사항

프로덕션, 사전 프로덕션 및 개발을 위해 워크로드를 별도의 환경에 배치하는 것이 일반적입니다. 다음은 몇 가지 주요 고려 사항입니다.

격리는 어떻게 유지 관리하나요?

프로덕션 환경은 반드시 다른 환경과 격리되어야 합니다. 낮은 환경 역시 격리 수준을 유지해야 합니다. 환경 간에 애플리케이션 소유의 리소스를 공유하지 마세요.

애플리케이션 팀이 소유한 전역, 지역 및 스탬프 리소스에는 하나의 프로덕션 환경이 필요합니다. 프로덕션을 최대한 많이 시뮬레이션하는 환경에서 애플리케이션을 테스트하려면 스테이징 및 통합과 같은 사전 프로덕션 환경이 필요합니다. 개발 환경은 스케일 다운된 프로덕션 버전이어야 합니다.

예상 수명 주기는 무엇인가요?

유효성 검사 테스트가 완료된 후 사전 프로덕션 환경을 제거할 수 있습니다. 개발 환경은 기능의 수명을 공유하고 개발이 완료되면 제거되는 것이 좋습니다. 이러한 작업은 CI/CD(연속 통합/지속적인 배포) 자동화를 통해 수행됩니다.

단점은 무엇인가요?

환경 격리, 관리 복잡성, 비용 최적화 간의 적절한 균형점을 찾아야 합니다.

워크로드 인프라에 대한 구독 토폴로지

구독은 플랫폼 팀이 제공합니다. 환경 수에 따라 하나의 워크로드에 대해 여러 구독을 요청하게 됩니다. 환경 유형에 따라 어떤 환경에는 전용 구독이 필요하고 어떤 환경은 하나의 구독으로 통합할 수 있습니다.

어떤 경우든, 플랫폼 팀과 협력하여 워크로드의 전체적인 안정성 목표를 충족하는 토폴로지를 설계합니다. 플랫폼 제공 리소스는 프로덕션 환경을 반영하기 때문에 동일한 구독의 환경 간에 플랫폼 제공 리소스를 공유하면 이점이 있습니다.

프로덕션 구독

워크로드 소유자에게 제공된 구독에 리소스 제한이 있을 수 있습니다. 모든 리소스를 한 구독에 공동 배치하는 경우 이러한 제한에 도달할 수도 있습니다. 배율 단위 및 예상 규모에 따라 보다 분산된 모델을 고려하세요. 예제:

• Azure DevOps 빌드 에이전트와 전역 리소스를 모두 포함하는 구독 하나

• 지역마다 구독 하나. 이 구독에는 지역별 리소스, 스탬프 리소스 및 지역 스탬프에 대한 점프 박스가 포함됩니다.

다음은 이 아키텍처에서 사용되는 구독 토폴로지의 예입니다.

사전 프로덕션 구독

하나 이상의 구독이 필요합니다. 구독에서 여러 독립 환경을 실행할 수 있지만, 전용 구독에서 여러 환경을 사용하는 것이 좋습니다. 위에서 설명한 프로덕션 구독과 같은 리소스 제한이 이 구독에 적용될 수 있습니다.

개발 구독

하나 이상의 구독이 필요합니다. 모든 독립 환경을 실행하는 경우 이 구독에 리소스 제한이 적용될 수 있습니다. 따라서 여러 구독을 요청할 수 있습니다. 전용 구독에서 개별 환경을 사용하는 것이 좋습니다.

프로덕션 토폴로지를 최대한 일치시키려고 노력해야 합니다.

배포 고려 사항

실패한 배포 또는 잘못된 릴리스는 애플리케이션이 중단되는 대표적인 원인입니다. 애플리케이션 수명 주기에서 애플리케이션(및 새 기능)을 철저히 테스트하세요. 랜딩 존에 워크로드를 배포할 때, 플랫폼 제공 리소스 및 거버넌스와 디자인을 통합해야 합니다.

잘 설계된 중요 업무용 워크로드: 배포 및 테스트를 참조하세요.

배포 인프라

빌드 에이전트 및 빌드 에이전트의 네트워크와 같은 배포 인프라의 안정성은 워크로드의 런타임 리소스만큼 중요한 경우가 많습니다.

이 아키텍처는 프라이빗 빌드 에이전트를 사용하여 애플리케이션의 가용성에 영향을 미칠 수 있는 무단 액세스를 방지합니다.

배포 리소스 간의 격리를 유지하는 것이 좋습니다. 배포 인프라는 해당 환경의 워크로드 구독에 바인딩되어야 합니다. 사전 프로덕션 구독에서 여러 환경을 사용하는 경우 액세스를 해당 개별 환경으로 제한하여 추가로 분리하세요. 지역별 배포 리소스는 배포 인프라의 안정성을 높이는 것으로 간주할 수도 있습니다.

가동 중지 시간 없는 배포

애플리케이션을 업데이트할 때 중단이 발생할 수 있습니다. 일관적인 배포를 적용하면 안정성이 향상됩니다. 다음과 같은 방식을 사용하는 것이 좋습니다.

• 배포 파이프라인이 완전히 자동화되었습니다.
• 클린 스탬프의 사전 프로덕션 환경에서 업데이트를 배포합니다.

자세한 내용은 중요 업무용 배포 및 테스트 지침을 참조하세요.

기준 아키텍처에서 이러한 전략은 프로비전 해제 후에 각 업데이트로 스탬프를 제거하여 구현됩니다. 이 디자인에서는 플랫폼 팀이 일부 리소스를 소유하기 때문에 완전한 프로비전 해제가 불가능합니다. 따라서 배포 모델이 변경되었습니다.

배포 모델

기준 아키텍처는 파란색-녹색 모델을 사용하여 애플리케이션 업데이트를 배포합니다. 변경 내용이 적용된 새 스탬프는 기존 스탬프와 함께 배포됩니다. 트래픽이 새 스탬프로 이동되면 기존 스탬프가 제거됩니다.

이 경우 주어진 피어링된 가상 네트워크는 삭제되지 않습니다. 스탬프는 가상 네트워크를 만들거나 지역 허브에 피어링할 수 없습니다. 각 배포에서 해당 리소스를 다시 사용해야 합니다.

카나리아 모델은 롤백 옵션을 사용하여 안전한 배포를 달성할 수 있습니다. 먼저 코드 변경 내용과 함께 새 스탬프가 배포됩니다. 배포 파이프라인은 미리 프로비저닝된 가상 네트워크를 참조하여 서브넷을 할당하고, 리소스를 배포하고, 프라이빗 엔드포인트를 추가합니다. 그런 다음, 미리 프로비저닝된 이 가상 네트워크의 서브넷으로 트래픽을 이동합니다.

기존 스탬프가 더 이상 필요 없으면 플랫폼 소유의 리소스를 제외한 모든 스탬프 리소스가 파이프라인에서 삭제됩니다. 가상 네트워크, 진단 설정, 피어링, IP 주소 공간, DNS 구성 및 RBAC(역할 기반 액세스 제어)는 보존됩니다. 이 시점에서 스탬프는 깨끗한 상태이며, 다음 신규 배포를 시작할 수 있습니다.

DINE(deploy-if-not-exists) Azure 정책

Azure 애플리케이션 랜딩 존에서 DINE(deploy-if-not-exists) Azure 정책을 사용할 수도 있습니다. 이러한 검사는 배포된 리소스가 애플리케이션 팀 소유인 경우에도 애플리케이션 랜딩 존의 회사 표준을 충족하도록 보장합니다. 배포와 최종 리소스 구성이 일치하지 않을 수 있습니다.

리소스에 적용되는 모든 DINE 정책의 영향을 이해해야 합니다. 리소스 구성이 변경되면 워크로드의 개발 주기 초기에 정책 의도를 선언적 배포에 통합해야 합니다. 그렇지 않으면 원하는 상태와 배포된 상태 간의 델타로 이어지는 드리프트가 있을 수 있습니다.

배포 구독 액세스 관리

구독 경계를 보안 경계로 처리하여 폭발 반경을 제한하세요. 위협은 워크로드의 안정성에 영향을 미칠 수 있습니다.

플랫폼 팀

• 애플리케이션 랜딩 존 구독으로 범위가 지정된 권한이 있는 작업에 대한 권한을 애플리케이션 팀에게 부여합니다.

단일 구독 내에서 여러 배포를 실행하는 경우 정책 위반이 두 배포 모두에 영향을 줍니다. 전용 구독에서 배포를 실행하는 것이 좋습니다. 논리적 분리를 유지하도록 환경마다 서비스 주체를 만드세요.

서비스 주체는 워크로드 리소스에 대한 자율성을 제공해야 합니다. 또한 구독 내의 플랫폼 리소스를 과도하게 조작하지 못하게 차단하는 제한이 있어야 합니다.

모니터링 고려 사항

Azure 랜딩 존 플랫폼은 관리 구독의 일부로 공유 가시성 리소스를 제공합니다. 중앙의 운영 팀은 애플리케이션 팀에게 페더레이션 모델을 사용할 것을 권장합니다. 그러나 중요 업무용 워크로드의 경우 중앙의 단일 가시성 저장소는 단일 실패 지점이 될 가능성이 있으므로 사용하지 않는 것이 좋습니다. 중요 업무용 워크로드는 중앙의 운영 팀에 적용하거나 실행할 수 없는 원격 분석 데이터도 생성합니다.

따라서 자율적인 접근 방식을 모니터링에 사용하는 것이 좋습니다. 워크로드 운영자는 궁극적인 모니터링 책임이 있으며 전체 상태를 나타내는 모든 데이터에 액세스할 수 있어야 합니다.

기준 아키텍처는 이러한 접근 방식을 따르며 이 참조 아키텍처에서 계속됩니다. Azure Log Analytics 및 Azure Application Insights는 해당 범위의 리소스를 모니터링하도록 지역 및 전역에 배포됩니다. 로그 집계, 대시보드 만들기 및 경고는 워크로드 팀의 범위에 속합니다. 다양한 싱크에 메트릭 및 로그를 전송하는 Azure Diagnostics 기능을 활용하여 로그 및 메트릭 수집에 대한 플랫폼 요구 사항을 지원합니다.

상태 모델

중요 업무용 디자인 방법론을 사용하려면 시스템 상태 모델이 필요합니다. 전체 상태 점수를 정의할 때, 애플리케이션이 사용하는 범위 내 플랫폼 랜딩 존 흐름을 포함시킵니다. 로그, 상태 및 경고 쿼리를 빌드하여 작업 영역 간 모니터링을 수행합니다.

플랫폼 팀

• 중요 업무용 애플리케이션의 중요 경로에서 사용되는 관련 플랫폼 리소스에 대한 RBAC(역할 기반 액세스 제어) 쿼리 및 읽기 로그 싱크를 부여합니다.

• 애플리케이션 팀에 작업을 수행할 수 있는 충분한 권한을 부여하여 중요 업무용 워크로드의 안정성이라는 조직의 목표를 지원합니다.

이 아키텍처에서는 연결 구독에 프로비저닝된 리소스의 로그 및 메트릭이 상태 모델에 포함됩니다. 데이터베이스와 같은 온-프레미스 리소스에 도달하도록 이 디자인을 확장하는 경우 Azure 및 온-프레미스의 네트워크 가상 어플라이언스와 같은 보안 경계를 비롯하여 해당 리소스에 대한 네트워크 연결이 상태 모델에 포함되어야 합니다. 이 정보는 근본 원인을 신속하게 확인하고 안정성 문제를 수정하는 데 중요합니다. 예를 들어 데이터베이스로 라우팅하려고 할 때 오류가 발생했거나 데이터베이스에 문제가 있었나요?

잘 설계된 중요 업무용 워크로드: 상태 모델링을 참조하세요.

플랫폼 제공 정책 및 규칙과 통합

애플리케이션 랜딩 존 구독은 관리 그룹에서 Azure 정책, Azure Network Manager 규칙 및 기타 컨트롤을 상속합니다. 플랫폼 팀은 이러한 가드레일을 제공합니다.

배포의 경우 다음과 같은 이유로 플랫폼 제공 정책에만 의존하면 안 됩니다.

• 플랫폼 제공 정책은 개별 워크로드의 요구 사항을 충족하도록 설계되지 않았습니다.
• 정책 및 규칙은 팀 외부에서 업데이트되거나 제거되어 안정성에 영향을 미칠 수 있습니다.

배포 내에서 Azure 정책을 만들고 할당하는 것이 좋습니다. 이러한 작업이 중복될 수도 있지만 시스템의 안정성에 미치는 잠재적 영향을 고려할 때 허용됩니다. 플랫폼 정책이 변경되어도 워크로드 정책은 여전히 로컬로 적용됩니다.

플랫폼 팀

• 정책이 발전함에 따라 애플리케이션 팀을 정책의 변경 관리 프로세스에 투입합니다.
• 애플리케이션 팀이 사용하는 정책을 알고 있어야 합니다. 이러한 정책을 관리 그룹에 추가해야 하는지 평가합니다.

이 아키텍처 배포

이 아키텍처의 네트워킹 측면은 중요 업무용 연결 구현에서 구현됩니다.

다음 단계

Azure Well-Architected Framework의 네트워킹 및 연결 디자인 영역을 검토합니다.

관련 참고 자료

이러한 서비스는 기준 아키텍처에 사용되는 Azure 서비스 외에도 이 아키텍처에 중요합니다.

• Azure 관리 그룹
• Azure Policy
• Azure Network Manager
• Azure Monitor
• Virtual Network
• 경로 테이블