팁 (조언)
이 콘텐츠는 .NET Docs에서 제공되거나 오프라인으로 읽을 수 있는 무료 PDF 파일로 다운받을 수 있는 eBook 'Architect Modern Web Applications with ASP.NET Core and Azure'에서 발췌한 것입니다.
"전 세계 LOB(기간 업무) 리더는 클라우드(SaaS라고도 함)에서 애플리케이션을 가져오기 위해 IT 부서를 우회하고 잡지 구독처럼 비용을 지불하고 있습니다. 그리고 서비스가 더 이상 필요하지 않으면 코너에서 사용하지 않은 장비 없이 구독을 취소할 수 있습니다."
- 대릴 플러머, 가트너 애널리스트
애플리케이션의 요구 사항과 아키텍처에 관계없이 Microsoft Azure는 애플리케이션을 지원할 수 있습니다. 호스팅 요구 사항은 정적 웹 사이트 또는 수십 개의 서비스로 구성된 정교한 애플리케이션만큼 간단할 수 있습니다. ASP.NET Core 모놀리식 웹 애플리케이션 및 지원 서비스의 경우 권장되는 몇 가지 잘 알려진 구성이 있습니다. 이 문서의 권장 사항은 호스트할 리소스의 종류, 전체 애플리케이션, 개별 프로세스 또는 데이터에 따라 그룹화됩니다.
웹 애플리케이션
웹 애플리케이션은 다음을 사용하여 호스팅할 수 있습니다.
App Service 웹 앱
컨테이너(여러 옵션)
가상 머신(VM)
이 중 App Service Web Apps는 간단한 컨테이너 기반 앱을 비롯한 대부분의 시나리오에 권장되는 방법입니다. 마이크로 서비스 아키텍처의 경우 컨테이너 기반 접근 방식을 고려합니다. 애플리케이션을 실행하는 머신에 대한 더 많은 제어가 필요한 경우 Azure Virtual Machines를 고려합니다.
App Service 웹 앱
App Service Web Apps는 웹 애플리케이션 호스팅에 최적화된 완전 관리형 플랫폼을 제공합니다. Azure는 앱을 실행하고 확장하는 데 필요한 인프라를 처리하면서 비즈니스 논리에 집중할 수 있는 PaaS(Platform as a Service) 제품입니다. App Service Web Apps의 몇 가지 주요 기능:
DevOps 최적화(연속 통합 및 배달, 여러 환경, A/B 테스트, 스크립팅 지원).
글로벌 규모 및 고가용성.
SaaS 플랫폼 및 온-프레미스 데이터에 연결합니다.
보안 및 규정 준수.
Visual Studio 통합
Azure App Service는 대부분의 웹앱에 가장 적합한 선택입니다. 배포 및 관리는 플랫폼에 통합되고, 사이트는 높은 트래픽 부하를 처리하도록 빠르게 확장할 수 있으며, 기본 제공 부하 분산 및 트래픽 관리자는 고가용성을 제공합니다. 온라인 마이그레이션 도구를 사용하여 기존 사이트를 Azure App Service로 쉽게 이동할 수 있습니다. 웹 애플리케이션 갤러리에서 오픈 소스 앱을 사용하거나 선택한 프레임워크 및 도구를 사용하여 새 사이트를 만들 수 있습니다. WebJobs 기능을 사용하면 App Service 웹앱에 백그라운드 작업 처리를 쉽게 추가할 수 있습니다. 로컬 데이터베이스를 사용하여 온-프레미스에서 호스트되는 기존 ASP.NET 애플리케이션이 있는 경우 마이그레이션할 명확한 경로가 있습니다. Azure SQL Database에서 App Service Web App을 사용할 수 있습니다(또는 원하는 경우 온-프레미스 데이터베이스 서버에 대한 보안 액세스).
대부분의 경우 로컬로 호스트되는 ASP.NET 앱에서 App Service Web App으로 이동하는 것은 간단한 프로세스입니다. 앱 자체는 거의 또는 전혀 수정이 필요하지 않으며, Azure App Service Web Apps가 제공하는 다양한 기능을 빠르게 활용할 수 있습니다.
클라우드에 최적화되지 않은 앱 외에도 Azure App Service Web Apps는 많은 ASP.NET Core 앱과 같은 많은 간단한 모놀리식(분산되지 않은) 애플리케이션에 적합한 솔루션입니다. 이 접근 방식에서 아키텍처는 기본적이고 간단하게 이해하고 관리합니다.
단일 리소스 그룹의 적은 수의 리소스는 일반적으로 이러한 앱을 관리하기에 충분합니다. 일반적으로 여러 개별 프로세스로 구성된 앱이 아닌 단일 단위로 배포되는 앱은 이 기본 아키텍처 접근 방식에 적합한 후보입니다. 아키텍처적으로 간단하지만 이 방법을 사용하면 호스트된 앱이 수요 증가를 충족하기 위해 확장(노드당 더 많은 리소스)과 아웃(더 많은 호스트된 노드)을 모두 확장할 수 있습니다. 자동 크기 조정을 사용하면 노드 간 수요 및 평균 부하에 따라 앱을 호스팅하는 노드 수를 자동으로 조정하도록 앱을 구성할 수 있습니다.
App Service 내 컨테이너용 웹 앱
Web Apps를 직접 호스팅하는 지원 외에도 컨테이너용 App Service Web Apps를 사용하여 Windows 및 Linux에서 컨테이너화된 애플리케이션을 실행할 수 있습니다. 이 서비스를 사용하면 비즈니스로 확장할 수 있는 컨테이너화된 애플리케이션을 쉽게 배포하고 실행할 수 있습니다. 앱에는 위에 나열된 App Service Web Apps의 모든 기능이 있습니다. 또한 Web Apps for Containers는 Docker Hub, Azure Container Registry 및 GitHub를 사용하여 간소화된 CI/CD를 지원합니다. Azure DevOps를 사용하여 레지스트리에 변경 내용을 게시하는 빌드 및 배포 파이프라인을 정의할 수 있습니다. 그런 다음, 이러한 변경 내용을 스테이징 환경에서 테스트하고 배포 슬롯을 사용하여 프로덕션에 자동으로 배포하여 가동 중지 시간이 0으로 업그레이드되도록 할 수 있습니다. 이전 버전으로 롤백하는 작업은 쉽게 수행할 수 있습니다.
Web Apps for Containers가 가장 적합한 몇 가지 시나리오가 있습니다. Windows 또는 Linux 컨테이너에서 컨테이너화할 수 있는 기존 앱이 있는 경우 이 도구 집합을 사용하여 쉽게 호스트할 수 있습니다. 컨테이너를 게시한 다음 선택한 레지스트리에서 해당 이미지의 최신 버전을 끌어오도록 Web Apps for Containers를 구성하기만 하면 됩니다. 클래식 앱 호스팅 모델에서 클라우드 최적화 모델로 마이그레이션하는 "리프트 앤 시프트" 접근 방식입니다.
개발 팀이 컨테이너 기반 개발 프로세스로 이동할 수 있는 경우에도 이 방법이 잘 작동합니다. 컨테이너를 사용하여 앱을 개발하는 "내부 루프"에는 컨테이너를 사용하여 앱을 빌드하는 것이 포함됩니다. 코드 및 컨테이너 구성에 대한 변경 내용은 소스 제어로 푸시되며 자동화된 빌드는 Docker 허브 또는 Azure Container Registry와 같은 레지스트리에 새 컨테이너 이미지를 게시합니다. 이러한 이미지는 다음 다이어그램과 같이 프로덕션에 배포할 뿐만 아니라 추가 개발의 기초로 사용됩니다.
컨테이너를 사용하여 개발하는 것은 특히 컨테이너가 프로덕션에서 사용되는 경우 많은 이점을 제공합니다. 동일한 컨테이너 구성은 로컬 개발 머신에서 프로덕션에 대한 빌드 및 테스트 시스템까지 실행되는 각 환경에서 앱을 호스트하는 데 사용됩니다. 이 방법은 컴퓨터 구성 또는 소프트웨어 버전의 차이로 인한 결함 가능성을 크게 줄입니다. 컨테이너는 모든 OS에서 실행할 수 있으므로 개발자는 운영 체제를 포함하여 가장 생산적인 도구를 사용할 수도 있습니다. 경우에 따라 많은 컨테이너와 관련된 분산 애플리케이션은 단일 개발 머신에서 실행하는 데 리소스를 많이 소비할 수 있습니다. 이 시나리오에서는 다음 섹션에서 설명하는 Kubernetes 및 Azure Dev Spaces를 사용하도록 업그레이드하는 것이 합리적일 수 있습니다.
더 큰 애플리케이션의 일부가 더 작고 독립적인 자체 마이크로 서비스로 나뉘어짐에 따라 추가 디자인 패턴을 사용하여 앱 동작을 개선할 수 있습니다. API 게이트웨이는 개별 서비스를 직접 사용하는 대신 액세스를 간소화하고 백 엔드에서 클라이언트를 분리할 수 있습니다. 다른 프런트 엔드에 대해 별도의 서비스 백 엔드를 사용하면 서비스가 소비자와 함께 진화할 수 있습니다. 일반적인 서비스는 앰배서더 패턴을 사용하는 일반적인 클라이언트 연결 라이브러리를 포함할 수 있는 별도의 사이드카 컨테이너를 통해 액세스할 수 있습니다.
마이크로 서비스 기반 시스템을 빌드할 때 고려해야 할 디자인 패턴에 대해 자세히 알아봅니다.
Azure Kubernetes Service
AKS(Azure Kubernetes Service)는 호스트된 Kubernetes 환경을 관리하므로 컨테이너 오케스트레이션 전문 지식 없이 컨테이너화된 애플리케이션을 빠르고 쉽게 배포하고 관리할 수 있습니다. 또한 애플리케이션을 오프라인으로 전환하지 않고도 요청 시 리소스를 프로비전, 업그레이드 및 크기 조정하여 지속적인 운영 및 유지 관리의 부담을 덜어줍니다.
AKS는 해당 책임의 상당 부분을 Azure로 오프로드하여 Kubernetes 클러스터 관리의 복잡성과 운영 오버헤드를 줄입니다. 호스트된 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리와 같은 중요한 작업을 처리합니다. 또한 마스터가 아닌 클러스터 내의 에이전트 노드에 대해서만 비용을 지불합니다. AKS는 관리되는 Kubernetes 서비스로 다음을 제공합니다.
- 자동화된 Kubernetes 버전 업그레이드 및 패치.
- 쉬운 클러스터 크기 조정.
- 자체 복구 호스트된 컨트롤 플레인(마스터).
- 비용 절감 - 에이전트 풀 노드를 실행하는 경우에만 비용을 지불합니다.
Azure가 AKS 클러스터의 노드 관리를 처리하면 클러스터 업그레이드와 같은 많은 작업을 수동으로 수행할 필요가 없습니다. Azure는 이러한 중요한 유지 관리 작업을 처리하므로 AKS는 클러스터에 대한 직접 액세스(예: SSH)를 제공하지 않습니다.
AKS를 활용하는 팀은 Azure Dev Spaces를 활용할 수도 있습니다. Azure Dev Spaces는 팀이 AKS에서 실행되는 전체 마이크로 서비스 아키텍처 또는 애플리케이션으로 직접 작업할 수 있도록 하여 팀이 마이크로 서비스 애플리케이션의 개발 및 신속한 반복에 집중할 수 있도록 지원합니다. 또한 Azure Dev Spaces는 AKS 클러스터 또는 다른 개발자의 나머지 부분에 영향을 주지 않고 마이크로 서비스 아키텍처의 일부를 독립적으로 업데이트하는 방법을 제공합니다.
Azure Dev Spaces:
- 로컬 컴퓨터 설정 시간 및 리소스 요구 사항 최소화
- 팀이 더 빠르게 반복할 수 있도록 허용
- 팀에 필요한 통합 환경 수 줄이기
- 개발/테스트 시 분산 시스템에서 특정 서비스를 모의할 필요가 없습니다.
Azure Virtual Machines
App Service에서 실행하기 위해 상당한 수정이 필요한 기존 애플리케이션이 있는 경우 클라우드로의 마이그레이션을 간소화하기 위해 Virtual Machines를 선택할 수 있습니다. 그러나 VM을 올바르게 구성, 보호 및 유지 관리하려면 Azure App Service에 비해 훨씬 더 많은 시간과 IT 전문 지식이 필요합니다. Azure Virtual Machines를 고려하는 경우 VM 환경을 패치, 업데이트 및 관리하는 데 필요한 지속적인 유지 관리 노력을 고려해야 합니다. Azure Virtual Machines는 IaaS(Infrastructure as a Service)이며 App Service는 PaaS입니다. 또한 컨테이너용 웹앱에 Windows 컨테이너로 앱을 배포하는 것이 시나리오에 실행 가능한 옵션이 될 수 있는지 여부를 고려해야 합니다.
논리적 프로세스
애플리케이션의 나머지 부분과 분리할 수 있는 개별 논리 프로세스는 "서버리스" 방식으로 Azure Functions에 독립적으로 배포될 수 있습니다. Azure Functions를 사용하면 애플리케이션 또는 인프라를 실행하지 않고도 지정된 문제에 필요한 코드를 작성할 수 있습니다. C#, F#, Node.js, Python 및 PHP를 비롯한 다양한 프로그래밍 언어 중에서 선택하여 현재 작업에 가장 생산적인 언어를 선택할 수 있습니다. 대부분의 클라우드 기반 솔루션과 마찬가지로 사용 시간에 대해서만 비용을 지불하고 필요에 따라 Azure Functions를 신뢰하여 확장할 수 있습니다.
데이터
Azure는 애플리케이션이 해당 데이터에 적절한 데이터 공급자를 사용할 수 있도록 다양한 데이터 스토리지 옵션을 제공합니다.
트랜잭션, 관계형 데이터의 경우 Azure SQL Database가 가장 좋은 옵션입니다. 고성능 읽기-대부분 데이터의 경우 Azure SQL Database에서 지원되는 Redis 캐시가 좋은 솔루션입니다.
구조화되지 않은 JSON 데이터는 SQL Database 열에서 Azure Storage의 Blob 또는 테이블, Azure Cosmos DB에 이르기까지 다양한 방법으로 저장할 수 있습니다. 이 중 Azure Cosmos DB는 최상의 쿼리 기능을 제공하며 쿼리를 지원해야 하는 많은 수의 JSON 기반 문서에 권장되는 옵션입니다.
애플리케이션 동작을 오케스트레이션하는 데 사용되는 임시 명령 또는 이벤트 기반 데이터는 Azure Service Bus 또는 Azure Storage 큐를 사용할 수 있습니다. Azure Service Bus는 더 많은 유연성을 제공하며 애플리케이션 내 및 애플리케이션 간의 사소한 메시징에 권장되는 서비스입니다.
아키텍처 권장 사항
애플리케이션의 요구 사항은 해당 아키텍처를 결정해야 합니다. 다양한 Azure 서비스를 사용할 수 있습니다. 올바른 것을 선택하는 것은 중요한 결정입니다. Microsoft는 일반적인 시나리오에 최적화된 일반적인 아키텍처를 식별하는 데 도움이 되는 참조 아키텍처 갤러리를 제공합니다. 애플리케이션의 요구 사항에 밀접하게 매핑되거나 적어도 시작점을 제공하는 참조 아키텍처를 찾을 수 있습니다.
그림 11-1은 예제 참조 아키텍처를 보여줍니다. 이 다이어그램에서는 마케팅에 최적화된 Sitecore 콘텐츠 관리 시스템 웹 사이트에 권장되는 아키텍처 방법을 설명합니다.
그림 11-1. Sitecore 마케팅 웹 사이트 참조 아키텍처.
참조 – Azure 호스팅 권장 사항
Azure 솔루션 아키텍처
https://azure.microsoft.com/solutions/architecture/Azure Basic 웹 애플리케이션 아키텍처
https://learn.microsoft.com/azure/architecture/reference-architectures/app-service-web-app/basic-web-app마이크로 서비스에 대한 디자인 패턴
https://learn.microsoft.com/azure/architecture/microservices/design/patternsAzure 개발자 가이드
https://azure.microsoft.com/campaigns/developer-guide/Web Apps 개요
https://learn.microsoft.com/azure/app-service/app-service-web-overview컨테이너용 웹 애플리케이션
https://azure.microsoft.com/services/app-service/containers/AKS(Azure Kubernetes Service) 소개
https://learn.microsoft.com/azure/aks/intro-kubernetes
.NET