Matrix 서버 셀프호스팅

사람들은 대화 내용을 기업이 쥐고 있지 못하게 하려고 Matrix를 셀프호스팅하며, 그 목적은 광고 그대로 정확히 달성됩니다. 나중에 놀라는 부분은 자신이 설치한 것의 실체입니다. 홈서버는 우연히 채팅을 지원하게 된 개인 전용 상자가 아닙니다. 그것은 공개 네트워크 안의 복제 노드이며, 연합(federation)은 대부분의 신규 관리자가 예상하는 것보다 훨씬 더 발행(publishing) 프로토콜처럼 동작합니다.

이는 서버 운영을 반대하는 근거가 아니라, 의도적으로 운영해야 한다는 근거입니다. 얻게 되는 프라이버시는 실재하지만 구체적입니다. 소유권(custody)이 여러분에게로 넘어오고, 계정을 다른 누군가가 정지시킬 수 없으며, 법적 요청은 기업이 아니라 여러분이 선택한 관할권으로 향합니다. 얻지 못하는 프라이버시 역시 마찬가지로 구체적이며, 그 대부분은 "메시지는 암호화되어 있다"는 사실과 "누가 누구와 대화하는지 아무도 알 수 없다"는 사실 사이의 간극에 있습니다. 이 가이드는 이 두 가지 측면을 모두 다룬 다음, 1년 뒤에도 서버가 건강하게 유지될지를 좌우하는 운영상의 세부 사항을 다룹니다.

직접 홈서버를 운영하면 실제로 무엇이 바뀌는가

먼저 위협 요소들을 구분하는 것부터 시작해야 합니다. 홈서버는 어떤 위협은 완전히 해결하고, 어떤 위협은 부분적으로만 해결하며, 어떤 위협은 전혀 해결하지 못하기 때문입니다. 아래 표는 이 제안의 솔직한 버전이며, 하드웨어를 고르기 전에 읽어볼 가치가 있습니다.

마지막 두 행을 주의 깊게 읽으십시오. 기대가 무너지는 지점이 바로 여기이기 때문입니다. 서비스가 존재한다는 사실 자체를 아무도 알아내지 못하게 하는 것이 목표라면 Matrix는 잘못된 도구이며, 어니언 서비스가 더 적합한 선택입니다. 목표가 소유권, 통제권, 관할권이라면 홈서버는 훌륭한 수단이며, 이 가이드의 나머지 부분은 그것을 잘 운영하는 방법을 다룹니다.

연합은 채팅 프로토콜의 탈을 쓴 복제 프로토콜입니다

대부분의 놀라움을 설명하는 메커니즘은 다음과 같습니다. 여러분의 사용자가 다른 곳에서 호스팅되는 방에 참여하면, 여러분의 서버는 메일 클라이언트처럼 필요할 때마다 메시지를 가져오지 않습니다. 서버는 분산 이벤트 그래프의 참여자로서 그 방에 합류한 다음, 방의 이벤트와 멤버십, 그리고 이후 내용을 검증하기에 충분한 상태 이력을 가져와 저장합니다. 그 순간부터 여러분의 머신은 복제본을 보유하게 되며, 참여하는 다른 모든 서버 역시 마찬가지입니다.

그 결과는 양방향으로 작용하며 어느 쪽도 직관적이지 않습니다. 여러분의 사용자가 생성하는 데이터 — 표시 이름, 아바타, 참여와 퇴장, 타임스탬프, 반응 — 는 그 방에 멤버를 둔 모든 서버에 복사되며, 여러분이 나중에 여러분 쪽에서 삭제하더라도 상대방의 데이터베이스에는 그대로 남아 있습니다. 삭제 요청(redaction)은 피어들에게 보내는 요청일 뿐 명령이 아닙니다. 독립적으로 운영되는 서버들의 연합 전체에 걸쳐 메시지를 되돌릴 방법은 없으며, 그것을 기대하는 것이 이 프로토콜에 대한 가장 흔한 오해입니다.

반대 방향으로는, 대형 공개 방에 참여한다는 것은 다른 사람들의 이력을 여러분의 디스크로 들여온다는 뜻입니다. 사용자가 세 명뿐인 신규 홈서버가 수십 기가바이트의 데이터베이스를 가질 수 있는 이유가 바로 이것입니다. 그 세 명이 많이 작성해서가 아니라, 그들이 회원 5만 명에 수년치 상태를 가진 방에 참여했기 때문입니다. 어떤 방에 참여할지 신중하게 고르는 것은 프라이버시 문제인 동시에 용량 문제이기도 합니다.

암호화가 가리는 것과 그대로 드러나는 것

Matrix는 Megolm으로 메시지 내용을 암호화하며, 비공개 방에서는 기본으로 켜져 있습니다. 이는 사람들이 가장 신경 쓰는 부분을 보호하며 실제로 잘 작동합니다 — 여러분의 서버는 읽을 수 없는 암호문만 저장하며, 서버가 임대한 하드웨어일 때 이는 실질적이고 유용한 특성입니다. 메시지를 둘러싼 봉투(envelope)는 이야기가 다르며, 그 간극은 대부분의 요약이 인정하는 것보다 훨씬 넓습니다.

실무적으로 정리하면 이렇습니다. 암호화는 무엇을 말했는지를 보호하고, 연합은 누가, 언제, 얼마나 자주 말했는지를 공개합니다. 대부분의 커뮤니티에게 이 정도의 절충은 충분히 받아들일 만하며, 그 정직함 자체가 핵심입니다. 소셜 그래프 그 자체가 민감한 부분인 위협 모델이라면, 연합형 프로토콜은 구조적으로 맞지 않는 형태이며 어떤 설정 값도 이를 바꾸지 못합니다.

Synapse, Dendrite, Conduit — 실제로 무엇을 운영해야 하는가

실무적으로 의미 있는 구현체는 세 가지이며, 선택은 대체로 철학의 문제가 아니라 자원의 문제입니다.

• Synapse는 Python으로 작성된 레퍼런스 서버이며, 모든 기능이 처음부터 작동하는 유일한 구현체입니다. 동시에 가장 자원을 많이 요구하기도 합니다. 메모리 사용량은 사용자들이 참여한 방의 수와 크기에 따라 늘어나며, 바쁜 서버는 결국 워커 프로세스로 분리해야 합니다. 스페이스, 모더레이션 도구, 브리지, 관리 API가 문서 그대로 정확히 동작하기를 원한다면 이를 선택하십시오.
• Dendrite는 Go로 다시 작성된 구현체입니다. Synapse보다 눈에 띄게 가볍고 소규모 서버에는 충분히 쓸 만하지만, 그 대가로 일부 기능이 뒤처져 있습니다. 실제 사용자 수에 비해 Synapse가 부담스럽게 느껴질 때 합리적인 중간 선택지입니다.
• Conduit와 그 활발히 개발되는 포크인 conduwuit은 Rust로 작성되었으며 내장 데이터베이스를 가진 단일 바이너리로 배포됩니다. 저희가 판매하는 가장 작은 플랜에서도 가족 단위나 소규모 커뮤니티 서버를 문제없이 운영할 수 있습니다. 대가는 더 작은 생태계입니다. 일부 관리 도구와 몇몇 브리지는 Synapse를 전제로 만들어져 있습니다.

사용자가 몇 명 안 되는 첫 서버라면, 소형 VPS에서 Conduit 계열 소프트웨어를 운영하는 것이 가장 무난하게 작동하면서 비용도 낮게 유지하는 길입니다. 성장할 것으로 예상되는 무엇이든 — 공개 커뮤니티, 회사, 브리지가 딸린 프로젝트라면 — 처음부터 Synapse로 시작해 이전 작업을 건너뛰십시오. 나중에 구현체를 옮기는 것은 설정 변경이 아니라 내보내기와 재구축 작업이기 때문입니다.

모두가 실수하는 위임(delegation) 설정

Matrix는 사용자 ID 안의 이름과 실제로 트래픽을 처리하는 머신을 분리하며, 이 순서를 거꾸로 이해하는 것이 셀프호스팅에서 가장 흔하면서도 되돌릴 수 없는 실수입니다. server_name은 여러분의 서버에 있는 모든 사용자 ID에서 콜론 뒤에 나타나는 도메인입니다. 이는 첫 이벤트가 서명되는 순간 연합 안에서 여러분의 정체성 일부가 되며, 머신 위의 모든 계정과 방을 포기하지 않는 한 이후에는 변경할 수 없습니다.

거의 항상 원하게 되는 구성은 이렇습니다. server_name은 순수 도메인으로 두고, 소프트웨어 자체는 서브도메인에서 실행합니다. 이 둘은 위임을 통해 연결하며, 방법은 두 가지 중 하나입니다. 간단한 쪽은 순수 도메인의 /.well-known/matrix/server에 실제 호스트와 포트를 명시한 정적 JSON 파일을 두는 것입니다. 다른 방법은 같은 곳을 가리키는 _matrix._tcp DNS 레코드입니다. 앱이 주소 하나만으로 홈서버를 찾을 수 있도록 /.well-known/matrix/client 클라이언트 측 파일도 함께 제공하십시오.

정직하게 사이징하기

Matrix는 평상시 운영에서 CPU에 크게 좌우되지 않으며, 오히려 메모리와 데이터베이스 동작에 좌우됩니다. Synapse에 대해 공개된 수치는 유용한 하한선입니다. 시작 단계에서는 약 2GB, 활성 사용자 10~50명이 되면 약 4GB, 100명을 넘으면 8GB 이상입니다. Conduit 계열 서버는 이보다 훨씬 낮은 수치로 충분합니다. 이 수치들이 놓치는 부분은, 소비량이 등록된 인원 수가 아니라 참여한 방에 비례한다는 점입니다 — 대형 공개방 100개에 있는 사용자 5명이, 소규모 비공개방 몇 개에 있는 사용자 50명보다 훨씬 더 많은 자원을 소모합니다.

여기서 두 가지 실용적인 규칙이 나옵니다. 데이터베이스는 빠른 스토리지에 두고 성장할 여유를 주십시오. 쓰기 패턴이 몰아치기보다는 작고 꾸준하기 때문입니다. 그리고 오늘의 사용자 수에 맞춰 사이징하지 마십시오. 그 사용자들이 첫 달 안에 참여하게 될 방을 기준으로 사이징하십시오. 놀라움은 대개 그 지점에서 발생합니다. 저희의 입문 플랜은 소규모 Conduit 또는 Dendrite 서버를 무리 없이 감당하며, 실제 커뮤니티를 위한 Synapse 인스턴스는 중급 플랜 이상이 적합합니다 — 채팅 호스팅 페이지에서 각 형태에 저희가 권장하는 등급을 확인할 수 있습니다.

이곳에서는 가동 시간이 대부분의 워크로드보다 더 중요합니다. 다운된 채팅 서버는 단순히 사용할 수 없는 상태가 아니라, 피어들이 한동안 재시도하다가 결국 포기하게 되는 이벤트들을 조용히 놓치고 있는 상태이기 때문입니다. 연합은 몇 분의 장애는 너그럽게 넘어가지만 며칠에 걸친 장애에는 가혹합니다.

미디어 저장소는 서서히 터지는 디스크 폭탄입니다

사용자들이 속한 방을 오가는 모든 이미지, 동영상, 파일은 여러분의 디스크에 캐시로 남을 수 있으며, 여기에는 여러분의 사용자가 한 번도 열어보지 않은 원격 미디어까지 포함됩니다. Synapse의 기본 보관 정책은 이를 무기한 유지합니다. 결과는 충분히 예측 가능한데도 여전히 사람들을 당황하게 만듭니다. 데이터베이스는 안정적인데 미디어 디렉터리만 조용히 계속 자라나다가 결국 볼륨이 가득 차며, 그 시점의 증상은 "디스크 가득 참"이 아니라 "서버가 이상하게 동작함"으로 나타납니다.

원격 미디어에 대한 보관 정책은 첫 장애를 겪은 뒤가 아니라 처음부터 설정하십시오. Synapse는 homeserver.yaml에 보관 설정을 노출하며, 오래된 이력과 캐시된 파일을 정리하는 관리자용 엔드포인트도 제공합니다. synapse-compress-state는 오래된 서버의 상태 테이블에서 놀라울 만큼 많은 공간을 회수해 줍니다. 데이터베이스와 미디어 경로 양쪽을 계속 지켜보고, 서비스 다운이 아니라 여유 공간을 기준으로 경보를 설정하십시오 — 두 번째 증상은 첫 번째 증상보다 며칠 늦게 나타납니다.

기본값이 아니라 직접 판단해야 할 설정이 하나 있습니다. URL 미리보기는 방에 게시된 링크를 서버가 대신 가져오게 만드는데, 이는 곧 누군가 링크를 붙여넣는 순간 여러분 서버의 IP 주소가 제3자에게 아웃바운드 요청을 보낸다는 것을 의미합니다 — 누가 물었는지 확인하려고 일부러 고른 링크라도 예외는 아닙니다. 여러분의 홈서버가 프론트 뒤에 있고 실제 주소가 중요한 경우라면 이를 신중히 저울질하십시오. 오리진 주소 숨기기 가이드에서 같은 종류의 누출을 더 자세히 다루고 있습니다.

가입, 스팸, 그리고 물려받게 되는 평판

공개 홈서버에서 가입을 열어두는 것은 초대장을 보내는 것과 같지만, 여러분이 원하는 종류의 초대는 아닙니다. 자동화된 가입은 며칠 만에 소규모 서버를 스팸 발신지로 만들며, 그 여파는 지역에 국한되지 않습니다. 다른 홈서버들이 여러분의 도메인을 접근 제어 목록에 추가하고, 충분히 많은 목록에 이름이 오르면 정상적인 사용자들조차 다른 곳의 방에 참여할 수 없게 됩니다. 한번 불탄 도메인 평판을 회복하는 것은 애초에 피하는 것보다 훨씬 어렵습니다. 메일 전달률과 정확히 같은 원리입니다.

방어 가능한 기본값은 단순합니다. 비공개 서버라면 enable_registration을 꺼두고 계정을 직접 발급하십시오. 문을 열어두고 싶다면 관문을 두십시오. registration_requires_token은 제3자 서비스 없이도 가입을 초대 시스템으로 바꿔주며, 캡차는 조잡한 수준의 공격을 막는 데 도움이 됩니다. 직접 관리하는 방이라면, Mjolnir와 Draupnir 계열의 모더레이션 봇을 이용해 커뮤니티 전체에 걸쳐 차단 목록과 방 ACL을 방 하나씩이 아니라 한 번에 적용할 수 있습니다.

반대 방향으로 알아둘 만한 사실도 있습니다. 저희의 주소 대역은 홈서버들 사이에 유통되는 Matrix ACL 차단 목록에 올라 있지 않으므로, 새 서버는 깨끗한 평판에서 출발합니다. 이후 그 평판에 어떤 일이 일어날지는 머신이 어디에 있는지가 아니라 가입을 어떻게 운영하는지에 달려 있습니다.

브리지와 그에 딸려오는 메타데이터 청구서

브리지는 많은 사람이 Matrix를 계속 쓰는 솔직한 이유입니다. 다른 네트워크에 있는 방들을 클라이언트 하나로 다룰 수 있게 해주기 때문입니다. 동시에 브리지는 놓치고 지나가기 쉬운 방식으로 여러분 서버의 보안 위치를 바꿔놓습니다. 브리지는 원격 계정의 자격 증명을 보유하며, 두 프로토콜이 맞닿는 경계에서는 필연적으로 변환 가능한 형태로, 즉 읽을 수 있는 형태로 메시지를 다룹니다 — 이는 브리지 프로세스가 양쪽 모두에서 종단간 암호화된 트래픽의 평문을 본다는 뜻입니다.

그렇다고 브리지를 피해야 한다는 뜻은 아닙니다. 브리지가 실행되는 호스트를 민감한 인프라로 취급해야 한다는 뜻입니다. 그 머신이 침해당하면 그것이 대변하는 계정들이 그대로 노출되기 때문입니다. 브리지 하나는 소규모 서버의 메모리 사용량을 대략 두 배로 늘리므로 그에 맞춰 용량을 계획하고, 홈서버 자체를 고를 때와 같은 만큼의 고민을 브리지가 실행될 위치에도 쏟으십시오 — 저희 관할권 가이드의 논리는 여러 네트워크의 자격 증명을 한꺼번에 쥔 머신에는 더욱 강하게 적용됩니다.

서버를 살아있게 유지하기: 키, 백업, 업그레이드

Matrix 서버에는 잃어버리면 데이터 용량과는 무관하게 복구가 불가능한 파일이 하나 있습니다. 서명 키 — Synapse에서는 signing.key — 는 여러분의 도메인에서 왔다고 주장하는 이벤트가 실제로 그렇다는 것을 서버가 증명하는 수단입니다. 이를 잃어버리면 더 이상 신뢰성 있게 자신의 서버라고 주장할 수 없습니다. 피어들은 여러분의 이름을 쥔 낯선 이가 서명한 이벤트를 거부할 것입니다. 이 키는 다른 모든 것과 별도로 백업하고, 그 사본은 머신 밖에 보관하십시오.

업그레이드는 평범한 작업이지만 선택 사항은 아닙니다. 홈서버 릴리스에는 스키마 마이그레이션이 포함되며, 여러 버전을 건너뛰면 5분짜리 업그레이드가 한나절짜리 작업이 되어 버립니다. 넘어가기 전에 릴리스 노트를 읽고, 각 단계가 작게 유지되도록 충분히 자주 업그레이드하며, 첫 시간 하드닝 체크리스트에 나온 기본적인 호스트 위생 관리를 수행하십시오 — 채팅 서버는 데이터베이스가 딸린, 인터넷에 오래 노출되는 서비스이며, 그에 걸맞은 대우를 받아야 합니다.

서버가 위치한 곳이 여전히 결과를 좌우합니다

지금까지 다룬 것은 모두 설정입니다. 설정이 손댈 수 없는 부분은 여러분의 사용자에 대한 요청을 어떤 법체계가 받게 되는가이며, 통신 서버에서는 이 질문이 일반 웹사이트보다 훨씬 무겁게 작용합니다. 홈서버는 메시지 본문이 암호화되어 있더라도 멤버십 기록, 타임스탬프, 소셜 그래프 데이터를 평문으로 보유하므로, 그것을 호스팅하는 관할권이 곧 그 기록에 대한 접근을 통제하는 관할권이 됩니다.

이것이 지연 시간만으로가 아니라 의도를 갖고 위치를 선택해야 하는 실질적인 이유입니다. 저희는 7개 관할권에서 서비스를 운영하고 있으며, 각각의 장단점은 관할권 가이드와 지역 페이지에 정리되어 있습니다. 같은 질문의 나머지 절반은 제공사가 여러분을 누구로 알고 있는가입니다. 신원이 연결되지 않은 계정은 애초에 수집한 적 없는 신원 서류를 제출할 수 없으며, 이것이 바로 노 KYC 호스팅과 셀프호스팅 통신이 같은 대화 속에서 계속 함께 언급되는 단순한 이유입니다. 둘 중 어느 쪽도 이미 여러분의 이름을 확보한 법원 앞에서는 방어 수단이 되지 못하며, 저희 OpSec 가이드는 그 경계가 어디에 있는지 가감 없이 다루고 있습니다.

요약

이 페이지에서 여섯 가지만 기억한다면 다음을 기억하십시오.

• 무엇이든 설치하기 전에 server_name부터 정하십시오 — 절대 나중에 고칠 수 없는 유일한 결정입니다.
• /.well-known/matrix/server나 SRV 레코드로 위임하고, 두 이름 모두에 유효한 TLS를 유지하십시오.
• 보유한 사용자 수가 아니라 그들이 참여할 방을 기준으로 사이징하십시오.
• 미디어 보관 정책은 처음부터 설정하고, URL 미리보기는 기본값을 그대로 물려받지 말고 직접 판단하십시오.
• 가입은 닫아두거나 토큰으로 제한하십시오. 한번 불탄 도메인 평판은 되돌리는 데 큰 비용이 듭니다.
• signing.key는 별도로 백업하고, 피어들보다 뒤처진 상태로 데이터베이스를 되돌리는 일은 절대 하지 마십시오.

이것들을 지키면 서버는 특별할 것 없는 상태가 될 것이며, 그것이 바로 채팅 서버가 지향해야 할 모습입니다. 그 대가로 얻는 것이 무엇인지는 냉정하게 볼 가치가 있습니다. 보이지 않게 되는 것도, 누가 누구와 대화하는지를 숨겨주는 프로토콜도 아니라, 내용이 온전히 여러분의 것인 대화, 다른 누구도 닫을 수 없는 계정, 그리고 여러분이 의도적으로 선택한 법체계 아래 놓인 머신입니다. 여러분이 고른 곳에 홈서버를 두고, 연합이 그곳으로 찾아오게 하십시오.