App Service 개요

Azure App Service는 웹 애플리케이션, REST API 및 모바일 백 엔드를 호스트하는 HTTP 기반 서비스입니다. .NET, .NET Core, Java, Ruby, Node.js, PHP 또는 Python 등 원하는 언어로 개발할 수 있습니다. Windows 및 Linux 기반 환경에서 애플리케이션을 쉽게 실행하고 확장할 수 있습니다.

App Service는 보안, 부하 분산, 자동 크기 조정 및 자동화된 관리와 같이 Microsoft Azure의 강력한 기능을 애플리케이션에 추가합니다. 또한 Azure DevOps, GitHub, Docker 허브 및 기타 원본, 패키지 관리, 스테이징 환경, 사용자 지정 도메인 및 TLS/SSL 인증서의 지속적인 배포와 같은 DevOps 기능도 활용할 수 있습니다.

App Service를 사용하면 Azure 컴퓨팅 리소스에 대한 비용을 지불하게 됩니다. 사용할 컴퓨팅 리소스는 앱을 실행하는 App Service 계획에 따라 결정됩니다. 자세한 내용은 Azure App Service 계획 개요를 참조하세요.

App Service를 사용하는 이유는 무엇인가요?

Azure App Service는 개발자를 위한 완전 관리형 PaaS(Platform as a Service) 제품입니다. App Service의 주요 기능은 다음과 같습니다.

  • 여러 언어 및 프레임워크 - App Service는 ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP 또는 Python에 대한 고급 지원을 제공합니다. PowerShell 및 기타 스크립트 또는 실행 파일을 백그라운드 서비스로 실행할 수도 있습니다.
  • 관리형 프로덕션 환경 - App Service는 OS 및 언어 프레임워크를 자동으로 패치하고 유지 관리합니다. 뛰어난 앱을 작성하고 Azure에서 플랫폼에 대해 걱정할 수 있습니다.
  • 컨테이너화 및 Docker - 앱을 Dockerize하고 App Service에서 사용자 지정 Windows 또는 Linux 컨테이너를 호스트합니다. Docker Compose를 사용하여 다중 컨테이너 앱을 실행합니다. Docker 기술을 App Service로 직접 마이그레이션합니다.
  • DevOps 최적화 - Azure DevOps, GitHub, BitBucket, Docker 허브 또는 Azure Container Registry를 사용하여 연속 통합 및 배포를 설정합니다. 테스트 및 스테이징 환경을 통해 업데이트를 승격합니다. Azure PowerShell 또는 플랫폼 간 CLI(명령줄 인터페이스)를 사용하여 App Service에서 앱을 관리합니다.
  • 고가용성을 가진 글로벌 규모 조정 - 수동 또는 자동으로 규모를 강화 또는 확장합니다. Microsoft의 글로벌 데이터 센터 인프라의 모든 위치에서 앱을 호스팅하고 App Service SLA 를 사용하면 고가용성이 보장됩니다.
  • SaaS 플랫폼 및 온-프레미스 데이터에 연결 - 엔터프라이즈 시스템(예: SAP), SaaS 서비스(예: Salesforce) 및 인터넷 서비스(예: Facebook)를 위해 50개 이상의 커넥터에서 선택합니다. 하이브리드 연결Azure Virtual Networks를 사용하여 온-프레미스 데이터에 액세스합니다.
  • 보안 및 규정 준수 - App Service는 ISO, SOC 및 PCI 규격입니다. Azure Active Directory, Google, Facebook, Twitter 또는 Microsoft 계정으로 사용자를 인증합니다. IP 주소 제한을 만들고 서비스 ID를 관리합니다.
  • 애플리케이션 템플릿 - Azure Marketplace(예: WordPress, Joomla 및 Drupal)의 광범위한 애플리케이션 템플릿 목록에서 선택합니다.
  • Visual Studio와 Visual Studio Code 통합 - Visual Studio 및 Visual Studio Code의 전용 도구는 생성, 배포, 디버깅 작업을 간소화합니다.
  • API 및 모바일 기능 - App Service는 RESTful API 시나리오에 대한 턴키 방식 CORS 지원을 제공하며, 인증, 오프라인 데이터 동기화, 푸시 알림 등을 활성화하여 모바일 앱 시나리오를 간소화합니다.
  • 서버리스 코드 - 인프라를 명시적으로 프로비전하거나 관리하지 않고도 요청 시에 코드 조각이나 스크립트를 실행하고, 코드에서 실제로 사용하는 컴퓨팅 시간에 대해서만 비용을 지불합니다(Azure Functions 참조).

Azure는 App Service 뿐만 아니라 웹 사이트와 웹 애플리케이션 호스팅에 사용할 수 있는 다른 서비스를 제공합니다. 대부분의 시나리오의 경우 App Service를 사용하는 것이 좋습니다. 마이크로 서비스 아키텍처의 경우 Azure Spring 앱 또는 Service Fabric을 사용하는 것이 좋습니다. 코드가 실행되는 VM을 보다 정밀하게 제어해야 하는 경우 Azure Virtual Machines를 사용하는 것이 좋습니다. 이러한 Azure 서비스 중에서 하나를 선택하는 방법에 대한 자세한 내용은 Azure App Service, Virtual Machines, 서비스 패브릭 및 Cloud Services 비교를 참조하세요.

Linux의 App Service

App Service는 지원되는 애플리케이션 스택에 대해 기본적으로 Linux에서 웹앱을 호스트할 수도 있습니다. 사용자 지정 Linux 컨테이너(컨테이너용 웹앱이라고도 함)를 실행할 수도 있습니다.

기본 제공 언어 및 프레임워크

Linux의 App Service는 다양한 언어별 기본 제공 이미지를 지원합니다. 코드를 배포하기만 하면 됩니다. 지원되는 언어에는 Node.js, Java(8, 11 및 17), Tomcat, PHP, Python, .NET Core 및 Ruby가 있습니다. az webapp list-runtimes --os linux를 실행하여 최신 언어 및 지원되는 버전을 확인합니다. 애플리케이션에 필요한 런타임이 기본 제공 이미지에서 지원되지 않는 경우 사용자 지정 컨테이너를 사용하여 배포할 수 있습니다.

오래된 런타임은 포털의 Web Apps 만들기 및 구성 블레이드에서 정기적으로 제거됩니다. 이러한 런타임은 유지 관리 조직에서 사용을 중단하거나 심각한 취약성이 발견될 경우 포털에서 숨겨집니다. 고객에게 가장 도움이 되는 최신 런타임으로 고객을 안내할 수 있도록 이러한 옵션은 숨겨져 있습니다.

오래된 런타임이 포털에서 숨겨지더라도 해당 버전을 사용하는 모든 기존 사이트는 계속 실행됩니다. Azure 구독 소유자는 런타임이 App Service 플랫폼에서 완전히 제거되기 전에 이메일 알림을 받게 됩니다.

포털에서 더 이상 표시되지 않는 오래된 런타임 버전을 사용하여 또 다른 웹앱을 만들어야 하는 경우 언어 구성 가이드에서 사이트의 런타임 버전을 받는 방법에 대한 지침을 참조하세요. Azure CLI를 사용하여 동일한 런타임으로 또 다른 사이트를 만들 수 있습니다. 또는 포털의 웹앱 블레이드에서 템플릿 내보내기 단추를 사용하여 사이트의 ARM 템플릿을 내보낼 수 있습니다. 이 템플릿을 다시 사용하여 런타임과 구성이 동일한 새 사이트를 배포할 수 있습니다.

Debian 9 수명 종료

2022년 6월 30일에 Debian 9("Stretch"라고도 함)가 EOL(End-of-Life) 상태에 도달하여 보안 패치와 업데이트가 중단됩니다. 2022년 6월부터 Debian 11("Bullseye"라고도 함)로의 업그레이드 경로를 제공하기 위해 플랫폼 업데이트가 출시됩니다. 아래 나열된 런타임은 현재 Debian 9를 사용하고 있습니다. 나열된 런타임 중 하나를 사용하는 경우 아래 지침에 따라 사이트를 Bullseye로 업그레이드합니다.

  • Python 3.8
  • Python 3.7
  • .NET 3.1
  • PHP 7.4

참고

고객 애플리케이션이 안전하고 지원되는 Debian 배포판에서 실행되도록 2023년 2월 이후에 Debian 9(Stretch)에서 여전히 실행 중인 모든 Linux 웹앱은 자동으로 Debian 11(Bullseye)로 업그레이드됩니다.

플랫폼 업데이트 확인

먼저 Debian 11이 포함된 새 플랫폼 업데이트가 사이트에 도달했는지 유효성 검사합니다.

  1. 웹앱의 SCM 사이트(Kudu 사이트라고도 함)로 이동합니다. http://<your-site-name>.scm.azurewebsites.net/Env에서 이 사이트를 탐색할 수 있습니다(\<your-site-name>을 웹앱 이름으로 바꿈).
  2. "환경 변수"에서 PLATFORM_VERSION을 검색합니다. 이 환경 변수의 값은 웹앱의 현재 플랫폼 버전입니다.
  3. PLATFORM_VERSION 값이 "99" 이상으로 시작하면 사이트가 최신 플랫폼 업데이트에 있는 것이며 아래 섹션으로 계속 진행할 수 있습니다. 값이 "99" 이상으로 표시되지 않으면 사이트가 아직 최신 플랫폼 업데이트를 받지 못한 것입니다. 나중에 다시 확인하세요.

다음으로, 프로덕션에 변경 내용을 적용하기 전에 애플리케이션이 Debian 11에서 제대로 작동하는지 테스트하는 배포 슬롯을 만듭니다.

  1. 아직 없는 경우 배포 슬롯을 만들고 프로덕션 슬롯에서 설정을 복제합니다. 배포 슬롯을 사용하면 애플리케이션의 변경 내용(예: Debian 11로 업그레이드)을 안전하게 테스트하고 검토 후 해당 변경 내용을 프로덕션으로 전환할 수 있습니다.

  2. Debian 11(Bullseye)로 업그레이드하려면 ORYX_DEFAULT_OS라는 이름의 슬롯에 값이 bullseye인 앱 설정을 만듭니다.

    az webapp config appsettings set -g MyResourceGroup -n MyUniqueApp --settings ORYX_DEFAULT_OS=bullseye
    
  3. 선택한 도구(VS Code, Azure CLI, GitHub Actions 등)를 사용하여 배포 슬롯에 애플리케이션을 배포합니다.

  4. 애플리케이션이 배포 슬롯에서 예상대로 작동하는지 확인합니다.

  5. 프로덕션 슬롯과 스테이징 슬롯을 바꿉니다. 이렇게 하면 ORYX_DEFAULT_OS=bullseye 앱 설정이 프로덕션에 적용됩니다.

  6. 더 이상 사용하지 않는 배포 슬롯을 삭제합니다.

리소스

제한 사항

참고

Linux 및 Windows App Service 요금제는 이제 리소스 그룹을 공유할 수 있습니다. 이 제한은 플랫폼에서 해제되었으며 기존 리소스 그룹은 이를 지원하도록 업데이트되었습니다.

  • Linux의 App Service는 공유 가격 책정 계층에서 지원되지 않습니다.
  • Azure Portal에는 현재 Linux 앱에서 작동하는 기능만 표시됩니다. 기능이 활성화되면 포털에서 활성화됩니다.
  • 기본 제공 이미지에 배포된 경우 코드 및 콘텐츠에는 Azure Storage에서 지원하는 웹 콘텐츠용 스토리지 볼륨이 할당됩니다. 이 볼륨의 디스크 대기 시간은 컨테이너 파일 시스템의 대기 시간보다 높고 더 많은 변수가 있습니다. 콘텐츠 파일에 대한 많은 읽기 전용 액세스를 필요로 하는 앱은 콘텐츠 볼륨 대신 파일 시스템에 파일을 배치하는 사용자 지정 컨테이너 옵션의 이점을 누릴 수 있습니다.

다음 단계

첫 번째 웹앱을 만듭니다.