Microsoft Teams에서 QoS(서비스 품질) 구현
이 문서는 Microsoft Teams에서 QoS(서비스 품질)를 구현하는 관리자 및 IT 전문가를 위한 것입니다.
Microsoft Teams의 QoS(서비스 품질)를 사용하면 덜 민감한 트래픽보다 네트워크 지연에 민감한 실시간 네트워크 트래픽의 우선 순위를 지정할 수 있습니다. 예를 들어 새 앱 다운로드보다 음성 및 비디오 스트림의 우선 순위를 지정합니다(다운로드할 추가 시간이 눈에 띄지 않는 경우).
QoS는 DSCP(차별화된 서비스 코드 포인트) 표시를 포트 기반 ACL(Access Control Lists)과 함께 사용하여 실시간 스트림에서 모든 패킷을 식별, 표시 및 분류합니다. 이렇게 하면 음성, 비디오 및 화면 공유 스트림이 다른 유형의 트래픽을 희생하여 우선적으로 처리됩니다.
어떤 형태의 QoS가 없으면 음성 및 비디오에서 다음과 같은 품질 문제가 표시될 수 있습니다.
지터 – 미디어 패킷은 서로 다른 속도로 도착하므로 호출 시 단어나 음절이 누락됩니다.
패킷 손실 – 패킷이 삭제되어 음성 품질이 낮아지고 음성을 이해하기 어려울 수도 있습니다.
지연된 RTT(왕복 시간) – 미디어 패킷이 목적지에 도달하는 데 시간이 오래 걸리며, 이로 인해 대화에서 두 당사자 간에 눈에 띄는 지연이 발생하며 사람들이 서로 대화하게 됩니다.
이 문서에 설명된 문제가 발생하는 대규모 사용자 그룹을 지원하는 경우 QoS를 구현해야 합니다. 사용자가 거의 없는 소규모 비즈니스에서는 QoS가 필요하지 않을 수 있지만 네트워크 지연이 발생하는 경우 고려해야 합니다.
이러한 문제를 해결하는 가장 복잡한 방법은 내부적으로나 인터넷으로 데이터 연결의 크기를 늘리는 것이지만, 이 방법은 비용이 많이 드는 경우가 많습니다. QoS를 사용하면 대역폭을 추가하는 대신 가지고 있는 리소스를 관리할 수 있습니다. 품질 문제를 해결하려면 먼저 QoS를 사용한 다음 필요한 경우 대역폭을 추가하는 것이 좋습니다.
QoS가 효과적이려면 organization 전체에서 일관된 QoS 설정을 적용해야 합니다. QoS 우선 순위를 지원하지 않는 경로의 모든 부분은 통화, 비디오 및 화면 공유의 품질을 저하시킬 수 있습니다. 모든 사용자 PC 또는 디바이스, 네트워크 스위치, 라우터를 인터넷에 적용하고 Teams 서비스에 설정을 적용해야 합니다.
그림 1. organization 네트워크와 Microsoft 365 또는 Office 365 서비스 간의 관계
QoS 구현 검사 목록
다음 검사 목록은 QoS를 구현하는 데 필요한 단계에 대한 개요를 제공합니다. 이 단계는 이 문서 전체에서 자세히 설명합니다.
클라이언트, 라우터, 미디어 트래픽에 대한 QoS 설정을 구현합니다.
네트워크에서 Teams 트래픽을 분석하여 QoS 구현의 유효성을 검사합니다.
다음 지침에 유의하세요.
- Microsoft 365의 가장 짧은 경로가 가장 좋습니다.
- 포트를 닫으면 품질이 저하됩니다.
- 프록시와 같은 그 사이에 있는 장애물은 권장되지 않습니다.
- 홉 수를 제한합니다.
- 클라이언트-네트워크 에지 – 3~5개의 홉
- ISP에서 Microsoft 네트워크 에지까지 – 3개의 홉
- 최종 대상에 대한 Microsoft 네트워크 에지 – 관련이 없음
방화벽 포트를 구성하는 방법에 대한 자세한 내용은 Office 365 URL 및 IP 범위를 참조하세요.
QoS 큐 소개
QoS를 제공하려면 네트워크 디바이스에 트래픽을 분류하는 방법이 있어야 하며 음성 또는 비디오를 다른 네트워크 트래픽과 구분할 수 있어야 합니다.
네트워크 트래픽이 라우터에 들어가면 트래픽이 큐에 배치됩니다. QoS 정책이 구성되지 않은 경우 큐가 하나만 있고 모든 데이터는 우선 순위가 동일한 첫 번째 실행으로 처리됩니다. 즉, 음성 트래픽(지연에 매우 민감)은 몇 밀리초의 추가 지연이 문제가 되지 않는 트래픽 뒤에 갇히게 될 수 있습니다.
QoS를 구현할 때 Cisco의 우선 순위 큐 및 CBWFQ(클래스 기반 가중 공정 큐) 및 WRED(가중 무작위 조기 검색)와 같은 혼잡 회피 기능과 같은 여러 정체 관리 기능 중 하나를 사용하여 여러 큐를 정의합니다.
그림 2. QoS 큐의 예
간단한 비유는 QoS가 데이터 네트워크에 가상 "카풀 레인"을 만들어 일부 유형의 데이터가 지연되거나 거의 발생하지 않도록 한다는 것입니다. 해당 레인을 만들면 상대 크기를 조정하고 있는 연결 대역폭을 훨씬 더 효과적으로 관리할 수 있으며, organization 사용자에게 비즈니스 등급 환경을 제공할 수 있습니다.
1단계. 네트워크가 준비되었는지 확인
QoS 구현을 고려하는 경우 대역폭 및 기타 네트워크 요구 사항을 이미 결정했어야 합니다.
네트워크 간 트래픽 정체는 미디어 품질에 큰 영향을 줍니다. 대역폭이 부족하면 성능이 저하되고 사용자 환경이 저하됩니다. organization Teams 채택 및 사용량이 증가함에 따라 네트워크 성능을 모니터링하고 관리해야 합니다. 문제를 식별한 다음 QoS 및 선택적 대역폭 추가를 사용하여 조정하려면 보고, 사용자별 통화 분석 및 CQD(통화 품질 대시보드) 도구를 사용합니다.
VPN 고려 사항
QoS는 호출자 간의 모든 링크에서 구현된 경우에만 예상대로 작동합니다. 내부 네트워크에서 QoS를 사용하고 사용자가 원격 위치에서 로그인하는 경우 내부 관리형 네트워크 내에서만 우선 순위를 지정할 수 있습니다.
원격 위치는 VPN(가상 사설망)을 구현하여 관리되는 연결을 받을 수 있지만 VPN은 기본적으로 패킷 오버헤드를 추가하고 실시간 트래픽에서 지연을 만듭니다. VPN을 통해 실시간 통신 트래픽을 실행하지 않는 것이 좋습니다.
대륙에 걸쳐 있는 관리되는 링크가 있는 글로벌 organization 해당 링크의 대역폭이 LAN에 비해 제한되기 때문에 QoS를 사용하는 것이 좋습니다.
2단계. QoS 구현 방법 선택
다음 메서드를 사용하여 QoS를 구현할 수 있습니다.
- 라우터에서 포트 기반 DSCP(차별화된 서비스 코드 지점) 태그 지정
- 클라이언트가 IP 패킷 헤더에 DSCP 마커를 삽입합니다.
이러한 두 메서드는 모두 DSCP 마커를 기반으로 합니다. DSCP 마커는 우편 근로자에게 배달이 얼마나 긴급한지, 그리고 신속한 배송을 위해 패키지를 정렬하는 가장 좋은 방법을 나타내는 우편 우표에 비유할 수 있습니다. 실시간 미디어 스트림에 우선 순위를 부여하도록 네트워크를 구성한 후에는 손실된 패킷과 늦은 패킷이 크게 감소해야 합니다.
라우터의 포트 기반 태그 지정
네트워크 라우터는 포트 기반 태그 지정을 사용하여 들어오는 패킷을 검사하여 사용되는 포트를 확인합니다. 패킷이 특정 포트 또는 포트 범위를 사용하여 도착하는 경우 라우터는 패킷을 특정 미디어 유형으로 식별합니다. 그런 다음 라우터는 해당 유형의 큐에 패킷을 배치하고, 다른 디바이스가 해당 트래픽 유형을 인식하고 큐에서 우선 순위를 부여할 수 있도록 미리 결정된 DSCP 표시를 IP 패킷 헤더에 추가합니다.
네트워크의 라우터에서 ACL(Access Control Lists)을 사용하여 포트 기반 태그 지정을 구현합니다. 포트 기반 태그 지정 구현에 대한 지침은 라우터 제조업체의 설명서를 참조하세요.
포트 기반 태그 지정은 혼합 Windows, Mac 및 Linux 환경에서 작동하기 때문에 가장 신뢰할 수 있는 방법입니다. 또한 구현하기가 가장 쉽습니다. 포트 기반 태그 지정은 플랫폼 간에 작동하지만 WAN 에지에서 트래픽만 표시하고(클라이언트 머신에 대한 모든 방법은 아님) 관리 오버헤드를 만듭니다.
클라이언트가 DSCP 마커를 삽입합니다.
클라이언트 엔드포인트가 IP 패킷 헤더에 DSCP 마커를 삽입하도록 요구하여 QoS를 구현할 수도 있습니다. 엔드포인트 유형(Windows, Mac, iOS, Android, Microsoft Teams 룸 시스템)에 따라 여러 가지 방법으로 이 작업을 수행할 수 있습니다. 이 내용은 이 문서의 구현 섹션에서 다룹니다.
DSCP 마커는 패킷을 특정 유형의 트래픽(예: 음성)으로 식별합니다. DSCP 마커를 인식하도록 라우터 및 기타 네트워크 디바이스를 구성하고 트래픽을 우선 순위가 높은 별도의 큐에 배치할 수 있습니다.
모범 사례
가능하면 클라이언트 엔드포인트에서 DSCP 표시와 라우터의 포트 기반 태그 지정 ACL 조합을 사용하는 것이 좋습니다. 관리 디바이스(예: Intune)는 DSCP 표시 구성을 허용하는 중앙 집중식 정책 제어의 이점을 누릴 수 있는 반면 라우터의 포트 기반 ACL은 클라이언트 쪽 DSCP 표시를 구성할 수 없는 디바이스에서 들어오는 트래픽을 식별할 수 있습니다.
네트워크의 모든 디바이스가 동일한 분류, 표시 및 우선 순위를 사용하게 되면 각 트래픽 유형에 사용되는 큐에 할당된 포트 범위의 크기를 변경하여 지연, 삭제된 패킷 및 지터를 줄이거나 제거할 수 있습니다.
Teams 관점에서 가장 중요한 구성 단계는 패킷의 분류 및 표시입니다. 그러나 엔드투엔드 QoS가 성공하려면 애플리케이션의 구성을 기본 네트워크 구성과 신중하게 조정해야 합니다. QoS가 완전히 구현되면 지속적인 관리는 organization 요구 사항 및 실제 사용에 따라 각 트래픽 유형에 할당된 포트 범위를 조정하는 문제입니다.
3단계. 각 미디어 유형에 대한 초기 포트 범위 선택
다양한 실시간 스트리밍 워크로드에 대한 포트 범위의 상대적 크기는 해당 워크로드 전용으로 사용 가능한 총 대역폭의 비율을 설정합니다. 우편 서비스 비유 사용: "Air Mail" 스탬프가 있는 편지는 1시간 이내에 가장 가까운 공항으로 이동할 수 있으며, "대량 메일"으로 표시된 작은 패키지는 일련의 트럭으로 땅을 여행하기 전에 하루 동안 기다릴 수 있습니다.
DSCP 값은 클라이언트 또는 ACL 설정에 따라 네트워크 자체에 의해 DSCP 표시가 할당되는지 여부에 관계없이 패킷 또는 스트림에 부여할 우선 순위를 해당하게 구성된 네트워크에 알려줍니다. 각 미디어 워크로드는 고유한 DSCP 값과 각 미디어 유형에 사용되는 정의되고 별도의 포트 범위를 가져옵니다. (다른 서비스에서 워크로드가 DSCP 표시를 공유할 수 있지만 Teams는 공유하지 않습니다.) 다른 환경에는 네트워크 워크로드의 우선 순위를 결정하는 데 도움이 되는 기존 QoS 전략이 있을 수 있습니다.
권장되는 초기 포트 범위
| 미디어 트래픽 유형 | 클라이언트 원본 포트 범위 | 프로토콜 | DSCP 값 | DSCP 클래스 |
|---|---|---|---|---|
| 오디오 | 50,000~50,019 | TCP/UDP | 46 | Expedited Forwarding(EF) |
| 비디오 | 50,020~50,039 | TCP/UDP | 34 | Assured Forwarding(AF41) |
| 응용 프로그램/화면 공유 | 50,040~50,059 | TCP/UDP | 18 | Assured Forwarding(AF21) |
| 통화 및 모임 신호 | 50,070–50,089* | UDP | 40 | 클래스 선택기 5(CS5) |
* 이러한 포트는 현재 구성할 수 없습니다.
이러한 설정을 사용하는 경우 다음 사항에 유의하세요.
모바일 클라이언트 및 Teams 디바이스를 포함한 모든 클라이언트는 이러한 포트 범위를 사용하며 이러한 원본 포트 범위를 사용하는 구현하는 모든 DSCP 정책의 영향을 받습니다. 동적 포트를 계속 사용하는 클라이언트는 브라우저 기반 클라이언트뿐입니다(참가자가 브라우저를 사용하여 모임에 참가할 수 있도록 하는 클라이언트).
Mac 및 모바일(iOS 및 Android) 클라이언트는 이러한 원본 포트 범위를 사용하지만 이러한 클라이언트는 오디오(EF) 및 AF41(비디오 및 애플리케이션/화면 공유)에 하드 코딩된 값을 사용합니다. 이러한 값은 구성할 수 없습니다.
나중에 사용자 환경을 개선하기 위해 포트 범위를 조정해야 하는 경우 포트 범위는 겹칠 수 없으며 서로 인접해야 합니다.
통화 및 모임 신호에 사용되는 포트 범위는 현재 사용자 지정할 수 없습니다.
4단계. QoS 설정 구현
클라이언트 및 네트워크 디바이스에 대한 QoS 설정을 구현하고 모임에 대한 미디어 트래픽을 처리하는 방법을 결정합니다.
필수 조건으로 Teams 관리 Center에서 QoS를 전역적으로 사용하도록 설정합니다. 실시간 미디어 트래픽 설정에 대한 QoS(서비스 품질 삽입) 표식을 사용하도록 설정하는 방법에 대한 자세한 내용은 Teams 관리 센터에서 QoS 구성을 참조하세요.
Windows 엔드포인트에 대한 DSCP 표시를 구성하는 방법에 대한 자세한 내용은 Teams 클라이언트에서 QoS 구현을 참조하세요.
참고
클래식 Teams에서 새 Teams로의 전환의 일환으로 실행 파일 이름이 teams.exe(클래식 Teams)에서 ms-teams.exe(새 Teams)로 변경되었습니다.
Mac 및 모바일(iOS 및 Android) 클라이언트는 오디오(EF) 및 AF41(비디오 및 애플리케이션/화면 공유)에 하드 코딩된 값을 사용합니다. Teams 전화 디바이스는 EF(오디오)의 기본값도 사용합니다. 그러나 이를 작동하려면 Teams 관리 센터에서 QoS를 전역적으로 사용하도록 설정해야 합니다. 실시간 미디어 트래픽에 대한 QoS(서비스 품질 삽입) 표식을 사용하도록 설정하는 방법에 대한 자세한 내용은 Teams 관리 센터에서 QoS 구성을 참조하세요.
Microsoft Teams 룸(Windows 및 Android)에 대한 DSCP 표시를 구성하는 방법에 대한 자세한 내용은 Teams 룸 디바이스에서 QoS(서비스 품질) 구성을 참조하세요.
WINDOWS 10 TEAM OS를 실행하는 Surface Hub 디바이스에 대한 DSCP 표시를 구성하는 방법에 대한 자세한 내용은 MDM 공급자를 사용하여 Surface Hub 관리를 참조하세요.
라우터용 QoS 구현에 대한 자세한 내용은 제조업체의 설명서를 참조하세요.
네트워크 디바이스에서 QoS를 설정하려면 ACL(포트 기반 Access Control Lists 사용), QoS 큐 및 DSCP 표시 정의 또는 이러한 모든 항목이 포함될 수 있습니다.
중요
클라이언트 원본 포트와 "any"의 원본 및 대상 IP 주소를 사용하여 이러한 QoS 정책을 구현하는 것이 좋습니다. 그러면 내부 네트워크에서 들어오는 미디어 트래픽과 나가는 미디어 트래픽을 모두 catch할 수 있습니다.
5단계. QoS 구현 유효성 검사
QoS가 유효하려면 DSCP 값 집합이 호출의 양쪽 끝에 있어야 합니다. Teams 클라이언트에서 생성된 트래픽을 분석하여 Teams 워크로드 트래픽이 네트워크를 통해 이동할 때 DSCP 값이 변경되거나 제거되지 않는지 확인할 수 있습니다.
네트워크 송신 지점에서 트래픽을 캡처하는 것이 좋습니다. 스위치 또는 라우터에서 포트 미러링을 사용하여 이를 도울 수 있습니다.
6단계. 원본 포트 관리
Teams의 경우 각 미디어 유형에 대한 초기 포트 범위를 선택한 후(3단계 참조) 필요에 따라 다양한 워크로드에서 사용하는 QoS 원본 포트를 모니터링하고 조정해야 합니다. 지정된 미디어 유형에 더 많거나 적은 포트가 필요할 수 있습니다.
포트를 모니터링하고 관리하는 방법에 대한 자세한 내용은 다음을 참조하세요.
포트 범위를 조정할 수는 있지만 DSCP 표시를 구성할 수는 없습니다.