이 아키텍처는 Azure에서 중요 업무용 워크로드를 설계하기 위한 지침을 제공합니다. 클라우드 네이티브 기능을 사용하여 안정성과 운영 효율성을 최대화합니다. 잘 설계된 중요 업무용 워크로드에 대한 설계 방법론을 인터넷 연결 애플리케이션에 적용합니다. 여기서 워크로드는 퍼블릭 엔드포인트를 통해 워크로드에 액세스되고 타사 리소스에 대한 개인 네트워크 연결은 필요하지 않습니다.
중요
이 지침은 Azure에서 중요 업무용 애플리케이션 개발을 보여 주는 프로덕션 등급 예제 구현이 뒷받침합니다. 이 구현은 프로덕션을 향한 첫 번째 단계에서 추가 솔루션 개발을 위한 기초로 사용할 수 있습니다.
안정성 계층
안정성은 상대적인 개념이며 워크로드를 적절하게 안정적으로 유지하려면 SLO(서비스 수준 목표)와 SLA(서비스 수준 약정)를 포함하여 워크로드를 둘러싼 비즈니스 요구 사항을 반영하여 애플리케이션을 사용할 수 있는 시간의 비율을 캡처해야 합니다.
이 아키텍처는 99.99%의 SLO를 목표로 하며, 이는 연간 52분 35초의 가동 중지 시간에 해당합니다. 따라서 포함된 모든 설계 결정은 이 목표 SLO를 달성하기 위한 것입니다.
팁
현실적인 SLO를 정의하려면 아키텍처 범위 내에서 모든 Azure 구성 요소 및 기타 요인의 안정성 목표를 이해하는 것이 중요합니다. 자세한 내용은 안정성 대상을 정의하기 위한 권장 사항을 참조 하세요. 이러한 개별 숫자를 집계하여 워크로드 대상에 맞춰야 하는 복합 SLO를 결정해야 합니다.
주요 설계 전략
실패로부터의 복구 기능, 지역 가용성, 배포 효율성, 보안과 같은 많은 요소가 애플리케이션의 안정성에 영향을 미칠 수 있습니다. 이 아키텍처는 이러한 요소를 해결하고 대상 안정성 계층이 달성되도록 하기 위한 일련의 포괄적인 설계 전략을 적용합니다.
계층의 중복성
활성-활성 모델의 여러 지역에 배포합니다. 애플리케이션은 활성 사용자 트래픽을 처리하는 둘 이상의 Azure 지역에 배포됩니다.
고려된 모든 서비스에 가용성 영역을 활용하여 단일 Azure 지역 내에서 가용성을 최대화하여 지역 내의 물리적으로 분리된 데이터 센터에 구성 요소를 분산합니다.
전역 배포를 지원하는 리소스를 선택합니다.
잘 설계된 중요 업무용 워크로드: 전역 배포를 참조하세요.
배포 스탬프
리소스의 논리적 집합을 독립적으로 프로비저닝하여 수요 변화에 부응할 수 있는 배율 단위로 지역 스탬프를 배포합니다. 또한 각 스탬프는 독립적으로 스케일 인 및 스케일 아웃할 수 있는 프런트 엔드 API 및 백그라운드 프로세서와 같은 여러 중첩된 배율 단위를 적용합니다.
잘 설계된 중요 업무용 워크로드: 배율 단위 아키텍처를 참조하세요.
안정적이고 반복 가능한 배포
Terraform과 같은 기술을 사용하여 IaC(Infrastructure as Code) 원칙을 적용하고 인프라 구성 요소에 대한 버전 제어와 표준화된 운영 접근 방식을 제공합니다.
가동 중지 시간이 없는 블루/그린 배포 파이프라인을 구현합니다. 지속적인 유효성 검사가 적용된 블루/그린 배포를 사용하여 스탬프를 단일 운영 단위로 배포하려면 빌드와 릴리스 파이프라인을 완전히 자동화해야 합니다.
프로덕션과 사전 프로덕션 환경에서 동일한 배포 파이프라인 코드를 사용하여 고려된 모든 환경에 환경 일관성을 적용합니다. 이렇게 하면 환경 전반의 배포와 프로세스 변형과 관련된 위험이 제거됩니다.
동기화된 부하와 카오스 테스팅을 포함하여 DevOps 프로세스의 일부로 자동화된 테스트를 통합하여 애플리케이션 코드와 기본 인프라의 상태의 유효성을 완전히 검사하여 지속적인 유효성 검사를 수행합니다.
잘 설계된 중요 업무용 워크로드: 배포 및 테스트를 참조하세요.
작업 인사이트
가시성 데이터에 대한 페더레이션된 작업 영역이 있습니다. 전역 리소스와 지역 리소스에 대한 모니터링 데이터는 독립적으로 저장됩니다. 단일 실패 지점을 방지하기 위해 중앙 집중식 가시성 저장소는 권장되지 않습니다. 작업 영역 간 쿼리는 통합 데이터 싱크 및 운영을 위한 단일 창을 구현하는 데 사용됩니다.
컨텍스트화를 위해 애플리케이션 상태를 신호등 모델에 매핑하는 계층화된 상태 모델을 구성합니다. 상태 점수는 각 개별 구성 요소에 대해 계산된 다음 사용자 흐름 수준에서 집계되고 성능과 같은 주요 비기능 요구 사항(예: 애플리케이션 상태를 정량화하는 계수)과 결합됩니다.
잘 설계된 중요 업무용 워크로드: 상태 모델링을 참조하세요.
아키텍처
*이 아키텍처의 Visio 파일을 다운로드하세요.
이 아키텍처의 구성 요소는 이러한 방식으로 광범위하게 분류할 수 있습니다. Azure 서비스에 대한 제품 설명서는 관련 리소스를 참조하세요.
전역 리소스
전역 리소스는 수명이 길고 시스템의 수명을 공유합니다. 다중 지역 배포 모델의 컨텍스트 내에서 전역적으로 사용할 수 있는 기능이 있습니다.
다음은 구성 요소에 대한 개략적인 고려 사항입니다. 결정에 대한 자세한 내용은 전역 리소스를 참조하세요.
글로벌 부하 분산 장치
전역 부하 분산 장치는 지역의 백 엔드 서비스의 가용성을 기반으로 일정 수준의 보장을 통해 트래픽을 지역 배포로 안정적으로 라우팅하는 데 중요합니다. 또한 이 구성 요소에는 수신 트래픽을 검사하는 기능(예: 웹 애플리케이션 방화벽을 통해)이 있어야 합니다.
Azure Front Door는 수신되는 모든 클라이언트 HTTP(S) 트래픽의 전역 진입점으로 사용되며, WAF(Web Application Firewall) 기능은 보안 계층 7 수신 트래픽에 적용됩니다. TCP Anycast를 사용하여 Microsoft 백본 네트워크를 사용하여 라우팅을 최적화하고 지역 상태가 저하될 경우 투명한 장애 조치(failover)를 허용합니다. 라우팅은 주요 지역 리소스의 복합 상태를 확인하는 사용자 지정 상태 프로브에 따라 달라집니다. 또한 Azure Front Door는 웹 사이트 구성 요소에 대한 정적 자산을 캐시하는 기본 제공 CDN(콘텐츠 배달 네트워크)을 제공합니다.
또 다른 옵션은 DNS 기반 계층 4 부하 분산 장치인 Traffic Manager입니다. 그러나 DNS 전파가 발생해야 하므로 실패가 모든 클라이언트에 투명하지는 않습니다.
잘 설계된 중요 업무용 워크로드: 전역 트래픽 라우팅을 참조하세요.
데이터베이스
워크로드와 관련된 모든 상태는 외부 데이터베이스인 Azure Cosmos DB for NoSQL에 저장됩니다. 이 옵션은 클라이언트와 서버 쪽 모두에서 성능과 안정성 튜닝에 필요한 기능 세트가 있기 때문에 선택되었습니다. 계정을 다중 마스터 쓰기 가능으로 설정하는 것이 좋습니다.
참고
다중 지역 쓰기 구성은 안정성에 대한 최고의 기준을 나타내지만 비용 측면에서 상당한 장단점이 있으므로 적절하게 고려되어야 합니다.
계정은 각 지역 스탬프에 복제되며 영역 중복성도 사용하도록 설정됩니다. 또한 컨테이너 수준에서 자동 스케일링을 사용하도록 설정되어 컨테이너가 필요에 따라 프로비저닝된 처리량을 자동으로 스케일링합니다.
자세한 내용은 중요 업무용 워크로드를 위한 데이터 플랫폼을 참조하세요.
컨테이너 레지스트리
Azure Container Registry는 모든 컨테이너 이미지를 저장하는 데 사용됩니다. 리소스가 다중 마스터 지역 레지스트리로 여러 지역에 서비스를 제공하는 단일 레지스트리로 기능할 수 있도록 하는 지역 복제 기능이 있습니다.
보안 조치로 필요한 엔터티에 대한 액세스만 허용하고 해당 액세스를 인증합니다. 예를 들어 구현에서 관리자 액세스는 사용하지 않도록 설정됩니다. 따라서 컴퓨팅 클러스터는 Microsoft Entra 역할 할당을 통해서만 이미지를 끌어올 수 있습니다.
잘 설계된 중요 업무용 워크로드: 컨테이너 레지스트리를 참조하세요.
지역 리소스
지역 리소스는 단일 Azure 지역에 배포 스탬프의 일부로 프로비저닝됩니다. 이러한 리소스는 다른 지역의 리소스와 아무 것도 공유하지 않으며 독립적으로 제거하거나 추가 지역에 복제할 수 있습니다. 그러나 이들은 서로 전역 리소스를 공유합니다.
이 아키텍처에서 통합 배포 파이프라인은 이러한 리소스와 함께 스탬프를 배포합니다.
다음은 구성 요소에 대한 개략적인 고려 사항입니다. 결정에 대한 자세한 내용은 지역 스탬프 리소스를 참조하세요.
프런트 엔드
이 아키텍처는 백 엔드 서비스에 요청을 보내는 SPA(단일 페이지 애플리케이션)를 사용합니다. 장점은 웹 사이트 환경에 필요한 컴퓨팅이 서버 대신 클라이언트에 오프로드된다는 것입니다. SPA는 Azure Storage 계정에서 정적 웹 사이트로 호스트됩니다.
또 다른 선택은 인증서가 노출되는 방법, 전역 부하 분산 장치에 대한 연결, 기타 요소와 같은 추가 고려 사항을 소개하는 Azure Static Web Apps입니다.
정적 콘텐츠는 일반적으로 CDN(콘텐츠 배달 네트워크)을 사용하여 클라이언트와 가까운 저장소에 캐시되므로 백 엔드 서버와 직접 통신하지 않고도 데이터를 신속하게 처리할 수 있습니다. 안정성을 높이고 네트워크 대기 시간을 줄이는 비용 효율적인 방법입니다. 이 아키텍처에서 Azure Front Door의 기본 제공 CDN 기능은 경계 네트워크에서 정적 웹 사이트 콘텐츠를 캐시하는 데 사용됩니다.
컴퓨팅 클러스터
백 엔드 컴퓨팅은 세 개의 마이크로 서비스로 구성된 애플리케이션을 실행하며 상태 비저장입니다. 따라서 컨테이너화는 애플리케이션을 호스트하는 데 적합한 전략입니다. AKS(Azure Kubernetes Service)는 대부분의 비즈니스 요구 사항을 충족하고 Kubernetes가 많은 산업에서 널리 채택되기 때문에 선택되었습니다. AKS는 고급 스케일링 성능과 배포 토폴로지를 지원합니다. AKS 작동 시간 SLA 계층은 Kubernetes 컨트롤 플레인에 대한 가용성을 보장하므로 중요 업무용 애플리케이션을 호스트하는 데 적극 권장됩니다.
Azure는 Azure Functions와 Azure App Service와 같은 다른 컴퓨팅 서비스를 제공합니다. 이러한 옵션은 유연성과 밀도를 희생하여 추가 관리 책임을 Azure에 오프로드합니다.
참고
스탬프의 임시 특성을 염두에 두고 컴퓨팅 클러스터에 상태를 저장하지 않습니다. 가능한 한 외부 데이터베이스에 상태를 유지하여 스케일링과 복구 작업을 가볍게 유지합니다. 예를 들어 AKS에서 Pod는 자주 변경됩니다. Pod에 상태를 연결하면 데이터 일관성의 부담이 가중됩니다.
지역 메시지 브로커
성능을 최적화하고 최대 부하 동안 응답성을 유지하기 위해 설계는 비동기 메시징을 사용하여 집중적인 시스템 흐름을 처리합니다. 요청이 프런트 엔드 API로 빠르게 다시 승인되면 메시지 브로커에서도 요청이 대기됩니다. 이러한 메시지는 예를 들어 데이터베이스에 대한 쓰기 작업을 처리하는 백 엔드 서비스에서 이후에 사용됩니다.
이 메시지 브로커와 같은 특정 지점을 제외하고 전체 스탬프는 상태 비저장입니다. 데이터는 짧은 기간 동안 브로커에서 큐에 대기합니다. 메시지 브로커는 적어도 한 번 배달을 보장해야 합니다. 즉, 서비스가 복원된 후 브로커를 사용할 수 없게 되면 메시지가 큐에 있게 됩니다. 그러나 해당 메시지에 여전히 처리가 필요한지 여부를 결정하는 것은 소비자의 책임입니다. 메시지가 처리되고 전역 데이터베이스에 저장되면 큐가 드레이닝됩니다.
이 설계에서는 Azure Event Hubs가 사용됩니다. 검사점 지정을 위해 추가 Azure Storage 계정이 프로비저닝됩니다. Event Hubs는 이벤트 스트리밍과 같이 높은 처리량이 필요한 사용 사례에 권장되는 선택입니다.
추가 메시지 보장이 필요한 사용 사례의 경우 Azure Service Bus를 권장합니다. 클라이언트 쪽 커서를 사용하는 2단계 커밋뿐만 아니라 기본 제공 배달 못 한 편지 큐와 중복 제거 기능과 같은 기능을 사용할 수 있습니다.
자세한 내용은 중요 업무용 워크로드에 대한 메시징 서비스를 참조하세요.
지역 비밀 저장소
각 스탬프에는 비밀과 구성을 저장하는 자체 Azure Key Vault가 있습니다. 전역 데이터베이스에 대한 연결 문자열과 같은 공통 비밀이 있지만 Event Hubs 연결 문자열과 같은 단일 스탬프에 고유한 정보도 있습니다. 또한 독립 리소스는 단일 실패 지점을 방지합니다.
잘 설계된 중요 업무용 워크로드: 데이터 무결성 보호를 참조하세요.
배포 파이프라인
중요 업무용 애플리케이션의 빌드와 릴리스 파이프라인은 완전히 자동화되어야 합니다. 따라서 어떤 조치도 수동으로 수행할 필요가 없습니다. 이 설계는 매번 일관성 있게 유효성을 검사한 스탬프를 배포하는 완전히 자동화된 파이프라인을 보여 줍니다. 또 다른 방법은 기존 스탬프에 롤링 업데이트만 배포하는 것입니다.
소스 코드 리포지토리
GitHub는 소스 제어에 사용되며 애플리케이션 코드와 인프라 코드에 대한 협업을 위한 고가용성 Git 기반 플랫폼을 제공합니다.
CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인
사전 프로덕션 및 프로덕션 환경에서 업무 워크로드를 구축, 테스트, 배포하려면 자동화된 파이프라인이 필요합니다. Azure Pipelines는 Azure와 기타 클라우드 플랫폼을 대상으로 할 수 있는 풍부한 도구 세트를 고려하여 선택되었습니다.
또 다른 선택은 CI/CD 파이프라인용 GitHub Actions입니다. 추가된 이점은 소스 코드와 파이프라인을 함께 배치할 수 있다는 것입니다. 그러나 풍부한 CD 기능 때문에 Azure Pipelines를 선택했습니다.
잘 설계된 중요 업무용 워크로드: DevOps 프로세스를 참조하세요.
빌드 에이전트
Microsoft 호스팅 빌드 에이전트는 구현에서 복잡성과 관리 오버헤드를 줄이기 위해 사용됩니다. 자체 호스팅 에이전트는 강화된 보안 태세가 필요한 시나리오에 사용할 수 있습니다.
참고
자체 호스팅 에이전트의 사용은 중요 업무용 - 연결됨 참조 구현에서 설명합니다.
가시성 리소스
효과적인 운영을 허용하고 안정성을 최대화하려면 애플리케이션과 인프라의 운영 데이터를 사용할 수 있어야 합니다. 이 참조는 애플리케이션의 전체적인 가시성을 달성하기 위한 기준을 제공합니다.
통합 데이터 싱크
- Azure Log Analytics는 모든 애플리케이션과 인프라 구성 요소에 대한 로그와 메트릭을 저장하는 통합 싱크로 사용됩니다.
- Azure Application Insights는 APM(애플리케이션 성능 관리) 도구로 사용되어 모든 애플리케이션 모니터링 데이터를 수집하고 이를 Log Analytics 내에 직접 저장합니다.
전역 리소스와 지역 리소스에 대한 모니터링 데이터는 독립적으로 저장해야 합니다. 단일 실패 지점을 방지하기 위해 단일 중앙 집중식 가시성 저장소는 권장되지 않습니다. 작업 영역 간 쿼리는 단일 창을 구현하는 데 사용됩니다.
이 아키텍처에서 영역 내의 모니터링 리소스는 스탬프 자체와 독립적이어야 합니다. 스탬프를 분해하더라도 여전히 가시성을 유지하기를 원하기 때문입니다. 각 지역 스탬프에는 고유한 전용 Application Insights와 Log Analytics 작업 영역이 있습니다. 리소스는 지역별로 프로비저닝되지만 스탬프보다 오래 지속됩니다.
마찬가지로 Azure Front Door, Azure Cosmos DB, Container Registry와 같은 공유 서비스의 데이터는 Log Analytics 작업 영역의 전용 인스턴스에 저장됩니다.
데이터 보관 및 분석
활성 작업에 필요하지 않은 운영 데이터는 데이터 보존 목적, 애플리케이션 상태 모델과 운영 절차를 최적화하기 위해 적용할 수 있는 AIOps에 대한 분석 원본을 제공하기 위해 Log Analytics에서 Azure Storage 계정으로 내보내집니다.
잘 설계된 중요 업무용 워크로드: 예측 작업 및 AI 작업을 참조하세요.
요청 및 프로세서 흐름
이 이미지는 참조 구현의 요청 및 백그라운드 프로세서 흐름을 보여 줍니다.
이 흐름에 대한 설명은 다음 섹션에 있습니다.
웹 사이트 요청 흐름
웹 사용자 인터페이스에 대한 요청은 전역 부하 분산 장치로 전송됩니다. 이 아키텍처의 경우 전역 부하 분산 장치는 Azure Front Door입니다.
WAF 규칙이 평가됩니다. WAF 규칙은 XSS(교차 사이트 스크립팅)와 SQL 주입과 같은 다양한 공격으로부터 시스템을 보호하여 시스템의 안정성에 긍정적인 영향을 미칩니다. WAF 규칙을 위반하고 처리가 중지되는 경우 Azure Front Door는 요청자에게 오류를 반환합니다. 위반한 WAF 규칙이 없으면 Azure Front Door는 계속 처리합니다.
Azure Front Door는 라우팅 규칙을 사용하여 요청을 전달할 백 엔드 풀을 결정합니다. 요청을 라우팅 규칙에 매칭하는 방법. 이 참조 구현에서 라우팅 규칙을 사용하여 Azure Front Door에서 UI와 프런트 엔드 API 요청을 다른 백 엔드 리소스로 라우팅할 수 있습니다. 이 경우 패턴 “/*”은 UI 라우팅 규칙과 일치합니다. 이 규칙은 SPA(단일 페이지 애플리케이션)를 호스트하는 정적 웹 사이트가 있는 스토리지 계정이 포함된 백 엔드 풀로 요청을 라우팅합니다. Azure Front Door는 풀의 백 엔드에 할당된 우선 순위 및 가중치를 사용하여 요청을 라우팅할 백 엔드를 선택합니다. 원본으로의 트래픽 라우팅 메서드. Azure Front Door는 상태 프로브를 사용하여 요청이 정상이 아닌 백 엔드로 라우팅되지 않도록 합니다. SPA는 정적 웹 사이트가 있는 선택된 스토리지 계정에서 제공됩니다.
참고
Azure Front Door 클래식의 백 엔드 풀 및 백 엔드라는 용어는 Azure Front Door 표준 또는 프리미엄 계층에서 원본 그룹 및 원본이라고 합니다.
SPA는 Azure Front Door 프런트 엔드 호스트에 대한 API 호출을 수행합니다. API 요청 URL의 패턴은 “/api/*”입니다.
프런트 엔드 API 요청 흐름
WAF 규칙은 2단계와 같이 평가됩니다.
Azure Front Door는 “/api/*” 패턴으로 요청을 API 라우팅 규칙과 일치하게 합니다. API 라우팅 규칙은 요청을 AKS(Azure Kubernetes Service)의 올바른 서비스로 라우팅하는 방법을 알고 있는 NGINX 수신 컨트롤러에 대한 공용 IP 주소가 포함된 백 엔드 풀로 요청을 라우팅합니다. 이전과 마찬가지로 Azure Front Door는 백 엔드에 할당된 우선 순위와 가중치를 사용하여 올바른 NGINX 수신 컨트롤러 백 엔드를 선택합니다.
GET 요청의 경우 프런트 엔드 API는 데이터베이스에서 읽기 작업을 수행합니다. 이 참조 구현의 경우 데이터베이스는 전역 Azure Cosmos DB 인스턴스입니다. Azure Cosmos DB에는 다중 쓰기 지역을 쉽게 구성하여 보조 지역에 대한 읽기 및 쓰기에 대한 자동 장애 조치(failover)를 허용하는 기능을 포함하여 중요 업무용 워크로드에 적합한 여러 기능이 있습니다. API는 재시도 논리로 구성된 클라이언트 SDK를 사용하여 Azure Cosmos DB와 통신합니다. SDK는 ApplicationRegion 매개 변수를 기반으로 통신할 수 있는 Azure Cosmos DB 지역의 최적 순서를 결정합니다.
POST 또는 PUT 요청의 경우 프런트 엔드 API는 메시지 브로커에 대한 쓰기를 수행합니다. 참조 구현에서 메시지 브로커는 Azure Event Hubs입니다. Service Bus를 선택할 수도 있습니다. 처리기는 나중에 메시지 브로커에서 메시지를 읽고 Azure Cosmos DB에 필요한 모든 쓰기를 수행합니다. API는 클라이언트 SDK를 사용하여 쓰기를 수행합니다. 다시 시도하도록 클라이언트를 구성할 수 있습니다.
백그라운드 프로세서 흐름
백그라운드 프로세서는 메시지 브로커의 메시지를 처리합니다. 백그라운드 프로세서는 클라이언트 SDK를 사용하여 읽기를 수행합니다. 다시 시도하도록 클라이언트를 구성할 수 있습니다.
백그라운드 프로세서는 전역 Azure Cosmos DB 인스턴스에서 적절한 쓰기 작업을 수행합니다. 백그라운드 프로세서는 다시 시도하도록 구성된 클라이언트 SDK를 사용하여 Azure Cosmos DB에 연결합니다. 클라이언트의 기본 지역 목록은 여러 지역으로 구성될 수 있습니다. 이 경우 쓰기에 실패하면 다음 기본 설정 지역에서 다시 시도가 수행됩니다.
디자인 영역
중요 업무용 아키텍처를 정의할 때 권장 사항과 모범 사례 지침을 위해 이러한 설계 영역을 살펴보는 것이 좋습니다.
| 디자인 영역 | 설명 |
|---|---|
| 애플리케이션 설계 | 스케일링과 오류 처리를 허용하는 디자인 패턴. |
| 애플리케이션 플랫폼 | 잠재적인 실패 사례에 대한 인프라 선택 및 완화. |
| 데이터 플랫폼 | 필요한 볼륨, 개발속도, 다양성, 진실성 특성을 평가하여 정보를 제공하는 데이터 저장소 기술의 선택 사항. |
| 네트워킹 및 연결 | 들어오는 트래픽을 스탬프로 라우팅하기 위한 네트워크 고려 사항. |
| 상태 모델링 | 고객 영향 분석을 통한 가시성 고려 사항은 전반적인 애플리케이션 상태를 결정하기 위한 상관 관계 모니터링임. |
| 배포 및 테스트 | 동기화된 부하 테스트 및 실패 주입(카오스) 테스트와 같은 통합된 테스트 시나리오를 사용하는 CI/CD 파이프라인 및 자동화 고려 사항에 대한 전략. |
| 보안 | Microsoft 제로 트러스트 모델을 통한 공격 벡터 완화. |
| 운영 프로시저 | 배포, 키 관리, 패치, 업데이트와 관련된 프로세스. |
** 이 아키텍처와 관련된 설계 영역 고려 사항을 나타냅니다.
관련 참고 자료
이 아키텍처에서 사용되는 Azure 서비스에 대한 제품 설명서는 다음 문서를 참조하세요.
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure Application Insights
- Azure Event Hubs
- Azure Blob Storage
이 아키텍처 배포
참조 구현을 배포하여 중요 업무용 컨텍스트에서 운영되는 방법을 포함하여 고려되는 리소스를 완전히 이해합니다. 여기에는 Azure에서 중요 업무용 애플리케이션 개발을 위한 솔루션 지향 접근 방식을 설명하기 위한 배포 가이드가 포함되어 있습니다.
다음 단계
수신 및 송신 트래픽에 대한 네트워크 제어를 사용하여 기준 아키텍처를 확장하려면 이 아키텍처를 참조하세요.