Matrixサーバーのセルフホスト構築

Matrixを自前でホストする理由の多くは、企業に会話を握られたくないからです。その目的は宣伝通りに達成できます。ただし後になって驚かれるのは、インストールしたものの正体です。ホームサーバーはチャットを話す単なる専用箱ではありません。公開ネットワーク内の複製ノードであり、フェデレーションは多くの新任管理者が想像するより、はるかに配信プロトコルに近い振る舞いをします。

だからといって自前運用をやめるべきという話ではなく、むしろ意図を持って運用すべきという話です。得られるプライバシーは本物ですが、範囲は限定的です。データの管理権はあなたに移り、アカウントを他人に凍結されることはなく、法的な照会もあなたが選んだ法域に届きます。一方で得られないプライバシーも同じくらい明確で、その大半は「メッセージは暗号化されている」ことと「誰が誰と話しているか誰にも分からない」こととの間のギャップに潜んでいます。このガイドでは両方の側面を扱ったうえで、1年後もサーバーが健全であり続けるかどうかを左右する運用面の詳細に進みます。

自前のホームサーバーで実際に何が変わるのか

まず懸念事項を切り分けることから始めましょう。ホームサーバーが完全に解決するものもあれば、部分的にしか解決しないもの、まったく解決しないものもあります。以下の表は宣伝文句を誇張なく整理したもので、機材を選ぶ前に目を通しておく価値があります。

最後の2行はよく読んでください。期待が崩れるのはまさにここだからです。サービスの存在自体を誰にも特定させたくないのであれば、Matrixは適したツールではなく、オニオンサービスのほうが目的に近いでしょう。管理権とコントロール、そして法域の選択が目的であれば、ホームサーバーは優れた手段であり、このガイドの残りはそれをうまく運用する方法についてです。

フェデレーションはチャットの皮をかぶった複製プロトコルです

ここに、ほとんどの驚きを説明する仕組みがあります。ユーザーがどこか別の場所でホストされているルームに参加すると、あなたのサーバーはメールクライアントのようにオンデマンドでメッセージを取得するわけではありません。分散イベントグラフの参加者としてそのルームに加わり、ルームのイベント、メンバーシップ、そして以降の内容を検証するのに十分な状態履歴を取得して保存します。その瞬間から、あなたのマシンは複製を保持することになり、参加している他のすべてのサーバーも同様に複製を保持します。

この結果は双方向に及び、どちらも直感に反します。ユーザーが生成するデータ——表示名、アバター、参加と退出、タイムスタンプ、リアクション——は、そのルームにメンバーを持つすべてのサーバーにコピーされ、あなたが後で自分のサーバー上で削除しても、相手のデータベースには残り続けます。削除要求はピアへの「依頼」であって「命令」ではありません。独立して運営されるサーバー群のフェデレーションをまたいだ「送信取り消し」は存在せず、それができると思い込むことがこのプロトコルに対する最も一般的な誤解です。

逆方向では、大規模な公開ルームに参加することは他人の履歴を自分のディスクに取り込むことを意味します。3人しかユーザーがいない新規ホームサーバーが数十ギガバイトものデータベースを抱える理由はここにあります。3人が大量に書き込んだからではなく、5万人規模で何年分もの状態履歴を持つルームに参加したからです。ルーム選びを慎重に行うことは、プライバシーの問題であると同時に容量計画の問題でもあります。

暗号化がカバーする範囲と、平文のまま残る範囲

Matrixはメッセージ本文をMegolmで暗号化しており、プライベートルームではデフォルトで有効になっています。これは多くの人が最も気にかけている部分を守るもので、実際にきちんと機能します——サーバーは読み取れない暗号文を保存するだけであり、レンタルサーバー上で運用する場合には本当に役立つ性質です。しかしメッセージを包む「封筒」の部分は事情が異なり、そのギャップは多くの要約が認めているより大きいものです。

実務的にまとめると、暗号化が守るのは何を話したかであり、フェデレーションが公開してしまうのは誰が、いつ、どれくらいの頻度で話したかです。ほとんどのコミュニティにとってこのトレードオフは十分に許容範囲であり、この正直さこそが要点です。ソーシャルグラフそのものが機微な情報となる脅威モデルにおいては、フェデレーション型プロトコルは構造的に不向きであり、どんな設定を変えても解決しません。

Synapse・Dendrite・Conduit——実際に何を選ぶべきか

実務上重要な実装は3つあり、その選択は哲学的な問題というより、ほとんどの場合リソースの問題です。

• SynapseはPythonで書かれたリファレンス実装であり、初日からすべての機能が動く唯一の選択肢です。同時にもっともリソースを食う実装でもあります。メモリ使用量はユーザーが参加するルームの数と規模に応じて増え、負荷の高いサーバーはいずれワーカープロセスへの分割が必要になります。スペース機能、モデレーションツール、ブリッジ、管理APIをドキュメント通りに動かしたいならこれを選びます。
• DendriteはGoによる再実装です。Synapseより明らかに軽量で、小規模サーバーには十分実用的ですが、その分いくつかの機能追従が遅れます。実際の利用人数に対してSynapseが重すぎると感じる場合の妥当な中間案です。
• Conduitと、その開発が活発なフォークであるconduwuitはRustで書かれ、組み込みデータベースを持つ単一バイナリとして配布されます。家族利用や小規模コミュニティ向けサーバーであれば、当社の最小プランでも問題なく動きます。引き換えにエコシステムは小さく、一部の管理ツールやブリッジはSynapseを前提にしています。

数人規模の最初のサーバーであれば、小さなVPSでConduit系のソフトウェアを動かすのが、動作して安上がりに済む最も痛みの少ない道です。公開コミュニティ、企業利用、ブリッジを使うプロジェクトなど成長が見込まれる用途では、最初からSynapseで始めて移行の手間を避けましょう。実装間の移行は設定変更ではなく、エクスポートしてから作り直す作業になるからです。

誰もが間違えるデリゲーション設定

MatrixはユーザーIDに含まれる名前と、実際にトラフィックを処理するマシンとを分離しています。この順序を取り違えることが、自前運用における最も一般的で取り返しのつかない失敗です。server_nameは、あなたのサーバー上のすべてのユーザーIDでコロンの後に現れるドメインです。最初のイベントに署名した瞬間からフェデレーション内でのアイデンティティの一部となり、それ以降は変更できません。変更するには、そのマシン上のすべてのアカウントとルームを放棄する必要があります。

ほぼ常に望ましい構成はこうです。server_nameは裸のドメインにし、実際のソフトウェアはサブドメインで動かします。両者はデリゲーションで結び付けます。方法は2つあります。簡単なのは、裸のドメイン上の/.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人よりはるかにコストがかかります。

ここから実務的な原則が2つ導かれます。データベースは高速なストレージに置き、拡張できる余裕を持たせること。書き込みパターンは突発的ではなく、少量で継続的だからです。そしてもう一つ、今日のユーザー数でサイジングしないこと。サイジングすべきは、そのユーザーが最初の1か月で参加するルームの規模であり、驚きの原因はたいていそこにあります。当社のエントリープランでも小さなConduitやDendriteサーバーは余裕を持って動きますが、本格的なコミュニティ向けのSynapseインスタンスにはミドルクラス以上のプランが必要です——チャットホスティングのページに、それぞれの規模に対して推奨するプランを掲載しています。

他の多くのワークロードよりも、ここでは稼働率が重要になります。チャットサーバーが落ちるということは単に利用できなくなるだけでなく、ピアがしばらく再送を試みたのちに諦めてしまうイベントを静かに取りこぼすことを意味するからです。フェデレーションは数分の停止には寛容ですが、数日にわたる停止には容赦がありません。

メディアストアはスローモーションのディスク爆弾です

ユーザーが参加しているルームを通過する画像・動画・ファイルは、自分のユーザーが一度も開いていないリモートメディアも含めて、すべてディスクにキャッシュされ得ます。Synapseのデフォルト設定では、それらは無期限に保持されます。結果は予測可能でありながら今も人を油断させます。データベースは安定しているのにメディアディレクトリだけが静かに肥大化し続け、ボリュームが満杯になったとき現れる症状は「ディスクフル」ではなく「サーバーの様子がおかしい」なのです。

リモートメディアの保持ポリシーは、最初の障害の後ではなく初日に設定してください。Synapseはhomeserver.yamlに保持設定を公開しているほか、古い履歴やキャッシュ済みファイルを削除するための管理者向けエンドポイントも用意しています。synapse-compress-stateは、古くなったサーバーのstateテーブルから驚くほどの容量を回収してくれます。データベースとメディアパスの両方に目を配り、サービス停止ではなく空き容量に対してアラートを設定してください。「様子がおかしい」という症状は、空き容量が尽き始めてから何日か後にようやく現れます。

デフォルトのままにせず、判断すべき設定が一つあります。URLプレビュー機能は、ルームに投稿されたリンクをサーバー自身が取得しに行くというもので、つまり誰かがリンクを貼った瞬間、あなたのサーバーのIPアドレスから第三者へアウトバウンドのリクエストが発生します——誰が食いつくかを確認するためだけに選ばれたリンクであってもです。ホームサーバーがフロントの背後にあり、実アドレスの秘匿が重要な場合は慎重に検討してください。同じ種類の漏えいについてはオリジンアドレスを隠すガイドで詳しく扱っています。

登録・スパム、そして受け継ぐことになる評判

公開ホームサーバーで登録を開放するのは招待状のようなものですが、望ましい種類の招待ではありません。自動化された登録は数日のうちに小さなサーバーをスパムの発生源に変えてしまい、その影響は局所的では済みません。他のホームサーバーがあなたのドメインをアクセス制御リストに追加し、十分な数のリストに載ってしまうと、正当なユーザーまでもが他所のルームに参加できなくなります。焼け付いたドメインの評判を回復するのは、避けるよりはるかに困難です。これはメールの到達性の話とまったく同じ構図です。

無難なデフォルト設定はシンプルです。プライベートなサーバーではenable_registrationをオフにしたまま、アカウントは自分の手で発行しましょう。門を開けたい場合は必ず制限をかけてください。registration_requires_tokenを使えば、サードパーティのサービスなしで登録を招待制にできますし、キャプチャは雑な攻撃への対策として役立ちます。自分が管理するルームについては、MjolnirやDraupnirファミリーのモデレーションボットを使うことで、ルーム単位ではなくコミュニティ全体に対してBANリストやルームACLを適用できます。

逆方向にも知っておく価値があります。当社のアドレス帯は、ホームサーバー間で出回っているMatrixのACLブロックリストには載っていないため、新規サーバーはクリーンな評判からスタートできます。その後の評判がどうなるかは、マシンの設置場所ではなく、登録をどう運用するかによって決まります。

ブリッジと、それに伴うメタデータの代償

多くの人がMatrixを使い続ける正直な理由がブリッジです。他のネットワーク上にあるルームを一つのクライアントでまとめて扱えます。同時にブリッジは、見落とされがちな形でサーバーのセキュリティ上の立ち位置を変えてしまいます。ブリッジはリモートアカウントの認証情報を保持しており、プロトコルが接する境界では変換可能な形でメッセージを扱う必要があります。つまりブリッジのプロセスは、両側ではエンドツーエンドで暗号化されているはずのトラフィックを、平文として目にすることになります。

だからといってブリッジを避けるべきという話ではありません。むしろブリッジを動かすホストを機微なインフラとして扱うべきという話です。侵害されれば、そこが代弁しているアカウントすべてを危険にさらすマシンだからです。ブリッジ1つにつき、小規模サーバーのメモリ使用量はおおよそ倍になるため、それを見込んで容量を計画し、ホームサーバー本体と同じだけの配慮をブリッジの設置場所にも払ってください。法域選びのガイドで述べている考え方は、複数のネットワークの認証情報を一度に抱える箱にはなおさら強く当てはまります。

生かし続けるために——鍵、バックアップ、アップグレード

Matrixサーバーには、失うとデータ量とは無関係に取り返しのつかないファイルが一つあります。署名鍵——Synapseではsigning.key——は、あなたのドメインから発信されたと主張するイベントが本物であることを証明する仕組みです。これを失うと、もはや自分のサーバーとして正当性を主張できなくなります。ピアはあなたの名前を持つ見知らぬ相手による署名済みイベントを拒否するようになります。他のすべてとは別に、このファイルはマシンの外にバックアップしてください。

アップグレードはありふれた作業ですが、省略していいものではありません。ホームサーバーのリリースにはスキーマ移行が伴うことが多く、多くのバージョンを飛ばすと、5分で終わるはずのアップグレードが半日仕事になってしまいます。飛び越える前にリリースノートを読み、各ステップが小さく済むよう定期的にアップグレードし、最初の1時間のハードニングチェックリストにある基本的なホスト衛生も実施してください。チャットサーバーはデータベースを抱えた長期稼働のインターネット公開サービスであり、それにふさわしい扱いを受けるべきです。

それでも結果を左右するのはサーバーの設置場所です

ここまで述べてきたことはすべて設定の話です。設定では手が届かない部分が一つあります。それは、ユーザーに関する開示請求をどの法制度が受け取るかという問題であり、通信サーバーにとってこの問いはウェブサイト以上に重みを持ちます。ホームサーバーはメッセージ本文が暗号化されていても、メンバーシップの記録やタイムスタンプ、ソーシャルグラフのデータは平文で保持しています。つまり、それをホストする法域こそが、その記録へのアクセスを左右する法域なのです。

だからこそ、レイテンシだけでなく意図を持って設置場所を選ぶべきだという実務的な理由があります。当社は7つの拠点を運用しており、それぞれのトレードオフは法域選びのガイドと拠点ページにまとめています。同じ問題のもう半分は、プロバイダがあなたを何者として把握しているかです。身元情報が紐付いていないアカウントは、そもそも収集していない身元書類を提出できません。これが、no-KYCホスティングと自前運用の通信サービスが同じ文脈で語られ続ける単純な理由です。どちらも、すでにあなたの名前を把握している裁判所に対する防御にはならず、その境界線がどこにあるかはOpSecガイドで率直に述べています。

まとめ

このページから6つだけ持ち帰るなら、次の点です。

• 何かをインストールする前にserver_nameを決めてください——これだけは後から絶対に修正できない決定です。
• /.well-known/matrix/serverまたはSRVレコードでデリゲートし、両方の名前で有効なTLSを維持してください。
• ユーザー数ではなく、ユーザーが参加するルームの規模を基準にサイジングしてください。
• メディアの保持期間は初日に設定し、URLプレビューについてもデフォルトに任せず自分で判断してください。
• 登録は非公開かトークン制のままにしてください。焼け付いたドメインの評判を元に戻すのは高くつきます。
• signing.keyは別途バックアップし、ピアより先にデータベースをロールバックしないでください。

これらを実践すれば、サーバーは目立たない存在になります。それこそがチャットサーバーにとって望ましい姿です。その引き換えに得られるものについては、はっきりと理解しておく価値があります。得られるのは不可視性でも、誰が誰と話しているかを隠すプロトコルでもなく、内容が自分のものである会話、他人には閉鎖できないアカウント、そして自分が意図して選んだ法制度の下にあるマシンです。自分で選んだ場所にホームサーバーを置き、あとはフェデレーションが向こうからやって来るのに任せましょう。