이번 장에서는 Azure 컴퓨팅에 대한 개념에 대해서 알아보자.
Azure 컴퓨팅이란?
Azure 계산은 클라우드 기반 어플리케이션을 실행하기 위한 주문형 컴퓨팅 서비스다. 가상 머신 및 컨테이너를 통해 멀티코어 프로세서, 슈퍼컴퓨터 등의 컴퓨팅 리소스를 제공한다. 인프라 설정 또는 구성이 필요하지 않고 앱을 실행하는 서버리스 컴퓨팅도 제공한다. 리소스는 요청시 제공되며, 일반적으로 수분 또는 수초 이내에 만들 수 있다. 사용한 리소스에 대해 사용 기간 동안의 요금만 지불하면 된다.
Azure에서 컴퓨팅을 수행하는 일반적인 기술에는 아래 4가지가 있다.
- 가상머신
- 컨테이너
- Azure App Service
- 서버리스 컴퓨팅
가상머신이란?
가상머신 또는 VM이라고도 한다. 이는 물리적 컴퓨터의 소프트웨어 에뮬레이션으로, VM에는 가상 프로세서, 메모리, 스토리지 및 네트워킹 리소스가 포함된다. (즉, 이를 소프트웨어 차원에서 돌리는 것!) 운영체제를 호스트하며, 물리적 컴퓨터처럼 소프트웨어를 설치하고 실행할 수 있다. 또한 원격 데스크톱 클라이언트를 사용하여, 실제처럼 가상 머신을 사용하고 제어할 수 있다.
컨테이너란?
컨테이너는 어플리케이션을 실행하기 위한 가상화 환경이다. 가상머신과 마찬가지로, 컨테이너는 호스트 운영 체제에서 실행된다. 그러나 VM과 달리 컨테이너에는 컨테이너 내부에서 실행되는 앱의 운영체제가 포함되지 않는다. 대신, 컨테이너에는 어플리케이션을 실행하고 컨테이너를 실행하는 기존 호스트 OS를 사용하는데 필요한 라이브러리와 구성 요소를 포함한다. 예를들어, 특정 리눅스 커널이 있는 서버에서 컨테이너를 5개 실행하는 경우, 컨테이너 5개와 그 안에 있는 앱 모두 동일한 리눅스 커널을 공유한다.
Azure App Service란?
Azure App Service는 엔터프라이즈급 웹 기반 어플리케이션을 호스트하도록 설계된 Azure의 PaaS(Platform as a Service) 제품이다. 완전 관리형 플랫폼을 사용하여 인프라 유지 관리를 수행하는 동안 엄격한 성능, 확장성, 보안 및 규정 준수 요구 사항을 충족할 수 있다.
서버리스 컴퓨팅이란?
서버리스 컴퓨팅은 코드를 실행하는, 클라우드에 호스트된 실행 환경이지만 기본 호스팅 환경을 완전히 추상화하는 것을 말한다. 서비스 인스턴스를 만들고 코드를 추가하기만 하면 된다. 인프라 구성 또는 유지 관리가 필요하지 않으나 허용되지 않는다.
Azure Virtual Machines 살펴보기
Azure VM을 사용ㅇ하여 클라우드에서 가상머신을 만들고 사용할 수 있다. 이 서비스는 IaaS(서비스 제공 인프라)를 가상화된 서버 형식으로 제공하며 다양한 방법으로 사용될 수 있다. 물리적 컴퓨터처럼 가상 머신에서 실행되는 모든 소프트웨어를 사용자 지정할 수 있다. 가상머신은 보통 아래와 같은 경우에 사용한다.
- OS 제어
- 사용자 지정 소프트웨어 실행 기능
- 사용자 지정 호스팅 구성을 사용하는 경우
Azure VM은 VM을 실행하는 실제 하드웨어를 구입 및 유지 관리하지 않고도 가상화의 유연성을 제공한다. 하지만 VM을 계속 유지관리 해야하며, VM에서 실행되는 소프트웨어를 구성하고 업데이트하는 것도 계속 관리해주어야 한다.
미리 구성된 가상 머신 이미지를 선택하면 짧은 시간 안에 가상머신을 만들고 프로비저닝할 수 있다. 이미지를 선택하는 일은 가상머신을 만들 때 필요한 가장 중요한 결정 사항중 하나다. 이미지는 가상 머신을 만드는데 사용되는 템플릿으로, 이러한 템플릿에는 OS와 종종 개발 도구나 웹 호스팅 환경과 같은 기타 소프트웨어가 이미 포함되어 있다.
가상머신을 사용해야하는 경우 예시
- 테스트 및 개발 도중
- 클라우드에서 어플리케이션을 실행하는 경우
- 데이터 센터를 클라우드로 확장하는 경우
- 재해 복구 도중
가상 머신을 사용하여 클라우드로 이동
가상 머신은 실제 서버에서 클라우드로 이동할때도 굳. 물리적 서버의 이미지를 만들고 거의 또는 전혀 변경할 필요 없이 가상 머신 내에서 호스트할 수 있다. 물리적 온프레미스 서버와 마찬가지로 VM을 유지, 관리해야 한다. 설치된 OS 및 해당 OS를 실행하는 소프트웨어를 업데이트한다.
Azure에서 VM 크기 조정
테스트, 개발 또는 보조 작업용으로 단일 가상 머신을 실행하거나 가상 머신을 함께 그룹화하여 고가용성, 확장성 및 중복성을 제공할 수 있다. Azure에는 작동시간 요구사항과 관계없이 Azure에서 이를 충족할 수 있는 여러 기능이 있다. 기능은 아래와 같다.
- 가용성 집합
- Virtual Machine Scale Sets
- Azure Batch
가용성 집합이란?
가용성 집합은 계획되거나 계획되지 않은 유지 관리 중에 어플리케이션을 계속 사용할 수 있도록 하는 두 개 이상의 가상 머신이 포함된 논리 그룹이다.
“계획된 유지 관리 이벤트”는 가상머신을 호스트하는 기본 Azure 패브릭이 Microsoft에서 업데이트 되는 경우다. 계획된 유지관리 이벤트는 보안 취약성을 패치하고, 성능을 향상하고, 기능울 추가하거나 업데이트 하기 위해 수행된다. 대부분의 경우 이러한 업데이트는 게스트 가상 머신에 영향을 주지 않고 수행된다. 하지만 업데이트를 완료하기 위해 가상 머신을 다시 부팅해야 하는 경우가 있다. 가상 머신이 가용성 집합에 포함되는 경우 Azure 패브릭은 연결된 모든 가상머신이 동시에 다시 부팅되지는 않도록 업데이트 순서가 지정되었는지 확인한다. 가상머신은 다른 ‘업데이트 도메인’에 배치된다. 업데이트 도메인은 동시에 다시 부팅할 수 있는 가상 머신 그룹과 기본 물리적 하드웨어를 나타낸다. 업데이트 도메인은 각 데이터 센터의 논리적 파트이고 소프트웨어 및 논리를 통해 구현된다.
‘계획되지않은 유지관리 이벤트’에는 데이터 센터의 하드웨어 오류가 포함된다. (예. 정전 또는 디스크 오류) 가용성 집합의 일부인 가상 머신은 자동으로 작동중인 물리적 서버로 전환되어 가상 머신이 계속 실행된다. 일반적인 하드웨어를 공유하는 가상 머신 그룹은 동일한 ‘장애 도메인’에 포함된다. 장애 도메인은 기본적으로 서버 렉이다. 이 도메인은 데이터 센터 서버렉의 물리적 서버를 지원하는 여러 다른 전원, 냉각 및 네트워크 하드웨어에서 워크로드를 물리적으로 구분한다. 서버 렉을 지원하는 하드웨어를 사용할 수 없게 되면 해당 서버 렉만 가동 중단의 영향을 받는다.
가용성 집합을 사용하면 다음이 제공된다.
- 각각의 전용 전원 및 네트워크 리소스가 있는 서버 렉을 포함하는 최대 3개의 장애 도메인
- 최대 20개까지 늘릴 수 있는 5개의 논리 업데이트 도메인
그러면 가상 머신이 장애 및 업데이트 도메인에 순차적으로 배치된다. 아래 그림은 2개의 가용성 집합에 있는 6개 가상머신이 2개의 장애 도메인과 5개의 업데이트 도메인에 분산된 예제를 보여준다.
가용성 집합에 대한 비용은 없다. 가용성 집합 내 가상 머신에 대해서만 요금이 부과된다. 가상 머신 아키텍처에 단일 실패 지점이 없도록 각 워크로드를 가용성 집합에 배치하는 것이 좋다.
Virtual Machine Scale Sets란?
Azure Virtual Machine Scale Sets를 사용하면 부하 분산된 동일한 가상 머신 그룹을 만들고 관리할 수 있다. 가상머신을 복제할 경우 일반적으로 웹사이트 가상 머신의 여러 인스턴스 간에 요청을 라우팅하는 추가 서비스를 구성해야 하는데, virutal machine scale sets는 이러한 작업을 자동으로 수행한다.
Scale Sets를 사용하면 몇 분 안에 많은 수의 가상머신을 중앙에서 관리, 구성 및 업데이트 하므로 고가굥성 어플리케이션을 제공할 수 있다. VM 인스턴스의 수는 요구 또는 정의된 일정에 따라 자동으로 늘리거나 줄일 수 있다. virtual machine scale sets를 사용하면 컴퓨팅, 빅데이터 및 컨테이너 작업과 같은 영역에 대한 대규모 서비스를 구축살 수 있다.
Azure Batch란?
Azure Batch를 통해 수십, 수백 또는 수천개의 가상머신으로 확장할 수 있을 뿐 아니라 대규모 작업을 예약하고 컴퓨팅을 관리할 수 있다. 작업을 실행할 준비가 된 경우, batch에서 다음 작업을 수행한다.
- 컴퓨팅 가상 머신 풀을 시작한다
- 어플리케이션 설치 및 준비 데이터를 설치
- 사용자의 여러 태스크를 포함하는 작업 실행
- 오류 식별
- 작업을 큐에 다시 대기
- 작업이 완료되면 풀을 축소
Azure에서 컨테이너 살펴보기
단일 호스트 머신에서 어플리케이션의 여러 인스턴스를 실행하려는 경우 컨테이너를 사용하는 것이 좋다. 컨테이너 오케스트레이터는 필요에 따라 어플리케이션 인스턴스를 시작, 중지, 확장할 수 있다.
컨테이너는 수정된 런타임 환경으로 어플리케이션을 실행하는 호스트 OS 위에 빌드된다. 컨테이너는 가상화를 사용하지 않으므로 중복 OS를 사용하여 가상 하드웨어를 시뮬레이션 하면서 리소스를 낭비하지 않는다. 이 환경에서 일반적으로 컨테이너가 VM보다 가볍다. 이 설계를 사용하여 요청 또는 실패시 변경 내용에 신속하게 대응할 수 있다. 컨테이너의 또 다른 이점은 단일 컨테이너 호스트에서 여러 개의 격리된 어플리케이션을 실행할 수 있다는 것이다. 컨테이너는 보안이 설정되고 격리되므로 각 앱에 별도의 서버가 필요하지 않는다.
Azure의 컨테이너
Azure는 Docker 컨테이너(표준화된 컨테이너 모델)를 지원하고 Azure에서 컨테이너를 관리하는 다양한 방법이 있다.
- ACI(Azure Container Instances)
- AKS(Azure Kubernetes Service)
Azure Container Instances (ACI)
ACI는 Azure에서 컨테이너를 실행하는 가장 빠르고 쉬운 방법이다. 가상 머신을 관리하거나 추가 서비스를 구성할 필요가 없다. 컨테이너를 업로드하고 자동 탄력적 확장을 통해 직접 실행할 수 있는 PaaS 제품이다.
Azure Kubernetes Service (AKS)
많은 컨테이너를 자동화, 관리 및 상호 작용하는 작업을 오케스트레이션이라고 한다. AKS는 여러 컨테이너가 있는 분산 아키텍처를 사용하는 완벽한 컨테이너용 오케스트레이션 서비스다.
솔루션에서 컨테이너 사용
컨테이너는 종종 마이크로서비스 아키텍처를 사용하여 솔루션을 만드는데 사용된다. 이 아키텍처에서 솔루션을 더 작고 독립적인 조각으로 분할할 수 있다. 예를들어, 웹사이트를 프론트엔드를 호스팅하는 컨테이너, 백엔드를 호스트하는 컨테이너 및 스토리지용 컨테이너로 분할할 수 있다. 분할 후에는 앱을 논리적 섹션으로 구분하여 독립적으로 유지관리, 확장 또는 업데이트할 수 있다.
컨테이너로 앱 마이그레이션
기존 어플리케이션을 컨테이너로 이동하고 AKS 내에서 이를 실행할 수 있다. Azure AC(Azure Active Directory) 및 엑세스 SLA(서비스 수준 약정) 지원 Azure 서비스(예: 데이터 요구에 대한 Azure Database for MySQL)와의 통합을 통해 OSBA(Open Service Broker for Azure)를 통해 액세스를 제어한다.
- 기존 어플리케이션을 하나 이상의 컨테이너로 변환한 다음 하나 이상의 컨테이너 이미지를 Azure Container Registry에 게시한다.
- Azure Portal 또는 명령줄을 사용하여 컨테이너를 AKS 클러스터에 배포한다.
- Azure AD는 AKS 리소스에 대한 액세스를 제어한다.
- OSBA를 통해 SLA 지원 Azure 서비스 (Azure Database for MySQL)에 액세스한다.
- 또는 AKS가 가상 네트워크를 사용하여 배포된다.
Azure App Service 살펴보기
Azure App Service를 사용하면 인프라를 관리할 필요 없이 선택한 프로그래밍 언어로 웹앱, 백그라운드 작업, 모바일 백엔드 및 RESTful API를 빌드하고 호스트할 수 있다. 자동 확장 기능과 고가용성을 제공한다. App Service는 Windows 및 Linux를 모두 지원하며, Github, Azure DevOps 또는 Git 레포지토리에서 자동화된 배포를 사용하여 지속적인 배포 모델을 지원한다.
이 PaaS(Platform as a Service)를 사용하면 Azure가 웹 어플리케이션을 실행하고 크기를 조정하기 위한 인프라를 처리하는 동안 웹사이트 및 API 논리에 초점을 맞출 수 있다.
App Service 비용
선택한 App Service 계획에 따라 요청을 처리하는 동안 앱에서 사용하는 Azure 컴퓨팅 리소스에 대한 요금을 지급한다. App Service 계획에 따라 호스트에 할당된 하드웨어의 양(예: 전용 또는 공유 하드웨어인지 여부 및 호스트용으로 예약된 메모리의 양)이 결정된다. 작고 트래픽이 적은 사이트를 호스트하는 데 사용할 수 있는 무료 계층도 있다.
웹앱 형식
Azure App Service를 사용하면 다음과 같은 일반적인 웹앱스타일을 호스트할 수 있다.
- Web Apps
- API Apps
- WebJobs
- Mobile Apps
Azure App Service는 웹앱 호스트시 결정해야 하는 대부분의 인프라 관련 사항을 처리한다. 배포와 관리 기능이 플랫폼에 통합되고, 엔드포인트에 보안이 설정되고, 높은 트래픽 부하를 처리하기 위해 사이트를 빠르게 확장할 수 있고, 기본 제공 부하 분산 및 Traffic Manager가 고가용성을 제공한다. 이러한 모든 앱 스타이른 동일한 인프라에 호스트되고, 이러한 이점을 공유한다. 이와 같은 유연성으로 App Service는 웹기반 어플리케이션을 호스트하는데 적합하다.
웹앱
App Service는 ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP 또는 Python을 사용하는 웹앱 호스팅이 전체 지원된다. Windows 또는 Linux를 호스트 운영 체제로 선택할 수 있다.
API 앱
웹 사이트를 호스팅하는 것처럼 원하는 언어 및 프레임워크를 사용하여 REST 기반 웹 API를 빌드할 수 있다 .전체 Swagger 지원과 함께 Azure Marketplace에서 API를 패키지 및 게시하는 기능을 사용할 수 있다 .생성된 앱은 HTTP 기반 클라이언트에서 사용할 수 있다.
WebJobs
WebJobs를 사용하면 웹앱, API 앱 또는 모바일 앱과 동일한 컨텍스트에서 프로그램 또는 스크립트를 실행할 수 있다. 프로그램과 스크립트는 트리거를 통해 예약하거나 실행할 수 있다. WebJobs는 종종 어플리케이션 로직의 일부로 백그라운드 작업을 실행하는 데 사용된다.
모바일 앱 백엔드
Azure App Service의 Mobile Apps 기능을 사용하여 iOS 및 Android 앱의 백엔드를 빠르게 빌드할 수 있다.
- 클라우드 기반 SQL 데이터베이스에 모바일 앱 데이터 저장
- MSA, Google, Twitter 및 Facebook과 같은 일반적인 소셜 공급 기업에 대해 고객 인증
- 푸시 알림 보내기
- C# 또는 Node.js에서 사용자 지정 백엔드 논리 실행
모바일 앱의 경우 네이티브 iOS/Android, Xamarin 및 React 네이티브 앱을 위한 SDK 지원이 제공된다.
Azure의 서버리스 컴퓨팅 살펴보기
서버리스 컴퓨팅은 서버, 인프라 및 OS를 추상화 한 것을 말한다. Azure에서는 서버리스 컴퓨팅을 통해 서버 인프라 관리 및 수요에 따른 리소스 할당/해제를 처리한다. 인프라는 크기 조정 및 성능이 자동으로 처리되며, 사용하는 리소스에 대해서만 요금이 청구된다.
서버리스 컴퓨팅은 세가지 아이디어를 포함한다.
- 서버의 추상화 : 서버리스 컴퓨팅은 실행하는 서버를 추상화한다. 서버 인스턴스를 명시적으로 예약하지 않는 대신, 플랫폼에서 이를 관리한다. 각 함수 실행은 다른 컴퓨팅 인스턴스에서 실행될 수 있으며, 이 실행 컨텍스트는 코드에 투명하다. 서버리스 아키텍처를 통해 고가용성으로 실행되는 코드를 간단하게 배포한다.
- 이벤트 기반 크기 조정 : 서버리스 컴퓨팅은 예정된 이벤트에 응답하는 워크로드에 대해 매우 적합하다. 이벤트에는 타이머, 대기열 등을 통해 수행되는 트리거가 포함된다. 전체 어플리케이션을 작성하는 대신 개발자는 함수를 작성하고, 함수에는 트리거 및 바인딩에 관한 코드 및 메타데이터 모두가 포함된다. 플랫폼은 자동으로 함수 실행을 예약하고 예정된 이벤트의 비율에 따라 컴퓨팅 인스턴스의 수를 조정한다. 트리거는 함수가 호출되는 방식을 정의하고, 바인딩은 코드 내에서 서비스에 연결하는 선언적 방법을 제공한다.
- 마이크로 청구 : 기존의 컴퓨팅에는 초당 청구 방식이 있지만 유용하지 않은 경우가 있다. 고객의 웹사이트에서 하루에 한번만 방문하는 경우에도 일일 가용성 전체에 대해 지불하게 된다. 서버리스 컴퓨팅을 사용하면 코드에 실행되는 시간에 대해서만 비용을 지불한다. 활성 함수 실행이 발생하지 않는 경우 요금이 부과되지 않는다. 예를들어, 코드가 하루에 한번 2분동안 실행되는 경우 실행 1회와 컴퓨팅 시간 2분에 대해 요금이 부과된다.
Azure에는 다음과 같은 두가지 서버리스 컴퓨팅 구현이 있다.
- Azure Functions 거의 모든 최신 언어로 코드를 실행할 수 있다.
- Azure Logic Apps 웹기반 디자이너에서 설계되며 코드를 작성하지 않고 Azure 서비스에서 트리거한 논리를 실행할 수 있다.
Azure Functions
기본 플랫폼 인프라가 아닌 서비스를 실행하는 코드에 관해서만 관심이 있는 경우에 Azure Functions를 사용하는 것이 이상적이다. Azure Fuctions는 REST 요청, 타이머 또는 다른 Azure 서비스로부터 받은 메세지를 통해 이벤트에 대한 응답으로 작업을 수행해야 하는 경우, 그리고 해당 작업을 수초 이내에 빠르게 완료할 수 있는 경우에 주로 사용된다.
Azure Functions는 수요에 따라 자동으로 크기가 조정되므로 수요가 가변적일 때 좋은 선택이다. 예를 들어 배달 차량을 모니터링 하는 데 사용되는 IoT 솔루션으로부터 메세지를 받을 수 있다. 이 경우 업무 시간 중에 더 많은 데이터가 도착할 가능성이 크다.
VM 기반 접근 방식을 사용하면 VM이 유휴상태인 경우에도 비용이 부과된다. Azure Functions를 사용하면 함수가 트리거되는 때 코드를 실행하고 함수가 완료될 때 자동으로 리소스를 할당 해제한다. 이 모델에서는 함수가 실행되는 동안 사용되는 CPU 시간에 대한 요금만 부과한다.
또한 Azure Functions는 이벤트에 응답할 때 마다 다시 시작되는 것처럼 동작하는 경우 상태 비저장(기본값) 또는 함수를 통해 컨텍스트가 전달되어 이전 활동을 추적하는 경우 상태 저장(“Durable Functions”라고 함)일 수 있다.
함수는 서버리스 컴퓨팅의 핵심 요소지만, 모든 코드 형식을 실행하기 위한 일반 계산 플랫폼이기도 하다. 개발자의 앱을 변경해야 하는 경우 서버리스가 아닌 환경에 프로젝트를 배포할 수 있으므로, 유연하게 크기 조정을 관리하고 가상 네트워크에서 실행하고, 함수를 완전히 격리할 수도 있다.
Azure Logic Apps
Azure Logic Apps는 Functions와 비슷하고, 둘 다 이벤트에 따라 논리를 트리거할 수 있다. Functions가 코드를 실행하는 경우 Logic Aoos는 비즈니스 시나리오를 자동화 하도록 설계되고 미리 정의된 논리 블록에서 빌드된 ‘워크플로’를 실행한다. 모든 논리 앱 워크플로는 특정 이벤트가 발생하거나 사용 가능한 새 데이터가 특정 기준을 충족할 때 실행되는 트리거를 통해 시작된다. 워크로드가 주기적으로 실행되는 빈도를 개발자가 지정할 수 있도록 많은 트리거가 기본적인 일정 예약 기능을 제공한다. 트리거가 실행될 때마다 Logic Apps 엔진은 워크플로의 작업을 실행하는 논리 앱 인스턴스를 만든다. 또한 이러한 작업에는 조건부 명령문, 전환 명령문, 루프, 분기 등의 데이터 변환 및 흐름 컨트롤이 포함될 수 있다.
Azure Portal 또는 Visual Studio 에서 비주얼 디자이너를 사용하여 Logic App 워크플로를 만든다. 워크플로는 알려진 워크플로 스키마를 사용하여 json 파일로 지속된다.
Azure는 가장 인기 있는 엔터프라이즈 앱을 비롯한 다양한 서비스를 조작할 수 있는 200개가 넘는 다양한 커넥터 및 처리 블록을 제공한다. 조작해야 하는 서비스가 포함되지 않는 경우 사용자 지정 커넥터 및 워크플로 단계를 빌드할 수도 있다. 그런 다음 비주얼 디자이너를 통해 커넥터와 블록을 함께 연결하여 사용자 지정 처리를 수행하는 워크플로를 통해 데이터를 전달한다. 이러한 작업은 보통 코드 작성 없이 이루어진다.
Functions 및 Logic Apps
Functions 및 Logic Apps는 둘 다 복잡한 오케스트레이션을 만들 수 있습니다. 오케스트레이션은 복잡한 작업을 수행하기 위해 실행되는 함수 또는 단계의 모음입니다. Azure Functions에서는 각 단계를 완료하는 코드를 작성하고, Logic Apps에서는 GUI를 사용하여 작업을 정의하고 작업이 서로 어떻게 관련되는지 정의합니다.
오케스트레이션을 빌드할 때 논리 앱에서 함수를 호출하고 함수에서 논리 앱을 호출하여 서비스를 적절하게 맞출 수 있습니다. 두 항목의 몇 가지 일반적인 차이점은 다음과 같습니다.
시스템 상태 | 일반적으로 상태 비저장이지만 Durable Functions가 상태를 제공함 | 상태 저장 |
개발 | 코드 중심(명령적) | 디자이너 중심(선언적) |
연결 | 약 12가지의 기본 제공 바인딩 형식 정보, 사용자 지정 바인딩에 대한 코드 작성 | 대규모의 커넥터 컬렉션, B2B 시나리오용 엔터프라이즈 통합 팩, 사용자 지정 커넥터 빌드 |
작업 | 각 작업은 Azure 함수입니다. 작업 함수에 대한 코드 작성 | 즉시 사용 가능한 작업의 대규모 컬렉션 |
모니터링 | Azure Application Insights | Azure Portal, Log Analytics |
관리 | REST API, Visual Studio | Azure Portal, REST API, PowerShell, Visual Studio |
실행 컨텍스트 | 로컬로 또는 클라우드에서 실행 가능 | 클라우드에서만 실행합니다. |
출처 : https://docs.microsoft.com/ko-kr/learn/modules/intro-to-azure-compute/