사용 가능 플랜: Enterprise, Enterprise Advanced

이 가이드는 전용 RTCD 서비스를 사용한 Mattermost Calls 배포를 설정, 구성 및 검증하는 방법에 대한 자세한 지침을 제공합니다.

사전 요구 사항#

RTCD를 배포하기 전에 다음을 확인하세요.

• Mattermost Enterprise 라이선스
• 충분한 CPU 및 네트워크 용량을 갖춘 서버 또는 VM (사이징 지침은 성능 기준 섹션 참조)

네트워크 요구 사항#

다음 네트워크 연결이 필요합니다.

설치 및 배포#

환경에 따라 RTCD를 배포하는 방법이 여러 가지 있습니다. 프로덕션 준비도와 운영 제어를 기준으로 다음 순서를 권장합니다.

베어메탈 또는 VM 배포 (권장)#

이 방법은 Kubernetes가 아닌 프로덕션 환경에서 권장하는 배포 방법으로, 최상의 성능과 운영 제어를 제공합니다. Kubernetes 배포의 경우 Kubernetes에서 Calls 배포 가이드를 참조하세요.

1. RTCD 바이너리 다운로드 및 설치:

   RTCD GitHub 리포지터리에서 최신 릴리즈를 다운로드합니다.

   # Create the RTCD directory structure
   sudo mkdir -p /opt/rtcd
   
   # Download the latest RTCD binary (adjust URL for your architecture)
   # For Linux x86_64:
   wget https://github.com/mattermost/rtcd/releases/latest/download/rtcd-linux-amd64
   
   # Make the binary executable and move it to the installation directory
   chmod +x rtcd-linux-amd64
   sudo mv rtcd-linux-amd64 /opt/rtcd/rtcd
   

2. 구성 파일 생성 (/opt/rtcd/rtcd.toml):

   Mattermost는 공식 config.sample.toml을 시작점으로 사용할 것을 권장합니다. 이 파일을 다운로드하여 기본 구성으로 사용하세요.

3. RTCD 서비스를 위한 전용 사용자를 생성합니다.

   sudo useradd --system --no-create-home --shell /bin/false mattermost
   

4. 데이터 디렉터리를 생성하고 소유권을 설정합니다.

   sudo mkdir -p /opt/rtcd/data/db
   sudo chown -R mattermost:mattermost /opt/rtcd
   

5. systemd 서비스 파일(/etc/systemd/system/rtcd.service)을 생성합니다.

   [Unit]
   Description=Mattermost RTCD Server
   After=network.target
   
   [Service]
   Type=simple
   User=mattermost
   Group=mattermost
   ExecStart=/opt/rtcd/rtcd --config /opt/rtcd/rtcd.toml
   Restart=always
   RestartSec=10
   LimitNOFILE=65536
   
   [Install]
   WantedBy=multi-user.target
   

6. 서비스를 활성화하고 시작합니다.

   sudo systemctl daemon-reload
   sudo systemctl enable rtcd
   sudo systemctl start rtcd
   

7. 서비스 상태를 확인합니다.

   sudo systemctl status rtcd
   

Docker 배포#

Docker 배포는 개발, 테스트 또는 컨테이너화된 프로덕션 환경에 적합합니다.

1. 기본 구성으로 RTCD 컨테이너를 실행합니다.

   docker run -d --name rtcd \
     -e "RTCD_LOGGER_ENABLEFILE=true" \
     -p 8443:8443/udp \
     -p 8443:8443/tcp \
     -p 8045:8045/tcp \
     mattermost/rtcd:latest
   

2. 디버깅 목적으로 더 자세한 로깅을 활성화할 수 있습니다.

   docker run -d --name rtcd \
     -e "RTCD_LOGGER_ENABLEFILE=true" \
     -e "RTCD_LOGGER_CONSOLELEVEL=DEBUG" \
     -p 8443:8443/udp \
     -p 8443:8443/tcp \
     -p 8045:8045/tcp \
     mattermost/rtcd:latest
   

   로그를 보려면 다음을 실행합니다.

   docker logs -f rtcd
   

환경 변수 대신 마운트한 구성 파일을 사용할 수도 있습니다.

docker run -d --name rtcd \
  -p 8045:8045 \
  -p 8443:8443/udp \
  -p 8443:8443/tcp \
  -v /path/to/config.toml:/rtcd/config/config.toml \
  mattermost/rtcd:latest

전체 샘플 구성 파일은 공식 리포지터리의 RTCD config.sample.toml을 참조하세요.

Kubernetes 배포#

Helm 차트 구성, 리소스 요구 사항, 확장 시 고려 사항을 포함하여 Kubernetes 환경에서 RTCD를 배포하는 방법에 대한 자세한 내용은 Kubernetes에서 Calls 배포 가이드를 참조하세요.

구성#

RTCD 구성 파일#

RTCD 서비스는 TOML 구성 파일을 사용합니다. Mattermost는 공식 config.sample.toml을 기본 구성 파일로 사용할 것을 권장합니다.

TURN 구성#

엄격한 방화벽 뒤에 있는 클라이언트를 위해 TURN 서버를 구성해야 할 수 있습니다. RTCD 구성 파일에서 다음과 같이 TURN 서버를 참조합니다.

[rtc]
# TURN server configuration
   ice_servers = [
     { urls = ["turn:turn.example.com:3478"], username = "turnuser", credential = "turnpassword" }
   ]

TURN 서버 구현에는 coturn 사용을 권장합니다.

시스템 튜닝#

대용량 배포의 경우 Linux 시스템을 튜닝하세요.

1. /etc/sysctl.conf에 다음을 추가합니다.

   # Increase UDP buffer sizes
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.core.optmem_max = 16777216
   

2. 설정을 적용합니다.

   sudo sysctl -p
   

검증 및 테스트#

RTCD를 배포한 후 설치를 검증하세요.

1. 서비스 상태 및 버전 확인:

   curl http://YOUR_RTCD_SERVER:8045/version
   # Should return a JSON object with service information
   # Example: {"build_hash":"abc123","build_date":"2023-01-15T12:00:00Z","build_version":"0.11.0","goVersion":"go1.20.4"}
   

2. UDP 연결 테스트:

   테스트하기 전에 RTCD 서비스가 같은 포트에 바인딩되므로 서비스가 중지되어 있는지 확인하세요.

   sudo systemctl stop rtcd
   

   RTCD 서버에서 다음을 실행합니다.

   sudo ncat -u -l -k -p 8443 -c '/bin/cat'
   

   클라이언트 머신에서 다음을 실행합니다.

sudo nmap -sU -p 8443 RTCD_SERVER_IP

   
UDP 연결이 작동하면 `nmap`이 `open`으로 보고합니다.

테스트 후 RTCD를 다시 시작합니다.

```bash
sudo systemctl start rtcd

3. TCP 연결 테스트 (활성화한 경우):

   클라이언트 머신에서 다음 확인을 실행합니다.

   nmap -p 8443 RTCD_SERVER_IP
   

   TCP 폴백이 활성화되어 있고 도달할 수 있으면 nmap이 open으로 보고합니다.

4. 메트릭 모니터링:

   Calls 메트릭 및 모니터링 설정은 Calls 메트릭 및 모니터링을 참조하세요.

수평 확장#

RTCD를 수평으로 확장하려면 다음과 같이 합니다.

1. 여러 RTCD 인스턴스 배포:

   각각 고유한 IP 주소를 가진 여러 RTCD 서버를 배포합니다.

2. DNS 레코드 구성:

   여러 RTCD IP 주소를 가리키는 DNS 레코드를 설정합니다.

   rtcd.example.com.    IN A    10.0.0.1
   rtcd.example.com.    IN A    10.0.0.2
   rtcd.example.com.    IN A    10.0.0.3
   

3. 상태 확인 구성:

   비정상 상태인 RTCD 인스턴스를 DNS에서 자동으로 제거하도록 상태 확인을 설정합니다.

4. Mattermost 구성:

   Mattermost 시스템 콘솔에서 RTCD 서비스 URL을 DNS 이름으로 설정합니다(예: rtcd.example.com).

통화가 시작되면 Mattermost 서버는 구성된 DNS 레코드를 통해 사용 가능한 RTCD 서버를 확인하고, CPU 사용량이 가장 낮은 RTCD 서버에서 통화를 시작합니다. 통화의 모든 참가자는 해당 RTCD 서버에 연결되며, 하나의 통화를 여러 서버가 나누어 처리할 수는 없습니다.

RTCD 업그레이드#

RTCD는 Mattermost 서버와 독립적으로 릴리즈되고 업그레이드됩니다. 업그레이드는 바이너리 또는 컨테이너 이미지를 교체하고 서비스를 다시 시작하는 것으로 이루어지며, 데이터베이스나 스키마 마이그레이션은 포함되지 않습니다. 준비해야 할 것은 두 가지입니다. 데이터 저장소를 보존하는 것과, 진행 중인 통화가 끊기지 않도록 재시작 시점을 정하는 것입니다.

릴리즈는 RTCD GitHub 리포지터리에 rtcd-linux-amd64 및 rtcd-linux-arm64 바이너리로, Docker Hub에는 mattermost/rtcd 이미지로 게시됩니다.

데이터 저장소 보존#

RTCD는 구성 파일 [store] 섹션의 data_source가 지정하는 경로(기본값 /tmp/rtcd_db)에 작은 로컬 저장소를 유지합니다. 이 저장소에는 Mattermost 서버가 등록한 클라이언트 ID와 각 클라이언트 인증 키의 bcrypt 해시가 보관됩니다. RTCD가 유지하는 상태는 이것뿐이므로, 업그레이드 후에도 반드시 보존되어야 합니다.

• 베어메탈 또는 VM. 저장소는 바이너리 바깥에 있으므로 바이너리를 제자리에서 교체하면 그대로 보존됩니다. 다만 data_source가 재부팅 시 삭제되는 위치를 가리키지 않는지 확인하세요. 기본값인 /tmp/rtcd_db는 많은 배포판에서 임시 파일 시스템에 있습니다.
• Docker. 저장소는 마운트하지 않는 한 컨테이너 파일 시스템 안에 있으므로, 컨테이너를 다시 만들면 삭제됩니다. 이미지를 교체한 뒤에도 저장소를 유지하려면 data_source 경로에 볼륨을 마운트하세요.

서비스를 중지한 상태에서 저장소 디렉터리를 복사하여 백업하세요.

버전 호환성#

Calls 플러그인은 RTCD의 최소 버전을 요구하며, 그보다 낮은 버전이 실행 중인 서버는 사용하지 않습니다.

이러한 이유로, 더 새로운 버전의 Calls가 포함된 릴리즈로 Mattermost 서버를 업그레이드하기 전에 RTCD를 먼저 업그레이드하세요. 플러그인이 최소 버전보다 낮은 서버를 발견하면 다음과 같이 동작합니다.

• Mattermost 서버를 재시작하거나 업그레이드한 후와 같이 플러그인이 활성화될 때는 버전 점검에 실패하여 Calls 플러그인이 아예 시작되지 않습니다. 이는 RTCD 서비스 URL로 확인된 서버 중 하나라도 점검에 실패하면 발생하며, 모든 서버가 실패할 때만 발생하는 것이 아닙니다.
• 플러그인이 이미 실행 중일 때 DNS를 통해 발견한 서버가 점검에 실패하면 오류로 기록되고 해당 서버는 사용되지 않습니다. Calls는 나머지 서버로 계속 라우팅됩니다.

즉, 최소 버전보다 낮은 RTCD 서버를 DNS 레코드에 그대로 두면, 당시에는 통화가 정상적으로 이루어지고 있더라도 다음번 Mattermost 서버 재시작 시 Calls가 시작되지 않을 수 있습니다.

버전별 요구 사항은 중요 업그레이드 노트를 참조하세요. 서버가 실행 중인 버전을 확인하려면 curl http://YOUR_RTCD_SERVER:8045/version으로 서버를 직접 조회하세요.

RTCD 종료 방식#

RTCD가 SIGTERM 또는 SIGINT 신호를 받으면 즉시 종료하지 않고 드레인(drain)합니다. 모든 활성 통화 세션이 끝날 때까지 기다린 뒤에 종료합니다. 진행 중인 통화는 강제로 닫히지 않으며 드레인 제한 시간도 없으므로, 프로세스는 마지막 통화가 끝날 때까지 기다립니다.

이 동작에서 다음 두 가지를 알아 두어야 합니다.

• HTTP 및 WebSocket API 리스너는 드레인 중에도 열려 있으므로, 드레인 중인 서버에 새 통화가 배정될 수 있습니다. 프로세스에 신호를 보내기 전에 DNS 레코드에서 서버를 제거하세요. 그렇지 않으면 플러그인이 계속 새 통화를 보내 드레인이 끝나지 않을 수 있습니다.
• 제한 시간이 지나면 서비스를 강제로 종료하는 프로세스 관리자는 해당 서버에서 아직 진행 중인 통화를 끊으며, 기본 제한 시간은 대체로 통화 시간보다 짧습니다.

systemctl stop rtcd는 서비스에 SIGTERM을 보내며, 기본값인 KillMode=control-group에서는 유닛의 컨트롤 그룹에 속한 모든 프로세스에도 신호를 보냅니다. 이후 systemd는 TimeoutStopSec 동안 기다린 다음 SIGKILL로 격상합니다. 이 값을 명시적으로 설정하지 않으면 DefaultTimeoutStopSec을 상속하며, 기본 systemd 설치에서는 90초입니다. 따라서 제한 시간이 만료될 때 아직 진행 중인 통화는 끊깁니다.

아래의 롤링 업그레이드는 서버를 중지하기 전에 DNS를 통해 드레인하므로, 서비스를 중지할 때는 서버가 이미 유휴 상태이고 제한 시간이 적용되지 않습니다.

단일 서버 업그레이드#

RTCD 서버가 한 대뿐이라면 업그레이드 중에 서비스가 중단됩니다. 프로세스가 내려가 있는 동안에는 새 통화를 시작할 수 없고, 서비스는 종료 시 드레인하므로 기존 통화가 끝나야 재시작이 완료됩니다. 선택지는 두 가지입니다.

• 드레인이 끝날 때까지 기다립니다. SIGTERM을 보내고 마지막 통화가 끝난 뒤 서비스가 종료되도록 둡니다. 끊기는 통화는 없지만, 중단 시간은 해당 통화가 얼마나 오래 이어지는지에 따라 달라지며 그동안 새 통화는 실패합니다. 드레인은 프로세스 관리자가 허용하는 경우에만 끝까지 진행된다는 점에 유의하세요. systemd의 기본 중지 제한 시간은 90초이므로, 더 긴 드레인은 중간에 끊기고 남은 통화는 끊깁니다.
• 정해진 시간에 서비스를 중지합니다. 참가자에게 알린 다음, 정해진 시간이 지나면 SIGKILL로 프로세스를 강제 종료합니다. 그때까지 진행 중이던 통화는 모두 끊기며, 클라이언트에는 해당 통화가 종료된 것으로 표시됩니다.

사용량이 적은 시간대에 업그레이드를 예약하면 두 선택지 모두 중단 시간이 짧아집니다. 사용자에게 알릴 때 쓸 수 있는 템플릿은 예정된 유지 관리 안내를 참조하세요.

다중 서버 롤링 업그레이드#

수평 확장이 구성되어 있다면 통화를 끊지 않고 서버를 한 대씩 업그레이드할 수 있습니다. 각 서버에 대해 차례로 다음을 수행하세요.

1. DNS에서 서버 제거:

   RTCD 서비스 URL이 확인하는 DNS 레코드에서 해당 서버의 IP 주소를 제거합니다.

2. 플러그인이 변경 사항을 인식할 때까지 대기:

   플러그인은 10초마다 호스트 이름을 다시 확인하며, 더 이상 광고되지 않는 서버를 표시합니다. 표시된 서버는 새 통화에서 제외되지만, 이미 그 서버에서 진행 중인 통화는 중단 없이 계속됩니다.

3. 서버가 유휴 상태가 될 때까지 대기:

   rtcd_rtc_sessions_total 메트릭은 통화 그룹별 활성 RTC 세션 수를 보고합니다(RTCD 메트릭 참조). 모든 그룹의 합계가 0이 되면 서버를 안전하게 재시작할 수 있습니다.

4. 서비스 중지:

   sudo systemctl stop rtcd
   

   이 시점에서 서버는 이미 유휴 상태이므로 즉시 종료되며, 중지 제한 시간은 적용되지 않습니다.

5. 새 버전 설치:

   바이너리 또는 컨테이너 이미지를 새 버전으로 교체하고 서비스를 다시 시작합니다.

6. 업그레이드 확인:

   curl http://YOUR_RTCD_SERVER:8045/version
   

7. 서버를 DNS에 복귀:

   해당 서버의 IP 주소를 DNS 레코드에 다시 추가합니다. 플러그인은 다음 확인 주기에 이 서버를 다시 인식하고 새 통화를 배정하기 시작합니다.

서버가 다시 로테이션에 포함되면 다음 서버에 대해 같은 과정을 반복합니다.

Kubernetes에서 업그레이드#

RTCD Helm 차트는 기본적으로 maxUnavailable: 1인 RollingUpdate 전략을 사용하며, configuration.terminationGracePeriod를 18000초(5시간)로 설정합니다. 이 값은 Pod의 terminationGracePeriodSeconds에 매핑되므로, Kubernetes는 Pod를 종료하기 전에 통화를 드레인할 수 있도록 Pod에 5시간을 허용합니다.

이미지를 변경하기 전에 데이터 저장소를 어떻게 처리할지 결정하세요. 차트에는 PersistentVolumeClaim 템플릿이 없고 저장소는 기본적으로 컨테이너 안의 경로에 있으므로, 교체된 Pod는 모두 빈 저장소로 시작합니다. 저장소는 Pod당 하나씩 두는 로컬 임베디드 데이터베이스이므로 하나의 볼륨을 여러 레플리카가 공유할 수도 없습니다. 적용할 수 있는 방법은 두 가지입니다.

• Pod가 다시 등록하도록 허용. 위의 경고에서 설명한 대로 접근이 통제된 사설 네트워크에서 allow_self_registration을 활성화하면, 플러그인이 새 Pod마다 자동으로 다시 등록합니다. 저장소 구성이 필요 없는 더 간단한 방법입니다.
• Pod마다 별도 스토리지 제공. deploymentType: daemonset을 사용하면 노드당 Pod가 하나씩 실행되므로, configuration.extraVolumes와 configuration.extraVolumeMounts를 통해 data_source 경로에 노드별 hostPath를 마운트하면 이미지를 교체해도 각 Pod의 저장소가 유지됩니다.

업그레이드하려면 values 파일에서 image.tag를 새 버전으로 설정하고 차트를 적용하세요. Kubernetes는 교체하는 각 Pod에 SIGTERM을 보내며, 이로써 위에서 설명한 드레인이 시작됩니다.

차트는 maxSurge를 설정하지 않으므로 Deployment 롤아웃은 Kubernetes 기본값을 따르며, 드레인 중인 Pod가 종료되기 전에 새 Pod가 만들어질 수 있습니다. 드레인이 끝날 때까지 이전 Pod와 새 Pod가 함께 실행될 것으로 예상하고 그에 맞게 노드 풀 크기를 정하세요. maxUnavailable: 1은 동시에 사용할 수 없는 Pod 수의 상한일 뿐, 교체가 순차적으로 이루어진다는 뜻은 아닙니다.

Mattermost와 통합#

RTCD를 올바르게 설정하고 검증했다면 Mattermost가 이를 사용하도록 구성합니다.

1. System Console > Plugins > Calls로 이동합니다.

2. RTCD 서비스 URL을 RTCD 서비스 주소(단일 서버 또는 DNS 로드 밸런싱 호스트 이름)로 설정합니다. URI에 생성된 자격 증명을 함께 입력해야 합니다(예: http://clientID:authKey@rtcd.local).

3. 구성을 저장합니다.

4. Mattermost의 아무 채널에서나 새 통화를 만들어 테스트합니다.

5. RTCD 로그 및 메트릭을 확인하여 통화가 RTCD를 통해 라우팅되고 있는지 검증합니다.

기타 Calls 문서#

• Calls 배포 가이드: 배포 옵션 및 아키텍처 개요
• Calls Offloader 설정 및 구성: 통화 녹음 및 전사 설정 가이드
• Calls 메트릭 및 모니터링: 메트릭과 관측 가능성을 활용한 Calls 성능 모니터링 가이드
• Kubernetes에서 Calls 배포: Kubernetes 환경에서 Calls를 배포하는 상세 가이드
• Calls 로깅: Calls 로그와 클라이언트 진단 정보 수집에 대한 상세 안내

Mattermost Calls 구성 옵션에 대한 자세한 내용은 Calls 플러그인 구성 설정 문서를 참조하세요.