Azure SignalR의 지역에서 복제

로컬에서 활약하려고 하거나 강력한 장애 조치(failover) 시스템을 요구하는 회사는 종종 여러 Azure 지역에 서비스를 배포하도록 선택합니다. Azure SignalR에서 지역 복제가 통합됨에 따라 다중 지역 시나리오를 관리하는 것이 훨씬 쉬워졌습니다.

지역 복제 사용의 이점

• 지역 가동 중단에 대한 복원력 향상: 지역 가동 중단이 발생하면 Azure SignalR DNS가 다른 지역의 정상 복제본으로 확인됩니다.
• 지역 간 통신. 여러 다른 복제본은 동일한 인스턴스인 것처럼 서로 통신할 수 있습니다.
• 향상된 네트워크 속도: 지리적으로 분산된 클라이언트는 가장 가까운 복제본에 연결됩니다. 이러한 복제본은 Azure 글로벌 네트워크 백본을 통해 통신하여 빠르고 안정적인 네트워킹을 보장합니다.
• 공유 구성 모든 복제본은 기본 Azure SignalR Service 리소스의 구성을 유지합니다.

필수 조건

• 프리미엄 계층의 An Azure SignalR Service

사용 사례

Contoso는 고객 기반이 미국과 캐나다에 분포되어 있는 소셜 미디어 회사입니다. Contoso는 이러한 고객에게 서비스를 제공하고 서로 통신할 수 있도록 하기 위해 미국 중부에서 서비스를 실행합니다. Azure SignalR Service는 사용자 연결을 처리하고 사용자 간의 통신을 용이하게 하는 데 사용됩니다. Contoso의 최종 사용자는 대부분 전화 사용자입니다. 지리적 거리가 멀기 때문에 캐나다의 최종 사용자는 대기 시간이 길고 네트워크 품질이 저하될 수 있습니다.

지역에서 복제 기능이 도입되기 전에 Contoso는 캐나다 사용자에게 서비스를 제공하기 위해 캐나다 중부에 또 다른 Azure SignalR Service를 설정할 수 있습니다. 지리적으로 더 가까운 Azure SignalR Service를 설정함으로써 최종 사용자의 경우 이제 네트워크 품질이 향상되고 대기 시간이 단축됩니다.

그러나 여러 Azure SignalR Service를 관리하면 몇 가지 문제가 발생합니다.

1. 캐나다와 미국 사용자 간의 대화를 사용하려면 지역 간 통신 메커니즘이 필요합니다.
2. 개발 팀은 각각 고유한 도메인 및 연결 문자열이 있는 두 개의 별도 Azure SignalR Service를 관리해야 합니다.
3. 지역 가동 중단이 발생하면 트래픽을 다른 지역으로 전환해야 합니다.

지역 복제 활용

Contoso는 새로운 지리적 복제 기능을 통해 캐나다 중부에 복제본을 설정하여 위에서 언급한 문제를 효과적으로 극복할 수 있습니다.

SignalR 복제본 만들기

포털

복제본을 만들려면 Azure Portal에서 SignalR 복제본 블레이드로 이동하고 추가를 클릭하여 복제본을 만듭니다. 생성 시 자동으로 사용하도록 설정됩니다.

만든 후에는 복제본 이름을 클릭하여 포털에서 복제본을 보거나 편집할 수 있습니다.

Bicep

Visual Studio Code 또는 즐겨 사용하는 편집기를 사용하여 다음 콘텐츠가 포함된 파일을 만들고 이름을 main.bicep으로 지정합니다.

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Azure CLI를 사용하여 Bicep 파일 배포

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

가격 책정 및 리소스 단위

각 복제본에는 고유한unit 및 autoscale settings가 있습니다.

복제본은 Azure SignalR Service의 프리미엄 계층 기능입니다. 각 복제본은 자체 단위 및 아웃바운드 트래픽에 따라 별도로 비용이 청구됩니다. 무료 메시지 할당량도 별도로 계산됩니다.

앞의 예제에서 Contoso는 캐나다 중부에 하나의 복제본을 추가했습니다. Contoso는 프리미엄 가격의 단위 및 메시지에 따라 캐나다 중부의 복제본에 대한 비용을 지불합니다.

지역 간 아웃바운드 트래픽에 대해 송신 요금이 발생하게 될 것입니다. 메시지가 복제본 및 간에 전송되고 전송 후 클라이언트 또는 서버로 성공적으로 전송되는 경우 아웃바운드 메시지로서 요금이 청구됩니다.

복제본 삭제

Azure SignalR Service에 대한 복제본을 만든 후에는 더 이상 필요하지 않은 경우 언제든지 삭제할 수 있습니다.

Azure Portal에서 복제본을 삭제하려면 다음을 수행합니다.

1. Azure SignalR Service로 이동하고 복제본 블레이드를 선택합니다. 삭제할 복제본을 클릭합니다.
2. 복제본 개요 블레이드에서 삭제 단추를 클릭합니다.

SignalR 복제본의 작동 방식 이해

아래 다이어그램에서는 SignalR 복제본의 기능을 간략하게 설명합니다.

1. 클라이언트는 앱 서버와 협상하고 Azure SignalR Service로의 리디렉션을 받습니다. 그런 다음, SignalR Service의 FQDN(정규화된 도메인 이름) contoso.service.signalr.net을 확인합니다. 이 FQDN은 Traffic Manager를 가리키며, 결과적으로 가장 가까운 지역 SignalR 인스턴스의 CNAME(정식 이름)이 반환됩니다.
2. 이 CNAME을 사용하여 클라이언트는 지역 인스턴스(복제본)에 대한 연결을 설정합니다.
3. 두 복제본은 데이터를 서로 동기화합니다. 한 복제본으로 전송된 메시지는 필요한 경우 다른 복제본으로 전송됩니다.
4. 복제본이 TM(Traffic Manager)에서 수행하는 상태 검사에 실패하는 경우 TM은 실패한 인스턴스의 엔드포인트를 도메인 확인 프로세스에서 제외합니다. 자세한 내용은 아래의 복원력 및 재해 복구를 참조하세요.

참고 항목

• 데이터 평면에서 기본 Azure SignalR 리소스는 복제본과 동일하게 작동합니다.

복원력 및 재해 복구

Azure SignalR Service는 Traffic Manager를 사용하여 복제본에 대한 상태 검사 및 DNS 확인을 수행합니다. 정상적인 상황에서는 모든 복제본이 제대로 작동하면 클라이언트가 가장 가까운 복제본으로 전송합니다. 예를 들면 다음과 같습니다.

• eastus에 가까운 클라이언트는 eastus에 있는 복제본으로 전송합니다.
• 마찬가지로 westus에 가까운 클라이언트는 westus의 복제본으로 전송합니다.

미국 동부에서 지역 가동 중단이 발생하는 경우(아래 그림 참조) Traffic Manager는 해당 지역의 상태 검사 실패를 검색합니다. 그런 다음, 이 결함이 있는 복제본의 DNS가 Traffic Manager의 DNS 확인 결과에서 제외됩니다. 90초로 설정된 DNS TTL(Time-to-Live) 기간이 지나면 eastus의 클라이언트가 westus의 복제본에 연결하도록 리디렉션됩니다.

eastus의 문제가 해결되고 지역이 다시 온라인 상태가 되면 상태 검사가 성공합니다. 그러면 eastus의 클라이언트가 다시 한 번 해당 지역의 복제본으로 전송합니다. 연결된 클라이언트는 기존 연결을 닫을 때까지 영향을 받지 않으므로 이 전환은 원활하게 진행됩니다.

이 장애 조치(failover) 및 복구 프로세스는 자동이며 수동 개입이 필요하지 않습니다.

서버 연결의 경우 장애 조치 및 복구는 클라이언트 연결과 동일한 방식으로 작동합니다.

참고 항목

• 이 장애 조치 메커니즘은 Azure SignalR Service에 대한 것입니다. 앱 서버의 지역 가동 중단은 이 문서에서 다루지 않습니다.

복제본 엔드포인트 사용 안 함 또는 사용

복제본을 설정할 때 해당 엔드포인트를 사용하거나 사용하지 않도록 설정하는 옵션이 있습니다. 이 기능을 사용하지 않도록 설정하면 기본 FQDN의 DNS 확인에 복제본이 포함되지 않으므로 트래픽이 해당 복제본으로 전달되지 않습니다.

엔드포인트를 만든 후 사용하지 않도록 설정할 수도 있습니다. 주 리소스의 복제본 블레이드에서 복제본의 오른쪽에 있는 줄임표 단추를 클릭하고 엔드포인트 사용 또는 엔드포인트 사용 안 함을 선택합니다.

복제를 삭제하기 전에 먼저 엔드포인트를 사용하지 않도록 설정하는 것이 좋습니다. 시간이 지남에 따라 기존 연결이 끊어집니다. 새 연결이 설정되지 않으면 복제가 마침내 유휴 상태가 됩니다. 이렇게 하면 원활한 삭제 프로세스가 보장됩니다.

이 기능은 지역 문제를 해결하는 데에도 유용합니다.

참고 항목

• DNS 캐시로 인해 DNS 업데이트가 적용되는 데 몇 분 정도 걸릴 수 있습니다.
• 기존 연결은 연결을 끊을 때까지 영향을 받지 않습니다.

복제본을 추가한 후 성능에 미치는 영향

복제본을 사용하도록 설정하면 클라이언트는 지리적 위치에 따라 자연스럽게 배포됩니다. SignalR은 이러한 복제본 간에 데이터를 동기화하는 책임을 맡지만, 가장 일반적인 사용 사례에 대해 서버 로드의 관련 오버헤드가 최소화된다는 사실을 알고 만족스러워할 것입니다.

특히 애플리케이션이 일반적으로 더 큰 그룹(크기 > 10) 또는 단일 연결로 브로드캐스트하는 경우 동기화의 성능 영향은 거의 눈에 띄지 않습니다. 소규모 그룹(크기 < 10) 또는 개별 사용자를 메시징하는 경우 동기화 오버헤드가 약간 더 발생할 수 있습니다.

효과적인 장애 조치 관리를 보장하려면 모든 트래픽을 처리하도록 각 복제본의 단위 크기를 설정하는 것이 좋습니다. 또는 자동 스케일링을 사용하도록 설정하여 이 작업을 관리할 수 있습니다.

성능 평가에 대한 자세한 내용은 성능을 참조하세요.