本日以下の日程でメンテナンスを実施します。期間中は全てのサービスが利用出来ません。ご迷惑をおかけして申し訳ございませんがご協力お願いします。
13:44追記: メンテナンスは予定通り終了しました。13:30:24 〜 13:39:20 の 8分56秒間サービスが停止しました。
- 日時: 2019/12/7(土) 13:30〜13:45
- 影響範囲: 全サービス
- 理由: 各種セキュリティアップデートのため
本日以下の日程でメンテナンスを実施します。期間中は全てのサービスが利用出来ません。ご迷惑をおかけして申し訳ございませんがご協力お願いします。
13:44追記: メンテナンスは予定通り終了しました。13:30:24 〜 13:39:20 の 8分56秒間サービスが停止しました。
はんドンクラブにおいて,以下の障害が発生していましたが,現在は復旧しています。ご迷惑をおかけしたことをお詫びいたします。
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)側でアップロードファイルサイズの上限を制限しました。この対処により,ffmpegに動画を渡す前にあまりに容量の大きな動画はrejectできますので,今回と同様の事象の発生確率は下げられるものと推察します。
client_max_body_size 80m;
client_max_body_size 50m;
なお,念のため述べておきますが,コンフィグ中の「50MB」というのは,「アップロード時に受け付けるサイズの上限値」であり,「実際にはんドンクラブサーバに格納される場合のサイズの上限値」ではありません。ffmpeg等により再エンコード/リサイズされるため,実際には数MB程度にまで圧縮されています。
はんドンクラブでは,prometheus+grafanaを使った常時監視を行っています。さらに,アラートが発生すると管理者全員にLINEで通知される仕組みとなっています。しかし今回は,実際にサービス影響が出始めてからGrafanaのアラート発報まで10分程度要してしまいました。一部の閾値を見直し,より早く気づけるように修正を行いました。
特に意味はないかもしれませんが,今回の対応時系列を公開します。
.env.production
のuser名/db名設定が無効化される )はんドンクラブにおいて,以下の障害が発生していましたが,現在は復旧しています。ご迷惑をおかけしたことをお詫びいたします。
はんドンクラブでは,メディア(トゥートに添付された画像や動画,またはアイコン画像など)は,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レコードが使われつづけてしまいます。
今回の障害の原因については,前述の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
については修正を行います。
(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; ~~~中略~~~ } }
handon.club は v3.0.0 → v3.0.1 へアップデートしました🎉
Mastodon 3.0 のメンテナンスリリースが行われました。検証環境にて試験を実施し,問題無いことが確認出来たため,アップデートを行いました。
v3.0.0 からのアップデート内容はバグ修正です。更なる詳細はGithubのリリースページを参照ください。
Release v3.0.1 · tootsuite/mastodon · GitHub
v3.0.0で多くの新機能が導入されています。詳細はイカをご参照ください。
handon.club は v2.9.3 → v3.0.0rc1 へアップデートしました🎉
新バージョンである Mastodon 3.0 のリリース候補版(RC版)のリリースが行われました。正式版ではありませんが,検証環境(AWS)にて試験を実施し,問題無いことが確認出来たため,アップデートを行いました。なお,3.0リリース前に本家ソースコードのmaster追従を行っていたため,はんドンクラブでは大半の機能が2019/9/20頃から利用出来ていました。
v2.9.3 からのアップデート内容は以下の通りです。内容が非常に多いため,管理人の独断で,はんドンクラブのユーザに関係しそうだと思うもののみ記載しています。
上記は一部だけを書き出しています。今回のアップデートには,多くのバグ修正や微細な機能修正が含まれています。更なる詳細はGithubのリリースページを参照ください。 Release v3.0.0rc1 · tootsuite/mastodon · GitHub
以下の障害が発生しており,復旧に向けて取り組んでいます。ご利用の皆様にはご不便ご迷惑をおかけしております。
Update: 本件は復旧し,現在は正常に動作しています。
復旧まで時間を要してしまったこと,検証環境にて本問題に気づけなかったこと,お詫びいたします。
状況を報告頂ける方は,以下のトゥートの通り,詳細な情報を頂けますと幸いです。
なお,今後の障害情報については,以下ページでも配信します。将来的にはこのブログも移行する予定です。
はんドンクラブ管理人のはんです。
この記事では通報機能の使い方について,お願いを記載いたします。最近意図の分からない通報が増えており,インスタンス運営上の困りごとの一つとなっています。厳密なルールにしたいわけではないので,どうしても難しい場合は柔軟に運用することとしたいと思いますが,ご協力をお願いします。
マストドンには「フォロー解除」「ミュート」「ブロック」などの機能があります。この機能は,マストドンに登録しているユーザであれば誰でも自分の意思のみで利用でき,管理者に報告する必要はありません。
機能の名前 | 効果 |
---|---|
フォロー解除 | 対象の人の発言が,あなたのHTLに流れなくなります |
ミュート | 対象の人の発言が,あなたのHTL/LTL共に流れなくなります(フォロー状態には影響しません) |
ブロック | 対象の人の発言が,あなたのHTL/LTL共に流れなくなります(その上で互いにフォロー解除されます) |
これらの機能は,サーバ(インスタンス)全体に影響を与えることはなく,あなた個人だけに影響する設定です。そのため,管理者への通報は「サーバ全体で統一的な処置が必要な場合」にのみ実施していただきたいです。
ここで,サーバ全体に影響する機能としては,「アカウント削除」「ログイン停止」「サイレンス*1」などがあります。これらの機能は,管理者*2だけが利用出来ます。そのため,このような機能を用いて,サーバレベルで対処が必要と考えられる場合にのみ通報をお願いします。つまり,あなたが「苦手な人や発言を見たくない」「自分の信念と合わない」というだけの場合には,通報の必要はありません。
上記の要件を満たす場合,通報した理由があるはずです。通報には,そういった「なぜこの発言やユーザを通報したのか」という理由を明記してください。
無言で通報が行われると,それが真に必要な通報なのか,私怨なのか,はたまた操作ミスなのか判断出来ません。更に,そのユーザの詳細や前後のトゥートを確認して通報理由を類推する,という作業も手間がかかりすぎますので,(申し訳無いですが)難しいです。WebUIからは複数のトゥートをまとめて通報することも可能*3ですので,問題のあるトゥートを全て選択したうえで,どういう理由でこのトゥート群を通報したのかを記載してください。
なお,通報理由に長文を書いてくれと言っている訳ではありません。例えば以下の様な記載でも十分と考えられます(これに拘るものではありません)。
今後,はんドンクラブでは,無言の通報の場合,無条件で無視する運用にいたします。申し訳ありませんが,ご協力をお願いします。