Calls 자체 호스팅 배포#

plans-img 모든 플랜에서 사용 가능

deployment-img 자체 호스팅 배포

Mattermost Calls는 통신 인프라에 대한 향상된 보안과 제어를 요구하는 조직을 위한 훌륭한 옵션입니다. Calls는 에어갭 환경을 포함한 자체 호스팅 배포에서 안전하게 작동하도록 설계되었으며, 복잡한 네트워크 요구사항에 대한 유연한 구성 옵션으로 공용 인터넷 연결에 의존하지 않고 개인 통신을 보장합니다.

이 문서는 자체 호스팅 배포에서 Calls 플러그인을 성공적으로 작동시키는 방법에 대한 정보를 제공합니다. 또한 예시 다이어그램과 함께 가장 일반적인 배포 전략을 설명하고, 녹화, 전사 및 실시간 자막 서비스에 대한 배포 가이드라인을 제공합니다.

용어#

  • WebRTC: 통화가 구현되는 기본 프로토콜/명세의 집합입니다.

  • RTC (Real Time Connection): 실시간 연결입니다. 이는 미디어 트랙(오디오/비디오/화면)을 전송하는 데 사용되는 채널입니다.

  • WS (WebSocket): WebSocket 연결입니다. 이는 연결(시그널링 프로세스)을 설정하는 데 사용되는 채널입니다.

  • NAT (Network Address Translation): IP 주소를 매핑하는 네트워킹 기술입니다.

  • STUN (Session Traversal Utilities for NAT): WebRTC 클라이언트가 NAT를 통과하는 데 도움을 주는 프로토콜/서비스입니다. 서버 측에서는 주로 인스턴스의 공용 IP를 파악하는 데 사용됩니다.

  • TURN (Traversal Using Relays around NAT): 엄격한 방화벽 뒤에 있는 WebRTC 클라이언트가 미디어 릴레이를 통해 통화에 연결할 수 있도록 도와주는 프로토콜/서비스입니다.

플러그인 구성 요소#

  • Calls 플러그인: 이는 채널 통화를 활성화하기 위한 주요 진입점이자 요구사항입니다.

  • rtcd: WebRTC 연결과 관련된 모든 기능과 데이터 처리를 오프로드하기 위해 배포할 수 있는 선택적 서비스입니다. rtcd를 사용하는 시기와 이유에 대한 자세한 내용은 아래를 참조하세요.

요구사항#

서버#

  • Mattermost 서버를 보안(HTTPS) 연결로 실행하세요. 이는 클라이언트에서 장치(예: 마이크, 화면) 캡처를 허용하기 위한 필수 요구사항입니다. 자세한 내용은 TLS 구성 섹션을 참조하세요.

  • 아래의 네트워크 요구사항을 참조하세요.

클라이언트#

  • 클라이언트는 RTC Server Port 로 구성된 UDP 포트를 통해 통화를 호스팅하는 인스턴스에 연결(데이터 송수신)할 수 있어야 합니다. 이것이 불가능한 경우 연결을 위해 TURN 서버를 사용해야 합니다.

  • 플랫폼이나 운영체제에 따라 클라이언트는 오디오 입력 캡처나 화면 공유를 허용하기 위해 애플리케이션(예: 브라우저, 데스크톱 앱)에 추가 권한을 부여해야 할 수 있습니다.

네트워크#

팁

아래 표의 추가 열을 보려면 가로로 스크롤하세요.

서비스

포트

프로토콜

소스

대상

목적

API (Calls 플러그인)

80,443

TCP (인바운드)

Mattermost 클라이언트 (웹/데스크톱/모바일)

Mattermost 인스턴스 (Calls 플러그인)

클라이언트에서 Calls 플러그인으로의 HTTP 및 WebSocket 연결을 허용합니다. 이 API는 Mattermost와 동일한 연결에 노출되므로 아무것도 변경할 필요가 없을 것입니다.

RTC (Calls 플러그인 또는 rtcd)

8443

UDP (인바운드)

Mattermost 클라이언트 (웹/데스크톱/모바일)

Mattermost 인스턴스 또는 rtcd 서비스

클라이언트가 통화 관련 미디어(예: 오디오, 비디오)를 전송하는 연결을 설정할 수 있도록 합니다. 이는 플러그인(또는 rtcd)을 실행하는 인스턴스와 통화에 참여하는 클라이언트 사이의 모든 네트워크 구성 요소(예: NAT, 방화벽)에서 열려 있어야 하며, UDP 트래픽이 양방향(클라이언트에서/로)으로 올바르게 라우팅되도록 합니다.

RTC (Calls 플러그인 또는 rtcd)

8443

TCP (인바운드)

Mattermost 클라이언트 (웹/데스크톱/모바일)

Mattermost 인스턴스 또는 rtcd 서비스

클라이언트가 통화 관련 미디어(예: 오디오, 비디오)를 전송하는 연결을 설정할 수 있도록 합니다. 이는 플러그인(또는 rtcd)을 실행하는 인스턴스와 통화에 참여하는 클라이언트 사이의 모든 네트워크 구성 요소(예: NAT, 방화벽)에서 열려 있어야 하며, TCP 트래픽이 양방향(클라이언트에서/로)으로 올바르게 라우팅되도록 합니다. 클라이언트가 UDP를 사용하여 연결할 수 없는 경우 백업 채널로 사용할 수 있습니다. rtcd 버전 >= v0.11과 Calls 버전 >= v0.17이 필요합니다.

API (rtcd)

8045

TCP (인바운드)

Mattermost 인스턴스(들) (Calls 플러그인)

rtcd 서비스

Calls 플러그인에서 rtcd 서비스로의 HTTP/WebSocket 연결을 허용합니다. Mattermost 서버를 실행하는 인스턴스(들)에서만 접근 가능하면 되므로 내부적으로 노출될 수 있습니다.

STUN (Calls 플러그인 또는 rtcd)

3478

UDP (아웃바운드)

Mattermost 인스턴스(들) (Calls 플러그인) 또는 rtcd 서비스

구성된 STUN 서버

(선택사항) Calls 플러그인 또는 rtcd 서비스가 인스턴스의 공용 IP를 발견할 수 있도록 합니다. STUN/TURN 서버를 구성하는 경우에만 필요합니다. ICE Host Override 구성 옵션을 통해 IP 또는 호스트명을 수동으로 설정하는 경우에는 이 요구사항이 적용되지 않습니다.

에어갭 배포#

Mattermost Calls는 에어갭 환경에서 작동할 수 있습니다. 사용자가 로컬 네트워크 외부에서 연결해야 하고 기존 방법으로는 해당 연결을 지원할 수 없는 경우에만 Calls를 공용 인터넷에 노출할 필요가 있습니다. 이러한 설정에서는:

  • 사용자는 프라이빗/로컬 네트워크 내에서 연결해야 합니다. 온프레미스, VPN 또는 가상 머신을 통해 연결할 수 있습니다.

  • 모든 연결이 로컬 네트워크 내에서 이루어지므로 STUN 서버 구성이 필요하지 않습니다.

  • 특정 네트워크 구성 및 토폴로지에 따라 ICE Host Override 구성 설정을 로컬 IP 주소(예: 192.168.1.45)로 선택적으로 설정할 수 있습니다.

제한사항#

  • 모든 Mattermost 고객은 선택적 화면 공유가 가능한 1:1 오디오 통화를 시작하고, 참여하고, 참가할 수 있습니다.

  • 최대 50명의 동시 사용자가 참여하는 그룹 통화를 위해서는 Mattermost Enterprise, Professional 또는 Mattermost Cloud가 필요합니다.

  • Enterprise 고객은 통화 녹화, 통화 중 실시간 텍스트 자막 활성화, 녹화된 통화 전사 기능을 사용할 수 있습니다. 50명 이상의 동시 사용자가 참여하는 그룹 통화를 원하는 Enterprise 자체 호스팅 고객은 전용 rtcd 서비스 사용을 고려하는 것이 좋습니다.

  • Mattermost 자체 호스팅 배포의 경우, 시스템 관리자는 시스템 콘솔을 사용하여 플러그인을 활성화하고 구성해야 합니다. 기본 최대 참가자 수는 무제한이지만, 통화당 최대 50명의 참가자를 권장합니다. 최대 통화 참가자 수는 시스템 콘솔 > 플러그인 관리 > Calls > 최대 통화 참가자 에서 구성할 수 있습니다. 통화 참가자 제한은 인스턴스 리소스에 크게 의존합니다. 자세한 내용은 아래 성능 섹션을 참조하세요.

구성#

Mattermost 자체 호스팅 고객의 경우, calls 플러그인은 사전 패키징되어 설치되고 활성화됩니다. 최종 사용자가 사용할 수 있도록 하는 구성은 시스템 콘솔에서 찾을 수 있습니다.

운영 모드#

Mattermost 서버의 실행 방식에 따라 Calls 플러그인이 작동할 수 있는 여러 모드가 있습니다. rtcd와 Selective Forwarding Unit (SFU)에 대해 자세히 알아보려면 아래 rtcd 서비스 섹션을 참조하세요.

Mattermost 배포

SFU

SFU 배포

단일 인스턴스

통합

단일 인스턴스

rtcd

고가용성 클러스터 기반

통합

클러스터

고가용성 클러스터 기반

rtcd

단일 인스턴스#

통합#

단일 Mattermost 인스턴스 설정에서 플러그인을 처음 설치할 때의 기본 모드입니다. WebRTC 서비스는 플러그인 자체에 통합되어 Mattermost 서버와 함께 실행됩니다.

단일 인스턴스의 통합 구성 모델 다이어그램.

rtcd#

외부 전용 확장 가능한 WebRTC 서비스(rtcd)가 모든 통화 미디어 라우팅을 처리하는 데 사용됩니다.

Web RTC 배포 구성 다이어그램.

고가용성 클러스터 기반#

클러스터#

고가용성 클러스터 기반 배포에서 플러그인을 실행할 때의 기본 모드입니다. 모든 Mattermost 노드는 WebRTC 서비스를 포함하는 플러그인 인스턴스를 실행합니다. 통화는 기존 로드 밸런서를 통해 사용 가능한 모든 노드에 분산됩니다: 통화는 초기 websocket 연결(첫 번째 참가 클라이언트)이 이루어진 인스턴스에서 호스팅됩니다. 단일 통화는 단일 클러스터 노드에서 호스팅됩니다.

클러스터형 통화 배포 다이어그램.

rtcd (고가용성)#

rtcd 배포 다이어그램.

성능#

Calls 성능은 주로 두 가지 리소스에 의존합니다: CPU와 대역폭(네트워크 지연 시간 및 전체 처리량). 최종 소비량은 미디어를 송수신하는 클라이언트 수에 따라 2차 성장을 보입니다.

예를 들어, 10명의 참가자 중 2명이 음소거 해제된(음성 데이터 전송) 단일 통화는 일반적으로 단일 참가자가 음소거 해제된 동일한 통화보다 두 배의 리소스를 소비합니다. 성능에 궁극적으로 영향을 미치는 것은 서버 전체의 동시 미디어 흐름(입력/출력)의 총 수입니다.

벤치마크#

전용 rtcd 인스턴스에서 내부적으로 수행된 성능 및 한계 테스트 결과는 다음과 같습니다:

배포 사양#

  • 1x r6i.large nginx 프록시

  • 3x c5.large MM 앱 노드 (HA)

  • 2x db.x2g.xlarge RDS Aurora MySQL v8 (작성자 1명, 읽기 1명)

  • 1x (c7i.xlarge, c7i.2xlarge, c7i.4xlarge) RTCD

  • 2x c7i.2xlarge 부하 테스트 에이전트

앱 사양#

  • Mattermost v9.6

  • Mattermost Calls v0.28.0

  • RTCD v0.16.0

  • 부하 테스트 에이전트 v0.28.0

미디어 사양#

  • 음성 샘플 비트레이트: 80Kbps

  • 화면 공유 샘플 비트레이트: 1.6Mbps

결과#

팁

아래 표의 추가 열을 보려면 가로로 스크롤하세요.

통화

참가자/통화

음소거 해제/통화

화면 공유

CPU (평균)

메모리 (평균)

대역폭 (입력/출력)

인스턴스 유형 (RTCD)

1

1000

2

아니오

47%

1.46GB

1Mbps / 194Mbps

c7i.xlarge

1

800

1

예

64%

1.43GB

2.7Mbps / 1.36Gbps

c7i.xlarge

1

1000

1

예

79%

1.54GB

2.9Mbps / 1.68Gbps

c7i.xlarge

10

100

1

예

74%

1.56GB

18.2Mbps / 1.68Gbps

c7i.xlarge

100

10

2

아니오

49%

1.46GB

18.7Mbps / 175Mbps

c7i.xlarge

100

10

1

예

84%

1.73GB

171Mbps / 1.53Gbps

c7i.xlarge

1

1000

2

아니오

20%

1.44GB

1.4Mbps / 194Mbps

c7i.2xlarge

1

1000

2

예

49%

1.53GB

3.6Mbps / 1.79Gbps

c7i.2xlarge

2

1000

1

예

73%

2.38GB

5.7Mbps / 3.06Gbps

c7i.2xlarge

100

10

2

예

60%

1.74GB

181Mbps / 1.62Gbps

c7i.2xlarge

150

10

1

예

72%

2.26GB

257Mbps / 2.30Gbps

c7i.2xlarge

150

10

2

예

79%

2.34GB

271Mbps / 2.41Gbps

c7i.2xlarge

250

10

2

아니오

58%

2.66GB

47Mbps / 439Mbps

c7i.2xlarge

1000

2

2

아니오

78%

2.31GB

178Mbps / 195Mbps

c7i.2xlarge

2

1000

2

예

41%

2.6GB

7.23Mbps / 3.60Gbps

c7i.4xlarge

3

1000

2

예

63%

3.53GB

10.9Mbps / 5.38Gbps

c7i.4xlarge

4

1000

2

예

83%

4.40GB

14.5Mbps / 7.17Gbps

c7i.4xlarge

250

10

2

예

79%

3.49GB

431Mbps / 3.73Gbps

c7i.4xlarge

500

2

2

예

71%

2.54GB

896Mbps / 919Mbps

c7i.4xlarge

참고

  • 단일 노드 내의 처리 한계를 이해하기 위해 테스트는 단일 수직 확장 RTCD 인스턴스에 초점을 맞췄습니다. RTCD 서비스를 수평으로 확장하면 더 많은 수의 통화를 지원하기에 충분할 것입니다.

  • RTCD 프로세스는 모든 성능 프로파일링(블록 및 뮤텍스 포함)이 활성화된 상태로 실행되었습니다. 이로 인해 일부 계산 오버헤드가 발생했습니다.

  • 음성 및 화면 샘플 모두 실제 클라이언트(예: 브라우저)에서 생성되는 평균보다 약간 더 높은 비트레이트를 가집니다. 이는 실제 배포에 대한 안전 마진을 제공합니다.

전용 서비스#

엔터프라이즈 고객을 위해 통화를 더 확장하는 데 사용할 수 있는 전용 서비스를 통해 성능 비용을 분산시키는 방법을 제공합니다.

부하 테스트#

통화의 성능 영향을 시뮬레이션하고 측정하는 데 사용할 수 있는 부하 테스트 도구를 제공합니다.

모니터링#

플러그인과 외부 rtcd 서비스 모두 성능을 모니터링하기 위한 Prometheus 메트릭을 노출합니다. Grafana에서 가져올 수 있는 공식 대시보드를 제공합니다. Prometheus를 설정하고 Grafana를 통해 메트릭을 시각화하는 방법에 대한 자세한 내용은 성능 모니터링을 참조하세요.

Calls 플러그인 메트릭#

Calls 플러그인의 메트릭은 기존 Mattermost 서버 메트릭 엔드포인트 아래의 /plugins/com.mattermost.calls/metrics 하위 경로를 통해 노출됩니다. 이는 성능을 위한 수신 주소 구성 설정에 의해 제어됩니다. 기본값은 8067 포트입니다.

참고

  • 메트릭 플러그인은 애플리케이션 수준의 메트릭만 수집하며 시스템 또는 OS 수준의 호출을 수행하지 않습니다. 결과적으로 일반적으로 시스템 수준 메트릭에서 파생되는 데이터가 Grafana 패널에 누락될 수 있습니다.

  • v9.5 이전 Mattermost 버전에서는 플러그인 메트릭이 웹 서버 수신 주소 구성 설정에 의해 제어되는 공개 /plugins/com.mattermost.calls/metrics API 엔드포인트를 통해 노출되었습니다. 기본값은 8065 포트입니다.

프로세스

  • mattermost_plugin_calls_process_cpu_seconds_total: 초 단위로 소요된 총 사용자 및 시스템 CPU 시간.

  • mattermost_plugin_calls_process_max_fds: 열린 파일 설명자의 최대 수.

  • mattermost_plugin_calls_process_open_fds: 열린 파일 설명자의 수.

  • mattermost_plugin_calls_process_resident_memory_bytes: 바이트 단위의 상주 메모리 크기.

  • mattermost_plugin_calls_process_virtual_memory_bytes: 바이트 단위의 가상 메모리 크기.

WebRTC 연결

  • mattermost_plugin_calls_rtc_conn_states_total: RTC 연결 상태 변경의 총 횟수.

  • mattermost_plugin_calls_rtc_errors_total: RTC 오류의 총 횟수.

  • mattermost_plugin_calls_rtc_rtp_bytes_total: 바이트 단위의 송신/수신 RTP 패킷의 총 수.

    • 참고: v0.16.0부터 제거됨

  • mattermost_plugin_calls_rtc_rtp_packets_total: 송신/수신 RTP 패킷의 총 수.

    • 참고: v0.16.0부터 제거됨

  • mattermost_plugin_calls_rtc_rtp_tracks_total: 수신/송신 RTP 트랙의 총 수.

    • 참고: v0.16.0부터 추가됨

  • mattermost_plugin_calls_rtc_sessions_total: 활성 RTC 세션의 총 수.

애플리케이션

  • mattermost_plugin_calls_app_handlers_time_bucket: 앱 핸들러 실행에 소요된 시간.

    • mattermost_plugin_calls_app_handlers_time_sum

    • mattermost_plugin_calls_app_handlers_time_count

데이터베이스

  • mattermost_plugin_calls_store_ops_total: 데이터베이스 저장소 작업의 총 수.

  • mattermost_plugin_calls_store_methods_time_bucket: 저장소 메서드 실행에 소요된 시간.

    • mattermost_plugin_calls_store_methods_time_sum

    • mattermost_plugin_calls_store_methods_time_count

  • mattermost_plugin_calls_cluster_mutex_grab_time_bucket: 전역 뮤텍스를 획득하는 데 소요된 시간.

    • mattermost_plugin_calls_cluster_mutex_grab_time_sum

    • mattermost_plugin_calls_cluster_mutex_grab_time_count

  • mattermost_plugin_calls_cluster_mutex_locked_time_bucket: 전역 뮤텍스에서 잠긴 시간.

    • mattermost_plugin_calls_cluster_mutex_locked_time_sum

    • mattermost_plugin_calls_cluster_mutex_locked_time_count

WebSocket

  • mattermost_plugin_calls_websocket_connections_total: 활성 WebSocket 연결의 총 수.

  • mattermost_plugin_calls_websocket_events_total: WebSocket 이벤트의 총 수.

작업

  • mattermost_plugin_calls_jobs_live_captions_new_audio_len_ms_bucket: 실시간 자막을 위해 전사된 새 오디오의 지속 시간(밀리초).

    • mattermost_plugin_calls_jobs_live_captions_new_audio_len_ms_sum

    • mattermost_plugin_calls_jobs_live_captions_new_audio_len_ms_count

  • mattermost_plugin_calls_jobs_live_captions_pktPayloadCh_buf_full: 채널이 가득 차서 삭제된 오디오 데이터 패킷의 총 수.

  • mattermost_plugin_calls_jobs_live_captions_window_dropped: 전사기에 부하가 걸려 삭제된 오디오 데이터 윈도우의 총 수.

WebRTC 서비스 메트릭#

rtcd 서비스의 메트릭은 api.http.listen_address 구성 설정으로 제어되는 rtcd API 리스너 아래의 /metrics API 엔드포인트를 통해 노출됩니다. 기본 포트는 8045입니다.

프로세스

  • rtcd_process_cpu_seconds_total: 사용자 및 시스템 CPU 시간의 총 소요 시간(초).

  • rtcd_plugin_calls_process_max_fds: 열린 파일 디스크립터의 최대 수.

  • rtcd_plugin_calls_process_open_fds: 열린 파일 디스크립터의 수.

  • rtcd_plugin_calls_process_resident_memory_bytes: 상주 메모리 크기(바이트).

  • rtcd_plugin_calls_process_virtual_memory_bytes: 가상 메모리 크기(바이트).

WebRTC 연결

  • rtcd_rtc_conn_states_total: RTC 연결 상태 변경의 총 수.

  • rtcd_rtc_errors_total: RTC 오류의 총 수.

  • rtcd_rtc_rtp_bytes_total: 송수신된 RTP 패킷의 총 바이트 수.

  • rtcd_rtc_rtp_packets_total: 송수신된 RTP 패킷의 총 수.

  • rtcd_rtc_rtp_tracks_total: 수신/송신 RTP 트랙의 총 수.

  • rtcd_rtc_sessions_total: 활성 RTC 세션의 총 수.

  • rtcd_rtc_rtp_tracks_writes_time_bucket: 송신 RTP 트랙에 쓰는 데 소요된 시간.

    • rtcd_rtc_rtp_tracks_writes_time_sum

    • rtcd_rtc_rtp_tracks_writes_time_count

WebSocket

  • rtcd_ws_connections_total: 활성 WebSocket 연결의 총 수.

  • rtcd_ws_messages_total: 수신/송신된 WebSocket 메시지의 총 수.

구성#

플러그인과 rtcd 메트릭을 모두 수집하는 Prometheus 구성 예시는 다음과 같습니다:

scrape_configs:
- job_name: node
  static_configs:
    - targets: ['rtcd-0:9100','rtcd-1:9100', 'calls-offloader-1:9100', 'calls-offloader-2:9100']
- job_name: calls
   metrics_path: /plugins/com.mattermost.calls/metrics
   static_configs:
     - targets: ['app-0:8067','app-1:8067','app-2:8067']
- job_name: rtcd
   static_configs:
     - targets: ['rtcd-0:8045', 'rtcd-1:8045']

시스템 튜닝#

많은 수의 통화나 많은 참가자가 있는 통화를 호스팅하려면 다음 플랫폼별(Linux) 튜닝을 살펴보세요(현재 플러그인에서 공식적으로 지원하는 유일한 대상입니다):

# Setting the maximum buffer size of the receiving UDP buffer to 16MB
net.core.rmem_max = 16777216

# Setting the maximum buffer size of the sending UDP buffer to 16MB
net.core.wmem_max = 16777216

# Allow to allocate more memory as needed for more control messages that need to be sent for each socket connected
net.core.optmem_max = 16777216

rtcd 서비스#

참고

plans-img rtcd 서비스는 Enterprise 플랜에서만 사용할 수 있습니다

Calls 플러그인은 오디오와 화면 공유 데이터를 라우팅하기 위한 내장 선택적 전달 장치(SFU)가 있습니다. 이는 위의 작동 모드 섹션에서 설명한 integrated 옵션입니다. 하지만 이 SFU 기능은 외부 rtcd 인스턴스로 별도 배포할 수 있습니다.

rtcd 서비스 사용 이유#

이 섹션에서는 조직이 rtcd 를 사용해야 하는 시기와 이유를 이해하는 데 도움이 됩니다.

참고

rtcd 는 독립형 서비스로, 운영 복잡성과 유지 관리 비용이 추가되며 엔터프라이즈 라이선스가 필요합니다. Calls를 평가 중이거나 소규모 Mattermost 인스턴스의 경우, 통합 SFU(Calls 플러그인에 포함된 것)가 초기에는 충분할 수 있습니다.

다음과 같은 이유로 rtcd 서비스는 Calls 호스팅을 위한 권장 방식입니다:

  • 주요 Mattermost 서버의 성능. Calls 플러그인이 SFU를 실행할 때, 통화 트래픽이 Mattermost 서비스의 나머지 부분을 실행하는 서버의 처리 부하에 추가됩니다. Calls 트래픽이 급증하면 이러한 서비스의 응답성에 부정적인 영향을 미칠 수 있습니다. rtcd 서비스를 사용하면 통화 트래픽 처리가 해당 rtcd 인스턴스로 격리되고, CPU 사용량 급증을 최소화하여 비용도 절감됩니다.

  • Calls 제품의 성능, 확장성 및 안정성. Calls 트래픽이 급증하거나 전체 용량이 더 필요한 경우, 부하를 분산하기 위해 rtcd 서버를 추가할 수 있습니다. 추가적인 이점으로, Mattermost 트래픽이 급증하거나 Mattermost 인스턴스를 재시작해야 하는 경우에도 현재 통화 중인 사용자에게 영향을 주지 않습니다 - 현재 통화가 끊기지 않습니다.

여기에는 몇 가지 주의사항이 있습니다. 메인 Mattermost 서버가 다운되는 동안 웹소켓 이벤트(예: 이모지 반응, 손 들기, 음소거/음소거 해제)는 전송되지 않습니다. 하지만 메인 서버가 재시작되는 동안 통화 자체는 계속됩니다.

  • Kubernetes 배포. Kubernetes 배포에서는 rtcd를 강력히 권장합니다. 현재 Calls를 실행하는 공식적으로 지원되는 유일한 방법입니다.

  • 기술적 이점. 전용 rtcd 서비스는 실시간 오디오/비디오 트래픽을 위해 시스템/네트워크 수준에서 최적화 및 조정되었으며, 일반적으로 처리량보다 지연 시간이 더 중요한 경우에 적합합니다.

일반적으로 rtcd는 성능이 좋고 확장 가능한 배포를 위한 선호되는 솔루션입니다. rtcd를 사용하면 많은 수의 통화를 호스팅할 때 Mattermost 서버에 미치는 영향이 최소화됩니다.

서비스를 통해 통화를 실행하는 방법에 대한 자세한 내용은 GitHub의 Mattermost rtcd 저장소 문서를 참조하세요. 또한:

수평적 확장성#

Calls의 수평적 확장성을 활성화하는 지원되는 방법은 DNS 기반 로드 밸런싱 형태를 통한 것입니다. 이는 rtcd 서비스가 어떻게 배포되든(베어본 인스턴스, Kubernetes 또는 대체 방식) 관계없이 달성할 수 있습니다.

이것이 작동하려면 RTCD 서비스 URL이 여러 IP 주소로 해석되는 호스트명을 가리켜야 하며, 각 IP 주소는 실행 중인 rtcd 인스턴스를 가리킵니다. 그러면 Mattermost Calls 플러그인이 사용 가능한 호스트들 사이에 자동으로 통화를 분배합니다.

예상되는 요구사항은 다음과 같습니다:

  • 새로운 rtcd 인스턴스가 배포되면 DNS 레코드에 추가되어야 합니다. 그러면 플러그인 측에서 이를 감지하고 새 호스트에 통화를 할당하기 시작할 수 있습니다.

  • rtcd 인스턴스가 다운되면 DNS 레코드에서 제거되어야 합니다. 그러면 플러그인 측에서 변경 사항을 감지하고 해당 호스트에 새 통화를 할당하지 않습니다.

참고

  • 로드 밸런싱은 통화 수준에서 수행됩니다. 이는 단일 통화가 항상 단일 rtcd 인스턴스에서 실행됨을 의미합니다.

  • 현재 동일한 통화에 속한 세션을 여러 인스턴스에 걸쳐 분산하는 기능은 지원되지 않습니다.

녹화, 전사 및 실시간 자막 구성#

통화 녹화, 전사 및 실시간 자막을 시작하기 전에 calls-offloader 작업 서비스를 구성해야 합니다. 이 서비스의 배포 및 실행에 대한 자세한 내용은 GitHub의 calls-offloader 문서를 참조하세요. 이 서비스와 관련된 성능 및 확장성 권장사항도 GitHub에서 확인할 수 있습니다.

참고

Kubernetes 클러스터에 서비스를 배포하는 경우 Helm 차트 섹션을 참조하세요.

calls-offloader 서비스가 실행되면 통화 녹화 활성화 구성 설정을 통해 녹화를 명시적으로 활성화하고 작업 서비스 URL을 사용하여 서비스의 URL을 구성해야 합니다.

통화 전사는 통화 전사 활성화 구성 설정을 통해 활성화할 수 있습니다.

실시간 자막은 실시간 자막 활성화 구성 설정을 통해 활성화할 수 있습니다.

참고

  • 통화 전사 기능은 Calls v0.22.0 버전부터 사용할 수 있습니다.

  • 실시간 자막 기능은 Calls v0.26.2 버전부터 사용할 수 있습니다.

Kubernetes 배포#

Calls 플러그인은 배포에 대한 향상된 확장성과 제어를 제공하기 위해 Kubernetes와 잘 통합되도록 설계되었습니다.

다음은 rtcd 독립형 서비스가 Kubernetes 클러스터에 배포되는 방법을 보여주는 예시 다이어그램입니다:

Kubernetes 클러스터에 배포된 통화 다이어그램.

Mattermost가 Kubernetes 클러스터에 배포되어 있지 않고 이 배포 유형을 사용하려면 Kubernetes에 Mattermost 배포 문서를 참조하세요.

Helm 차트#

Kubernetes 배포에서 Calls 관련 구성 요소와 서비스를 배포하는 권장 방법은 공식적으로 제공되는 Helm 차트를 사용하는 것입니다. 이러한 서비스를 배포하는 방법에 대한 자세한 정보를 포함한 관련 문서는 mattermost-helm 저장소에서 찾을 수 있습니다:

제한사항#

WebRTC 서비스 호스팅의 고유한 복잡성으로 인해 Kubernetes 환경에서 Calls를 배포할 때 일부 제한사항이 적용됩니다.

주요 요구사항 중 하나는 각 rtcd 프로세스가 전용 Kubernetes 노드에 있어야 한다는 것입니다. 이는 수평적 확장을 허용하면서 데이터를 올바르게 전달하기 위해 필요합니다. 데이터는 일반적으로 표준 ingress를 통해 전달되지 않고 rtcd 프로세스를 실행하는 pod로 직접 전달되어야 합니다.

일반적인 권장사항은 rtcd 인스턴스(Kubernetes 노드)당 하나의 외부 IP 주소를 노출하는 것입니다. 이렇게 하면 애플리케이션이 자체 외부 주소를(STUN을 통해) 감지하고 이를 클라이언트에 알려 최소한의 구성으로 연결성을 달성할 수 있어 확장이 더 간단해집니다.

어떤 이유로 여러 IP 주소를 노출할 수 없는 환경에서는 포트 매핑(NAT)을 사용할 수 있습니다. 이 시나리오에서는 단일 외부 IP 뒤에 있는 각 rtcd 노드를 매핑하기 위해 다른 포트를 사용합니다. 예시:

EXT_IP:8443 -> rtcdA:8443
EXT_IP:8444 -> rtcdB:8443
EXT_IP:8445 -> rtcdC:8443

이 경우 몇 가지 추가 구성이 필요합니다:

  • 모든 rtcd 노드에 대해 NAT 매핑이 필요합니다. 이는 일반적으로 ingress 지점(예: ELB, NLB 등)에서 수행됩니다.

  • RTCD_RTC_ICEHOSTPORTOVERRIDE 구성을 사용하여 노드 IP와 해당 포트의 전체 매핑을 전달해야 합니다.

    • 예시: RTCD_RTC_ICEHOSTPORTOVERRIDE=rtcdA_IP/8443,rtcdB_IP/8444,rtcdC_IP/8445

  • RTCD_RTC_ICEHOSTOVERRIDE를 사용하여 외부 IP 주소를 설정해야 합니다.

참고

이러한 정적 매핑을 제한하는 한 가지 옵션은 로컬 서브넷의 크기를 줄이는 것입니다(예: /29).

자주 묻는 질문#

암호화가 있나요?#

미디어(오디오/비디오)는 WebRTC의 일부로 보안 표준을 사용하여 암호화됩니다. 주로 DTLS와 SRTP의 조합입니다. 현재 설계에서는 모든 미디어가 미디어 라우터 역할을 하는 Mattermost를 통해 전달되어야 하므로 엔드투엔드 암호화는 아닙니다. 미디어는 전송 중에 보안이 유지되도록 클라이언트로 다시 암호화됩니다. 요약하자면: 참가자 클라이언트와 Mattermost 서버만 암호화되지 않은 통화 데이터에 접근할 수 있습니다.

관련된 타사 서비스가 있나요?#

사용되는 유일한 외부 서비스는 기본값으로 구성된 Mattermost 공식 STUN 서버(stun.global.calls.mattermost.com)입니다. 이는 ICE Host Override 옵션을 통해 제공되지 않는 경우 Mattermost 인스턴스의 공용 주소를 찾는 데 주로 사용됩니다. 이 서비스로 전송되는 유일한 정보는 다른 트래픽이 통과하지 않기 때문에 연결하는 클라이언트의 IP 주소입니다. ICE Host Override 설정이 제공되는 경우 제거할 수 있습니다.

참고

에어갭 배포에서는 모든 연결이 로컬 네트워크 내에 유지되므로 STUN 서버를 사용할 필요가 없습니다.

UDP 사용이 필수인가요?#

네, UDP는 피어 간 최저 지연 시간을 허용하므로 실시간 미디어 제공을 위한 권장 프로토콜입니다. 그러나 제한이나 엄격한 방화벽으로 인해 UDP를 사용할 수 없는 클라이언트를 위한 몇 가지 가능한 해결책이 있습니다:

  • 플러그인 버전 0.17과 rtcd 버전 0.11부터 RTC 서비스는 UDP 연결 외에도 TCP 연결을 수신합니다. 올바르게 구성된 경우(예: 80 또는 443과 같은 일반적으로 허용된 포트 사용) 선호하는 UDP 채널을 통해 연결할 수 없는 경우 클라이언트가 TCP를 통해 직접 연결할 수 있습니다.

  • TCP에서 수신하고 피어 간의 모든 미디어 트래픽을 중계하는 외부 TURN 서버를 통해 통화를 실행합니다. 그러나 이는 추가 지연 시간과 인프라 비용을 발생시키므로 가능하면 피해야 하는 차선책입니다.

TURN 서버가 필요한가요?#

구성된 UDP 포트를 통해 연결할 수 없는 클라이언트가 있을 것으로 예상되는 경우 TURN이 필요해집니다. 이는 나가는 방향에서도 비표준 포트를 차단하거나 UDP 프로토콜 사용을 전혀 허용하지 않는 매우 제한적인 방화벽(예: 일부 기업 방화벽)으로 인해 발생할 수 있습니다. 이러한 경우 연결을 허용하기 위해 TURN이 필요합니다.

안정적이고 성능이 좋은 TURN 서비스 구현을 위해 coturn 사용을 공식적으로 지원하고 권장합니다.

Mattermost 앞에 있는 기존 리버스 프록시와 어떻게 작동하나요?#

일반적으로 클라이언트는 구성된 UDP 포트를 통해 Mattermost 또는 배포된 경우 전용 rtcd 서비스에 직접 연결해야 합니다. 그러나 UDP 프로토콜 라우팅을 지원하는 기존 로드 밸런서(예: nginx)를 통해 트래픽을 라우팅할 수도 있습니다. 물론 HTTP와 달리 여러 인스턴스에서 UDP 흐름을 로드 밸런싱할 수 없기 때문에 추가 구성과 플러그인 실행 방식의 잠재적 변경이 필요합니다.

통화가 작동하려면 전용 서버가 필요한가요, 아니면 Mattermost와 함께 실행할 수 있나요?#

플러그인은 다양한 모드로 작동할 수 있습니다. 기본적으로 통화는 Mattermost의 일부로 실행되는 플러그인에 의해 완전히 처리됩니다. 계산 및 대역폭 비용을 오프로드하고 더 확장하기 위해 전용 서비스를 사용할 수도 있습니다(Enterprise 전용).

Mattermost와 rtcd 간의 트래픽을 내부적으로 유지할 수 있나요, 아니면 공개해야 하나요?#

가능한 경우 Mattermost 클러스터와 전용 rtcd 서비스 간의 통신을 동일한 프라이빗 네트워크 내에서 유지하는 것이 좋습니다. 이는 배포와 보안을 크게 단순화할 수 있기 때문입니다. rtcd의 HTTP API를 공개 인터넷에 노출할 필요는 없습니다.

Calls를 채널별로 롤아웃할 수 있나요?#

참고

deployment-img-yellow self-hosted 배포에서만 사용 가능

네. 자체 호스팅 배포를 실행하는 Mattermost 시스템 관리자는 채널별로 통화 기능을 활성화하거나 비활성화할 수 있습니다. Mattermost Calls에 대해 test mode가 활성화되면:

  • Calls를 활성화하려는 각 채널에서 Enable calls 를 선택하세요

  • Calls를 비활성화하려는 모든 채널에서 Disable calls 를 선택하세요.

특정 채널에 대해 Calls가 활성화되면 사용자는 해당 채널에서 통화를 시작할 수 있습니다.

참고

Mattermost Calls에 대해 test mode가 비활성화되면 모든 Mattermost 채널의 사용자가 통화를 할 수 있습니다.

문제 해결#

연결 문제#

통화 연결이 실패하거나 시간 초과되는 경우 플러그인 구성이나 네트워킹 수준에서 잘못된 구성이 있을 가능성이 높습니다.

예를 들어, RTC Server Port (UDP) 또는 RTC Server Port (TCP)가 열려 있지 않거나 올바르게 전달되지 않았을 수 있습니다.

연결 확인#

데이터가 통과할 수 있는지 확인하는 쉬운 방법은 netcat 명령줄 도구를 사용하여 일부 테스트를 수행하는 것입니다.

Calls를 실행하는 호스트(선택한 설정에 따라 Mattermost 인스턴스 자체이거나 rtcd를 실행하는 인스턴스)에서 다음을 실행하세요:

nc -l -u -p 8443

클라이언트 측(즉, Mattermost 데스크톱 앱이나 브라우저를 실행하는 데 일반적으로 사용하는 컴퓨터)에서 다음을 실행하세요:

nc -v -u HOST_IP 8443

연결이 성공하면 양쪽에서 텍스트를 입력하고 Enter를 눌러 텍스트 메시지를 주고받을 수 있어야 합니다.

참고

HOST_IP는 일반적으로 통화를 호스팅하는 Mattermost(또는 rtcd) 인스턴스의 공개(클라이언트 대면) IP여야 합니다. 설정된 경우 ICE Host Override 구성 설정의 값이어야 합니다.

8443은 RTC Server Port에 구성된 포트로 변경해야 합니다.

-u 플래그를 제거한 동일한 명령을 사용하여 TCP 포트를 통한 연결성을 테스트할 수 있습니다.

네트워크 패킷 디버깅#

네트워킹 문제를 디버깅하는 더 고급 방법은 tcpdump 명령줄 유틸리티를 사용하여 통화를 호스팅하는 인스턴스로 들어오고 나가는 네트워크 패킷을 일시적으로 모니터링하는 것입니다.

서버 측에서 다음을 실행하세요:

sudo tcpdump -n port 8443

이 명령은 포트 8443을 통해 송수신되는 모든 네트워크 패킷에 대한 정보(즉, 소스 및 대상 주소)를 출력합니다. 이는 데이터가 인스턴스로 들어오고 나가는지 확인하는 좋은 방법이며, 네트워크 구성 문제를 빠르게 식별하는 데 사용할 수 있습니다.