수동으로 웹앱 크기 조정
수동으로 규모를 확장한 후 다시 감축하면 예상되는 트래픽 증가 및 감소에 대응할 수 있습니다. 스케일 아웃은 웹앱의 인스턴스 수가 늘어나므로 가용성이 향상되는 추가적인 이점이 있습니다. 즉 한 인스턴스가 실패해도 웹앱은 계속 사용할 수 있습니다.
호텔 예약 시스템에서는 예상되는 계절적 유입이 발생하기 전에 규모 확장할 수 있습니다. 시즌이 끝나고 예약 요청 수가 줄면 다시 규모 감축할 수 있습니다.
이 단원에서는 웹앱을 수동으로 스케일 아웃하고 다시 스케일 인하는 방법을 알아봅니다.
App Service 계획 및 확장성
Azure에서 실행되는 웹앱은 일반적으로 Azure App Service를 사용하여 호스팅 환경을 제공합니다. App Service는 실행할 웹앱의 여러 인스턴스를 정렬할 수 있습니다. App Service는 이러한 인스턴스에서 들어오는 요청의 부하를 분산합니다. 각 인스턴스는 가상 머신에서 실행됩니다.
App Service 요금제는 각 인스턴스에 사용할 수 있는 리소스를 정의합니다. App Service 계획은 운영 체제(Windows 또는 Linux), 하드웨어(메모리, CPU 처리 용량, 디스크 스토리지 등) 및 서비스의 가용성(예: 자동 백업 및 복원)을 지정합니다.
Azure에서는 일련의 잘 정의된 App Service 계획 계층을 제공합니다. 아래 목록에는 각 계층이 용량 및 비용의 오름차순으로 요약되어 있습니다.
- 체험 계층은 1GB의 디스크 공간을 제공하고 최대 10개의 앱을 지원하지만, 하나의 공유 인스턴스만 제공되며 가용성 SLA는 없습니다. 각 앱에 대한 일일 컴퓨팅 할당량은 60분입니다. 체험 서비스 플랜은 프로덕션 배포보다는 앱 개발 및 테스트에 적합합니다.
- 공유 계층은 단일 공유 인스턴스에서 더 많은 앱(최대 100개)을 실행할 수 있도록 지원합니다. 앱의 컴퓨팅 할당량은 하루 240분입니다. 가용성 SLA는 없습니다.
- 기본 계층은 앱을 개수에 제한 없이 제공하고 더 많은 디스크 공간을 제공합니다. 앱이 세 개의 전용 인스턴스로 규모 확장할 수 있습니다. 이 계층은 99.95% 가용성 SLA를 제공합니다. 이 계층에는 다양한 크기의 컴퓨팅 성능, 메모리 및 디스크 스토리지를 제공하는 세 가지 수준이 있습니다.
- 표준 계층은 앱을 무제한으로 지원합니다. 이 계층은 최대 10개의 전용 인스턴스로 크기 조정할 수 있으며, 가용성 SLA는 99.95%입니다. 기본 계층과 마찬가지로, 이 계층에는 더 강력한 컴퓨팅, 메모리 및 디스크 옵션 세트를 제공하는 세 가지 수준이 있습니다.
- 프리미엄 계층은 최대 20개의 전용 인스턴스, 99.95% 가용성 SLA 및 여러 수준의 하드웨어를 제공합니다.
- 격리 계층은 전용 Azure 가상 네트워크에서 실행되며, 네트워크 및 컴퓨팅 격리가 제공됩니다. 이 계층은 최대 100개의 인스턴스로 규모 확장할 수 있으며, 가용성 SLA는 99.95%입니다.
참고
일부 계층은 일부 운영 체제에서만 사용할 수 있습니다. 예를 들어 Linux에 대한 공유 계층은 현재 사용할 수 없습니다.
웹앱 모니터링 및 크기 조정
웹앱을 만들 때 새 App Service 계획을 만들거나 기존 계획을 사용할 수 있습니다. 기존 플랜을 선택하면 동일한 계획을 사용하는 다른 웹앱에서 해당 웹앱과 리소스를 공유합니다. 모든 웹앱이 동시에 스케일링되므로 동일한 스케일링 요구 사항이 필요합니다. 앱의 요구 사항이 서로 다르면 각 앱마다 별도의 App Service 계획을 사용합니다.
선택한 계층에서 사용할 수 있는 최대 제한까지 인스턴스를 App Service 계획에 추가하여 규모 확장합니다. 무료 계층을 사용하지 않는 경우 요금은 각 인스턴스에 대해 시간 단위로 부과됩니다. 이 작업은 Azure Portal에서 수행할 수 있습니다.
효과적으로 크기를 조정하는 작업의 핵심은 조정의 시기와 크기를 파악하는 것입니다. App Service에서 사용할 수 있는 메트릭을 통해 웹앱의 성능을 모니터링합니다. 이 작업을 수행하는 가장 간단한 방법은 Azure Portal을 사용하는 것입니다.
CPU 사용률, 메모리 점유율 또는 디스크 큐 길이와 같이 리소스의 사용이 꾸준히 증가하는 것으로 나타나면 메트릭이 중요한 지점에 도달하기 전에 크기 확장을 사용해야 합니다. 또한 요청의 평균 응답 시간 및 실패한 요청 수도 모니터링해야 합니다. 이러한 두 수치가 모두 높으면 시스템이 용량에 가깝거나 초과하여 실행되고 있을 수 있습니다. 이 경우 즉시 규모 확장해야 할 수도 있습니다.
메트릭에서 시스템에 부하가 적고 예비 용량이 충분하다고 표시되면 비용을 줄이기 위해 다시 규모 감축하는 것이 좋습니다.
두 경우 모두에서 웹앱에 대한 통계를 계속 모니터링해야 합니다. 시스템이 안정되도록 합니다. 메트릭에서 앱 성능이 여전히 부족하거나 초과한다고 표시되면 필요에 따라 인스턴스를 추가하거나 제거합니다.