Azure App Service의 운영 체제 기능

이 문서에서는 Azure App Service에서 실행되는 모든 Windows 앱에서 사용할 수 있는 기준 운영 체제 기능에 대해 설명합니다. 이 기능에는 진단 로그 및 이벤트와 함께 파일, 네트워크 및 레지스트리 액세스가 포함됩니다.

App Service 계획 계층

App Service는 다중 테넌트 호스팅 환경에서 고객 앱을 실행합니다.

• 무료 및 공유 계층에 배포된 앱은 공유 VM(가상 머신)의 작업자 프로세스에서 실행됩니다.
• 표준 및 프리미엄 계층에 배포된 앱은 단일 고객과 연결된 앱 전용 VM에서 실행됩니다.

App Service는 계층 간에 원활한 크기 조정 환경을 지원하므로 App Service 앱에 적용되는 보안 구성은 동일하게 유지됩니다. 이 구성은 App Service 계획이 한 계층에서 다른 계층으로 전환할 때 앱이 갑자기 다르게 동작하지 않고 예기치 않은 방식으로 실패하도록 합니다.

개발 프레임워크

App Service 가격 책정 계층은 앱에서 사용할 수 있는 컴퓨팅 리소스(CPU, 디스크 스토리지, 메모리 및 네트워크 송신)의 양을 제어합니다. 그러나 앱에서 사용할 수 있는 프레임워크 기능의 폭은 크기 조정 계층에 관계없이 동일하게 유지됩니다.

App Service는 ASP.NET, 클래식 ASP, Node.js, PHP 및 Python을 비롯한 다양한 개발 프레임워크를 지원합니다. 보안 구성을 단순화하고 정규화하기 위해 App Service 앱은 일반적으로 기본 설정으로 개발 프레임워크를 실행합니다. 플랫폼이 제공하는 프레임워크 및 런타임 구성 요소는 보안 및 규정 준수 요구 사항을 충족하도록 정기적으로 업데이트됩니다. 이러한 이유로 특정 부 버전 또는 패치 버전을 보장하지는 않습니다. 고객은 필요에 따라 주 버전을 대상으로 하는 것이 좋습니다.

다음 섹션에서는 App Service 앱에서 사용할 수 있는 일반적인 종류의 운영 체제 기능을 요약합니다.

파일 액세스

App Service 내에는 로컬 드라이브 및 네트워크 드라이브를 비롯한 다양한 드라이브가 있습니다.

로컬 드라이브

핵심인 App Service는 Azure PaaS(Platform as a Service) 인프라를 기반으로 실행되는 서비스입니다. 따라서 VM과 연결된 로컬 드라이브는 Azure에서 실행되는 모든 작업자 역할에 사용할 수 있는 것과 동일한 드라이브 유형입니다. 다음을 포함합니다.

• VM 크기에 따라 크기가 달라지는 운영 체제 드라이브(%SystemDrive%)입니다.
• App Service에서 내부적으로 사용하는 리소스 드라이브(%ResourceDrive%)입니다.

가장 좋은 방법은 하드 코딩된 파일 경로 대신 항상 환경 변수 %SystemDrive%%ResourceDrive% 를 사용하는 것입니다. 이러한 두 환경 변수에서 반환된 루트 경로는 시간이 d:\c:\지남에 따라 이동되었습니다. 그러나 App Service가 d:\을 d:\로 자동으로 다시 매핑하기 때문에 파일 경로 참조로 하드 코딩된 이전 애플리케이션은 계속 작동합니다. 앞에서 설명한 것처럼 파일 경로를 빌드할 때 항상 환경 변수를 사용하고 기본 루트 파일 경로에 대한 플랫폼 변경에 대한 혼동을 방지하는 것이 좋습니다.

애플리케이션이 증가함에 따라 디스크 사용률을 모니터링하는 것이 중요합니다. 디스크 할당량에 도달하면 애플리케이션에 부정적인 영향을 미칠 수 있습니다. 다음은 그 예입니다.

• 앱에서 디스크에 공간이 충분하지 않음을 나타내는 오류가 발생할 수 있습니다.
• Kudu 콘솔로 검색할 때 디스크 오류가 표시될 수 있습니다.
• Azure DevOps 또는 Visual Studio의 배포가 ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk) 실패할 수 있습니다.
• 앱의 성능이 저하될 수 있습니다.

네트워크 드라이브(UNC 공유)

앱 배포 및 유지 관리를 간단하게 만드는 App Service의 고유한 측면 중 하나는 모든 콘텐츠 공유가 UNC(유니버설 명명 규칙) 공유 집합에 저장된다는 것입니다. 이 모델은 부하 분산된 서버가 여러 대 있는 온-프레미스 웹 호스팅 환경에서 사용하는 콘텐츠 스토리지의 일반적인 패턴에 잘 매핑됩니다.

App Service 내에서 UNC 공유는 각 데이터 센터에 만들어집니다. 각 데이터 센터의 모든 고객에 대한 사용자 콘텐츠의 백분율이 각 UNC 공유에 할당됩니다. 각 고객의 구독에는 데이터 센터의 특정 UNC 공유에 대한 예약된 디렉터리 구조가 있습니다. 고객은 특정 데이터 센터에서 여러 앱을 만들 수 있으므로 단일 고객 구독에 속하는 모든 디렉터리를 동일한 UNC 공유에 만듭니다.

Azure 서비스가 작동하는 방식 때문에 UNC 공유 호스팅을 담당하는 특정 VM은 시간이 지남에 따라 변경됩니다. UNC 공유는 Azure 운영의 일반적인 과정 동안 상승 및 축소되므로 다른 VM에 의해 탑재됩니다. 이러한 이유로 앱은 UNC 파일 경로의 컴퓨터 정보가 시간이 지남에 따라 안정적으로 유지된다는 하드 코딩된 가정을 해서는 안 됩니다. 대신 App Service에서 제공하는 편리한 가짜 절대 경로를 %HOME%\site 사용해야 합니다.

가상의 절대 경로는 사용자 자신의 앱을 참조하기 위한 범용적인 방법입니다. 앱 또는 사용자에 한정되지 않습니다. 각 전송에 대한 %HOME%\site새 절대 경로를 구성하지 않고도 공유 파일을 앱에서 앱으로 전송할 수 있습니다.

앱에 부여된 파일 액세스 유형

%HOME% 앱의 디렉터리가 해당 앱 전용 Azure Storage의 콘텐츠 공유에 매핑됩니다. 가격 책정 계층은 크기를 정의합니다. 콘텐츠, 오류 및 진단 로그와 같은 디렉터리와 소스 제어에서 만든 이전 버전의 앱이 포함될 수 있습니다. 이러한 디렉터리를 읽기 및 쓰기 액세스를 위해 런타임에 앱의 애플리케이션 코드에 사용할 수 있습니다. 파일이 로컬로 저장되지 않으므로 앱이 다시 시작될 때 지속됩니다.

시스템 드라이브에서 App Service는 앱별 임시 로컬 스토리지를 예약합니다 %SystemDrive%\local . 이 디렉터리의 파일에 대한 변경 내용은 앱 다시 시작에서 지속 되지 않습니다 . 앱에는 자체 임시 로컬 스토리지에 대한 전체 읽기 및 쓰기 액세스 권한이 있지만 해당 스토리지는 애플리케이션 코드에서 직접 사용하기 위한 것이 아닙니다. 대신 IIS 및 웹 애플리케이션 프레임워크에 대한 임시 파일 스토리지를 제공하기 위한 것입니다.

App Service는 개별 앱이 %SystemDrive%\local 과도한 양의 로컬 파일 스토리지를 사용하지 못하도록 각 앱에 대한 스토리지 양을 제한합니다. 무료, 공유 및 소비(Azure Functions) 계층의 경우 제한은 500MB입니다. 다음 표에서는 다른 계층을 나열합니다.

임시 ASP.NET 파일의 디렉터리와 IIS 압축 파일의 디렉터리가 App Service에서 임시 로컬 스토리지를 사용하는 방법의 두 가지 예입니다. ASP.NET 컴파일 시스템은 디렉터리를 임시 컴파일 캐시 위치로 사용합니다 %SystemDrive%\local\Temporary ASP.NET Files . IIS는 %SystemDrive%\local\IIS Temporary Compressed Files 디렉터리를 사용하여 압축된 응답 출력을 저장합니다. 이러한 유형의 파일 사용량(다른 사용자와 함께)은 App Service에서 앱별 임시 로컬 스토리지로 다시 매핑됩니다. 이 다시 매핑은 기능이 예상대로 계속되도록 하는 데 도움이 됩니다.

App Service의 각 앱은 애플리케이션 풀 ID라는 임의의 고유하고 낮은 권한의 작업자 프로세스 ID로 실행됩니다. 애플리케이션 코드는 운영 체제 드라이브에 대한 기본 읽기 전용 액세스에 이 ID를 사용합니다. 이 액세스는 애플리케이션 코드가 공용 디렉터리 구조를 나열하고 운영 체제 드라이브에서 공통 파일을 읽을 수 있음을 의미합니다. 이 수준의 액세스는 광범위해 보일 수 있지만 Azure 호스팅 서비스에서 작업자 역할을 프로비전하고 드라이브 콘텐츠를 읽을 때 동일한 디렉터리와 파일에 액세스할 수 있습니다.

여러 인스턴스에 대한 파일 액세스

콘텐츠 공유(%HOME%) 디렉터리에는 애플리케이션의 콘텐츠가 포함되며, 애플리케이션 코드는 이 디렉터리에 쓸 수 있습니다. 앱이 여러 인스턴스에서 실행되는 경우 모든 인스턴스 %HOME% 가 동일한 디렉터리를 볼 수 있도록 디렉터리가 모든 인스턴스 간에 공유됩니다. 예를 들어 앱이 업로드된 파일을 %HOME% 디렉터리에 저장하는 경우 해당 파일은 모든 인스턴스에서 즉시 사용할 수 있습니다.

임시 로컬 스토리지(%SystemDrive%\local) 디렉터리가 인스턴스 간에 공유되지 않습니다. 또한 앱과 Kudu 앱 간에 공유되지 않습니다.

네트워크 액세스

애플리케이션 코드는 TCP/IP 및 UDP 기반 프로토콜을 사용하여 외부 서비스를 노출하는 인터넷에 액세스할 수 있는 엔드포인트에 아웃바운드 네트워크 연결을 만들 수 있습니다. 앱은 Azure SQL Database에 대한 HTTPS 연결을 설정하여 이러한 동일한 프로토콜을 사용하여 Azure 내의 서비스에 연결할 수 있습니다.

또한 앱이 하나의 로컬 루프백 연결을 설정하고 앱이 해당 로컬 루프백 소켓에서 수신 대기하도록 하는 제한된 기능도 있습니다. 이 기능을 사용하면 기능의 일부로 로컬 루프백 소켓에서 수신 대기하는 앱을 사용할 수 있습니다. 각 앱에는 프라이빗 루프백 연결이 있습니다. 한 앱은 다른 앱이 설정한 로컬 루프백 소켓을 수신 대기할 수 없습니다.

명명된 파이프는 앱을 총체적으로 실행하는 프로세스 간의 프로세스 간 통신을 위한 메커니즘으로도 지원됩니다. 예를 들어 IIS FastCGI 모듈은 명명된 파이프를 사용하여 PHP 페이지를 실행하는 개별 프로세스를 조정합니다.

코드 실행, 프로세스 및 메모리

앞에서 설명한 것처럼 앱은 임의 애플리케이션 풀 ID를 사용하여 권한이 낮은 작업자 프로세스 내에서 실행됩니다. 애플리케이션 코드는 CGI 프로세스 또는 다른 애플리케이션이 생성할 수 있는 자식 프로세스와 함께 작업자 프로세스와 연결된 메모리 공간에 액세스할 수 있습니다. 그러나 한 앱은 동일한 VM에 있더라도 다른 앱의 메모리 또는 데이터에 액세스할 수 없습니다.

앱은 지원되는 웹 개발 프레임워크로 작성된 스크립트 또는 페이지를 실행할 수 있습니다. App Service는 웹 프레임워크 설정을 더 제한된 모드로 구성하지 않습니다. 예를 들어 App Service에서 실행되는 ASP.NET 앱은 더 제한된 신뢰 모드가 아닌 완전 신뢰로 실행됩니다. 클래식 ASP 및 ASP.NET 포함한 웹 프레임워크는 Windows 운영 체제에 기본적으로 등록된 In-Process COM 구성 요소(예: ActiveX Data Objects)를 호출할 수 있습니다. 웹 프레임워크는 Out-of-process COM 구성 요소를 호출할 수 없습니다.

앱은 임의의 코드를 생성 및 실행하거나 명령 셸을 열거나 PowerShell 스크립트를 실행할 수 있습니다. 그러나 실행 프로그램 및 스크립트는 여전히 부모 애플리케이션 풀에 부여된 권한으로 제한됩니다. 예를 들어 앱은 아웃바운드 HTTP 호출을 수행하는 실행 프로그램을 생성할 수 있지만 해당 실행 프로그램은 네트워크 어댑터에서 VM의 IP 주소를 바인딩 해제하려고 시도할 수 없습니다. 권한이 낮은 코드에는 아웃바운드 네트워크 호출이 허용되지만 VM에서 네트워크 설정을 다시 구성하려면 관리 권한이 필요합니다.

진단 로그 및 이벤트

로그 정보는 일부 앱이 액세스하려고 하는 또 다른 데이터 집합입니다. App Service에서 실행되는 코드에 사용할 수 있는 로그 정보 유형에는 앱이 생성하고 쉽게 액세스할 수 있는 진단 및 로그 정보가 포함됩니다.

예를 들어 앱에서 생성된 W3C HTTP 로그는 다음 중 하나를 사용할 수 있습니다.

• 앱에 대해 만든 네트워크 공유 위치의 로그 디렉터리에서
• Blob Storage에서 W3C 로깅을 스토리지에 설정하는 경우

후자 옵션을 사용하면 앱이 네트워크 공유와 연결된 파일 스토리지 제한을 초과하지 않고 많은 양의 로그를 수집할 수 있습니다.

마찬가지로 .NET 앱의 실시간 진단 정보는 .NET 추적 및 진단 인프라를 통해 기록할 수 있습니다. 그런 다음, 추적 정보를 앱의 네트워크 공유 또는 Blob Storage 위치에 쓸 수 있습니다.

앱에서 사용할 수 없는 진단 로깅 및 추적 영역은 ETW(Windows용 Windows 이벤트 추적) 이벤트 및 일반적인 Windows 이벤트 로그(예: 시스템, 애플리케이션 및 보안 이벤트 로그)입니다. 올바른 액세스 제어 목록을 사용하여 컴퓨터에서 ETW 추적 정보를 볼 수 있으므로 ETW 이벤트에 대한 읽기 액세스 및 쓰기 액세스가 차단됩니다. ETW 이벤트 및 일반적인 Windows 이벤트 로그를 읽고 쓰는 API 호출이 작동하는 것처럼 보일 수 있지만 실제로 애플리케이션 코드는 이 이벤트 데이터에 액세스할 수 없습니다.

레지스트리 액세스

앱은 실행 중인 VM 레지스트리의 대부분에 대한 읽기 전용 액세스 권한을 갖습니다. 이 액세스는 앱이 로컬 사용자 그룹에 대한 읽기 전용 액세스를 허용하는 레지스트리 키에 액세스할 수 있음을 의미합니다. 현재 읽기 또는 쓰기 액세스에 대해 지원되지 않는 레지스트리의 한 영역은 하이브입니다 HKEY_CURRENT_USER .

사용자별 레지스트리 키에 대한 액세스를 포함하여 레지스트리에 대한 쓰기 액세스가 차단됩니다. 앱의 관점에서 볼 때 VM 간에 앱을 마이그레이션할 수 있으므로 Azure 환경의 레지스트리에 대한 쓰기 액세스를 사용할 수 없습니다. 앱이 의존할 수 있는 유일한 영구 쓰기 가능한 스토리지는 App Service UNC 공유에 저장된 앱별 콘텐츠 디렉터리 구조입니다.

원격 데스크톱 액세스

App Service는 VM 인스턴스에 대한 원격 데스크톱 액세스를 제공하지 않습니다.

관련 콘텐츠

App Service의 실행 환경에 대한 가장 up-to날짜 정보는 Azure App Service 샌드박스를 참조하세요. App Service 개발 팀은 이 페이지를 유지 관리합니다.