はんドンクラブを支える技術(継続的デリバリー)
こんばんは。はんドンクラブのはんです。
はんドンクラブでは、昨年インフラを刷新しました。その目的の一つは、CI&CDを実現できる環境づくりです。
CI&CDとは、継続的インテーグレーション・継続的デリバリー の略で、ざっくりと言うと「実装変更(コーディング)・テスト・本番適用までを自動化すること」です。一般には、CI&CDを実現することで、サービスデリバリーのアジリティ向上、ならびにサービス品質の維持・向上ができると考えられています。特に後者については、個人運営のサーバーであることを考慮しても、大幅に作業負担を軽減できますので、他の作業に時間を使えるようになり、結果的にサービス品質の維持・向上に向けた作業ができる、という訳です。
ただ、最初に申し上げておくと、残念ながらはんドンクラブは全ての作業をCI&CD化した訳ではありません。これは、意図があって自動化したくない作業、言い換えると「私が目で実行結果を確認し、その後に心を込めてエンターキーを押したい作業」があるためです。ただし、自動化したかった箇所について、特にデリバリー作業に関連する作業については、私の手作業はほとんどなくなりました。
そこで、今日は、特にはんドンクラブのデリバリー作業の自動化に関連した、いくつかの技術を紹介したいと思います。正直、まったく難しいことはしていません。そのため、あまり読み応えはないと思います。
全体のビルド・デリバリー構成
手で作業する箇所は4つ(図中、青矢印で記載)のみです。本当は全部自動化できたのですが、Mastodonプロセスのログ確認やブラウザによるアクセス確認を人力で行いGoサインを出したかったので、あえて何回か止めています。
さて、キーポイントとなる技術を2つ紹介します。
Docker
Mastodonは本来、Dockerコンテナのイメージが公開されています。かつ、githubには docker-compose.yml
も掲載されています。そのため、少々の設定をして docker compose up -d
と打つだけで、実はサーバーの運用が可能な状態になります。
しかし、はんドンクラブでは、ソースコードをそれなりに修正しています。かつ、様々なパフォーマンスチューニングを行いたかったため、dockerはあえて使っていませんでした*1。以上の理由と運用面を考慮し、ホストサーバー上で直接プロセスを動かしていました。
再Docker化
今回の移行で、上の図のとおり再docker化を行いました。これは、はんドンクラブの独自DockerイメージをビルドしGithubにプッシュすることで、自動リリースを容易にするためです。
このDocker化により、大幅な変更が無いMastodonへのアップデート(バグFix、セキュリティパッチ等)への追従であれば、ソースコードのマージ・Dockerイメージのビルド・ステージング環境へのデプロイまで、完全自動化できるようになりました。
# ソースコードのマージ $ git checkout -b ${UPSTREAM_BRANCH} ${TAG} $ git checkout -b ${HANDON_CI_BRANCH} ${HANDON_PROD_BRANCH} $ git rebase ${UPSTREAM_BRANCH} # ビルド $ docker image build -t ghcr.io/highemerly/mastodon/handon:handon-nightly . $ docker push ghcr.io/highemerly/mastodon/handon:handon-nightly # デプロイ(ステージング環境) $ docker compose pull $ docker compose restart
ところで、自動化したといっても、やってることは実は上記だけです(実際のコードにはエラー処理がありますが、わかりやすさのためにこの記事では記載を省略しています)。
なお、はんドンクラブのDockerイメージは、handon-nightly タグ と handon-latest タグの2つを運用しています。 docker-compose.yml
を書き分けることで、ステージング環境では handon-nightly を、本番環境では handon-latest を使っています。そして、handon-nightly には 検証なしで 気軽にプッシュ しますが、handon-latest へのプッシュは各種目視確認を得て実施する運用ルールとしています。
# docker-compose.yml のイメージ (ステージング環境) services: web: image: ghcr.io/highemerly/mastodon/handon:handon-nightly restart: always env_file: .env.production command: bash -c "rm -f /mastodon/tmp/pids/server.pid; bundle exec rails s -p 3000" ports: - '127.0.0.1:3000:3000' volumes: - ./public/system:/mastodon/public/system depends_on: - pgbouncer
余談です。当初はk8s化を考えていました。しかし、事前検証の結果、コスト面でのデメリットが大きく、今回は見送ることとしました。サーバーの規模が倍以上になる場合は、再度k8s化を検討したいと思っています。
クラウドロードバランサー
構成の差分
2023年のインフラ移行前後で、ロードバランシングの実現方式が変わりました。先の構成図のとおり、移行前のフロントエンドは3インスタンス、移行後のフロントエンドは2インスタンスで運用されています*2が、エンドユーザーからのリクエストを分配する方法は、以下のようになっていました。
移行前は、(一応)DNSラウンドロビン です。注意点として、はんドンクラブの通常のHTTPS通信は全てCloudFlare経由であり、エンドユーザーからのDNSクエリを受けても実際のサーバーのIPアドレスが応答されるわけではなく、CloudFlareのエッジサーバのIPアドレスが応答されます。よって、CloudFlareがオリジンサーバへリクエストを送る際のロードバランシングアルゴリズム(たぶん、ラウンドロビン)に従って割り振られているだけで、正確にはDNSラウンドロビンとは少し性質が異なります。すなわち、普通のDNSラウンドロビンのように、エンドユーザーの選出アルゴリズムに依存する訳ではありません。
一方、移行後は、Vultrのマネージドロードバランサーを使います。Least Connectionsで分散を行います。マネージドロードバランサーの採用によって、継続的デリバリーとは直接関係ありませんが、セッションのPersistenceの担保(注: はんドンクラブではMastodonが発行するCookieを使っています)・ハートビートによる各インスタンスの死活監視・TLS処理のオフロードなどを実現しました。でも、それだけでなく、継続的デリバリーの観点でも非常に重要な構成変更です。
このロードバランサーに$10/Monthの追加経費がかかっていますが、やむを得ません。
メンテナンス時のリクエスト迂回方法
今回の構成変更が継続的デリバリーに有益である理由を説明するため、まずはメンテナンス方法を説明したいと思います。Mastodonのアップデートなどを行う場合、通常はmastodon-webプロセスの再起動が必要となります。しかし当然、再起動時、数十秒〜数分の通信断が発生してしまいます。
従来のはんドンクラブでは、このサービス中断を防ぐための工夫をしています。でも、CloudFlareでのロードバランシングアルゴリズムがよく分からないため、実際にロードバランシングを行っているCloudFlareでの解決は期待できませんでした*3。そのため、ホスト側のnginxでバックエンドの設定を変え、VPCを経由して生きている他サーバーのプロセスへ飛ばす 処理を行っていました。
ただ、この方法では、nginxの設定変更を行いreload*4しても、おそらくnginxの仕様で現行のTCPセッションのバックエンド側の接続先は変更されないようです。つまり、いつまで待っても旧セッションが使われ続けてしまうことがあります。加えて、そもそもこの方法は、ホスト自身のメンテナンス(例:カーネルアップデートに伴う再起動など)に対応できませんよね。
以上から、オペレーションが複雑で、かつ完全ではない状態でした。つまり、自動化に向いた構成ではありませんでした。
移行後はより単純です。マネージドロードバランサーの設定を変えるだけです。これでサービスを止めることなく、プロセスまたはホストのメンテナンスが可能です。
実際には、websocketの通信は瞬断してしまう場合があることが分かっています。しかし、少なくともMastodonのWebクライアントは、すぐに再接続が行われることを確認しています。よって、ユーザー体験への影響は一切なく、仮にホストの再起動が必要な状況でもサービスを一切止めることなくデプロイができるのです。
Vultr API
さて、実際にメンテナンスへ移行する場合に、マネージドロードバランサの設定を変更する必要があります。
マネージドロードバランサはVultrが提供しているRest APIがあり、設定の差分のみをPATCHで送信することができます。そのため、例えばHost1とHost2で運用している際に、Host1のアップデート作業を行うため切り離したい場合には、以下のコマンドを発行すればOKです。
$ curl -i "https://api.vultr.com/v2/load-balancers/${LB_ID}" \ -X PATCH \ -H "Authorization: Bearer ${VULTR_API_KEY}" \ -H "Content-Type: application/json" \ --data '{ "instances": [ "'${HOST2_ID}'" ] }' HTTP/2 204 server: nginx date: ・・・(Snipped)
これで30秒も待てば、全てのセッションが新しい設定(この例だと、 $HOST2_ID
のインスタンス)に向かいます。
なお、実際に切り戻しが行われたかどうかは、インスタンスのnginxのアクセスログを監視し、本当にアクセスがなくなったことを確認しています。これは、Vultr側の反映ラグを考慮したものです。Rest APIでマネージドロードバランサー側の設定を取得することもできますが、その結果から反映が終わったように見えていても、実際にはマネージドロードバランサーの設定が終わっていないことがあるようです。
まとめ
これまでのリリース作業は、軽微なリリースであっても、1時間以上の作業を要していました。しかし、この仕組みを構築したことで、実作業は10分程度に抑えることができています。また、軽微なオペレーションミス(例:特定インスタンスのみアップデート作業を忘れてしまう)も防げるようになったと考えています。
運用に関する課題は他にもたくさんあります。継続的な改善に取り組んでいきたいと思います。引き続き、はんドンクラブをよろしくお願いいたします。
2023年末のご挨拶
こんにちは。はんドンクラブのはんです。
早いものでもう年末ですね。そして、はんドンクラブも早いもので、もう7周年が見えてきました。私はプライベートの時間が皆無の状態が続いておりあまりアクティブではありませんが、皆様にはたくさんサーバーを使って頂いてありがとうございました。
今年を簡単に振り返って、年末のご挨拶とさせて頂ければと思います。来年も引き続きよろしくお願いします!
主なイベント
- 2023/1中: 画像サーバーの障害と構成変更
- クラウド事業者側の問題で画像のアップロードができない問題がありました。そもそも、以前からアップロードが遅いという問題があったので、思い切って構成変更して、パフォーマンスもアベイラビティも向上しました。
- 2023/2/6: 利用規約の更新
- 2023/2/11: 4.1.xへのメジャーアップデート
- 2023/5/29〜2023/6/2 : 外部との接続が不安定な障害が発生
- 2023/7/6: セキュリティ脆弱性対応
- 2023/8/29: サーバー移転
- サーバーをさくらVPSからVultrに移転し、構成を大幅に変更しました。
- 詳しいことはここには書きませんが、構成変更により以下の3点を達成しました。
- コストの最適化
- アップデート作業の大幅な短縮
- EoL(End-of-Life: 古いソフトウェアの保守期限が切れ、今後セキュリティアップデートが行われなくなること)の対応
- 2023/8/29 - 2023/9/5: ストリーミングが不安定な問題が発生
- 事前検証不足によりご迷惑をおかけしました。
- 詳しくは障害報告をご確認ください。handon.hatenablog.jp
- 2023/9/23: セキュリティ脆弱性対応
- 2023/11/21: 4.2.xへのメジャーアップデート
- 全文検索が大幅に改善されました。
- 今回のメジャーアップデートははんドンクラブの独自機能とのバッティングが多く、コードの修正と検証に大幅な時間を費やしてしまいました。結果として、いくつかの独自機能は削除することとしました。
主な統計情報
トゥート数ランキング
毎年恒例のトゥート数ランキングです。ご自身のアカウントは、投稿数とアカウント作成日から推察してくださいね。
順位 | 投稿数 | アカウント作成日 |
---|---|---|
1 | 201855 | 2017-04-16 03:14:45.210683 |
2 | 180558 | 2018-09-26 14:00:24.677902 |
3 | 170488 | 2017-04-19 23:46:20.721773 |
4 | 144721 | 2018-08-17 04:55:36.888916 |
5 | 143760 | 2018-08-15 15:46:57.420607 |
6 | 130197 | 2018-09-26 13:34:53.286009 |
7 | 130018 | 2018-09-06 12:13:56.291501 |
8 | 123509 | 2017-04-14 15:25:19.467587 |
9 | 112150 | 2017-04-15 02:53:53.437558 |
10 | 109947 | 2017-12-10 05:49:59.90627 |
11 | 98689 | 2018-08-21 03:56:48.835622 |
12 | 85726 | 2017-04-15 02:55:00.283981 |
13 | 82749 | 2017-04-15 01:58:28.244079 |
14 | 72268 | 2018-09-09 08:15:49.611543 |
15 | 71733 | 2018-08-27 18:58:03.712292 |
16 | 67688 | 2018-11-19 04:43:11.381105 |
17 | 66028 | 2019-08-16 09:27:18.956742 |
18 | 65248 | 2018-03-21 04:27:47.006326 |
19 | 65226 | 2018-11-19 04:44:53.895617 |
20 | 64825 | 2018-08-16 13:33:57.829532 |
21 | 61868 | 2017-04-15 02:53:10.105472 |
22 | 58590 | 2018-08-16 15:52:19.943946 |
23 | 57801 | 2018-08-23 10:41:04.900378 |
24 | 55970 | 2020-01-04 15:34:32.12934 |
25 | 54454 | 2017-10-07 06:55:04.372879 |
26 | 54139 | 2017-04-15 02:01:39.684488 |
27 | 53552 | 2018-08-17 12:06:59.137676 |
28 | 52384 | 2018-08-18 23:14:00.993394 |
29 | 51289 | 2018-12-13 10:31:57.524099 |
30 | 45939 | 2018-09-25 09:56:10.853888 |
31 | 44749 | 2018-10-19 10:33:06.773122 |
32 | 38632 | 2018-09-05 14:53:38.892203 |
33 | 35690 | 2018-09-19 08:50:05.531581 |
34 | 35684 | 2019-05-28 10:45:38.544188 |
35 | 35603 | 2017-04-25 00:18:49.618914 |
36 | 33925 | 2020-01-04 15:38:40.128898 |
37 | 33107 | 2017-04-15 11:42:27.962394 |
38 | 32501 | 2017-04-25 00:39:02.780603 |
39 | 32030 | 2018-08-16 05:59:16.471888 |
40 | 30343 | 2018-04-08 13:43:48.229188 |
41 | 30125 | 2018-08-17 17:18:24.625016 |
42 | 28576 | 2018-08-15 15:39:00.204377 |
43 | 27750 | 2018-08-18 01:04:57.818141 |
44 | 27585 | 2018-08-16 06:30:05.115409 |
45 | 26833 | 2018-11-02 06:18:31.772157 |
46 | 26293 | 2018-09-23 09:01:46.863769 |
47 | 26198 | 2017-04-22 10:16:53.612031 |
48 | 24601 | 2019-03-04 12:21:16.389625 |
49 | 23972 | 2018-04-04 14:43:53.887628 |
50 | 23818 | 2018-09-07 20:46:42.100261 |
ちなみに、2019年以降にアカウントを作成した方に限ってランキングを作ってみました。以下のようになりました。
順位 | 投稿数 | アカウント作成日 |
---|---|---|
1 | 66028 | 2019-08-16 09:27:18.956742 |
2 | 55970 | 2020-01-04 15:34:32.12934 |
3 | 35684 | 2019-05-28 10:45:38.544188 |
4 | 33925 | 2020-01-04 15:38:40.128898 |
5 | 24601 | 2019-03-04 12:21:16.389625 |
6 | 23793 | 2019-12-14 16:12:36.803644 |
7 | 18957 | 2019-01-20 15:15:23.96502 |
8 | 10076 | 2019-09-02 12:25:39.220573 |
9 | 8719 | 2022-07-20 23:09:32.295987 |
10 | 8652 | 2019-01-18 04:15:22.984582 |
11 | 8545 | 2021-12-12 00:40:17.976319 |
12 | 7687 | 2020-05-25 11:16:53.155869 |
13 | 7551 | 2020-05-25 08:10:05.992741 |
14 | 4812 | 2023-02-14 03:48:49.693808 |
15 | 3516 | 2020-02-29 11:07:49.071021 |
16 | 3125 | 2023-08-19 13:13:11.328339 |
17 | 2606 | 2019-06-04 14:20:41.999689 |
18 | 2449 | 2022-05-18 14:50:13.033206 |
19 | 2430 | 2019-04-05 04:23:31.871571 |
20 | 2412 | 2023-02-02 23:59:45.34248 |
フォロワー数ランキング
順位 | フォロワー | (参考)投稿数 |
---|---|---|
1 | 817 | 123509 |
2 | 441 | 201855 |
3 | 432 | 130018 |
4 | 415 | 391 |
5 | 397 | 61868 |
6 | 326 | 20770 |
7 | 324 | 30343 |
8 | 322 | 109947 |
9 | 312 | 54139 |
10 | 269 | 671 |
11 | 250 | 112151 |
12 | 229 | 32030 |
13 | 209 | 85727 |
14 | 208 | 38632 |
15 | 207 | 4762 |
16 | 203 | 144723 |
17 | 198 | 72268 |
18 | 198 | 12860 |
19 | 194 | 52384 |
20 | 186 | 27585 |
21 | 184 | 130197 |
22 | 184 | 8652 |
23 | 183 | 64825 |
24 | 175 | 33107 |
25 | 174 | 17864 |
メディア利用量ランキング
順位 | 利用量(GB) |
---|---|
1 | 19.0426854630932212 |
2 | 16.2412302158772945 |
3 | 12.8786057466641068 |
4 | 9.1862531360238791 |
5 | 8.8057373138144612 |
6 | 6.3584921630099416 |
7 | 5.7975652972236276 |
8 | 5.7018317887559533 |
9 | 5.3196726590394974 |
10 | 4.8284646151587367 |
11 | 4.6705092173069715 |
12 | 4.4955962570384145 |
13 | 4.1477874331176281 |
14 | 3.9942653700709343 |
15 | 3.9166470151394606 |
16 | 3.8486613761633635 |
17 | 3.8317625029012561 |
18 | 3.6665426520630717 |
19 | 3.4228599537163973 |
20 | 3.3217734936624765 |
21 | 3.2794725243002176 |
22 | 3.2305235359817743 |
23 | 2.7993793683126569 |
24 | 2.7909871954470873 |
25 | 2.7644846774637699 |
はんドンクラブが認知している外部サーバのアカウント数
順位 | サーバー名 | アカウント数 |
---|---|---|
1 | misskey.io | 23707 |
2 | mastodon.social | 18510 |
3 | mstdn.jp | 13528 |
4 | pawoo.net | 9618 |
5 | fedibird.com | 4520 |
6 | mastodon.online | 2083 |
7 | mstdn.social | 1783 |
8 | 非公開 | 1740 |
9 | m.cmx.im | 1399 |
10 | vivaldi.net | 1335 |
11 | noagendasocial.com | 1278 |
12 | fosstodon.org | 1232 |
13 | mas.to | 1169 |
14 | sushi.ski | 1149 |
15 | poa.st | 1113 |
16 | misskey.design | 1025 |
17 | mastodon-japan.net | 1013 |
18 | chaos.social | 983 |
19 | best-friends.chat | 902 |
20 | mastodon.art | 889 |
21 | hachyderm.io | 862 |
22 | misskey.cf | 812 |
23 | nijimiss.moe | 805 |
24 | mastodon.cloud | 730 |
25 | mastodon.world | 707 |
ストリーミング障害発生のお詫びとご報告
みなさんこんにちは。はんドンクラブ管理人のはんです。
本日は先日発生したストリーミング障害に関するお詫びと、発生原因や再発防止策のご報告をさせていただきます。
概要
- 日時: 2023年8月29日 23:04 - 9月4日 23:59、および 2023年9月5日 6:16 - 14:14
- 対象: すべてのユーザー
- 内容: ユーザーストリーミングが不安定(定期的にタイムラインが更新されなくなる)
長期間にわたりストリーミングサービスが停止し、ご不便をおかけして申し訳ございませんでした。
経緯
日時(JST) | 時系列 |
---|---|
8/29 22:43 | サーバー移転作業が終了し動作確認を開始 |
8/29 23:04 | サーバー移転の動作確認が完了(このタイミングから障害が発生) |
8/29 23:05 | ユーザー申告により問題が発生していることを認知 |
8/29 23:30 | Redisサーバーの設定変更を行いDebugログが取得できる状態になった |
8/29 23:36 | RedisサーバーとStreamingコンテナ間のTCPコネクションに異常がある可能性を発見 ※結果的にこれが根本原因の一つでした |
8/30 00:13 | 解析の結果、影響範囲軽減に有効だと判断し、 【暫定対処(1) 5分おきにStreamingコンテナを再起動】 を開始(このタイミングから障害が緩和) |
8/31 23:32 | TCPコネクションの異常がStreamingの更新されない事象と本障害が直接関連していると断定し、対処策を本格的に検討開始 |
9/1 00:25 | 【対処案(1) ARPキャッシュTTL/TCP KeepAlive時間の調整】 を実行、同時に 暫定対処(1) を一時中断 |
9/1 00:30 | 対処案(1) 実行後に事象が再発したため、不十分と判断し、暫定対処(1) を再開 |
9/4 23:01 | 解析の結果、根本原因(後述する原因A・B・Cとその因果関係)を断定 |
9/4 23:22 | 【対処案(2) クラウドサービスのVPC設定変更等】 を実施、監視を継続 |
9/4 23:59 | 対処案(2)の効果が見られたと判断し、暫定対処(1) を中断 |
9/5 06:16 | 対処案(2) 実行後に最初に事象が再発(一時的に障害が悪化) |
9/5 09:02 | 暫定対処(1) を再開(障害が再度緩和) |
9/5 14:14 | 【対処案(3) コンテナのネットワーク設定変更】 を実行、暫定対処(1) を中断(障害が完全に回復) |
9/5 22:37 | 対処案(3) により事象が完全に回復したと判断、ユーザ周知 |
結果的にサービス影響は以下のとおりとなります。
- 全く使えない状態(サービス停止状態)
- 合計3時間55分
- 8/29 23:04〜8/30 0:13の1時間9分、9/5 06:16〜9/5 09:02の2時間46分
- 定期的にサービスが使えなくなるものの、数分以内に自動的に再接続が行われる状態(サービスデグレ状態)
- 合計148時間58分
- 8/30 0:13〜9/4 23:59の5日23時間46分、9/5 09:02〜9/5 14:14の5時間12分
原因
データセンター内のサーバー間の通信(TCPコネクション)が不安定となり再接続が行われた場合、MastodonがRedisのSubscribe要求を再送しますが、Redisの上限値である1024*1024を超過して送出する場合があり、かつMastodonがRedisサーバーのエラーを正しくハンドリングできていないためにタイムラインの情報がStreamingで更新できない状態となりました。
発生メカニズムの詳細
まずは構成を説明します。
要因となった動作を説明するには、メインホスト (=Streamingコンテナが動いているホスト)と Redisホスト が登場します。他にMastodonを構成するために必須なPostgresホストなどもありますが、今回の障害要因に関係ないため、この記事では記載を省略します。
メインホスト である host名 prd-host1
および prd-host2
は、Dockerでいくつかのコンテナが動いています。その中の一つがstreamingコンテナです。コンテナはbridgeでVPCに繋がっており、このbridgeではNATが行われます。
Redisホスト であるhost名 prd-redis
は Redisが直接ホストで動いており、メインホストと同様にVPCに繋がっています。
さて、事象が発生するメカニズムは以下のとおりです(ただし、後の解析で、①②は③を誘発する要因の1つでしかなく、必要条件ではないことが分かっています)。
- ① ARPキャッシュTTL切れを契機にメインホスト → Redisホストに ARPリクエストを送出
- ② Redisホスト → メインホストにARPリプライを応答、メインホストは正常に受け取る
- ③ 根本原因は不明だが、メインホストがRedisホストに対して全てのTCPコネクションをリセットする要求を送出する場合がある ・・・【原因A】
- ④ 直後にメインホストがRedisホストに対してTCPの再接続要求を送出し、3-way handshake完了後にRedis上でSubscribeリクエストを送出。このとき、元々のSubscribe量によって、Redisのmulti bulk 引数制限(1024*1024)を超過したメッセージを送出する場合がある・・・【原因B】
- ⑤ multi bulk 引数制限を超過している場合のみ、Redisサーバーはsubscribeリクエストに対してエラー応答
- ⑥ StreamingコンテナはSubscribe要求を再送せず、要求が認められたとして以後の処理を継続する・・・【原因C】
①②の後に100%で③が発生しています。しかし前述のとおり、③は①②のARPキャッシュTTL切れ有無によらず、発生する場合がありました。そのため、③が発生する契機は完全には解明できていません。
④はSubscribe量によるため、アクティブユーザー数によって発生する場合と発生しない場合がありました。私の感覚では10分の1〜5分の1程度です。④が発生した後、継続して⑤⑥が発生する確率は100%です。
各要因の深掘り(原因A)
特に負荷が高い状況でなくとも、当初は60秒に1度全てのTCPコネクションをリセットする送出していました。このTCPリセット送出の要因は、ホストの可能性とStreamingコンテナの可能性があります。実際にはキャプチャをVPCに接続しているNICでしか取得できなかった(=bridge側インターフェースで取得できなかった)ため断定はしておりませんが、他のコンテナで同様の問題が発生していないことから、Streamingコンテナが送出元と想定しています。
○パケットキャプチャの例
○Redisサーバー側
12249:M 05 Sep 2023 13:24:54.971 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.034 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.083 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.083 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.274 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.285 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.679 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.888 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:55.988 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:56.190 - Reading from client: Connection reset by peer 12249:M 05 Sep 2023 13:24:56.218 - Reading from client: Connection reset by peer
送出している原因は断定できていません。しかし、当初はARPを契機にTCP RSTを送出していたため、ARPが一つの要因であることに間違いはありません。メインホストはRedisサーバーからAPRリプライを受け取った直後100ms以内でTCP RSTを送出していました。これは再現率100%です。しかし、MACアドレスの変動などは見受けられなかったため、この原因は不明です。
一方、ARPキャッシュ時間を長くしても、この問題は完全には解消されませんでした。そのため、TCPの何らかのタイムアウト値の設定が悪く、例えばKeep Aliveの不具合が発生しているものだと考えました。DockerをBridgeで接続していたことで間にNATが居たわけですが、このNATが原因で、タイムアウトの瞬間がほぼ同時に発生しTCPクライアント・サーバー間で状態の認識に齟齬が発生した可能性が高いと考えています。
各要因の深掘り(原因B)
MastodonのStreamingプロセスの実装上、一度TCPコネクションが切断されても再度TCPコネクションを張り直し、Redisに対してSubscribeしていた内容を再度Subscribeしようとします。この実装自体に問題はありません。
しかしながら、このSubscribeを1リクエスト(1パケット)にまとめて送る仕様のようで、稀にRedisサーバーが受け取れる上限を超えて送ってしまうようです。具体的には、Redisサーバーはmulti bulkリクエストを送る場合に1024*1024までというサイズ制限があるのに、MastodonのStreamingプロセスはこれを無視して全ての要求を一度に送ってしまう ことが原因です。
○Redisサーバー側
29 Aug 2023 23:51:51.721 - Protocol error (unauth mbulk count) from client: id=502 addr=192.168.1.9:60128 fd=58 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=1122 qbuf-free=31646 argv-mem=0 obl=55 oll=0 omem=0 tot-mem=61440 events=r cmd=NULL user=default. Query buffer during protocol error: '*39..$9..SUBSCRIBE..$28..timeline:access_token:XXXXXX..$17..time' (... more 994 bytes ...) ':XXXXX..$14..timeline:XXXXX..$28..timeline:XXXXX:notifications..'
※ユーザIDを含む部分はログ上でマスクしています。
○Streamingプロセス側
ERR! Redis Client Error! Error: read ECONNRESET ERR! Redis Client Error! at TCP.onStreamRead (node:internal/stream_base_commons:217:20) ERR! Redis Client Error! Error: read ECONNRESET ERR! Redis Client Error! at TCP.onStreamRead (node:internal/stream_base_commons:217:20) { ERR! Redis Client Error! errno: -104, ERR! Redis Client Error! code: 'ECONNRESET', ERR! Redis Client Error! syscall: 'read' ERR! Redis Client Error! }
各要因の深掘り(原因C)
MastodonのStreamingプロセスは大変イケてなくて、一度RedisサーバーにSubscribe要求を断られても、それを再送するということをしません。プロセス内部的には、Subscribeされた状態だと認識しているのです。これを再度Subscribeさせるためには、TCPコネクションを完全に切断するか、プロセス毎を起動するしかありません(もっとも、TCPコネクションを完全に切断してしまうと、原因Bをもう一度引き起こすので解決しないのですが)。
対処方法
StreamingコンテナのみTCPポート4000番(Streamingプロセスが利用するポート)をホストに直接接続する構成変更を行い、本件の解決を行いました。
対処方針の検討プロセス
当然ですが、発生を根絶するためには、ワークフロー後段の原因から対処を検討すべきです。
そこでまず、原因Cの対処を考えましたが、断念しました。この修正のためにはMastodonの実装の確認・修正が必要ですが、Streamingのコードを読んだことすらなかったので、時間的/スキル的制約から取りえない手段でした。
次に原因Bの対処を考えます。Redisサーバーの1024*1024制限はソースコードにハードコードされており、confファイルでは変更できないことが分かりました。ということは、原因Bと同様に、この修正のためにはMastodonの実装の確認・修正が必要です。
以上から、障害認知後の初期段階から、原因Aを修正する方法のみを中心に検討を進めていました。
原因Aの対処案(1)とその評価
発生直後から、1分単位でTCPコネクションが頻繁に切れていることはわかっており、かつUbuntuで1分のタイマ値として思いつくものがARPキャッシュ・TCP Keep Aliveしかありませんでした。 そして、取得したパケットキャプチャから、ARPのタイミングとTCP RSTのタイミングが100ms以内であることを特定していましたので、まずはARPキャッシュを1日に延長することにしました。
echo xxxx >/proc/sys/net/ipv4/neigh/default/gc_stale_time
若干の影響軽減は認められたものの、根本解決はしませんでした。 これは、前述のとおり、①②のARPシーケンスは原因Aの発生原因の1つでしかなかったからです。
なお、そのほか、Kernel上でTCP Keepaliveの調整をいくつか試しましたが、こちらは効果はありませんでした。
sudo sysctl -w net.ipv4.tcp_keepalive_time=xxxx sudo sysctl -w net.ipv4.tcp_keepalive_intvl=xxxx
原因Aの対処案(2)とその評価
他に同じ事象で困っている鯖缶がいないということは、クラウド事業者側の問題ではないかと疑いました。そこで、VPCの異常を疑いました。
他社のVPSサービスで費用を払い忘れるとネットワーク帯域を絞られた経験があったので、その可能性を考え、費用を先行してデポジットしようとしました。すると、そもそもクレジットカードの支払いに失敗しており、先月分の支払いができてない状態になっていました・・・。
当初、この支払いにより障害の回復が行われたように見えていました。しかしこれも原因Aの発生確立を高める事象の1つでしかなかったようで、すぐに頻発しました。結果的に、対処案(1)ほどの効果はなかったと評価しています。
余談: 当初VultrのVPC2.0をつかっていたのですが、これだとProxy ARPをしている人がいるように見えて気持ち悪かったので、VPC1.0に戻しました。しかし、この処置により改善は見られませんでした。
原因Aの対処案(3)とその評価
主に切り分けを目的として、ネットワーク経路の被疑箇所を減らすべきだと考えました。よって、NATを除去すべきだと考えました。
具体的には、StreamingコンテナのみTCPポート4000番(Streamingプロセスが利用するポート)をホストに直接接続することで、切り分けを行おうとしました。実際には、docker-compose.yml
に network_mode の設定を加え、docker compose down && docker compose up -d
しました。
streaming: network_mode: "host"
この変更は効果があり、結果的に一度も問題が再発せず、障害が解決しました。
対処プロセスの評価
早い段階でメカニズムを解明し、かつ原因Aの対処案策定に絞れたことは評価できると考えています。しかしながら、以下の理由により、具体的な対処案策定には時間を要してしまいましたので、改善が必要だと考えています。
- 管理人の寝不足
- 前日までの手順確認作業により寝不足であり、発生当日の切り分け時間が十分確保できませんでした。
- 管理人の風邪
- 子供から風邪をもらってしまい、寝込んでしまいました。
対処案策定から実行までの時間に問題はありませんでした。
加えて、例えばVPC等に障害が起こった場合に、原因A以外の原因で原因Bが発生し、結果的に同一障害が発生してしまうリスクは残っています。 すなわち、原因B・原因Cの本格対処が不要となったわけではありませんので、原因Bの発生を検知したらStreamingコンテナを自動再起動するようなスクリプトの開発が必要 だと考えています。
再発防止策
- 開発環境での長期安定性試験の強化(実施中)
事前に発見できなかったのかという観点での再発防止です。 負荷がある程度ある状態でないと再現しない問題だったとはいえ、開発環境でも複数回再現していた痕跡がありました。
そのため、開発環境での試験項目に長期安定性試験を加え、Streamingの確認をより入念に行うようにします。
- 体調管理の徹底(実施中)
もうすこし日常的に運動をして、免疫を付けたいと思います。よい運動の方法について、慎重に検討を重ねております。
また、子供(1歳)に、帰宅後は手をよく洗うようにお願いしたところ、「はい」と返事しました。これで大丈夫でしょう。
- 原因C発生時の自動再起動スクリプトの開発(実施中)
スクリプトの開発は概ねできていますが、いくつか技術的な問題があり、苦戦中です。力業で解決できる見込みなので、2023年10月中に完了予定です。
おわりに
今回はご迷惑をおかけして申し訳ありませんでした。ひきつづき、はんドンクラブをよろしくお願いいたします。
もし引き続き調子が悪い方がいらっしゃれば個別にご連絡をお願いいたします。
新たに登録された方へ
はんドンクラブ(handon.club)へようこそ! 管理人のはん(@highemerly@handon.club)です。
数あるMastodonサーバーから、この「はんドンクラブ」を見つけてくださり、ありがとうございます。Mastodonは、Twitterと非常に似たサービスですが、意外と異なる部分もあります。ですから、もしかしたら、少しだけ取っつきにくいと感じる方もいらっしゃるかもしれません。この記事では、そんな方が悩みやすいポイントとその解説をまとめました。
決して、はんドンクラブを使う前に必ず読んでください、という訳ではありません。でも、もしMastodonを使うのが初めてで、不安なことがある方は、是非この記事を読んでみてください!
- はじめに: 管理人が一番伝えたいこと
- どうやって投稿するの?
- この投稿は全世界に伝わってしまうの?鍵垢にできるの?
- 他のサーバーの人をフォローできるの?フォローするために、他のサーバーにもアカウントを作った方がいいの?
- おすすめの設定があったら知りたい!
- 用語が分からない!
- もっと深く知りたい!
はじめに: 管理人が一番伝えたいこと
上記の投稿のとおり、PCでもスマホでも、最初はWeb(ブラウザ)を使うことをオススメします。
MastodonのWebは、とってもよくできています。更に、アカウント作成直後にログインすると、フォローするユーザーをオススメしてくれます。でも、アプリやクライアントはこのオススメユーザーに対応していない場合が多いので、最初のフォローだけでもブラウザで済ませちゃうことをオススメしているのです。
では、オススメユーザーの探し方について、具体的にご説明します。最初のページ(図左)で、気になるユーザーを見つけ、フォローボタンを押すだけです。もしこの画面が出なかった場合や、しばらくMastodonを使ってみた後にまたオススメユーザーを見たい場合は、画面右メニューの「#(エクスプローラー)」を開いて「おすすめ」をクリックしてください。ほぼ同じ画面(図右)に飛べます。ユーザの選出方法は若干違うのですが、十分参考になると思います。
加えて、ローカルタイムライン(左)という機能もあります。これは、あなたが誰もフォローしていなくても、はんドンクラブに登録しているユーザーの公開投稿が全て勝手に流れてくるタイムラインです。このローカルタイムラインからユーザーを見つけるのもまた良いかもしれません。ちなみに、連合タイムライン(右)という似た機能もありますが、流量が多すぎるため、最初は見なくてよいですよ。
いかがでしょう。フォローを増やせましたでしょうか? もし何か分からないことがあれば、先の投稿にあったとおり、何でも気軽に聞いてください。実はこれが一番伝えたかったことです。 お気軽に管理人のはん(@highemerly@handon.club)宛にリプライを頂ければ、手が空いたときにお返しします!
どうやって投稿するの?
ここまでで、私の伝えたかったことは終わりました。以下はもう読まなくて良いので、適当に触ってみてくださいね!
・・・。まあ、それでももっと知りたいという方のために、もう少しだけ続けますね。
まずはとりあえず投稿してみましょう。 初期設定でかつ誰にもフォローされていなければ、はんドンクラブのローカルタイムラインにだけ流れ、他のサーバーには流れません。 気楽に挨拶でもしておきましょう。
もしかしたら、ローカルタイムラインを監視している暇人がフォローしてくれるかもしれません。気に入った方であれば、フォローを返してみてくださいね。それか、フォロー有無に関係なく、ローカルタイムラインに投稿している他の人の投稿にリプライを送ってみてもといいかもしれませんね。
この投稿は全世界に伝わってしまうの?鍵垢にできるの?
はんドンクラブ所属のユーザーであれば、ローカルタイムラインで誰でもあなたの投稿を見ることができます。時間が経つと、他のサーバーでも見えるようになるでしょう。
でも、 設定変更により、Twitterの鍵垢と同じように、あなたが許可した人にしか投稿を見せなくすることができます。 ただ、Mastodonは高機能な故にすこしだけ複雑な設定が必要です。すなわち、
- 投稿単位での公開範囲設定
- アカウント単位での公開範囲設定(=フォロー許可設定)
の2つが別々に設定できるようになっており、Twitterの鍵垢と同じことをするには両方の設定を変えなくてはならないです。
具体的には、各投稿毎の公開範囲設定を「フォロワー限定」にして、かつ、アカウントの設定で「承認制アカウントにする」にする必要があります。 長くなるので、具体的な設定方法の説明は省略させてください(知りたい方はリプライしてください)。
ちなみに、一見複雑でめんどくさそうに思えますが、この「各投稿毎に公開範囲を設定できる」という仕様は慣れるととても便利です。例えば、普段は鍵垢として運用しながら、拡散したい投稿だけ公開投稿とすることができますよね。
なお、投稿毎の公開範囲は以下の4つが選べるようになっています。
投稿ごとの公開範囲 | 概要 |
---|---|
公開 | 初期設定/通常の公開投稿 |
非収載 | ローカルタイムラインには流れないが、アカウントページからは誰でも閲覧できる |
フォロワー限定 | フォローされているユーザーしか閲覧できない |
指定された相手のみ | いわゆる「ダイレクトメッセージ(DM)」 |
4つの違いは少し難しいので、まずは気にせず初期設定のまま、「公開」投稿をするのがオススメです。繰り返しですが、「フォロワー限定」の投稿をしても、アカウントの設定で「承認制アカウントにする」を有効にしていない場合、誰でも許可なくフォローできる状態ですので、結果的にその投稿は誰でも見れてしまいますからご注意ください。
他のサーバーの人をフォローできるの?フォローするために、他のサーバーにもアカウントを作った方がいいの?
フォローできます。ですから、他のサーバーのアカウント作成を急ぐ必要はありません。
Mastodonサーバーには連合という機能があり、はんドンクラブ以外のサーバーと勝手に連携して動く仕組みになっています。つまり、あなたは、はんドンクラブ以外のサーバーの人ともコミュニケーションを取ることができます。ただ、ローカルタイムラインには他のサーバーの投稿は流れませんから、そのユーザーのIDをどうにかして仕入れてきてフォローする必要があります。
フォローしたいユーザーのIDは、短縮形ではなく正確なIDを知る必要があります。ここで、「正確な」IDというのは、@username@domain のように、@マークが2つある形式のことです。例えば、あなたの登録したIDが donmi で、登録先がはんドンクラブなら、あなたの正確なIDは @donmi@handon.club となります。所属するサーバーが異なれば短縮形のIDはかぶる可能性がある、つまり @donmi@example.com と @donmi@handon.club が別の人かもしれないので、正確なIDが必要なんです。技術的には、メールアドレスに近いです。いずれにせよ、この正確なIDをフォローしたいユーザーに直接聞くなどして、あらかじめ控えておいてください。
後は簡単です。教えてもらった正確なIDをエクスプローラの検索窓に打ち込み、Enterキーを押します。すると、そのユーザーが表示されるはずです。その画面でフォローしちゃいましょう。
ちなみに、フォローしたいユーザーがMastodon以外のソフトウェア、例えばMisskeyやPleromaといった他の分散型SNSを使っていても、はんドンクラブからフォローできます。ですから、はじめてMastodonに登録したあなたは、他のサーバーにアカウントを作る必要はありません。 もちろん、使いこなしてきた後、他のサーバーの雰囲気を知りたいとか、Misskeyをやってみたいとか、そういった用途でアカウントを増やすことはよいと思います。
おすすめの設定があったら知りたい!
以上です!
用語が分からない!
- トゥート: TwitterでいうTweet。投稿のこと*1。
- ブースト: TwitterでいうReTweet。
- リモートフォロー: 別サーバーの人をフォローすること。
- HTL: ホームタイムラインのこと。Twitterにもある、通常のタイムライン。
- LTL: ローカルタイムラインのこと。そのサーバーの人の公開投稿が流れる。
- FTL: 連合タイムラインのこと。そのサーバーで認知しているユーザー*2全員の公開投稿が流れる。
- インスタンス: サーバーのこと。たくさんあるMastodonサーバーのうち、1つだけ特定のサーバーを差して使う*3。
- Fediverse: MastodonやMisskeyなど、多数の分散型SNSサーバーが繋がっている空間全体を指す、ちょっと概念的な言葉。ただ、最近は分散型SNSのことを総称してFediverseと呼ぶ場合が多いです。
- NSFW: Not safe for work。閲覧注意フラグという言い方が正確。ちょっとアレなトゥートやネタバレなどを一時的に隠して投稿できる。
- CW: Content warning。ちょっとエッチな画像を一時的に隠して投稿できる。
- カスタム絵文字: 管理人が登録した特殊な絵文字。そのサーバーに属している人なら誰でも使える。他のサーバーの人は使えないけど、あなたの投稿で使われたカスタム絵文字は見ることができるので、気軽に使ってみよう。
もっと深く知りたい!
まきはらさんのとてもわかりやすいまとめです。この記事との重複もありますが、ぜひどうぞ。
はんドンクラブでは、他のMastodonサーバーにない独自機能を実装しています。詳しくはこちらをどうぞ。
はんドンクラブの利用規約を変更します。
Mastodonの新しいシステムに対応するため、利用規約を更新します。 意図を変えているつもりはありませんが、文章構造が変わっているため、内容をご確認ください。
**2023/2/4 追記 何ヶ所か微調整を行い、期限を延長しました。**
- プライバシーポリシーに更新はありませんので、このページからは記載を省略しています。
- Mastodonのシステムの都合上、「利用規約」を「サーバーのルール」と言い換えます。
- 不安な点があれば、
2023/2/62023/2/11までにお問い合わせください。問い合わせが無ければ、2023/2/72023/2/12以降に本サーバーのルールを適用します。
更新のポイント
- 規約の構造を修正しました。
- 利用者に守って頂く必要がある事項のみ、"サーバーのルール" に記載することにしました(通報時、このルールを選択する必要があるためです)。結果、他の免責事項などの利用規約は "その他" に移動しました。
- その他、文意が変わらない範囲で、段落を組み替えました。
- 「みんな仲良くしてください。」の意図を明確にしました。
- 細かな文言修正を行いました。
更新後
Mastodonサーバーのはんドンクラブ(以下,本サービス)をご利用いただく場合,以下の「サーバーのルール」と「プライバシーポリシー」の両方に同意するものとします。
サーバーのルール
サーバーのルールに概要を記載しています。このページでは,補足を含め,ルールの原本を記載します。
1. みんな仲良くしてください。
「馴れ合いましょう」という意図ではありません。「能動的に仲を悪くする行動をしないでください」という意図です。嫌な人・投稿を見つけても,まずはブロックやミュートを活用し,自衛してください。他人に思想や行動を強いないでください。
2. 法または道徳に反する投稿はやめてください。
特に,自身が権利を有している,または適切な同意を得ているもののみ投稿してください。
3. 投稿画像や動画には,必要と認める場合は閲覧注意フラグを付与してください。
基準は皆さんの良心にお任せします。閲覧注意フラグが付いていれば,投稿内容画像や動画の制限は行いません。ただし,法に前項の規定に反する場合はこの限りではありません。
4. サーバーに過度な負荷をかけないでください。
常識的な利用(サードパーティー製クライアントの利用,多重接続,実況,動画投稿などを含む)は問題ありません。botによる大量の反復動作など,機械的かつ非常識的な利用はやめてください。
その他
- 本サービスを利用したこと,および利用できなかったことによる損害は,いかなる場合も補償しません。
- 投稿内容の著作権等の権利は,いかなる場合も投稿したユーザーに帰属します。
- サーバーのルールに反する場合など,管理人が必要と判断した場合は,
発言投稿またはアカウントの削除を行うことがあります。 - サーバーのルールは以下を全て満たす場合改定できるものとし,改定後も本サービスを継続利用しているユーザーは新たなルールにも同意したとみなします。
- 新たな規約案は適用1週間以上前に掲載し,広く意見を求めます。
- 掲載は分かりやすい複数の方法で行います。
更新前
Mastodonインスタンスのはんドンクラブ(以下,本サービス)をご利用いただく場合,以下の「サーバーのルール」と「プライバシーポリシー」の両方に同意するものとします。
- 1. みんな仲良くしてください。
- 2. 法または道徳に反する投稿はやめてください。
- 投稿内容は,投稿者が著作権等の権利を有している,または適切な同意を得ているものにしてください。
- 3. 投稿画像や動画には,必要と認める場合は閲覧注意フラグを付与してください。
- 基準は皆さんの良心にお任せします。
- 閲覧注意フラグが付いていれば,投稿内容の制限は行いません。ただし,法に反する場合はこの限りではありません。
- 4. 安定運用のため頑張りますが,万一全てが吹っ飛んでも泣かないでください。
- 5. サーバに過度な負荷をかけないでください。
- 6. 利用規約に違反している場合,その他管理人が必要と判断した場合は,発言またはアカウントの削除を行うことがあります。
- 7. 投稿内容の著作権等の権利は,いかなる場合も投稿したユーザに帰属します。
- 8. 利用規約は以下を全て満たす場合改定できるものとし,改定後も本サービスを継続利用しているユーザは新たな規約にも同意したとみなします。
- 新たな規約案は適用1週間以上前に掲載し,広く意見を求めます。
- 掲載は分かりやすい複数の方法で行います。
はんドンクラブの運営について
サーバーのルール・プライバシーポリシー
運営ガイドライン
管理人は,はんドンクラブを,以下3つの基本方針(「運営ガイドライン」と呼称します)に従い運営するよう努めることとします。
インフラ運用
安定運用を第一に,常時監視,データの定期バックアップ,各種作業時の検証環境による事前テスト等を行います。運用状況は可能な限りオープンにします。Mastodonの新バージョンにいち早く追従するため,ソースコード改変は最小限にします。
モデレーション
サーバブロックやアカウント停止は必要最低限とし,その内容や理由は運営やプライバシーに支障が無い限りオープンにします。通報についても,真に必要な場合のみ対処を行います。ユーザーのプライバシーを最大限尊重します。
コミュニティ
サーバ内での話題,フォロー関係,イベントやオフ会等については、サーバ管理人が管理するところではないため,特に制限しません。
また,上記運営ガイドラインに従うための具体的なアクションとして,ユーザへの注意喚起事項や実際の運営方法など(「運営に関する情報」と呼称します)を別途定めることとします。
運営に関する情報
運営に関して,必要と思われる情報をまとめたものです。管理人の意向により周知なく改定されることがあります。
管理人へのリクエスト方法
記載の無い内容で管理人へリクエストが必要な場合は、お気軽にリプライ・ダイレクトメッセージ等でご連絡ください。
レポート(スパム報告)
レポートには理由をできる限り詳細に記載して下さい。記載頂いた理由のみから客観的に判断し,処置を検討します。なお,すべてのレポートは公開される場合がある旨はご了承下さい。より詳細な事項については, 「通報」機能についてのお願いをご参照ください。
カスタム絵文字の追加
以下の条件をすべて満たす画像であれば登録を受け付けています。管理人まで個別にリプライまたはダイレクトメッセージでお申し出ください。
アカウント削除
ユーザ設定画面からのアカウント削除は,技術的な理由により無効にしています。アカウント削除をご希望の方は,管理人まで個別にリプライまたはダイレクトメッセージで申し出てください。原則3日後までの深夜帯に処理します。
ただし,分散型SNSの性質上,他サーバへ配送済の投稿を全て削除することは保証できません。これは,はんドンクラブから連合している全てのサーバへ削除要求を送ったとしても,そのサーバが確実に削除するかどうかを掌握できないためです。管理人はユーザの"忘れられる権利"を最大限尊重し,個人運営サーバとして現実的に可能な範囲での努力を行いますが,連合先サーバでのデータ削除保証はできないことをあらかじめご承知おきください。
権利侵害の報告,情報開示請求
権利侵害の申告,法令等に基づく情報開示請求,警察・行政機関等からの問合せについては,Google Formでご連絡ください。
はんドンクラブの特徴
ユーザーの新規登録,ユーザの招待
はんドンクラブは招待制インスタンスです。招待は,はんドンクラブにアカウントをお持ちの方であれば,誰でも可能です。設定画面の「新規ユーザーの招待」よりURLを発行してください。利用規約を遵守出来る方であれば,招待する人にも人数にも制限はありません。
また,招待が無くても登録できる「承認制」も採用しています。意気込みを記載の上,登録申請をしてください。管理人の独断により承認可否を決定することをご了承ください。
独自機能
以下の記事でまとめていますので,よろしければご一読ください。
カスタムテーマ
以下のカスタムテーマを採用しており,誰でも設定で有効にできます。
- InstanceTicker by weepjp
- Blacklead Theme by mast.mast
- Canta Dark by Pourrito
ソースコード
mastodonの公式リポジトリのソースコードをupstreamとし,一部独自に改変したコードが動いています。upstreamへの追従は,原則として正式なreleaseまたはpre-releaseへの追従のみとし,いわゆる"main追従"は可能な限り行いません。実際に動作しているコードについては,github で公開しており,独自部分もgithub上のcompareページで確認可能です。
マスコットキャラクター
「ドン美ちゃん」 をよろしくお願いします。
- アカウント: @donmi
- 誕生日: 4月14日
- 好きなもの: ヤクルト400LT
- カスタム絵文字: :donmi:
運営状況
運営情報の発信
メンテナンスなどのサーバ公式情報は,以下のいずれかの方法で発信します。なお,やむを得ず予告なくメンテナンスを実施する場合もございますので予めご了承ください。
- HTL上部の「お知らせ」欄
- https://status.handon.club/
- このブログ
- ハッシュタグ #handon_info
運営費用
このサーバは各種クラウドサービスを使って運営されています。クラウドサービスには月額で費用が発生するため、以下ページで月額制でのカンパを募集しています。
なお,カンパは決して強制ではありません。もちろん,「カンパをしていないから〇〇をしてはいけない」ということもありません。
実際にカンパをいただいた方のお名前は、 このサーバーについて - handon.club にて掲載しています。
連合状況等
Fediverseとの連合状況などをお伝えします。
連合を停止またはメディアを拒否しているサーバー
このサーバーについて - handon.club をご参照ください。
通報を受理していないサーバー
以下のサーバーからの通報は受理していません。
サーバ名 | 理由 |
---|---|
ro-mastodon[.]puyo[.]jp | 意図不明の通報が多く,正常な運営に著しく支障をきたしているため |
プッシュ通知を送信していないサーバー
以下のアプリ・サービスへのプッシュ通知は送信しません。
アプリ・サービス名 | 理由 |
---|---|
tootle | ほぼ常時通知サーバーが応答せず,サーバ全体のパフォーマンスに著しく支障をきたしているため |
avalanche | ほぼ常時通知サーバーが応答せず,サーバ全体のパフォーマンスに著しく支障をきたしているため |
なお,あくまでプッシュ通知を送信しないだけなので,その他の用途ではお使い頂けます。
リレーの利用
本サービスでは,リレーは利用していません。
その他
運営者による人的リスク
Webサービスを提供する以上,技術的に排除できない人的リスクが残ります。そのリスクとそれに対する考え方を以下のとおり説明します。
- Mastodonに限らず全てのwebサービスに共通することですが,特定のソースコードで確かに動作していることをユーザーに対して保証する方法は世に存在しません。すなわち,技術的には,管理人は特定の改変を無断で行えてしまうため,例えばパスワードを平文で取得する改変が出来てしまいます。しかしながら,管理人はこういった改変行為を行う,または試みることは決してないと宣言します。
- 管理人は,ダイレクトメッセージや非公開の投稿などの秘匿すべき情報であっても,技術的には閲覧できる状態にあります。これは,現在MastodonにE2E暗号化機能が存在しないための技術的な制約であり,回避不可能です。しかしながら,プライバシーポリシーに示す真にやむを得ない事項を除き,個人的な目的および趣向に基づいてそれらの情報を閲覧・公開したり,またはそれらを試みたりすることは決してないと宣言します。
届出電気通信事業
当サーバの運営は,電気通信事業として関東総合通信局に届出を行っています(届出番号: A-04-19588)。
沿革
- 2017.04 運営開始
- 2018.08 電気通信事業の届出
- 2018.09 一部サーバ移転,IPv6対応
- 2018.11 完全招待制へ移行
- 2019.07 電気通信事業の届出先変更(関東→近畿)
- 2019.10 100万トゥート達成
- 2020.11 200万トゥート達成
- 2021.05 一部サーバ移転
- 2022.02 電気通信事業の届出先変更(近畿→関東)
- 2022.05 300万トゥート達成
2022年年末のご挨拶
こんにちは。はんドンクラブ管理人のはんです。
2022年も残すところわずかとなりました。今年も皆様はんドンクラブをご利用いただきありがとうございました。
毎年言っているような気がしますが、元々はんドンクラブは自分用に建てたおひとり様サーバーで、正直ここまで長く続くと思っていませんでした。それがもうすぐ6周年です。みなさんがたくさん使ってくれているので、その結果私のモチベーションは一切衰えることなく運営できています。
2022年、私自身はプライベートがめちゃくちゃ忙しく投稿数は若干減ってしまいましたが、タイムラインはめっちゃ見てます。来年も引き続きたくさん投稿してくださいね。あ、もちろん私も頑張りますよ。
いくつか、はんドンクラブの状況を貼って、年末の挨拶に変えさせて頂きます。
主なイベント
- 2022/4/1 3.5.Xへのメジャーアップデート
- 2022/4/15 5周年🎉
- 2022/5/10 300万トゥート達成
- 2022/5/29 ステータスページの公開
- 2022/6/18 LT大会実施
- 2022/6/21 CloudFlareの大規模故障に伴うサービス停止
- 2022/6/22 攻撃によるサービスのデグレ
- 2022/7/29 動画がアップロードできない問題への対処
- 2022/11/13 データベースサーバの移転(スケールアップ)
- 2022/11/20 4.xへのメジャーアップデート
- 2022/11/22 トレンド承認に協力頂く方を募集、運用開始
- 2022/12 アドベントカレンダー
統計情報
基本情報
- ローカルの情報
項目 | 値 | 説明 |
---|---|---|
総アカウント数 | 371 | |
総トゥート数 | 3,353,951 | 削除されたトゥートはカウントされません。 |
総ふぁぼ数 | 2,890,440 | はんドンクラブのユーザが登録したお気に入りの数の合計です。 |
総ブックマーク数 | 10,977 | はんドンクラブのユーザが登録したブックマークの数の合計です。 |
総被通報数 | 560 |
- Fediverseの情報
項目 | 値 | 説明 |
---|---|---|
総アカウント数(Fediverse) | 102,232 | はんドンクラブが認知している、Fediverseのアカウント数です。 |
総サーバ数(Fediverse) | 8,144 | はんドンクラブが認知している、Fediverseのサーバ数です。 |
- サーバの情報
項目 | 値 | 説明 |
---|---|---|
Postgresql | 24.4GB | トゥートの内容などを保存してるデータベースの容量です。 |
メディアストレージ | 265GB | トゥートに添付されている画像・動画などを保存しているデータベースの容量です。 |
トゥート数ランキング
自分のトゥート数から、自分が何位なのか確認してみてください。
rank | トゥート数 | (参考)アカウント作成日時 |
---|---|---|
1 | 178,656 | 2017-04-16 3:14:45 |
2 | 163,997 | 2018-09-26 14:00:25 |
3 | 146,379 | 2017-04-19 23:46:21 |
4 | 131,224 | 2018-08-15 15:46:57 |
5 | 130,053 | 2018-09-06 12:13:56 |
6 | 120,478 | 2018-08-17 4:55:37 |
7 | 114,850 | 2017-04-14 15:25:19 |
8 | 109,053 | 2018-09-26 13:34:53 |
9 | 99,747 | 2017-12-10 5:50:00 |
10 | 95,954 | 2017-04-15 2:53:53 |
11 | 75,130 | 2018-08-21 3:56:49 |
12 | 74,348 | 2017-04-15 2:55:00 |
13 | 69,004 | 2017-04-15 1:58:28 |
14 | 67,690 | 2018-11-19 4:43:11 |
15 | 65,230 | 2018-11-19 4:44:54 |
16 | 62,461 | 2018-09-09 8:15:50 |
17 | 59,387 | 2018-08-16 13:33:58 |
18 | 57,333 | 2018-03-21 4:27:47 |
19 | 54,388 | 2017-10-07 6:55:04 |
20 | 54,232 | 2018-08-27 18:58:04 |
21 | 53,739 | 2020-01-04 15:34:32 |
22 | 52,305 | 2018-08-16 15:52:20 |
23 | 51,015 | 2019-08-16 9:27:19 |
24 | 51,003 | 2017-04-15 2:53:10 |
25 | 50,959 | 2018-08-23 10:41:05 |
26 | 48,670 | 2017-04-15 2:01:40 |
27 | 45,025 | 2018-08-17 12:06:59 |
28 | 45,005 | 2018-08-18 23:14:01 |
29 | 42,951 | 2018-12-13 10:31:58 |
30 | 42,037 | 2018-09-25 9:56:11 |
31 | 39,312 | 2018-10-19 10:33:07 |
32 | 33,396 | 2020-01-04 15:38:40 |
33 | 33,355 | 2017-04-25 0:18:50 |
34 | 31,416 | 2017-04-25 0:39:03 |
35 | 31,113 | 2018-09-19 8:50:06 |
36 | 30,990 | 2019-05-28 10:45:39 |
37 | 30,125 | 2018-08-17 17:18:25 |
38 | 30,123 | 2017-04-15 11:42:28 |
39 | 29,726 | 2018-09-05 14:53:39 |
40 | 29,189 | 2018-04-08 13:43:48 |
41 | 27,585 | 2018-08-16 6:30:05 |
42 | 26,833 | 2018-11-02 6:18:32 |
43 | 25,271 | 2018-08-16 5:59:16 |
44 | 24,877 | 2018-08-18 1:04:58 |
45 | 24,600 | 2019-03-04 12:21:16 |
46 | 24,394 | 2018-08-15 15:39:00 |
47 | 23,818 | 2018-09-07 20:46:42 |
48 | 22,591 | 2018-09-23 9:01:47 |
49 | 22,507 | 2017-04-22 10:16:54 |
50 | 20,154 | 2018-08-17 3:38:12 |
51 | 18,902 | 2019-01-20 15:15:23 |
52 | 18,890 | 2017-11-01 12:48:57 |
53 | 18,869 | 2018-08-20 13:48:26 |
54 | 17,707 | 2018-08-24 04:52:52 |
55 | 17,057 | 2018-08-15 05:07:14 |
56 | 16,526 | 2019-12-14 16:12:36 |
57 | 15,700 | 2017-04-15 03:00:31 |
58 | 15,617 | 2018-09-27 03:28:07 |
59 | 14,917 | 2018-09-01 10:00:56 |
60 | 13,604 | 2018-12-30 14:05:18 |
61 | 13,589 | 2018-08-27 00:11:08 |
62 | 10,197 | 2018-12-06 03:18:37 |
63 | 10,121 | 2017-04-19 10:59:09 |
64 | 9,856 | 2017-04-15 09:47:13 |
65 | 8,275 | 2018-08-26 03:40:14 |
フォロワー数
rank | フォロワー数 |
---|---|
1 | 693 |
2 | 426 |
3 | 368 |
4 | 333 |
5 | 301 |
6 | 297 |
7 | 293 |
8 | 283 |
9 | 198 |
10 | 191 |
11 | 188 |
12 | 185 |
13 | 182 |
14 | 162 |
15 | 160 |
16 | 159 |
17 | 157 |
18 | 154 |
19 | 153 |
20 | 152 |
メディア容量ランキング
自分のメディア容量は、設定画面から確認できます。
rank | メディア容量 (GB) |
---|---|
1 | 14.68 |
2 | 13.39 |
3 | 11.04 |
4 | 7.28 |
5 | 6.65 |
6 | 5.39 |
7 | 4.78 |
8 | 4.51 |
9 | 4.44 |
10 | 3.93 |
11 | 3.85 |
12 | 3.72 |
13 | 3.41 |
14 | 3.24 |
15 | 3.20 |
16 | 2.97 |
17 | 2.94 |
18 | 2.87 |
19 | 2.87 |
20 | 2.77 |
21 | 2.72 |
22 | 2.46 |
23 | 2.38 |
24 | 2.27 |
25 | 2.17 |
26 | 2.15 |
27 | 2.12 |
28 | 1.86 |
29 | 1.77 |
30 | 1.72 |
はんドンクラブが認知している外部サーバのアカウント数
rank | サーバ名 | アカウント数 |
---|---|---|
1 | mastodon.social | 12,640 |
2 | mstdn.jp | 10,653 |
3 | pawoo.net | 8,809 |
4 | fedibird.com | 2,522 |
5 | misskey.io | 2,389 |
6 | 非公開 | 1,604 |
7 | mastodon.online | 1,482 |
8 | noagendasocial.com | 1,173 |
9 | poa.st | 1,017 |
10 | mstdn.social | 869 |
11 | sushi.ski | 856 |
12 | best-friends.chat | 761 |
13 | m.cmx.im | 732 |
14 | mastodon.art | 723 |
15 | fosstodon.org | 717 |
16 | chaos.social | 674 |
17 | botsin.space | 642 |
18 | mstdn.maud.io | 568 |
19 | mas.to | 530 |
20 | mastodon.cloud | 524 |
21 | vocalodon.net | 421 |
22 | alive.bar | 390 |
23 | misskey.cf | 372 |
24 | knzk.me | 364 |
25 | vivaldi.net | 362 |
26 | shitposter.club | 341 |
27 | mstdn.guru | 337 |
28 | lesbian.energy | 322 |
29 | kiwifarms.cc | 322 |
30 | freespeechextremist.com | 321 |