以下の障害が発生しており，復旧に向けて取り組んでいます。ご利用の皆様にはご不便ご迷惑をおかけしております。
Update: 本件は復旧し，現在は正常に動作しています。
復旧まで時間を要してしまったこと，検証環境にて本問題に気づけなかったこと，お詫びいたします。
状況を報告頂ける方は，以下のトゥートの通り，詳細な情報を頂けますと幸いです。
なお，今後の障害情報については，以下ページでも配信します。将来的にはこのブログも移行する予定です。
はんドンクラブ管理人のはんです。
この記事では通報機能の使い方について，お願いを記載いたします。最近意図の分からない通報が増えており，インスタンス運営上の困りごとの一つとなっています。厳密なルールにしたいわけではないので，どうしても難しい場合は柔軟に運用することとしたいと思いますが，ご協力をお願いします。
マストドンには「フォロー解除」「ミュート」「ブロック」などの機能があります。この機能は，マストドンに登録しているユーザであれば誰でも自分の意思のみで利用でき，管理者に報告する必要はありません。
| 機能の名前 | 効果 |
|---|---|
| フォロー解除 | 対象の人の発言が，あなたのHTLに流れなくなります |
| ミュート | 対象の人の発言が，あなたのHTL/LTL共に流れなくなります（フォロー状態には影響しません） |
| ブロック | 対象の人の発言が，あなたのHTL/LTL共に流れなくなります（その上で互いにフォロー解除されます） |
これらの機能は，サーバ（インスタンス）全体に影響を与えることはなく，あなた個人だけに影響する設定です。そのため，管理者への通報は「サーバ全体で統一的な処置が必要な場合」にのみ実施していただきたいです。
ここで，サーバ全体に影響する機能としては，「アカウント削除」「ログイン停止」「サイレンス*1」などがあります。これらの機能は，管理者*2だけが利用出来ます。そのため，このような機能を用いて，サーバレベルで対処が必要と考えられる場合にのみ通報をお願いします。つまり，あなたが「苦手な人や発言を見たくない」「自分の信念と合わない」というだけの場合には，通報の必要はありません。
上記の要件を満たす場合，通報した理由があるはずです。通報には，そういった「なぜこの発言やユーザを通報したのか」という理由を明記してください。
無言で通報が行われると，それが真に必要な通報なのか，私怨なのか，はたまた操作ミスなのか判断出来ません。更に，そのユーザの詳細や前後のトゥートを確認して通報理由を類推する，という作業も手間がかかりすぎますので，（申し訳無いですが）難しいです。WebUIからは複数のトゥートをまとめて通報することも可能*3ですので，問題のあるトゥートを全て選択したうえで，どういう理由でこのトゥート群を通報したのかを記載してください。
なお，通報理由に長文を書いてくれと言っている訳ではありません。例えば以下の様な記載でも十分と考えられます（これに拘るものではありません）。
今後，はんドンクラブでは，無言の通報の場合，無条件で無視する運用にいたします。申し訳ありませんが，ご協力をお願いします。
handon.club は v2.9.2 → v2.9.3 へアップデートしました🎉
Mastodon 2.9 のメンテナンスリリースがありましたので，アップデートを行いました。
v2.9.2からのアップデート内容は以下の通りです。
その他，管理者向け機能の修正やバグ修正，およびセキュリティー関連のアップデートが行われています。その他詳細は，Githubのリリースページ（2.9.3も参照ください。
Mastodon公式リポジトリでは，v3.0リリースへ向けた開発が着々と進んでいるようです。様々な目玉機能がありますが，管理人一押しは「カスタム絵文字のカテゴリ分け機能」です。webpickerにおけるカスタム絵文字が，サーバ管理人の指定したカテゴリ毎に表示可能となります。ユーザにとっては，カスタム絵文字の入力がより簡単になることが期待されます。
2019年7月11日頃より，3rd Party製のiOS向けMastodonクライアントである「Tootle」において，そのプッシュ通知用サーバの輻輳が発生していました。その結果，はんドンクラブにおいて処理遅延が発生し，TLの配送遅延など複数の問題が発生していました。この記事では，その詳細な原因と影響範囲に加え，せっかくなのでプルリクを送るまでの流れを整理しておこうと思います。
本ブログにおけるご報告が遅くなったことをお詫びいたします。
/etc/hosts でTootleプッシュ通知サーバを 0.0.0.0 と解決させることで対応Tootleのプッシュ通知サーバが原因ではんドンクラブ全体が重くなった理由を説明します。
そもそもiOSクライアントのPush通知機能は，Tootleも含め，以下の様な通信フローとなっている場合が大半です。
+----------+ +--------+ +--------+ +----------+ | Mastodon | ---> | Client | ---> | Apple | ---> | iOS | | Server | Push | Server | Push | Server | Push | Terminal | +----------+ +--------+ +--------+ +----------+
図中の「Client Server」が，Tootleが独自に立てているプッシュ通知専用のサーバとなります。今回はこのサーバのレスポンスが極端に悪くなっていました。
とはいえ，本来であれば，関係のないサーバの処理が遅くなったからといって，Mastodonサーバの処理が遅延するのはおかしいはずです。にもかかわらず今回配送遅延が発生した理由は，以下2つの要因が重なっていました。
特に【要因2】についてですが，本来Mastodonサーバ側で実装されている並列処理により，他処理に影響はないはずでした。実際はんドンクラブでは，今回のWebPush通知が処理されるDefaultキューは，15個の処理が並列処理できるよう設定されています。しかしながら，このエラーがあまりに多量に発生してしまい，15個の処理が全てTootleサーバ宛の処理で埋まってしまう事象が発生してしまいました。Defaultキューでは，LTL/HTLのへのトゥート配信を担う処理も行われるため，結果としてTL配送遅延になっていました。なお，もちろんTootleサーバが完全に断となっており，即座にエラーを返してくれればこうはならなかったのですが，【要因1】でも記載したとおり即座にエラーが返らなかったため，タイムアウト処理を待つ形となり，こういった事象となりました。
参考までに，mstdn.jpなどの他サーバへのPush（ActivityPub）については，Defaultキュートは別キューになっています。はんドンクラブでは8個の処理が（Defaultキューとは別のスレッドで）並列処理されるようになっています。そのため，はんドンに限っては，大規模サーバがダウンしたからといって，今回に類似する事象は発生しないはずです（初期設定のまま運用しているサーバでは，DefaultキューとPushキューが同じsidekiqプロセスで処理されてることが多いため，発生する可能性が高いです）。
次に，上図に，リトライ待ちの処理数と遅延時間の時間変化を示します。緑の線で示されているのがリトライ待ちの処理数（左軸）で，青の棒で示されているのが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つがありました。
最終的にMastodonの本家ソースコードへ反映させたいと言うことで，既存コードとの整合性も考慮した結果，【案3】を選びました。本当は【案1】が最も良いと思ったのですが，これはおそらくRubyライブラリのデフォルト値で，WebPush通知だけ変更することは難しいのではないかと思いました（注意： 筆者の推測であり，確認はしていません）。更に【案2】については，有効な案ではあったと思うのですが，Mastodonのソースコードを大きく変える方式であり，本家Githubへのプルリクを行ってもどうせMergeしてくれないだろうなと判断しました。
【案3】の詳細な内容についてです。WebPush処理のリトライ実装は，リトライ回数を明示的に指定されていませんでした。そのため，sidekiqのデフォルト値である26回になっていたと思われます。今回はそこを5回に変更しました。また，【案3】で本当に効果が得られるかを確認するため，検証環境での試験を行い，確かに効果があることを確認しました。そのうえで，Githubにプルリクを送りました。
早速マージされたので，結果的に初めてのMastodonへのコントリビュートとなりました😝 たいしたことのないコードですが，大きなプロジェクトにコントリビュートするのは初めてなので，ちょっぴり嬉しいですね。
違う話題です。
今回の障害は私の想定より検知が遅れました。今回の障害は，私自身がサーバを使っていて，TL表示が遅いと気づいたために調査を行ったために発覚しました。本来であれば，Defaultキューの遅延が長時間閾値を超えた場合，私のLINEにアラートが飛ぶ仕組みになっていましたが，このアラートが発報されず，結果として検知が数分〜数十分遅れてしまいました。もし私が障害発生時刻にTLを見ていなければ，もっと遅くなったのではないかと思います･･･。
原因は詳しくは説明しませんが，本件は再発防止済となりますのでご安心頂ければと思います。簡単に説明すると，他のMetricsが数時間前に警戒域になった際に正常にアラートが発報されておりましたが，ただちに影響はないと判断し無視していたところ，このアラートの発報が継続されていたため，Defaultキュー遅延が発生しても新たなアラートが発報されないようになっていました。
まず，念のため申し上げておきますが，Tootleはとても素晴らしいクライアントだと思っています。私も愛用させて頂いています。今回の問題は，Tootleのサーバ実装が悪い訳ではなく，Mastodonサーバの実装が悪いものだと理解しています。とはいえ，パラメータ設定というのはとても難しいものです。今回は実運用の中で，StatsD経由で取得しているMetricsとにらめっこしながらパラメータチューニングを行うことができました。ある程度の規模のサーバでないとできないチューニング方法だと思いますので，はんドンクラブの皆様には感謝しかありませんね。
なお，今回の障害については，はんドンクラブでは既に解消しているものと考えています。引き続き安定運用に努めたいと思います。
handon.club は v2.9.0 → v2.9.2 へアップデートしました🎉
Mastodon 2.9 のメンテナンスリリースがありましたので，アップデートを行いました。
v2.9.0からのアップデート内容は以下の通りです。
その他，管理者向け機能の修正やバグ修正が行われています。その他詳細は，Githubのリリースページ（2.9.1，2.9.2）も参照ください。
handon.club は v2.9.0rc1 → v2.9.0 へアップデートしました🎉
新バージョンである Mastodon 2.9 の正式版がリリースされましたので，アップデートを行いました。
v2.9.0rc1 からのアップデート内容は主にバグ修正のみです。 前回のメジャーバージョンである2.8からのバージョンアップ事項については，2.9.0rc1版へのアップデート記事を参照ください。 その他詳細は，Githubのリリースページも参照ください。
handon.club は v2.8.4 → v2.9.0rc1 へアップデートしました🎉
新バージョンである Mastodon 2.9 のリリース候補版（RC版）のリリースが行われました。 正式版ではありませんが，検証環境（AWS）にて試験を実施し，問題無いことが確認出来たため，アップデートを行いました。
v2.8.4 からのアップデート内容は以下の通りです。
上記は一部だけを書き出しています。更なる詳細はGithubのリリースページを参照ください。 Release v2.9.0rc1 · tootsuite/mastodon · GitHub
設定画面（歯車のマーク）で有効化できます。既にアカウントをお持ちの方は，上記図のように，「上級者向けUI」のチェックが有効になっているかと思います。ややこしいですが，**この「上級者向けUIを有効にする」のチェックを外すことで，シングルカラムUIが有効になります。TwitterのようなUIですね。
上記のようなテーマに変更されました。
プロフィールページを充実させてみましょう！詳細は別記事をご参照ください。
