Azure App Service Plan: 웹앱을 실행하는 핵심 인프라 개념 이해하기

Azure App Service는 Azure에서 제공하는 웹 애플리케이션, API, 백엔드 서비스를 쉽게 배포하고 관리할 수 있도록 도와주는 PaaS(Platform as a Service) 솔루션입니다. Azure App Service 에서 Web App 을 생성하게 되면 다음과 같이 Pricing plan을 선택해야 합니다.

Choosing the right pricing plan for web app

Azure App Service 를 처음 사용하거나 익숙하지 않은 사람이 이 개념이 다소 헷갈릴 수 있습니다.
예를, 들어 다음 의문이 생길 수 있습니다.

• "S1 App Service Plan으로 1개의 Worker Instance에서 3개의 Web App을 실행하면, 각각 독립된 서버에서 실행되는 걸까? 아니면 같은 리소스를 공유하는 걸까?"
• "하나의 Web App이 많은 트래픽을 사용하면, 같은 Plan의 다른 Web App도 영향을 받을까?"
• "웹앱이 여러 개 필요하면 App Service Plan도 여러 개 만들어야 할까?"
• "App Service를 만들 때마다 App Service Plan도 새로 생성해야 하는 걸까?"

이 글에서는 이러한 의문을 해결하기 위해서 App Service Plan이 무엇인지, Web App과 어떤 관계를 가지고, 운영 환경에서 어떻게 활용할 수 있는지를 단계비별로 살펴보겠습니다.
 

1. App Service Plan이란?

App Service Plan은 웹 애플리케이션을 실행하기 위한 컴퓨팅 리소스(Worker)와 확장성(Scaling)을 결정하는 논리적 단위로, 같은 Plan에 속한 모든 웹앱이 동일한 리소스(CPU, RAM, Storage)를 공유하는 방식으로 동작합니다.

App Service Plan Overview

하나의 App Service Plan을 생성하면 해당 Plan 내에서 여러 개의 Web App을 배포할 수 있으며, 모든 Web App은 같은 Plan의 서버(Worker) 자원을 나누어 사용합니다. 따라서 같은 Plan 내에서 Web App이 많아질수록 리소스 사용량이 증가하며, 적절한 확장 전략이 필요합니다.
App Service Plan은 하드웨어 리소스를 추상화한 개념으로, 사용자는 직접 가상머신을 생성하거나 설정할 필요 없이 웹 애플리케이션을 배포할 수 있습니다.

2. App Service Plan의 장점

2.1 비용 절감 및 효율적인 리소스 활용

Web App마다 하나의 별도 가상머신에서 실행한다면, 트래픽이 적은 Web App의 경우에도 VM을 사용하므로 자원이 낭비됩니다. 뿐만 아니라 관리의 복잡성도 증가됩니다.
App Service Plan에서는 Web App이 동일한 컴퓨팅 리소스를 공유하므로 불필요한 가상머신 비용을 줄이고 유휴 리소스를 최소화 할 수 있습니다.

2.2 운영 및 확장의 단순화

Web App이 개별적으로 가상머신을 사용하면, 트래픽이 증가 시 각각의 Web App을 별도로 확장해야 합니다. 만약 Web App이 10개라면 10개의 가상환경을 각각 확장해야하므로 운영 부담이 크게 됩니다. 
App Service Plan에서 Scale Out을 수행하면, 해당 Plan 내의 모든 Web App이 확장됩니다. 개별 Web App이 아닌 Plan 단위로 Worker를 추가하므로 전체적으로 성능을 높일 수 있습니다. 이 경우 로드 밸런싱은 자동으로 이루어지므로 운영자는 Web App별로 확장을 고민할 필요가 없습니다.

2.3 관리 효율성 극대화

Web App이 개별적으로 가상머신을 사용하면, Web App이 많아질수록 가상머신 개수도 증가하여 업데이트, 모니터링, 배포 작업이 번거로울 수 있습니다.
App Service Plan에서는 Plan내에 모든 Web App을 통합 관리 할 수 있습니다. Web App이 많이지더라도 하나의 Plan을 관리한 것만흐로 효율적인 관리가 가능합니다.
 

3. App Service Plan에서 SKU(Stock Keeping Unit)란?

3.1 SKU란?

App Service Plan을 생성할 때 SKU(Stock Keeping Unit)을 선택해야 합니다. SKU는 App Service Plan의 성능, 확장성, 기능을 결정하는 요소로, 사용자는 비용과 성능을 고려하여 적절한 SKU를 선택해야합니다.

App Service Pricing Plan

3.2 SKU가 App Service 에 미치는 영향

SKU가 App Service Plan에 미치는 영향은 다음과 같습니다. 즉 SKU에 따라서 App Service Plan의 성능과 기능이 달라지므로, Web App의 운영 목적에 맞는 SKU를 선택하는 것이 중요합니다.

요소	설명
Worker 크기	SKU에 따라 CPU, RAM 크기가 달라짐
Worker 수(Scale Out)	SKU에 따라 확장 가능한 Worker 개수가 다름
자동 확장(Auto Scale)	일부 SKU는 자동 확장을 지원
VNet 통합	Premium 이상의 SKU에서 VNet 통합 가능
커스텀 도메인 및 SSL 지원	Standard 이상에서 가능
Dedicated vs. Shared vs. Isolated	일부 SKU는 멀티 테넌트, 일부는 전용 환경 제공

 

3.3 SKU의 종류

App Service Plan의 SKU는 무료/공유형, 기본형, 표준형, 프리미엄형, 고급(격리형) 등 여러 가지가 있다.
각 SKU별 특징을 정리하면 다음과 같다.

SKU	유형설명	크기 & 확장성	주요 기능
Free (F1)	무료 플랜	1개 Worker, 확장 불가	실험 및 테스트 용도
Shared (D1)	여러 사용자와 공유	1개 Worker, 확장 불가	매우 제한적인 리소스
Basic (B1, B2, B3)	기본적인 웹앱 운영	최대 3개 Worker	사용자 지정 도메인 가능
Standard (S1, S2, S3)	프로덕션 운영 가능	최대 10개 Worker	Auto Scale, 스테이징 슬롯 지원
Premium (P1V2, P2V2, P3V2)	성능 최적화된 서비스	최대 20개 Worker	VNet 통합, 고성능 SSD 지원
Isolated (I1, I2, I3)	전용 환경 (App Service Environment, ASE)	최대 100개 Worker	완전한 네트워크 격리 제공

 

3.4 SKU 선택 가이드

사용자 입장에서 SKU는 비용과 직접적으로 연관되어 있기 때문에 Web App의 트래픽 규모, 성능 요구 사항, 보안 요구 사항에 따라 적절한 SKU를 선택하는 것이 중요합니다.
다음 표는 Web App의 유형에 따른 적절한 SKU를 정리한 표이다.

애플리케이션 유형	추천 SKU	이유
개인 프로젝트, 실험용	Free (F1), Shared (D1)	비용 절감, 최소한의 리소스
소규모 블로그, 기업 웹사이트	Basic (B1, B2)	커스텀 도메인 사용 가능
중소 규모 서비스	Standard (S1, S2)	Auto Scale 지원, 프로덕션 운영 가능
대규모 트래픽 서비스	Premium (P1V2, P2V2)	높은 성능, SSD, VNet 통합 가능
금융, 보안 요구 사항 높은 서비스	Isolated (I1, I2)	네트워크 격리, 전용 환경 제공

 

4. App Service Architecture 관점에서 App Service Plan

지난 포스팅에서 App Service Architecture 에 대해서 살펴보았습니다. 여기에서는 App Service Plan을 Architecture 관점에서 분석하며 Web App과의 관계, Worker와의 관계, 확장방식에 대해서 알아보도록 하겠습니다.

4.1 App Service Plan과 Web App과의 관계

App Service Plan과 Web App은 플랫폼과 애플리케이션의 관계와 유사합니다. App Service Plan은 Web App이 실핼될 컴퓨팅 리소스 (CPU, RAM, Storage 등)을 정의하는 개념이고, Web App은 App Service Plan에서 실행되는 실제 애플리케이션입니다. 즉 App Service Plan이 없으면 Web App을 만들 수 없습니다. 같은 App Service Plan 내에는 여러 개의 Web App을 실행 할 수 있습니다.
 
다음 예제를 살펴보도록 하겠습니다.
예제 1) 하나의 App Service Plan에서 여러개의 Web App 실행

App Service Plan (B1)	Web App
appserviceplan-1 (B1)	webapp-1
appserviceplan-1 (B1)	webapp-2
appserviceplan-1 (B1)	webapp-3

appserviceplan-1 (B1) hosting three web apps

모든 Web App이 같은 plan에서 실행되므로 같은 자원을 공유합니다. 만약 하나의 Web App이 많은 리소스를 사용하면 같은 Plan 내의 다른 Web App 성능에도 영향을 줄 있습니다.
 
예제 2) Web App을 다른 App Service Plan에 배포한 경우

App Service Plan	Web App
appserviceplan-prod (P0v3)	webapp-prod
appserviceplan-dev (B1)	webapp-dev

appserviceplan-prod (P0v3) for production and appserviceplan-dev (B1) for development

운영 환경과 개발 환경을 분리하여 각각 다른 App Service Plan에서 실행됩니다. 각 환경의 Web App이 독립적인 리소스를 사용하므로, 서로 영향을 주지 않습니다
 

4.2. App Service Plan과 Worker의 관계

여기까지 설명을 들으면 App Service Plan과 Worker가 동일한가? 라는 생각을 갖을 수 있을 것입니다. 하지만 App Service Plan은 Worker를 포함하는 개념으로 동일 개념은 아닙니다. 위에서 이야기했듯이 App Service Plan은 Web App이 실행될 컴퓨팅 리소스를 정의하는 논리적인 단위이며, Worker는 Web App이 실행되는 가상 머신 또는 컨테이너 환경입니다. 지난 포스팅에서 App Service Architecture에 대해서 살펴보았습니다. 이번에는 이를 바탕으로 App Service 에서 App Service Plan과 Worker의 관계를 알아보겠습니다. 이제  다음예제를 통해서 Azure에서 App Service Plan이 생성시 Worker가 할당 과정을 살펴보도록 하겠습니다.

App Service Architecture

Scale Unit은 App Service의 물리적인 배포 단위로, 특정 Azure Region내에서 여러개가 존재 할 수 있습니다. Scale Unit내에 Windows, Linux에 따라 SKU별로 Worker Pool이 존재합니다.
 
appserviceplan-1이라는 App Service Plan을 생성하고 app-1이라는 Web App을 배포한다고 가정해보겠습니다. Web App을 배포하기 전에는 무조건 App Service Plan을 생성해야 합니다. 생성시에는 OS, SKU를 설정해야합니다.
App Service Plan 생성은 Azure Portal, Azure CLI, Powershell 등을 통해 가능합니다.
다음은 Azure CLI를 이용해서 app service plan을 생성하는 명령어입니다.

az appservice plan create --name appserviceplan-1 \
 --resource-group resourcegroup-1 \
 --sku B1

resourcegroup-1 containing appserviceplan-1 (B1) which hosts app-1

App Service Plan을 생성하면 Azure는 Scale Unit내의 해당 OS 및 SKU를 지원하는 Worker를 선택하게 됩니다.

App Service Architecture - app-1 is running on Worker-1

 추가로 appserviceplan-1에 app-2를 배포하면 다음과 같습니다.

resourcegroup-1 containing appserviceplan-1 (B1) which hosts two applications, app-1 and app-2

기존 app-1이 동작하던 Worker-1에 app-2도 동작하게 됩니다.
아래 그림과 같이 Worker-1 내부에 app-1, app2가 배치된 것을 알 수 있습니다. app-1과 app-2는 Worker-1의 자원을 서로 공유하게 됩니다.

App Service Architecture - app-1 and app-2 are running on Worker-1

 

4.3 App Service Plan의 Scale UP

App Service Plan의 Scale Up은 SKU 변경하는 방식으로 동작합니다. 이를 통해 더 높은 성능의 가상머신으로 변경할 수 있습니다.
App Service Plan의 SKU 변경은 Azure Portal, Azure CLI, Powershell 등을 통해 가능합니다.
다음은 기존 예제에서 Azure CLI를 이용하여 SKU를 변경한 예시입니다.

az appservice plan update --name appserviceplan-1 \
--resource-group resourcegroup-1 \
--sku P0v3

resourcegroup-1 containing appserviceplan-1 (P0v3) which hosts two applications, app-1 and app-2

SKU를 변경하게 되면 해당 SKU의 Worker를 선택하게 됩니다. 아래 그림에서 보자면 P0v3 SKU의 Woker-3에서 app-1, app-2가 실행되는 것을 확인 할 수 있습니다.

App Service Architecture - Worker-3 hosts app-1 and app-2

Scale Up은 더 성능이 좋은 Worker로 교체하는 방식으로, 트래픽이 크게 증가하지 않는 환경에서 성능을 향상하는데 적합한 방법입니다.

4.4 App Service Plan의 Scale Out

App Service Plan의 Scale Out은 Worker 개수를 늘리는 방식으로 동작합니다. 이를 통해 부하를 여러 Worker에 분산할 수 있습니다.
다음은 기존 예제 Azure CLI를 이용하여 Worker 수를 변경한 예시입니다.

az appservice plan update --name appserviceplan-1 \
--resource-group resourcegroup-1 \
--sku B1
--number-of-workers 2

Two workers in appserviceplan-1 (B1), each hosting app-1 and app-2

Worker 를 추가하게 되면 기존 SKU의 Worker를 추가로 선택하게 됩니다. 아래 그림에서 보자면 B1 SKU의 Woker-2에서 app-1, app-2가 실행되는 것을 확인 할 수 있습니다.

App Service Architecture - app-1 and app-2 are running on Worker-1 and Worker-2

Scale Out을 하는 경우 Worker의 성능은 변하지 않지만 Worker의 개수가 증가하여 더 많은 트래픽을 처리 할 수 있습니다. 이는 트래픽이 급증하는 경우 부하는 분산처리하여 성능을 향상하는데 적합한 방법입니다.
 

5. 결론

이 글에서는 Azure App Service Plan이 무엇인지, 그리고 Web App 및 Worker와의 관계를 단계별로 살펴보았습니다.
App Service Plan은 웹 애플리케이션을 실행하기 위한 컴퓨팅 리소스와 확장성을 결정하는 논리적 단위이며, 같은 Plan에 속한 Web App들은 동일한 리소스(CPU, RAM, Storage)를 공유한다는 특징이 있습니다. 이를 통해 비용을 절감하고 관리 효율성을 높일 수 있지만, 한 Web App이 과도한 리소스를 사용하면 같은 Plan 내의 다른 Web App 성능에도 영향을 줄 수 있습니다.
또한, App Service Plan의 SKU(Stock Keeping Unit) 선택은 성능, 확장성, 기능 지원 여부를 결정하는 중요한 요소입니다. SKU에 따라 사용 가능한 Worker 크기, 확장 가능한 Worker 수, 자동 확장(Auto Scale) 지원 여부, VNet 통합 기능 등이 달라집니다. 따라서 서비스의 특성과 요구 사항에 맞는 SKU를 선택하는 것이 중요합니다.
App Service Plan은 Scale Up(더 높은 성능의 VM으로 변경) 및 Scale Out(Worker 수 증가) 두 가지 확장 방식을 지원하며, 이를 활용하면 성능을 높이거나 트래픽 증가에 대응할 수 있습니다. 특히, Scale Out을 사용하면 여러 Worker에 부하를 분산할 수 있어 대규모 트래픽을 처리하는 데 유리합니다.
결론적으로, App Service Plan은 Azure에서 Web App을 효율적으로 배포하고 운영하기 위한 핵심 요소이며, 적절한 리소스 설계와 확장 전략을 통해 최적의 성능과 비용 효율성을 확보할 수 있습니다. 이 글에서 다룬 개념들을 바탕으로, 실무에서 App Service Plan을 보다 효과적으로 활용하는 데 도움이 되길 바랍니다.

 
참고자료
https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans

App Service plans - Azure App Service

https://itnerd.space/2016/10/28/azure-app-service-architecture-1/

Azure App Service Architecture (1)