홈
» 네트워크 관리자
»
BigBlueButton Kurento 미디어 서버가 부하 시 충돌하는 문제 해결
BigBlueButton Kurento 미디어 서버가 부하 시 충돌하는 문제 해결
BigBlueButton 회의가 활발하게 진행되는 동안 Kurento Media Server(KMS) 프로세스가 종료되면 녹화가 중단되거나, 이전 버전에서는 실시간 오디오 및 비디오가 중단될 수 있습니다. 유용한 첫 번째 결과는 단순히 서비스를 다시 시작하는 것만이 아니라, 어떤 미디어 스택이 영향을 받는 기능을 처리하고 있는지, 종료에 앞서 어떤 리소스 또는 오류가 발생했는지, 그리고 수정 사항이 다음 유사한 회의를 안정적으로 유지하는지 여부를 파악하는 것입니다.
먼저 BigBlueButton 버전과 해당 서버에서 Kurento가 수행하는 역할을 확인하십시오. BigBlueButton 2.5 이상 버전은 기본적으로 WebRTC 라이브 미디어에 mediasoup을 사용합니다. Kurento는 녹화용으로 사용되거나 관리자가 기존/사용자 지정 설정을 유지한 경우 여전히 사용될 수 있습니다. 따라서 "Kurento 충돌"만으로는 KMS가 과부하된 웹캠을 처리하고 있다고 단정할 수 없습니다. 버전별 차이점에 대해서는 BigBlueButton 공식 문제 해결 가이드를 참조하십시오. 아래의 자세한 KMS 해결 방법은 버전별 BigBlueButton 2.7 서버 사용자 지정 가이드를 기반으로 작성되었으므로 , 적용하기 전에 설치된 버전에 맞는 문서를 확인하십시오.
sudo bbb-conf --check미디어 스택을 변경하기 전에 설치된 BigBlueButton 버전을 확인하고 구성을 검토하는 데 사용하십시오 .
먼저 무엇이 실패했는지 확인하십시오.
서비스를 반복적으로 재시작하기 전에 증거를 수집하십시오. 사용자가 문제를 처음 발견한 시간, 영향을 받은 회의, 오디오, 웹캠, 화면 공유 또는 녹화 실패 여부, 그리고 서버 전체 또는 특정 미디어 기능만 저하되었는지 여부를 기록하십시오. 서비스 재시작은 프로세스를 일시적으로 복구할 수 있지만, 네트워크 또는 클라이언트 문제와 충돌을 구분하는 데 필요한 시간적 단서를 지워버릴 수 있습니다.
BigBlueButton 호스트에서 읽기 전용 검사부터 시작하세요.
sudo bbb-conf --check
sudo systemctl status kurento-media-server --no-pager
sudo journalctl -u kurento-media-server --since "1 hour ago" --no-pager
sudo ls -lt /var/log/kurento-media-server/ | head
릴리스 및 배포에 해당하는 유닛 이름을 사용하십시오. 서비스가 여러 KMS 유닛으로 분할된 경우, 해당 유닛과 로그를 검사하여 실패한 프로세스를 찾으십시오. systemd 저널 타임스탬프를 최신 KMS 로그와 비교하십시오. 명시적인 종료, 재시작 루프, 미디어 파이프라인 실패 또는 리소스 관련 메시지를 찾으십시오. 일치하는 실패 없이 "경고" 메시지 하나만으로는 원인을 파악하기에 충분하지 않습니다.
사용자가 실제로 Kurento를 사용하여 문제가 발생하는 트래픽을 처리하는지 확인하십시오. Firefox에서는 about:webrtc피어 연결 세부 정보를 확인할 수 있으며, Chrome에서는 다른 방법을 제공합니다 chrome://webrtc-internals. BigBlueButton의 문제 해결 문서에는 mediasoup에 대한 협상된 세션 세부 정보를 확인하는 방법이 설명되어 있습니다. 또한 구성된 미디어 서비스와 녹화 워크플로를 검토하십시오. 라이브 미디어가 mediasoup에서 제공되고 KMS가 종료될 때만 녹화가 중단되는 경우, 라이브 웹캠 설정을 무작정 변경하기보다는 녹화/Kurento 경로를 조정하십시오.
해당 미디어 프로세스의 CPU 및 메모리 사용량을 서비스 종료 시점과 비교하십시오. 이 패널은 개략적인 모니터 화면이며 실시간 서버 데이터가 아닙니다.
출구 직전에 발생하는 압력을 찾으십시오.
"부하 상태"는 여러 가지 병목 현상을 의미할 수 있습니다. 대표적인 회의가 진행 중인 동안 호스트를 샘플링하고 해당 샘플을 회의 시작 시간과 비교하십시오. 유용한 점검 사항은 다음과 같습니다.
free -h또한 vmstat 1사용 가능한 메모리, 스와핑 및 실행 대기열 압력에 대해서도 고려합니다.
mpstat -P ALL 1CPU 코어별 사용률 포화도를 확인하려면 sysstat관련 도구가 설치되어 있어야 합니다.
df -h또한 iostat -xz 1가능한 경우 전체 파일 시스템 또는 스토리지 지연 시간에 대해서도 마찬가지입니다.
journalctl -k --since "1 hour ago"메모리 부족으로 인한 종료를 포함한 커널 메시지용입니다.
systemd 상태 및 KMS 로그를 통해 반복적인 종료, 파이프라인 오류 및 활성화된 미디어 작업을 확인합니다.
서버의 평균 CPU 사용률에만 의존하지 마십시오. 미디어 프로세스는 특정 코어 하나만 바쁘게 작동할 때 다른 코어는 유휴 상태일 수 있으며, 메모리 부족으로 인해 CPU 사용률이 장시간 높게 유지되지 않더라도 프로세스가 종료될 수 있습니다. 반대로, KMS는 정상적으로 작동하지만 UDP가 차단되었거나 브라우저가 WebRTC 경로를 설정할 수 없어 사용자가 "카메라 멈춤" 오류를 보고할 수도 있습니다. BigBlueButton은 제한적인 네트워크 환경에 대한 해결책으로 TURN을 제시하고 있습니다. TURN은 연결성을 개선할 수 있지만 KMS 컴퓨팅 용량을 추가하지는 않습니다. 서비스가 계속 활성화되어 있고 로그에 리소스 관련 이벤트가 기록되지 않는 경우, 미디어 사용량 제한을 늘리기 전에 ICE, 방화벽 및 클라이언트 연결 상태를 점검하십시오.
용량은 회의 참석자 수뿐만 아니라 실제 스트림 및 처리량의 조합에 따라 달라집니다. 웹캠 접속 및 수신, 화면 공유, 오디오 세션, 녹화, 품질 설정, 회의 레이아웃 등 모든 요소가 중요합니다. 따라서 지속 가능한 용량 한도는 관련 없는 서버의 용량을 복사하는 것이 아니라 조직의 고유한 회의 패턴을 기준으로 측정해야 합니다.
제어된 환경 재현 중에 CPU, 메모리, 디스크 I/O 및 네트워크 추세를 함께 관찰하십시오. 여기에서 상승하는 선은 모니터링해야 할 범주를 나타내며, BigBlueButton의 실제 성능을 측정한 것은 아닙니다.
증거에 부합하는 치료법을 선택하십시오.
기존 KMS 배포의 경우 미디어 워크로드를 분리합니다.
BigBlueButton 2.7 사용자 지정 가이드에서는 듣기 전용 오디오, 웹캠 및 화면 공유 처리를 위해 각각 하나씩, 총 세 개의 KMS 프로세스를 실행하는 방법을 설명합니다. 이렇게 하면 미디어 시작/정지 작업을 여러 프로세스로 분산시켜 하나의 KMS 프로세스가 충돌하더라도 영향을 최소화할 수 있다고 합니다. 가이드에 설명된 설정 방법은 BigBlueButton 구성 스크립트의 enableMultipleKurentos설정을 사용한 다음 BigBlueButton을 재시작하는 것입니다. 사용 중인 버전에 맞는 지침을 따르고 재시작 후 서비스 유닛과 로그를 확인하십시오.
이러한 분리는 격리 및 분산 조치일 뿐, 충분한 CPU, 메모리 또는 저장 공간을 대체하는 것은 아닙니다. 또한 추가 프로세스가 실행되므로 기본 리소스 사용량이 증가할 수 있습니다. 유지 관리 기간을 예약하면 sudo bbb-conf --restart활성 세션이 중단됩니다. 생성된 서비스 파일을 수동으로 편집하거나 2.7 버전에 대해 문서화된 명령이 최신 버전 또는 공급업체에서 수정한 설치 환경에 변경 없이 적용될 것이라고 가정하지 마십시오.
서버에 접근 제한이 필요한 경우 미디어 임계값을 설정하세요.
문서화된 옵션을 지원하는 KMS 기반 버전의 경우, BigBlueButton은 , , 및 mediaThresholds값을 허용합니다 . 2.7 가이드에서는 이러한 값이 패키지 업그레이드 시에도 유지되도록 설계된 재정의 파일인 에 있음을 보여줍니다. 문서화된 예제에서 0은 제한이 없음을 의미합니다. 구성된 임계값에 도달하면 참가자가 웹캠을 공유하려고 할 때 "미디어 리소스를 사용할 수 없습니다(2002)" 오류가 발생할 수 있습니다.globalperRoomperUser/etc/bigbluebutton/bbb-webrtc-sfu/production.yml
측정된 용량과 필요한 서비스 품질을 기준으로 값을 선택하십시오. 문서에 제시된 예시 값을 일반적인 안전 한계값으로 붙여넣지 마십시오. 임계값은 추가 미디어를 거부함으로써 과부하를 더 예측 가능하게 만들지만, 버그, 메모리 누수 또는 관련 없는 운영 체제 제한으로 인한 충돌을 해결하지는 않습니다. 배포하기 전에 해당 릴리스의 문서에서 설정 이름과 동작을 확인하십시오.
구성 예시에서는 임계값 키만 식별합니다. 측정된 부하와 해당 BigBlueButton 설명서에서 버전 호환 값을 선택하십시오.
용량 예상치를 높이기 전에 미디어 수요를 줄이세요.
모니터링 결과 리소스 포화 상태가 감지되면, 먼저 서비스가 수행해야 하는 최대 작업량을 줄이십시오. 진행자에게 웹캠을 선택적으로 켜도록 요청하고, 불필요한 동시 화면 공유를 피하거나, 교육 형식에 맞는 경우 대규모 대화형 세션을 더 작은 방으로 분할하도록 하십시오. 웹캠 페이지네이션 또는 스트림 제한 기능이 지원되는 버전의 경우, 문서화된 재정의 메커니즘을 통해 해당 설정을 조정하십시오. 수신 스트림 수를 줄이면 팬아웃을 줄일 수 있고, 카메라 해상도 또는 비트레이트를 낮추면 처리 및 대역폭 요구량을 줄일 수 있습니다. 이러한 변경 사항은 시각적 세부 정보나 즉흥성을 희생하는 대신 안정성을 확보하는 것이므로, 회의 주최자에게 이러한 장단점을 설명하고 결과적인 사용자 경험이 만족스러운지 확인하십시오.
제한 사항이 다시 적용될 경우 업그레이드 또는 아키텍처 변경을 고려하십시오.
설치된 버전이 오래된 경우, KMS 튜닝에 추가 투자를 하기 전에 지원되는 업그레이드 경로와 미디어 아키텍처를 확인하십시오. BigBlueButton 2.5 버전부터는 라이브 미디어 처리에 mediasoup이 기본값으로 사용되며, Kurento의 역할은 이전 버전과 다릅니다. 따라서 현재 서버에서 KMS가 지속적으로 충돌하는 경우, 녹화, 사용자 지정 미디어 스택 또는 특정 통합 문제가 원인일 수 있습니다. 적절한 제한 및 워크로드 변경 후에도 측정된 한계에 반복적으로 도달하는 기존 배포 환경의 경우, 임계값을 높이는 것보다 배포 환경을 업그레이드하거나 재설계하는 것이 더 효과적일 수 있습니다. 운영 비용은 호환성 테스트, 마이그레이션 계획 및 유지 관리 기간에 발생합니다.
유사한 회의에서 변경 사항을 검증하십시오.
한 번에 하나의 설정이나 작업 부하 방식을 변경한 다음, 일반적인 최대 사용 환경과 유사한 통제된 회의를 통해 테스트하십시오. BigBlueButton 릴리스 시간, 참가자 수, 활성 웹캠 수, 화면 공유 횟수, 녹화 활성화 여부를 기록하십시오. 이렇게 하면 참가자 수를 유일한 부하 변수로 고려하지 않고 유용한 비교를 할 수 있습니다.
해당 KMS 장치가 활성 상태를 유지하고 재시작 루프에 빠지지 않는지 확인하십시오.
테스트 전후의 코어별 CPU 사용량, 사용 가능한 메모리 및 스왑 공간, 디스크 활동, 로그를 비교합니다.
Kurento의 실제 역할에 따라 오디오, 웹캠, 화면 공유 및 녹화 기능을 각각 확인하십시오.
2002 오류, 미디어 설정 실패 또는 사용자 보고서의 변경 사항을 확인하십시오. 단일 지표만으로는 문제 해결을 입증할 수 없습니다.
용량 변경이 성공적이라고 선언하기 전에 예상되는 혼잡 시간대에 이 과정을 반복하십시오.
서비스가 계속 충돌하는 경우, 정확한 KMS 로그 및 저널 창, 커널 메시지, 설치된 BigBlueButton/Kurento 버전, 그리고 활성 구성 재정의 내용을 관리자 또는 지원팀에 제공하십시오. 서비스는 정상적으로 작동하지만 사용자가 여전히 연결할 수 없는 경우, ICE 후보, 방화벽 규칙, TURN 가용성 및 브라우저 측 WebRTC 진단으로 조사 범위를 전환하십시오. 궁극적인 목표는 무제한 스트림 수나 모든 서버에 적합한 단일 구성이 아니라, 명확한 제한 사항이 있는 안정적인 미디어 워크로드를 구현하는 것입니다.