容量の大きな動画がアップロードできなかった問題が解決しました

ご報告いただいていたにも関わらず長らく解決できていなかった、容量の大きな動画がアップロードできなかった問題が解決しました。分からないことも多いのですが、原因と対策について説明します。

事象の概要

• 発生日時: 2021年5月9日(推定)-2022年7月28日23:00頃
• 事象の内容: 容量の大きな動画のアップロードに失敗する場合がある
  • 手元での再現試験とログの解析結果から、2つの失敗事例がありました。
    • 422エラーが表示される場合
    • 500エラーが表示される場合
  • 発生条件:
    • Webまたは/api/v2/mediaを使って非同期アップロードを行う3rdパーティークライアントからのアップロードであること
      • /api/v1/mediaではおそらく問題は発生していないと思いますが、自信はありません。
    • おおむね15MB以上の動画であること
• 原因: オブジェクトストレージへのアップロード処理に失敗していたため。
  • 2つの事象毎に原因が異なるようでした。
    1. マルチパートアップロードに失敗している
    2. アップロード自体は成功しているが、何らかのタイムアウトにより失敗したと勘違いしている
  • 当初、1. だけが原因かと思ったのですが、どうも2. もたまに発生している場合があるようです。
• 対処: マストドン側の設定変更。
  • 2つの事象毎に以下の対処を行いました。
    1. マルチパートアップロードを行う閾値を大幅に上げ、事実上マルチパートアップロードが行われないようにしました。
    2. S3関係のリードタイムアウトを延長しました。

原因

Web側の問題のときは Api::V2::MediaController がエラーを吐き、バックエンド処理（sidekiq）側の問題のときは PostProcessMediaWorker がエラーを吐いていました。当初、バックエンドの問題に引っ張られてApi::V2::MediaControllerがエラーを吐いているのだと思っていましたが、稀に違う場合があり、バックエンド側は正常終了しているのにもかかわらずWeb側が前述の問題と同じエラーを吐いているログも見つけました。

ただ、バックエンド側が明らかにアップロードに失敗しているログが一番多くありましたので、先にここを調査しました。

2022-07-28T13:05:08.717Z pid=18954 tid=h71ve class=PostProcessMediaWorker jid=○○○○○○○○○○○○○○○ ERROR: Processing media attachment ○○○○○○○○○○○○ failed with undefined method `split' for nil:NilClass
from /home/highemerly/mastodon/vendor/bundle/ruby/3.0.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/file_downloader.rb:127:in `block (3 levels) in thread_batches'
/home/highemerly/mastodon/vendor/bundle/ruby/3.0.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/file_downloader.rb:135:in `write': undefined method `split' for nil:NilClass (NoMethodError)
#<Thread:0x00007f3f816ef290 /home/highemerly/mastodon/vendor/bundle/ruby/3.0.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/file_downloader.rb:123 run> terminated with exception (report_on_exception is true):

調査の結果、このバックエンド側の根本的な問題は、オブジェクトストレージをWasabiに変えた際にマルチパートアップロード（大容量のファイルを複数のチャンクに分割してアップロードする方法）が上手くいっていないことが分かりました。本当は対応しているそうなのですが、少なくともpaperclip（mastodonがS3へのアップロード処理等で使っているgem）からは使えませんでした。

wasabi-support.zendesk.com

ぐぐったところ、オブジェクトストレージをGCPにしている場合にも同じ問題が発生しているそうで、こちらの投稿を参考にさせていただいて対処しました。具体的には、マルチパートアップロードを行う閾値を大きくする（＝マルチパートアップロードが起こらないような閾値にする）という設定変更を行いました。

mstdn.anqou.net

一方、422でサムネイルが作られないというエラーは、実際にアップロードが成功しているのにも関わらずAPIの内部処理がタイムアウトしていることが分かりました。以下の問題が関係ありそうだと考え、リードタイムアウトも長めにとりました。

github.com

どちらもなんと .env ファイルへの記載だけで変更できるということで、以下のような設定をいれてみました。

S3_READ_TIMEOUT=20
S3_MULTIPART_THRESHOLD=52428801

現時点では両方を設定しています。しかし、リードタイムアウトの変更は本当に必要だったのか怪しいと考えており、余裕のあるときにA/Bテストを行ってもう少し原因を追跡する予定です。

その他

実はここ最近、バックエンド（sidekiq）サーバで、特定プロセスがファイルディスクリプタを食い潰してしまい、システムが不安定になるケースが散見されていました。特に、/etc/resolve.confが開けなくなり、外部サーバ宛の配信が失敗することが多かったです。この問題はsidekiqプロセス再起動によりファイルディスクリプタは返してもらえるので、当面は定期的なプロセス再起動でやり過ごしています。しかし、今回のアップロード処理失敗によりファイルディスクリプタを食い潰していたのかもしれないですね。

以前より5分おきにlsofコマンドで開いているファイル数を監視するスクリプトを回しているので、本当にこれが原因だったのか、少し様子を見てみようと思います。

はんドンクラブの独自機能・特徴

この記事ははんドンクラブの独自機能や構成をまとめたものです。誰がいるか，どう使われているかは記載していません。管理人のメモ（仕様書）として使うことも想定しています。随時更新されます。

追加機能

Mastodonの内部処理を書き換えている追加機能で，ブラウザでも3rdパーティー製のクライアント（アプリ）でも影響するものです。

DMをホームTLに表示しない

Mastodonは，Twitterなど他のSNSと違い，ダイレクトメッセージ（DM）もホームTLに表示されます。しかし，はんドンクラブでは，①初期設定では，DMをホームTLに表示しない ②希望する場合，DMをホームTLに表示することもできる 仕様に変更しています。つまり，DMの表示は以下のとおりです。

	通常	はんドンクラブ
ホーム欄	表示される＊	表示されない（設定で表示される＊にも変更可）
通知欄	表示される	表示される
ダイレクトメッセージ欄	表示される	表示される

＊フォローしている場合に限る

設定を変更したい場合，設定→ユーザ設定→その他→DMをホームTLに表示しない で変更してください。

プロフィール絵文字

自分または他人のアイコンをカスタム絵文字のように使えます。私のアイコンであれば :@highemerly: とすることで，誰でも利用できます。best-friends.chat さんの実装を参考に，だいぶ書き換えてます。

他のサーバの実装では3rdパーティのクライアントでプロフィール絵文字が表示されない場合が多いのですが，はんドンクラブでは3rdパーティのクライアントであっても表示可能な実装に書き換えています。API上，通常のカスタム絵文字かのように絵文字の情報を渡しています。

連合については，以下の仕様となります。

• ○ はんドンクラブのユーザは，他のサーバのユーザのアイコンを使ったプロフィール絵文字は投稿できる
• ○ はんドンクラブのユーザは，他のサーバのユーザのプロフィール絵文字の投稿を表示できる
• ○ プロフィール絵文字に対応しているサーバのユーザは，はんドンクラブのユーザのプロフィール絵文字の投稿を表示できる＊
• × プロフィール絵文字に対応していないサーバのユーザは，はんドンクラブのユーザのプロフィール絵文字の投稿を表示できない

＊ はんドンクラブの実装と同様の実装の場合。

全文検索機能

自分の投稿やお気に入り・ブックマークした投稿は全文検索が可能です。もともとMastodonある機能なのですが，別コンポーネントが必要なため有効にしているサーバは多くありません。

はんドンクラブでは，日本語検索を最適化するため，日本語専用の形態素分析を行うプラグインを導入しています。kuromojiを使っており，利用するためにソースコードを修正しています。

アナウンス機能

投稿欄の下に私からのアナウンスが表示される欄です。mstdn.maud.io さん の実装を参考に，いじっています。間違って押してしまうということで苦情が来ているので，いつか別の形で実装し直そうと思っています。実はjsonでも取れます。

パラメータのチューニング内容

追加機能というほどではありませんが，いくつか通常よりも制限を緩和しているものがありますので紹介します。ブラウザでも3rdパーティー製のクライアント（アプリ）でも影響します。

メディアファイルの制限

はんドンクラブへ投稿できる画像や動画のサイズ上限を以下のように変更しています。なお，実際にサーバに保存される画像や表示される画像は，リサイズ・圧縮・フォーマット変換が行われる場合があります。

項目	通常	はんドンクラブ
画像ピクセル数上限	1920x1080px	2880x1440px
画像サイズ上限	10MB	15MB
動画サイズ上限	40MB	65MB

その他の上限などが知りたい方は，以下のソースコードを参照してください。

github.com

投票（poll）の選択肢の制限

投票機能では，選択肢の数と投票可能期間をより柔軟に選択できるようにしています。

項目	通常	はんドンクラブ
選択肢の上限	4	16
投票期間	5,30分／1,6時間／1,3日	1,5,10,30分／1,2,6時間／1,3日

タイムライン取得上限値

タイムラインは，過去に遡れる上限値があります。400投稿から1,200投稿に増やしています。

トレンドの選出閾値

トレンドに選出される条件にはいくつかの閾値が設定されています。トレンドに選出されやすいように少々いじっています。

Webの表示形式の変更内容

3rdパーティー製のクライアント（アプリなど）では関係のない，ブラウザでの見た目だけの項目です。一番簡単にカスタマイズできるので，結構いじっています。

3.x系風UIへの修正

4.0になってUIが使いにくくなったとの声が多かったので、3.x風のUIに修正を行っています。

• タイムライン中の無駄な余白を削除
• タイムライン中のアイコン画像とその余白を縮小
• タイムライン中のリプライ表記とその余白を縮小
• スマホからのアクセス時、投稿ボタンをサイドバーに追加
• 「投稿」を「トゥート」表記に変更
• その他余白の微修正

ブックマークボタンの追加

各投稿にブックマークボタンが表示されるようにしています。通常はメニューの奥深くにありますが，はんドンクラブではブックマークしやすくしてあります。fedibird.com さんを参考にさせて頂いています。

→すでにバニラ（標準）にも実装されています。

カスタム絵文字のスタンプ機能

カスタム絵文字を一つだけ投稿すると，スタンプのように大きく表示されます。2つ以上投稿された場合や普通の文字（ユニコード絵文字を含む）が投稿されている場合は対象外ですが，クリックorタップすることで一時的に大きくなります。独自機能です。なお，スタンプのように大きく表示される機能は Tootoise にも実装されています。

カスタムテーマ

いくつかのカスタムテーマを取り入れています。Blacklead Theme，Canta Darkの他に，InstanceTickerを取り入れており，好きなものを選べます。

inst.ance.tk

Blacklead Theme，Canta Darkは，一部スタイルを変更し，文字を読みやすくしています。その他にもよさそうなテーマ（かつ，ライセンス上問題ないテーマ）があれば，随時取り入れていこうと考えています。

InstanceTickerは，アカウントが所属するサーバを見やすくしてくれるツールです。Type1のみ実装しています。また，自分と同一サーバのユーザのティッカーは非表示にしています。そのためローカルタイムラインにはティッカーが出現しません。

どんなテーマがあるか試してみたい方は，設定→ユーザ設定→外観→サイトテーマ から変更できます。

より見やすいVisibility

各投稿の右上にVisibility（公開範囲）を表すアイコンが表示されますが，見やすさを向上するため，以下表のような修正を行っています。

同一サーバのIDを赤文字で表示

同一サーバのユーザは，タイムライン上でのIDが赤文字になります。それ以外のユーザは，テーマに沿った色で表示されます。

はんドンロゴの表示

スマホからのアクセス時、 @inabap に頂いたはんドンクラブのロゴが表示されます。

ユーザコミュニティ

管理人が把握している外部のユーザコミュニティを紹介します。いずれも管理人は一切関与していません。

• 投稿まとめ

hagetter.hansode.club

• Wiki

hndn.blazing.jp

• おみくじ

donmikuji.netlify.app

また，私が見えていない範囲でこれ以外にもあるかもしれません。掲載を希望するものがあればお気軽に教えてください。

運営の考え方

サーバ運営の考え方をまとめたものです。

ガイドライン

handon.hatenablog.jp

カスタム絵文字の追加申請方法、アカウントの削除申請などはこちらに記載があります。

プライバシー

はんドンクラブは，全ての投稿の著作権は投稿者に帰属すると考えています。当然，日本国内の法律である改正個人情報保護法を遵守し，当該法に基づく自己の個人情報の照会はGoogle フォームで受け付けています。併せて，GDPRも一つの指針として捉えています。主に日本国内に向けてのみサービス提供しているためGDPR準拠は必須ではないと認識していますが，これを目標として設定することでユーザのプライバシー尊重に努めています。

詳しいプライバシーポリシーは以下を参照ください。

handon.club

その他法令（プライバシーを除く）

はんドンクラブは，直接料金を徴収していないものの寄附を募っていること，及びダイレクトメッセージ機能を提供していることから，電気通信事業法に基づき届出電気通信事業として総務省関東総合通信局へ届出を行っています。提供役務は「31 インターネット関連サービス（ＩＰ電話を除く。）」，提供区域は「全国」です。なお，利用者が少ないため即時報告の対象となることはありませんが，四半期報告の対象になる場合があります。

はんドンクラブは，プロバイダ責任制限法の適用を受けると考えています。発信者情報開示に関する請求や権利の侵害に関するお問い合わせは，Google フォームで行うことができます。

費用

fantia.jp

費用は原則として管理人のポケットマネーから捻出しています。しかし，よりよいサービス提供のため，ファンティアで寄附を募っています。スポット的な寄附ももちろん助かるのですが，サーバ代は月額で発生しますので，月額寄附が可能なファンティアを使っています。

また，2023年上期には毎月の収支報告ができるようにしたいと思っています。

サーバ構成

これ以降は技術的な話です。興味の無い方は読み飛ばしてください。

概要

規模

2023年3月現在

• ヒット数: 25万〜30万アクセス / 1日
• 転送容量: 20GB〜25GB / 1日
• データベース容量: 28GB程度
• メディアストレージ容量: 300GB程度

利用しているサービス・コンポーネント

サービスを提供するため，以下のサービス・コンポーネントを利用しています。

2023年3月現在

• サービス
  • コンピューティング: さくらVPS（データ保存あり： 運用は東京，バックアップは大阪）
  • オブジェクトストレージ: wasabi（データ保存あり： 東京）
  • メール送信: sendgrid
  • CDN: CloudFlare Proプラン
  • WAF: CloudFlare Proプラン
  • レジストラ: GMO
  • ネームサーバ: CloudFlare Proプラン
  • SSL証明書: Origin-CDN間はLet's Encrypt，CDN-ユーザ間はCloudFlareが提供
  • 監視: LINE
• コンポーネント・OSS
  • OS: CentOS 7.x系
  • リバースプロキシ: nginx 独自コンパイル
  • データベース: postgresql 17.x系 (with pgbouncer), redis 7.x系
  • 全文検索: Elasticsearch 7.x系
  • テレメトリ取得・監視・可視化: prometheus, grafana

CDNは画像・動画のキャッシュのために利用しており、投稿/プロフィールをはじめとするAPI応答が保存されることはありません（cache-control: private）。画像・動画もパーソナルデータであると考えていますが、重要な情報が抜かれることはないと考えていただいてよいと思います。

2つのWebサーバは，グローバルロードバランサによるロードバランシングではなく，DNSラウンドロビンによるロードバランスが行われます。しかし，ユーザが接続するのはCloudFlareのサーバですので，実際に接続するWebサーバを選択しているのはCloudFlareです。

監視系については，CPUやディスクなどのメトリクスの監視の他，外形監視を行っています。警報は管理人のLINEに飛ぶようになっています。以下の記事も参照ください。

handon.hatenablog.jp

運用状況は，一般ユーザからもuptimerobotで確認できます。ただし，管理人による監視は，上記記載のとおりprometheus+grafana+LINEで行われています。

stats.uptimerobot.com

セキュリティ

handon.hatenablog.jp

• アプリケーションセキュリティ
  • Mastodon本体の脆弱性には1週間以内（目標：2日以内）に対応する体制を取っています。
  • Mastodonが直接依存するパッケージや関連するパッケージなどは定期的（目標：1ヶ月に一度）にアップデートする体制を取っています。
  • CloudFlareでWAFを利用しています。精度はよく分かりませんのであまり過信していません。
• DDoS対応
  • 現状は全ての通信がCDNを通過するため，DDoSはCDN側で緩和されます。
  • はんドンクラブサーバのIPアドレスを直接外部に公開しないことで，CDNをバイパスする攻撃が発生しないようにしています。
• ネットワークセキュリティ
  • ファイアウォールは一般的な対策（インターネット側インターフェースで必要最低限のポートのみ公開するなど）を完了しています。
  • 管理用SSHログインについては一般的な対策（公開鍵認証を必須とする，fail2banの導入など）を完了しています。
  • TORからのアクセスは原則ブロックしています。
• 暗号化・署名
  • ユーザとの通信は全てTLSで暗号化されます。Origin-CDN間，CDN-ユーザ間ともに，TLS1.1以下を無効化し，1.2・1.3のみで運用しています。
  • SNIを利用しているため，ガラケー，Android2.x，Windows XPのIEからはアクセスできません。
  • HSTSを設定しています。
  • CloudFlareの設定上，一部弱めの暗号化スイートもオファーされる場合がありますが，普通のブラウザやOSをお使いの方には十分安全な暗号化スイートが選択されます。
  • DNSトラヒックの暗号化（DoH、DoT）やレコードの署名（DNSSEC）は行っていないため、悪意のあるユーザーや雇用主などによって通信先が傍受・書き換えられるリスクがあります。署名（DNSSEC）の導入に向けて取り組んでいます。
• 監査
  • ログは可能な限り90日以上保管されるように設定しています。
• DR（Disaster Recovery）プラン
  • 1日2回のオフラインバックアップを行っています。詳細は，上記の記事を参照してください。

バッチ処理

日本時間の夜間帯にいくつかのバッチ処理を実行しています。

1. 他サーバから受信したメディアファイルの削除
   • 他サーバに所属するアカウントが投稿した画像や動画のメディアファイルなどは，一度はんドンクラブ側にキャッシュされます。しかし，容量削減のため，約1ヶ月経過したメディアはバッチ処理によって削除されます。
   • 削除されたメディアのリンクは保持しているため，リンクから当該サーバにアクセスすれば閲覧可能です。
   • はんドンクラブに所属するアカウントが投稿した画像や動画のメディアファイルは，時間が経過しても削除されません。
2. アカウントの削除
   • アカウントの削除は他の全てのサーバへその通知を送るため，サーバにとって非常に大きな負荷となります。そのため，アカウントの削除タイミングは管理人が管理しています。
   • 概ね依頼のあった翌日の夜間帯にバッチ処理が行われます。
3. トレンドの更新
   • トレンド更新頻度がゆっくりなため，結構短い頻度で強制的に更新しています。

その他，いくつかバッチがありますが，主なものはこれくらいです。

ソースコード

MastodonはAPGLでライセンスされているため，はんドンクラブで運用しているコードも以下で公開しています。

github.com

【故障発生報告】サービス全体が利用できなくなっています

• 日時： 2021年10月7日(木) 19:42頃〜
• 内容： サービスが利用できない
• 原因： ドメイン上流サーバの故障によりドメイン解決ができないため

基本的に私ができることはありませんので，復旧を待っております。

なお，技術的な知識をお持ちの方限定ですが，/etc/hostsに以下を記載するとアクセスできます。自己責任でお試しください。

104.26.13.147 handon.club media.handon.club streaming.handon.club
104.26.12.147 handon.club media.handon.club streaming.handon.club
172.67.75.216 handon.club media.handon.club streaming.handon.club

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

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

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

アップデート

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

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

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

github.com

• [Suggestion] add notice of audio CORS in 3.2.0 release note · Issue #14391 · tootsuite/mastodon · GitHub
• Hide announcement box in default when all announcement items have read · Issue #12988 · tootsuite/mastodon · GitHub

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

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

• Fix audit log error when custom emoji is copied from remote server (#… · tootsuite/mastodon@3919571 · GitHub
• Change the retry limit in error of web push notification (#11292) · tootsuite/mastodon@4023027 · GitHub

独自機能の追加

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

InstanceTicker

miy.pw

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

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

handon.hatenablog.jp

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

スタンプ機能

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

アイコン絵文字（プロフィール絵文字）

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

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

DMのHTL非表示機能

handon.hatenablog.jp

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

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

github.com

その他

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

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

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

統計情報

トゥート数推移

トゥート数推移

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

トゥート数ランキング

アカウントごとのトゥート数（トゥート数ランキング）

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

登録日ごとの総合トゥート数

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

公開範囲

投稿の公開範囲の推移

公開トゥートってどれくらいあるんだろう？と思ったので，統計を取ってみました。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

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

オブジェクトストレージの利用容量推移

終わりに

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

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

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とクライアントの未読管理は同期可能です。

     

     未読の通知には左側に青色のバーがついています。

4. ブックマークしたトゥートのインポート・エクスポートに対応しました #14956
   • トゥート含め，https://handon.club/settings/export からエクスポートできます。サーバに非常に高い負荷がかかるため，必要な時にのみエクスポートをお願いします。
5. 特定のユーザがトゥートした際に通知を受け取ることができるようになりました #13546

   

   ベルのマークを押して通知をオンにするとトゥートしたときに通知が届くようになります！

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に表示させるかさせないかをユーザごとに選択できるようにしました。

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

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（これまで）

これまで・非収載

• After（これから）

これから・非収載

フォロワー限定トゥート

• Before（これまで）

これまで・フォロワー限定

• After（これから）

これから・フォロワー限定トゥート

変更の経緯

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

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

github.com

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

おまけ

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

github.com

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

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

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

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

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

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

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

• さくらインターネット（さくらVPS）
• GMO（Conoha）
• SendGrid
• CloudFlare

このうち、データが保管されており、データという観点で可用性を考慮する必要があるサービスはさくらインターネットと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分以内に気づけるようになっているので、仕事中など即時対応できる状況であれば誤差の範囲です。