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ですね。
上記のようなテーマに変更されました。
プロフィールページを充実させてみましょう！詳細は別記事をご参照ください。
handon.club は v2.8.3 → v2.8.4 へアップデートしました🎉
新バージョンである Mastodon 2.8 のメンテンナンスリリースが行われたため，バージョンアップを行いました。
v2.8.3 からのアップデート内容は，主にバグ修正です。セキュリティアップデートを含みます 詳細はGithubのリリースページを参照ください。 Release v2.8.4 · tootsuite/mastodon · GitHub
プロフィールページを充実させてみましょう！詳細は別記事をご参照ください。
はんドンクラブでは，レスポンス・安定性の向上のため，以下のとおりメンテナンスを実施します。メンテナンス期間中は全てのサービスが利用頂けません。
なお，終了時刻の12:30は，最大の時刻を記載しております。うまくいけば12:00前には完了する見込みです。当日のメンテナンス中は，緊急連絡はTwitter （ https://twitter.com/highemerly ）で実施します。
ご迷惑をおかけいたしますが，どうぞよろしくお願いいたします。
