App Service 환경 사용

App Service Environment는 Azure App Service의 단일 테넌트 배포입니다. Azure 가상 네트워크에서 사용하며 이 시스템의 유일한 사용자입니다. 배포된 앱은 서브넷에 적용되는 네트워킹 기능을 적용합니다. 앱에서 관련 네트워킹 기능을 적용하기 위해 사용 설정을 해야 하는 추가 기능은 없습니다.

참고 항목

이 문서에서는 격리된 v2 App Service 요금제와 함께 사용되는 App Service Environment v3에 대해 알아봅니다.

앱 만들기

App Service Environment에서 앱을 만들려는 경우 일반적으로 앱을 만들 때 사용하는 것과 같은 프로세스를 사용하지만, 몇 가지 세부적인 차이점이 있습니다. 새 App Service 계획을 만들 때는 다음을 수행합니다.

• 앱을 배포하기 위한 지리적 위치를 선택하는 대신 App Service Environment를 위치로 선택합니다.
• App Service Environment에서 만든 모든 App Service 요금제는 격리된 v2 가격 책정 계층에만 있을 수 있습니다.

아직 없는 경우 App Service Environment를 만듭니다.

App Service Environment에서 앱을 만들려면 다음을 수행합니다.

1. 리소스 만들기>웹 + 모바일>웹앱을 선택합니다.
2. 구독을 선택합니다.
3. 새 리소스 그룹의 이름을 입력하거나 기존 항목 사용을 선택하고 드롭다운 목록에서 이름을 선택합니다.
4. 앱의 이름을 입력합니다. App Service Environment에서 이미 App Service 요금제를 선택한 경우 앱의 도메인 이름에 App Service Environment의 도메인 이름이 반영됩니다.
5. 게시, 런타임 스택, 운영 체제의 경우 적절하게 선택합니다.
6. 지역의 경우 기존 App Service Environment v3을 선택합니다. 새 App Service Environment를 만들려면 지역을 선택합니다.
7. 기존 App Service 요금제를 선택하거나 새로 만듭니다. 새 요금제를 만드는 경우 App Service 요금제에 대해 원하는 크기를 선택합니다. Isolated v2 가격 책정 SKU는 앱에 대해 선택할 수 있는 유일한 SKU입니다. App Service 요금제를 새로 만드는 작업은 일반적으로 20분 미만이 소요됩니다.
8. 새 App Service 요금제를 만드는 과정의 일부로 새 App Service Environment를 만들기로 선택한 경우 이름 및 가상 IP 유형을 입력합니다.
9. 다음: 모니터링을 선택합니다. 앱에서 Application Insights를 사용하도록 설정하려는 경우 여기에서 만들기 흐름 중에 해당 설정을 수행할 수 있습니다.
10. 다음: 태그를 선택합니다. 원하는 태그를 앱에 추가합니다.
11. 검토 + 만들기를 선택합니다. 정보가 올바른지 확인한 후 만들기를 선택합니다.

Windows 및 Linux 앱은 동일한 App Service Environment에 있을 수 있지만 동일한 App Service 요금제에 있을 수는 없습니다.

확장이 작동하는 방식

모든 App Service 앱은 App Service 계획에서 실행됩니다. App Service 환경은 App Service 계획을 포함하고 App Service 계획은 앱을 포함합니다. 앱을 스케일링할 경우 App Service 플랜과 같은 플랜 내에 있는 모든 앱 또한 스케일링합니다.

App Service 플랜을 스케일링하면 필요한 인프라가 자동으로 추가됩니다. 인프라가 추가되는 동안 스케일링 작업의 시간이 지연됩니다. 예를 들어 App Service 요금제를 스케일링하고 동일한 운영 체제의 또 다른 스케일링 작업과 실행 중인 크기가 있는 경우 요청된 스케일링이 시작될 때까지 몇 분 정도 지연될 수 있습니다.

한 크기 및 운영 체제의 스케일링 작업은 다른 크기 및 운영 체제 조합의 스케일링에 영향을 주지 않습니다. 예를 들어 Windows I2v2 App Service 요금제를 스케일링하는 경우 Windows I3v2 App Service 요금제로 스케일링 작업이 즉시 시작됩니다. 크기 조정은 일반적으로 15분 미만이 소요되지만 최대 45분이 소요될 수도 있습니다.

다중 테넌트 App Service에서는 작업을 지원할 공유 리소스 풀이 바로 사용 가능하도록 준비되어 있으므로 스케일링 작업을 즉시 실행할 수 있습니다. App Service Environment는 단일 테넌트 서비스이므로 공유 버퍼가 없으며 필요에 따라 리소스가 할당됩니다.

앱 액세스

내부 VIP(가상 IP)를 사용하는 App Service Environment에서 앱을 만드는 데 사용되는 도메인 접미사는 .<asename>.appserviceenvironment.net입니다. App Service Environment 이름이 my-ase이고 contoso라는 앱을 호스트하는 경우 다음과 같은 URL에서 앱에 액세스하게 됩니다.

• contoso.my-ase.appserviceenvironment.net
• contoso.scm.my-ase.appserviceenvironment.net

내부 VIP를 사용하는 App Service Environment에서 호스팅되는 앱은 동일한 가상 네트워크에 있거나 해당 가상 네트워크에 연결되어 있는 경우에만 액세스할 수 있습니다. 비슷하게, 게시는 동일한 가상 네트워크에 있거나 가상 네트워크에 연결되어 있는 경우에만 가능합니다.

외부 VIP를 사용하는 App Service Environment에서 앱을 만드는 데 사용되는 도메인 접미사는 .<asename>.p.azurewebsites.net입니다. App Service Environment 이름이 my-ase이고 contoso라는 앱을 호스트하는 경우 다음과 같은 URL에서 앱에 액세스하게 됩니다.

• contoso.my-ase.p.azurewebsites.net
• contoso.scm.my-ase.p.azurewebsites.net

scm URL은 Kudu 콘솔에 액세스하거나 웹 배포를 사용하여 앱을 게시하는 데 사용됩니다. 자세한 내용은 Azure App Service의 Kudu 콘솔을 참조하세요. Kudu 콘솔은 디버깅, 파일 업로드, 파일 편집을 위한 웹 UI를 제공합니다.

DNS 구성

외부 VIP를 사용하여 App Service Environment를 만든 경우 앱은 자동으로 퍼블릭 DNS에 배치됩니다. App Service Environment가 내부 VIP로 만들어진 경우 DNS를 구성해야 할 수 있습니다.

Azure DNS 프라이빗 영역을 자동으로 구성하도록 선택한 경우 DNS는 App Service Environment의 가상 네트워크에 구성됩니다. DNS 수동 구성을 선택한 경우에는 자체 DNS 서버를 사용하거나 Azure DNS 프라이빗 영역을 구성해야 합니다.

인바운드 주소를 찾으려면 App Service Environment 포털에서 IP 주소를 선택합니다.

사용자 고유의 DNS 서버를 사용하려면 다음 레코드를 추가합니다.

1. <App Service Environment-name>.appserviceenvironment.net에 대한 영역을 만듭니다.
2. 해당 영역에서 *를 App Service Environment에서 사용하는 인바운드 IP 주소로 가리키는 A 레코드를 만듭니다.
3. 해당 영역에서 @를 App Service Environment에서 사용하는 인바운드 IP 주소로 가리키는 A 레코드를 만듭니다.
4. scm으로 명명된 <App Service Environment-name>.appserviceenvironment.net에 영역을 만듭니다.
5. scm 영역에 *로 App Service Environment에서 사용하는 인바운드 주소를 가리키는 A 레코드를 만듭니다.

Azure DNS 프라이빗 영역에서 DNS를 구성하려면 다음을 수행합니다.

1. <App Service Environment-name>.appserviceenvironment.net이라는 Azure DNS 프라이빗 영역을 만듭니다.
2. 해당 영역에서 *를 인바운드 IP 주소로 가리키는 A 레코드를 만듭니다.
3. 해당 영역에서 @를 인바운드 IP 주소로 가리키는 A 레코드를 만듭니다.
4. 해당 영역에 *.scm으로 인바운드 IP 주소를 가리키는 A 레코드를 만듭니다.

App Service Environment의 기본 도메인 접미사에 대한 DNS 설정은 해당 이름으로만 액세스할 수 있도록 앱을 제한하지 않습니다. App Service Environment의 앱에 대한 유효성 검사 없이 사용자 지정 도메인 이름을 설정할 수 있습니다. 그런 다음, contoso.net이라는 영역을 만들려는 경우 이를 수행하고 인바운드 IP 주소를 가리킬 수 있습니다. 사용자 지정 도메인 이름은 앱 요청에 대해 작동하며 사용자 지정 도메인 접미사 인증서에 scm용 와일드카드 SAN이 포함된 경우 사용자 지정 도메인 이름은 scm 사이트에서도 작동하며 *.scm 레코드를 만들고 인바운드 IP 주소를 가리킬 수 있습니다.

게시 중

다음 방법 중 하나로 게시할 수 있습니다.

• 웹 배포
• CI(연속 통합)
• Kudu 콘솔에서 끌어서 놓기
• Visual Studio, Eclipse 또는 IntelliJ IDEA와 같은 IDE(통합 개발 환경)

내부 VIP App Service Environment를 사용하는 경우 게시 엔드포인트는 인바운드 주소를 통해서만 사용할 수 있습니다. 인바운드 주소에 대한 네트워크 액세스 권한이 없는 경우 해당 App Service Environment에 앱을 게시할 수 없습니다. 또한 IDE에 직접 게시하려면 App Service Environment의 인바운드 주소에 대한 네트워크 액세스 권한이 있어야 합니다.

GitHub, Azure DevOps와 같은 인터넷 기반 CI 시스템은 추가 변경 없이는 내부 VIP App Service Environment와 연동되지 않습니다. 게시 엔드포인트는 인터넷에 액세스할 수 없습니다. 가상 네트워크에 자체적으로 호스트된 릴리스 에이전트를 설치하여 Azure DevOps에서 내부 VIP App Service Environment에 게시를 사용하도록 설정할 수 있습니다.

스토리지

App Service Environment의 모든 앱에 대해 1TB의 스토리지가 있습니다. 격리 가격 책정 SKU의 App Service 요금제의 경우 스토리지 용량이 250GB로 제한됩니다. App Service Environment에서 250GB의 스토리지는 App Service 요금제당 1TB 제한까지 추가됩니다. App Service 요금제는 4개 이상 사용할 수 있지만 1TB 제한을 초과하는 스토리지는 더 이상 추가되지 않습니다.

모니터링

App Service Environment v3의 플랫폼 인프라는 Microsoft에서 모니터링하고 관리하며 필요에 따라 스케일링됩니다. 고객은 App Service 요금제 및 실행 중인 개별 앱만 모니터링하고 적절한 조치를 취해야 합니다. App Service Environment에 표시되는 일부 메트릭이 표시되지만 이는 이전 버전에만 사용되며 이 버전에 대한 값을 생략하지 않습니다. App Service Environment의 v1 또는 v2를 사용하는 경우 모니터링 및 스케일링에 대한 지침은 이 섹션을 참조하세요.

로깅

Azure Monitor와 통합하여 Azure Storage, Azure Event Hubs 또는 Azure Monitor 로그에 로그를 보낼 수 있습니다. 다음 표에서는 기록할 수 있는 상황 및 메시지를 보여 줍니다.

상황	메시지
App Service Environment 서브넷에 공간이 거의 없습니다.	지정된 App Service Environment가 있는 서브넷의 공간이 거의 다 찼습니다. 남은 주소가 {0} 있습니다. 해당 주소가 모두 사용되면 App Service Environment를 스케일링할 수 없습니다.
App Service Environment가 총 인스턴스 제한에 근접하고 있습니다.	지정된 App Service Environment가 App Service Environment의 총 인스턴스 제한에 근접하고 있습니다. 현재 최대 200개의 인스턴스 중 {0}개의 App Service 요금제 인스턴스를 포함합니다.
App Service Environment가 일시 중단되었습니다.	지정된 App Service Environment가 일시 중단됩니다. App Service Environment 일시 중단 현상은 계정 부족 또는 잘못된 가상 네트워크 구성으로 인해 발생할 수 있습니다. 근본 원인을 해결하고 App Service Environment를 다시 시작하여 트래픽을 계속 처리합니다.
App Service Environment 업그레이드가 시작되었습니다.	지정된 App Service Environment에 대한 플랫폼 업그레이드가 시작되었습니다. 스케일링 작업에서 지연이 발생합니다.
App Service Environment 업그레이드가 완료되었습니다.	지정된 App Service Environment에 대한 플랫폼 업그레이드가 완료되었습니다.
App Service 요금제 만들기가 시작되었습니다.	App Service 요금제({0}) 만들기가 시작되었습니다. 원하는 상태: {1} I{2}v2 작업자.
스케일링 작업이 완료되었습니다.	App Service 요금제({0}) 만들기가 완료되었습니다. 현재 상태: {1} I{2}v2 작업자.
스케일링 작업이 실패했습니다.	App Service 요금제({0}) 만들기에 실패했습니다. 이는 App Service Environment가 최대 인스턴스 수에서 작동하거나 서브넷 주소가 부족하기 때문일 수 있습니다.
스케일링 작업이 시작되었습니다.	App Service 플랜({0})의 스케일링이 시작되었습니다. 현재 상태: {1} I(2)v2. 원하는 상태: {3} I{4}v2 작업자.
스케일링 작업이 완료되었습니다.	App Service 플랜({0})의 스케일링이 완료되었습니다. 현재 상태: {1} I{2}v2 작업자.
스케일링 작업이 중단되었습니다.	App Service 요금제({0})이 스케일링 중에 중단되었습니다. 이전의 원하는 상태: {1} I{2}v2 작업자. 새로운 원하는 상태: {3} I{4}v2 작업자.
스케일링 작업이 실패했습니다.	App Service 플랜({0})의 스케일링에 실패했습니다. 현재 상태: {1} I{2}v2 작업자.

로깅을 사용하려면 다음 단계를 따릅니다.

1. 포털에서 진단 설정으로 이동합니다.
2. 진단 설정 추가를 선택합니다.
3. 로그 통합에 대한 이름을 제공합니다.
4. 원하는 로그 대상을 선택하고 구성합니다.
5. AppServiceEnvironmentPlatformLogs를 선택합니다.

Azure Monitor 로그와 통합하는 경우 App Service Environment 포털에서 로그를 선택하고 AppServiceEnvironmentPlatformLogs에 대한 쿼리를 만들어 로그를 볼 수 있습니다. 로그는 App Service Environment에 로그를 트리거하는 이벤트가 있는 경우에만 내보내집니다. App Service Environment에 관련 이벤트가 없는 경우 로그가 없는 것입니다. 로그의 예제를 신속하게 보려면 App Service 요금제를 사용하여 스케일링 작업을 수행합니다. 그런 다음 AppServiceEnvironmentPlatformLogs에 대해 쿼리를 실행하여 해당 로그를 볼 수 있습니다.

경고 만들기

로그에 대한 경고를 만들려면 Azure Monitor를 사용한 로그 경고 만들기, 보기, 관리의 지침을 따르세요. 개요:

1. App Service Environment 포털에서 경고 페이지를 엽니다.
2. 새 경고 규칙을 선택합니다.
3. 리소스의 경우 Azure Monitor 로그 작업 영역을 선택합니다.
4. 쿼리를 사용하도록 사용자 지정 로그 검색을 사용하여 조건을 설정합니다. 예를 들어 다음을 설정할 수 있습니다. ResultDescription이 포함된 위치 | AppServiceEnvironmentPlatformLogs가 스케일링을 시작했습니다. 임계값을 적정값으로 설정합니다.
5. 작업 그룹을 추가하거나 만듭니다(선택 사항). 작업 그룹은 메일 또는 SMS 메시지 전송 등의 경고에 대한 응답을 정의하는 위치입니다.
6. 경고 이름을 지정하고 저장합니다.

내부 암호화

App Service Environment 시스템 내에서 내부 구성 요소 또는 통신을 볼 수 없습니다. 높은 처리량을 활성화하기 위해 내부 구성 요소 사이에는 기본적으로 암호화가 사용되지 않습니다. 시스템은 트래픽을 모니터링하거나 액세스하는 데 액세스할 수 없기 때문에 보안이 유지됩니다. 데이터 경로의 전체 암호화에 대한 규정 준수 요구 사항이 있는 경우 이를 실행할 수 있습니다. 다음 스크린샷과 같이 구성을 선택합니다.

이 옵션은 내부 네트워크 트래픽을 암호화하고 페이지 파일 및 작업자 디스크도 암호화합니다. 이 옵션은 시스템 성능에 영향을 줄 수 있습니다. 변경 내용이 완전히 전파될 때까지 App Service Environment는 불안정한 상태가 됩니다. 변경 내용의 전체 전파는 인스턴스 수에 따라 완료하는 데 몇 시간이 걸릴 수 있습니다.

App Service Environment를 사용하는 동안에는 이 옵션을 사용하지 마세요. 그렇게 해야 하는 경우 작업이 완료될 때까지 트래픽을 백업으로 전환하는 것이 좋습니다.

업그레이드 기본 설정

App Service Environment가 여러 개인 경우 일부 환경을 다른 환경 이전에 업그레이드할 수 있습니다. App Service Environment 포털을 통해 이 동작을 사용하도록 설정할 수 있습니다. 구성 아래 업그레이드 기본 설정을 지정하는 옵션이 있습니다. 가능한 값은 다음과 같습니다.

• None: 특정 일괄 처리되지 않은 Azure 업그레이드입니다. 이 값은 기본값입니다.
• 초기: App Service 업그레이드의 초반부에서 업그레이드됩니다.
• 후기: App Service 업그레이드의 후반부에서 업그레이드됩니다.
• 수동: 업그레이드를 수동으로 배포하려면 15일 기간을 확보합니다.

원하는 값을 선택한 다음, 저장을 선택합니다.

이 기능은 여러 App Service Environment가 있고 업그레이드 시퀀싱의 이점을 누릴 수 있는 경우에 가장 유용합니다. 예를 들어 개발 및 테스트 App Service Environment를 초기로 설정하고 프로덕션 App Service Environment를 후기로 설정할 수 있습니다.

App Service 환경을 삭제합니다.

삭제하려면

1. App Service Environment 창 상단에서 삭제를 선택합니다.
2. App Service Environment의 이름을 입력하여 삭제를 확인합니다. App Service Environment를 삭제하는 경우 포함된 내용도 모두 삭제됩니다.
3. 확인을 선택합니다.