Azure App Service에 대한 모범 사례

이 문서는 Azure App Service를 사용하는 모범 사례를 요약합니다.

공동 배치

Azure App Service 솔루션은 콘텐츠 또는 데이터를 보관하기 위한 웹앱과 데이터베이스 또는 스토리지 계정으로 구성됩니다. 이러한 리소스가 다른 지역에 있는 상황에서는 다음과 같은 영향을 미칠 수 있습니다.

• 리소스 간 통신에 대한 대기 시간 증가
• Azure 가격 책정 페이지에서 설명한 것과 같이 지역 간 아웃바운드 데이터 전송에 대한 금전적인 청구

솔루션을 구성하는 Azure 리소스에는 공동 배치가 가장 적합합니다. 리소스를 만들 때 동일한 Azure 지역에 있어서는 안 되는 특정 비즈니스 또는 디자인 사유가 없는 한 동일한 Azure 지역에 있어야 합니다. 프리미엄 App Service 요금제에서 사용할 수 있는 App Service 복제 기능을 사용하여 App Service 앱을 데이터베이스와 동일한 지역으로 이동할 수 있습니다.

인증서 고정

인증서 고정은 애플리케이션에서 허용되는 CA(인증 기관), 공개 키, 지문 또는 인증서 계층 구조 일부의 특정 목록만 허용하는 사례입니다.

애플리케이션에 기본 와일드카드(*.azurewebsites.net) TLS 인증서에 대한 하드 종속성이나 고정이 있어서는 안 됩니다. App Service는 PaaS(Platform as a Service)이므로 언제든지 이 인증서를 회전할 수 있습니다. 서비스에서 기본 와일드카드 TLS 인증서를 회전하는 경우 인증서 고정 애플리케이션은 특정 인증서 특성 세트로 하드 코딩된 애플리케이션에 대한 연결을 끊고 중단합니다. 회전 빈도는 언제든지 변경될 수 있으므로 인증서가 회전되는 주기성도 보장되지 않습니다.

인증서 고정을 사용하는 애플리케이션에는 App Service 관리 인증서에 대한 하드 종속성이 없어야 합니다. App Service 관리 인증서는 언제든지 회전될 수 있으므로 안정적인 인증서 속성을 사용하는 애플리케이션에서 비슷한 문제가 발생할 수 있습니다. 인증서 속성을 사용하는 애플리케이션에 사용자 지정 TLS 인증서를 제공하는 것이 가장 좋습니다.

애플리케이션에서 인증서 고정 동작을 사용해야 하는 경우 사용자 지정 도메인을 웹앱에 추가하고 도메인에 대한 사용자 지정 TLS 인증서를 제공하는 것이 좋습니다. 그러면 애플리케이션이 인증서 고정에 사용자 지정 TLS 인증서를 사용할 수 있습니다.

메모리 리소스

모니터링 또는 서비스 권장 사항에 앱이 예상보다 많은 메모리를 사용한다고 나타날 경우 App Service 자동 복구 기능을 고려합니다. web.config를 사용하여 자동 복구를 구성할 수 있습니다.

자동 복구 기능에 대한 옵션 중 하나는 메모리 임계값을 기반으로 하는 사용자 지정 작업을 수행하는 것입니다. 작업은 작업자 프로세스를 재활용하여 자리 완화에 대한 메모리 덤프를 통해 이메일 알림에서 조사로 범위를 확장합니다.

CPU 리소스

모니터링 또는 서비스 권장 사항에 앱이 예상보다 더 많은 CPU를 사용하거나 CPU 스파이크가 반복 발생하고 있다고 표시되는 경우 App Service 요금제의 스케일 업 또는 스케일 아웃을 고려합니다. 애플리케이션이 상태 저장 상태인 경우 스케일 업이 유일한 옵션입니다. 애플리케이션이 상태 비 상태인 경우 스케일 아웃하면 유연성과 확장 가능성이 높아집니다.

App Service 크기 조정 및 자동 크기 조정 옵션에 대한 자세한 내용은 Azure App Service에서 앱 크기 조정을 참조하세요.

소켓 리소스

아웃바운드 TCP 연결을 소모시키는 일반적인 이유는 HTTP Keep-Alive처럼 더 높은 수준의 프로토콜을 사용하지 않거나, TCP 연결을 재사용하지 않는 클라이언트 라이브러리의 사용입니다.

App Service 요금제 참조에서 앱이 참조하는 각 라이브러리에 대한 설명서를 검토합니다. 아웃바운드 연결을 효율적으로 재사용하기 위해 라이브러리가 코드에서 구성되거나 액세스되었는지 확인합니다. 또한 연결 누수를 방지하도록 올바른 생성 및 릴리스 또는 정리에 대한 라이브러리 설명서 지침을 따릅니다. 이러한 클라이언트 라이브러리를 조사하는 중에 여러 인스턴스로 확장하여 영향을 완화할 수 있습니다.

Node.js 및 발신 HTTP 요청

Node.js 및 다수의 발신 HTTP 요청을 수행하는 경우, HTTP Keep-Alive를 처리하는 것이 중요합니다. agentkeepalivenpm 패키지를 사용하면 코드로 더 쉽게 처리할 수 있습니다.

처리기에서는 아무 작업도 수행하지 않더라도 http 응답을 항상 처리해야 합니다. 응답을 제대로 처리하지 않으면 사용할 수 있는 소켓이 없어지기 때문에 애플리케이션이 결국 멈추게 됩니다.

다음은 http 또는 https 패키지로 작업할 때 응답을 처리하는 예제입니다.

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

다중 코어가 있는 컴퓨터에서 Linux를 기반으로 App Service 앱을 실행 중인 경우 또 다른 좋은 방법은 PM2를 사용하여 여러 Node.js 프로세스를 시작하여 애플리케이션을 실행하는 것입니다. 이 작업은 컨테이너에 시작 명령을 지정하여 수행할 수 있습니다.

예를 들어 다음 명령을 사용하여 4개의 인스턴스를 시작합니다.

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

앱 백업

백업은 일반적으로 일정에 따라 실행되며, 스토리지(백업된 파일을 출력하는 경우) 및 데이터베이스(백업에 포함될 콘텐츠를 복사하고 읽는 경우)에 대한 액세스 권한이 필요합니다. 이러한 리소스 중 하나에 액세스하는 데 실패하면 일관된 백업 실패가 발생합니다.

앱 백업이 실패하는 가장 일반적인 이유는 잘못된 스토리지 설정 및 잘못된 데이터베이스 구성 등 두 가지가 있습니다. 이러한 오류는 일반적으로 스토리지 또는 데이터베이스 리소스를 변경한 후 또는 해당 리소스에 액세스하기 위해 자격 증명을 변경한 후에 발생합니다. 예를 들어 백업 설정에서 선택한 데이터베이스에 대한 자격 증명이 업데이트될 수 있습니다.

백업 실패가 발생하는 경우 가장 최근의 결과를 검토하여 어떤 유형의 오류가 발생하는지를 이해해야 합니다. 스토리지 액세스 실패의 경우 백업 구성의 스토리지 설정을 검토하고 업데이트합니다. 데이터베이스 액세스 실패의 경우 앱 설정의 일부로 연결 문자열을 검토하고 업데이트합니다. 그런 다음, 필요한 데이터베이스를 제대로 포함하도록 백업 구성을 업데이트합니다.

앱 백업에 대한 자세한 내용은 Azure App Service에서 앱 백업 및 복원을 참조하세요.

Node.js 앱

Node.js 앱에 대한 Azure App Service 기본 구성은 가장 일반적인 앱 요구에 가장 적합하게 지정되었습니다. Node.js 앱의 기본 구성을 개인화하여 성능을 증대하거나 CPU, 메모리 또는 네트워크 리소스에 대한 리소스 사용을 최적화하려면 Azure App Service의 Node 애플리케이션에 대한 모범 사례 및 문제 해결 가이드를 참조하세요. 이 문서에서는 Node.js 앱에 대해 구성해야 할 수 있는 iisnode 설정을 설명합니다. 또한 앱의 시나리오 또는 문제를 해결하는 방법을 설명합니다.

IoT 디바이스

App Service에 연결된 IoT(사물 인터넷) 디바이스를 실행하는 경우 환경을 향상시킬 수 있습니다.

IoT 디바이스에 대해 일반적인 사례 중 하나는 "인증서 고정"입니다. 서비스의 관리형 인증서 변경으로 인한 예기치 않은 가동 중지 시간을 방지하려면 인증서를 기본 *.azurewebsites.net 인증서 또는 App Service 관리 인증서에 고정하지 않아야 합니다. 시스템에서 인증서 고정 동작을 사용해야 하는 경우 사용자 지정 도메인을 웹앱에 추가하고 도메인에 대한 사용자 지정 TLS 인증서를 제공하는 것이 좋습니다. 그러면 애플리케이션이 인증서 고정에 사용자 지정 TLS 인증서를 사용할 수 있습니다. 자세한 내용은 이 문서의 인증서 고정 섹션을 참조하세요.

환경의 복원력을 높이려면, 모든 디바이스에 대해 단일 엔드포인트를 사용하지 않습니다. 단일 실패 지점을 방지하고 트래픽을 장애 조치(failover)하도록 준비하려면 최소한 두 지역에서 웹앱을 호스트합니다.

App Service에서 이러한 웹앱은 서로 다른 지역에서 호스트되는 한 동일한 사용자 지정 도메인을 다른 웹앱에 추가할 수 있습니다. 이 기능을 통해, 인증서를 고정해야 하는 경우 제공한 사용자 지정 TLS 인증서에도 고정할 수 있습니다.

또 다른 옵션은 웹앱에 대한 고가용성을 보장하기 위해 Azure Front Door 또는 Azure Traffic Manager와 같은 웹앱 앞에서 부하 분산 장치를 사용하는 것입니다. 자세한 내용은 빠른 시작: 고가용성 글로벌 웹 애플리케이션에 대한 Front Door 인스턴스 만들기 또는 Azure Traffic Manager를 사용하여 Azure App Service 트래픽 제어를 참조하세요.

다음 단계

리소스와 관련된 실행 가능한 모범 사례를 얻으려면 App Service 진단을 사용합니다.

1. Azure Portal에서 웹앱으로 이동합니다.
2. 왼쪽 창에서 문제 진단 및 해결을 선택하여 App Service 진단을 엽니다.
3. 모범 사례 타일을 선택합니다.
4. 가용성 및 성능을 위한 모범 사례 또는 최적의 구성을 위한 모범 사례를 선택하여 이러한 모범 사례에 관련된 앱의 현재 상태를 확인합니다.

이 링크(https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot)를 사용하여 리소스에 대한 App Service 진단을 직접 열 수도 있습니다.