RTCD 설정과 구성

이 가이드는 전용 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
   

   참고

   rtcd-linux-amd64를 시스템 아키텍처에 맞는 바이너리로 교체하세요(예: ARM64 시스템의 경우 rtcd-linux-arm64). systemd 서비스 파일을 비롯한 여러 문서가 /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
   

   참고

   RTCD_API_SECURITY_ALLOWSELFREGISTRATION 설정을 사용하는 경우, 기본값이 false라는 점에 유의하세요. 이 설정을 활성화하면 API 포트(8045)로 서비스에 접속할 수 있는 사람이라면 누구나 통화를 시작할 수 있게 됩니다. 활성화하기 전에 이 설정의 보안 영향을 충분히 이해하세요.

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를 다시 시작합니다.

   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 System Console에서 RTCD Service URL을 해당 DNS 이름(예: rtcd.example.com)으로 설정합니다.

통화가 시작되면 Mattermost 서버는 (설정된 DNS 레코드를 통해) 사용 가능한 RTCD 서버들을 살펴본 뒤 CPU 사용률이 가장 낮은 서버에서 통화를 시작합니다. 해당 통화의 모든 참가자는 그 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 Service URL이 해석하는 서버 중 하나라도 점검에 실패하면 발생하며, 전부 실패해야 하는 것이 아닙니다.
• 플러그인이 이미 실행 중인 상태에서 DNS를 통해 발견된 서버라면, 실패가 오류로 기록되고 해당 서버는 사용되지 않습니다. 통화는 나머지 서버로 계속 라우팅됩니다.

즉, 최소 버전에 못 미치는 RTCD 서버를 DNS 레코드에 남겨 두면 지금은 통화가 정상 동작하더라도 다음번 Mattermost 서버 재시작 때 Calls가 시작되지 못할 수 있습니다.

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

RTCD의 종료 방식

RTCD는 SIGTERM이나 SIGINT 신호를 받으면 즉시 종료하지 않고 드레인합니다. 즉, 활성 통화 세션이 모두 끝날 때까지 기다린 뒤에 종료합니다. 진행 중인 통화가 강제로 종료되는 일은 없으며 드레인 타임아웃도 없으므로, 프로세스는 마지막 통화가 지속되는 동안 계속 대기합니다.

이 동작에서 두 가지가 따라옵니다.

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

systemctl stop rtcd는 서비스에 SIGTERM을 보내며, 기본값인 KillMode=control-group에서는 해당 유닛의 컨트롤 그룹에 속한 모든 프로세스에 보냅니다. 그 뒤 systemd는 TimeoutStopSec만큼 기다렸다가 SIGKILL로 넘어갑니다. 이 값을 명시적으로 설정하지 않으면 DefaultTimeoutStopSec을 상속하는데, 기본 systemd 설치에서는 90초입니다. 따라서 중지 명령을 내린 뒤 90초가 지나도 진행 중인 통화는 끊깁니다.

아래의 롤링 업그레이드는 서버를 중지하기 전에 DNS를 통해 드레인시키므로 이 문제를 원천적으로 피합니다. 서비스를 중지하는 시점에는 서버가 이미 유휴 상태이므로 타임아웃이 개입할 여지가 없습니다.

단일 서버 업그레이드

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

• 드레인이 끝날 때까지 기다립니다. SIGTERM을 보내고 마지막 통화가 끝난 뒤 서비스가 종료되도록 둡니다. 끊기는 통화는 없지만, 중단 시간은 그 통화들이 얼마나 오래 지속되는지에 달려 있고 그동안 새 통화는 실패합니다. 다만 드레인이 끝까지 진행되려면 프로세스 관리자가 이를 허용해야 합니다. systemd의 기본 90초 중지 타임아웃에서는 그보다 긴 드레인이 중간에 잘리고 남은 통화가 끊깁니다.
• 정해진 시각에 서비스를 중지합니다. 참가자에게 미리 알린 뒤, 일정 시간이 지나면 SIGKILL로 프로세스를 강제 종료합니다. 그때까지 진행 중이던 통화는 끊기고, 클라이언트에는 해당 통화가 종료된 것으로 표시됩니다.

사용량이 적은 시간대로 업그레이드 일정을 잡으면 어느 쪽을 택하든 영향이 짧아집니다. 사용자에게 알릴 때 쓸 템플릿은 예정된 유지 보수 공지를 참고하세요.

여러 서버를 사용하는 롤링 업그레이드

수평 확장을 구성한 경우, 통화를 끊지 않고 서버를 한 대씩 업그레이드할 수 있습니다. 각 서버에 대해 차례로 다음을 수행합니다.

1. DNS에서 서버를 제거합니다:

   RTCD Service 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시간)로 설정합니다. 이 값은 파드의 terminationGracePeriodSeconds로 매핑되므로, Kubernetes는 파드가 통화를 드레인할 시간을 5시간까지 허용합니다.

이미지를 변경하기 전에 데이터 스토어를 어떻게 다룰지 결정하세요. 이 차트에는 PersistentVolumeClaim 템플릿이 포함되어 있지 않고 스토어는 기본적으로 컨테이너 내부 경로에 있으므로, 교체된 파드는 모두 빈 스토어로 시작합니다. 스토어는 파드마다 인스턴스가 하나씩 있는 로컬 임베디드 데이터베이스이므로 여러 레플리카가 볼륨 하나를 공유할 수도 없습니다. 실행 가능한 접근 방식은 두 가지입니다.

• 파드가 다시 등록하도록 둡니다. 위 주의 항목에서 설명한 대로 접근이 통제되는 사설 네트워크에서 allow_self_registration을 활성화하면, 플러그인이 새 파드마다 자동으로 다시 등록합니다. 스토리지 설정이 전혀 필요 없는 더 간단한 선택지입니다.
• 파드마다 자체 스토리지를 제공합니다. deploymentType: daemonset을 사용하면 노드당 파드가 하나씩 실행되므로, configuration.extraVolumes와 configuration.extraVolumeMounts를 통해 data_source 경로에 노드별 hostPath를 마운트하면 이미지를 교체해도 유지되는 스토어를 각 파드에 제공할 수 있습니다.

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

이 차트는 maxSurge를 설정하지 않으므로 Deployment 롤아웃은 Kubernetes 기본값을 사용하며, 드레인 중인 파드가 종료되기 전에 새 파드가 생성될 수 있습니다. 드레인이 지속되는 동안 이전 파드와 새 파드가 함께 실행될 것을 예상하고 그에 맞게 노드 풀 크기를 잡으세요. maxUnavailable: 1은 동시에 사용 불가 상태가 될 수 있는 파드 수를 제한할 뿐이며, 교체를 순차적으로 진행하게 만들지는 않습니다.

Mattermost와의 연동

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

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

2. RTCD Service URL을 RTCD 서비스 주소(단일 서버 또는 DNS 로드 밸런싱된 호스트명)로 설정합니다. 설정 과정에서 생성된 자격 증명이 있다면 URI에 반드시 포함하세요(예: http://clientID:authKey@rtcd.local).

3. 설정을 저장합니다

4. 아무 Mattermost 채널에서 새 통화를 시작해 테스트합니다

5. RTCD 로그와 지표를 확인해 통화가 RTCD를 통해 라우팅되고 있는지 검증합니다

그 밖의 Calls 문서

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

Mattermost Calls의 상세한 설정 옵션은 Calls 플러그인 설정 문서를 참고하세요.