Azure 웹 사이트와 Azure 웹 역할의 차이점


241

새로운 Azure 웹 사이트 와 ASP.NET MVC 응용 프로그램의 기존 Azure 웹 역할의 주요 차이점은 무엇입니까 ? "웹 역할"대신 "웹 사이트"를 선택하는 이유는 무엇입니까?

두 경우 모두 (예 : 2 개의 작은 인스턴스) 동일한 용량이 필요하다고 가정 해 봅시다. 웹 사이트가 미리보기 기간 동안 일시적으로 33 % 할인된다는 사실 외에는 가격이 비슷한 것으로 보입니다.

웹 역할로는 어렵거나 불가능한 "웹 사이트"로 할 수있는 일이 있습니까? 예를 들어 "웹 사이트"를 사용하여 여러 웹 사이트를 단일 VM 세트에 쉽게 배치 할 수 있습니까? "웹 사이트"와 "웹 역할"중 어떤 것이라도 손실됩니까? IIS를 미세 조정할 수 있습니까? 캐시 서비스를 로컬로 사용할 수 있습니까?


같은 질문을했습니다. 문서에서 명확하게 설명해야합니다.
90abyss

답변:


213

웹 역할은 웹 응용 프로그램 (이전의 웹 사이트) 이외의 여러 기능을 제공합니다.

  • 승격 된 시작 스크립트를 실행하여 앱 설치, 레지스트리 설정 수정, 성능 카운터 설치, IIS 미세 조정 등의 기능
  • 앱을 티어 (프론트 엔드의 웹 역할, 백엔드 처리의 작업자 역할)로 분할하고 독립적으로 확장하는 기능
  • 디버깅 목적으로 VM에 RDP 기능
  • 네트워크 격리
  • 클라우드 서비스의 웹 역할 인스턴스가 IP 제한 가상 머신에 액세스 할 수 있도록하는 전용 가상 IP 주소
  • ACL 제한 엔드 포인트 (2014 년 4 월 Azure SDK 2.3에 추가됨)
  • 모든 TCP / UDP 포트 지원 (웹 사이트는 TCP 80/443으로 제한됨)

웹 앱은 웹 역할에 비해 다음과 같은 장점이 있습니다.

  • 배포 기록 / 롤백을 통한 거의 즉각적인 배포
  • Visual Studio Online, github, 로컬 git, ftp, CodePlex, DropBox, BitBucket 배포 지원
  • 수많은 CMS 및 프레임 워크 (예 : WordPress, Joomla, Django, MediaWiki 등)를 출시 할 수있는 기능
  • SQL 데이터베이스 또는 MySQL 사용
  • 프리 티어에서 공유 티어, 전용 티어까지 간단하고 빠르게 확장 가능
  • 웹 채용
  • 웹 사이트 컨텐츠 백업
  • 내장 웹 기반 디버깅 도구 (간단한 cmd / powershell 디버그 콘솔, 프로세스 탐색기, 로그 스트리밍과 같은 진단 도구 등)

2014 년 4 월 및 2014 년 9 월 롤아웃을 통해 이제 다음을 포함하여 웹앱 및 웹 역할 (및 작업자 역할)에 공통적 인 기능이 있습니다.

  • 스테이징 + 프로덕션 슬롯
  • 와일드 카드 DNS, SSL 인증서
  • Visual Studio 통합
  • 트래픽 관리자 지원
  • 가상 네트워크 지원

웹 사이트 갤러리 선택 양식에서 가져온 화면 캡처는 다음과 같습니다. 여기에 이미지 설명을 입력하십시오

Web Apps는 공유 리소스에서 예약 된 리소스로 이동할 수있는 빠른 시작 및 실행에 좋은 방법이라고 생각합니다. 이를 능가하면 웹 역할로 이동하여 필요에 따라 확장 할 수 있습니다.


힘내 + 외에 또 다른 큰 하나 (또한 예를 들어 WebMatrix 2에서 사용할 수있는) PublishSettings입니다 FTP
크리스 반 데르 마스트

18
계층으로 나누는 것은 차별화 요소가 아닙니다. 웹 사이트에서 작업자 역할을 사용할 수 있습니다.
RickAndMSFT

4
계층 관련 : 웹 사이트에서는 가상 네트워크를 지원하지 않으므로 웹 사이트를 사용하면 외부 엔드 포인트를 통해 작업자에 연결해야합니다. 또한 코드를 여러 배포 (웹 사이트 용, 클라우드 서비스 용 / 작업자 역할 용)로 나누어야합니다. Cloud Service를 사용하면 코드를 확장 가능한 계층으로 쉽게 분할 한 다음 각 계층간에 내부 통신을 유지하면서 각 계층을 독립적으로 크기와 크기를 조정할 수 있습니다. 이것이 계층을 클라우드 서비스 (웹 / 작업자)의 차별화 요소로 지적 할 때의 의미입니다.
David Makogon

1
이것은 stackoverflow.com/a/10960755/56145 와 비교하여 약간 오래된 버전 입니까?
Matt Kocaj 2016 년

2
웹 역할을 사용하면 동일한 VM에서 백그라운드 처리를 수행 할 수도 있습니다
Boris Lipschitz

44

편집 2014 : 가치있는 것에 대해이 답변의 많은 정보가 더 이상 정확하지 않습니다-의견을 참조하십시오.

@David 응답에 더 추가 :

Windows Azure 웹 사이트를 사용하면 동일한 컴퓨터에서 수백 개의 다른 웹 사이트와 함께 리소스 슬라이스를 사용하고 다른 리소스를 공유하므로 IIS를 제어 할 수 없으므로 IIS 또는 웹 서버를 제어 할 수 없습니다.

웹 사이트 공유와 Azure 웹 역할의 큰 차이점은 웹 사이트는 프로세스 바운드로 간주되고 역할은 VM 바운드입니다.

웹 사이트는 팜의 모든 "웹 서버"에서 액세스 할 수있는 콘텐츠 공유에 저장되므로 복제 또는 이와 유사한 것이 필요하지 않습니다.

윈도우 Azure 웹 사이트 대신 그들이 사용합니다 자신의 호스트 이름을 가질 수 없습니다 웹 사이트 이름 .azurewebsites.net 만 당신은 확실히 그들이 예약 된 모드에서 실행하는 경우에만 이전 윈도우 Azure 역할과 정확히 같은 경로에 DNS 제공 업체에 요청을 CNAME 설정을 사용할 수 있습니다 . 공유 웹 사이트에는 CNAME 설정이 지원되지 않습니다.


AFAIK WebRoles는 자체 호스트 이름을 얻지 못합니다. 모두 rolename.cloudapp.net입니다. 내가 모르는 기능이 없다면?
Brian Reischl

DNS를 사용하여 www.yourdomain.com에서 websitename.azurewebsites.net을 가리키는 CNAME 별칭을 만들 수 없습니까?
Bernard Vander

WA 웹 사이트는 예약 인스턴스 (전용 VM)로 실행되는 앱만 사용자 지정 도메인을 매핑 할 수 있다고 생각합니다.
user94559

scottgu는 최근에 공유 인스턴스에서도 사용자 지정 도메인을 지원하려고한다고 언급했습니다.
jeremy

19
가치가있는 것으로,이 답변의 많은 정보가 더 이상 정확하지 않습니다 (2012 년 6 월에 있었음). 이제 웹 사이트에 사용자 정의 도메인이있을 수 있습니다. 웹 사이트는 본질적으로 VM이지만 완전히 관리되는 "예약 된"모드로 실행될 수 있습니다.
Jay Querido

34

방금 http://robdmoore.id.au/blog/2012/06/09/windows-azure-web-sites-vs-web-roles/ 에이 주제에 대한 포괄적 인 블로그 게시물을 게시했습니다 .

내 결론에서 발췌 : 거대한 규모, SSL, 아시아 또는 미국 서부 데이터 센터, 비표준 구성 (IIS, 포트, 진단, 보안 인증서 또는 시작 스크립트의 구성), RDP 또는 비용 효율적인 작업자 역할 ( 웹 역할과 결합) 지금 당장 웹 역할을 고수해야합니다.

그렇지 않으면 웹 사이트는 훌륭한 옵션입니다!


14

Azure Web Role은 가상 개인 호스트와 같습니다. 웹 서버 역할을하는 VM을 얻고 해당 VM 인스턴스를 소유합니다.

Azure 웹 사이트는 탄력적 인 공유 호스팅 서비스와 같습니다. 귀하가 제어하지 않는 웹 서버 및 다른 사용자의 사이트를 서버로 배포하는 응용 프로그램을 배포합니다. 추가 비용으로 사이트를 확장하거나 축소하여 리소스가 필요할 때 탄력적으로 만들 수 있습니다.


6

대기중인 시나리오가 하나 더 있습니다. 이러한 500 개의 예외가 제거 된 후에도 Azure 웹 사이트가 와일드 카드 CNAME을 처리하는 기능에 대해서는 언급하지 않았습니다. 우리 중 일부는 클라우드 서비스에서 Nate의 Web Role Accelerator를 사용하고 있습니다. Nate의 소프트웨어에서 와일드 카드 하위 도메인 기능을 제공하는 단 한 줄의 핵이되기 때문입니다. Azure 웹 사이트에서 처리 할 수있을 때까지 이러한 와일드 카드 하위 도메인 앱을 이동할 수 없습니다. 그렇게 할 수 없다면 웹 역할 측면에서 긍정적으로 내려갑니다. 또한 미리보기 할인이 만료 된 후 가격이 정확히 동일하기 때문에 RDC 및 이벤트 뷰어에 대한 액세스 권한을 포기하고 싶지는 않습니다 (단 두 가지 언급).


6

Azure 웹 사이트Azure에서 확장 성이 뛰어난 웹 사이트를 빠르게 구축 할 수 있습니다. Azure Portal 또는 명령 줄 도구를 사용하여 .NET, PHP, Node.js 및 Python과 같은 널리 사용되는 언어로 웹 사이트를 설정할 수 있습니다. 지원되는 프레임 워크가 이미 배포되어 있으며 추가 설치 단계가 필요하지 않습니다. Azure 웹 사이트 갤러리에는 Drupal 및 WordPress와 같은 많은 타사 응용 프로그램과 Django 및 CakePHP와 같은 개발 프레임 워크가 포함되어 있습니다. 사이트를 만든 후 기존 웹 사이트를 마이그레이션하거나 완전히 새로운 웹 사이트를 구축 할 수 있습니다. 웹 사이트는 실제 하드웨어를 관리 할 필요가 없으며 몇 가지 확장 옵션도 제공합니다. 공유 다중 테넌트 모델에서 전용 시스템이 들어오는 트래픽을 처리하는 표준 모드로 이동할 수 있습니다. 웹 사이트를 사용하면 다른 Azure 서비스와 통합 할 수 있습니다. SQL 데이터베이스, 서비스 버스 및 스토리지와 같은 Azure WebJobs SDK 미리보기를 사용하면 백그라운드 처리를 추가 할 수 있습니다. 요약하면 Azure 웹 사이트를 통해 광범위한 언어, 오픈 소스 응용 프로그램 및 배포 방법론 (FTP, Git, Web Deploy 또는 TFS)을 지원하여 응용 프로그램 개발에보다 쉽게 ​​집중할 수 있습니다. 클라우드 서비스 또는 가상 머신이 필요한 특수한 요구 사항이없는 경우 Azure 웹 사이트가 가장 적합합니다.

클라우드 서비스풍부한 PaaS (Platform as a Service) 환경에서 고 가용성 및 확장 가능한 웹 애플리케이션을 작성할 수 있습니다. 웹 사이트와 달리 클라우드 서비스는 Azure에 배포되기 전에 Visual Studio와 같은 개발 환경에서 먼저 만들어집니다. PHP와 같은 프레임 워크에는 역할 시작시 프레임 워크를 설치하는 사용자 정의 배포 단계 또는 작업이 필요합니다. 클라우드 서비스의 주요 장점은보다 복잡한 멀티 티어 아키텍처를 지원할 수 있다는 것입니다. 단일 클라우드 서비스는 프론트 엔드 웹 역할과 하나 이상의 작업자 역할로 구성 될 수 있습니다. 각 계층은 독립적으로 확장 될 수 있습니다. 또한 웹 응용 프로그램 인프라에 대한 제어 수준이 향상되었습니다. 예를 들어 역할 인스턴스를 실행중인 시스템에서 원격 데스크톱을 수행 할 수 있습니다.

가상 머신Azure의 가상 컴퓨터에서 웹 응용 프로그램을 실행할 수 있습니다. 이 기능은 IaaS (Infrastructure as a Service)라고도합니다. 포털을 통해 새 Windows Server 또는 Linux 시스템을 작성하거나 기존 가상 시스템 이미지를 업로드하십시오. 가상 머신은 운영 체제, 구성 및 설치된 소프트웨어 및 서비스를 가장 잘 제어합니다. 머신을 전체적으로 이동할 수 있기 때문에 복잡한 온 프레미스 웹 애플리케이션을 클라우드로 빠르게 마이그레이션하는 데 좋은 옵션입니다. 가상 네트워크를 사용하면 이러한 가상 컴퓨터를 온-프레미스 회사 네트워크에 연결할 수도 있습니다. Cloud Services와 마찬가지로 이러한 머신에 원격으로 액세스 할 수 있으며 관리 수준에서 구성 변경을 수행 할 수 있습니다. 그러나 웹 사이트 및 클라우드 서비스와 달리 인프라 수준에서 가상 머신 이미지 및 애플리케이션 아키텍처를 완전히 관리해야합니다. 하나의 기본 예는 운영 체제에 고유 한 패치를 적용해야한다는 것입니다.

이 링크에서 업데이트되고 포괄적 인 비교를 참조하십시오. http://azure.microsoft.com/en-us/documentation/articles/choose-web-site-cloud-service-vm/


4

Azure 웹 사이트, 웹 작업자 및 가상 컴퓨터는 Windows Azure에서 사용할 수있는 세 가지 컴퓨팅 방식입니다. 제어 수준과 책임 수준이 다릅니다.

  • Azure 웹 사이트 는 제어 수준이 가장 낮지 만 Azure 가상 컴퓨터와 IIS를 유지하는 것은 신경 쓰지 않습니다.
  • 웹 역할 은 더 많은 제어 기능 (트래픽 관리자, 원격 데스크톱)을 제공하지만 더 많은 관리가 가능하므로 원격 데스크톱을 통해 무언가를 차단할 수 있습니다.
  • 가상 머신 은 VM을 완벽하게 제어 할 수 있으므로 최대한의 관리 노력이 필요합니다.

필요한 제어 수준, 필요한 기능 및 유지 관리를 위해 Azure 기능을 유지하려는 대상에 따라 최선의 선택은 없습니다. 그리고 그것은 큰 주제입니다 ..

보다 많은 정보를 바탕으로 선택하려면이 기사를 참조하십시오.

사용의 용이성과 기능 간의 절충으로 귀결됩니다.


3

내가 찾은 두 가지 사항은 사용자 지정 도메인 사이트 및 다중 테넌트 구성을위한 SSL을 얻는 비용이었습니다.

웹 사이트의 경우 표준 인스턴스 위에 매달 지불해야합니다 (작은 인스턴스가 가장 저렴한 옵션 임). 이는 사용자 지정 도메인 https를 가져 오려면 작은 인스턴스의 경우 ~ 70 / 월, 모든 브라우저를 지원하는 SSL의 경우 ~ 41 / 월의 비용이 든다는 것을 의미합니다.

WebRole의 경우 XS 인스턴스를 가져 와서 자신의 SSL을 무료로 추가 할 수 있습니다. 이는 매월 ~ 15 달러를 의미하며 SSL이있는 사용자 정의 도메인이 있습니다.

다중 테넌트 웹 사이트의 경우 다중 테넌트 Azure 동적 와일드 카드 CName을 확인하십시오.


1

웹 역할은 여러 웹 사이트를 호스팅하는 가상 머신입니다.


2
정확하지 않습니다. 당신은 할 수 있습니다 웹 역할에서 여러 웹 사이트를 호스팅,하지만 그들은 윈도우 서버 VM을있어 이후 웹의 역할은 훨씬 넘어 간다. 웹 사이트 를 전혀 실행 하지 않고 백그라운드 작업, REST 엔드 포인트, 데이터베이스 서버 등 만 실행 하도록 선택할 수 있습니다 (IIS를 사용할 필요가 없으며 비활성화 할 수도 있음). 그것들은 상태가 없어서 확장하기가 매우 쉽다는 것을 잊지 마십시오.
David Makogon 2016 년

@DavidMakogon 따라서 웹 역할은 실제로 일부 작업을 수행하지만 HTTP 프로토콜을 사용하기 때문에 'WEB'역할이라고하며이 프로토콜을 지원하므로 웹 사이트도 지원하지만 이것이 기본 목표는 아닙니다. 그런가?
Aditya Bokade

@AdityaBokade 자세히 읽어 보지 마십시오. 이름은 Azure가 처음 시작된 시점의 유물입니다. 웹 역할은 외부 애플리케이션을 호스팅하는 유일한 방법 이었습니다. VM이 아닌 웹 애플리케이션이 아님). 웹 (및 작업자) 역할은 코드 및 시작 스크립트를위한 특수 패키징이 포함 된 상태 비 저장 Windows 가상 머신입니다. http를 지원하여 정의되지는 않습니다. http (s), tcp, udp를 통해 외부 리소스와 통신하거나 전혀 아무것도 할 수 없습니다. 그게 전부입니다.
David Makogon

0

이것은 일반적인 질문이며 msdn에서 발췌하고 싶습니다.

캐싱, 서비스 버스, 스토리지, SQL Azure Database-WebSite : Yes WebRole : Yes와 같은 서비스에 액세스

ASP.NET, 클래식 ASP, Node.js, PHP 지원-WebSite : 예 WebRole : 예

공유 컨텐츠 및 구성-WebSite : 예 WebRole : 아니요

GIT, FTP-SiteSite : Yes WebRole : No를 사용하여 코드 배포

거의 즉각적인 배포 -WebSite : 예 WebRole : 아니요

통합 MySQL 서비스로 지원 -WebSite : Yes WebRole : Yes

다중 배포 환경 (생산 및 준비) -WebSite : No WebRole : Yes

네트워크 격리-웹 사이트 : 웹롤 없음 : 예

서버에 대한 원격 데스크톱 액세스 -WebSite : No WebRole : Yes

높은 권한으로 프로그램을 실행하는 기능 -WebSite : No WebRole : Yes

시작 작업 정의 / 실행 기능 -WebSite : No WebRole : Yes

지원되지 않는 프레임 워크 또는 라이브러리를 사용하는 기능 -WebSite : No WebRole : Yes

Windows Azure Connect / Windows Azure Network-WebSite : No WebRole : Yes 지원

자세한 내용을 보려면 다음 링크를 방문하십시오. http://blogs.msdn.com/b/silverlining/archive/2012/06/27/windows-azure-websites-web-roles-and-vms-when-to -use-which.aspx

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.