Azure App Service의 운영 체제 기능

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

참고 항목

App Service의 Linux 앱은 자체 컨테이너에서 실행됩니다. 사용자에게는 컨테이너에 대한 루트 액세스 권한은 있지만 호스트 운영 체제에 대한 액세스 권한은 없습니다. 마찬가지로, Windows 컨테이너에서 실행되는 앱의 경우 컨테이너에 대한 관리자 액세스 권한은 있지만 호스트 운영 체제에 대한 액세스 권한은 없습니다.

App Service 계획 계층

App Service는 다중 테넌트 호스팅 환경에서 고객 앱을 실행합니다. 무료 계층 및 공유 계층에 배포된 앱은 공유 VM(가상 머신)의 작업자 프로세스에서 실행됩니다. 표준 계층 및 프리미엄 계층에 배포된 앱은 단일 고객과 연결된 앱 전용 VM에서 실행됩니다.

참고 항목

App Service 체험 및 공유(미리 보기) 서비스 요금제는 다른 App Service 앱과 동일한 Azure 가상 머신에서 실행되는 기본 계층입니다. 일부 앱은 다른 고객에게 속할 수 있습니다. 이러한 계층은 개발/테스트용으로만 사용할 수 있습니다.

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) 인프라에서 실행되는 서비스입니다. 따라서 가상 머신과 연결된 로컬 드라이브는 Azure에서 실행되는 모든 작업자 역할에서 사용할 수 있는 것과 동일한 드라이브 종류입니다. 다음이 포함됩니다.

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

항상 하드 코딩된 파일 경로 대신 %SystemDrive% 및 %ResourceDrive% 환경 변수를 사용하는 것이 가장 좋습니다. 이러한 두 환경 변수에서 반환된 루트 경로는 시간이 지자면서 d:\에서 c:\로 바뀌었습니다. 그러나 App Service는 c:\를 가리키도록 d:\를 자동으로 다시 매핑하므로, d:\에 대한 파일 경로 참조로 하드 코딩된 이전 애플리케이션이 계속 작동합니다. 앞서 설명했듯이, 파일 경로를 빌드할 때 항상 환경 변수를 사용하고 플랫폼을 기본 루트 파일 경로로 변경하는 것을 혼동하지 않도록 방지하는 것이 좋습니다.

애플리케이션이 커질수록 디스크 사용률을 모니터링하는 것이 중요합니다. 디스크 할당량에 도달하면 애플리케이션에 부정적인 영향을 줄 수 있습니다. 예시:

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

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

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

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

Azure 서비스가 작동하는 방식으로 인해 UNC 공유를 호스트하는 가상 머신은 시간이 지나면서 바뀝니다. UNC 공유는 일반적인 Azure 작동 과정에서 늘리고 줄이므로 다양한 가상 머신에 탑재됩니다. 이 때문에 앱은 UNC 파일 경로의 컴퓨터 정보가 시간이 지남에 따라 안정성을 유지할 것으로 강력하게 가정해서는 안 됩니다. 대신 UNC 공유는 App Service에서 제공하는 간편한 가짜 절대 경로인 %HOME%\site를 사용해야 합니다.

가짜 절대 경로는 사용자 고유의 앱을 참조하는 데 사용되는 이식 가능 메서드입니다. 가짜 절대 경로는 앱 또는 사용자에 한정되지 않습니다. %HOME%\site를 사용하면 전송할 때마다 새 절대 경로를 구성할 필요 없이 앱 간에 공유 파일을 전송할 수 있습니다.

앱에 부여되는 파일 액세스 형식

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

시스템 드라이브에서 App Service는 앱별 임시 로컬 스토리지에 대해 %SystemDrive%\local을 예약합니다. 이 디렉터리의 파일에 대한 변경 내용은 앱 다시 시작에서 지속되지 않습니다. 앱은 자체의 임시 로컬 스토리지를 모두 읽고 쓸 수 있지만, 이 스토리지는 사실상 애플리케이션 코드에 직접 사용하도록 만들어지지 않았습니다. IIS 및 웹 애플리케이션 프레임워크를 위한 임시 파일 스토리지를 제공하기 위한 것입니다.

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

계층	로컬 파일 스토리지
B1/S1/P1	11GB
B2/S2/P2	15GB
B3/S3/P3	58GB
P0v3	11GB
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21GB
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61GB
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140GB
Isolated4v2	276GB
P4mv3	280GB
Isolated5v2	552GB
P5mv3	560GB
Isolated6v2	1,104GB

App Service가 임시 로컬 스토리지를 사용하는 방법을 두 가지 예로 들면 임시 ASP.NET 파일용 디렉터리와 IIS 압축 파일용 디렉터리 등입니다. 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 내의 서비스에 연결할 수 있습니다(예: Azure SQL Database에 대한 HTTPS 연결 설정).

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

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

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

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

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

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

진단 로그 및 이벤트

로그 정보는 일부 앱이 액세스를 시도하는 또 하나의 데이터 집합입니다. App Service에서 실행되는 코드에 사용할 수 있는 로그 정보의 종류로는 앱에서 생성하고 쉽게 액세스할 수 있는 진단 및 로그 정보가 있습니다.

예를 들어 앱에서 생성된 W3C HTTP 로그는 다음 중 한 곳에 제공됩니다.

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

두 번째 옵션을 사용하면 네트워크 공유와 관련된 파일 스토리지 제한을 초과하지 않고 대량의 로그를 수집할 수 있습니다.

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

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

레지스트리 액세스

앱은 실행 중인 가상 머신의 레지스트리 대부분(전체는 아님)에 읽기 전용으로 액세스할 수 있습니다. 앱이 로컬 사용자 그룹에 대한 읽기 전용 액세스를 허용하는 레지스트리 키에 액세스할 수 있다는 뜻입니다. 현재 읽기 또는 쓰기 액세스가 지원되지 않는 레지스트리 영역 중 하나는 HKEY\_CURRENT\_USER 하이브입니다.

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

원격 데스크톱 액세스

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

자세한 정보

App Service의 실행 환경에 대한 최신 정보는 Azure App Service 샌드박스를 참조하세요. App Service 개발 팀이 이 페이지를 유지 관리합니다.