この記事は、Misskeyサーバ「パズルゲームすきー」の年末企画 「逆アドカレ2025」12/31の記事です。
皆様、サーバはお好きですか?
ここでは創設~2025年12月31日のパズルゲームすきーのサーバ管理者としての奮闘をここに記します。
運用理念
まず、当サーバの運用理念として、次の3つがあります:
- サーバの利用料金を極力減らす
- 人力の手間を極力減らす
- サーバが突然死んでも復活できるようにする
また、各種Fediverseのサーバがサービス終了する主な原因は下記の3つがあります:
- サーバの利用料金が高すぎること
- モデレーションが追い付かないこと
- DBバックアップしてなくて死ぬこと
そうです、当サーバの運用理念の逆を行うとこうなります。
つまり、当サーバの運用理念はサービス終了を防ぐための理念ということです。
世の中のサーバエンジニアには新しい技術とかを率先して使いたがる人もいますが、自分の考えとしては、「利用者にとって便利なこと(しかし言及されづらい)はいつでも使えること・当たり前のように使えること」です。このため、とにかく管理の手間が少ない技術を選び、サービス維持を第一にすることが一番重要です。
そして、サービス維持のために、「資金的コスト」や「人的コスト」を極力減らす、「省エネ運用」を常日頃から心がけています。
心がけているだけでできているかはわかりませんが、これまでの奮闘をここに記します。
尚、サーバに関する専門用語がわからない場合は、ググってください。
サーバ構成について
2025年12月31日時点での構成
初代サーバ Contabo
- VPS業者:Contabo
- 使用期間:創設~2025年5月
- 料金:12.5USD
- 性能:6vCPU、メモリ12GB、SSD200GB
当時は安価で高性能のサーバがあると飛びついた私でした。
当初は安定しており、また潤沢なリソースで結構パフォーマンスに余裕があると思っていました。
また結構SSD容量も多く、実は結構便利だとは思ってました、そう、2025年5月までは・・・
2025年5月初めくらいから不安定になり、1週間に1回前後サーバが落ちて、サーバコンソールから起動させないといけなくなりました。昼間であればすぐに気づいて再起動をかけられますが、深夜に落ちた場合に復旧に時間がかかり、「朝に落ちる」という事態が発生しました。特に、最後の方は1日2回落ちていました。
https://mk.puzzlesskey.com/notes/a7uu4kutlb76000g

2代目サーバ Time4VPS
- VPS業者:Time4VPS
- 使用期間:2025年5月~2025年11月
- 料金:13.02EUR
- 性能:3vCPU、メモリ8GB、SSD80GB
そこで急遽、以前より稼働実績のあったTime4VPSに移行することにしました。
急に移転の必要が発生し、とにかく急ぐ必要があり、ユーザ影響を最小にしつつ段階的な移行を行いました。
第一段階としては、昼間にRedisとMisskey本体・nginxの移転を行いました。
RedisとMisskeyは同居でないとRedisの速度を生かせないこと、また切り替えに時間がほとんどかからず、ダウンタイムがほぼ発生しないことから、移行先サーバに先にMisskey・nginx・Redisを入れて、移行元にあったPostgreSQLとはTLS通信をするようにしました。
第一段階完了直後の構成
第二段階として、時間のかかるDBの移行を深夜に行いました。
DB移行中はサービス停止が発生する上にDB移行には時間がかかるため、深夜のうちに全移行が完了しました。
これによりユーザ影響を最小限にしつつ移行に成功しました。無事2日前後でサーバ移行が終了しました。
また、Time4VPSは実は若干癖のあるサーバでしたので、DNSを手動で入力しないとうまく動かず、外部との通信がうまくいかないという謎の事象にも見舞われました。
これに関しては、暫定対応としてはDNSに8.8.8.8指定し、あとでVPS業者のDNSサーバについて調べて、そのIPを入力して恒久対応としました。
https://mk.puzzlesskey.com/notes/a7yg1kkigxlz00l5

なお、移行直後にやはり初代サーバが落ちていました。あやうくまたダウンタイムが発生するところでした。
3代目サーバ Hetzner
- VPS業者:Hetzner
- 使用期間:2025年11月~
- 料金:6.59USD
- 性能:4vCPU、メモリ8GB、SSD80GB
2代目サーバから3代目サーバに移した理由としては、単純に料金が大体半額で済むという理由です。(あとEURJPYが160円くらいだったのが180円くらいになったのもある)
しかし、今回は安さだけに飛びついたわけではなく、実は後述のパズルゲームすきーβでの稼働実績があったので3代目への移行を決断しました。
この時は別にサーバ不調で急遽移転したわけではないことと、一度移行作業を行って移行に慣れたというのもあり、
移行前までにゆっくり時間をかけて準備をして、移行当日深夜に一気に移転しました。
さすがにもう、次の移転はないと思います。4代目サーバはないと思います。具体的にどうとはあまり言えませんが・・・
検証環境としてのパズルゲームすきーβ (Hetzner)
- VPS業者:Hetzner
- 使用期間:2025年5月~
- 料金:3.49USD
- 性能:2CPU、メモリ4GB、SSD40GB、IPv6のみ
最初は4vCPU,メモリ8GB、SSD80GB、IPv4ありで運用していましたが、性能過剰であることに気づいたので途中からスケールダウンさせました。(ストレージ縮小するので移行作業必須になりましたが)
パズルゲームすきーβを立てた理由としては、いろいろサービス改善のための施策を行おうと思ったのですが、サービス影響のある変更をポンポン本番環境で行うのはどうかと思ったというのが一番の理由です。
このサーバを立ててからは、後述のオブジェクトストレージ関係の施策を試したり、またはデータベースソフトウェアのアップグレードを先に行って、手順を確定させたり影響を調査した後に本番で作業を行えるようになりました。
尚、細かい話ですが、IPv4のない環境だと、料金は安くなりますが、Githubへの通信ができなかったり、Misskeyのビルドに失敗したりするので工夫が必要です。
オブジェクトストレージ関係の施策
まず、当サーバはオブジェクトストレージから画像・動画等を配信していますが、
2025年6月から、BackblazeからCloudflareを経由して直接ユーザにファイルを配信することで、転送料金(ダウンロード帯域幅料金)が0になりました。
Backblaze B2では、Cloudflare経由での配信が無料になる仕様のため、これで一切転送料金がかからなくなりました。
以前の状態について
サーバを立てた当初はオブジェクトストレージ(Backblaze B2)の転送量問題で、たまに画像や動画ファイルが配信できなくなっていました。
Backblaze B2からの転送量に応じて料金がかかるので、その日一定以上、オブジェクトストレージからの配信量があった場合は配信を止めて料金をそれ以上払わないようにしていました。
しかし、当然これはユーザに画像・動画を配信できなくなるため、どこかで作業をしようと思っていました。
結果的には初代サーバのゴタゴタもあり、初代サーバの移転が終わって落ち着いたタイミングで設定を行いました。
参考までに、当初の構成:
赤矢印に注目、Misskeyサーバ・Cloudflareを経由して配信している。

今の構成
Backblaze B2から、Misskeyサーバを通さずにCloudflareのみを経由して配信している。

Backblazeのダウンロード帯域幅グラフ
6月からFree Transfersが大量に増え、また7月から突然ほぼ0になっている。この施策を行ったタイミングが6月なので、ちょうどタイミングが重なっている。

2025/12/30時点でのCloudflareのダウンロード帯域幅(過去30日)
配信すべき帯域幅の内、9割近くをCloudflareからキャッシュできていることがわかる。

運用面
今までハードウェア的な話ばかりしてきましたが、これは料金面の問題。「資金的コスト」です。ここからは「人的コスト」削減の話をします。
料金だけがコストなのではなく、手間もまたコストだと考えている私は、サーバの保守運用の手間を減らすべく、以下のような施策を行いました。
- DBバックアップスクリプトの作成・運用
- Misskeyのアップデートスクリプトの作成・運用
- Uptimerobotによる死活監視
- 新規ユーザ登録通知の作成
DBバックアップスクリプト
これは、DB(PostgresとRedis)をバックアップした後に、データをオブジェクトストレージに放り込むスクリプトです。
サーバ創設直後は定期的にDBの手動バックアップをしていました。
しかし、Linuxでは基本的にコマンドをそのままシェルスクリプトにしてしまえば楽ができるので、割と早い段階で手動起動のバックアップスクリプトを用意しました。
その後、遅くとも2代目サーバの時点ではバックアップが全自動化されました。
全自動化といっても大したことはなく、systemd timerで午前3時に起動するだけです。よくある夜間バッチですね。
また、遅くとも2代目サーバ時点スクリプト自体のバックアップもかねてGithubのプライベートリポジトリを作成し、そこで管理するようにしました。
Misskeyアップデートスクリプト
これは、DBバックアップ・git pull・ビルド・設定ファイルの上書きなどを一括で行ってくれる感じのスクリプトです。
Misskeyは定期的にセキュリティアップデートがあり、管理者はなるべく速やかに適用されることが(おそらく)推奨されています。
2025年だけでも6件あります。
https://github.com/misskey-dev/misskey/security
また、新機能には便利なものが多いため、アップデートスクリプトを作成し、少ない手間でアップデートを行えるようにしました。
これにより、毎回アップデートに10分程度手作業をしていたのが、コマンド1つでできるようになったのでだいぶ楽になりました。コマンドを打ったら放置してテトリスができるので。
尚、アップデートは自動ではなく手動でアップデートしています。(パズルゲームすきーβのほうは自動だけど)
Uptimerobotによる死活監視
Uptimerobotによる死活監視で、サーバのトップページが表示されない場合にすぐに通知されるようになりました。
サーバの死活監視をしておくことで、初代サーバの時にあった、「いつの間にか落ちていた」をすぐに判別できるようになりました。
これで、落ちるのを防げなくても、落ちた後にすぐに対処することができるようになりました。
新規ユーザ登録通知の作成
これはどちらかというとモデレーションコスト削減の施策です。
MisskeyにはWebhookを登録する機能があり、新規ユーザが登録したり、通報があった際にそれを外部に通知する機能があります。
これを用いて、Discordに通知を飛ばすことでいち早く新規ユーザが登録したり通報があった際に対応できるようになりました。
パズルゲームすきーは新規ユーザが1日1人以下しか入らないためできている施策かもしれませんが、
海外のスパムっぽいユーザかどうかをいち早く確認し、明らかに怪しいアカウントについて早期に対応できるようになりました。
少なくとも毎朝ユーザ一覧を確認しなくて済むようになったのはよかった。
参考までに
自分は下記2つの記事を読んでWebhookを使えるようにしました。
https://memo.kabomk.com/misskey-webhook/
https://7ka.org/2024-08-02-misskey-webhook-discord/
その他細かいこと
- 創設直後はPostgreSQL16だったのでPostgreSQL18にしました!
- PGroongaを導入して、投稿の検索を早くしました!
- Misskey本体とnginx間をUNIX Domain socketで通信するようにしました! (あんまやってるサーバ聞かない、権限さえ気を付ければ簡単だよ)
今後
今後もサーバをより楽に運用できるようにするため、実は以下のようなことも考えています。
他にもやってて面倒だと思うことがあったら増えるかもしれないけど・・・
- PrometheusとGrafanaを用いてサーバリソースの監視をする
- もうちょっとDBバックアップ用スクリプトを改善する
- 月次バックアップの仕組みがちょっといけてない仕組みになってる
下らんネタ
あなたとMisskey,
今すぐアップデー
ト
なんか言ってたら伝染したっぽい
https://mk.puzzlesskey.com/notes/afa2mzuu6eao01uh

https://misskey.io/notes/afm9s06monp702ce

あとがき
1年に色々やりすぎじゃね???

