다음을 통해 공유

Azure Communications Gateway의 안정성

  • 아티클

Azure Communications Gateway는 Azure 중복 메커니즘 및 SIP 관련 재시도 동작을 사용하여 서비스를 안정적으로 유지합니다. 네트워크는 서비스 가용성을 보장하기 위해 특정 요구 사항을 충족해야 합니다.

Azure Communications Gateway의 중복성 모델

프로덕션 Azure Communications Gateway 배포(표준 배포라고도 함)는 세 개의 개별 지역, 즉 관리 지역과 두 개의 서비스 지역으로 구성됩니다. 랩 배포는 하나의 관리 지역과 하나의 서비스 지역으로 구성됩니다.

이 문서에서는 서로 다른 두 지역 유형과 고유한 중복 모델에 대해 설명합니다. 가용성 영역의 지역 안정성과 재해 복구를 통해 지역 간 안정성을 모두 다룹니다. Azure의 안정성에 대한 포괄적인 개요는 Azure 안정성을 참조하세요.

두 개의 서비스 지역, 즉 관리 지역과 두 개의 운영자 사이트를 보여주는 다이어그램.

서비스 지역

서비스 지역에는 네트워크와 선택한 통신 서비스 간의 트래픽을 처리하는 데 사용되는 음성 및 API 인프라가 포함되어 있습니다.

프로덕션 Azure Communications Gateway 배포에는 활성-활성 모드(운영자 연결 및 Teams 전화 모바일 프로그램에 필요한 대로)로 배포되는 두 개의 서비스 지역이 있습니다. 서비스 지역 간의 빠른 장애 조치(failover)는 인프라/IP 수준 및 애플리케이션(SIP/RTP/HTTP) 수준에서 제공됩니다.

서비스 지역에는 Azure Communications Gateway의 프로비전 API에 대한 인프라도 포함되어 있습니다.

팁

선택한 서비스 지역 중 하나가 단일 지역 Azure 지리(예: 카타르)에 있더라도 프로덕션 배포에는 항상 두 개의 서비스 지역이 있어야 합니다. 단일 지역 Azure Geography를 선택하는 경우 다른 Azure Geography에서 두 번째 Azure 지역을 선택합니다.

서비스 지역은 작업에서 동일하며 영역 및 지역 오류 모두에 대한 복원력을 제공합니다. 각 서비스 지역은 Azure Communications Gateway instance를 사용하여 트래픽의 100%를 전송할 수 있습니다. 따라서 최종 사용자는 영역 또는 지역 가동 중지 시간 동안 통화를 성공적으로 수행하고 받을 수 있어야 합니다.

랩 배포에는 하나의 서비스 지역이 있습니다.

통화 라우팅 요구 사항

Azure Communications Gateway는 '성공적인 다시 실행' 중복 모델을 제공합니다. 실패한 피어에 의해 처리된 호출은 종료되지만 새 호출은 정상 피어로 라우팅됩니다. 이 모델은 Microsoft Teams에서 제공하는 중복 모델을 미러링합니다.

프로덕션 배포의 경우 네트워크에 지리적으로 중복된 두 사이트가 있을 것으로 예상됩니다. 각 사이트는 Azure Communications Gateway 지역과 페어링되어야 합니다. 중복 모델은 네트워크와 Azure Communications Gateway 서비스 지역 간의 교차 연결에 의존합니다.

2개의 운영 사이트와 2개의 서비스 지역을 보여 주는 다이어그램. 두 서비스 지역 모두 기본 경로와 보조 경로를 통해 두 사이트에 연결됩니다.

랩 배포는 네트워크의 한 사이트에 연결되어야 합니다.

각 Azure Communications Gateway 서비스 지역은 SRV 레코드를 제공합니다. 이 레코드에는 지역 내에서 SBC 기능(통신 서비스에 대한 호출 라우팅용)을 제공하는 모든 SIP 피어가 포함되어 있습니다. 이 SRV 레코드는 온보딩 팀이 제공한 /28 IP 범위의 모든 IP 주소를 가리킬 수 있습니다.

Azure Communications Gateway에 MCP(이동제어점)가 포함된 경우 각 서비스 지역은 MCP에 대한 추가 SRV 레코드를 제공합니다. 각 지역별 MCP 레코드에는 우선 순위가 가장 높은 지역 내의 MCP와 낮은 우선 순위에 있는 다른 지역의 MCP가 포함됩니다.

네트워크의 각 사이트는 다음을 수행해야 합니다.

  • 기본적으로 로컬 Azure Communications Gateway 서비스 지역으로 트래픽을 보냅니다.
  • RFC 3263에 설명된 대로 DNS SRV를 사용하여 지역 내에서 Azure Communications Gateway 피어를 찾습니다.
    • _sip._tls.<regional-FQDN-from-portal>을 사용하여 서비스 지역과 네트워크 연결을 위한 도메인 이름에서 DNS SRV 조회를 수행합니다. <regional-FQDN-from-portal>을 Azure Portal 리소스에 대한 개요 페이지의 호스트 이름 필드에 있는 지역별 FQDN으로 바꿉니다. 예를 들어, 배포에서 commsgw.azure.com 도메인 이름을 사용하는 경우 첫 번째 지역에 대해 _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com을 검색합니다.
    • SRV 조회가 여러 대상을 반환하는 경우 각 대상의 가중치와 우선 순위를 사용하여 단일 대상을 선택합니다.
  • 사용 가능한 Azure Communications Gateway 피어에 새 호출을 보냅니다.
  • Azure Communications Gateway와 연결된 각 IP 범위의 모든 IP 주소에서 트래픽을 수신할 수 있습니다.

네트워크에서 SBC 함수에 대한 Azure Communications Gateway의 SIP 피어에 호출을 라우팅하는 경우 다음을 수행해야 합니다.

  • SIP 옵션(또는 OPTIONS 및 SIP 트래픽의 조합)을 사용하여 Azure Communications Gateway SIP 피어의 가용성을 모니터링합니다.
  • 응답 408, 응답 503이나 504를 받거나 또는 응답을 받지 못한 INVITE를 로컬 사이트의 다른 사용 가능한 피어로 다시 라우팅하여 다시 시도합니다. 로컬 서비스 지역의 모든 피어가 실패한 경우에만 다른 서비스 지역(다른 지역의 SRV 레코드에 의해 정의됨)으로 헌팅합니다.
  • 408, 503 및 504 이외의 오류 응답을 수신하는 호출을 다시 시도하지 마세요.

Azure Communications Gateway 배포에 MCP(이동제어점)가 포함된 경우 네트워크는 MCP에 대해 다음과 같이 수행해야 합니다.

  • 지역의 MCP를 사용할 수 없는 경우를 검색하고, 해당 지역의 SRV 레코드에 대한 대상을 사용할 수 없음으로 표시하고, 지역이 다시 사용 가능한 시기를 확인하기 위해 주기적으로 재시도합니다. MCP는 SIP OPTIONS에 응답하지 않습니다.
  • 조직의 정책에 따라 MCP의 5xx 응답을 처리합니다. 예를 들어 요청을 다시 시도하거나 Azure Communications Gateway를 통과하지 않고 Microsoft Phone System으로 통화를 계속하도록 허용할 수 있습니다.

이 라우팅 동작의 세부 정보는 네트워크에 따라 다릅니다. 통합 프로젝트 중에 온보딩 팀과 동의해야 합니다.

관리 지역

관리 지역에는 Azure Communications Gateway의 주문, 모니터링 및 청구에 사용되는 인프라가 포함되어 있습니다. 이러한 지역 내의 모든 인프라는 영역 중복 방식으로 배포됩니다. 즉, 모든 데이터가 지역 내의 각 가용성 영역에 자동으로 복제됩니다. 모든 중요한 구성 데이터는 Azure 지역 오류 발생 시 서비스의 적절한 작동을 보장하기 위해 각 서비스 지역에 복제됩니다.

가용성 영역 지원

Azure 가용성 영역은 각 Azure 지역 내에서 물리적으로 분리된 세 개 이상의 데이터 센터 그룹입니다. 각 영역 내의 데이터 센터에는 독립적인 전원, 냉각, 네트워킹 인프라가 장착되어 있습니다. 가용성 영역은 로컬 영역이 실패한 경우에 한 영역이 영향을 받는 경우 나머지 두 영역에서 지역 서비스, 용량 및 고가용성을 지원하도록 설계되었습니다.

오류는 소프트웨어 및 하드웨어 오류에서 지진, 홍수 및 화재와 같은 이벤트에 이르기까지 다양합니다. Azure 서비스의 중복성과 논리적 격리로 인해 오류 허용성에 도달합니다. Azure의 가용성 영역에 대한 자세한 내용은 지역 및 가용성 영역을 참조하세요.

Azure 가용성 영역 지원 서비스는 적절한 수준의 복원력과 유연성을 제공하도록 설계되었습니다. 두 가지 방법으로 구성할 수 있습니다. 영역 간 자동 복제를 사용하는 영역 중복 또는 특정 영역에 고정된 인스턴스를 사용하는 영역일 수 있습니다. 이러한 방식을 결합할 수도 있습니다. 영역 및 영역 중복 아키텍처에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.

서비스 지역에 대한 영역 다운 환경

영역 전체 가동 중단 중에 영향을 받는 영역에서 처리하는 호출이 종료되고, 서비스의 자체 복구가 기본 리소스를 정상 영역으로 재조정할 때까지 지역 내에서 용량이 잠시 손실됩니다. 이 자동 복구는 영역 복원에 의존하지 않습니다. Microsoft 관리형 서비스 자동 복구 상태는 다른 영역의 용량을 사용하여 손실된 영역을 보완합니다. 리소스를 운반하는 트래픽은 영역 중복 방식으로 배포되지만 가장 낮은 규모의 트래픽은 단일 리소스에서 처리될 수 있습니다. 이 경우 이 문서에 설명된 장애 조치(failover) 메커니즘은 트래픽을 전송하는 리소스가 정상 영역에서 다시 배포되는 동안 모든 트래픽을 다른 서비스 지역으로 리밸런스합니다.

관리 지역에 대한 영역 다운 환경

영역 전체 가동 중단 동안에는 영역 복구 중에 아무 작업도 필요하지 않습니다. 관리 지역은 정상 영역을 자동으로 활용하기 위해 자체적으로 치유되고 균형을 조정합니다.

재해 복구: 다른 지역으로 대체

DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.

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

이 섹션에서는 지역 전체 중단 시 Azure Communications Gateway의 동작에 대해 설명합니다.

재해 복구: 서비스 지역에 대한 지역 간 장애 조치(failover)

지역 전체 가동 중단 시 이 문서에 설명된 장애 조치(failover) 메커니즘(옵션 폴링 및 실패 시 SIP 재시도)은 모든 호출 트래픽을 다른 서비스 지역으로 재조정하여 가용성을 유지합니다. 지역 중복성 복원을 시작합니다. 연장된 가동 중지 시간 동안 지역 중복성을 복원하려면 다른 Azure 지역을 사용해야 할 수 있습니다. 실패한 지역을 다른 지역으로 마이그레이션해야 하는 경우 마이그레이션을 시작하기 전에 문의해 드리겠습니다.

Azure Communications Gateway의 SBC 함수는 네트워크에서 피어 가용성을 확인할 수 있도록 OPTIONS 폴링을 제공합니다. MCP의 경우 네트워크에서 MCP를 사용할 수 없는 시기를 검색하고 주기적으로 다시 시도하여 MCP를 다시 사용할 수 있는 시기를 확인할 수 있어야 합니다. MCP는 SIP OPTIONS에 응답하지 않습니다.

프로비전 API 클라이언트는 배포에 대한 기본 도메인 이름을 사용하여 Azure Communications Gateway에 연결합니다. 이 도메인의 DNS 레코드에는 TTL(Time to Live)이 60초입니다. 지역에 오류가 발생하면 Azure는 다른 지역을 참조하도록 DNS 레코드를 업데이트하므로 새 DNS 조회를 수행하는 클라이언트는 새 지역의 세부 정보를 받습니다. 클라이언트가 새 DNS 조회를 수행하고 시간 제한 또는 5xx 응답 후 60초 후에 요청을 다시 시도할 수 있도록 하는 것이 좋습니다.

팁

랩 배포는 서비스 지역이 하나만 있기 때문에 지역 간 장애 조치(failover)를 제공하지 않습니다.

재해 복구: 관리 지역에 대한 지역 간 장애 조치(failover)

번호 관리 포털을 통한 음성 트래픽 및 프로비저닝은 해당 Azure 리소스가 서비스 지역에서 호스트되기 때문에 관리 지역의 오류에 영향을 받지 않습니다. 번호 관리 포털의 사용자는 다시 로그인해야 할 수 있습니다.

서비스가 복원될 때까지 모니터링 서비스를 일시적으로 사용할 수 없습니다. 관리 지역에서 가동 중지 시간이 길어지면 영향을 받은 리소스를 사용 가능한 다른 지역으로 마이그레이션합니다.

관리 및 서비스 지역 선택

Azure Communications Gateway의 단일 배포는 지리적 영역 내에서 트래픽을 처리하도록 설계되었습니다. 동일한 지리적 영역(예: 북아메리카) 내의 프로덕션 배포에 두 서비스 지역을 모두 배포합니다. 이 모델을 사용하면 음성 통화 대기 시간이 Operator Connect 및 Teams Phone Mobile 프로그램에 필요한 한도 내에서 유지됩니다.

서비스 지역 위치를 선택할 때 다음 사항을 고려합니다.

  • 사용 가능한 Azure 지역 목록에서 선택합니다. 지역별 제품 페이지에서 서비스 지역으로 선택할 수 있는 Azure 지역을 볼 수 있습니다.
  • 사용자 고유의 프레미스와 가까운 지역 및 네트워크와 Microsoft 간의 피어링 위치를 선택하여 통화 대기 시간을 줄입니다.
  • 다중 지역 중단이 발생하는 경우 복구 시간을 최소화하려면 지역 쌍을 사용하는 것이 좋습니다.

다음 목록에서 관리 지역을 선택합니다.

  • 미국 동부
  • 미국 중서부
  • 서유럽
  • 영국 남부
  • 인도 중부
  • 캐나다 중부
  • 오스트레일리아 동부

관리 지역은 서비스 지역과 공동 배치할 수 있습니다. 서비스 지역에 가장 가까운 관리 지역을 선택하는 것이 좋습니다.

참고 항목

Azure 연산자 콜 보호 미리 보기를 사용하도록 설정하는 경우 선택한 서비스 지역은 지원 리소스가 배포되는 Azure 지역이 아닐 수 있습니다. 현재 지원되는 Azure 연산자 콜 보호 서비스 지역 목록은 지역별 Azure 제품을 참조하고, 어떤 지역이 선택되었는지에 대한 질문이 있는 경우 온보딩 팀에 문의하세요.

서비스 수준 약정

이 문서에 설명된 안정성 디자인은 Microsoft에서 구현하며 구성할 수 없습니다. Azure Communications Gateway SLA(서비스 수준 계약)에 대한 자세한 내용은 Azure Communications Gateway SLA를 참조하세요.

다음 단계