RTCD 설정 및 구성

요약

이 가이드는 전용 RTCD 서비스를 사용한 Mattermost Calls 배포를 설정, 구성 및 검증하는 방법에 대한 자세한 지침을 제공합니다. RTCD를 배포하기 전에 다음을 확인하세요: 환경에 따라 RTCD를 배포하는 방법이 여러 가지 있습니다.

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

사전 요구 사항#

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

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

네트워크 요구사항#

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

서비스	포트	프로토콜	출발지	목적지	목적
API (Calls 플러그인)	80,443	TCP (수신)	Mattermost 클라이언트 (웹/데스크톱/모바일)	Mattermost 인스턴스 (Calls 플러그인)	클이언트에서 Calls 플러그인으로의 HTTP 및 WebSocket 연결을 허용합니다. 이 API는 Mattermost와 동일한 연결에서 노출되므로 변경할 필요가 없을 수 있습니다.
RTC (Calls 플러그인 또는 `rtcd`)	8443	UDP (수신)	Mattermost 클라이언트 (웹/데스크톱/모바일) 및 calls-offloader	Mattermost 인스턴스 또는 `rtcd` 서비스	클이언트가 통화 관련 미디어(예: 오디오, 비디오)를 전송하는 연결을 설정할 수 있도록 합니다. 플러그인(또는 `rtcd`)을 실행하는 인스턴스와 통화에 참여하는 클라이언트 사이의 네트워크 구성 요소(예: NAT, 방화벽)에서 UDP 트래픽이 양방향(클이언트에서/클라이언트로)으로 올바르게 라우팅되도록 개방되어야 합니다.
RTC (Calls 플러그인 또는 `rtcd`)	8443	TCP (수신)	Mattermost 클라이언트 (웹/데스크톱/모바일) 및 calls-offloader	Mattermost 인스턴스 또는 `rtcd` 서비스	클이언트가 통화 관련 미디어(예: 오디오, 비디오)를 전송하는 연결을 설정할 수 있도록 합니다. 클라이언트가 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 또는 호스트명을 수동으로 설정할 때는 이 요구사항이 적용되지 않습니다.

설치 및 배포#

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

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

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

자동화된 설정을 원하십니까? Ubuntu/Debian 시스템에서 RTCD 서비스를 빠르게 프로비저닝하기 위한 커뮤니티 유지 관리 [Calls 설치 스크립트](https://github.com/bgardner8008/calls-install-scripts)를 확인하세요.

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

RTCD GitHub 저장소에서 최신 릴리즈를 다운로드합니다:

# RTCD 디렉터리 구조 생성
sudo mkdir -p /opt/rtcd

# 최신 RTCD 바이너리 다운로드 (아키텍처에 맞게 URL 조정)
# Linux x86_64의 경우:
wget https://github.com/mattermost/rtcd/releases/latest/download/rtcd-linux-amd64

# 바이너리를 실행 가능하게 하고 설치 디렉터리로 이동
chmod +x rtcd-linux-amd64
sudo mv rtcd-linux-amd64 /opt/rtcd/rtcd

시스템 아키텍처에 맞는 바이너리로 `rtcd-linux-amd64`를 교체하세요(예: ARM64 시스템의 경우 `rtcd-linux-arm64`). 바이너리는 systemd 서비스 파일 및 기타 문서에서 참조되는 예상 위치인 `/opt/rtcd/rtcd`에 배치해야 합니다.

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

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

RTCD 서비스를 위한 전용 사용자 생성:

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

데이터 디렉터리 생성 및 소유권 설정:

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

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

서비스 활성화 및 시작:

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

서비스 상태 확인:
```
sudo systemctl status rtcd
```

Docker 배포#

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

기본 구성으로 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)에서 서비스에 연결할 수 있는 모든 사람이 성공적으로 통화를 시작할 수 있습니다. 이 설정을 활성화하기 전에 보안 영향을 이해하세요.

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

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을 기본 구성 파일로 사용할 것을 권장합니다.

주목할 만한 설정은 `[rtc]` 섹션 아래의 `ice_host_override`입니다. RTCD가 NAT 뒤에 배포되거나, 복잡한 네트워크 토폴로지에 있거나, STUN을 통한 자동 주소 검색이 불안정한 경우 이 설정을 명시적으로 구성해야 할 수 있습니다. `ice_host_override`를 서버의 공용 IP 주소 또는 호스트명으로 직접 설정하는 것이 권장되는 방법입니다.

TURN 구성#

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

[rtc]
# TURN 서버 구성
   ice_servers = [
     { urls = ["turn:turn.example.com:3478"], username = "turnuser", credential = "turnpassword" }
   ]

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

시스템 튜닝#

대용량 배포의 경우 Linux 시스템을 튜닝합니다:

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

# UDP 버퍼 크기 증가
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.optmem_max = 16777216

설정 적용:
```
sudo sysctl -p
```

검증 및 테스트#

RTCD 배포 후 설치를 검증합니다:

서비스 상태 및 버전 확인:

curl http://YOUR_RTCD_SERVER:8045/version
# 서비스 정보가 포함된 JSON 객체를 반환해야 합니다
# 예시: {"build_hash":"abc123","build_date":"2023-01-15T12:00:00Z","build_version":"0.11.0","goVersion":"go1.20.4"}

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
```
TCP 연결 테스트 (활성화된 경우):

클라이언트 머신에서 다음을 실행합니다:
```
nmap -p 8443 RTCD_SERVER_IP
```
TCP 백업 채널이 활성화되어 있고 도달 가능하면 nmap에 open으로 표시됩니다.
메트릭 모니터링:

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

수평 확장#

RTCD를 수평으로 확장하려면:

여러 RTCD 인스턴스 배포:

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

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

상태 확인 구성:

비정상적인 RTCD 인스턴스를 DNS에서 자동으로 제거하는 상태 확인을 설정합니다.
Mattermost 구성:

Mattermost System Console에서 RTCD Service 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 측의 어떤 것과도 일치하지 않게 되어 플러그인이 인증할 수 없습니다. 복구 방법은 `[api.security]` 아래의 `allow_self_registration`에 따라 달라집니다:

- 기본값인 비활성 상태에서는 등록 자체가 먼저 인증을 요구하므로, 플러그인은 인증도 재등록도 할 수 없습니다. 저장소를 복원하거나 새 자격 증명을 발급받기 전까지 Calls는 동작하지 않습니다.
- 활성 상태라면 플러그인이 이 상황을 감지하고 자동으로 다시 등록하므로, 저장소를 잃어도 스스로 복구됩니다.

`allow_self_registration`을 활성화하면 API 포트에 도달할 수 있는 모든 클라이언트가 인증 없이 등록할 수 있습니다. 인터넷에서 도달 가능한 RTCD 서비스에서는 비활성으로 두고, 접근이 통제된 사설 네트워크에서만 활성화하세요.

Calls 플러그인은 플러그인 시작 시 RTCD에 연결을 열고, 서비스에 연결할 수 없으면 시작에 실패합니다. 녹음, 전사 또는 실시간 캡션을 구성한 경우 `calls-offloader` 서비스도 마찬가지입니다. 따라서 RTCD는 Mattermost 서버가 시작되기 전, 또는 Calls가 다시 활성화되기 전에 실행 중이어야 합니다.

시작 시 실패와 그 이후의 실패는 다르게 동작합니다:

- **플러그인 활성화 중**에는 초기 연결 실패로 Calls가 비활성화된 상태로 남습니다. 서버의 플러그인 상태 점검은 성공적으로 활성화된 플러그인만 모니터링하므로 재시도하지 않습니다. RTCD에 연결할 수 있게 되면 Calls 플러그인을 다시 시작해 복구하세요.
- **연결 설정 이후**에는 이후의 단절이 자동으로 재시도되므로, RTCD를 잠시 재시작핦 때도 Mattermost 측에서 조치할 필요가 없습니다. 플러그인은 호스트당 최대 8회까지 재연결을 시도하고, 제외된 호스트가 DNS에 계속 광고되어 있다면 10초 간격의 호스트 점검에 의해 다시 선택됩니다.

버전 호환성#

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

이 때문에 Mattermost 서버를 업그레이드해 더 새로운 Calls 버전이 실린 릴리즈로 옮기기 전에, 먼저 RTCD를 업그레이드하세요. 플러그인이 최소 버전 미만의 서버를 발견하면:

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

즉, 최소 버전 미만의 RTCD 서버를 DNS 레코드에 그대로 두면, 당시에는 통화가 잘 되고 있어도 다음 번 Mattermost 서버 재시작 때 Calls가 시작되지 않을 수 있습니다.

버전별 요구 사항은 {doc}중요 업그레이드 노트 <../../administration-guide/upgrade/important-upgrade-notes>를 참조하세요. 서버가 실행 중인 버전을 확인하려면 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초)을 상속합니다. 따라서 stop 명령을 내린 지 90초가 지나도록 끝나지 않은 통화는 끊깁니다.

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

단일 서버 업그레이드#

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

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

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

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

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

DNS에서 서버 제거:

RTCD Service URL이 확인하는 DNS 레코드에서 해당 서버의 IP 주소를 제거합니다.
플러그인이 변경을 인식할 때까지 대기:

플러그인은 10초마다 호스트명을 다시 확인하고, 더 이상 광고되지 않는 서버를 표시합니다. 표시된 서버는 새 통화에서 제외되지만, 이미 그 서버에서 실행 중인 통화는 중단 없이 계속됩니다.
서버가 유휴 상태가 될 때까지 대기:

rtcd_rtc_sessions_total 메트릭은 통화 그룹별 활성 RTC 세션 수를 보고합니다(RTCD 메트릭 참조). 모든 그룹의 합계가 0이 되면 안전하게 서버를 재시작할 수 있습니다.
서비스 중지:
```
sudo systemctl stop rtcd
```
이 시점에서 서버는 이미 유휴 상태이므로 즉시 종료되고, 정지 제한 시간은 발동하지 않습니다.
새 버전 설치:

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

업그레이드 확인:

curl http://YOUR_RTCD_SERVER:8045/version

서버를 DNS에 복귀:

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

서버가 로테이션에 복귀하면 다음 서버에 대해 같은 과정을 반복합니다.

- 통화는 항상 단일 서버 안에서만 존재하므로, 한 서버를 재시작하면 그 서버에 있던 통화만 영향을 받습니다.
- 서버가 로테이션에서 빠져 있는 동안 새 통화를 흡수할 수 있는 용량을 클러스터에 충분히 확보하세요. 통화가 길게 이어지면 서버가 0 세션에 도달할 때까지 꽤 오래 걸릴 수 있습니다.

Kubernetes에서 업그레이드#

RTCD Helm 차트는 기본적으로 RollingUpdate 전략에 maxUnavailable: 1을 사용하고, 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은 동시에 사용할 수 없는 파드 수의 상한일 뿐, 교체가 직렬화된다는 뜻은 아닙니다.

`terminationGracePeriod`를 30초나 60초 같은 일반적인 값으로 줄이지 마세요. 유예 기간이 끝나면 Kubernetes는 `SIGKILL`을 본내고 그 파드에서 아직 실행 중인 모든 통화가 끊깁니다. 기본값인 5시간은 길게 이어지는 회의까지도 버티도록 의도적으로 잡은 값입니다.

Mattermost와 통합#

RTCD가 제대로 설정되고 검증되면 Mattermost에서 이를 사용하도록 구성합니다:

System Console > Plugins > Calls로 이동합니다
RTCD Service URL을 RTCD 서비스 주소(단일 서버 또는 DNS 부하 분산 호스트명)로 설정합니다. URI에 생성된 자격 증명을 함께 제공하세요 (예: http://clientID:authKey@rtcd.local).
구성을 저장합니다
Mattermost 채널에서 새 통화를 만들어 테스트합니다
RTCD 로그 및 메트릭을 확인해 통화가 RTCD를 통해 라우팅되고 있는지 검증합니다

기타 Calls 문서#

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

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