Azure Functions 명시적 인프라 프로비저닝 또는 관리 없이 작은 코드 블록 또는 functions 실행하는 이벤트 기반 컴퓨팅 서비스입니다. 함수는 HTTP 요청, 타이머, 큐 메시지 및 다른 Azure 서비스의 변경 내용과 같은 이벤트에 응답할 수 있습니다. 이 기능을 사용하면 Functions가 데이터 처리, 시스템 통합 및 백그라운드 작업에 적합합니다.
Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.
이 문서에서는 일시적인 오류, 가용성 영역의 실패 및 지역 전체의 장애를 포함한 다양한 잠재적 중단 및 문제에 대해 기능을 복원력 있게 만드는 방법을 설명합니다. 또한 Functions SLA(서비스 수준 계약)에 대한 주요 정보도 강조 표시합니다.
프로덕션 배포 권장 사항
Azure Well-Architected Framework는 안정성, 보안, 비용, 작업 및 성능에 대한 권장 사항을 제공합니다. 이러한 영역이 서로 영향을 미치고 신뢰할 수 있는 Functions 솔루션에 기여하는 방법을 알아보려면 Functions에 대한 아키텍처 모범 사례를 참조하세요.
안정성 아키텍처 개요
Functions를 배포할 때는 다음 개념을 숙지해야 합니다.
호스팅 계획: 계획은 함수 앱의 호스팅 환경을 나타냅니다. 계획은 사용 가능한 컴퓨팅 리소스, 가격 책정 모델 및 크기 조정 동작을 결정합니다.
스토리지 계정: 함수 앱을 만들 때 호스트 스토리지 계정을 지정해야 합니다. 스토리지 계정은 함수 코드 스토리지, 로깅 및 동시성 관리(예: 특정 트리거 형식에 대한 Blob 임대)를 포함하여 함수 앱의 내부 작업의 측면을 관리합니다.
배포에 스토리지 계정을 사용할 수도 있습니다. 이 스토리지 계정은 호스트 스토리지 계정 또는 다른 스토리지 계정과 동일할 수 있습니다.
중요합니다
스토리지 계정은 Functions 안정성 아키텍처의 중요한 부분입니다. 함수 앱의 복원력 요구 사항을 충족하도록 구성합니다.
트리거 및 바인딩: 트리거 및 바인딩을 사용하면 함수가 이벤트에 응답하고, 다른 서비스에서 데이터를 수신하고, 다른 서비스에 데이터를 쓸 수 있습니다.
지속성 함수: 지속성 함수는 Functions의 기능입니다. 장기 실행 오케스트레이션 및 상태 저장 엔터티와 같은 상태 저장 함수를 제공합니다.
지속성 함수를 사용하는 경우 상태를 저장하는 스토리지 공급자 를 구성합니다. 선택한 상태 저장소의 안정성 특성을 평가하고 복원력 요구 사항을 충족하도록 구성합니다.
일시적인 오류에 대한 복원력
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.
함수 앱에서 일시적인 오류를 처리하기 위한 다음 권장 사항을 고려합니다.
트리거 및 바인딩: Functions 플랫폼에는 트리거 및 바인딩에 대한 기본 제공 임시 오류 처리가 포함되어 있습니다. 지원되는 트리거가 작동하거나 지원되는 바인딩이 데이터를 읽거나 쓰는 동안 일시적인 오류가 발생하면, 플랫폼은 자동으로 작업을 재시도할 수 있습니다. 이 기본 제공 재시도 동작은 임시 연결 문제 또는 서비스 중단으로 인해 함수가 실행되지 않도록 합니다. 자세한 내용은 Functions 오류 처리 및 재시도를 참조하세요.
이 보호는 일시적인 오류만 포함합니다. 플랫폼은 잘못 구성된 연결 문자열 또는 삭제된 리소스와 같은 영구 오류를 다시 시도하지 않습니다.
이 플랫폼은 영구 오류 및 반복된 일시적 오류를 오류로 처리합니다. 함수 실행 오류에 대한 정보를 캡처하도록 로깅을 구성합니다. 자세한 내용은 Functions에 대한 모니터링 구성을 참조하세요.
함수 코드: 함수 코드에서는 함수가 외부 서비스를 호출할 때 일시적인 오류를 처리해야 합니다. 함수 코드에서 수행한 외부 서비스 호출에 적합한 재시도 논리, 시간 제한 및 회로 차단기 패턴을 구현합니다. 재시도로 중복된 부작용이 생성되지 않도록 가능한 경우 함수를 idempotent로 디자인합니다.
클라이언트: HTTP 연결을 통해와 같이 함수에 동기적으로 연결하는 클라이언트 애플리케이션은 일시적인 오류에 복원력이 있어야 합니다.
가용성 영역 오류에 대한 복원력
가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.
소비 계획은 가용성 영역을 지원하지 않습니다. 영역 중복성이 워크로드에 대한 요구 사항인 경우 Flex Consumption, Premium 또는 dedicated(Azure App Service) 계획을 대신 사용하는 것이 좋습니다.
Flex Consumption 계획은 영역 중복 배포를 지원합니다.
프리미엄 플랜은 영역 중복 배포를 지원합니다.
영역 중복을 사용하도록 설정하면 플랫폼은 선택한 지역의 모든 가용성 영역에 계획 인스턴스를 자동으로 분산합니다. 지역의 가용성 영역에 문제가 있는 경우 함수는 정상 영역의 인스턴스를 사용하여 계속 실행됩니다.
호스트 스토리지 계정에서 ZRS(영역 중복 스토리지)를 사용하도록 설정해야 하므로 영역 중단에도 복원력이 있습니다.
다이어그램은 세 가지 가용성 영역을 보여 줍니다. 각 영역에는 Functions 인스턴스가 포함됩니다. ZRS 계정은 세 가지 가용성 영역에 걸쳐 있습니다.
전용(App Service) 플랜은 영역 중복 배포를 지원합니다. 영역 중복을 사용하도록 설정하면 플랫폼은 선택한 지역의 모든 가용성 영역에 인스턴스를 자동으로 분산합니다. 계획에서 영역 중복성을 구성합니다. Azure App Service 영역 중복을 처리하는 방법에 대한 자세한 내용은 App Service의 신뢰성 참조하세요.
영역 중복을 사용하지 않도록 설정하면 계획이 비영역 또는 지역이 됩니다. 플랫폼은 지역 또는 동일한 영역에 있는 가용성 영역에 계획 인스턴스를 배치할 수 있습니다. 계획 인스턴스는 가용성 영역 오류에 복원력이 없습니다. 해당 지역의 모든 영역에서 가동 중단이 발생하는 동안 계획이 가동 중지될 수 있습니다.
요구 사항
- 지역 지원: 영역 중복 Flex Consumption 계획을 특정 지역 집합에 배포할 수 있습니다. Azure CLI를 사용하여 지원되는 지역의 현재 목록을 검색할 수 있습니다. 자세한 내용은 가용성 영역을 지원하는 지역 보기를 참조하세요.
지역 지원: 영역 중복 프리미엄 플랜을 다음 지역에 배포할 수 있습니다.
Americas 유럽 중동 Africa Asia Pacific Brazil South 프랑스 중부 Israel Central 남아프리카 북부 Australia East Canada Central 독일 중서부 Qatar Central Central India Central US Italy North UAE North 중국 북부 3 East US North Europe East Asia 미국 동부 2 Norway East Japan East 미국 중남부 스웨덴 중부 동남아시아 미국 서부 2 Switzerland North 미국 서부 3 UK South West Europe 사용 시스템: 플랫폼은 영역 중복 Windows 및 Linux 계획 배포를 지원합니다.
최소 인스턴스 수: 프리미엄 플랜의 영역 중복성에는 항상 준비된 인스턴스가 2개 이상 필요합니다.
- 호스트 스토리지 계정:ZRS를 사용하도록 함수 앱의 기본 호스트 스토리지 계정을 구성해야 합니다. ZRS에 대해 구성되지 않은 호스트 스토리지 계정을 사용하는 경우 영역 중단 중에 앱이 예기치 않게 동작할 수 있습니다.
- 배포 컨테이너 스토리지 계정: 앱의 배포 컨테이너에 별도의 스토리지 계정을 사용하는 경우, 해당 계정을 영역 중복성을 가지도록 업데이트합니다.
고려 사항
런타임이 아닌 동작: 영역 중복은 배포된 애플리케이션에 대한 지속적인 가동 시간만 보장합니다. 애플리케이션이 트래픽을 계속 처리하더라도 가용성 영역 중단은 Functions의 측면에 영향을 줄 수 있습니다. 이러한 동작에는 계획 크기 조정, 애플리케이션 만들기, 애플리케이션 구성 및 애플리케이션 게시가 포함됩니다.
영역 간 인스턴스 배포
Flex Consumption 계획 앱을 영역 중복으로 구성하면 플랫폼은 항상 준비된 인스턴스와 주문형 인스턴스에 대해 서로 다른 규칙을 사용하여 선택한 지역의 여러 영역에 계획 인스턴스를 자동으로 분산합니다.
항상 준비된 인스턴스는 라운드 로빈 배포를 사용하여 두 개 이상의 영역에 분산됩니다.
영역 복원력을 보장하기 위해 플랫폼은 앱에 대한 항상 준비된 구성에 관계없이 각 함수별 크기 조정 함수 또는 그룹에 대해 항상 준비된 인스턴스를 두 개 이상 자동으로 유지 관리합니다. 플랫폼이 만드는 인스턴스는 플랫폼 관리형 인스턴스이며, 항상 준비된 인스턴스로 청구되며, 항상 준비된 구성 설정을 변경하지 않습니다.
주문형 인스턴스는 앱이 항상 준비된 인스턴스 수를 초과하여 확장됨에 따라 이벤트 원본 볼륨에서 발생합니다. 주문형 인스턴스는 최상의 노력으로 가용성 영역에 분산됩니다. 플랫폼은 영역 간 균등 배포보다 더 빠른 스케일 아웃 우선 순위를 지정합니다. 플랫폼은 시간이 지남에 따라 배포를 고르게 만들려고 합니다.
Elastic Premium 함수 앱 계획을 영역 중복으로 구성하면 플랫폼은 선택한 지역의 여러 영역에 계획 인스턴스를 자동으로 분산합니다. 인스턴스 확산은 앱이 스케일 인 및 스케일 아웃되는 경우에도 다음과 같은 규칙을 따릅니다.
최소 함수 앱 인스턴스 수는 2개입니다.
영역 수보다 큰 용량을 지정하면 용량이 영역 수의 배수인 경우에만 인스턴스가 균등하게 분산됩니다.
인스턴스 수를 곱한 영역 수보다 큰 용량 값의 경우 추가 인스턴스가 나머지 영역에 분산됩니다.
Functions은 영역 중복 프리미엄 계획에 인스턴스를 할당할 때, 기본적으로 Azure Virtual Machine Scale Sets에서 제공하는 최적의 노력 기반 영역 분산을 사용합니다. Azure는 각 영역이 계획의 다른 영역과 동일한 수의 VM(가상 머신)을 가지거나 플러스 마이너스 하나의 VM일 때 프리미엄 요금제가 균형을 이루었다고 간주합니다.
Cost
영역 중복을 사용하도록 설정하면 추가 비용이 발생하지 않습니다. 영역 중복 계획에 대한 가격 책정은 단일 영역 계획과 동일합니다. 그러나 영역 중복을 사용하도록 설정하면 계획의 최소 인스턴스 수에 영향을 줍니다.
각 함수별 크기 조정 함수 또는 그룹에 대해 항상 준비된 인스턴스 구성이 2개 미만인 앱에서 가용성 영역을 사용하도록 설정하면 플랫폼은 각 함수별 크기 조정 함수 또는 그룹에 대해 항상 준비된 형식 의 두 인스턴스를 자동으로 만듭니다. 이러한 새 인스턴스는 항상 준비된 인스턴스로 청구됩니다.
인스턴스가 2개 미만인 계획에서 가용성 영역을 사용하도록 설정하면 플랫폼이 해당 계획에 대해 최소 인스턴스 수를 2개 적용하고 두 인스턴스에 대해 요금이 청구됩니다.
전체 가격 책정 정보는 Functions 가격 책정을 참조하세요.
가용성 영역 지원 구성
영역 중복이 있는 새 Functions 플랜을 만듭니다. 새 계획을 만들 때 영역 중복을 사용하도록 설정할 수 있습니다. 자세한 내용은 영역 중복 함수 앱 만들기를 참조하세요.
기존 계획에서 영역 중복을 사용하도록 설정합니다. 기존 Elastic Premium 요금제에 대해 가용성 영역을 설정하거나 해제할 수 있습니다. Elastic Premium 요금제에는 전용(App Service) 계획과 다른 특정 용량 동작이 있으며 추가 구성 단계가 필요합니다. 자세한 단계는 기존 계획에서 영역 중복 사용 설정을 참조하세요.
새 영역 중복 함수 계획을 만듭니다. 새 계획을 만들 때 영역 중복을 사용하도록 설정할 수 있습니다. 자세한 내용은 영역 중복 함수 앱 만들기를 참조하세요.
기존 계획에서 영역 중복을 사용하도록 설정합니다. 프리미엄 플랜의 경우 계획을 만드는 동안에만 영역 중복을 사용하도록 설정할 수 있습니다. 기존 프리미엄 요금제는 영역 중복으로 변환할 수 없습니다. 대신 새 프리미엄 계획 앱에서 병렬 배포를 만들어 앱을 마이그레이션합니다. 자세한 내용은 기존 계획에서 영역 중복 사용 설정을 참조하세요.
용량 계획 및 관리
영역 중복 함수 앱은 지역의 영역에서 중단이 발생하는 경우에도 계속 실행됩니다.
영역 중단 중에 Functions는 손실된 인스턴스를 검색하고 정상 영역에서 대체 인스턴스를 자동으로 찾거나 만들려고 시도합니다. 플랫폼은 최상의 노력으로 이 프로세스를 수행하며 성공을 보장하지는 않습니다. 워크로드에 예상 서비스 수준을 유지하기 위해 특정 개수의 인스턴스가 필요한 경우 항상 준비된 인스턴스 수를 과도하게 프로비전하는 것이 좋습니다. 오버프로비전하면 솔루션이 용량 손실을 허용하고 성능 저하 없이 계속 작동할 수 있습니다. 자세한 내용은 오버프로비전하여 용량 관리를 참조하세요.
모든 영역이 정상인 경우의 동작
이 섹션에서는 계획이 영역 중복이고 호스트 스토리지 계정이 ZRS를 사용하며 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.
영역 간 작업: Functions에서 영역 중복성을 구성하면 요청이 각 가용성 영역의 인스턴스에 자동으로 분산됩니다. 요청은 가용성 영역의 모든 인스턴스로 이동될 수 있습니다.
영역 간 데이터 복제: Functions는 상태 비정상 컴퓨팅 서비스이므로 영역 간에 복제할 데이터가 없습니다. 플랫폼은 영역 간에 구성을 자동으로 복제합니다.
호스트 스토리지 계정이 ZRS를 사용하는 경우 Azure Storage는 여러 가용성 영역에 데이터를 동기적으로 복제합니다.
지속성 함수의 경우 스토리지 공급자를 검토하여 영역 간에 데이터를 복제하는 방법을 알아봅니다.
영역 오류 중 동작
이 섹션에서는 계획이 영역 중복이고 호스트 스토리지 계정이 ZRS를 사용하며 가용성 영역 중단이 있을 때 예상되는 사항에 대해 설명합니다.
- 검색 및 응답: Functions 플랫폼은 가용성 영역에서 오류를 감지하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작할 필요가 없습니다.
- 알림: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Resource Health 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고 설정하여 문제를 알릴 수 있습니다. 또한 Azure Service Health를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 가용성 영역을 사용할 수 없는 경우 잘못된 가용성 영역의 인스턴스에 연결하는 진행 중인 요청이 종료되고 다시 시도해야 합니다. 일시적인 오류 처리 지침에 따라 애플리케이션이 준비되었는지 확인합니다.
예상 데이터 손실: Functions는 상태 비정상 서비스이므로 영역 오류로 인해 데이터가 손실되지 않을 것으로 예상됩니다.
호스트 스토리지 계정이 ZRS를 사용하는 경우 Storage는 영역 오류로 인한 데이터 손실을 방지합니다.
지속성 함수의 경우 스토리지 공급자를 검토하여 영역 오류 중에 데이터 손실이 가능한지 여부를 알아봅니다.
예상 가동 중지 시간: 영역 중단 중에는 트래픽이 재배포될 때 일반적으로 몇 초 동안 지속되는 짧은 중단이 발생할 수 있습니다. 일시적인 오류 처리 지침에 따라 애플리케이션이 준비되었는지 확인합니다.
트래픽 경로 변경: 함수는 해당 영역에서 손실된 인스턴스를 검색하고 새 대체 인스턴스를 찾으려고 시도합니다. Functions는 대체 항목을 찾은 후 필요에 따라 새 인스턴스에 트래픽을 분산합니다.
중요합니다
Azure는 영역 다운 시나리오에서 추가 인스턴스에 대한 요청이 성공할 것을 보장하지 않습니다. 이 플랫폼은 최선의 활동을 다해 손실된 인스턴스를 다시 채우려고 시도합니다. 가용성 영역 실패 시 보장된 용량이 필요한 경우 용량을 과도하게 프로비전하여 영역 손실을 고려하도록 계획을 만들고 구성합니다.
런타임이 아닌 동작: 영역 중복 함수 앱 계획의 애플리케이션은 가용성 영역에서 중단이 발생하는 경우에도 계속 실행되고 트래픽을 제공합니다. 그러나 가용성 영역 중단 중에는 런타임이 아닌 동작이 영향을 받을 수 있습니다. 이러한 동작에는 함수 앱 크기 조정, 애플리케이션 만들기, 애플리케이션 구성 및 애플리케이션 게시가 포함됩니다.
영역 복구
가용성 영역이 복구되면 Functions는 가용성 영역의 인스턴스를 자동으로 복원하고, 다른 가용성 영역에서 만든 임시 인스턴스를 제거하고, 인스턴스 간의 트래픽을 정상적으로 다시 라우팅합니다.
영역 오류 테스트
Functions 플랫폼은 영역 중복 리소스에 대한 트래픽 라우팅, 장애 조치(failover) 및 영역 복구를 관리합니다. 아무것도 시작할 필요가 없습니다. Azure 이 기능을 완전히 관리하므로 가용성 영역 오류 프로세스의 유효성을 검사할 필요가 없습니다.
지역 전체 오류에 대한 복원력
함수는 단일 지역 서비스입니다. 지역을 사용할 수 없게 되면 Functions 리소스도 사용할 수 없습니다.
복원력을 위한 사용자 지정 다중 지역 솔루션
지역 전체 중단 중에 서비스가 중단되는 것을 방지하기 위해 여러 지역의 함수 앱에 동일한 함수를 중복 배포할 수 있습니다.
다음을 담당합니다.
여러 지역에 함수 앱 배포
지역 간 트래픽 분산 관리.
장애 극복 메커니즘 구현
지역 간 데이터 일관성 보장(해당하는 경우).
지역 간 배포 모니터링 및 관리
여러 지역에서 동일한 함수 코드를 실행하는 경우 활성-활성 및 활성-수동 패턴을 고려합니다. 다음 섹션에서는 이러한 패턴을 소개하지만 자세한 지침이나 구성 단계는 제공하지 않습니다.
HTTP 트리거 함수에 대한 활성-활성 패턴
활성-활성 패턴에서 두 지역의 함수는 중복된 방식으로 또는 회전으로 이벤트를 적극적으로 실행하고 처리합니다. 중요한 HTTP 트리거 함수의 경우 Azure Front Door와 함께 활성-활성 패턴을 사용하여 여러 지역에서 실행되는 함수 간에 HTTP 요청을 라우팅하고 라운드 로빈할 수 있습니다. Azure Front Door는 각 엔드포인트의 상태를 주기적으로 확인할 수도 있습니다. 한 지역의 함수가 상태 검사에 응답하지 않으면 Azure Front Door 순환에서 제거되고 나머지 정상 함수에만 트래픽을 전달합니다.
다이어그램은 맨 위에 Azure Front Door 보여줍니다. 왼쪽의 주 지역과 오른쪽의 보조 지역이라는 두 개의 지역이 아래에 표시됩니다. 각 지역에는 Functions 앱과 데이터베이스가 포함됩니다. 화살표는 Azure Front Door에서 두 함수 앱 모두를 가리킵니다. 화살표는 각 함수 앱에서 해당 데이터베이스로 이동합니다.
HTTP가 아닌 트리거 함수에 대한 활성-수동 패턴
이벤트 기반의 비 HTTP 트리거 함수(예: Azure Service Bus 및 Azure Event Hubs 트리거)의 경우 활성-수동 패턴을 사용합니다. 활성-수동 패턴에서 함수 인스턴스는 이벤트를 수신하는 지역에서 실행되지만 보조 지역의 인스턴스는 유휴 상태로 유지됩니다. 이 패턴은 하나의 함수만 각 메시지를 처리하므로 데이터 일관성을 유지하는 데 도움이 됩니다. 재해 발생 중 지역 중단과 같은 상황에서 보조 지역으로 페일오버할 방법도 제공합니다.
다음과 같은 사용하는 다른 서비스의 장애 조치 동작을 함수 앱의 장애 조치 동작과 함께 고려하십시오.
Event Hubs 네임스페이스가 지역 재해 복구를 위해 구성된 Event Hubs 트리거를 사용하는 토폴로지 예제를 생각해 보세요. 이 경우 활성-수동 패턴에는 다음 구성 요소가 필요합니다.
주 지역과 보조 지역에 모두 배포된 Event Hubs 네임스페이스입니다.
지리적 재해 복구 기능이 활성화되었습니다 기본 및 보조 이벤트 허브를 페어링하기 위해. 또한 이 구성은 Event Hubs 네임스페이스에 연결하고 연결 정보를 변경하지 않고 주 네임스페이스에서 보조로 별칭을 전환하는 데 사용할 수 있는 별칭을 만듭니다.
기본 리전과 보조 리전에 모두 배포된 함수 앱 보조 지역의 앱은 메시지를 받지 않으므로 유휴 상태로 유지됩니다.
각 함수 앱의 트리거는 해당 Event Hubs 네임스페이스에 대해 direct (비별칭) 연결 문자열을 사용합니다.
Event Hubs 네임스페이스의 게시자는 별칭 연결 문자열에 게시합니다.
다이어그램은 왼쪽의 주 지역과 오른쪽의 보조 지역을 보여줍니다. 주 지역에는 활성 Event Hubs 네임스페이스, 함수 앱 및 데이터베이스가 포함됩니다. 보조 지역에는 수동 Event Hubs 네임스페이스, 함수 앱 및 데이터베이스가 포함됩니다. 별칭에서 나오는 화살표는 기본 및 보조 Event Hubs 네임스페이스를 연결하는 지리적 재해 복구 기능을 갖춘 Event Hubs를 가리킵니다. 화살표는 각 이벤트 허브에서 해당 함수 앱으로 이동합니다. 화살표는 각 함수 앱에서 해당 데이터베이스로 이동합니다.
장애 조치(failover) 전에 이벤트를 공유 별칭으로 보내는 게시자는 트래픽을 기본 이벤트 허브로 라우팅합니다. 기본 함수 앱은 주 이벤트 허브에서만 수신 대기합니다. 보조 함수 앱은 수동 및 유휴 상태로 유지됩니다.
장애 조치(failover)가 시작되면 이벤트를 공유 별칭으로 보내는 게시자는 보조 이벤트 허브로 라우팅됩니다. 보조 함수 앱이 활성화되고 자동으로 트리거됩니다. 이벤트 허브는 전체 장애 조치(failover) 프로세스를 구동할 수 있으며, 각 함수 앱은 해당 이벤트 허브가 활성화된 경우에만 실행됩니다.
지속성 함수
지속성 함수에 대한 다중 지역 재해 복구는 Azure 지속성 함수의 Disaster 복구 및 지역 분포 참조하세요.
서비스 유지 관리에 대한 복원력
함수는 정기적인 서비스 업그레이드 및 기타 유지 관리 작업을 수행합니다.
- 일시적인 오류 복원력: 서비스 유지 관리 중에 함수 앱을 실행하는 인스턴스가 다시 시작되거나 일시적인 중단이 발생할 수 있습니다. 함수 앱과 상호 작용하는 클라이언트 애플리케이션이 일시적인 오류에 복원력이 있는지 확인합니다.
- 영역 중복을 사용하도록 설정: 계획에서 영역 중복을 사용하도록 설정하면 플랫폼 업데이트 중에 복원력도 향상됩니다. 계획에서 여러 인스턴스를 배포하고 계획에 대한 영역 중복을 사용하도록 설정하면 업그레이드 중에 인스턴스 또는 영역이 비정상 상태가 되는 경우 추가 복원력 계층이 추가됩니다.
추가 임시 인스턴스: 업그레이드하는 동안 예상 용량을 유지하기 위해 플랫폼은 업그레이드 프로세스 중에 계획의 추가 인스턴스를 자동으로 추가합니다.
영역 중복을 사용하도록 설정: 계획에서 영역 중복을 사용하도록 설정하면 플랫폼 업데이트 중에 복원력도 향상됩니다. 업데이트 도메인은 업데이트 중에 오프라인 상태가 되는 VM 컬렉션으로 구성되며 가용성 영역에 매핑됩니다. 계획에 여러 인스턴스를 배포하고 계획에 대한 영역 중복을 사용하도록 설정하면 업그레이드 중에 인스턴스 또는 영역이 비정상 상태가 될 경우 추가 복원력 계층이 추가됩니다.
App Service Environment: App Service Environment에서 함수 앱을 호스트하는 경우 업그레이드 주기를 사용자 지정할 수 있습니다. 업그레이드가 워크로드에 미치는 영향의 유효성을 검사해야 하는 경우 수동 업그레이드를 사용하도록 설정합니다. 프로덕션 인스턴스에 업그레이드를 적용하기 전에 이 방법을 사용하여 비프로덕션 인스턴스의 유효성을 검사하고 테스트합니다.
유지 관리 기본 설정에 대한 자세한 내용은 App Service Environment 계획된 유지 관리를 위한 업그레이드 기본 설정을 참조하세요.
애플리케이션 배포에 대한 복원력
애플리케이션 배포는 프로덕션 환경에서 문제의 위험을 초래합니다. 문제가 발생하는 경우 업데이트를 롤백할 준비를 합니다. 애플리케이션 다시 시작으로 인한 중단을 줄이기 위해 업데이트가 롤아웃되는 방식을 제어합니다.
Flex Consumption 계획은 앱 업데이트를 배포하는 여러 가지 방법을 제공하는 사이트 업데이트 전략을 지원합니다. 이러한 전략에는 무중단 배포를 위한 롤링 업데이트가 포함됩니다.
함수 배포 슬롯을 사용하면 함수 앱의 가동 중지 시간이 0으로 설정됩니다. 배포 슬롯을 사용하여 사용자에 대한 배포 및 구성 변경의 영향을 최소화합니다. 또한 배포 슬롯은 애플리케이션이 다시 시작될 가능성을 줄입니다. 애플리케이션을 다시 시작하면 일시적인 오류가 발생합니다.
서비스 수준 약정
Azure 서비스에 대한 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 솔루션이 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.
함수는 소비 계획 및 다른 계획 유형에 대해 고유한 가용성 SLA를 제공합니다.