Azure Web PubSub의 복원력 및 재해 복구
복원력 및 재해 복구는 온라인 시스템에 공통적으로 필요합니다. Azure Web PubSub Service는 이미 99.9% 가용성을 보장하지만 여전히 지역 서비스에 불과합니다. 지역 전체 중단이 있는 경우 서비스가 다른 지역에서 실시간 메시지를 계속 처리하는 것이 중요합니다.
지역 재해 복구의 경우 다음 두 가지 방식을 권장합니다.
- 지역 복제를 사용하도록 설정합니다(쉬운 방법). 이 기능은 자동으로 지역 장애 조치(failover)를 처리합니다. 사용하도록 설정되면 Azure SignalR 인스턴스가 하나만 남아 있으며 코드 변경 내용이 적용되지 않습니다. 자세한 내용은 지역 복제를 확인합니다.
- 여러 엔드포인트를 활용합니다. 이 문서에서 그 방법을 알아봅니다.
Web PubSub 서비스에 대한 고가용성 아키텍처
Web PubSub 서비스를 사용하는 두 가지 일반적인 패턴이 있습니다.
- 하나는 클라이언트가 서버에 이벤트를 보내고서버가 클라이언트에 메시지를 푸시하는 클라이언트-서버 패턴입니다.
- 또 다른 하나는 Web PubSub 서비스를 통해 클라이언트가 pub/sub 메시지를 다른 클라이언트에 전달하는 클라이언트-클라이언트 패턴입니다.
아래 섹션에서는 이러한 두 패턴이 재해 복구를 수행하는 다양한 방법을 설명합니다.
클라이언트-서버 패턴에 대한 고가용성 아키텍처
Web PubSub Service에 대한 지역 간 복원력을 위해서는 다른 지역에서 여러 서비스 인스턴스를 설정해야 합니다. 그러면 하나의 지역이 다운되는 경우 다른 지역을 백업으로 사용할 수 있습니다.
지역 간 시나리오에 대한 한 가지 일반적인 설정은 Web PubSub Service 인스턴스와 앱 서버의 쌍을 두 개(또는 이상) 가지는 것입니다.
각 쌍 앱 서버와 Web PubSub 서비스는 동일한 지역에 있으며 Web PubSub 서비스는 이벤트 처리기를 동일한 지역의 앱 서버로 업스트림으로 설정합니다.
아키텍처를 더 잘 설명하기 위해 Web PubSub 서비스를 동일한 쌍의 앱 서버에 대한 기본 서비스라고 합니다. 또한 다른 쌍의 Web PubSub 서비스를 앱 서버에 대한 보조 서비스로 호출합니다.
애플리케이션 서버는 서비스 상태 검사 API 를 사용하여 기본 및 보조 서비스가 정상인지 여부를 검색할 수 있습니다. 예를 들어 라는 demoWeb PubSub 서비스의 경우 서비스가 정상이면 엔드포인트 https://demo.webpubsub.azure.com/api/health 가 200을 반환합니다. 앱 서버는 주기적으로 엔드포인트를 호출하거나 요청 시 엔드포인트를 호출하여 엔드포인트가 정상인지 확인할 수 있습니다. WebSocket 클라이언트는 일반적으로 먼저 해당 애플리케이션 서버와 협상 하여 WEB PubSub 서비스에 연결하는 URL을 가져오며, 애플리케이션은 이 협상 단계를 사용하여 클라이언트를 다른 정상 보조 서비스로 장애 조치(failover)합니다. 아래와 같은 자세한 단계:
- 클라이언트가 앱 서버와 협상 할 때 앱 서버는 기본 Web PubSub 서비스 엔드포인트만 반환해야 하므로 일반적인 경우 클라이언트는 기본 엔드포인트에만 연결합니다.
- 주 인스턴스가 다운된 경우 협상 은 클라이언트가 여전히 연결을 만들고 클라이언트가 보조 엔드포인트에 연결할 수 있도록 정상 보조 엔드포인트를 반환해야 합니다.
- 주 인스턴스가 설정되면 클라이언트가 이제 기본 엔드포인트에 연결할 수 있도록 협상 에서 정상 기본 엔드포인트를 반환해야 합니다.
- 앱 서버는 메시지를 브로드캐스트할 때 기본 및 보조를 포함한 모든 정상 엔드포인트에 메시지를 브로드캐스트해야 합니다.
- 앱 서버는 보조 엔드포인트에 연결된 연결을 닫아 클라이언트가 정상 기본 엔드포인트에 다시 연결되도록 할 수 있습니다.
이 토폴로지를 통해 모든 앱 서버와 Web PubSub 서비스 인스턴스가 서로 연결되므로 한 서버의 메시지를 모든 클라이언트에 계속 배달할 수 있습니다.
아직 전략을 SDK에 통합하지 않았으므로 지금은 애플리케이션이 이 전략을 자체 구현해야 합니다.
요약하면 애플리케이션 쪽에서 구현해야 하는 것은 다음과 같습니다.
- 상태 검사. 애플리케이션은 백그라운드에서 주기적으로 또는 모든 협상 호출에 대해 요청 시 서비스 상태 검사 API를 사용하여 서비스가 정상인지 확인할 수 있습니다.
- 논리를 협상합니다. 애플리케이션은 기본적으로 정상 기본 엔드포인트 를 반환합니다. 기본 엔드포인트가 다운되면 애플리케이션은 정상 보조 엔드포인트를 반환합니다.
- 브로드캐스트 논리. 메시지가 여러 클라이언트로 전송되는 경우 애플리케이션은 모든 정상 엔드포인트에 메시지를 브로드캐스트해야 합니다.
다음은 이러한 토폴로지를 보여주는 다이어그램입니다.
장애 조치(Failover) 시퀀스와 모범 사례
이제 올바른 시스템 토폴로지 설정이 완료되었습니다. 하나의 Web PubSub 서비스 인스턴스가 다운될 때마다 온라인 트래픽은 다른 인스턴스로 라우팅됩니다. 기본 인스턴스가 다운되는 경우 다음과 같은 상황이 발생합니다(그리고 얼마 후 복구됨).
- 기본 서비스 인스턴스가 다운되면 이 인스턴스의 모든 서버 연결이 삭제됩니다.
- 새 클라이언트 또는 다시 연결 클라이언트가 앱 서버와 협상
- 앱 서버는 주 서비스 인스턴스가 다운된 것을 감지하고 협상에서 이 엔드포인트 반환을 중지하고 정상 보조 엔드포인트 반환을 시작합니다.
- 클라이언트는 보조 인스턴스에 연결합니다.
- 이제 보조 인스턴스가 모든 온라인 트래픽을 사용하게 됩니다. 보조가 모든 앱 서버에 연결되므로 서버에서 클라이언트로 가는 모든 메시지는 계속 배달될 수 있습니다. 하지만 클라이언트에서 서버로 가는 메시지는 동일한 지역에 있는 앱 서버로만 라우팅됩니다.
- 주 인스턴스가 복구되고 다시 온라인 상태가 된 후 앱 서버는 주 인스턴스가 정상으로 돌아온 것을 감지합니다. 새로운 클라이언트가 기본에 다시 연결되므로 이제 협상은 기본 엔드포인트를 다시 반환합니다. 하지만 기존 클라이언트는 삭제되지 않으며 자체 연결을 차단할 때까지 보조로 계속 라우팅됩니다.
아래 다이어그램은 Web PubSub 서비스에서 장애 조치가 수행되는 방법을 보여줍니다.
그림 1 장애 조치(failover) 전 
그림 2 장애 조치(failover) 후 
그림 3 기본 복구 후 짧은 시간 
정상 사례에서 볼 수 있듯이 기본 앱 서버 및 Web PubSub 서비스만 온라인 트래픽을 가집니다(파란색).
장애 조치(failover) 후 보조 앱 서버 및 Web PubSub 서비스도 활성화됩니다. 기본 Web PubSub 서비스가 다시 온라인 상태가 되면 새 클라이언트가 기본 Web PubSub에 연결됩니다. 하지만 기존 클라이언트는 두 인스턴스 모두에 트래픽이 있으므로 계속 보조에 연결됩니다.
모든 기존 클라이언트 연결이 끊긴 후, 시스템은 정상으로 돌아갑니다(그림 1).
지역 간 고가용성 아키텍처를 구현하기 위한 두 가지 주요 패턴이 있습니다.
- 첫 번째는 모든 온라인 트래픽을 사용하는 앱 서버와 Web PubSub 서비스의 쌍을 갖고, 백업으로 다른 쌍을 확보하는 것입니다(활성/수동이라고 함, 그림 1에서 설명됨).
- 다른 하나는 앱 서버와 Web PubSub 서비스 인스턴스의 쌍이 두 개(또는 이상)인 것입니다. 각각 온라인 트래픽의 일부를 사용하며 다른 쌍에 대한 백업 역할을 합니다(활성/활성이라고 함, 그림 3과 유사).
Web PubSub 서비스는 두 패턴을 모두 지원하며 주요 차이점은 앱 서버를 구현하는 방법입니다. 앱 서버가 활성/수동인 경우 Web PubSub 서비스는 활성/수동이 될 수 있습니다(기본 앱 서버는 해당 기본 Web PubSub 서비스 인스턴스만 반환하므로). 앱 서버가 활성/활성인 경우 Web PubSub 서비스는 활성/활성이 될 수 있습니다(모든 앱 서버는 자체 기본 Web PubSub 인스턴스를 반환하므로 모두 트래픽을 받을 수 있음).
사용하도록 선택한 패턴이 무엇인지 확인하세요. 각 SignalR Service 인스턴스를 기본으로 앱 서버에 연결해야 합니다.
또한 WebSocket 연결의 특성상(긴 연결임) 재해 및 장애 조치(failover)가 발생하는 경우 클라이언트에서 연결이 끊깁니다. 최종 고객에게 명료하도록 그러한 경우를 클라이언트 쪽에서 처리해야 합니다. 예를 들어 연결을 닫은 후 다시 연결을 수행합니다.
클라이언트-클라이언트 패턴에 대한 고가용성 아키텍처
클라이언트-클라이언트 패턴의 경우 현재 여러 인스턴스를 사용하여 가동 중지 시간 없는 재해 복구를 지원할 수 없습니다. 고가용성 요구 사항이 있는 경우 지역에서 복제를 사용하는 것이 좋습니다.
장애 조치(failover)를 테스트하는 방법
장애 조치(failover)를 트리거하려면 다음 단계를 따릅니다.
- 포털의 기본 리소스에 대한 네트워킹 탭에서 공용 네트워크 액세스를 사용하지 않도록 설정합니다. 리소스에 개인 네트워크가 사용하도록 설정된 경우 액세스 제어 규칙을 사용하여 모든 트래픽을 거부합니다.
- 기본 리소스를 다시 시작합니다.
다음 단계
이 문서에서는 Web PubSub Service에 대한 복원력을 달성하기 위해 애플리케이션을 구성하는 방법을 알아보았습니다.
다음 리소스를 사용하여 사용자 고유의 애플리케이션 빌드를 시작합니다.