다음을 통해 공유


Azure Functions의 안정성

이 문서에서는 Azure Functions의 안정성 지원을 설명하고 가용성 영역을 통한 지역 내 복원력과 지역 간 복구 및 비즈니스 연속성을 모두 설명합니다. Azure의 안정성 원칙에 대한 자세한 개요는 Azure 안정성을 참조하세요.

Azure Functions에 대한 가용성 영역 지원은 Functions 호스팅 계획에 따라 달라집니다.

호스팅 계획 지원 수준 자세한 내용은...
Flex 사용량 계획 미리 보기 이 문서의 맨 위에 있는 플렉스 소비를 선택합니다.
탄력적 프리미엄 플랜 미국 조지아주 이 문서의 맨 위에서 프리미엄 을 선택합니다.
전용(App Service) 플랜 미국 조지아주 Azure App Service의 안정성을 참조하세요.
사용 계획 n/a 소비 계획에서 지원되지 않습니다.

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치될 수 있습니다.

Azure Functions는 영역 중복 배포를 지원합니다.

가용성 영역 지원

중요합니다

Flex Consumption 계획에서 앱을 호스팅할 때 가용성 영역에 대한 지원은 현재 미리 보기로 제공됩니다.

Flex Consumption 계획 앱을 영역 중복성으로 구성하면 플랫폼은 선택한 지역의 각 영역에 함수 앱의 인스턴스를 자동으로 분산하며, 항상 준비된 인스턴스와 주문형 인스턴스에 대해 서로 다른 규칙을 적용합니다.

Flex 소비 계획에서 영역 중복성을 사용하도록 설정하면 다음 규칙 내에서 인스턴스 분산이 결정됩니다.

  • 항상 준비된 인스턴스는 라운드 로빈 방식으로 두 개 이상의 영역에 분산됩니다.
  • 앱이 항상 준비된 것 이상으로 확장됨에 따라 이벤트 원본 볼륨의 결과로 생성되는 주문형 인스턴스는 최상의 노력으로 가용성 영역에 분산됩니다. 즉, 주문형 인스턴스의 경우 가용성 영역 간의 분산보다 더 빠른 스케일 아웃이 기본 설정됩니다. 플랫폼은 시간이 지남에 따라 균등 배포를 시도합니다.
  • 가용성 영역을 사용하여 영역 복원력을 보장하기 위해 플랫폼은 앱에 대한 항상 준비된 구성에 관계없이 각 함수별 크기 조정 함수 또는 그룹에 대해 항상 준비된 인스턴스를 두 개 이상 자동으로 유지 관리합니다. 플랫폼에서 만든 모든 인스턴스는 플랫폼 관리형으로, 항상 준비된 인스턴스로 청구되며, 항상 준비된 구성 설정을 변경하지 않습니다.

Elastic Premium 함수 앱 계획을 영역 중복으로 구성하면 플랫폼이 선택한 지역의 영역에 함수 앱 인스턴스를 자동으로 분산합니다.

영역 중복 배포를 통해 분산되는 인스턴스는 앱 규모가 확대 및 축소되더라도 다음 규칙 내에서 결정됩니다.

  • 최소 함수 앱 인스턴스 수는 2개입니다.
  • 영역 수보다 큰 용량을 지정하면 용량이 영역 수의 배수인 경우에만 인스턴스가 균등하게 분산됩니다.
  • 영역 수 * 인스턴스 수를 초과하는 용량 값의 경우 추가 인스턴스가 나머지 영역에 분산됩니다.

중요합니다

Azure Functions는 Azure App Service 플랫폼에서 실행할 수 있습니다. App Service 플랫폼에서 프리미엄 플랜 함수 앱을 호스트하는 계획을 Elastic Premium 요금제라고 하며 SKU 이름은 다음과 같습니다 EP1. 프리미엄 계획에서 함수 앱을 실행하도록 선택한 경우 SKU 이름으로 시작하는 E계획을 만들어야 합니다(예: EP1.). App Service 계획 SKU 이름은 P로 시작하는 P1V2 (Premium V2 Small Plan)과 같이 전용 호스팅 계획을 의미합니다. Elastic Premium이 아닌 전용이므로 SKU 이름으로 시작하는 P 플랜은 동적으로 확장되지 않으며 비용을 증가시킬 수 있습니다.

국가별 가용성

현재 모든 지역이 Flex Consumption 계획에 대한 영역 중복을 지원하는 것은 아닙니다. Azure CLI를 사용하여 Azure CLI를 지원하는 지역을 볼 수 있습니다.

  1. 아직 수행하지 않은 경우 Azure CLI를 사용하여 Azure에 설치하고 로그인합니다.

    az login
    

    az login 명령을 선택하면 사용자가 Azure 계정에 로그인됩니다.

  2. az functionapp list-flexconsumption-locations 명령을 --zone-redundant=true 옵션과 함께 사용하여 현재 영역 중복 Flex Consumption 계획을 지원하는 지역 목록을 반환합니다.

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
    

Azure Portal에서 Flex Consumption 앱을 만들 때, 선택한 지역이 이를 지원하면 기본 페이지의 Zone redundancy 섹션이 활성화됩니다.

영역 중복 프리미엄 플랜은 다음 지역에서 사용할 수 있습니다.

아메리카 유럽 중동 아프리카 아시아 태평양
브라질 남부 프랑스 중부 이스라엘 중부 남아프리카 북부 오스트레일리아 동부
캐나다 중부 독일 중서부 카타르 중부 인도 중부
미국 중부 이탈리아 북부 아랍에미리트 북부 중국 북부 3
미국 동부 북유럽 동아시아
미국 동부 2 노르웨이 동부 일본 동부
미국 중남부 스웨덴 중부 동남아시아
미국 서부 2 스위스 북부
미국 서부 3 영국 남부
서유럽

필수 구성 요소

가용성 영역 지원은 Flex Consumption 계획의 속성입니다. 가용성 영역 사용에 대한 현재 고려 사항은 다음과 같습니다.

가용성 영역 지원은 프리미엄 플랜의 속성입니다. 가용성 영역에 대한 현재 고려 사항은 다음과 같습니다.

  • 앱을 만들 때만 계획에서 가용성 영역을 사용하도록 설정할 수 있습니다. 기존 프리미엄 플랜은 가용성 영역을 사용하도록 변환할 수 없습니다.
  • 함수 앱의 기본 호스트 스토리지 계정에는 영역 중복 스토리지 계정(ZRS)을 사용해야 합니다. 다른 유형의 스토리지 계정을 사용하는 경우 영역 중단 중에 앱이 예기치 않게 동작할 수 있습니다.
  • Windows와 Linux가 모두 지원됩니다.
  • 프리미엄 플랜에서 호스트되는 함수 앱에는 항상 준비된 인스턴스가 2개 이상 있어야 합니다.
  • 2개 미만의 인스턴스 수를 지정하는 경우 플랫폼은 백그라운드에서 이 최소 개수를 적용합니다.
  • 프리미엄 플랜 또는 가용성 영역을 지원하는 배율 단위를 사용하지 않거나 지원되지 않는 지역에 있거나 확실하지 않은 경우 마이그레이션 지침을 참조하세요.

가격 책정

가용성 영역을 활성화하는 것과 관련된 별도의 계량기는 없습니다. 영역 중복 Flex Consumption 앱에 사용되는 인스턴스에 대한 가격 책정은 단일 영역 Flex Consumption 앱과 동일합니다. 자세한 내용은 청구를 참조하세요.

각 함수별 크기 조정 함수 또는 그룹에 대해 항상 준비된 인스턴스 구성이 2개 미만인 앱에서 가용성 영역을 사용하도록 설정하면 플랫폼은 각 함수별 크기 조정 함수 또는 그룹에대해 항상 준비된 형식의 두 인스턴스를 자동으로 만듭니다. 이러한 새 인스턴스는 항상 준비된 인스턴스로 청구됩니다.

가용성 영역 사용과 관련된 추가 비용은 없습니다. 영역 중복 Premium App Service 요금제에 대한 가격 책정은 단일 영역 프리미엄 플랜과 동일합니다. 사용하는 App Service 요금제마다 선택한 SKU, 지정한 용량 및 자동 크기 조정 조건을 기반으로 크기를 조정하는 모든 인스턴스에 따라 요금이 청구됩니다. 인스턴스가 2개 미만인 계획에서 가용성 영역을 사용하도록 설정하는 경우 플랫폼은 해당 App Service 계획에 대해 최소 인스턴스 수를 2개 적용하며 두 인스턴스에 대해 요금이 청구됩니다.

영역 중복 플랜에서 함수 앱 만들기

현재 영역 중복 Flex Consumption 앱을 배포하는 방법에는 여러 가지가 있습니다.

  1. Azure Portal에서 함수 앱 만들기 페이지로 이동합니다. 포털에서 함수 앱 만들기에 관한 자세한 내용은 함수 앱 만들기를 참조하세요.

  2. Flex 사용을 선택한 다음 선택 단추를 선택합니다.

  3. 함수 앱 만들기(Flex Consumption) 페이지의 기본 사항 탭에서 함수 앱에 대한 설정을 입력합니다. 다음 표의 설정에 있는 영역 중복에 대한 특정 요구 사항을 특히 주의하세요(다음 스크린샷에서도 강조 표시됨).

    설정 제안 값 영역 중복에 대한 참고 사항
    지역 선호하는 지원 지역 플렉스 컨섬션 플랜이 생성되는 지역입니다. 가용성 영역을 지원하는 지역을 선택해야 합니다. 지역 가용성 목록을 참조하세요.
    영역 중복성 사용 이 설정은 앱이 영역 중복인지 여부를 지정합니다. 영역 중복을 지원하는 지역을 선택한 경우에만 Enabled를 선택할 수 있습니다.

    Flex Consumption 함수 앱 만들기 페이지의 기본 사항 탭 스크린샷

  4. Storage 탭에서 함수 앱 스토리지 계정에 대한 설정을 입력합니다. 다음 표의 설정에 있는 영역 중복에 대한 특정 요구 사항을 특히 주의하세요.

    설정 제안 값 영역 중복에 대한 참고 사항
    스토리지 계정 영역 중복 스토리지 계정 사전 요구 사항 섹션에서 설명했듯이, 영역 중복 함수 앱에 영역 중복 스토리지 계정을 사용하는 것이 좋습니다.
  5. 나머지 함수 앱 만들기 프로세스는 정상적으로 함수 앱을 만듭니다. 만들기의 나머지 프로세스에는 영역 중복성에 영향을 주는 설정이 없습니다.

영역 중복 플랜이 만들어져 배포된 후에는 새 계획에 호스트된 Flex 사용 함수 앱이 영역 중복으로 간주됩니다.

Flex 사용 플랜을 영역 중복으로 업데이트

앱의 영역 중복성을 변경하려면 다시 시작해야 하므로 앱에서 가동 중지 시간이 발생합니다.

Flex Consumption 계획을 영역 중복으로 업데이트하기 전에 기본 호스트 스토리지 계정을 또한 영역 중복으로 업데이트해야 합니다. 앱의 배포 컨테이너를 위해 별도의 스토리지 계정을 사용하는 경우, 해당 계정을 영역 간 중복이 가능하도록 업데이트해야 합니다.

다음 단계를 사용하여 변경에 대한 스토리지 계정을 준비합니다.

  1. 스토리지 고려 사항을 검토합니다.
  2. 앱의 기본 호스트 스토리지 계정이 될 영역 중복 스토리지 계정을 만들거나 지정합니다.
  3. 영역 중복 스토리지 계정을 참조하도록 앱의 스토리지 관련 애플리케이션 설정(예: AzureWebJobsStorage)을 업데이트합니다. 애플리케이션 설정 작업을 참조하세요.
  4. 앱에 연결된 스토리지 계정과 동일하거나 다를 수 있는 앱의 배포 스토리지 계정을 업데이트합니다. 배포 설정 구성을 참조하세요.

앱에서 사용하는 스토리지 계정이 업데이트된 후에는 Bicep 또는 ARM 템플릿을 사용하여 Flex 사용 플랜을 영역 중복으로 업데이트할 수 있습니다. Azure Portal은 현재 계획에 대한 영역 중복 업데이트 만들기를 지원하지 않습니다.

현재 지원되지 않습니다.

현재 영역 중복 프리미엄 플랜 및 함수 앱을 배포하는 두 가지 방법이 있습니다. Azure Portal 또는 ARM 템플릿을 사용할 수 있습니다.

  1. Azure Portal에서 함수 앱 만들기 페이지로 이동합니다. 포털에서 함수 앱 만들기에 관한 자세한 내용은 함수 앱 만들기를 참조하세요.

  2. Functions Premium선택 단추를 차례로 선택합니다.

  3. 함수 앱 만들기(Functions Premium) 페이지의 기본 탭에서 함수 앱에 대한 설정을 입력합니다. 다음 표의 설정에 있는 영역 중복에 대한 특정 요구 사항을 특히 주의하세요(다음 스크린샷에서도 강조 표시됨).

    설정 제안 값 영역 중복에 대한 참고 사항
    지역 선호하는 지원 지역 Elastic Premium 플랜이 만들어지는 지역입니다. 가용성 영역을 지원하는 지역을 선택해야 합니다. 지역 가용성 목록을 참조하세요.
    요금제 탄력적 프리미엄 계획 중 하나입니다. 자세한 내용은 사용 가능한 인스턴스 SKU를 참조하세요. 이 문서에서는 프리미엄 계획에서 영역 중복 앱을 만드는 방법을 설명합니다. 영역 중복은 현재 사용량 플랜에서 사용할 수 없습니다. App Service 계획의 영역 중복성에 관한 자세한 내용은 Azure App Service의 안정성을 참조하세요.
    영역 중복성 사용 이 설정은 앱이 영역 중복인지 여부를 지정합니다. 앞에서 설명한 대로 영역 중복을 지원하는 지역을 선택하지 않으면 Enabled을(를) 선택할 수 없습니다.

    함수 앱 만들기 페이지의 기본 사항 탭을 보여주는 스크린샷.

  4. Storage 탭에서 함수 앱 스토리지 계정에 대한 설정을 입력합니다. 다음 표의 설정에 있는 영역 중복에 대한 특정 요구 사항을 특히 주의하세요.

    설정 제안 값 영역 중복에 대한 참고 사항
    스토리지 계정 영역 중복 스토리지 계정 사전 요구 사항 섹션에서 설명했듯이, 영역 중복 함수 앱에 영역 중복 스토리지 계정을 사용하는 것이 좋습니다.
  5. 나머지 함수 앱 만들기 프로세스는 정상적으로 함수 앱을 만듭니다. 만들기의 나머지 프로세스에는 영역 중복성에 영향을 주는 설정이 없습니다.

영역 중복 플랜이 만들기 및 배포된 후 새 플랜에서 호스팅되는 모든 함수 앱은 영역 중복으로 간주됩니다.

가용성 영역 마이그레이션

현재 기존 함수 앱에 대한 Elastic Premium 계획의 가용성 영역 지원을 변경할 수 없습니다. 공용 다중 테넌트 프리미엄 플랜을 사용할 수 없는 영역에서 가용성 영역 지원으로 마이그레이션하는 방법에 대한 자세한 내용은 App Service를 가용성 영역 지원으로 마이그레이션을 참조하세요.

영역 다운 환경

영역 중복성이 있는 Flex Consumption 계획 앱의 모든 사용 가능한 함수 앱 인스턴스가 활성화되어 이벤트를 처리하고 있습니다. Flex Consumption 앱은 동일한 지역의 다른 영역이 중단되는 경우에도 계속 실행됩니다. 그러나 다른 가용성 영역의 중단으로 인해 런타임이 아닌 동작이 영향을 받을 수 있습니다. 가용성에 영향을 줄 수 있는 표준 함수 앱 동작은 다음과 같습니다.

  • 확장
  • 앱 만들기
  • 구성 변경
  • 배포

Flex Consumption 계획의 영역 중복성은 실행 중인 배포된 애플리케이션에 대한 지속적인 작동 시간만 보장합니다.

영역이 다운되면 Functions는 손실된 인스턴스를 검색하고 필요에 따라 사용 가능한 영역에서 대체 인스턴스를 찾거나 만들려고 자동으로 시도합니다. 영역 중단 중에 플랫폼은 남은 사용 가능한 영역에서 균형을 복원하려고 합니다.

영역 중복으로 구성된 함수 앱의 사용 가능한 모든 함수 앱 인스턴스가 사용하도록 설정되고 이벤트를 처리합니다. 영역의 가동이 중지되면 Functions에서 손실된 인스턴스를 검색하고, 필요한 경우 자동으로 새 대체 인스턴스를 찾으려고 시도합니다. 탄력적 크기 조정 동작은 계속 적용됩니다. 그러나 영역 다운 시나리오에서는 손실된 인스턴스를 가능한 범위 내에서 복구하므로, 더 많은 인스턴스에 대한 요청이 성공할 것이라는 보장은 없습니다. 가용성 영역이 사용하도록 설정된 프리미엄 플랜에 배포된 애플리케이션은 동일한 지역의 다른 영역이 중단되는 경우에도 계속 실행됩니다. 그러나 다른 가용성 영역의 중단으로 인해 런타임이 아닌 동작이 여전히 영향을 받을 수 있습니다. 이러한 영향을 받는 동작에는 프리미엄 플랜 크기 조정, 애플리케이션 만들기, 애플리케이션 구성 및 애플리케이션 게시가 포함될 수 있습니다. 프리미엄 플랜의 영역 중복은 배포된 애플리케이션의 지속적인 작동 시간만 보장합니다.

Functions에서 인스턴스를 영역 중복 프리미엄 플랜에 할당하는 경우 기본 Azure Virtual Machine Scale Sets에서 제공하는 최상의 영역 균형을 사용합니다. 프리미엄 플랜은 각 영역에 프리미엄 플랜에서 사용하는 다른 모든 영역과 같은 수의 가상 머신이 있거나, 가상 머신 수가 하나 차이가 날 경우 균형 잡힌 것으로 간주됩니다.

지역 간 재해 복구 및 비즈니스 연속성

DR(재해 복구)은 자연 재해나 가동 중지 및 데이터 손실을 초래하는 배포 실패와 같은 큰 영향을 미치는 사건에서 조직이 복구하는 데 사용하는 사례를 말합니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 작성하기 전에 재해 복구 전략 디자인을 위한 권장 사항을 참조하세요.

DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 이 모델에서 Microsoft는 기준 인프라와 플랫폼 서비스를 사용할 수 있도록 보장합니다. 그러나 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우, 워크로드에 맞는 재해 복구 계획을 수립하는 것은 사용자의 책임입니다. Azure PaaS(서비스 제공 플랫폼)에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공합니다. DR 계획을 개발하는 데 도움이 되는 빠른 복구를 지원하는 서비스별 기능을 사용할 수 있습니다.

이 섹션에서는 재해 복구를 허용하는 함수 앱을 배포하는 데 사용할 수 있는 몇 가지 전략에 대해 설명합니다.

Durable Functions에 대한 재해 복구는 Azure Durable Functions의 재해 복구 및 지역 배포를 참조하세요.

다중 지역 재해 복구

사용할 수 있는 기본 제공 중복성이 없으므로 함수는 특정 Azure 지역의 함수 앱에서 실행됩니다. 중단 중 실행 손실을 방지하기 위해 동일한 함수를 여러 지역의 함수 앱에 중복 배포할 수 있습니다. 다중 지역 배포에 대한 자세한 내용은 고가용성 다중 지역 웹 애플리케이션의 지침을 참조하세요.

여러 지역에서 같은 함수 코드를 실행할 때는 활성-활성활성-수동 등 두 가지 패턴을 고려합니다.

HTTP 트리거 함수에 대한 활성-활성 패턴

활성-활성 패턴을 사용하면 두 지역의 함수가 복제 방식이나 순환 방식으로 활발히 실행되고 이벤트를 처리합니다. 여러 지역에서 실행되는 함수 간에 HTTP 요청을 라우팅하고 라운드 로빈할 수 있는 중요한 HTTP 트리거 함수에 대해 Azure Front Door 와 함께 활성-활성 패턴을 사용해야 합니다. 또한 Front Door에서 각 엔드포인트의 상태를 주기적으로 확인할 수 있습니다. 한 지역의 함수가 상태 확인에 응답하지 않으면 Azure Front Door는 해당 함수를 순환에서 제외하고 나머지 정상 함수로만 트래픽을 전달합니다.

Azure Front Door 및 함수에 대한 아키텍처

비 HTTPS 트리거 함수에 대한 활성-수동 패턴

Service Bus 및 Event Hubs 트리거 함수와 같은 이벤트 기반의 비 HTTP 트리거 함수에 활성-수동 패턴을 사용하는 것이 좋습니다.

비 HTTP 트리거 함수에 대한 중복성을 만들려면 활성-수동 패턴을 사용합니다. 활성-수동 패턴을 사용하면 함수는 이벤트를 수신하는 지역에서 적극적으로 실행되지만 두 번째 지역의 같은 함수는 유휴 상태로 유지됩니다. 활성-수동 패턴은 단일 함수에서 각 메시지를 처리하는 방법을 제공하지만 재해가 발생한 경우 보조 지역으로 장애 조치하는 메커니즘을 제공합니다. 함수 앱은 Azure Service Bus 지역 복구Azure Event Hubs 지역 복구와 같은 파트너 서비스의 장애 조치(failover) 동작과 함께 작동합니다.

Azure Event Hubs 트리거를 사용하는 예제 토폴로지를 고려합니다. 이 경우 활성/수동 패턴에는 다음 구성 요소가 필요합니다.

  • Azure Event Hubs가 기본 및 보조 지역에 모두 배포되어 있습니다.
  • 기본 및 보조 이벤트 허브를 페어링하기 위해 지역 재해를 사용하도록 설정했습니다. 또한 이벤트 허브에 연결하고 연결 정보를 변경하지 않고 기본에서 보조로 전환하는 데 사용할 수 있는 별칭을 만듭니다.
  • 함수 앱은 기본 및 보조(장애 조치(failover)) 지역 모두에 배포되며 보조 지역의 앱은 메시지가 전송되지 않기 때문에 기본적으로 유휴 상태입니다.
  • 해당 이벤트 허브에 대한 직접(별칭 아님) 연결 문자열에서 함수 앱이 트리거됩니다.
  • 이벤트 허브에 대한 게시자는 별칭 연결 문자열에 게시해야 합니다.

활성-수동 아키텍처 예

장애 조치(failover) 전에 공유 별칭으로 보내는 게시자는 기본 이벤트 허브로 라우팅합니다. 기본 함수 앱은 기본 이벤트 허브만을 대상으로 수신 대기합니다. 보조 함수 앱은 수동적이고 유휴 상태입니다. 장애 조치(failover)가 시작되는 즉시 공유 별칭으로 보내는 게시자는 보조 이벤트 허브로 라우팅됩니다. 이제 보조 함수 앱이 활성화되고 자동으로 트리거되기 시작합니다. 보조 지역에 대한 효과적인 장애 조치(failover)는 이벤트 허브에서 전적으로 구동될 수 있으며, 함수는 해당 이벤트 허브가 활성 상태인 경우에만 활성화됩니다.

자세한 내용은 Service BusEvent Hubs의 장애 조치(failover)에 대한 정보 및 고려 사항을 참조하세요.

비 HTTPS 트리거 함수에 대한 활성-활성 패턴

비 HTTPS 트리거 함수에 대해 활성-수동 패턴을 사용하는 것이 좋습니다. 하지만 HTTP가 아닌 트리거 함수에 대한 활성-활성 배포를 만들 수 있습니다. 이 패턴을 구현하기 전에 두 활성 영역이 상호 작용하거나 서로 조정하는 방법을 고려해야 합니다.

예를 들어 동일한 Service Bus 트리거 함수 코드를 두 지역에 배포하지만 동일한 Service Bus 큐에서 트리거하는 것이 좋습니다. 이 경우 두 함수는 단일 큐에서 큐를 제거하는 데 있어 경쟁하는 소비자 역할을 합니다. 각 메시지는 두 앱 인스턴스 중 하나에서만 처리할 수 있지만 단일 Service Bus 인스턴스인 단일 실패 지점이 여전히 있음을 의미합니다.

대신 주 지역에 하나씩, 하나는 보조 지역에 있는 두 개의 Service Bus 큐를 배포할 수 있습니다. 이 경우 각각 해당 지역에서 활성화된 Service Bus 큐를 가리키는 두 개의 함수 앱이 있을 수 있습니다. 이 토폴로지의 문제는 큐 메시지가 두 지역 간에 분산되는 방식입니다. 이는 일반적으로 각 게시자가 지역에 메시지를 게시하려고 시도하고, 각 메시지가 활성 함수 앱에서 처리되는 것을 의미합니다. 이렇게 하면 원하는 활성/활성 패턴이 만들어지지만 컴퓨팅 복제와 데이터 통합 시기 또는 방법과 관련된 다른 문제도 발생합니다.

다음 단계