Azure의 중요 업무용 기준 아키텍처
이 아키텍처는 Azure에서 중요 업무용 워크로드를 디자인하기 위한 지침을 제공합니다. 클라우드 네이티브 기능을 사용하여 안정성 및 운영 효율성을 극대화합니다. Well-Architected 중요 업무용 워크로드에 대한 디자인 방법론을 공용 엔드포인트를 통해 워크로드에 액세스하고 다른 회사 리소스에 대한 프라이빗 네트워크 연결이 필요하지 않은 인터넷 연결 애플리케이션에 적용합니다.
중요합니다
이 지침은 Azure에서 중요 업무용 애플리케이션 개발을 보여 주는 프로덕션 등급 예제 구현 을 통해 지원됩니다. 이 구현은 프로덕션을 향한 첫 번째 단계에서 추가 솔루션 개발을 위한 기초로 사용할 수 있습니다.
안정성 계층
안정성은 상대적 개념이며 워크로드가 적절하게 안정되려면 SLO(서비스 수준 목표) 및 SLA(서비스 수준 계약)를 포함하여 관련 비즈니스 요구 사항을 반영하여 애플리케이션을 사용할 수 있어야 하는 시간을 캡처해야 합니다.
이 아키텍처는 허용되는 연간 가동 중지 시간 52분 35초에 해당하는 99.99%SLO를 대상으로 합니다. 따라서 모든 포괄 디자인 결정은 이 대상 SLO를 수행하기 위한 것입니다.
팁 (조언)
현실적인 SLO를 정의하려면 아키텍처 범위 내에서 모든 Azure 구성 요소 및 기타 요인의 안정성 목표를 이해하는 것이 중요합니다. 자세한 내용은 안정성 목표 정의에 대한 권장 사항을 참조하세요. 이러한 개별 숫자를 집계하여 워크로드 대상에 맞춰야 하는 복합 SLO를 결정해야 합니다.
주요 디자인 전략
실패, 지역 가용성, 배포 효율성 및 보안에서 복구하는 기능과 같은 많은 요인이 애플리케이션의 안정성에 영향을 줄 수 있습니다. 이 아키텍처는 이러한 요소를 해결하고 대상 안정성 계층이 달성되도록 하기 위한 일련의 가장 중요한 디자인 전략을 적용합니다.
계층의 중복성
활성-활성 모델의 여러 지역에 배포합니다. 애플리케이션은 활성 사용자 트래픽을 처리하는 둘 이상의 Azure 지역에 분산됩니다.
고려된 모든 서비스에 가용성 영역을 활용하여 단일 Azure 지역 내에서 가용성을 최대화하여 지역 내의 물리적으로 분리된 데이터 센터에 구성 요소를 분산합니다.
전역 배포를 지원하는 리소스를 선택합니다.
배포 스탬프
지역 스탬프를 논리 리소스 집합을 독립적으로 프로비전하여 수요 변화를 따라갈 수 있는 배율 단위 로 배포합니다. 또한 각 스탬프는 독립적으로 스케일 인 및 스케일 아웃할 수 있는 프런트 엔드 API 및 백그라운드 프로세서와 같은 여러 중첩 배율 단위를 적용합니다.
안정적이고 반복 가능한 배포
Terraform과 같은 기술을 사용하여 IaC(Infrastructure as Code)의 원칙 을 적용하여 인프라 구성 요소에 대한 버전 제어 및 표준화된 운영 방식을 제공합니다.
가동 중지 시간 0/녹색 배포 파이프라인을 구현합니다. 지속적인 유효성 검사가 적용된 파란색/녹색 배포를 사용하여 스탬프를 단일 운영 단위로 배포하려면 빌드 및 릴리스 파이프라인을 완전히 자동화해야 합니다.
프로덕션 및 사전 프로덕션 환경에서 동일한 배포 파이프라인 코드를 사용하여 고려된 모든 환경에서 환경 일관성 을 적용합니다. 이렇게 하면 환경 전반의 배포 및 프로세스 변형과 관련된 위험이 제거됩니다.
동기화된 부하 및 비정상 상황 테스트를 비롯한 DevOps 프로세스의 일부로 자동화된 테스트를 통합하여 애플리케이션 코드와 기본 인프라의 상태를 완전히 검증하여 지속적인 유효성 검사를 수행합니다.
운영 인사이트
관찰 가능성 데이터에 대한 페더레이션된 작업 영역이 있습니다. 글로벌 리소스 및 지역 리소스에 대한 모니터링 데이터는 독립적으로 저장됩니다. 단일 실패 지점을 방지하려면 중앙 집중식 관찰 저장소를 사용하지 않는 것이 좋습니다. 작업 영역 간 쿼리는 작업을 위해 통합 데이터 싱크 및 단일 창 유리를 달성하는 데 사용됩니다.
컨텍스트화를 위해 애플리케이션 상태를 신호등 모델에 매핑하는 계층화된 상태 모델을 생성합니다. 상태 점수는 각 개별 구성 요소에 대해 계산된 다음 사용자 흐름 수준에서 집계되고 성능과 같은 주요 비기능적 요구 사항과 결합되어 애플리케이션 상태를 정량화하는 계수로 사용됩니다.
건축학
*이 아키텍처의 Visio 파일을 다운로드합니다.
이 아키텍처의 구성 요소는 이러한 방식으로 광범위하게 분류될 수 있습니다. Azure 서비스에 대한 제품 설명서는 관련 리소스를 참조하세요.
전역 리소스
글로벌 리소스는 오래 지속되며 시스템의 수명을 공유합니다. 다중 지역 배포 모델의 컨텍스트 내에서 전역적으로 사용할 수 있는 기능이 있습니다.
다음은 구성 요소에 대한 개략적인 고려 사항입니다. 결정에 대한 자세한 내용은 전역 리소스를 참조하세요.
글로벌 부하 분산 장치
글로벌 부하 분산 장치는 지역 내 백 엔드 서비스의 가용성에 따라 일정 수준의 보증을 통해 트래픽을 지역 배포로 안정적으로 라우팅하는 데 중요합니다. 또한 이 구성 요소에는 예를 들어 웹 애플리케이션 방화벽을 통해 수신 트래픽을 검사하는 기능이 있어야 합니다.
Azure Front Door 는 들어오는 모든 클라이언트 HTTP(S) 트래픽에 대한 전역 진입점으로 사용되며, 보안 계층 7 수신 트래픽에 WAF(웹 애플리케이션 방화벽) 기능이 적용됩니다. TCP Anycast를 사용하여 Microsoft 백본 네트워크를 사용하여 라우팅을 최적화하고 지역 상태가 저하된 경우 투명한 장애 조치(failover)를 허용합니다. 라우팅은 주요 지역 리소스의 복합 히스를 확인하는 사용자 지정 상태 프로브에 따라 달라집니다. 또한 Azure Front Door는 웹 사이트 구성 요소에 대한 정적 자산을 캐시하는 기본 제공 CDN(콘텐츠 배달 네트워크)을 제공합니다.
또 다른 옵션은 DNS 기반 계층 4 부하 분산 장치인 Traffic Manager입니다. 그러나 DNS 전파가 발생해야 하므로 모든 클라이언트에 오류가 투명하지는 않습니다.
데이터베이스
워크로드와 관련된 모든 상태는 외부 데이터베이스인 NoSQL용 Azure Cosmos DB에 저장됩니다. 이 옵션은 클라이언트와 서버 쪽 모두에서 성능 및 안정성 튜닝에 필요한 기능 집합을 가지고 있기 때문에 선택되었습니다. 계정에 다중 마스터 쓰기를 사용하도록 설정하는 것이 좋습니다.
비고
다중 지역 쓰기 구성은 안정성에 대한 골드 표준을 나타내지만 비용을 적절하게 고려해야 하는 상당한 절상이 있습니다.
계정은 각 지역 스탬프에 복제되며 영역 중복도 사용하도록 설정됩니다. 또한 컨테이너 수준에서 자동 크기 조정을 사용하도록 설정하여 컨테이너가 필요에 따라 프로비전된 처리량의 크기를 자동으로 조정합니다.
자세한 내용은 중요 업무용 워크로드에 대한 데이터 플랫폼을 참조하세요.
Well-Architected 중요 업무용 워크로드: 전역적으로 분산된 다중 쓰기 데이터 저장소를 참조하세요.
컨테이너 레지스트리
Azure Container Registry 는 모든 컨테이너 이미지를 저장하는 데 사용됩니다. 리소스가 단일 레지스트리로 작동하여 다중 마스터 지역 레지스트리가 있는 여러 지역에 서비스를 제공할 수 있는 지역 복제 기능이 있습니다.
보안 조치로 필요한 엔터티에 대한 액세스만 허용하고 해당 액세스를 인증합니다. 예를 들어 구현에서 관리자 액세스는 사용하지 않도록 설정됩니다. 따라서 컴퓨팅 클러스터는 Microsoft Entra 역할 할당을 통해서만 이미지를 끌어올 수 있습니다.
지역 자원
지역 리소스는 단일 Azure 지역에 배포 스탬프 의 일부로 프로비전됩니다. 이러한 리소스는 다른 지역의 리소스와 아무 것도 공유하지 않습니다. 독립적으로 제거하거나 추가 지역에 복제할 수 있습니다. 그러나 서로 간에 글로벌 리소스를 공유합니다 .
이 아키텍처에서 통합 배포 파이프라인은 이러한 리소스가 포함된 스탬프를 배포합니다.
다음은 구성 요소에 대한 개략적인 고려 사항입니다. 결정에 대한 자세한 내용은 지역 스탬프 리소스를 참조하세요.
프론트엔드
이 아키텍처는 백 엔드 서비스에 요청을 보내는 SPA(단일 페이지 애플리케이션)를 사용합니다. 장점은 웹 사이트 환경에 필요한 컴퓨팅이 서버 대신 클라이언트로 오프로드된다는 것입니다. SPA는 Azure Storage 계정에서 정적 웹 사이트로 호스트됩니다.
정적 콘텐츠는 일반적으로 CDN(콘텐츠 배달 네트워크)을 사용하여 클라이언트와 가까운 저장소에 캐시되므로 백 엔드 서버와 직접 통신하지 않고도 데이터를 신속하게 처리할 수 있습니다. 안정성을 높이고 네트워크 대기 시간을 줄이는 비용 효율적인 방법입니다. 이 아키텍처에서는 Azure Front Door의 기본 제공 CDN 기능을 사용하여 에지 네트워크에서 정적 웹 사이트 콘텐츠를 캐시합니다.
컴퓨팅 클러스터
백 엔드 컴퓨팅은 3개의 마이크로 서비스로 구성된 애플리케이션을 실행하며 상태 비포장입니다. 따라서 컨테이너화는 애플리케이션을 호스트하는 적절한 전략입니다. AKS(Azure Kubernetes Service) 는 대부분의 비즈니스 요구 사항을 충족하고 Kubernetes는 여러 산업에서 널리 채택되기 때문에 선택되었습니다. AKS는 고급 확장성 및 배포 토폴로지 지원을 지원합니다. AKS 가동 시간 SLA 계층 은 Kubernetes 컨트롤 플레인에 대한 가용성 보장을 제공하기 때문에 중요 업무용 애플리케이션을 호스팅하는 데 매우 권장됩니다.
Azure는 Azure Functions 및 Azure App Services와 같은 다른 컴퓨팅 서비스를 제공합니다. 이러한 옵션은 유연성과 밀도를 희생하여 Azure에 추가 관리 책임을 오프로드합니다.
비고
스탬프의 임시 특성을 염두에 두고 컴퓨팅 클러스터에 상태를 저장하지 않습니다. 크기 조정 및 복구 작업을 간단하게 유지하기 위해 가능한 한 외부 데이터베이스에 상태를 유지합니다. 예를 들어 AKS에서 Pod는 자주 변경됩니다. Pod에 상태를 연결하면 데이터 일관성의 부담이 가중됩니다.
중요 업무용 워크로드Well-Architected 컨테이너 오케스트레이션 및 Kubernetes를 참조하세요.
지역 메시지 브로커
최대 부하 중에 성능을 최적화하고 응답성을 유지하기 위해 디자인은 비동기 메시징을 사용하여 집중적인 시스템 흐름을 처리합니다. 요청이 프런트 엔드 API로 빠르게 다시 승인되므로 요청도 메시지 브로커에 큐에 대기됩니다. 이러한 메시지는 나중에 데이터베이스에 대한 쓰기 작업을 처리하는 백 엔드 서비스에서 사용됩니다.
이 메시지 브로커와 같은 특정 지점을 제외하고 전체 스탬프는 상태 비지정입니다. 데이터는 짧은 기간 동안 broker에 큐에 대기됩니다. 메시지 브로커는 적어도 한 번 이상 배달을 보장해야 합니다. 즉, 서비스가 복원된 후 broker를 사용할 수 없게 되면 메시지가 큐에 있습니다. 그러나 해당 메시지가 여전히 처리가 필요한지 여부를 결정하는 것은 소비자의 책임입니다. 메시지가 처리되고 전역 데이터베이스에 저장되면 큐가 드레이닝됩니다.
이 디자인에서는 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가 선택되었습니다.
빌드 에이전트
Microsoft에서 호스팅하는 빌드 에이전트 는 복잡성 및 관리 오버헤드를 줄이기 위해 이 구현에서 사용됩니다. 자체 호스팅 에이전트는 강화된 보안 태세가 필요한 시나리오에 사용할 수 있습니다.
비고
자체 호스팅 에이전트의 사용은 중요 업무용 - 연결된 참조 구현에서 보여 줍니다.
관찰성 리소스
효과적인 작업을 허용하고 안정성을 최대화하려면 애플리케이션 및 인프라의 운영 데이터를 사용할 수 있어야 합니다. 이 참조는 애플리케이션의 전체적인 관찰 가능성을 달성하기 위한 기준을 제공합니다.
통합 데이터 싱크
- Azure Log Analytics 는 모든 애플리케이션 및 인프라 구성 요소에 대한 로그 및 메트릭을 저장하는 통합 싱크로 사용됩니다.
- Azure Application Insights 는 모든 애플리케이션 모니터링 데이터를 수집하고 Log Analytics 내에 직접 저장하는 APM(애플리케이션 성능 관리) 도구로 사용됩니다.
글로벌 리소스 및 지역 리소스에 대한 모니터링 데이터는 독립적으로 저장해야 합니다. 단일 중앙 집중식 관찰 저장소는 단일 실패 지점을 방지하기 위해 권장되지 않습니다. 작업 영역 간 쿼리는 단일 창의 유리를 달성하는 데 사용됩니다.
이 아키텍처에서 지역 내의 리소스 모니터링은 스탬프 자체와 독립적이어야 합니다. 스탬프를 분해하는 경우 여전히 관찰 가능성을 유지하려고 하기 때문입니다. 각 지역 스탬프에는 고유한 전용 Application Insights 및 Log Analytics 작업 영역이 있습니다. 리소스는 지역별로 프로비전되지만 스탬프보다 오래 지속됩니다.
마찬가지로 Azure Front Door, Azure Cosmos DB 및 Container Registry와 같은 공유 서비스의 데이터는 Log Analytics 작업 영역의 전용 인스턴스에 저장됩니다.
데이터 보관 및 분석
활성 작업에 필요하지 않은 운영 데이터는 데이터 보존을 위해 Log Analytics에서 Azure Storage 계정으로 내보내지며, 애플리케이션 상태 모델 및 운영 절차를 최적화하기 위해 적용할 수 있는 AIOps에 대한 분석 원본을 제공합니다.
요청 및 프로세서 흐름
이 이미지는 참조 구현의 요청 및 백그라운드 프로세서 흐름을 보여줍니다.
이 흐름에 대한 설명은 다음 섹션에 있습니다.
웹 사이트 요청 흐름
웹 사용자 인터페이스에 대한 요청이 전역 부하 분산 장치로 전송됩니다. 이 아키텍처의 경우 전역 부하 분산 장치는 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 프론트 도어
- Azure Cosmos DB
- Azure Container Registry
- Azure 로그 분석
- Azure Key Vault
- Azure Service Bus
- Azure Kubernetes Service
- Azure 애플리케이션 인사이트
- Azure Event Hubs
- Azure Blob Storage
이 아키텍처 배포
중요 업무용 컨텍스트에서 운영되는 방법을 포함하여 고려된 리소스에 대한 완전한 이해를 얻기 위해 참조 구현을 배포합니다. 여기에는 Azure에서 중요 업무용 애플리케이션 개발을 위한 솔루션 지향 접근 방식을 설명하기 위한 배포 가이드가 포함되어 있습니다.
다음 단계
수신 및 송신 트래픽에 대한 네트워크 컨트롤을 사용하여 기준 아키텍처를 확장하려면 이 아키텍처를 참조하세요.