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

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

2021年もはんドンクラブをよろしくお願いします

こんにちは。はんドンクラブ管理人のはんです。昨年中も大変お世話になりました。寄附を頂いた方,友人を誘っていただいた方,イベントを企画していただいた方,たくさんトゥートしていただいた方,様々な方法でコミュニティを盛り上げようとしてくださった方,みなさまに感謝します。使っていただくのが一番嬉しいですが,はんドンクラブがきっかけで交友関係が広がったという話を聞くのも嬉しいです。2021年も引き続きはんドンクラブをよろしくお願いします!

本当はこの記事は大晦日に投稿しようと思っていましたが間に合わなかったので,新年の挨拶に代え,2020年のはんドンクラブ運営の振り返りをまとめてみたいとおもいます。なんども同じことを言いますが,これは決してコミュニティのまとめではなくて,運営のまとめですのでご理解ください。

アップデート

2020年の元日はバージョン3.0.1で迎えたようです。2021年の元日は,前日にアップデートした3.3.0で迎えましたので,メジャーバージョンアップはなかったのですね。とはいえ,様々な新機能が追加された1年だったかと思います。公式側で追加された機能について述べても仕方ありませんので,ここではそれ以外の話をしたいと思います。

公式へのコントリビューション

2020年はcommitは1件だけ,issueは2件でした。

github.com

CORSの件,切り分けにかなり苦労したのを覚えてます。無事Suggestionが認められリリースノートに反映してもらえたので,他の鯖缶の皆さんに貢献できたのではないかと思います。とはいえ,まあもうちょっとコントリビュートしたかったですね。

参考までに昨年のcommitは以下の2件だったようです。

独自機能の追加

2020年はどちらかというと独自機能の開発が多かった気がします。今年実装した機能を以下の通り紹介します。

InstanceTicker

miy.pw

これは独自機能ではありませんが・・・。マストドン界隈では有名なプラグインのひとつInstanceTickerテーマを追加し,選択できるようにしました。機能の詳細は miy.pw を参照ください。はんドンクラブで利用したい場合は,ユーザ設定の外観から,サイトテーマを変更してください。私は普段有効にしています。

f:id:highemerly:20210101234410p:plain:w300

f:id:highemerly:20210101234723p:plain

トゥートの公開範囲の表示変更

handon.hatenablog.jp

これまではんドン独自で実装していた機能に相当する機能が公式側にも実装されたため,はんドン側の仕様も変更しました。公式との差分は色を変えただけですが,非収載やDMがより見やすくなるようにしています。詳細は上記ブログを参照ください。

スタンプ機能

f:id:highemerly:20210101233934p:plain:w300

「カスタム絵文字が1つだけ投稿されたときにすごく大きく表示する機能」のことです。これまでもそれっぽいものを実装していたのですが,微妙だったので,2020年にちゃんと直しました。実はCSSだけでは実装できないので,Rails側に手を加えています。私としては結構お気に入りの機能です。

アイコン絵文字(プロフィール絵文字)

f:id:highemerly:20210101234045p:plain:w300

イコン画像を絵文字にする機能を実装しました。ずっとやりたかった機能です。といっても中身は bestfriends のforkです。ショートコードとして「 :@highemerly: 」のように記載すれば利用できます。他サーバの人のアイコンも使えます。

実は,bestfriendsなど他のサーバでよく使われているコードでは,クライアントで見たときにアイコン絵文字が表示できない仕様になっています。要するにアイコン絵文字専用のAPIを作っているんで,Webでは問題ないものの,クライアント側の追加対応が必須なんですね。しかしはんドンクラブでは,クライアント〜サーバ間の処理を通常のカスタム絵文字と全く同じ処理に偽装しています。そのため,はんドンクラブのユーザについては,クライアントから見たときでもアイコン絵文字が表示できるはずです。

DMのHTL非表示機能

handon.hatenablog.jp

年末に実装しました。3.3.0からDMをHTLに表示する仕様になったのですが,私はこれが嫌いなので,ユーザが選択できるようにしました。詳細は上記ブログを参照してください。

だいたいこんな感じでしょうか。なお,はんドンでソースコードをいじっている部分については,以下ですべて確認できます。

github.com

その他

公式イベントとしては,オフ会は流石に実施できなかったものの,オンライン上でアドベントカレンダーの企画を行いました。かなり盛り上がってくれて嬉しかったです。

はんドンクラブ Advent Calendar 2020 - Adventar

まだ読んでない方は是非読んでみてくださいね!みなさん個性的な記事を書いていただいています。

統計情報

トゥート数推移

f:id:highemerly:20210101185513p:plain
トゥート数推移

毎年恒例の総トゥート数推移です。今年は総合200万トゥートを達成しました。1日の平均トゥート数も,2018年8月のTwitter APIの仕様変更で急増したまま,そこまで変化はないようです。一部,2019年の前半あたりに赤の線の傾きが増えてるのですが,まあこれは一時的なものかなと思いますので…

トゥート数ランキング

f:id:highemerly:20210101185534p:plain
アカウントごとのトゥート数(トゥート数ランキング)

みんな大好きトゥート数ランキングです。横軸は順位を、縦軸は12/31時点のトゥート数を示しています。10万トゥート越えの方は現時点で2名のようですね。また、割と頻繁にトゥートしていないとなかなか到達しない1万トゥート越えの方も60名弱いらっしゃるようです。多くの方にアクティブに使っていただいているようで素直に嬉しいです。

f:id:highemerly:20210101185246p:plain
登録日ごとの総合トゥート数

はんドンクラブへの登録日ごとにトゥート数をマップしてみました。そもそも登録日にだいぶ偏りはありますが,昔から使っていただいている方も,比較的最近使い初めていただいた方もいるようですね。これ誰だ?って気になるプロットもありますね…

公開範囲

f:id:highemerly:20210101185712p:plain
投稿の公開範囲の推移

公開トゥートってどれくらいあるんだろう?と思ったので,統計を取ってみました。1日単位で、はんドン内の全トゥートに占める公開範囲の割合を表してます。今年に入って非収載の割合が増えました。いまは公開以外のトゥートが半分以上を占めてそうですね。

なお、LTLに表示されるのは「公開トゥートかつリプライでないトゥート」なので、公開だからといって全てがLTLに現れてるわけではない点は注意ください。

認知しているアカウント数

他のサーバの認知しているアカウント数は以下の通りです。200アカウント以上のものを表示しています。認知しているというのは,はんドンクラブのユーザがフォローする・されているアカウントだけでなく,ブーストで流れてきたりしたアカウントも含まれます。

サーバ名 アカウント数
mastodon.social 8,725
pawoo.net 7,655
mstdn.jp 7,403
misskey.io 740
best-friends.chat 690
mstdn.maud.io 513
mastodon.art 472
fedibird.com 461
baraag.net 433
mastodon.cloud 392
knzk.me 364
mastodon.online 316
mstdn.beer 282
mstdn.guru 279
cybre.space 279
gab.com 252
imastodon.net 229
mastodon.technology 225
octodon.social 219

2019年の振り返りの記事のデータと比較すると、misskey.ioが急増しましたね。その他はそこまで変動ないんじゃないかとおもいます。

その他

DB容量がなかなかに肥大化してきました。まだまだ全然余裕ですが。

項目
登録ユーザ数 243アカウント
認知ユーザ数 53,821アカウント
認知サーバ数 4,026サーバ
総合トゥート数 2,114,723トゥート
DB容量 18.1GB
画像サーバ容量 149.1GB

なお、画像サーバの容量推移は以下の通りです。

f:id:highemerly:20210101191004p:plain
オブジェクトストレージの利用容量推移

終わりに

ということで,つらつらと書きましたが,今年もはんドンをよろしくお願いします! ということが言いたいだけです。

使い方はもちろん自由ですし,疲れた時はお休みくださいね。私も,安定運用とセキュリティ担保はもちろん,面白い企画立案や便利な機能開発ができるようがんばります。トゥートもたくさんしようと思います!それでは。

3.3.0にアップデートしました【DM表示方法について】

はんドンクラブは3.3.0にアップデートしました🎉

  • 3.2.1→3.3.0へアップデートしました
  • アップデートに伴うサービス停止時間は,全サービス停止が41分53秒(検索機能は1時間1分4秒)でした
  • 3.3.0がリリースされてから4日かかりました

リリースされてからアップデートまで時間を要してしまい申し訳ありません。

機能追加された点

3.3.0のアップデートに伴い機能追加された点は以下の通りです。

  1. WebUIの画像の拡大表示UIがより操作しやすくなりました #15068
  2. WebUIで動画/音声を再生中に画面外までスクロールすると右下にポップアウト表示されるようになりました #14870
  3. WebUIの通知バーで未読管理できるよう未読の通知の左側にマーカーが表示されるようになりました #14818
    • ちなみに未読管理自体は内部のDBで管理されており,API取得も可能です。クライアントが対応していればWebUIとクライアントの未読管理は同期可能です。
      f:id:highemerly:20201231121823p:plain:w300
      未読の通知には左側に青色のバーがついています。
  4. ブックマークしたトゥートのインポート・エクスポートに対応しました #14956
    • トゥート含め,https://handon.club/settings/export からエクスポートできます。サーバに非常に高い負荷がかかるため,必要な時にのみエクスポートをお願いします。
  5. 特定のユーザがトゥートした際に通知を受け取ることができるようになりました #13546
    f:id:highemerly:20201231122519p:plain:w320
    ベルのマークを押して通知をオンにするとトゥートしたときに通知が届くようになります!
  6. ストリーミングに関わる大きな実装変更がありました #14524
    • ユーザのみなさんはあまり意識する必要はありませんが,今回のバージョンにおける最も大きな変更なので挙げておきました。効率があがったと思っていただければ。
  7. 削除したトゥートは他のサーバ(リモートサーバ)側でも削除されるべきですが,これがより確実に削除できるような実装変更がありました #15200

その他は公式リポジトリを参照してください。

今回併せて実施したメンテナンス

  1. サーバのホストOSをCentOS 7.8.2008 → 7.9.2009にアップデートしました
  2. Elasticsearchを6.8系から7系(7.10.1)にアップデートしました
  3. その他一部ミドルウェアのバージョンアップを行いました

DM表示方法について(はんドン独自機能)

Mastodon公式リポジトリ(tootsuite/mastodon)では,このバージョンから,ダイレクトメッセージ(DM)をホームタイムライン(HTL)上にも表示させるようになりました。しかし,私はこの変更があまりにも嫌すぎるのと,みなさんの意見を聞いていてもやっぱり嫌なようだったので,対処を行うこととしました。

具体的には,DMをHTLに表示させるかさせないかをユーザごとに選択できるようにしました。

f:id:highemerly:20201231123530p:plain

初期設定ではチェックが入っています。つまり,「DMをHTLに表示させない」,すなわち3.2.xまでの動作を引き継ぐようにしました。このままがよい方は変更する必要はありませんが,もし公式リポジトリと全く同じ動作を希望されるかたは,上記画像に従って設定を変更してください。下のようにタイムライン上に表示されます。

f:id:highemerly:20201231123656p:plain:w300

Webにおける細かな仕様は以下のとおりです。

チェックする チェックしない
自分の送ったDMがHTLに 表示されない 表示される
自分の送ったDMが通知欄に 表示されない 表示されない
自分の送ったDMがDM欄に 表示される 表示される
他人から受け取ったDMがHTLに 表示されない 表示される
他人から受け取ったDMが通知欄に 表示される 表示される
他人から受け取ったDMがDM欄に 表示される 表示される

繰り返しですが,

  • 公式準拠の場合・・・ 強制的に「チェックしない」の動作となる
  • はんドンの場合・・・初期設定は「チェックする」の動作となる。ユーザが希望すれば「チェックしない」の動作も選択可能。

です。

なお,クライアントをご利用の方も基本的には同様の表示となることが予想されますが,実際はクライアントの実装に依存します。今回はAPIをいじっている*1ので,Web側もクライアント側もどちらにも設定が反映されてます。

注意点です。この機能は独自で開発した機能です。十分なテストを行っていますが,一部動作不良がある可能性があります。DMを取りこぼさないようにDMはDM欄で見てくださいね。また,設定を変更した際は,基本的に設定が変更された後のDMに新しい設定が適用されますが,一部過去に遡って適用される場合もあります(条件はややこしいので書きません)。要するに頻繁な設定変更は強くおすすめしません。

*1:WebのみCSSで非表示にすることで対応するか,Webでもクライアントでも対応できるようAPIをいじるかは相当悩みました。しかし,クライアントをメインで使っているみなさんにもこの機能を使ってもらいたかったので,APIをいじることにしました。

3.2.0アップデートに伴うトゥートの公開範囲の表示方法変更について

こんばんは。アップデートの度に記事を書くのが面倒になって辞めてしまった,はんドンクラブ管理人のはんです。

はんドンクラブでは先ほど3.2.0rc1にアップデートをしましたが,はんドンクラブ独自仕様に関わる重要な仕様変更が行われましたので,この記事にてみなさんに周知したいと思います。

変更の理由は,本家のソースコードで行われた変更に起因するものです。この変更が従来のはんドンクラブ独自仕様と干渉するような内容でして,独自仕様を変更する必要が発生しました。

変更内容

Webにおけるタイムライン上のトゥートの公開範囲に関わる表記が変更となります。具体的には,非収載トゥートおよびフォロワー限定トゥートの表記方法(識別方法)が変更になります。右肩に鍵マークが付くようになります。

なお,クライアントを利用する場合には影響ありません。

非収載トゥート

  • Before(これまで)

f:id:highemerly:20200716232821p:plain
これまで・非収載

  • After(これから)

f:id:highemerly:20200716233636p:plain
これから・非収載

フォロワー限定トゥート

  • Before(これまで)

f:id:highemerly:20200716232850p:plain
これまで・フォロワー限定

  • After(これから)

f:id:highemerly:20200716233713p:plain
これから・フォロワー限定トゥート

変更の経緯

もともと,Mastodonでは,タイムライン上で公開トゥートと非収載トゥートの区別が付きませんでした。そこではんドンクラブは,独自仕様として「ブーストボタンに斜線を付与することで非収載トゥートであることを明示する」こととしていました。しかし,この点には問題がありました。それは,本来非収載トゥートはブースト出来るのにもかかわらず,あたかもブーストできないかのような印象を与えていたことです。

一方最近,本家ソースコードにおいて,トゥートの公開範囲を明示するような修正がマージされました。本家でも公開トゥートと非収載トゥートの区別が付くようになったのです。

github.com

そのためはんドンクラブでは,非収載トゥートのブーストボタンに斜線を付与する独自の変更を辞めました。前述の通り,非収載トゥートはブースト可能であるので,わざわざわかりづらい表示をする必要はないと判断したためです。ただ,フォロワー限定トゥートにブーストボタンが表示されるようになったので,そこには独自仕様として斜線を付与してみました(このコミットによりブースト可否がボタンの濃淡だけで表現されるようになったため,その分かりづらさを解消するためです)。

おまけ

関連するコミットをプルリクしてマージされました。

github.com

データの可用性・バックアップポリシーについて

こんにちは。運営ブログの更新が滞っている、はんドンクラブ管理人のはんです。たまには何か書こうと思い立ちました。

この記事では、はんドンクラブにおけるデータの可用性ポリシーについてまとめておこうと思います。可用性(アベイラビリティ)とは、システムを故障なく継続して動かせる能力のことです。ただ、はんドンクラブを構成するすべての要素の可用性について書くのはとても大変です。そこで今回は、特に重要なデータベースの可用性、特にバックアップのポリシーについてご紹介したいと思います。

はんドンクラブの利用サービス

はんドンクラブでは、サービス開始当初から、「私の家にサーバを設置する構成(オンプレ構成)は取らない」というポリシーを貫いています。様々な理由がありますが、一番の理由はセキュリティです。オンプレ構成の場合、データ漏洩リスクとして「私の家に強盗が入る」「私の家に来た友人が不正を働きデータを盗む*1」ことを考慮しなくてはならず、設計や運用の負担になることが予想されます。

もちろん、可用性の向上という観点でも、クラウドサービスを使う利点はあります。残念なことに私はデータセンターには住んでおりませんので、家庭向けインターネットアクセス回線や家庭向け商用電源の可用性を考慮しなくてはなりません。面倒すぎます。

さて、前置きが長くなりました。利用しているクラウドサービスの可用性について考えたいと思います。はんドンクラブでは主に以下のサービスを利用しています。

このうち、データが保管されており、データという観点で可用性を考慮する必要があるサービスはさくらインターネットGMOの2つです。いずれも日本国内に設置されたサーバのみを利用しており、十分な可用性が担保されていると認識しています。そのため、そもそもこれらのサービスを利用している時点で、不意の故障に起因する可用性の低下について神経質に考える必要はないというのが実情です。 ここで、不意の故障とは、電源喪失やネットワーク切断などインフラ面の故障を指しています。

さくらのVPSの特長|VPS(仮想専用サーバー)はさくらインターネット

オブジェクトストレージ|VPSならConoHa

とはいえ、これはあくまで設備故障に起因する可用性の話です。私のオペレーションミス、ソフトウェアのバグに起因したデータロストなど、ソフトウェア的なリスクは考慮すべきです。このリスク軽減のためには「定時の自動バックアップ」が有効です。以後はデータのバックアップについて考えていこうと思います。

Mastodonの主なデータ

そもそもMastodonで記録されるデータは、その保存先によって、以下4つに分類されます。

保存先 データの内容
PostgreSQL トゥート、フォロー関係、個人設定など
オブジェクトストレージ メディアファイル、アイコン画像など
redis キャッシュ(各個人のタイムラインなど)
Elasticsearch 検索インデックス

当然、すべてのバックアップを取得しておくのが望ましいです。しかし、当然それなりの費用がかかります。そこで、はんドンクラブでは、redisとElasticsearchについてはバックアップの取得は不要だと判断し、一旦考慮の対象から除外しています。理由は、万が一の故障が発生しても、再生成可能なデータが多いからです。

redisの中の最も重要なデータの一つである各ユーザのタイムラインは、いざとなれば以下コマンドで再生成できます。

$ RAILS_ENV=production bundle exec bin/tootctl feeds build

なお、redisには、タイムライン以外の情報も含まれています。しかしながら、それはあくまでキャッシュデータです。大半はPostgreSQLのデータから復旧可能ですし、そうでない情報もあくまで処理速度向上などにしか用いられません。

ElasticSearchについても同様です。PostgreSQLのデータさえ残っていれば、以下コマンドで復旧できます(ものすごく時間かかりますが・・・)。

$ RAILS_ENV=production bundle exec bin/tootctl search deploy

ここまでの説明で、PostgreSQLとオブジェクトストレージのデータバックアップが可用性担保に重要であることをご理解頂けたと思います。次は、これら重要なデータのバックアップについて考えたいと思います。

バックアップルール

PostgreSQL

2020年6月現在、以下のルールで運用しています。

  • 1日2回のフルバックアップを自動で取得する。
    • 2回のうち1回は、データベースサーバのローカルに保管する。
    • 2回のうちもう1回は、地理的に離れた別サーバへ保管する。
    • 自動バックアップは5世代分(=約3日間分)保管し、その後は自動で削除する。
  • ソフトウェアアップデートの際にDBマイグレーションが走る場合は、フルバックアップを手動で取得する。

特に、「地理的に離れた」サーバへの保管については、さくらインターネット自体の故障リスクを考慮しない場合は不要なはずです。これは、仮にディスクの枯渇を考慮*2しても、同じロケーションの別サーバに保存さえしておけば、可用性が担保できるはずだからです。冒頭に言ったことと矛盾していますね。

このリスクを考慮しているのは、PostgreSQLのデータが大変重要であるためです。このデータが吹き飛べば、サービス継続はほぼ不可能です。そのため、さくらインターネット側の故障や、大規模な自然災害が起きた場合でも迅速にデータを復旧できるようにするための工夫をしています。具体的には、現在PostgreSQLが設置されているのは東京都内ですので、毎日大阪府内へのバックアップデータ転送を行なっています。

オブジェクトストレージ

2020年6月現在、特段バックアップをしていません。メディアファイルのバックアップは非常に費用がかかるためです。

しかし、アカウントのアイコン、カスタム絵文字など、特にサービス継続に重要なメディアファイルについては、自動バックアップできる仕組みを整えようと考えています。そのために、現在、OpenStack Swiftの仕様を頑張って調査しています。そのうちバックアップできるようにしたいです。

復旧のポリシー

データの可用性を担保するためには、バックアップだけ取っていればいいというわけではありません。有事の際、迅速かつ確実な復旧を行う必要があります。インフラエンジニアあるあるですが、「バックアップを取っていたつもりだったが実は取れていなかった」という事態はなんとしてでも避けなくてはなりません。

そこで、PostgreSQLのバックアップデータについては、過去1度、バックアップデータからの復旧訓練を実施しています。その際には、手順の確認に加え、全データが復旧できたことを確認しました。

また、故障を発見してから復旧作業が完了するまでの目標時間とその方法は、以下のとおり定めてあります。

  • ソフトウェア不具合やDB不整合などDBのデータのみ故障した場合
    • 復旧目標: 20分
    • 最新のバックアップを挿入することで復旧
  • ディスク枯渇などでDBサーバ自体が故障した場合
    • 復旧目標: 2時間
    • 新たにサーバを立ち上げることで復旧
  • DBサーバを含むさくらVPS東京リージョンがすべて故障した場合
    • 仮復旧目標: 2時間、復旧目標: 3日
    • 一旦開発系として利用しているAWSを利用して仮復旧させ、その後別のクラウドサービスを用いて本格復旧
  • 大規模災害等で東京中のインフラが壊滅状態の場合
    • 復旧目標: 3日
    • 大阪に設置されているクラウドサービスで復旧

勘の良い方はお分かりかと思いますが、復旧目標が「2時間」に設定されているのは、総務省総合通信局への四半期報告を行わなくていいようにするためです*3*4。とはいえ、個人の運営サービスである以上、すべてのパターンの故障時に2時間以内の復旧ができるようにすることは考えていません。それはやりすぎです。

今後の課題

PostgreSQLのデータ肥大化に伴い、フルバックアップを取得することが負荷に繋がっている可能性があります。現在は pg_dump コマンドでのバックアップ取得をしていますが、実際はほぼ参照されない古いデータも総なめしてしまいます。つまり、PostgreSQL最適化の仕組みであるキャッシュを壊滅させているのではないかと思っています。

PostgreSQLアンチパターン:運用DBのpg_dump - Qiita

しかし、正確な影響の度合いはまだできていません。そもそも、ホットバックアップの場合、よく知られた代替手段は存在しないと思ってます(常時レプリケーションを行い、レプリケーション先でバックアップを取得すればいいのでしょうが、費用がかかりすぎます)。影響度合いと手間・費用を天秤にかけて、継続検討していきたいです。

  • オブジェクトストレージのバックアップ

本文中でも述べた話です。

ConohaのオブジェクトストレージはOpenStack Swiftに準拠しています。OpenStackを触らなくなってもう3年、、ほぼ知識がない技術領域です。その特性や仕様をきちんと理解した上で、バックアップの必要性有無については継続検討します。

  • redis

本文中でredisはバックアップ不要だと言いましたが、実際にはバックアップしたいデータも含まれています。特に、応答しなかったリモートサーバ一覧のキャッシュは、サービスの安定運用に必要なものです。優先度は低いですが、余裕ができれば考えていきたいです。

おわりに

長文となりましたが、はんドンクラブにおける可用性設計について、私の備忘録を兼ねてまとめてみました。

大事なことは、コスト・影響度合い・発生確率を考慮したリスクマネジメントをすることだと思っています。何がなんでも考慮していては、どこかに無理が生じ、実運用に支障をきたすことが考えられるためです。

また、バックアップを取っているだけでは不十分で、どういう時にどのバックアップをどのタイミングで復旧させるのか、あらかじめ決めておき訓練しておくことも大事だと思います。このあたりは引き続き検討し、改善に努めたいと思います。

*1:そんな友人はいないと思っていますが、リスクマネジメントとして考慮しなくてはならないという意味で記載しています。

*2:ディスクの枯渇が起こらないよう5分間隔で監視しており、そのリスクがある場合には管理人と副管理人の2人に警報が飛ぶ仕組みになっています。そのため、枯渇は起きるリスクは実際には低いです。

*3:はんドンクラブでは、近畿総合通信局に、個人の届出電気通信事業者として届出を行なっています。

*4:実際には私が故障に気づくまでの時間を含んで、ユーザへの影響時間が2時間以内である必要があります。しかし、原則5分以内に気づけるようになっているので、仕事中など即時対応できる状況であれば誤差の範囲です。

2019年はんドンクラブ運営の振り返りと年末のご挨拶

こんにちは。はんドンクラブ管理人のはんです。年末の挨拶に代えて,今年のはんドンクラブの振り返り記事を書かせていただきます。今年も1年間,皆様のおかげで無事に運営できました。本当にありがとうございました。

振り返り

コミュニティに関する所感

繰り返しとなりますが,SNSサービスの管理人としては,フォロー/フォロワー関係やオフ会など,はんドンクラブやFediverseで形成されたコミュニティについては関知しないことにしています。ただし,私個人の観測範囲(死語)における感じたことだけまとめておきたいと思います。

まず,2019年も何人かのユーザが登録してくれました。定着した方もいるようです。新たなユーザに登録して頂けるのは,管理人としてとても嬉しいことです。はんドンクラブは招待制として運用していますが,これは元々スパム防止の目的で導入した制度であり,新規登録ユーザを制限するためではありません。そのため,招待したい人が居れば遠慮無く招待していただけると嬉しいです。

なお,v3.0より,「承認制」という設定ができるようになりました。今後の運用について検討中ですが,もしかしたら承認制+招待制に変更するかもしれません。その際はきちんと事前にご相談しますね。

さて,はんドンクラブ全体に話を戻します。トゥートのvisilibityを非収載や非公開に設定しているユーザが多くLTLには現れづらいものの,引き続きいろいろな方に利用していただいているようです。管理人としては嬉しい限りです。私のフォロー範囲に限っても,様々な使い方で様々な方と交流しているユーザさんが観測できています。分散SNSは,サーバ内部の交流と,それ以外のサーバとの交流,どちらも十分に楽しめるようになっています。はんドンクラブは,当然,話題や利用方法を一切制限していませんので,皆さま思い思いのMastodonを楽しんで頂いていれば幸いです。

また,Fantiaで行っているカンパについても,ご協力いただきありがとうございます。本当に助かっています。このカンパがなければ絶対に運営できていません。引き続きのご支援をいただきますようお願いします。なお,サーバ運営費用の公表も行いたいとは思っていますが,適切な方法を模索しています。もう少しお待ち頂ければ幸いです。

データで振り返る2019年

昨年から引き続き,データで振り返ってみたいと思います。

  • 基礎データ

(2019年12月31日現在)

キー
登録ユーザ数 224人
アクティブユーザ数 142人
総トゥート数 1,268,023トゥート
総通報数 297
カスタム絵文字数 731
データベース使用容量 8.8GB
メディアストレージ使用容量 85.52GB
  • トゥート数推移

f:id:highemerly:20191231141709p:plain

はんドンクラブにおける総トゥート数の推移のグラフです。参考までに,はんドンクラブで受信した,他のサーバのトゥート数も含んだ合計値も示しています(各データのオーダが異なるため,表示軸を分離している点は注意ください)。はんドンクラブでは,2018年8月のTwitter APIの利用規程変更以降,1日あたり安定して2,000トゥート〜3,000トゥートほどご利用いただいているようです。

  • ユーザ毎のトゥート数分布

f:id:highemerly:20191231143737p:plain

2019年12月31日現在の,アカウント毎のトゥート数の分布です。相変わらずロングテールですね。

  • はんドンクラブが認知している他サーバのユーザ数

2019年は,mstdn.jp・pawoo.netの運営委譲,friends.nicoの閉鎖とbest-friends.chatの開始など,国内大規模サーバ激動の年でした。その影響かどうかはわかりませんが,はんドンクラブで認知しているユーザ数は,海外サーバであるmastodon.cloudが最も多い・・・という結果になりました。昨年はpawoo.netだったのですが。

認知しているユーザ数の一覧は以下のとおりです。150人以上のサーバに絞って記載してみました。なお,あくまではんドンクラブが認知しているユーザに限ったものであり,そのサーバに属する全ユーザを補足できている訳ではない点はご注意ください。

サーバ名 アカウント数
mastodon.social 7540
pawoo.net 6571
mstdn.jp 5991
best-friends.chat 606
mastodon.art 446
mstdn.maud.io 434
knzk.me 364
misskey.io 358
mastodon.cloud 331
cybre.space 253
mstdn.guru 215
octodon.social 202
mastodon.technology 199
baraag.net 198
niu.moe 192
imastodon.net 187
mstdn.io 177
fedibird.com 164
mstdn.beer 159
mastodon.xyz 155
mamot.fr 150

故障発生状況

2019年に発生した主な故障は以下の通りです。

発生日時 復旧日時 故障内容 原因 再発防止 リンク
1/15 23:47 1/15 23:54 緊急メンテ 設定誤り 検証環境との差分があったため修正 link
7/11 21:28 7/11 21:52 TL表示遅延 tootleサーバのスタック Mastodon本体ソース修正 link
9/21 05:45 9/22 20:10 一部ユーザでTL表示が遅い Mastodon本体DB関連のバグ 影響極小化のためログ監視強化 link
11/19 15:05 11/19 19:02 特定の画像が表示されない 利用中クラウドサービスのIPアドレス変更 自動追従できるよう設定変更 link
11/27 22:46 11/27 23:34 全体的に動作が重い 大量動画投稿による負荷集中 影響極小化のためログ監視強化 link

今年も多々ご迷惑をおかけしました。いずれの故障についても再発防止または発生時の影響極小化に取り組みたいと思います。また,故障発生時の迅速な情報提供に努めるよう努力したつもりですが,なにかご意見があれば是非頂ければと思います。

特に9/21〜9/22の故障では,多くのご迷惑をおかけしたかと思います。技術的には,アップデートによりソフトウェアバグが混入してしまい,DB検索時のindexが正しく選択されないという問題でした。一定の負荷をかけないと顕在化しない問題のため,検証環境での試験段階で気づけませんでした。本件については,後でお話ししますが,副管理人として運営に協力いただいているのんさんのおかげで迅速に解決出来たと思っています。とても助かりました。なお,この問題は,結果として本家Githubでもissueとして扱われました

また,7/11の故障もよく覚えています。tootleの通知を受け取るサーバがスタックしてしまい,結果としてはんドンクラブにおいても重要なTL配送処理が全て遅延してしまった,という故障です。本件は,そもそもソフトウェア実装がいけてないのが原因の一つでしたので,修正のうえ 本家Githubのソースコードにも反映しました。実際に運営していないと分からない課題をgithubへフィードバックできたよい例かと考えています。

その他運営振り返り

  • 主なバージョンアップ/サーバ変更作業

2019年は,待望のv3.0.0がリリースされたのが最も記憶に残っているところでしょうか。その他,サーバ管理者観点では,様々なイベントがありました。主な作業履歴とバージョンアップ履歴をまとめておきます(この他にもメンテナンスやマイナーバージョンアップやを実施していますが,主要でないものは本表からは除外しました)。

日付 イベント内容 主な新機能
1/4 全文検索サーバの運用開始 全文検索
1/9 v2.7アップデート(rc1) ディレクトリ機能
3/7 利用規約の改定 -
3/30 v2.8アップデート (rc1) 投票(アンケート)機能
6/2 大規模メンテナンス(postgre 9→11 へのver. up) -
6/10 v2.9アップデート(rc1) シングルカラムUI
9/25 v3.0アップデート カスタム絵文字のカテゴリ機能など多数
  • 副管理人

9月頃より,副管理人としてのんさんに運営にご協力いただきました。主には,私が死んだときのバックアップと,技術的な困りごとの相談相手になってもらっています。とても助かっています。この場を借りて御礼申し上げます。

実はまだサーバの権限関係をきちんと委譲できていないので,これは私の正月の宿題としたいと思います。なお,2人で議論した結果,副管理人はDBへのアクセスを禁止する方向で進めたいと思っています(システム的に難しい場合,ログ監視により不正を取り締まれる状態にする方向で進めると思います)。

今後の展望

2020年以降も引き続き頑張って運営していきます。是非,安心して利用頂ければと思います。

なお,サーバについては一部増強も予定していますが,負荷を監視しつつ増強タイミングを判断したいと思います。その他,いくつか時限爆弾を持っていますので,実施しなくてはならないメンテナンスもあります。継続して安定運用に努めたいと思います。

と,いうことで。2020年も引き続きはんドンクラブをご利用頂き,盛り上げて頂けると嬉しいです! 最後になりましたが,はんドンクラブの全てのユーザと,Mastodon開発コミュニティで活動されている皆様に感謝します。おかげで2019年も楽しい1年になりました。よいお年を!

ユーザへの運営情報の配信チャネルについて

この記事について

この記事は 分散SNS Advent Calendar 2019 - Adventar の記事として 12/13(金)に公開される予定の記事でした。

※ インフルエンザの発症で長いこと寝込んでしまい,大遅刻しました。申し訳ありません。

サーバ運営の悩み

こんにちは。はんドンクラブ 管理人の @highemerly@handon.club です。はんドンクラブはあまり名の知れたサーバではありませんが,実はそこそこアクティブなMastodonサーバです。今日は,このはんドンクラブの運営において悩んでいる,運営者からユーザに対して運営情報を周知する方法(周知チャネル)についてお話できればと思います。

Mastodon前提で記載している箇所もありますが,原則他の分散SNSでも同じことが言えるかと思います(というか,"分散" SNSに限った話ではない気もしますが・・・)。

運営情報の周知チャネル

サーバの管理者であれば,サーバに関する運営情報,例えば以下のような情報をユーザへ配信したい場合があるかと思います。

  • メンテナンスの予告
  • 実施したアップデートの情報
  • 故障発生の第一報
  • 運営方針に関するヒアリング,アンケート
  • 利用規約の変更

しかし,Mastodonが元々持っている機能の範囲では,こういった情報を伝達するために用意された手段(チャネル)はありません。そのため現実的には,サーバ管理者が自分のアカウントで発言するなどの代替手段を取っている場合が多いのではないでしょうか。ただ,この代替手段について,なかなかベストな案は無いよね・・・というのが悩みであり,この記事の議論点です。

候補1: サーバ管理者のアカウントでの発言

単に管理者がトゥートするだけです。最もシンプルなチャネルであり,管理者の作業負担も少ないです。しかし,サーバにアカウントを持つ人は必ずしも管理者をフォローしているわけではありません。一定規模以上のサーバになると,必ずしもよい手段ではないように思います。

なお,候補1の派生案として,専用のハッシュタグを作り,ユーザにはそのハッシュタグの検索結果を見てもらう方法も考えられます。また,運営情報配信の専用アカウントを作り,かつ強制フォローさせるというやり方もあります。

候補2: 専用Webページ/ブログでの告知

はんドンクラブにおけるこのブログのことです。過去の履歴を追いやすい点が最大のメリットかと思います。ただ,そもそもこの専用ブログ等へユーザを誘導する必要がありますので,結局サーバ管理者のアカウントで告知するケースが多いと思われます。また,緊急周知には適さないと思われます。

候補3: 独自機能によるWebページ(投稿欄下)での表示

いくつかのMastodonサーバで導入されている独自機能で,投稿欄下に管理者からのお知らせ表示することができる機能があります。これを活用する方法です。Webを使っているユーザにはかなり確実にリーチできる一方,サードパーティクライアントしか使わないユーザには一切気づかれないという欠点があります。

候補4: メール

シンプルに,メールを送りつける方法です。ユーザはメールアドレスを登録していることから,有効な手段になるかと思います。とはいえ,実際には読まないユーザも多数いるでしょう。さらに,管理者にとってはとても手間です*1

候補のまとめ

ということでまとめるとこんな感じでしょうか。

ユーザの網羅度 作業負担 速報性 アーカイブ,検索性
1. 管理者の発言 △(管理者のフォロー要)
2. 専用ページ △(誘導要)
3. 投稿欄下 △(Webユーザのみ) ×
4. メール

特に重要なのはユーザの網羅度かと思います。なお,「メールはどうせ読まないユーザもいるので〇ではないのでは」とヤジが飛んできそうですが,一応全員に届くはずなので,比較表上は〇にしました。

ではどうするか

結局は 複数のチャネルを使って告知することでできるだけ多くのユーザに届く努力をする ことしかありません。まあ最初から分かってたことですが。

現在のはんドンクラブでは,候補1の「管理者の発言(ハッシュタグつき)」・候補2の「専用ブログ」・候補3の「投稿欄下表示」の3つのチャネルを使って周知することが多いです。実際にユーザにアンケートを取ってみたところ,どのチャネルも一定数使われているようでした。

※ そもそもこのアンケートが「管理者の発言」により開始されたものであり,そのバイアスがかかっている可能性は大いにあります。

ただ,3つのチャネルで告知するのって結構大変なんですよね。そのため,アップデートの情報や故障情報は確実に周知したいので複数チャネルを使っていますが,他の情報の場合はサボっている場合が多いです。

もし管理者の方で「もっと良い方法あるよ!」というご意見があれば,是非教えて頂けると嬉しいなーと思っています。それでは。

*1:プライバシーポリシーで予め,メールアドレスの利用目的に「運営情報の配信」を加えておかなくてはなりません

【完了】【メンテナンス】12/7 サービスの停止を伴うメンテナンスを実施します

本日以下の日程でメンテナンスを実施します。期間中は全てのサービスが利用出来ません。ご迷惑をおかけして申し訳ございませんがご協力お願いします。

13:44追記: メンテナンスは予定通り終了しました。13:30:24 〜 13:39:20 の 8分56秒間サービスが停止しました。

  • 日時: 2019/12/7(土) 13:30〜13:45
  • 影響範囲: 全サービス
  • 理由: 各種セキュリティアップデートのため