Matrix Synapse Federationのラグとルーム参加の遅延を修正

まず遅延箇所を特定することから始めましょう

Matrixルームの開設や参加に時間がかかる場合は、まず、その遅延がリモートホームサーバー1台、ルーム1つ、またはSynapseインスタンス全体に影響しているかどうかを判断してください。この区別は重要です。フェデレーションはホームサーバー間の双方向通信であり、ルームへの参加には複数のサーバーが関与する可能性があるためです。参加の遅延は、Synapseプロセス、リモートサーバー、DNSまたはTLSルーティング、データベース、ルームのサイズや状態などが原因で発生する可能性があります。これらの問題をすべて解決する単一の「フェデレーション遅延」スイッチはありません。

検証済み： Synapseはリモート宛先の再試行情報を記録し、Prometheusメトリクスを公開し、ルーム参加のレート制限を含みます。状況によりますが、これらのうちどれが個々の参加の遅延の原因となっているかは不明です。症状だけでは、他のホームサーバーまたは中間ネットワークが遅いかどうかはわかりません。影響を受けているユーザー1人、ルーム1つ、および遅延試行のおおよその時間から始め、これらの詳細を正常に参加するコントロールルームと比較してください。

フェデレーションに到達可能かどうかを確認してください

公式のMatrix Federation TesterをホームサーバーのMatrixサーバー名とともに使用してください。一般的なDNS、委任、証明書、および到達可能性の問題を検出できます。ユーザーIDのサーバー名は、Synapseを提供するマシンまたはプロキシと異なる場合があるため、ユーザーIDドメインがSynapseを直接ホストしていると考えるのではなく、設定されているフェデレーションエンドポイントと委任を確認してください。

Synapse のフェデレーションに関するドキュメントでは、デフォルトのフェデレーション ポートは TCP 8448 と記載されていますが、委任またはリバース プロキシによるデプロイメントでは、ポート 443 で HTTPS を使用できます。該当するポートは他のホームサーバーからアクセス可能である必要があり、送信ファイアウォールでフェデレーション トラフィックを許可する必要がある場合もあります。受信および送信ファイアウォール ルールが一致していることを確認し、フェデレーション テスターから再度テストしてください。デプロイメントが一方のポートのみを使用するように構成されている場合は、両方のポートを無差別に開かないでください。

証明書、DNS、またはルーティングのエラーが表示される場合は、サーバー容量の問題ではなく、構成またはネットワークの到達可能性の問題を示しています。Matrixサーバー名のDNSレコードと委任、リバースプロキシのTLS証明書チェーン、およびプロキシがフェデレーションパスをSynapseに転送しているかどうかを確認してください。Synapseのドキュメントによると、一部の設定ではフェデレーションサーバーが308パーマネントリダイレクトに従わないことがあるため、予期しないリダイレクトについても調査してください。ワーカー数やレート制限を変更する前に、特定の失敗したチェックを修正して再テストしてください。

参考資料：Synapseフェデレーションの設定とトラブルシューティング、およびSynapseファイアウォールのガイダンス。

リモートサーバーのいずれかがリトライクールダウン中かどうかを確認します。

Synapse は、フェデレーション要求が失敗した後、リモート宛先を一時的にオフラインとしてマークします。再試行遅延はバックオフを使用するため、繰り返し失敗すると、その宛先に関連するメッセージや参加が遅延しているように見えることがあります。これは、ホームサーバー全体が遅いという証拠ではありません。到達不能なリモートサーバーや、要求が失敗している単一のリモートサーバーが原因である可能性があります。

管理者は、Synapse の Federation Admin API を検査できます。この API にはドキュメントがありますGET /_synapse/admin/v1/federation/destinations。サーバー管理者アクセス トークンを使用し、秘密にしてください。影響を受けたルームに関係するホームサーバーの宛先レコードと再試行フィールドを確認してください。これらのレコードは、宛先が再試行しているタイミングを特定するのに役立ちますが、それ自体では接続が失敗した理由を証明するものではありません。Synapse ログ、プロキシ ログ、DNS/TLS テスト、およびユーザーが問題を報告した時刻と関連付けてください。

Federation Admin API は実験的な機能であり、変更される可能性があります。安定した公開クライアント API であるかのようにスクリプトを作成することは避けてください。Synapse には、既にクールダウン中の宛先に対してバックグラウンドで再度接続を試みるリセット接続タイムアウト操作も記載されています。これは、根本的な障害を修正または理解した後にのみ、診断または復旧アクションとして扱ってください。クールダウンを繰り返しクリアしても、異常なリモート サーバーが応答するようになるわけではありません。リセット エンドポイントからの HTTP 応答が成功したとしても、バックグラウンドでのフェデレーション試行が完了したことを意味するものではありません。

参考資料：Synapse Federation Admin API。APIの実験的な状態や利用可能なフィールドはSynapseのリリースによって変更される可能性があるため、操作を実行する前に、使用しているバージョンのドキュメントを確認してください。

スケーリング前にSynapseとそのデータベースを測定する

Synapse の Prometheus メトリクス エンドポイントは、信頼できる内部ネットワーク上、またはアクセス制御の背後でのみ有効にしてください。公式の監視ガイドには/_synapse/metrics、メトリクス リスナーまたは既存の HTTP リスナーを介してエンドポイントを公開する方法が記載されています。メトリクスには運用上の詳細情報が含まれる可能性があるため、このエンドポイントを公開しないでください。既にメトリクスを収集している場合は、スロー ジョインの時間を CPU、メモリ、リクエストのレイテンシ、データベース トランザクションの所要時間、およびフェデレーションの送受信アクティビティと比較してください。

グラフを使用して、広範囲にわたる過負荷とフェデレーション固有の遅延を区別します。通常のクライアント要求とデータベーストランザクションが結合と同時に遅くなる場合は、ホストのCPUとメモリの負荷、PostgreSQLの状態、接続制限、ディスクの遅延、および長時間実行中のクエリを調べます。ローカルルームのアクティビティは応答性を維持しているものの、リモート宛先の1つで障害や再試行の遅​​延が発生している場合は、フェデレーションの到達可能性と当該リモートサーバーの優先順位を決定します。影響を受けているのが1つの大きなルームのみである場合は、ルームの状態と参加サーバーの数が影響している可能性があります。結論を出す前に、より小さなルームと比較してください。

SynapseのGrafanaガイドでは、メッセージ送信時間、CPUとメモリ使用量、データベーストランザクション数と期間、フェデレーショングラフを確認することを推奨しています。トランザクション数が多いからといって必ずしもボトルネックになるわけではなく、期間とシステム負荷も重要です。メトリック名は時間の経過とともに変更されているため、インストールされているSynapseのバージョンと最新のダッシュボードドキュメントを確認してください。

参考文献: Synapse Prometheus による Synapse の監視とGrafana グラフによる Synapse の理解。

ルーム接続時のスロットリングとバーストをチェックする

Synapseには、rc_joinsローカル参加とリモート参加でそれぞれ異なる制限があります。リモート参加は、サーバーが既に参加しているルームに参加するよりも多くの処理が必要になる場合があります。また、Synapseにはrc_joins_per_room、最近の参加をルームに制限することで、大量参加の波を軽減する機能もあります。ログやクライアントの応答からレート制限が示唆される場合は、これらの設定と最近の参加量を確認してから変更してください。

速度改善策としてレート制限を引き上げないでください。制限値を上げると、サーバーや他のホームサーバーへの負荷が増加し、接続集中による負荷増大に対する保護機能が低下する可能性があります。正当な移行やオンボーディング処理で設定済みの制限値に達した場合は、該当する制限値を特定し、Synapse のバージョンに応じた最新のドキュメント値を確認してください。接続負荷を分散させることを検討してください。関連する値を一度に 1 つずつ変更し、以前の設定を保持し、デプロイメントの要件に応じて再読み込みまたは再起動後にエラー率とリソース使用量を監視してください。

参考資料：Synapse設定：rc_joinsおよびSynapse設定：rc_joins_per_room。デフォルト設定とサポートされているオプションはリリースによって異なる場合があります。編集する前に、インストールされているバージョンと比較してください。

制御結合テストを使用する

1. 影響を受けたルームを1つ選択し、ルームのエイリアスまたはルームID、参加ユーザーのホームサーバー、時刻、および正確なクライアントエラーを記録してください。サポートログにはアクセストークンを含めないでください。
2. フェデレーションテスターでサーバー名を確認し、設定されているフェデレーションエンドポイント、証明書、およびプロキシルートを確認してください。
3. 該当のタイムスタンプ付近のSynapseログを確認し、フェデレーションの失敗、リモート宛先エラー、タイムアウト、またはレート制限応答がないか調べてください。リバースプロキシとデータベースのログを検索して、一致する遅延を探してください。
4. 関連するリモート宛先に関連付けられている再試行状態について、フェデレーション管理APIを検査します。影響を受けたルームと、迅速に参加したコントロールルームを比較します。
5. 同じ期間におけるPrometheusとホストのメトリクスを比較してください。リクエストのレイテンシ、データベースのトランザクション時間、CPU使用率、メモリ負荷、またはフェデレーション活動の急増がないか確認してください。
6. DNS/TLS/プロキシの問題の修正、データベースのボトルネックの解消、確認済みのレート制限の調整など、特定の修正を1つ行い、同じテストを繰り返して結果を比較してください。

避けるべき一般的な思い込み

• 「接続が遅いということは、サーバーのポート8448が閉じているということだ。」必ずしもそうとは限りません。委任やリバースプロキシがポート443を使用している可能性もあります。実際に設定されているフェデレーションエンドポイントを確認し、テストしてみてください。
• 「フェデレーションテストが成功すれば、すべてのルームへの参加が高速であることが証明されます。」ただし、これは一般的なフェデレーション構成と接続性のみをチェックするものです。リモートサーバーの状態、ルームの状態、ローカルの負荷、データベースのパフォーマンスは、参加に影響を与える可能性があります。影響を受けるルームをテストし、ログを確認してください。
• 「フェデレーションの遅延は常に私のSynapseインスタンスで発生している。」 Synapseの設定ドキュメントには、観測されたフェデレーションの遅延は、エンドポイントのいずれか、またはそれらの間のネットワークで発生する可能性があると注意喚起されています。可能な限り、宛先を比較し、両端から証拠を収集してください。
• 「作業員の増員やレート制限の引き上げが最初の解決策です。」これらの変更は、計測結果が容量不足やスロットリングを示している場合にのみ有効です。まず、問題が接続性、リモートリトライ、ローカルの飽和、データベースの遅延、または結合レート制限のいずれにあるのかを特定してください。

修正がうまくいったことを確認してください。

変更後、同じ参加テストを再度実行してください。ユーザーが正常に参加し、影響を受けた接続先で繰り返し失敗しなくなり、フェデレーションテスターが関連するチェックを正しく報告し、リクエスト/データベースのレイテンシが正常範囲に戻ることを確認してください。後日、接続が混雑する時間帯に再発がないか監視してください。1回の成功は、リモートサーバーまたはネットワークが常に正常であることを証明するものではありません。

ローカルのメトリクスとフェデレーションチェックが正常であるにもかかわらず、リモートホームサーバーのうち1台だけが引き続き障害を起こす場合は、タイムスタンプ、宛先、匿名化されたエラー、および関連するリクエストIDをそのサーバーの管理者と共有してください。複数のルームと宛先が影響を受け、ローカルリクエストが遅い場合は、フェデレーションの動作を調整する前に、SynapseとPostgreSQLの容量を調査してください。設定と管理APIの詳細は変更される可能性があるため、インシデントメモにSynapseのバージョンを記録しておいてください。