爆発炎上で振り返るびびびどんの2024年
ご挨拶
多くの人にとってそうだったように、びびびどんにとっても2024年は激動の年だった。Fediverse Advent Calendar 2024、21日の記事は、このなさけないちびのサーバーの受難を軸に、1年を振り返る趣旨のものである。なお、筆者がFediverseアドベントカレンダーに寄稿するのはこれが2回目となる。前回はMastodonのSF的な格好よさについて書いているので、よければそちらも読んでみてほしい。また、この記事に先立って「いやFediverseってなんだよ」「Mastodonって潰れたんじゃなかったのか」というような人に向けて分かりやすく解説した記事も用意しているので、自信のない人は先に読んでおくことをお勧めする。なお、本記事は特にFediverseの知識を必要としない。
びびびどんとはなにか
まずは筆者と、筆者が運営するMastodonサーバー「びびびどん」の紹介から入ることにする。職場で外部講師を招いての研修を受けるたびに、別に属人的な内容の講演でもないのに講師と所属企業の詳細な自己紹介（この会社はどういう分野に強くて、自分は何年に入社して、どういった業務を何年やって……）から始まるのを「要らんやろ」と思い続けてきたが、この記事は思いきりびびびどんの属サーバー的な話なので許してほしい。
筆者、𣅜月蒼葉はそんじょそこらの馬の骨である。詳しいプロフィールはメインサイトのAboutページでも見ておけばいいのではないだろうか。もともと「蕎麦」という名前でネタツイートをし続けるTwitterのオタクだったが、Twitterの空気の悪化と運営方針への疑念に耐えきれなくなり、mstdn.jpに半移住、その後自らMastodonサーバー「びびびどん」を立ち上げるに至った。
そのびびびどんは、2019年1月21日に運用を開始したサーバーである。ユーザーは仲のいい友人やその友人などのみの、いわゆる身内サーバーではあるが、アクティブユーザー数は20人強と小規模サーバーとしてはそれなりの賑やかさを維持していて、「にこにこふわふわ」のスローガンのもと平和にやれている。内政が好きなのでサーバールールやプライバシーポリシーもしっかり目かつ分かりやすいものを独自に作ったり、かつevilにならないような運営を心がけたりなど、管理人としても楽しくやれている。
びびびどんがどのような運営方針に基づいているかは、サーバーの概要ページに記載のとおりだ。全部で方針は5か条からなるが、一つずつ見ていこう。
大規模SNSにありがちな分断と対立、憎悪と悪意から逃れられる、のんびりとした空間であることを第一の目的としています。
これは筆者がMastodonに半移住を決めたとき、Mastodonに託した思いをそのまま方針としたものである。とかくTwitterは性別や国籍、支持政党などでの分断とヘイトが横行していて、特に運営母体が変わってからはひどい有様だ。びびびどんは一義的には、そうした分断とヘイトから逃れられる場として運営している。サーバールールでも政治的意見の表明や偽情報の拡散について制限を設けている。
運営管理においては可能な限り民主的で公正なプロセスと透明性の高さを重視し、管理人がevilとならないよう努めています。
これもTwitterに嫌気がさした理由の一つだが、Twitterだけでなくどのプラットフォーマーも程度の差こそあれevilな運営に陥っている感は否めない。Twitterの現運営が特大のevil（邪悪）であることは論を俟たないが、FacebookやAmazonの巨悪さだって大したものだ。びびびどんでは、管理人がevilにならないよう、運営においては可能な限りユーザーの意見を取り入れ、ルール等の変更時は変更前との違いを可視化するなど、民主性、公正性、透明性を担保するようにしている。
そして、ここからが本題となる3つの条項だ。これら3か条は、いずれも今年の11月に初めて明文化したものである。つまりは、そうせざるを得なかった何らかの事情があったということだ。まずは何も言わずにその条項を見ていただきたい。
Mastodonのタグリリースには特段の事情がない限り速やかに追従し、安定したサービス提供ができるよう心がけています。
サーバーが無法地帯となることのないよう、利用状況の確認と適切なモデレーションを欠かさず実施することを約束します。
定期・随時のバックアップやインシデント訓練等を行うことで、データが消失することのないよう細心の注意を払っています。
びびびどんの2024年を振り返る
それでは、本題であるびびびどんの2024年について振り返っていこうと思う。振り返りの軸とするのは、先ほど挙げた3つの条項だ。そう書けば、まあどんな一年だったかは容易に察しもつくだろう。そもそもこの記事のタイトルが「爆発炎上で振り返るびびびどんの2024年」な以上、言うまでもないことではあるのだが。
1月1日、2024年の幕開け
2024年のびびびどんの幕開けは平穏なものだった。例年通り、筆文字の「辰」だの「寿」だのといった期間限定のカスタム絵文字が乱舞し、それに紛れて筆文字の「神（虹色）」だの「神（金色）」だのといった期間限定でも何でもないカスタム絵文字も乱舞する、ありふれた新年の光景だった。それがこの後、あんなことになろうとは、その場の誰にも知る由などなかったのだ。
2月10日、びびびどん爆発炎上
びびびどんにとって、2024年2月はこれまでで最悪の月だった。それまで大規模な障害もほとんどなく、おっかなびっくりではあるが比較的安定したサーバー運営ができていたびびびどんが、この月に地獄に直面する。
きっかけはMastodon v3.5.17のリリースだ。それまでびびびどんは、タグリリース追従ではなく安定版リリース追従という方針で運営していた。というのも、初期のMastodonでは「安定版以外を運用するのはおすすめしないよ」と公式文書に記載があったほど不安定だったため、筆者はそれに従って「各マイナーバージョンの安定版がリリースされるまでバージョンアップは行わない」という方針を採用していた。
しかし、その方針にはデメリットも多い。中でも一番大きいデメリットは「バージョンアップの回数が少なくなるため、ノウハウの蓄積機会が減少し、いつまで経っても作業に慣れない」というところではないか。もちろんバージョンアップに際しては作業手順書を作るようにはしていたが、それでも不安の大きい中での作業となることは否めない。悪い意味で慣れてしまうのは問題だが、いい意味での慣れは必要だ。
そんな中で事件が起きる。それまでびびびどんはv3.4系とかなり古いバージョンを使用していたのだが、次期バージョンであるv3.5系の安定版、v3.5.17のリリースにようやく気付いた筆者は、リリースノートを見て大焦りした。v3.5系と、それどころかv4.0系はもう今後セキュリティパッチも含めアップデートしない――すなわちサポート終了のお知らせが記載されていたのだ。こうなっては、今からv3.5.17にアップデートしても意味に乏しい。仕方なく段階的に作業を行い、最終的にv4.1系までアップデートすることにした。
しかしここで問題が発生する。v3.x系からv4.x系にアップデートするにあたっては、データベースの移行作業が必要になるのだが、その作業中に不整合エラーが出て、アップデート不能になってしまったのだ。仕方なくバージョンアップを取りやめ、v3.x系に戻そうとしたのだが、どこかで操作をミスしてしまったらしくそれもできない。挙句の果てに、泣きながら何度もロールバックを試しているうちに/var/lib/docker/vfsディレクトリがストレージ全体を埋め尽くすレベルで肥大化し、まともに作業もできなくなってしまった。慌てて廃ボリュームを削除しようとするものの、夜間に作業を始めてから既に8時間以上経過しており、とっくに日も昇っている。疲労と眠気でわけが分からなくなってしまい、生きているボリュームまで削除をかけ、データベースもろとも吹っ飛ばしてしまった。終わりだ。
最後の手段としてMastodonをクリーンインストールし、バックアップを読み込ませることにしたのだが、バックアップはあるもののなぜかレストアにも失敗する始末。一応レストア訓練も行うようにはしていたが、本番環境でそれができないと意味がないんだよな。体力も気力も限界となった12時すぎ、レストアを諦め、白紙の状態でびびびどんの供用を再開した。ユーザーは再度アカウント作成を行う必要があるため、バックアップファイルからユーザーとメールアドレスを抜き出し、メールやTwitterのDM等で謝罪と連絡をして回り、ようやく一段落ついたのが13時半。実に12時間に及ぶ敗北戦だった。
なお、後日作業内容を一人レビューしたところ、レストアの手順を間違っていたことが発覚した。今からやり直せばレストアはできるんだろうけど、もう新しいDBを作ってしまっている……という悲しい事態になってしまった。
2月11日、機能追加中になんかハマる
焼け野原となったびびびどんをさらなる悲劇が襲う！ 前日の復旧作業（もはや旧に復してなどいないが）では、とりあえず主たる機能を復活（復た活かしてなどいないが）させるので精いっぱいだったため、ElasticSearchによる全文機能の整備は後回しにしていた。それをやろうとしたのだが、なんかどこかでハマってしまい、またしても明け方までかかってしまった。
具体的にどういうポイントでハマってしまったのかは一切覚えていない。記録にも残っていない。普段はサーバー作業中に何かあった場合、必ず記録をとるようにしているのだが、前日の疲れが色濃くそんなことをしていられるような状態ではなかった。
余談だが、この日は翌日に恋人とのデートを控えた状態での作業だった。結果、ろくに寝られずへとへとの状態で会う羽目になったのだが、笑って許してくれたし心配までしてくれた。サーバー管理に理解のある恋人、得難いものだ……。
2月14日、管理人アカウントを誤って削除する
焼け野原となったびびびどんをさらなる悲劇が襲う！ びびびどん復活後、featherというクライアントでログインができないという報告をユーザーから受けたため、挙動確認のためにfeather含め様々なクライアントアプリでログインを試していた。筆者はiPhoneではIvoryというクライアントアプリを使用しているため、ログイン挙動の確認をするためにはいったんアカウント情報を削除する必要があったのだが、UIが英語しかなかったために混乱してしまい、「Ivory上から自分のアカウント情報を削除する」をやりたかったのに誤って「びびびどんから自分のアカウント情報を削除する」をやってしまった。アホここに極まれり。管理人のアカウントが削除されるサーバーとか前代未聞ではないだろうか。
泣きながらアカウントを作成し直したものの、新規アカウントという扱いになるため誰からもフォローされていない状態に。仕方がないのでサーバー管理人としての強権を発動し、びびびどんの全ユーザーに自分のアカウントを強制的にフォローさせるコマンドを打つハメになった。びびびどん管理人がevilとなった瞬間だった。当然ながらびびびどん以外のアカウントにそんなコマンドは通用しないので、かなり長い間存在に気付かれずフォローが返ってこない人もいて寂しかった。
なお、そもそものログインできないという事象は、びびびどんがリセットされたことでfeather側で持っていたサーバーリストとの齟齬が起きたことによるものだったらしく、2月22日にfeather側のアップデートにより解決した。迅速かつ親身に対応してくださった開発者の方に感謝。
2月16日～2月20日、スパガキ襲来
焼びさ悲襲！ この節についてはびびびどんに限った話ではないのだが、Fediverse各サーバーに大量のSPAMリプライが送り付けられるという荒らし行為が発生した。荒らしなんてしょうもないことをするのはガキしかいないので、便宜上この攻撃者をSPAM送り付けガキ、通称スパガキと呼ぶことにする。スパガキの手口は単純で、誰でもアカウントを作成でき（かつおそらくメール認証などもない）、モデレーションもほとんど機能していないようなサーバーをリストアップして、スクリプトを用いて大量のアカウントを作成し、公開タイムラインに存在するアカウントに無差別にdiscordサーバーのURL付きのリプライを飛ばしまくる、というものだ。
別にこれといった害があるわけでもなく、何となくリプライ欄が汚れてうっとうしいな程度の効用しかないため、ランク的にはカメムシとかの不快害虫と同じ程度ということになる。まあでも家の中にカメムシはいてほしくないので、各サーバーがそれぞれの手法でスパガキ対策を行った。びびびどんでも、サーバーにSPAMが届く前段にSPAM判定スクリプトを置き、SPAMはその時点でサーバーに送らず破棄するという仕組みを採用した。これについてはこの記事に詳しい。
ただ、すんなりとこの対応が取れたわけではなく、かなりグダついてしまった感は否めない。なにせまったく触ったことのないCloudflareの機能を勉強するところからのスタートだったのだ。それについ数日前に爆発炎上したばかりだったうえ、現在進行形でいくつかの不具合の調査も行っている中でのスパガキ爆誕だったので、もはや消耗戦といったところだ。実際、渦中のタイミングで「HoI4の絶望セーブみたいだ」とpostしている記録が残っている。SPAM判定スクリプトが満足に作動し、スパガキの声が聞こえなくなるのは2月20日になってからのことだった。
2月20日、アマゾン脱出
久しぶりに平和なニュースだ。スパガキとの戦いの中で「どうやらCloudflareというものが便利だぞ」と気付いた筆者だったが、よくよく調べてみるとCloudflareにはS3互換のクラウドストレージも存在し、かつS3より圧倒的に安いことが分かった。
当時、びびびどんは画像や動画等のメディアファイルはすべてAmazon S3というクラウドストレージに保存するようにしていたが、その保存容量は当然ながら年々増加の一途をたどっていく。S3の月額使用料は保存容量に概ね比例するため、爆発炎上直前の時点での使用料は月1000円以上と、サーバー規模に比して無視できない額になっていた。そこで、S3と同じ機能が同じコマンドで使用でき、かつ使用料が意味不明に安いCloudflare R2に移行することにした。ファイルの移行作業でまた炎上するのかな、とも思ったが、案外すんなりと作業は終わり、平和的な権力移譲が実現した。これにより、現在はクラウドストレージに毎月0円を支払っている。
2月10日～2月24日、頻繁なアップデート
びびびどん爆発炎上から2月24日のv4.2.8アップデートまでの2週間で、3回にわたるアップデート作業を行った。消耗している時期にアップデート作業が発生するのは精神的にきつかったが、この間にバージョンアップ時の作業手順や、例外発生時の対応などを確立できたので、結果的には得るものの非常に多い2週間だった。
3月～8月、訪れた平和
この半年間は特に何事もなく平和な時間が続いた。数度あったバージョンアップ作業も、いずれも平和裡に完了していた。筆者はユーザーにサーバー爆発炎上の件をネタにされては、それを甘受しつつ「もう爆発炎上させないぞ」と心に決めていた。
9月1日、史上最も愚かな障害
この日、サーバーにGrowiというwikiアプリをインストールするための作業をしていたが、その際に新たに切り出したサブドメインに証明書のインストールができずnginxの再起動に失敗し、巻き添えを食う形でびびびどんへのアクセスも不能になるという障害が発生した。小一時間大慌てで原因究明をした結果、「サブドメインを切り出すためにドメイン管理サービスのDNS管理画面からAAAレコードを入力していたが、その際に保存ボタンをクリックしていなかった（そのためサブドメインは実際には切り出されておらず、当然存在しないサブドメインに証明書をインストールすることはできないため失敗する）」ことが原因と判明した。
なんか小難しいことを書いたようだが、要は設定を保存していなかったので失敗しました、というだけの話だ。「うっかりさん」という言葉があるが、この場合に使用するのは妥当ではないだろう。もっと適切な言葉がある。「愚鈍」だ。
9月12日〜9月13日、二度目の爆発炎上
9月12日の夜頃から急激にサーバーのパフォーマンスが低下し、その調査対応にあたっていたところ、9月13日の1時頃にサービスが全面的にダウンしてしまった。原因は2月の爆発炎上の要因の一つでもあったDockerボリュームの肥大化だ。前回は消耗しきった状態で「もう分からん！」となり、/var/lib/docker/vfsディレクトリをまるごと削除してしまっておしまいになったのだが、さすがに今回は学習していた。どのコンテナからも参照されていないボリュームだけを選択的に削除していった。そのつもりだったんだ。
削除に使用したスクリプトの使用方法を間違えたのか、またしても生きているボリュームを削除してしまった。みなさんはここまで読んで「こいつマジでなんなんだ」と思ったことだろう。安心してほしい。筆者も思っている。これが自分自身の所業でなかったら「キショすぎ」と一笑に付しているところだ。
とはいえ、さすがに2月のインシデントで懲りていたのでレストア訓練も行っていたこともあり、定期バックアップを読み込ませることでどうにか復旧には成功した。しかし、レストアしたのはユーザーのpostやフォロー、いいねなどを保存するpostgresDBのみであり、タイムラインなどを保存するredisDBはレストアできなかったため（そもそもバックアップをとっていなかった）、復旧直後のタイムラインはただひたすらの無人になっており、ひどく寂しい光景だった。以降、「redisDBは機能面ではバックアップ/レストアする必要はないんだけど、やっぱりあった方がいいよね」という気持ちを抱き、対応していくことになる。
また、postgresDBについても、定期バックアップについてはスクリプトを書いて自動化していたものの、メンテナンス前の随時バックアップについては手動でコマンドを打って対応していたため、今回のような「まあたぶんデータベースに影響でることはないでしょ」みたいな障害の場合は省略することもままあった。今回はそれが完全に裏目に出て、定期バックアップを取得した4時からサーバーがダウンした1時までの21時間分のデータは消失してしまっている。随時バックアップについても省力化のうえで必ず行う運用に改める必要性を感じた。
ちなみに、この障害で同じくDocker運用をしていたGrowiもダウンしたが、こちらは立ち上げ直後でバックアップの設定が追いついておらず、あえなく白紙状態での再スタートとなった。
9月29日、新サーバーへの移行〜新たな地獄の始まり〜
かねてからの懸案事項があった。びびびどんを運用しているサーバーはCentOS 7というOSを使っているのだが、そのサポート期限は6月末で切れているのだ。なんとかしなきゃなあという気持ちは常にあったが、私生活がバタバタしていてなかなかOSの切り替えに踏み切れなかった。というか、普通にAlmalinuxという後継OSに切り替える作業とかもしていたのだが、なんか上手くいかなくてそのままになっていた。
だが、9月の爆発炎上でredisDBのバックアップ対象への追加や、随時バックアップスクリプトの作成など新たな仕組みを導入することになり、それであればこの九龍城と化したサーバーを捨て、新しいサーバーでやり直す方がスッキリするのでは、と思い至り、実は裏でせこせこと作業を進めてきたのだ。そして9月29日、いよいよ新サーバーの準備が整い、びびびどんをサーバー移行させることにした。
ところで、以前からの懸案事項がもう一つある。それは「このサーバー、スペックがムダに高すぎないか？」というものだ。もともとはびびびどんも動かしWordpressも動かし、さらにはmod盛り盛りのMinecraftも動かす予定でいたので、スペックはかなり高めのものを選んでいた。しかし結局Minecraftはほとんどやらないままアンインストールしてしまったので、ムダに高いスペックを持て余している様子が、さくらVPSの管理画面を見るたびにグラフとして映し出されていたのだ。
そのため、新サーバーは旧サーバーよりもスペックを落とすことにしていたのだが、これがよくなかった。サーバー移行自体は最終的には上手くいった。MastodonのインストールもDBのレストアもなんとかできた（redisのレストアについては知見が足りず見送ったが）。しかし、結果だけ見れば上手くいっていても、その裏では10回くらい途中でビルド失敗を繰り返していた。手順書通り、想定通りのステップでビルドが何度も失敗していた。しかもようやくMastodonが立ち上がっても、全文検索機能は死んでいるし挙動も目に見えてノロノロしている。
実はこの日は、午後から恋人と新居を探しに不動産屋に行く予定だった。なんでそんな日にサーバー移行とかいう重い作業をやるのだろうか。答えは簡単だ。愚鈍だからだ。結局この日も明け方近くまで作業が続き、「考えたくないけど、スペックが足りてないんだろうなー」と思いながらとりあえずスワップ領域（メモリが足りない場合に備えてHDD/SSDに作成する、メモリとして使える領域）をバカほど作成してみたらやっぱり多少マシな挙動になったので、そのまま眠りについて午後にはヘトヘトの状態で物件を見て回った。こんな愚鈍に付き合ってあげている恋人とかいう存在、実在するとはにわかに信じがたいものがある。得難いものだ……。
9月30日、敗北のスケールアップ
物件もつつがなく決まり、意気揚々と帰宅した筆者を待っていたのは、青息吐息のサーバーだった。あまりの重さで今にもダウンしそうになっている。具体的には、アクセスしてからタイムラインが表示されるまで2秒くらいかかる感じだった。しかしこのサーバー、まだGrowiを移行させていない。こ、この状態からさらにGrowiを？ 一体どうなってしまうんだ……。筆者は愚鈍なので試しにGrowiも移行させてみたところ、びびびどんにアクセスしてからタイムラインが表示されるまで5秒かかるようになった。ヤバすぎるのでサーバーをスケールアップし、旧サーバーと同じスペックに戻したところ小康状態に落ち着いた、ように見えた。
10月1日、愚鈍
スケールアップしたのにやはりサーバーの調子はよくなかった。どうにも接続が不安定で、すぐにタイムラインが表示されるときもあれば数秒のラグが出るときもある。これは一体どういうことだろうといろいろ調べてみるもどうにも分からず、何となくtopコマンド（メモリとCPUの使用状況を表示するコマンド）を打ってぼんやり画面を眺めていると、なんかおかしい。一昨日バカほど作ったはずのスワップ領域が0になっている。実はスワップ作成時にfstabへのエントリ（スワップの設定を保存する行為。これをすると再起動しても自動的にスワップが再作成される）がうまくできておらず、その後サーバーを再起動した際にスワップ領域が消去されていたのが原因だった。レベル感としては家の鍵を部屋に置いたままオートロックの家を出たくらいの話で、もう愚鈍としかいいようがない。
とはいえ、この件で相当な回数のサーバー復旧を行うハメになったため、意図せずノウハウが溜まりまくった。また、頻繁なメンテナンスでユーザーに迷惑をかけた反省もあり、「今後は障害時に確認できるステータスページも作らないといけないな」と思うようになった。
10月6日、ステータスページ作成
行動が早い！ 一度こうと決めたら一直線、まさに愚鈍といったところだ。ステータスページを作成できるOSSはいくつかあったが、デザインがすぐれているという理由でCachetを採用することにした。また、いくら愚鈍といえどステータスページをびびびどんと同じサーバーに置いたら何の意味もないことくらいは理解していたので、別エリアに新たにサーバーを作成することにした。こちらはCachetと大学時代のサークルのWebサイトくらいしか置かないことにしたので、スペックはかなり絞ったものにして出費を浮かせることに成功した。
Cachetはそれ単体では手動で情報を更新するしかないが、cachet-url-monitorというプラグインを使うことで自動監視が可能になる。これにより、現在は30秒おきに稼働状態を更新するようにしている。また、バージョンアップ等のメンテナンスをする際も詳細をそこに記載するようにした。なんかWebサービスって感じがして楽しい。
なお、Cachetはかなりバグが多い上に開発も凍結している（新バージョンの開発に専念しているらしい）ので、利用は完全に自己責任でといった感じであり、おすすめはしない。実際にその後数日間はバグ潰しにかなり時間をとられた。ただ、デザインは他のアプリと比べてもピカイチなため、新バージョンがリリースされたら大手を振っておすすめしたいと思う。
10月9日、スパガキは二度死ぬ
10月8日にMastodon v4.3.0への大型アップデートの準備をつつがなく終えて、あとは翌日夜にコンテナを切り替えるだけの状態までこぎ着け、ようやくサーバー管理者としての自信が少しだけ戻ってきたその日、やつはまた現れた。タイミング的にバージョンアップとスパガキ対策を同時にやるハメになる。勘弁してくれ。
とはいえこれは2月に作ったスパガキ対策スクリプトを少し書き換えるだけでなんとかなった。これも先述のページに詳細を記載しているので、そちらを参照されたい。
11月4日、幕間
https://bbbdn.jp/@minadzki/113420594296559691
11月5日、スパガキ×☆☆☆
もう飽きたんだ、味のしないガム。またスパガキが現れたので、さくっとスクリプトを書き換えて対処した。スパガキがこちらの対策を把握して迂回法を考えている可能性も考慮し、今回の対処法はびびびどんユーザーにのみ公開することとしたので、ここでは詳細は伏せる。
11月15日、スケールアップも二度死ぬ
9月末にスケールアップしてスペックは上がったはずなのだが、それでもどうもびびびどんの挙動は緩慢だった。いや、びびびどんはまだいい。Growiの挙動があり得ないレベルで遅くなっている。Wordpressもたまにとてつもないラグが生じる。ひょっとして、ひょっとして……まだスペックが足りないのか？ 恐る恐るtopコマンドを叩いてみると、CPU使用率は低空飛行を続けているが、メモリ使用量がほぼ100%になっていて、常にスワップのお世話になっている状況だった。これはいけませんねえ……と言いながらVPSのスケールアップボタンをクリックしたところ、びびびどんもGrowiもWordpressも嘘のように爆速になって、思わず笑ってしまった。
スケールアップ後のびびびどんはこれといった不具合も見られず、常時快調に動いている。一度バージョンアップ直後に画像や動画といったメディアファイルのアップロードができなくなる事象が発生して肝を冷やしたが、たまたまバージョンアップと同タイミングでCloudflare R2側に不具合が生じていただけらしく、半日放置したら治っていた。それ以外は特筆すべき事象はない。
激動の2024年から学んだこと
こうして記録をもとに振り返ってみると、記憶以上に恥の多い1年を送ってきたと感じる。特にデータを消失してしまったのは忸怩たる思いであり、今なおその記憶が色濃く、友人に「びびびどんに来なよ」とすら気軽に言えなくなっている。「安定性とか考えたらFedibirdがおすすめだね～……ち、ちなみにぼくもびびびどんってサーバーをやってる、よ（小声）……？」とボソボソしゃべるのをもうやめたい。そのためにも、長期安定運用の実績を積み重ねていかなければならないところだ。
サーバーの運営方針にも今年の反省が大いに反映されている。爆発炎上の一つの要因として、安定版追従の方針が存在していたのは間違いない。そのため、新生びびびどんではタグリリース追従の方針をとることにした。また、インシデント訓練などの必要性も痛感したところだ。バックアップ取得用のスクリプトも改修し、postgresとredisの両方をバックアップできるようにした。バックアップ中のnginxの一時停止等も1コマンドで自動でやってくれるので、現在はどんな些細なメンテナンスであっても必ずバックアップをとるようにしている。スパガキに関してもいつ第4波が来るか分からないので、Cloudflare上のスクリプトとモデレーション、ハードとソフトの両面からしっかり対応を行う必要がある。この対比の場合、スクリプトがハード扱いになるのおもしろいな。
本来であれば安定運用のためには試験環境を別途用意すべきなのだろうが、本番環境と同等の環境をもう一つ用意するのは、個人ユースでは経済面でかなり厳しいものがある。ステータスページを作成した際にサーバー2台構成にはなったものの、2台目は本当にスペックが低めなのでMastodonの試験にはそぐわないだろう。このあたりについては来年以降の課題ということにしておこうと思う。
ともあれ、大変な一年だったが、かえってノウハウが蓄積されるなどいい面もないわけではなかった。昨年までのびびびどんは確かに大規模な障害などもなく、安定したサーバー運営ができているようではあったが、今思えばそれは安定版追従というメンテナンス機会の非常に少ない運用方針を採用していたからであって、見せかけの安定でしかなかった。今年の相次ぐ爆発炎上でユーザー各位には多大な迷惑をかけてしまい、申し訳ない限りではあったが、これを糧に来年以降は真の安定運用により無障害記録の積み上げを目指していきたい。
また、大事な日の前日にサーバーを爆発炎上させては死にそうな状態になっている筆者を、いやな顔せずに受け入れてくれた恋人にも感謝を伝えておきたい。いや、いやな顔一つくらいはしていたかもしれない。いずれにしても愛想を尽かさずにいてくれたのは本当にありがたいことだった。来年はこのようなことのないよう心がけたい。
さて、来年の抱負も書けたところで、このあたりで筆をおこうと思う。この記事は「Fediverseアドベントカレンダー2024」であり、「本番環境でやらかした人アドベントカレンダー」っぽくもあり、実質「しくじり先生～俺みたいになるな！！～」であった。
