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

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

【障害発生・復旧報】サーバに接続しづらい問題が発生していました

障害発生報 運営情報

はんドンクラブにおいて，以下の障害が発生していましたが，現在は復旧しています。ご迷惑をおかけしたことをお詫びいたします。

  • 日時： 2019年11月27日(水) 22:46 〜23:34 (JST)
  • 影響範囲： はんドンクラブの全ユーザ
  • 障害内容： レスポンスが悪いため，アクセス困難な状態になる（Web・API経由いずれも）
  • 原因：大容量動画投稿による処理遅延の発生
  • 解決方法： 自然回復

根本原因

mastodonでは，動画が投稿された際，ffmpegによる動画ファイルの再エンコードが行われます。（おそらくffmpeg側の不具合で）ffmpegがCPUリソースをほぼ100%使い果たしてしまい，結果的に他の処理ができなくなってしまいました。なお，ffmpegはwebデーモン（bundle exec puma）から呼び出されるため，今回CPUリソースをほぼ100%使い果たしてしまったのはwebサーバのみです。

根拠ですが，実はれっきとした証拠はつかめていません。客観的に見てその可能性が高いと判断した，ということになります。

その詳細を説明します。はんドンクラブにある2台のwebサーバはDNSラウンドロビンにより負荷分散されています。今回，2台のwebサーバのCPU利用率の高騰が開始した直前に，いずれのサーバにも全く同じ動画が投稿されていました。なぜ2台のwebサーバに同じ動画の投稿がリクエストされたかは分かりませんが，3rd party製クライアントで動画アップロードを試みたものの失敗したためリトライ処理が行われ，その際にたまたまDNSのTTLが切れた可能性があります。この状況から，原因を推測しました。

今回の対処方法

自然回復しました。

今後の対処方針，改善点

再発防止策は現状分かっておらず，再発の可能性は十分にあります。

nginx設定の変更

根本対処にはなりませんが，今後大容量なファイルができるかぎりアップロードされないよう，リバースプロキシ（nginx）側でアップロードファイルサイズの上限を制限しました。この対処により，ffmpegに動画を渡す前にあまりに容量の大きな動画はrejectできますので，今回と同様の事象の発生確率は下げられるものと推察します。

  • Before
  client_max_body_size 80m;
  • After
  client_max_body_size 50m;

なお，念のため述べておきますが，コンフィグ中の「50MB」というのは，「アップロード時に受け付けるサイズの上限値」であり，「実際にはんドンクラブサーバに格納される場合のサイズの上限値」ではありません。ffmpeg等により再エンコード／リサイズされるため，実際には数MB程度にまで圧縮されています。

アラート発報閾値の見直し

はんドンクラブでは，prometheus＋grafanaを使った常時監視を行っています。さらに，アラートが発生すると管理者全員にLINEで通知される仕組みとなっています。しかし今回は，実際にサービス影響が出始めてからGrafanaのアラート発報まで10分程度要してしまいました。一部の閾値を見直し，より早く気づけるように修正を行いました。

本件が発生した環境

対応時系列

特に意味はないかもしれませんが，今回の対応時系列を公開します。

2019年11月27日

  • 22:46:30頃 web1サーバ CPU利用率高騰開始
  • 22:46:45頃 HTTPレスポンス警戒域
  • 22:48:30頃 web2サーバ CPU利用率高騰開始
  • 22:48:59 dbサーバ pbouncer でのエラー多発（ .env.production のuser名/db名設定が無効化される ）
  • 22:49:04 web2サーバ rack_attack.rb での API レートリミットが多発
  • 22:49:15頃 web1サーバ CPU利用率警戒域（60%超）
  • 22:51:50頃 web2サーバ CPU利用率警戒域（60%超）
  • 22:54:01 監視サーバからのHTTPレスポンス警報が発報，管理者へLINE通知
  • 22:55:16 監視サーバからのCPU利用率警報が発報，管理者へLINE通知
  • 22:55:19 web2サーバ rack_attack.rb での API レートリミットが多発
  • 23:30頃 管理者による対応開始
  • 23:32:15頃 web1，2サーバ共にCPU利用率の低下開始
  • 23:34:35頃 HTTPレスポンス 通常値に復旧
  • 23:36:15頃 web1サーバ CPU利用率 定常レベルに改善
  • 23:38:15頃 web2サーバ CPU利用率 定常レベルに改善
  • 23:41頃 管理人により障害発生第一報の正式周知

2019年11月28日

  • 00:33頃 管理者によりあらかたの原因が発覚
  • 01:14頃 管理人により障害発生・復旧報（最終報）の正式周知

【追記あり】【障害発生・復旧報】一部画像が正常に表示されない不具合が発生していました

運営情報 障害発生報

はんドンクラブにおいて，以下の障害が発生していましたが，現在は復旧しています。ご迷惑をおかけしたことをお詫びいたします。

  • 日時： 2019年11月19日 15:05:13 〜 2019年11月19日 19:02:19 (JST)
  • 影響範囲： はんドンクラブの全ユーザ
  • 障害内容： 特定の画像が表示されない
  • 原因：Webサーバ設定が不適切であり，利用している外部サービスのIPアドレス変更に追従できなかったため
  • 解決方法： 暫定的にはWebサーバの再起動で回復済。本格対処は11月21日までに実施予定 11月20日23:50頃に本格対処完了

障害の発生メカニズム

はんドンクラブでは，メディア（トゥートに添付された画像や動画，またはアイコン画像など）は，Conohaのオブジェクトストレージに保存されています。このオブジェクトストレージ内のメディアへのアクセス用URLをWebページのドメイン（handon.club）と同一ドメイン（media.handon.club）にするため，はんドンクラブサーバ内のnginxでリバースプロキシを使っています。

media.handon.club における nginx.conf は，以下のようになっていました（一部抜粋）。

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name media.handon.club;
  ~~~中略~~~
  add_header Cache-Control "public, max-age=31536000, immutable";
  location / {
    proxy_pass https://object-storage.tyo2.conoha.io/v1/xxxxxxx/xxxxxxx/;
    ~~~中略~~~
  }
}

よく知られた問題として，proxy_pass にドメインを書いた場合，nginxの起動時にのみ名前解決が行われます。そのため，nginx起動後にDNSレコードの変更があった場合でも，OS側のTTL設定に依らず，レコード変更に追従することができません。つまり，手動でnginxを再起動するまで，永遠に古いDNSレコードが使われつづけてしまいます。

ktrysmt.github.io

今回の障害の原因については，前述のnginxの仕様により，オブジェクトストレージのグローバルIPアドレス変更に追従できなかったためです。conoha側で何らかの理由で object-storage.tyo2.conoha.io のIPアドレスが変更されましたが，はんドンクラブのnginxは古いIPアドレスへアクセスし続けてしまうため，結果としてユーザが画像を表示できない状態になっていました。

なお，古い画像には通常通りアクセスできていました。これは， media.handon.club が CDN によりキャッシュされているためです。前述の nginx.conf のとおり，一度アクセスした画像は，最大で31,536,000秒間CDNサービスのCloudflareにキャッシュされます（あれ，そういえば，Cloudflareってこのヘッダをちゃんと尊重してくれるんでしたっけ？？）。そのため，キャッシュされているアイコン画像や古いトゥートに添付された画像はアクセスが出来るが，1度もアクセスがなかった画像にはアクセスができなかった････ということになります。

なお管理人は，この proxy_pass の挙動について認識こそしていたものの，正しくない設定をしてしまいました。原因は，media.handon.club サーバについてはあまり深く考えずに各種設定を行っており，チェック漏れが発生したためです。要するに管理人の凡ミスです。

障害に気づくのが遅れた理由

今回の障害はユーザ申告により発覚しました。そのため，管理人が問題を把握したのは問題発生から3時間以上経過した18:30頃でした。こちらの原因について説明します。

はんドンクラブでは，media.handon.club については，1分に1回HTTPSリクエストを送ることで死活監視を行っています。そして，連続してアクセスエラーが発生すると，管理人と副管理人のLINEに通知される仕組みとなっています。そのため，サーバ障害に対しては速やかにその発生を認知出来るはずでした。

しかし，この死活監視は，常に同じエンドポイントに対して実施していました。そのため，当然CDNにキャッシュされているページに対して死活監視していたことになります。そのため，今回のように，新たにアップロードされている画像に限定して再現する障害では，アラートが上がらない状態となっていました。

今後の改善

  • nginx.conf については修正を行います。
    • 変数を介することでDNSレコードのTTLが設定出来るという（不思議な）手法があるため，これを適用します
    • 検証環境での動作確認を行う必要があるため，11/21(木)までの本番設定変更を目標に準備を進めます 適用済です
  • 死活監視方法の変更による早期障害検知は現実的ではないため，リスクを許容することとします。
    • 新しくアップロードされた画像に対するポーリング監視は，適切なエンドポイントが分からないため現実的ではありません
    • ただし，長期的には，ユーザの申告をより簡単かつ速やかに受け付けられる仕組みを検討し，リスクを軽減します

（11/20追記）以下のように設定変更しました。 

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name media.handon.club;
  ~~~中略~~~
  add_header Cache-Control "public, max-age=31536000, immutable";

  location ~ /(.*) {
    resolver 8.8.4.4 1.0.0.1 valid=360s;
    set $container "object-storage.tyo2.conoha.io/v1/xxxxxxx/xxxxxxx";
    proxy_pass https://$container/$1$is_args$args;
    ~~~中略~~~
  }
}

【バージョンアップ】3.0.1にアップデートしました

アップデート 運営情報

handon.club は v3.0.0 → v3.0.1 へアップデートしました🎉

アップデートの概要

Mastodon 3.0 のメンテナンスリリースが行われました。検証環境にて試験を実施し，問題無いことが確認出来たため，アップデートを行いました。

  • githubへリリースされてからアップデート完了まで，18時間を要しました
  • アップデートにかかるサービス中断時間は 0秒でした

前回バージョンからの変更点

v3.0.0 からのアップデート内容はバグ修正です。更なる詳細はGithubのリリースページを参照ください。

Release v3.0.1 · tootsuite/mastodon · GitHub

前回のアップデート

v3.0.0で多くの新機能が導入されています。詳細はイカをご参照ください。

handon.hatenablog.jp

【バージョンアップ】3.0.0rc1にバージョンアップしました

handon.club は v2.9.3 → v3.0.0rc1 へアップデートしました🎉

アップデートの概要

新バージョンである Mastodon 3.0 のリリース候補版（RC版）のリリースが行われました。正式版ではありませんが，検証環境（AWS）にて試験を実施し，問題無いことが確認出来たため，アップデートを行いました。なお，3.0リリース前に本家ソースコードのmaster追従を行っていたため，はんドンクラブでは大半の機能が2019/9/20頃から利用出来ていました。

  • githubへリリースされてからアップデート完了まで，13時間を要しました
  • アップデートにかかるサービス中断時間は 0秒でした

前回バージョンからの変更点

v2.9.3 からのアップデート内容は以下の通りです。内容が非常に多いため，管理人の独断で，はんドンクラブのユーザに関係しそうだと思うもののみ記載しています。

  • 新機能
    • ディレクトリ機能 の更新
    • オーディオプレーヤの追加
      • オーディオファイルだけをアップロードし，そのファイルをWeb上で再生する機能が追加されました。
      • アップロードできるオーディオファイルの形式は .ogg .oga .mp3 .wav .flac .opus .aac .m4a .3gp です。
    • ハッシュタグ補完機能の追加
    • 全文検索のpagination機能の追加
      • 全文検索の結果は，これまで予め管理者が設定した件数（デフォルトで20件）までしか表示されず，それ以降の結果は表示不可能でした。
      • 今回のアップデートでは，結果画面に「さらに表示」ボタンが追加されました。これによって，管理者が設定した上限数以上の検索結果を確認出来るようになりました。
    • 全文検索におけるオペレータ機能の追加
      • Google検索のように，「+」(AND)や「-」(NOT）と言ったOperatorを使うことで，より詳細に検索条件が出来るようになりました。
    • スローモードの追加
      • Web上でUserstreamによる自働更新を行わないモード（スローモード）が追加されました。
      • 利用するためには，ユーザ設定画面から「手動更新モード」を有効にして下さい。
    • 投票後に自分がどの選択肢に投票したか表示する機能の追加
      • アンケートに投票した後，自分がどの選択肢に投票を行ったのか，チェックマークにより明示されるようになりました。
    • アカウント自働移行機能 の追加
      • サーバ間でのアカウント移行が，Webで半自動的にできるようになりました。
      • 非常に重い機能となりますので，はんドンクラブにおいては，利用は推奨しません。
    • 注目のハッシュタグ機能 の復活
      • サーバ内でよく使われているハッシュタグを表示する「注目のハッシュタグ機能」が復活しました。以前一度実装されていましたが，スパムの温床になるとのことで一度削除されていました。
      • 今後，管理人の承諾が行われたハッシュタグのみ，注目のハッシュタグに表示されるようになります。注目のハッシュタグは，「トレンド」として，Webの一番右のカラムに表示されます。
    • サーバがブロックしているドメインを自働表示する機能の追加
      • 管理人がブロックまたはサイレントしているサーバを表示する機能が追加されました。
      • はんドンクラブでは https://handon.club/about/more の下部に表示されます。ブロックしている理由も明記しております。
    • カスタム絵文字のカテゴリ化機能 の追加
      • カスタム絵文字がカテゴリ分けできるようになりました。Webでは，サーバ管理者が設定したカテゴリに従って表示されます。
      • なお，3rdパーティ製クライアントをご利用の方は，クライアント側が対応するまでこの機能は利用出来ません。詳細はクライアント作者までお問い合わせ下さい。
    • 特定のサーバとのみ連合する機能（ホワイトリスト機能）の追加
      • はんドンクラブでは有効化する予定はありません。
    • 管理人からの警告メールに当該トゥートを明記する機能の追加
    • 2段階認証利用時におけるメール確認機能の追加
    • ブラウザタブに表示されるページタイトル名に未読通知数が表示される機能の追加
  • 変更点
    • DMカラムのUI変更
      • WebにおけるDMカラムのUIが大幅に変更されました。誰からDMを受け取ったかどうかが分かりやすくなりました。
    • クライアント向けAPIの一部削除
      • DMを取得するAPIが削除され， /api/v1/conversations を使う方法に変更する必要があります。
      • 全文検索を提供するAPIのうち古いものが削除され， /api/v2/search を使う必要があります。
    • 連合向けIFの一部削除
      • 1.0からサポートされていたOStatus関連の機能が全て削除されました。
    • 投稿メディアにおけるWebPサポートの削除
      • 対応が不十分であったことから，WebPの画像を投稿する機能が削除されました。

上記は一部だけを書き出しています。今回のアップデートには，多くのバグ修正や微細な機能修正が含まれています。更なる詳細はGithubのリリースページを参照ください。 Release v3.0.0rc1 · tootsuite/mastodon · GitHub

前回のアップデート

handon.hatenablog.jp

【復旧】【障害発生報】一部ユーザの接続レスポンスが悪い状態が続いています

運営情報 障害発生報

以下の障害が発生しており，復旧に向けて取り組んでいます。ご利用の皆様にはご不便ご迷惑をおかけしております。

Update: 本件は復旧し，現在は正常に動作しています。

復旧まで時間を要してしまったこと，検証環境にて本問題に気づけなかったこと，お詫びいたします。

状況を報告頂ける方は，以下のトゥートの通り，詳細な情報を頂けますと幸いです。

なお，今後の障害情報については，以下ページでも配信します。将来的にはこのブログも移行する予定です。

status.handon.highemerly.net

「通報」機能についてのお願い

運営情報

はんドンクラブ管理人のはんです。

この記事では通報機能の使い方について，お願いを記載いたします。最近意図の分からない通報が増えており，インスタンス運営上の困りごとの一つとなっています。厳密なルールにしたいわけではないので，どうしても難しい場合は柔軟に運用することとしたいと思いますが，ご協力をお願いします。

通報は管理者対処が必須の場合のみお願いします

マストドンには「フォロー解除」「ミュート」「ブロック」などの機能があります。この機能は，マストドンに登録しているユーザであれば誰でも自分の意思のみで利用でき，管理者に報告する必要はありません。

機能の名前 効果
フォロー解除 対象の人の発言が，あなたのHTLに流れなくなります
ミュート 対象の人の発言が，あなたのHTL/LTL共に流れなくなります（フォロー状態には影響しません）
ブロック 対象の人の発言が，あなたのHTL/LTL共に流れなくなります（その上で互いにフォロー解除されます）

これらの機能は，サーバ（インスタンス）全体に影響を与えることはなく，あなた個人だけに影響する設定です。そのため，管理者への通報は「サーバ全体で統一的な処置が必要な場合」にのみ実施していただきたいです。

ここで，サーバ全体に影響する機能としては，「アカウント削除」「ログイン停止」「サイレンス*1」などがあります。これらの機能は，管理者*2だけが利用出来ます。そのため，このような機能を用いて，サーバレベルで対処が必要と考えられる場合にのみ通報をお願いします。つまり，あなたが「苦手な人や発言を見たくない」「自分の信念と合わない」というだけの場合には，通報の必要はありません。

通報した理由を書いてください

上記の要件を満たす場合，通報した理由があるはずです。通報には，そういった「なぜこの発言やユーザを通報したのか」という理由を明記してください。

無言で通報が行われると，それが真に必要な通報なのか，私怨なのか，はたまた操作ミスなのか判断出来ません。更に，そのユーザの詳細や前後のトゥートを確認して通報理由を類推する，という作業も手間がかかりすぎますので，（申し訳無いですが）難しいです。WebUIからは複数のトゥートをまとめて通報することも可能*3ですので，問題のあるトゥートを全て選択したうえで，どういう理由でこのトゥート群を通報したのかを記載してください。

なお，通報理由に長文を書いてくれと言っている訳ではありません。例えば以下の様な記載でも十分と考えられます（これに拘るものではありません）。

  • 明らかに不適切なURL付きの広告トゥート→「spam広告」
  • 明らかに機械的かつスパム目的と思われるフォロー→「follow spam」
  • 平均的な職場や公共の場での閲覧が不適切な画像へのNSFW未付与→「NSFWなし」

今後，はんドンクラブでは，無言の通報の場合，無条件で無視する運用にいたします。申し訳ありませんが，ご協力をお願いします。

*1:対象の人の発言が，全員のLTLに表示されなくなります（HTLには表示されます）。

*2:正確には管理者またはモデレータ。

*3:通報自体は3rdパーティー製クライアントからも可能ですが，複数トゥートをまとめて通報する機能は実装されているクライアントは少ない印象です。ご自身の使っているクライアントの対応状況が分からない場合は，ブラウザからWebUIをご利用ください。

【バージョンアップ】2.9.3にバージョンアップしました

アップデート 運営情報

handon.club は v2.9.2 → v2.9.3 へアップデートしました🎉

アップデートの概要

Mastodon 2.9 のメンテナンスリリースがありましたので，アップデートを行いました。

  • githubへリリースされてからアップデート完了まで，2日を要しました
  • アップデートにかかるサービス中断時間は 29 秒でした

前回バージョンからの変更点

v2.9.2からのアップデート内容は以下の通りです。

  • 新機能
    • カスタム絵文字登録時の形式追加（#11519）
      • これまでカスタム絵文字を登録する際はかならずpng形式である必要がありましたが，今回からgifおよびwebp形式がサポートされます。はんドンクラブにおいても，カスタム絵文字登録依頼時は，png/gif/webp形式の何れかであれば，受け付けるように変更します。

その他，管理者向け機能の修正やバグ修正，およびセキュリティー関連のアップデートが行われています。その他詳細は，Githubのリリースページ（2.9.3も参照ください。

その他のお知らせ

Mastodon公式リポジトリでは，v3.0リリースへ向けた開発が着々と進んでいるようです。様々な目玉機能がありますが，管理人一押しは「カスタム絵文字のカテゴリ分け機能」です。webpickerにおけるカスタム絵文字が，サーバ管理人の指定したカテゴリ毎に表示可能となります。ユーザにとっては，カスタム絵文字の入力がより簡単になることが期待されます。

前回のアップデート

handon.hatenablog.jp