이 문서에서는 Azure 앱 Service를 사용하여 중요 업무용 웹 애플리케이션을 배포하는 방법을 설명합니다. 아키텍처는 신뢰할 수 있는 웹앱 패턴을 시작점으로 사용합니다. 레거시 워크로드가 있고 PaaS(Platform-as-a-Service) 서비스를 채택하려는 경우 이 아키텍처를 사용합니다.
.NET 용 신뢰할 수 있는 웹앱 패턴은 클라우드로 이동하는 웹앱을 업데이트하거나 서식을 변경하고, 필요한 코드 변경을 최소화하고, SLO(서비스 수준 목표)를 99.9%로 대상으로 지정하기 위한 지침을 제공합니다. 중요 업무용 워크로드에는 높은 안정성 및 가용성 요구 사항이 있습니다. 99.95%, 99.99% 이상의 SLO에 도달하려면 추가적인 중요 업무용 디자인 패턴과 운영 엄격을 적용해야 합니다. 이 문서에서는 주요 기술 영역과 중요 업무용 디자인 사례를 구현하고 도입하는 방법을 설명합니다.
참고 항목
이 문서의 지침은 잘 설계된 프레임워크 중요 업무용 워크로드 시리즈의 디자인 방법론 및 모범 사례를 기반으로 합니다.
다음 섹션에서는 다음 방법을 설명합니다.
- 기존 워크로드를 검토하여 구성 요소, 사용자 및 시스템 흐름, 가용성 및 확장성 요구 사항을 이해합니다.
- 스케일 단위 아키텍처를 개발하고 구현하여 구획화를 통해 엔드 투 엔드 확장성을 최적화하고 용량 추가 및 제거 프로세스를 표준화합니다.
- 상태 비저장 임시 배율 단위 또는 배포 스탬프를 구현하여 확장성 및 가동 중지 시간 제로 배포를 사용하도록 설정합니다.
- 워크로드를 구성 요소로 분할하여 확장성을 준비할 수 있는지 확인합니다. 확장성 및 분리 흐름에는 개별 구성 요소가 필요합니다.
- 고객과의 근접성을 개선하고 잠재적인 지역 가동 중단에 대비하기 위해 둘 이상의 Azure 지역에 워크로드를 배포하여 글로벌 배포 를 준비합니다.
- 구성 요소를 분리하고 이벤트 기반 아키텍처를 구현합니다.
아키텍처
다음 다이어그램은 신뢰할 수 있는 웹앱 패턴에 이전 고려 사항을 적용합니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
빨간색 상자는 함께 스케일링되는 서비스가 있는 배율 단위를 나타냅니다. 효과적으로 함께 크기를 조정하려면 각 서비스의 크기, SKU 및 사용 가능한 IP 주소를 최적화합니다. 예를 들어 Azure 앱 Configuration에서 제공하는 최대 요청 수는 배율 단위에서 제공하는 초당 요청 수와 상관 관계가 있습니다. 지역에 더 많은 용량을 추가하는 경우 개별 배율 단위도 더 추가해야 합니다.
이러한 개별 배율 단위에는 종속성이 없으며 개별 배율 단위 외부의 공유 서비스와만 통신합니다. 독립적인 배율 단위를 미리 테스트할 수 있습니다. 다른 배포 영역에 영향을 주지 않도록 하려면 독립적인 배율 단위를 배포하고 새 릴리스에서 서비스를 대체하는 옵션을 도입합니다.
중요 업무용 워크로드의 경우 독립 크기 조정 단위는 일시적이므로 출시 프로세스를 최적화하고 지역 내 및 지역 간에 확장성을 제공합니다. 독립 배율 단위로 상태를 저장하지 않습니다. 크기 조정 단위의 스토리지에 Azure Cache for Redis를 사용하고 데이터베이스에 저장된 중요 상태 또는 데이터만 저장하는 것이 좋습니다. 배율 단위 중단이 있거나 다른 배율 단위로 전환하는 경우 속도가 느려지거나 새 로그인이 필요할 수 있지만 Azure Cache for Redis는 계속 실행됩니다.
Application Insights는 배율 단위에서 제외됩니다. 데이터를 저장하거나 모니터링하는 서비스를 제외합니다. 고유한 수명 주기를 사용하여 리소스 그룹으로 구분합니다.
배율 단위를 바꾸거나 새 단위를 배포하는 경우 기록 데이터를 유지하고 지역당 하나의 인스턴스를 사용합니다.
자세한 내용은 Azure에서 중요 업무용 워크로드의 애플리케이션 디자인을 참조하세요.
구성 요소
이 아키텍처는 다음 구성 요소를 사용합니다.
- App Service 는 애플리케이션 호스팅 플랫폼입니다.
- Azure Cache for Redis 는 요청을 캐시합니다.
- App Configuration 은 구성 설정을 저장합니다.
- Azure SQL 은 백 엔드 데이터베이스입니다.
- Application Insights는 애플리케이션에서 원격 분석을 가져옵니다.
대안
신뢰할 수 있는 웹앱 패턴에서 다음을 수행할 수 있습니다.
- App Service 대신 AKS(Azure Kubernetes Service)를 사용합니다. 이 옵션은 마이크로 서비스가 많은 복잡한 워크로드에 적합합니다. AKS는 기본 인프라에 대한 더 많은 제어를 제공하고 복잡한 다중 계층 설정을 허용합니다.
- 워크로드를 컨테이너화합니다. App Service는 컨테이너화를 지원하지만 이 예제에서는 워크로드가 컨테이너화되지 않습니다. 컨테이너를 사용하여 안정성 및 이식성을 향상합니다.
자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 애플리케이션 플랫폼 고려 사항을 참조하세요.
애플리케이션 플랫폼 선택
가용성 수준은 애플리케이션 플랫폼의 선택 및 구성에 따라 달라집니다. 중요 업무용 지침은 다음과 같습니다.
- 가능하면 가용성 영역을 사용합니다.
- 워크로드에 적합한 플랫폼 서비스를 선택합니다.
- 워크로드를 컨테이너화합니다.
가용성 집합은 여러 오류에 배포를 분산하고 데이터 센터 내에서 기본 업데이트합니다. 가용성 영역은 Azure 지역 내의 개별 데이터 센터에 배포를 분산합니다. 가용성 영역은 우선 순위가 지정되는 경우가 많지만 사용하는 전략은 워크로드에 따라 달라집니다. 예를 들어 대기 시간이 중요하거나 수다스러운 워크로드는 가용성 집합의 우선 순위를 지정하면 도움이 될 수 있습니다. 가용성 영역에 워크로드를 분산하면 영역 간 트래픽에 대한 대기 시간과 비용이 증가할 수 있습니다. 가용성 영역을 사용하는 경우 배율 단위의 모든 서비스가 지원되는지 확인합니다. 신뢰할 수 있는 웹앱 패턴의 모든 서비스는 가용성 영역을 지원합니다.
데이터 플랫폼 선택
선택하는 데이터베이스 플랫폼은 전체 워크로드 아키텍처, 특히 플랫폼의 활성-활성 또는 활성-수동 구성 지원에 영향을 줍니다. 신뢰할 수 있는 웹앱 패턴은 둘 이상의 인스턴스에서 쓰기 작업을 사용하는 활성-활성 배포를 기본적으로 지원하지 않는 Azure SQL을 사용합니다. 따라서 데이터베이스 수준은 활성-수동 전략으로 제한됩니다. 읽기 전용 복제본(replica) 있고 단일 지역에만 쓰는 경우 애플리케이션 수준에서 활성-활성 전략이 가능합니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
여러 데이터베이스는 각 서비스에 대한 데이터베이스가 있는 마이크로 서비스 아키텍처와 같은 복잡한 아키텍처에서 일반적입니다. 여러 데이터베이스를 사용하면 Azure Cosmos DB와 같은 다중 주 쓰기 데이터베이스를 채택하여 고가용성과 짧은 대기 시간을 향상시킬 수 있습니다. 지역 간 대기 시간은 제한 사항을 만들 수 있습니다. 일관성, 조작성, 비용 및 복잡성과 같은 비기능적 요구 사항 및 요인을 고려하는 것이 중요합니다. 개별 서비스가 고유한 요구 사항을 충족하기 위해 별도의 데이터 저장소 및 특수 데이터 기술을 사용할 수 있도록 합니다. 자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 데이터 플랫폼 고려 사항을 참조하세요.
상태 모델 정의
여러 데이터 센터 및 지리적 지역에 분산된 복잡한 다층 워크로드에서 상태 모델을 정의해야 합니다. 사용자 및 시스템 흐름을 정의하고, 서비스 간의 종속성을 지정하고 이해하고, 서비스 중 하나에 대한 중단 또는 성능 저하가 전체 워크로드에 미칠 수 있는 영향을 이해하고, 고객 환경을 모니터링 및 시각화하여 적절한 모니터링을 사용하도록 설정하고 수동 및 자동화된 작업을 개선합니다.
이전 다이어그램에서는 App Configuration과 같은 단일 구성 요소의 중단 또는 성능 저하로 인해 고객에게 잠재적인 성능 저하가 발생할 수 있는 방법을 보여 줍니다.
구성 요소를 배율 단위로 구분하면 영향을 받는 배율 단위 또는 전체 지역과 같이 애플리케이션의 영향을 받는 부분에 대한 트래픽 전송을 중지할 수 있습니다.
자세한 내용은 Azure의 중요 업무용 워크로드 상태 모델링 및 가시성을 참조하세요.
보안 및 네트워킹
온-프레미스 엔터프라이즈 배포에서 마이그레이션하는 워크로드에 대한 엄격한 네트워킹 및 보안 요구 사항이 있습니다. 모든 설정된 온-프레미스 프로세스가 클라우드 환경으로 변환되는 것은 아닙니다. 클라우드 환경에 적용 가능한 경우 이러한 요구 사항을 평가합니다.
ID는 클라우드 네이티브 패턴의 기본 보안 경계인 경우가 많습니다. 기업 고객은 보다 실질적인 보안 조치가 필요할 수 있습니다. 네트워크 보안 요구 사항을 해결하기 위해 대부분의 Azure PaaS 서비스는 Azure Private Link를 사용하여 네트워크를 보안 경계로 구현할 수 있습니다. Private Link는 가상 네트워크 내에서만 서비스에 액세스할 수 있도록 할 수 있습니다. 모든 서비스는 프라이빗 엔드포인트를 통해서만 액세스할 수 있습니다. 다음 다이어그램은 공용 인터넷 연결 엔드포인트만 Azure Front Door인 방법을 보여줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
신뢰할 수 있는 웹앱 패턴이 네트워크를 보안 경계로 설정하려면 다음을 사용해야 합니다.
- 이를 지원하는 모든 서비스에 대한 Private Link입니다.
- Azure Front Door 프리미엄은 유일한 인터넷 연결 퍼블릭 엔드포인트입니다.
- Azure Bastion을 통해 서비스에 액세스하기 위한 점프박스입니다.
- 서비스에 액세스할 수 있는 자체 호스팅 빌드 에이전트입니다.
중요 업무용 애플리케이션의 또 다른 일반적인 네트워크 요구 사항은 송신 트래픽을 제한하여 데이터 반출을 방지하는 것입니다. 적절한 방화벽 디바이스를 통해 Azure 방화벽을 라우팅하고 디바이스로 필터링하여 송신 트래픽을 제한합니다. 네트워크 컨트롤이 있는 Azure 중요 업무용 기준 아키텍처는 방화벽 및 Private Link를 사용합니다.
배포 및 테스트
잘못된 릴리스 또는 사용자 오류로 인한 가동 중지 시간은 항상 사용할 수 있어야 하는 워크로드에 문제가 될 수 있습니다. 고려해야 할 몇 가지 주요 영역은 다음과 같습니다.
- 가동 중지 시간 0개 배포
- 임시 파란색/녹색 배포
- 개별 구성 요소의 수명 주기 분석 및 함께 그룹화
- 지속적인 유효성 검사
가동 중지 시간 없는 배포 는 중요 업무용 워크로드의 핵심입니다. 항상 실행해야 하는 워크로드에는 최신 버전을 롤아웃하는 기본 테넌트 창이 있을 수 없습니다. 이 제한을 해결하기 위해 Azure 중요 업무용 아키텍처는 가동 중지 시간 제로 배포 패턴을 따릅니다. 변경 내용은 트래픽이 증분 방식으로 라우팅되기 전에 종단 간 테스트되는 새 배율 단위 또는 스탬프로 롤아웃됩니다. 모든 트래픽이 새 스탬프로 라우팅되면 이전 스탬프가 비활성화되고 제거됩니다.
자세한 내용은 Azure에서 중요 업무용 워크로드에 대한 배포 및 테스트를 참조하세요.