はんドンクラブ 運営ブログ

Mastodonインスタンス「handon.club」の運営ブログです。コラムなど,Mastodonに関する一般的な記事も投稿予定です。

「通報」機能についてのお願い

はんドンクラブ管理人のはんです。

この記事では通報機能の使い方について,お願いを記載いたします。最近意図の分からない通報が増えており,インスタンス運営上の困りごとの一つとなっています。厳密なルールにしたいわけではないので,どうしても難しい場合は柔軟に運用することとしたいと思いますが,ご協力をお願いします。

通報は管理者対処が必須の場合のみお願いします

マストドンには「フォロー解除」「ミュート」「ブロック」などの機能があります。この機能は,マストドンに登録しているユーザであれば誰でも自分の意思のみで利用でき,管理者に報告する必要はありません。

機能の名前 効果
フォロー解除 対象の人の発言が,あなたのHTLに流れなくなります
ミュート 対象の人の発言が,あなたのHTL/LTL共に流れなくなります(フォロー状態には影響しません)
ブロック 対象の人の発言が,あなたのHTL/LTL共に流れなくなります(その上で互いにフォロー解除されます)

これらの機能は,サーバ(インスタンス)全体に影響を与えることはなく,あなた個人だけに影響する設定です。そのため,管理者への通報は「サーバ全体で統一的な処置が必要な場合」にのみ実施していただきたいです。

ここで,サーバ全体に影響する機能としては,「アカウント削除」「ログイン停止」「サイレンス*1」などがあります。これらの機能は,管理者*2だけが利用出来ます。そのため,このような機能を用いて,サーバレベルで対処が必要と考えられる場合にのみ通報をお願いします。つまり,あなたが「苦手な人や発言を見たくない」「自分の信念と合わない」というだけの場合には,通報の必要はありません。

通報した理由を書いてください

上記の要件を満たす場合,通報した理由があるはずです。通報には,そういった「なぜこの発言やユーザを通報したのか」という理由を明記してください。

無言で通報が行われると,それが真に必要な通報なのか,私怨なのか,はたまた操作ミスなのか判断出来ません。更に,そのユーザの詳細や前後のトゥートを確認して通報理由を類推する,という作業も手間がかかりすぎますので,(申し訳無いですが)難しいです。WebUIからは複数のトゥートをまとめて通報することも可能*3ですので,問題のあるトゥートを全て選択したうえで,どういう理由でこのトゥート群を通報したのかを記載してください。

なお,通報理由に長文を書いてくれと言っている訳ではありません。例えば以下の様な記載でも十分と考えられます(これに拘るものではありません)。

  • 明らかに不適切なURL付きの広告トゥート→「spam広告
  • 明らかに機械的かつスパム目的と思われるフォロー→「follow spam
  • 平均的な職場や公共の場での閲覧が不適切な画像へのNSFW未付与→「NSFWなし

今後,はんドンクラブでは,無言の通報の場合,無条件で無視する運用にいたします。申し訳ありませんが,ご協力をお願いします。

*1:対象の人の発言が,全員のLTLに表示されなくなります(HTLには表示されます)。

*2:正確には管理者またはモデレータ。

*3:通報自体は3rdパーティー製クライアントからも可能ですが,複数トゥートをまとめて通報する機能は実装されているクライアントは少ない印象です。ご自身の使っているクライアントの対応状況が分からない場合は,ブラウザからWebUIをご利用ください。

【バージョンアップ】2.9.3にバージョンアップしました

handon.club は v2.9.2 → v2.9.3 へアップデートしました🎉

アップデートの概要

Mastodon 2.9 のメンテナンスリリースがありましたので,アップデートを行いました。

  • githubへリリースされてからアップデート完了まで,2日を要しました
  • アップデートにかかるサービス中断時間は 29 秒でした

前回バージョンからの変更点

v2.9.2からのアップデート内容は以下の通りです。

  • 新機能
    • カスタム絵文字登録時の形式追加(#11519
      • これまでカスタム絵文字を登録する際はかならずpng形式である必要がありましたが,今回からgifおよびwebp形式がサポートされます。はんドンクラブにおいても,カスタム絵文字登録依頼時は,png/gif/webp形式の何れかであれば,受け付けるように変更します。

その他,管理者向け機能の修正やバグ修正,およびセキュリティー関連のアップデートが行われています。その他詳細は,Githubのリリースページ(2.9.3も参照ください。

その他のお知らせ

Mastodon公式リポジトリでは,v3.0リリースへ向けた開発が着々と進んでいるようです。様々な目玉機能がありますが,管理人一押しは「カスタム絵文字のカテゴリ分け機能」です。webpickerにおけるカスタム絵文字が,サーバ管理人の指定したカテゴリ毎に表示可能となります。ユーザにとっては,カスタム絵文字の入力がより簡単になることが期待されます。

前回のアップデート

handon.hatenablog.jp

3rd Party製クライアントの通知機能障害によるMastodonサーバへの遅延発生とソースコード修正内容について

2019年7月11日頃より,3rd Party製のiOS向けMastodonクライアントである「Tootle」において,そのプッシュ通知用サーバの輻輳が発生していました。その結果,はんドンクラブにおいて処理遅延が発生し,TLの配送遅延など複数の問題が発生していました。この記事では,その詳細な原因と影響範囲に加え,せっかくなのでプルリクを送るまでの流れを整理しておこうと思います。

本ブログにおけるご報告が遅くなったことをお詫びいたします。

サマリ

問題1:TLの配送遅延

  • 日時: 2019年7月11日 21:28〜21:52頃
  • 影響範囲: HTLやLTLの表示速度低下(配送遅延は最大1分程度)
  • 原因: Tootleプッシュ通知サーバのレスポンスの大幅な低下による,重要キューの処理遅延
  • 実施した対処:Tootleプッシュ通知サーバへのアクセスを遮断
    • /etc/hosts でTootleプッシュ通知サーバを 0.0.0.0 と解決させることで対応

問題2: Tootleプッシュ通知サーバへのアクセス不可

  • 日時: 2019年7月11日 21:52〜7月14日 23:14頃
  • 影響範囲: Tootleユーザにはんドンクラブからのプッシュ通知を送らない
  • 原因: 上記問題への暫定対処
  • 実施した対処: ソースコードの修正によりプッシュ通知のリトライ回数を削減
    • リトライ回数を26回から5回に削減

今回の障害の原因について

Tootleのプッシュ通知サーバが原因ではんドンクラブ全体が重くなった理由を説明します。

〇原因1: プッシュ通知用サーバの輻輳

そもそもiOSクライアントのPush通知機能は,Tootleも含め,以下の様な通信フローとなっている場合が大半です。

+----------+      +--------+      +--------+      +----------+
| Mastodon | ---> | Client | ---> | Apple  | ---> |   iOS    |
|  Server  | Push | Server | Push | Server | Push | Terminal |
+----------+      +--------+      +--------+      +----------+

図中の「Client Server」が,Tootleが独自に立てているプッシュ通知専用のサーバとなります。今回はこのサーバのレスポンスが極端に悪くなっていました。

〇原因2: MastodonのWebPushの処理方法

とはいえ,本来であれば,関係のないサーバの処理が遅くなったからといって,Mastodonサーバの処理が遅延するのはおかしいはずです。にもかかわらず今回配送遅延が発生した理由は,以下2つの要因が重なっていました。

  • 【要因1】Tootleサーバが即座にエラーを返さなかった(例えば30秒以上かかっていた)
  • 【要因2】エラーが返るまでの間,Mastodonサーバ側が他の処理をできなくなり,結果としてTL配送処理に遅延が発生した

特に【要因2】についてですが,本来Mastodonサーバ側で実装されている並列処理により,他処理に影響はないはずでした。実際はんドンクラブでは,今回のWebPush通知が処理されるDefaultキューは,15個の処理が並列処理できるよう設定されています。しかしながら,このエラーがあまりに多量に発生してしまい,15個の処理が全てTootleサーバ宛の処理で埋まってしまう事象が発生してしまいました。Defaultキューでは,LTL/HTLのへのトゥート配信を担う処理も行われるため,結果としてTL配送遅延になっていました。なお,もちろんTootleサーバが完全に断となっており,即座にエラーを返してくれればこうはならなかったのですが,【要因1】でも記載したとおり即座にエラーが返らなかったため,タイムアウト処理を待つ形となり,こういった事象となりました。

f:id:highemerly:20190716223054p:plain
はんドンクラブにおける各キューの並列処理数

参考までに,mstdn.jpなどの他サーバへのPush(ActivityPub)については,Defaultキュートは別キューになっています。はんドンクラブでは8個の処理が(Defaultキューとは別のスレッドで)並列処理されるようになっています。そのため,はんドンに限っては,大規模サーバがダウンしたからといって,今回に類似する事象は発生しないはずです(初期設定のまま運用しているサーバでは,DefaultキューとPushキューが同じsidekiqプロセスで処理されてることが多いため,発生する可能性が高いです)。

f:id:highemerly:20190716220024p:plain
リトライ待ちの処理数と遅延時間の関係

次に,上図に,リトライ待ちの処理数と遅延時間の時間変化を示します。緑の線で示されているのがリトライ待ちの処理数(左軸)で,青の棒で示されているのがDefaultキューの処理の平均遅延時間(右軸)を表しています。Mastodonでは,様々な処理が失敗したとき,何度か決められた回数分だけリトライを行うことになっています。そのリトライ待ちの処理数が,数時間で一気に増えていることが分かるかと思います(通常運用時は100程度ですが,このときは3000超となっています)。それに伴って,青軸で示される遅延時間が増えており,最大60秒弱の遅延が発生していることが分かります(通常運用時は0.1〜1秒程度です)。先ほどの説明のとおり,このキューにはWebPush通知だけでなく,LTL/HTLへのトゥート配送処理も含まれていますので,WebPush通知もトゥート配送も青の棒で示される同じ時間だけ遅延していることとなります。このようにして配送遅延が発生しました。

今回の対処内容

〇暫定対処

実際には以下の様なエラーが大量に出力されていました(セキュリティ上の理由から,ログは一部をマスクしています)。

WARN: {"context":"Job raised exception","job":{"class":"Web::PushNotificationWorker","args":[XXXXX,XXXXX],"queue":"default","backtrace":true,"jid":"XXXXXXXXXX","created_at":XXXXXXXXX.XXX,"enqueued_at":XXXXXXXXX.XXX,"error_message":"Net::ReadTimeout with #<TCPSocket:(closed)>","error_class":"Net::ReadTimeout","failed_at":XXXXXXXXX.XXX,"retry_count":3,"error_backtrace
WARN: Net::ReadTimeout: Net::ReadTimeout with #<TCPSocket:(closed)>

原因を特定するため,argsにあるWebPushIDを調査したところ,すべてがTootleサーバ宛の通信であることが分かりました。そのため,かなりの強引な処理ですが,以下を /etc/hosts に追加することで対処しました。

0.0.0.0 tootleformastodon.appspot.com

〇本格対処

対処案は以下3つがありました。

  • 【案1】WebPush通知のタイムアウトを短くする
  • 【案2】WebPush通知が処理されるキューをDefaultキューから変更する
  • 【案3】WebPush通知のリトライ回数を減らす

最終的にMastodonの本家ソースコードへ反映させたいと言うことで,既存コードとの整合性も考慮した結果,【案3】を選びました。本当は【案1】が最も良いと思ったのですが,これはおそらくRubyライブラリのデフォルト値で,WebPush通知だけ変更することは難しいのではないかと思いました(注意: 筆者の推測であり,確認はしていません)。更に【案2】については,有効な案ではあったと思うのですが,Mastodonソースコードを大きく変える方式であり,本家Githubへのプルリクを行ってもどうせMergeしてくれないだろうなと判断しました。

【案3】の詳細な内容についてです。WebPush処理のリトライ実装は,リトライ回数を明示的に指定されていませんでした。そのため,sidekiqのデフォルト値である26回になっていたと思われます。今回はそこを5回に変更しました。また,【案3】で本当に効果が得られるかを確認するため,検証環境での試験を行い,確かに効果があることを確認しました。そのうえで,Githubにプルリクを送りました。

github.com

早速マージされたので,結果的に初めてのMastodonへのコントリビュートとなりました😝 たいしたことのないコードですが,大きなプロジェクトにコントリビュートするのは初めてなので,ちょっぴり嬉しいですね。

今回の障害の検知について

違う話題です。

今回の障害は私の想定より検知が遅れました。今回の障害は,私自身がサーバを使っていて,TL表示が遅いと気づいたために調査を行ったために発覚しました。本来であれば,Defaultキューの遅延が長時間閾値を超えた場合,私のLINEにアラートが飛ぶ仕組みになっていましたが,このアラートが発報されず,結果として検知が数分〜数十分遅れてしまいました。もし私が障害発生時刻にTLを見ていなければ,もっと遅くなったのではないかと思います・・・。

原因は詳しくは説明しませんが,本件は再発防止済となりますのでご安心頂ければと思います。簡単に説明すると,他のMetricsが数時間前に警戒域になった際に正常にアラートが発報されておりましたが,ただちに影響はないと判断し無視していたところ,このアラートの発報が継続されていたため,Defaultキュー遅延が発生しても新たなアラートが発報されないようになっていました。

おわりに

まず,念のため申し上げておきますが,Tootleはとても素晴らしいクライアントだと思っています。私も愛用させて頂いています。今回の問題は,Tootleのサーバ実装が悪い訳ではなく,Mastodonサーバの実装が悪いものだと理解しています。とはいえ,パラメータ設定というのはとても難しいものです。今回は実運用の中で,StatsD経由で取得しているMetricsとにらめっこしながらパラメータチューニングを行うことができました。ある程度の規模のサーバでないとできないチューニング方法だと思いますので,はんドンクラブの皆様には感謝しかありませんね。

なお,今回の障害については,はんドンクラブでは既に解消しているものと考えています。引き続き安定運用に努めたいと思います。

【バージョンアップ】2.9.2にバージョンアップしました

handon.club は v2.9.0 → v2.9.2 へアップデートしました🎉

アップデートの概要

Mastodon 2.9 のメンテナンスリリースがありましたので,アップデートを行いました。

  • githubへリリースされてからアップデート完了まで,4日を要しました
  • アップデートにかかるサービス中断時間は 58秒でした

前回バージョンからの変更点

v2.9.0からのアップデート内容は以下の通りです。

  • 新機能
    • オーディオアップロード(#11123
      • .mp3 などの音声ファイルが直接アップロードできるようになりました。ブラウザまたはPWAで再生できます。

その他,管理者向け機能の修正やバグ修正が行われています。その他詳細は,Githubのリリースページ(2.9.12.9.2)も参照ください。

前回のアップデート

handon.hatenablog.jp

【バージョンアップ】2.9.0にバージョンアップしました

handon.club は v2.9.0rc1 → v2.9.0 へアップデートしました🎉

アップデートの概要

新バージョンである Mastodon 2.9 の正式版がリリースされましたので,アップデートを行いました。

  • githubへリリースされてからアップデート完了まで,21時間を要しました
  • アップデートにかかるサービス中断時間は 1分52秒でした

前回バージョンからの変更点

v2.9.0rc1 からのアップデート内容は主にバグ修正のみです。 前回のメジャーバージョンである2.8からのバージョンアップ事項については,2.9.0rc1版へのアップデート記事を参照ください。 その他詳細は,Githubのリリースページも参照ください。

前回のアップデート

handon.hatenablog.jp

【バージョンアップ】2.9.0rc1にバージョンアップしました

handon.club は v2.8.4 → v2.9.0rc1 へアップデートしました🎉

アップデートの概要

新バージョンである Mastodon 2.9 のリリース候補版(RC版)のリリースが行われました。 正式版ではありませんが,検証環境(AWS)にて試験を実施し,問題無いことが確認出来たため,アップデートを行いました。

  • githubへリリースされてからアップデート完了まで,23時間を要しました
  • アップデートにかかるサービス中断時間は 4分55秒でした

前回バージョンからの変更点

v2.8.4 からのアップデート内容は以下の通りです。

  • 新機能
    • シングルカラムWebUIの新規実装 (#10807等)
      • TwitterのようなシングルカラムのUIが登場しました。設定→ユーザ設定→プロフィールを編集から,「上級者向けUIを有効にする」のチェックを外すことで使えます(詳細は下部参照)。
      • なお,シングルカラムWebUIでは,先日実装した告知機能がまだ対応していません。気が向いたら対応します。
    • ブースト解除時の確認画面 (#10287)
      • WebUIでは,ブースト時には確認画面がでていたものの,解除時には確認画面が出ていませんでした。これが両者とも出るようになりました。
    • 投票機能の選択肢フィールドや閲覧注意フィールドにおけるカスタム絵文字補完 (#10555)
    • ユーザ設定画面の整理 (#10977等)
  • 変更点
    • ライトテーマのデザイン変更 (#10992等)
      • 設定画面から選べるWebのデザインですが,そのうちライトテーマに変更がありました(詳細は下部参照)。
    • 自己紹介文の文字数制限の変更 (#10790)
      • 自己紹介文(いわゆるbio)の文字数制限が変更となり,160文字→500文字まで記載できるようになりました。
  • バグ修正
    • Webキャッシュによりプライベートな投稿が誰でも閲覧できる恐れのある脆弱性修正 (#10969)
    • プライベートな投票であってもAPI経由で誰でも利用出来てしまう恐れのある脆弱性の修正 (#10960)

上記は一部だけを書き出しています。更なる詳細はGithubのリリースページを参照ください。 Release v2.9.0rc1 · tootsuite/mastodon · GitHub

シングルカラムUI

f:id:highemerly:20190610224251p:plain
シングルカラムUI

設定画面(歯車のマーク)で有効化できます。既にアカウントをお持ちの方は,上記図のように,「上級者向けUI」のチェックが有効になっているかと思います。ややこしいですが,**この「上級者向けUIを有効にする」のチェックを外すことで,シングルカラムUIが有効になります。TwitterのようなUIですね。

f:id:highemerly:20190610224655p:plain

ライトテーマの変更

f:id:highemerly:20190610225247p:plain

上記のようなテーマに変更されました。

その他

プロフィールページを充実させてみましょう!詳細は別記事をご参照ください。

handon.hatenablog.jp

前回のアップデート

handon.hatenablog.jp

【バージョンアップ】2.8.4にバージョンアップしました

handon.club は v2.8.3 → v2.8.4 へアップデートしました🎉

アップデートの概要

新バージョンである Mastodon 2.8 のメンテンナンスリリースが行われたため,バージョンアップを行いました。

  • githubへリリースされてからアップデート完了まで,3日を要しました
  • アップデートにかかるサービス中断時間は 1分58秒でした

前回バージョンからの変更点

v2.8.3 からのアップデート内容は,主にバグ修正です。セキュリティアップデートを含みます 詳細はGithubのリリースページを参照ください。 Release v2.8.4 · tootsuite/mastodon · GitHub

その他

プロフィールページを充実させてみましょう!詳細は別記事をご参照ください。

handon.hatenablog.jp

前回のアップデート

handon.hatenablog.jp