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

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

2025年もよろしくおねがいします

こんにちは。はんドンクラブのはんです。

この記事は、 はんドンクラブ2 Advent Calendar 2024 - Adventar 25日目の記事です。（大遅刻）

本来は毎年年末に1年を振り返る記事を投稿しているのですが、今年はあまりの多忙のため、全く記事を投稿する時間を作ることが出来ませんでした。ごめんね。

年が空けてしまいましたので、今年は年始のご挨拶とさせていただだければと思います。

主なイベント

サーバー運営に関連する主なイベントです。

Fediverseからのスパム対応

2024年に最も困った問題はスパムの対応でしょう。はんドンクラブでも多くのユーザーが、他サーバーのスパムからのリプライを受け取ったのではないかと思います。ご迷惑・ご心配をおかけしまして申し訳ございませんでした。

対処したスパムアカウントの数

上記が、2024年1月1日を0としたスパムアカウント（注： 厳密にはスパムではないものも若干含まれている）の増加傾向です。大きな山が3つあり、2月・10月・11月が主な攻撃をうけたタイミングです。

はんドンクラブでは、大きく2段階の対策を行い、全自動で対処できる仕組みを構築しています。

  • 【1段階目】スパムリプライを受ける前の自動除外（全体の約 40%）
  • 【2段階目】スパムリプライを受け取った後にシグネチャによる自動通報＆せいべAIによる自動判定（全体の約 60%）

このシステムは現在も継続して動作しております。ご安心ください。

継続的デリバリー環境の構築

handon.hatenablog.jp

運営業務の負担削減のため、私の念願であった継続的デリバリー（CD）環境の構築が終わりました。金をかければ簡単なのですが、金をかけずにやるのが難しく試行錯誤していたので、かなりの時間を要してしまいました。

サービス全断障害

2024年7月に極めて大きな障害を発生させてしまいました。ご迷惑をおかけし、誠に申し訳ございませんでした。

現在、既に再発防止策は履行済であり、仮に同じ問題が発生しても、私のスマホにアラートが飛ぶようになっています。しかしながらこの仕組みがLINE Notifyに依存しており、2025年3月末にサービス終了予定のため、2025年2月中には別の仕組みに移行予定です。

月次収支報告の開始

月次の収支報告を行うようにしました。といっても、私があまりに忙しすぎて、全然出来ていないので、そのうち頑張ります･･･。

そんななかでもカンパにご賛同頂いている皆様には感謝しかありません。

fantia.jp

データでみるはんドンクラブ

基礎データ

データ名 数字
アカウント数 470
アクティブユーザー数 148
総投稿数 43,761,664
総Fav数 3,300,688
総Bookmark数 16,452
データベースサイズ 43.5GB
メディアサイズ 359GB

投稿数ランキング

順位 投稿数 アカウント作成日時
1 224217 2017-04-16 03:14:45.210683
2 182826 2018-09-26 14:00:24.677902
3 181320 2017-04-19 23:46:20.721773
4 159205 2018-08-17 04:55:36.888916
5 153066 2018-08-15 15:46:57.420607
6 151775 2018-09-26 13:34:53.286009
7 129999 2018-09-06 12:13:56.291501
8 127005 2017-04-14 15:25:19.467587
9 121126 2017-04-15 02:53:53.437558
10 114171 2017-12-10 05:49:59.90627
11 101517 2017-04-15 01:58:28.244079
12 98689 2018-08-21 03:56:48.835622
13 93818 2017-04-15 02:55:00.283981
14 89425 2018-08-27 18:58:03.712292
15 82725 2018-09-09 08:15:49.611543
16 81794 2019-08-16 09:27:18.956742
17 69985 2017-04-15 02:53:10.105472
18 68960 2018-11-19 04:43:11.381105
19 67240 2018-03-21 04:27:47.006326
20 65751 2018-08-23 10:41:04.900378
21 65225 2018-11-19 04:44:53.895617
22 65166 2018-08-16 13:33:57.829532
23 61556 2018-08-16 15:52:19.943946
24 59511 2018-08-18 23:14:00.993394
25 59184 2018-08-17 12:06:59.137676
26 58996 2017-04-15 02:01:39.684488
27 57691 2018-12-13 10:31:57.524099
28 55977 2020-01-04 15:34:32.12934
29 54459 2017-10-07 06:55:04.372879
30 47344 2018-09-25 09:56:10.853888
31 46224 2018-10-19 10:33:06.773122
32 44907 2018-09-05 14:53:38.892203
33 39544 2019-05-28 10:45:38.544188
34 36639 2018-09-19 08:50:05.531581
35 36160 2017-04-25 00:18:49.618914
36 34256 2020-01-04 15:38:40.128898
37 34099 2018-04-04 14:43:53.887628
38 33107 2017-04-15 11:42:27.962394
39 32791 2018-08-16 05:59:16.471888
40 32744 2017-04-25 00:39:02.780603
41 32037 2018-04-08 13:43:48.229188
42 31236 2018-08-15 15:39:00.204377
43 30072 2019-12-14 16:12:36.803644
44 29878 2018-09-23 09:01:46.863769
45 29260 2018-08-18 01:04:57.818141
46 27585 2018-08-16 06:30:05.115409
47 26833 2018-11-02 06:18:31.772157
48 26234 2017-04-22 10:16:53.612031
49 24720 2019-03-04 12:21:16.389625
50 24171 2023-11-17 01:30:47.430285

投稿数の推移

開設日である2017/9/17から2025/1/1までの総投稿数の推移です。 投稿が削除されたものは含まれていません（現在のMastodonでは、自動での投稿削除機能が実装されたことで、投稿の削除がかなり頻繁に発生しています）。

投稿数の推移

ユーザー数の推移

のべ登録ユーザーの推移となります（＝削除されたユーザの数も加算されてしまっています）。 継続的に新規ユーザーにも登録頂いていることがわかります。

のべユーザー数推移

フォロワー／フォローイングの関係性

至極当たり前の傾向なのですが、フォローイングとフォロワーの数には正の相関があります。たくさんフォローしようね。

フォロワー／フォローイング

はんドンクラブが認知しているサーバーごとの利用者数

現時点ではんドンクラブが認知しているリモートサーバー毎のユーザー数ランキングです。 あくまではんドンクラブが認知しているユーザーに限るので、認知していない場合はカウントされていません。

サーバーリスト

おわりに

いかがでしたか？

2024年は私の人生で最も忙しい年でした。理由は2人目の子供が生まれたことです。育児の大変さはまあ2倍くらいになるかな･･･と思っていたら、実際は3倍以上だったんですよね。そのため、正直なところ、はんドンクラブの運営に関する作業はほとんど実施できませんでした。ごめんなさい。しかし今年は、年初よりいくつかのシステム的に重要なアップデートも予定しているので、引き続き頑張りたいと思います。

今年もはんドンクラブをどうぞよろしくお願いいたします。

はんドンクラブを支える技術（継続的デリバリー）

コラム

こんばんは。はんドンクラブのはんです。

はんドンクラブでは、昨年インフラを刷新しました。その目的の一つは、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分程度に抑えることができています。また、軽微なオペレーションミス（例：特定インスタンスのみアップデート作業を忘れてしまう）も防げるようになったと考えています。

運用に関する課題は他にもたくさんあります。継続的な改善に取り組んでいきたいと思います。引き続き、はんドンクラブをよろしくお願いいたします。

*1:正確には、第1期ではDocker、第2期・第3期では非Dockerです。今回の第4期インフラで再Docker化しました

*2:インスタンス数が減っているように見えますが、実際にはフロントエンドに割いているリソースは増えています。バックエンドのプロセスの構成などを変更したため、インスタンス数が少なくて済むようになりました

*3:実際には片方のAレコード/AAAAレコードを削除すれば確実に迂回できるのですが、検証の結果、浸透（浸透って言うなと怒られそう）にかかる時間がよく分からないのと、オペレーション複雑性の観点で、却下していました

*4:restartすれば反映されると思いますが、それでは既存TCPセッションが切れてしまいますので、困ります

2023年末のご挨拶

運営情報 コラム

こんにちは。はんドンクラブのはんです。

早いものでもう年末ですね。そして、はんドンクラブも早いもので、もう7周年が見えてきました。私はプライベートの時間が皆無の状態が続いておりあまりアクティブではありませんが、皆様にはたくさんサーバーを使って頂いてありがとうございました。

今年を簡単に振り返って、年末のご挨拶とさせて頂ければと思います。来年も引き続きよろしくお願いします！

主なイベント

  • 2023/1中: 画像サーバーの障害と構成変更
    • クラウド事業者側の問題で画像のアップロードができない問題がありました。そもそも、以前からアップロードが遅いという問題があったので、思い切って構成変更して、パフォーマンスもアベイラビティも向上しました。
  • 2023/2/6: 利用規約の更新
  • 2023/2/11: 4.1.xへのメジャーアップデート
  • 2023/5/29〜2023/6/2 : 外部との接続が不安定な障害が発生
    • クラウド事業者側の問題で一時的に外部との接続が不安定でした（技術者向け: クラウド事業者内部のDNSキャッシュサーバーの応答が著しく遅くなっていました）。
  • 2023/7/6: セキュリティ脆弱性対応
    • Mastodonのソフトウェアに脆弱性が発見され、速やかなアップデートが必要でした。
    • はんドンクラブでは、修正は公開当日に完了しました。（技術者向け: CVE-2023-36460 / CVE-2023-36459）
  • 2023/8/29: サーバー移転
    • サーバーをさくらVPSからVultrに移転し、構成を大幅に変更しました。
    • 詳しいことはここには書きませんが、構成変更により以下の3点を達成しました。
      1. コストの最適化
      2. アップデート作業の大幅な短縮
      3. EoL（End-of-Life: 古いソフトウェアの保守期限が切れ、今後セキュリティアップデートが行われなくなること）の対応

（技術者向け）構成の変更

  • 2023/8/29 - 2023/9/5: ストリーミングが不安定な問題が発生
    • 事前検証不足によりご迷惑をおかけしました。
    • 詳しくは障害報告をご確認ください。handon.hatenablog.jp
  • 2023/9/23: セキュリティ脆弱性対応
    • Mastodonのソフトウェアに脆弱性が発見され、速やかなアップデートが必要でした。
    • はんドンクラブでは、修正は公開3日後に完了しました。（技術者向け: CVE-2023-42451 / CVE-2023-42452）
  • 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) により事象が完全に回復したと判断、ユーザ周知

結果的にサービス影響は以下のとおりとなります。

  1. 全く使えない状態（サービス停止状態）
    • 合計3時間55分
    • 8/29 23:04〜8/30 0:13の1時間9分、9/5 06:16〜9/5 09:02の2時間46分
  2. 定期的にサービスが使えなくなるものの、数分以内に自動的に再接続が行われる状態（サービスデグレ状態）
    • 合計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。ちょっとエッチな画像を一時的に隠して投稿できる。
  • カスタム絵文字: 管理人が登録した特殊な絵文字。そのサーバーに属している人なら誰でも使える。他のサーバーの人は使えないけど、あなたの投稿で使われたカスタム絵文字は見ることができるので、気軽に使ってみよう。

もっと深く知りたい！

まきはらさんのとてもわかりやすいまとめです。この記事との重複もありますが、ぜひどうぞ。

prgm.x0.com

はんドンクラブでは、他のMastodonサーバーにない独自機能を実装しています。詳しくはこちらをどうぞ。

handon.hatenablog.jp

*1:正確には、現在はトゥートという表記は正式ではなく、「投稿」「ポスト」と呼称します。ただ、古い表記である「トゥート」を使うユーザーが多いです。

*2:分散SNSの仕組み上、全てのユーザーを全てのサーバーが知っている訳ではありません。例えば、誰一人としてフォローしていない別のサーバーのユーザーは、そもそも自分の所属サーバーから存在を認知できません。その場合は、連合タイムラインには流れません。

*3:正確には、現在はインスタンスという表記は正式ではなく、「サーバー」と呼称します。ただ、古い表記である「インスタンス」を使うユーザーが多いです。

はんドンクラブの利用規約を変更します。

Mastodonの新しいシステムに対応するため、利用規約を更新します。 意図を変えているつもりはありませんが、文章構造が変わっているため、内容をご確認ください。

＊＊2023/2/4 追記 何ヶ所か微調整を行い、期限を延長しました。＊＊

  • プライバシーポリシーに更新はありませんので、このページからは記載を省略しています。
  • Mastodonのシステムの都合上、「利用規約」を「サーバーのルール」と言い換えます。
  • 不安な点があれば、2023/2/62023/2/11までにお問い合わせください。問い合わせが無ければ、2023/2/72023/2/12以降に本サーバーのルールを適用します。

更新のポイント

  • 規約の構造を修正しました。
    • 利用者に守って頂く必要がある事項のみ、"サーバーのルール" に記載することにしました（通報時、このルールを選択する必要があるためです）。結果、他の免責事項などの利用規約は "その他" に移動しました。
    • その他、文意が変わらない範囲で、段落を組み替えました。
  • 「みんな仲良くしてください。」の意図を明確にしました。
  • 細かな文言修正を行いました。
    • 「Mastodonインスタンス」を「Mastodonサーバー」へ変更しました。
    • 「サーバー」「サーバ」や「ユーザー」「ユーザ」などの表記揺れを修正しました。

更新後

Mastodonサーバーのはんドンクラブ（以下，本サービス）をご利用いただく場合，以下の「サーバーのルール」と「プライバシーポリシー」の両方に同意するものとします。

サーバーのルール

サーバーのルールに概要を記載しています。このページでは，補足を含め，ルールの原本を記載します。

1. みんな仲良くしてください。

「馴れ合いましょう」という意図ではありません。「能動的に仲を悪くする行動をしないでください」という意図です。嫌な人・投稿を見つけても，まずはブロックやミュートを活用し，自衛してください。他人に思想や行動を強いないでください。

2. 法または道徳に反する投稿はやめてください。

特に，自身が権利を有している，または適切な同意を得ているもののみ投稿してください。

3. 投稿画像や動画には，必要と認める場合は閲覧注意フラグを付与してください。

基準は皆さんの良心にお任せします。閲覧注意フラグが付いていれば，投稿内容画像や動画の制限は行いません。ただし，法に前項の規定に反する場合はこの限りではありません。

4. サーバーに過度な負荷をかけないでください。

常識的な利用（サードパーティー製クライアントの利用，多重接続，実況，動画投稿などを含む）は問題ありません。botによる大量の反復動作など，機械的かつ非常識的な利用はやめてください。

その他

  • 本サービスを利用したこと，および利用できなかったことによる損害は，いかなる場合も補償しません。
  • 投稿内容の著作権等の権利は，いかなる場合も投稿したユーザーに帰属します。
  • サーバーのルールに反する場合など，管理人が必要と判断した場合は，発言投稿またはアカウントの削除を行うことがあります。
  • サーバーのルールは以下を全て満たす場合改定できるものとし，改定後も本サービスを継続利用しているユーザーは新たなルールにも同意したとみなします。
    • 新たな規約案は適用1週間以上前に掲載し，広く意見を求めます。
    • 掲載は分かりやすい複数の方法で行います。

更新前

Mastodonインスタンスのはんドンクラブ（以下，本サービス）をご利用いただく場合，以下の「サーバーのルール」と「プライバシーポリシー」の両方に同意するものとします。

  • 1. みんな仲良くしてください。
  • 2. 法または道徳に反する投稿はやめてください。
    • 投稿内容は，投稿者が著作権等の権利を有している，または適切な同意を得ているものにしてください。
  • 3. 投稿画像や動画には，必要と認める場合は閲覧注意フラグを付与してください。
    • 基準は皆さんの良心にお任せします。
    • 閲覧注意フラグが付いていれば，投稿内容の制限は行いません。ただし，法に反する場合はこの限りではありません。
  • 4. 安定運用のため頑張りますが，万一全てが吹っ飛んでも泣かないでください。
    • 本サービスを利用したこと，および利用できなかったことによる損害は，いかなる場合も補償しません。
    • 管理者は，運営ガイドラインに従った運営を行います。ただし，本ガイドラインは都度改定できるものとします。
  • 5. サーバに過度な負荷をかけないでください。
    • 常識的な利用（サードパーティー製クライアントの利用，多重接続，実況，動画投稿などを含む）は問題ありません。
    • botによる大量の反復動作など，機械的かつ非常識的な利用はやめてください。
  • 6. 利用規約に違反している場合，その他管理人が必要と判断した場合は，発言またはアカウントの削除を行うことがあります。
  • 7. 投稿内容の著作権等の権利は，いかなる場合も投稿したユーザに帰属します。
  • 8. 利用規約は以下を全て満たす場合改定できるものとし，改定後も本サービスを継続利用しているユーザは新たな規約にも同意したとみなします。
    • 新たな規約案は適用1週間以上前に掲載し，広く意見を求めます。
    • 掲載は分かりやすい複数の方法で行います。

はんドンクラブの運営について

サーバーのルール・プライバシーポリシー

プライバシーポリシー - handon.club

運営ガイドライン

管理人は，はんドンクラブを，以下3つの基本方針（「運営ガイドライン」と呼称します）に従い運営するよう努めることとします。

インフラ運用

安定運用を第一に，常時監視，データの定期バックアップ，各種作業時の検証環境による事前テスト等を行います。運用状況は可能な限りオープンにします。Mastodonの新バージョンにいち早く追従するため，ソースコード改変は最小限にします。

モデレーション

サーバブロックやアカウント停止は必要最低限とし，その内容や理由は運営やプライバシーに支障が無い限りオープンにします。通報についても，真に必要な場合のみ対処を行います。ユーザーのプライバシーを最大限尊重します。

コミュニティ

サーバ内での話題，フォロー関係，イベントやオフ会等については、サーバ管理人が管理するところではないため，特に制限しません。

また，上記運営ガイドラインに従うための具体的なアクションとして，ユーザへの注意喚起事項や実際の運営方法など（「運営に関する情報」と呼称します）を別途定めることとします。

運営に関する情報

運営に関して，必要と思われる情報をまとめたものです。管理人の意向により周知なく改定されることがあります。

管理人へのリクエスト方法

記載の無い内容で管理人へリクエストが必要な場合は、お気軽にリプライ・ダイレクトメッセージ等でご連絡ください。

レポート（スパム報告）

レポートには理由をできる限り詳細に記載して下さい。記載頂いた理由のみから客観的に判断し，処置を検討します。なお，すべてのレポートは公開される場合がある旨はご了承下さい。より詳細な事項については， 「通報」機能についてのお願いをご参照ください。

handon.hatenablog.jp

カスタム絵文字の追加

以下の条件をすべて満たす画像であれば登録を受け付けています。管理人まで個別にリプライまたはダイレクトメッセージでお申し出ください。

  • ルール： 「法に反しない」「公序良俗に反しない」
  • フォーマット： 「アスペクト比（画像サイズの縦横比）1:1」「透過png形式」「サイズ50KB以下」

アカウント削除

ユーザ設定画面からのアカウント削除は，技術的な理由により無効にしています。アカウント削除をご希望の方は，管理人まで個別にリプライまたはダイレクトメッセージで申し出てください。原則3日後までの深夜帯に処理します。

ただし，分散型SNSの性質上，他サーバへ配送済の投稿を全て削除することは保証できません。これは，はんドンクラブから連合している全てのサーバへ削除要求を送ったとしても，そのサーバが確実に削除するかどうかを掌握できないためです。管理人はユーザの"忘れられる権利"を最大限尊重し，個人運営サーバとして現実的に可能な範囲での努力を行いますが，連合先サーバでのデータ削除保証はできないことをあらかじめご承知おきください。

権利侵害の報告，情報開示請求

権利侵害の申告，法令等に基づく情報開示請求，警察・行政機関等からの問合せについては，Google Formでご連絡ください。

はんドンクラブの特徴

ユーザーの新規登録，ユーザの招待

はんドンクラブは招待制インスタンスです。招待は，はんドンクラブにアカウントをお持ちの方であれば，誰でも可能です。設定画面の「新規ユーザーの招待」よりURLを発行してください。利用規約を遵守出来る方であれば，招待する人にも人数にも制限はありません。

また，招待が無くても登録できる「承認制」も採用しています。意気込みを記載の上，登録申請をしてください。管理人の独断により承認可否を決定することをご了承ください。

独自機能

以下の記事でまとめていますので，よろしければご一読ください。

handon.hatenablog.jp

カスタムテーマ

以下のカスタムテーマを採用しており，誰でも設定で有効にできます。

ソースコード

mastodonの公式リポジトリのソースコードをupstreamとし，一部独自に改変したコードが動いています。upstreamへの追従は，原則として正式なreleaseまたはpre-releaseへの追従のみとし，いわゆる"main追従"は可能な限り行いません。実際に動作しているコードについては，github で公開しており，独自部分もgithub上のcompareページで確認可能です。

マスコットキャラクター

「ドン美ちゃん」 ドン美ちゃん をよろしくお願いします。

  • アカウント： @donmi
  • 誕生日： 4月14日
  • 好きなもの： ヤクルト400LT
  • カスタム絵文字： :donmi:

運営状況

運営情報の発信

メンテナンスなどのサーバ公式情報は，以下のいずれかの方法で発信します。なお，やむを得ず予告なくメンテナンスを実施する場合もございますので予めご了承ください。

  1. HTL上部の「お知らせ」欄
  2. https://status.handon.club/
  3. このブログ
  4. ハッシュタグ #handon_info

運営費用

このサーバは各種クラウドサービスを使って運営されています。クラウドサービスには月額で費用が発生するため、以下ページで月額制でのカンパを募集しています。

ファンティア[Fantia] - はんドンクラブ (はん)

なお，カンパは決して強制ではありません。もちろん，「カンパをしていないから〇〇をしてはいけない」ということもありません。

実際にカンパをいただいた方のお名前は、 このサーバーについて - 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万トゥート達成