Matrix Synapse Federation 지연 및 느린 회의실 참가 문제를 해결합니다.

먼저 지연 원인을 찾으세요.

Matrix 룸을 열거나 참가하는 데 시간이 오래 걸리는 경우, 먼저 지연이 특정 원격 홈서버, 특정 룸 또는 전체 Synapse 인스턴스에 영향을 미치는지 확인하십시오. 이 구분은 중요합니다. 페더레이션은 홈서버 간의 양방향 교환이며, 룸 참가에는 여러 서버가 관여할 수 있기 때문입니다. 참가 속도 저하는 Synapse 프로세스, 원격 서버, DNS 또는 TLS 라우팅, 데이터베이스, 룸 크기 및 상태 등 다양한 원인으로 발생할 수 있습니다. 이러한 모든 문제를 해결하는 단일 "페더레이션 지연" 솔루션은 없습니다.

확인됨: Synapse는 원격 대상 재시도 정보를 기록하고, Prometheus 메트릭을 제공하며, 회의실 참가 속도 제한을 포함합니다. 상황에 따라 이러한 요소 중 어떤 것이 개별 참가 속도 저하의 원인인지 파악하기 어렵습니다. 증상만으로는 알 수 없습니다. 다른 홈서버가 느린지, 아니면 중간 네트워크가 느린지 알 수 없습니다. 먼저 영향을 받는 사용자 한 명, 회의실 하나, 그리고 참가 속도 저하 시도가 발생한 대략적인 시간을 기록하고, 이를 정상적으로 참가하는 대조군 회의실과 비교해 보세요.

연합에 접속 가능한지 확인하십시오.

공식 Matrix Federation Tester를 사용 하여 홈서버의 Matrix 서버 이름을 입력하세요. 이 도구는 일반적인 DNS, 위임, 인증서 및 연결성 문제를 파악하는 데 도움이 됩니다. 사용자 ID의 서버 이름은 Synapse를 제공하는 시스템 또는 프록시와 다를 수 있으므로, 사용자 ID 도메인이 Synapse를 직접 호스팅한다고 가정하기보다는 구성된 페더레이션 엔드포인트와 위임 설정을 확인하세요.

Synapse의 페더레이션 문서에 따르면 기본 페더레이션 포트는 TCP 8448이며, 위임 또는 역방향 프록시 배포의 경우 HTTPS 443 포트를 사용할 수 있습니다. 해당 포트는 다른 홈 서버에서 접근 가능해야 하며, 아웃바운드 방화벽에서도 페더레이션 트래픽을 허용해야 할 수 있습니다. 일치하는 인바운드 및 아웃바운드 방화벽 규칙을 확인한 후 페더레이션 테스터에서 다시 테스트하십시오. 배포 구성이 하나의 포트만 사용하도록 되어 있는 경우 두 포트를 무분별하게 열지 마십시오.

인증서, DNS 또는 라우팅 오류가 표시되는 결과는 서버 용량 문제가 아니라 구성 또는 네트워크 연결성 문제일 가능성이 높습니다. Matrix 서버 이름에 대한 DNS 레코드 및 위임, 리버스 프록시의 TLS 인증서 체인, 그리고 프록시가 페더레이션 경로를 Synapse로 전달하는지 여부를 검토하십시오. Synapse 문서에 따르면 일부 설정에서 페더레이션 서버가 308 영구 리디렉션을 따르지 않는 경우가 있으므로 예기치 않은 리디렉션도 조사해야 합니다. 특정 검사 오류를 수정하고 다시 테스트한 후 작업자 수 또는 속도 제한을 변경하십시오.

참고: Synapse 페더레이션 설정 및 문제 해결 , Synapse 방화벽 안내 .

원격 서버 중 하나가 재시도 쿨다운 상태인지 확인하십시오.

Synapse는 페더레이션 요청이 실패한 후 원격 대상을 일시적으로 오프라인으로 표시합니다. 재시도 지연은 백오프 방식을 사용하므로, 반복적인 실패로 인해 해당 대상과 관련된 메시지 또는 연결이 지연될 수 있습니다. 이는 홈서버 전체가 느리다는 것을 의미하는 것이 아니라, 특정 원격 서버에 연결할 수 없거나 요청 처리에 실패하고 있을 가능성이 있습니다.

관리자는 Synapse의 페더레이션 관리 API를 검토하여 관련 문서를 확인할 수 있습니다 GET /_synapse/admin/v1/federation/destinations. 서버 관리자 액세스 토큰을 사용하고 이를 비공개로 유지하십시오. 문제가 발생한 룸에 연결된 홈서버의 대상 레코드와 재시도 필드를 검토하십시오. 이러한 레코드는 대상이 재시도를 수행하는 시점을 파악하는 데 도움이 되지만, 그 자체만으로는 연결 실패 원인을 입증하지 못합니다. Synapse 로그, 프록시 로그, DNS/TLS 테스트 결과, 그리고 사용자가 문제를 보고한 시간과 함께 이러한 레코드를 분석하십시오.

페더레이션 관리 API는 실험적인 기능으로 문서화되어 있으며 변경될 수 있습니다. 안정적인 공개 클라이언트 API처럼 스크립팅하여 사용하지 마십시오. Synapse는 또한 이미 쿨다운 중인 대상에 대해 백그라운드에서 다시 연결을 시도하는 재설정 연결 시간 초과 작업에 대해 설명합니다. 이 작업은 근본적인 오류를 수정하거나 이해한 후에만 진단 또는 복구 작업으로 사용하십시오. 쿨다운을 반복적으로 초기화한다고 해서 비정상적인 원격 서버가 응답하지 않는 것은 아닙니다. 재설정 엔드포인트에서 HTTP 응답을 성공적으로 받았다고 해서 백그라운드 페더레이션 시도가 완료된 것은 아닙니다.

참고: Synapse Federation 관리자 API . API의 실험적 상태 및 사용 가능한 필드는 Synapse 릴리스에 따라 변경될 수 있으므로 작업을 사용하기 전에 실행 중인 버전의 설명서를 확인하십시오.

확장하기 전에 Synapse와 해당 데이터베이스를 측정해 보세요.

Synapse의 Prometheus 메트릭 엔드포인트는 신뢰할 수 있는 내부 네트워크 또는 액세스 제어 내에서만 활성화하십시오. 공식 모니터링 가이드에는 /_synapse/metrics메트릭 리스너 또는 기존 HTTP 리스너를 통해 해당 엔드포인트를 노출하는 방법이 자세히 설명되어 있습니다. 메트릭에는 운영 세부 정보가 포함될 수 있으므로 이 엔드포인트를 공개적으로 게시하지 마십시오. 이미 메트릭을 수집하고 있다면 느린 조인 시간을 CPU, 메모리, 요청 지연 시간, 데이터베이스 트랜잭션 지속 시간, 수신 및 발신 페더레이션 활동과 비교해 보십시오.

그래프를 활용하여 전반적인 과부하와 페더레이션 관련 지연을 구분하십시오. 일반 클라이언트 요청과 데이터베이스 트랜잭션이 조인과 동시에 느려지는 경우 호스트 CPU 및 메모리 사용량, PostgreSQL 상태, 연결 제한, 디스크 지연 시간, 그리고 장시간 실행되는 쿼리를 점검하십시오. 로컬 룸 활동은 원활하게 응답하지만 원격 대상 서버 중 하나에서 오류가 발생하거나 재시도 지연이 발생하는 경우, 페더레이션 연결 가능성과 해당 원격 서버의 우선순위를 높이십시오. 하나의 대규모 룸만 영향을 받는 경우, 룸 상태와 참여 서버 수가 원인일 수 있으므로, 결론을 내리기 전에 소규모 룸과 비교해 보십시오.

Synapse의 Grafana 가이드에서는 메시지 전송 시간, CPU 및 메모리 사용량, 데이터베이스 트랜잭션 수 및 지속 시간, 페더레이션 그래프를 확인하도록 권장합니다. 트랜잭션 수가 많다고 해서 반드시 병목 현상이 발생하는 것은 아니며, 지속 시간과 시스템 부하 또한 중요합니다. 설치된 Synapse 버전의 메트릭 이름과 최신 대시보드 문서를 확인하세요. 메트릭 이름은 시간이 지남에 따라 변경될 수 있습니다.

참고 자료: Synapse Prometheus 모니터링 및 Grafana 그래프를 통한 Synapse 이해 .

룸조인 스로틀링 및 버스트 현상을 확인하세요.

Synapse는 rc_joins로컬 참가와 원격 참가에 대해 별도의 제한을 두고 있습니다. 원격 참가는 서버가 이미 참여 중인 방에 참가하는 것보다 더 많은 작업이 필요할 수 있습니다. 또한 Synapse에는 rc_joins_per_room대규모 참가 물결을 완화하기 위해 최근 참가 인원을 제한하는 기능이 있습니다. 로그나 클라이언트 응답에서 속도 제한이 나타나는 경우, 설정을 변경하기 전에 이러한 설정과 최근 참가 인원 수를 확인하십시오.

속도 향상을 위해 단순히 접속 제한을 높이는 것은 바람직하지 않습니다. 제한을 높이면 서버 및 다른 홈서버의 부하가 증가하고, 접속 폭주에 대한 보호 기능이 저하될 수 있습니다. 정상적인 마이그레이션이나 온보딩 과정에서 접속 폭주로 인해 설정된 제한에 도달하는 경우, 정확한 제한 값을 확인하고 사용 중인 Synapse 버전의 공식 설정값을 검토하십시오. 접속 작업 부하를 분산시키는 방안을 고려해 보세요. 한 번에 하나의 관련 값만 변경하고, 이전 설정을 유지한 후, 배포 환경에 따라 필요에 따라 서버를 다시 로드하거나 재시작한 후 오류율과 리소스 사용량을 모니터링하십시오.

참고: Synapse 구성:rc_joins 및 Synapse 구성:rc_joins_per_room . 기본값 및 지원되는 옵션은 릴리스에 따라 다를 수 있으므로 편집하기 전에 설치된 버전과 비교하십시오.

제어된 조인 테스트를 사용하세요

문제가 발생한 방 하나를 선택하고 방 별칭 또는 방 ID, 접속 사용자의 홈서버, 시간, 정확한 클라이언트 오류를 기록하십시오. 지원 로그에 액세스 토큰을 절대 포함하지 마십시오.
페더레이션 테스터에서 서버 이름을 확인하고 구성된 페더레이션 엔드포인트, 인증서 및 프록시 경로를 확인하십시오.
해당 타임스탬프 주변의 Synapse 로그를 검토하여 페더레이션 실패, 원격 대상 오류, 시간 초과 또는 속도 제한 응답이 있는지 확인하십시오. 역방향 프록시 및 데이터베이스 로그에서 일치하는 지연 시간을 검색하십시오.
관련 원격 대상과 연결된 재시도 상태를 확인하기 위해 페더레이션 관리자 API를 검사합니다. 문제가 발생한 회의실을 신속하게 연결되는 제어실과 비교합니다.
동일한 시간 간격 동안 Prometheus와 호스트 메트릭을 비교합니다. 요청 지연 시간, 데이터베이스 트랜잭션 지속 시간, CPU 사용량, 메모리 사용량 또는 페더레이션 활동의 급증 여부를 확인합니다.
DNS/TLS/프록시 문제 해결, 데이터베이스 병목 현상 해소 또는 확인된 속도 제한 제약 조건 조정과 같은 특정 수정 작업을 수행한 다음 동일한 테스트를 반복하고 결과를 비교하십시오.

흔히 하는 오해 중 피해야 할 것들

"연결 속도가 느리다는 것은 서버의 8448번 포트가 닫혀 있다는 뜻인가요?" 꼭 그런 것은 아닙니다. 위임 또는 리버스 프록시가 443번 포트를 사용할 수도 있습니다. 실제로 구성된 페더레이션 엔드포인트를 확인하고 테스트해 보세요.
"연합 테스트가 성공적으로 완료되면 모든 회의실 참가 속도가 빨라집니다." 이 테스트는 일반적인 연합 구성 및 연결 상태만 확인합니다. 원격 서버 상태, 회의실 상태, 로컬 부하 및 데이터베이스 성능은 여전히 참가 속도에 영향을 미칠 수 있습니다. 해당 회의실을 테스트하고 로그를 검토하십시오.
"연동 지연은 항상 제 Synapse 인스턴스에서 발생합니다." Synapse 자체 구성 문서에서는 관찰된 연동 지연이 양쪽 끝단 또는 그 사이 네트워크에서 발생할 수 있다고 경고합니다. 가능한 경우 양쪽 끝단에서 증거를 수집하고 대상을 비교해 보세요.
"작업자를 추가하거나 속도 제한을 높이는 것이 첫 번째 해결책입니다." 이러한 변경 사항은 측정 결과가 용량 부족이나 스로틀링을 나타낼 때만 유용합니다. 먼저 문제가 연결 문제인지, 원격 재시도 문제인지, 로컬 포화 상태인지, 데이터베이스 지연 시간인지, 아니면 접속 속도 제한 문제인지 파악하십시오.

수정 사항이 제대로 적용되었는지 확인하십시오.

변경 후 동일한 연결 테스트를 반복하십시오. 사용자가 성공적으로 연결되는지, 영향을 받는 대상 서버에서 더 이상 반복적으로 연결이 실패하지 않는지, 페더레이션 테스터에서 관련 검사 결과가 올바르게 보고되는지, 요청/데이터베이스 지연 시간이 정상 범위로 돌아오는지 확인하십시오. 이후 사용량이 많은 기간에 문제가 재발하는지 관찰하십시오. 한 번의 성공만으로는 원격 서버 또는 네트워크가 항상 정상적이라고 보장할 수 없습니다.

로컬 메트릭 및 페더레이션 검사는 정상으로 보이지만 특정 원격 홈서버 하나만 계속해서 오류가 발생하는 경우, 해당 서버 관리자에게 타임스탬프, 대상, 익명 처리된 오류 메시지 및 관련 요청 ID를 공유해 주세요. 여러 회의실과 대상이 영향을 받고 로컬 요청 속도가 느린 경우, 페더레이션 동작을 조정하기 전에 Synapse 및 PostgreSQL 용량을 점검하십시오. 구성 및 관리자 API 세부 정보는 변경될 수 있으므로, Synapse 버전을 문제 기록과 함께 기록해 두시기 바랍니다.